From vesely@tana.it Wed Aug 1 09:00: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 C9F8221F8526 for ; Wed, 1 Aug 2012 09:00:20 -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 D8DSELJFAWSC for ; Wed, 1 Aug 2012 09:00:19 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8521F853A for ; Wed, 1 Aug 2012 09:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1343836817; bh=mk266fU4DTZGt7dwCELxW0YmOiGaN9z1kBlUEjFuKmc=; l=1355; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gikgB2EUsGvg/eeYpMQSZfDFqF8/Z2eyK25jcsg+H3hAGiDRQF9Un29MWobX2mIQu BNTjUeEFH2793/cRemDT3yrY7O0BTbR9Odp28Mtwkq6mIUlb3I3M+ORG/O8bmPB9fy /fFCfjEswqWnY7crSnxY+tD7lxPAzucS1SHEU7Mk= Received: from [130.129.16.138] (dhcp-108a.meeting.ietf.org [130.129.16.138]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 01 Aug 2012 18:00:16 +0200 id 00000000005DC04A.0000000050195290.00002756 Message-ID: <50195284.5010807@tana.it> Date: Wed, 01 Aug 2012 09:00:04 -0700 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <2356084.rOqJxuchnj@scott-latitude-e6320> In-Reply-To: <2356084.rOqJxuchnj@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [spfbis] Recommend without mandating, was SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:00:21 -0000 On Tue 31/Jul/2012 21:01:39 -0700 Scott Kitterman wrote: > On Wednesday, August 01, 2012 01:44:06 PM Wayne Doust wrote: >>> Your suggested wording for 2.5.6 reads to me as if SPF can ever >>> provide a definitive result for message acceptance. It can't. >> >> I've used the wording from other parts of the same section. It >> doesn't seem to be a problem there to recommend a course Of >> action without mandating it. > > With one exception, RFC 4408 doesn't specify receiver policy. The > furthest is goes is to say, if you do X, then do it this way. > That's significantly different than what I think you are > suggesting. For the sake of clarity, it would be better to mention that protocol Y specifies how to do X. Examples may improve readability without conflating which specification is in charge of specifying how to do X. In order to convey that attempted relays with an SPF result of R deserve X, we must say so explicitly. The importance of such specifications cannot be overemphasized. Not only they are needed for discussing the pros and cons of possible alternative behaviors, but they are fundamental to convey the exact meaning of R. It has been noted multiple times that the terms of RFC 2119 are not suitable for such specifications. That doesn't make them any less urgent, we just have to use other terms. From hsantos@isdg.net Wed Aug 1 09:09: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 E95B911E8113 for ; Wed, 1 Aug 2012 09:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=-0.428, 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 Dd27m2Y0bftd for ; Wed, 1 Aug 2012 09:09:06 -0700 (PDT) Received: from news.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BA93711E8091 for ; Wed, 1 Aug 2012 09:09:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2911; t=1343837339; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OjxhR7VtPaweYl4cVia/ybwVBAQ=; b=mtA/LYYm5lTCvHBNcHUj KySua1b0aDlbvBlW5oJHsMPm+J3s5TLon7ZOSIcr4UsF6QL3xETLtuQS8TyXvw2p JA1GnRRbKsjiTQ2O51ViFvM8RZXxHgsA/MIlFGh8B3QrroUGd8hfgi107HTpaSZT 0LigaENnbAXiYE/TEcdYyec= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 01 Aug 2012 12:08:59 -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 4154124548.5475.4588; Wed, 01 Aug 2012 12:08:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2911; t=1343837186; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DXZOZt9 Z6hoBR5xvK5/TgmK44fugqmUif370NOLrA2I=; b=JOGfMBBya/3AZ73Rvw5J2cw CO9atRujSTshhadmXXA8NKukhr2NrXFqnqf5UbULH6CAmuNt7qspFxcVTMlyXt09 E2IVfGSMdicfco3LZRwR6eplVgzduUjTc17Nd/tM7s4iDuC9Z2usn06jV2L6iTKR Dd5JdU4jtZUyzec65LZQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 01 Aug 2012 12:06:26 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 457983458.9.1232; Wed, 01 Aug 2012 12:06:24 -0400 Message-ID: <501954A0.3090306@isdg.net> Date: Wed, 01 Aug 2012 12:09:04 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Wayne Doust References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3725056.uMTa6O8Y0m@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <5018AE61.4010202@isdg.net> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:09:07 -0000 Wayne Doust wrote: > I don't see how this follows. The "Bad Guy" would have to own the domain and > publish the SPF record. A bad guy with an invalid SPF record is in > a worse position than a "Bad Guy" with a valid SPF record. Right, but your proposal would relax the invalid SPF record to an indeterminate ("throw your hands up/give up") neutral condition which means it passes/skips SPF testing. >> But lets remember that ABUSE is also not just the user but also >> the receiver getting slammed with malicious abusive spoofers. > > This is OT, but the only case where I see this applies is publishing > a costly SPF record and then spamming possibly causing DOS. Abuse does not need to reach a DoS, but the attempt to do so and also just taking up CPU processing time and system resources, increasing your TCO. It may depend on volume. The bigger you are, the more you can absorb it (or not), but the smaller system will feel it (or not), they will be more apt to notice it. One way to measure it is with higher SMTP session times. >> What will you do if it was a bad guy with syntax errors? Accept the mail? > > Treat them as a bad guy with no SPF record. I don't see many bad > buys WITH SPF records (yet). There are quite of bit of them, and if want to lump Spammers and eMarketers with the "bad guy" label, there are quite a bit that want to give the "good guy" appearances of compliancy and following all the best current practices. >> Is there anything in SPF that can cause a PERMERROR in this similar manner? >> Where it can be too STRICT and needs to be RELAXED? > > The grammar for SPF is quite strong. However IME, there are mail > scanning "devices" that have choked on proper SPF entries. One case where a PERMERROR to REJECT translation can be a problem are with the artificial limits placed on SPF. Why 10? Why not 8 or 12, or even 20? This seems like Deja Vu to me, but Scott may wish to consider how SenderID RFC4406 has it written: 5.1. Neutral, None, SoftFail, or PermError An SMTP server receiving one of these results SHOULD NOT reject the message for this reason alone, but MAY subject the message to heightened scrutiny by other measures, and MAY reject the message as a result of this heightened scrutiny. Such additional security measures MAY take into account that a message for which the result is "SoftFail" is less likely to be authentic than a message for which the result is "Neutral". The thing is that the "heightened scrutiny" was learned and if a policy is perpetually in permerror, then as RFC 4408 has it as open ended, it does require an manual intervention or as I like to shoot for, automated logic to take action on those domains with invalid policies. Making it neutral is cool, but if its not fixed, eventually that needs to be seriously address and rejected - IMO. -- HLS From sm@elandsys.com Wed Aug 1 12: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 754F211E809B for ; Wed, 1 Aug 2012 12:40: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.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 5+pxyXPbQmAN for ; Wed, 1 Aug 2012 12:40: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 51C8711E814F for ; Wed, 1 Aug 2012 12:40:09 -0700 (PDT) Received: from sm-THINK.elandsys.com ([41.136.237.200]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q71JdrkH027379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 12:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1343850005; bh=SknIPYm5ErmlerhJNmnCNFKH9sqIahd17VwAM1eui0I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K/euXZ0sH6W88suscq47NOtvzzrXOZImBGwaWL3HYjahNIFFKJqaQR/XLJ5Q+KezX q7m318cYYm/j0awdGOhYlU4hjfRk9A+vKnkpb1Lrq+rVkBohX8nSeBKU9PSh3B86JT vKiEPPPJXuzoiwQnIydVdYj3LMSJOb3lwyyCRYC8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1343850005; i=@elandsys.com; bh=SknIPYm5ErmlerhJNmnCNFKH9sqIahd17VwAM1eui0I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tLg1V26S4ZCs09krKlLv03g3YSfOzpWmKOkhWDhgZhcyOKoiVU7NXmbDO8t8avfDV tyXaWL1gQab80JS9S+IBC5TlBKELjOUkkMwPzvYki0jOYkya38o8P9l/WNcYotDeam /Pwfgyqboqp1dmRIlNuqa8NtMGupXyqEkA+Hr0Qg= Message-Id: <6.2.5.6.2.20120801120941.04acbe28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Aug 2012 12:39:23 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.inter nal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <3510820.QBJdz4C5b1@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B05@XCHANGE.rvl.internal> <3725056.uMTa6O8Y0m@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: [spfbis] Disclaimers (was: SPF parsing failure should default to SPF NEUTRAL) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 19:40:12 -0000 Hello, I would like to remind the working group that all IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Please read the "Note Well" ( https://www.ietf.org/about/note-well.html ). Section 5.2 of RFC 5378 states that: "No information or document that is subject to any requirement of confidentiality or any restriction on its dissemination may be submitted as a Contribution or otherwise considered in any part of the IETF Standards Process, and there must be no assumption of any confidentiality obligation with respect to any Contribution. Each Contributor agrees that any statement in a Contribution, whether generated automatically or otherwise, that states or implies that the Contribution is confidential or subject to any privilege, can be disregarded for all purposes, and will be of no force or effect." Working participants are deemed to have accepted all IETF rules of process, including the above about disclaimers. Regards, S. Moonesamy SPFBIS WG co-chair From superuser@gmail.com Wed Aug 1 14:53: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 0D5D111E829B for ; Wed, 1 Aug 2012 14:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 8T7dpNSenDUp for ; Wed, 1 Aug 2012 14:53: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 B202911E82F3 for ; Wed, 1 Aug 2012 14:53:19 -0700 (PDT) Received: by lagv3 with SMTP id v3so5162758lag.31 for ; Wed, 01 Aug 2012 14:53:18 -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=19wI/ipwaX5N6qlaUbwE7v7+uRngUUqtDIIrgZorOkE=; b=I+iZiab3c9COn6uWyJIH0pomYfufNtfMa5ejmbcrfN6zy7bjHQvdlaDzlpiAn3rwVn IydWIZBQMoGzymHfISnq92I5QZc8BH9ZObIxPJfmegNEMHUmsEooIFHu6KN//YQlapZ0 GZHL5vTQA3Me5ZfUIC//v7iPSaJweFtZCxpVCrmwSs6gdEIiLhr0EVI15khVvOym6uRP /25fTxShNH8E3fjobHk1VbBlVILKet0gzqWruAZVfR1fvyCavsUdzkr2IfoGO1O7gEjv g25rp6x2chYa6K6RLlsoD2JWJhyWGngT79S20tJWYYNVSbDINDWOgMQNxxf78sjokwCE AoLA== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr19451059lab.43.1343857998571; Wed, 01 Aug 2012 14:53:18 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 1 Aug 2012 14:53:18 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B67@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <2356084.rOqJxuchnj@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B67@XCHANGE.rvl.internal> Date: Wed, 1 Aug 2012 14:53:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: multipart/alternative; boundary=f46d0434bfdea2287404c63b5248 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:53:21 -0000 --f46d0434bfdea2287404c63b5248 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 31, 2012 at 9:36 PM, Wayne Doust wrote: > Currently, there is no recommendation for PermErrors at all. I think it > should be clearly stated that PermErrors should be treated as no worse > than None. > I think this argument reduces to "Don't bounce mail, because software at either end could be buggy." One might even argue that a bug somewhere in the evaluation might trigger the "-all" at the end of the record for an otherwise legitimate message, and that's also obviously bad. But I'm not sure that we have to deal with it here. A faulty implementation of anything can have serious results that become pain points for either end of the protocol. SPF isn't special in that regard. I suppose, though, that some informative discussion of this particular issue somewhere (an appendix) with the above in mind might be prudent. -MSK --f46d0434bfdea2287404c63b5248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 9:36 PM, Wayne Doust <W.Doust@racingv= ictoria.net.au> wrote:
Currently, there is no recommendation for PermErrors at all. I think it
should be clearly stated that PermErrors should be treated as no worse
than None.

I think this argument reduces to "= Don't bounce mail, because software at either end could be buggy."= =A0 One might even argue that a bug somewhere in the evaluation might trigg= er the "-all" at the end of the record for an otherwise legitimat= e message, and that's also obviously bad.

But I'm not sure that we have to deal with it here.=A0 A faulty imp= lementation of anything can have serious results that become pain points fo= r either end of the protocol.=A0 SPF isn't special in that regard.
<= br> I suppose, though, that some informative discussion of this particular issu= e somewhere (an appendix) with the above in mind might be prudent.

-= MSK
--f46d0434bfdea2287404c63b5248-- From prvs=5536a0696=fmartin@linkedin.com Wed Aug 1 15:18: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 D4CDE11E8305 for ; Wed, 1 Aug 2012 15:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpmcXUcsXZhu for ; Wed, 1 Aug 2012 15:18:47 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4589E11E82FF for ; Wed, 1 Aug 2012 15:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim; t=1343859527; x=1375395527; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=quxFzGN4gZJeLGXuOKhFnPpcTlFb25YNZHRXr/Dtsz0=; b=Di19OjfyGOQ0Wj+F51Pd7apPI9JLaErAVAbFagcvn6fIFVPKzjmyk947 RqBDRivNCZC0doHKcgRLza8cFm6bRAFD3UEnDYi11q9wmCSK/mzU7ivmO GG3/0wL+aYXW7Ay; X-IronPort-AV: E=Sophos;i="4.77,696,1336374000"; d="scan'208";a="22260703" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Wed, 1 Aug 2012 15:18:24 -0700 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] SPF and empty mail from envelope spec is unclear. Thread-Index: AQHNa4zJSInjtc1rf0KkMKN4sD5TeZc9FpkAgAGp3YCAAACbgIADgc8AgAB+KYD//5DPgIAAeISA//+gb4CAAyVLAA== Date: Wed, 1 Aug 2012 22:18:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AA587255E9D1444B1FEF75612C248CA@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] SPF and empty mail from envelope spec is unclear. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:18:48 -0000 A small rewrite because of the suggestion of using wildcard domains, if there is any DNS record for a specific name then the wildcard is not used. People tend to put a A or AAAA record for the forward DNS verification done (after the reverse one) on the connecting IP during the SMTP connection. New text: 9.1.3 Bounces As explained in 2.2, [RFC5321] allows the reverse-path to be null, which is typical of some Delivery Status Notification [RFC3464], commonly called email bounces. In this case the only entity available for performing an SPF check is the HELO identity defined in 1.1. Administrators MUST(SHOULD?) ensure that this identity is set correctly and has an appropriate SPF record. It is common to have the HELO identity set to hostname instead of domain. Administrators SHOULD consider publishing an SPF for *.domain (wildcard domains) in that case if the involved hostnames do not have already any specific DNS record. From W.Doust@racingvictoria.net.au Wed Aug 1 16:11: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 44BD411E8235 for ; Wed, 1 Aug 2012 16:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19AJYJ33AmVG for ; Wed, 1 Aug 2012 16:11:10 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48711E81CC for ; Wed, 1 Aug 2012 16:11:07 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 9558) id ; Thu, 02 Aug 2012 09:11:04 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 2 Aug 2012 09:10:29 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B9F@XCHANGE.rvl.internal> In-Reply-To: <501954A0.3090306@isdg.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1v//6+8O7iOyTFR+qsWcWRRoiniAAOr41A References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><3725056.uMTa6O8Y0m@scott-latitude-e6320><0D2A0D5F64179F4F9556D3DEDE39F9AF01027B0B@XCHANGE.rvl.internal> <1472908.4zQmik4QZ7@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B4F@XCHANGE.rvl.internal> <5018AE61.4010202@isdg.net> <0D2A0D5F64179F4F9556D3DEDE39F9AF01027B6E@XCHANGE.rvl.internal> <501954A0.3090306@isdg.net> From: "Wayne Doust" To: "Hector Santos" Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:11:11 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpUaGlzIHNlZW1zIGxpa2UgRGVqYSBWdSB0 byBtZSwgYnV0IFNjb3R0IG1heSB3aXNoIHRvIGNvbnNpZGVyIGhvdyBTZW5kZXJJRCBSRkM0NDA2 IGhhcyBpdCB3cml0dGVuOg0KDQogICAgNS4xLiAgTmV1dHJhbCwgTm9uZSwgU29mdEZhaWwsIG9y IFBlcm1FcnJvcg0KDQogICAgQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIG9uZSBvZiB0aGVzZSBy ZXN1bHRzIFNIT1VMRCBOT1QgcmVqZWN0IHRoZQ0KICAgIG1lc3NhZ2UgZm9yIHRoaXMgcmVhc29u IGFsb25lLCBidXQgTUFZIHN1YmplY3QgdGhlIG1lc3NhZ2UgdG8NCiAgICBoZWlnaHRlbmVkIHNj cnV0aW55IGJ5IG90aGVyIG1lYXN1cmVzLCBhbmQgTUFZIHJlamVjdCB0aGUgbWVzc2FnZSBhcw0K ICAgIGEgcmVzdWx0IG9mIHRoaXMgaGVpZ2h0ZW5lZCBzY3J1dGlueS4NCg0KICAgIFN1Y2ggYWRk aXRpb25hbCBzZWN1cml0eSBtZWFzdXJlcyBNQVkgdGFrZSBpbnRvIGFjY291bnQgdGhhdCBhDQog ICAgbWVzc2FnZSBmb3Igd2hpY2ggdGhlIHJlc3VsdCBpcyAiU29mdEZhaWwiIGlzIGxlc3MgbGlr ZWx5IHRvIGJlDQogICAgYXV0aGVudGljIHRoYW4gYSBtZXNzYWdlIGZvciB3aGljaCB0aGUgcmVz dWx0IGlzICJOZXV0cmFsIi4NCg0KLS0NCg0KSSB0aGluayB0aGlzIHdvdWxkIGZvb3QgdGhlIGJp bGwgdmVyeSBuaWNlbHkhDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KRGlzY2xhaW1lcjogVGhpcyBlbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbC4gICANClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBlbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGJlIA0KY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBhbnkgdXNlLCBpbnRlcmZlcmVuY2Ugd2l0aCwgDQpkaXNjbG9zdXJlIG9yIGNvcHlpbmcgb2Yg dGhpcyBtYXRlcmlhbCBpcyB1bmF1dGhvcmlzZWQgYW5kIHByb2hpYml0ZWQuDQpUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGFsc28gc3ViamVjdCB0byBjb3B5cmlnaHQuICANCk5v IHBhcnQgb2YgdGhlbSBtYXkgYmUgcmVwcm9kdWNlZCwgYWRhcHRlZCBvciB0cmFuc21pdHRlZCB3 aXRob3V0IHRoZSB3cml0dGVuDQpwZXJtaXNzaW9uIG9mIHRoZSBjb3B5cmlnaHQgb3duZXIuDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBpbW1lZGlhdGVs eSBhZHZpc2UgdGhlIHNlbmRlciANCmJ5IHJldHVybiBlbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGZyb20geW91ciBzeXN0ZW0uIA0KQWx0aG91Z2ggdGhpcyBlbWFpbCBoYXMgYmVlbiBjaGVj a2VkIGZvciB2aXJ1c2VzIGFuZCBvdGhlciBkZWZlY3RzLCBubyByZXNwb25zaWJpbGl0eSANCmNh biBiZSBhY2NlcHRlZCBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSBpdHMgcmVj ZWlwdCBvciB1c2UuDQpSYWNpbmcgVmljdG9yaWEgTGltaXRlZCByZXNwZWN0cyB5b3VyIHByaXZh Y3kuIE91ciBwcml2YWN5IHBvbGljeSBjYW4gYmUgYWNjZXNzZWQgDQpmcm9tIG91ciB3ZWIgc2l0 ZTogImh0dHA6Ly93d3cucmFjaW5ndmljdG9yaWEubmV0LmF1Ig0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== From SRS0=FTZHd=GD==stuart@gathman.org Thu Aug 2 17:55: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 AB71821F8BF2 for ; Thu, 2 Aug 2012 17:55:33 -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 LI7kjE66M16O for ; Thu, 2 Aug 2012 17:55:33 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1633C21F8BF1 for ; Thu, 2 Aug 2012 17:55:32 -0700 (PDT) Authentication-Results: mail.bmsi.com; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q730tSVI001227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 20:55:29 -0400 Message-ID: <501B2180.9090304@gathman.org> Date: Thu, 02 Aug 2012 20:55:28 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5015F1A7.50000@gathman.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 00:57:40 -0000 Long ago, Nostradamus foresaw that on 07/30/2012 05:36 PM, Derek Diget would write: > =>The SPF specification *mandates* a result of PERMERROR (not fail or > =>softfail) for parsing failures. It already recommends treating > =>PermError like neutral. > > Can you point me in the direction where RFC4408 says that? I don't see > it in section 2.5.7 nor anywhere else in the doc. 4.6. Record Evaluation After one SPF record has been selected, the check_host() function parses and interprets it to find a result for the current test. If there are any syntax errors, check_host() returns immediately with the result "PermError". Implementations MAY choose to parse the entire record first and return "PermError" if the record is not syntactically well formed. However, in all cases, any syntax errors anywhere in the record MUST be detected. ----------- However, I don't find a local policy recommendation either - I must have been remembering the many discussions. Which is just as well, because PermError should get rejected with a 5xx and a diagnostic for the syntax error. That's what happens when a mail admin makes other boneheaded mistakes that are easy to fix and easy to prevent (run a record checker). From W.Doust@racingvictoria.net.au Thu Aug 2 22:43:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0F711E80D5 for ; Thu, 2 Aug 2012 22:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vumDe+sRilJj for ; Thu, 2 Aug 2012 22:43:14 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7A811E80B8 for ; Thu, 2 Aug 2012 22:43:08 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 0) id ; Fri, 03 Aug 2012 15:43:06 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Aug 2012 15:41:03 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> In-Reply-To: <501B2180.9090304@gathman.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1xEv/JcbSU+Q8bQPm55SUhJejkMwAJNW8A References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><5015F1A7.50000@gathman.org> <501B2180.9090304@gathman.org> From: "Wayne Doust" To: "Stuart Gathman" , Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 05:43:15 -0000 I think Derek was referring to the second part of what you mentioned, not the first part (I have deleted the first part for clarity) -----Original Message----- >> =3D> It already recommends treating=20 >> =3D>PermError like neutral. >> >> Can you point me in the direction where RFC4408 says that? I don't=20 >> see it in section 2.5.7 nor anywhere else in the doc. ----------- However, I don't find a local policy recommendation either - I must have been remembering the many discussions. Which is just as well, because PermError should get rejected with a 5xx and a diagnostic for the syntax error. That's what happens when a mail admin makes other boneheaded mistakes that are easy to fix and easy to prevent (run a record checker). ----------- I disagree. There are a number of reasons a PermError can be generated. Rejecting because of PermError simply punishes a domain for publishing an SPF record. It should be treated no worse than None - and the spec should indicate that just as it does for Neutral, and for precisely the same reasons. At worst, a 4xx can be issued with a detailed reason why. There are a HUGE number of syntactically incorrect SPF records out there. This week alone I've advised five hosting services that their SPF records are incorrect and will not work. Most of them are simple typos, others betray a fundamental misunderstanding of how SPF works. Of course, there's nothing stopping you (an informed email sysadmin that checks their logs) from doing so. What I'm saying is this is the best "default" case for the (unfortunately) vast majority of sysadmins that have just heard about SPF or has just ticked a box that says "spf". Putting it another way, what should the Out-of-the-box behaviour for M$ Exchange 50 user small business edition be as administered by the office accountant after doing a 5 day course on system administration? =20 *************************************************************************= ******************************* Disclaimer: This email message and any attachments are confidential. =20 The information contained in this email message and any attachments may b= e=20 confidential information. If you are not the intended recipient, any use,= =20interference with,=20 disclosure or copying of this material is unauthorised and prohibited. This email and any attachments are also subject to copyright. =20 No part of them may be reproduced, adapted or transmitted without the wri= tten permission of the copyright owner. If you have received this email in error please immediately advise the se= nder=20 by return email and delete the message from your system.=20 Although this email has been checked for viruses and other defects, no re= sponsibility=20 can be accepted for any loss or damage arising from its receipt or use. Racing Victoria Limited respects your privacy. Our privacy policy can be = accessed=20 from our web site: "http://www.racingvictoria.net.au" *************************************************************************= ******************************* From superuser@gmail.com Thu Aug 2 23:10: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 F26A011E809B for ; Thu, 2 Aug 2012 23:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 5qf46a4N7EWc for ; Thu, 2 Aug 2012 23:10:12 -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 82C8911E809A for ; Thu, 2 Aug 2012 23:10:11 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1494888lbb.31 for ; Thu, 02 Aug 2012 23:10: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=HxuVM8DlCaj2eF/yEmBmF+X6nsOAyrOOxXOn5mdxlCE=; b=f/QycwxqsFG0QOpTci6VUn7TpAlnUUXyVGjCoijfSUBfh7CFnTjXx6/yg/s+tQOQ7e E594xF5XXjkFlcSh0MCT/j93AgnQhltCkQx385l9zw3LfsRrC5SaokQoUhfCJ9dbdw1r wlsBFcTWnMFxncYAd8LHc/htrX/9+oENjuZRaJMi81omN/PrRDx6CYvm1FuYOjJsaWf0 I+4sp/v2/9Qlck+K1BB7+IslnlBfwvoyDclDwQGOdrxuKHmla4aWT+i6KPEA+yB0YXvU VR8R8lvMTWlfsEcWZ8c+1ndq+mhVk45DSBkxSPjLETI9SlQublnKUPbWoY538UAd/rBK bDBw== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr578538lab.5.1343974210456; Thu, 02 Aug 2012 23:10:10 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 2 Aug 2012 23:10:10 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5015F1A7.50000@gathman.org> <501B2180.9090304@gathman.org> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> Date: Thu, 2 Aug 2012 23:10:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: multipart/alternative; boundary=f46d04083de766cbe704c65661c5 Cc: spfbis@ietf.org, Stuart Gathman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 06:10:14 -0000 --f46d04083de766cbe704c65661c5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 10:41 PM, Wayne Doust wrote: > I disagree. There are a number of reasons a PermError can be generated. > Rejecting because of PermError simply punishes a domain for publishing > an SPF record. It should be treated no worse than None - and the spec > should indicate that just as it does for Neutral, and for precisely the same reasons. > I can't see how your proposed solution does anything other than reduce to a statement such as: "SPF attempts to establish a strong email policy layer, but you should never actually enforce it because there could be a bug." > > At worst, a 4xx can be issued with a detailed reason why. There are a > HUGE number of syntactically incorrect SPF records out there. This week > alone I've advised five hosting services that their SPF records are > incorrect and will not work. Most of them are simple typos, others > betray a fundamental misunderstanding of how SPF works. > Speaking practically, temp-fails are effectively delayed perm-fails. Nobody looks in the queues for things that are temp-failing and attempts to debug them before a final bounce occurs. Or, at a minimum, that case is exceedingly rare. > > Of course, there's nothing stopping you (an informed email sysadmin that > checks their logs) from doing so. What I'm saying is this is the best > "default" case for the (unfortunately) vast majority of sysadmins that > have just heard about SPF or has just ticked a box that says "spf". > We've been very careful in all protocol documents lately (ADSP, DKIM, SPF, and greylisting all come to mind) to talk only about what one could do with the results of those various systems, and not prescribing specific actions. That is, enable informed decisions, but don't prescribe specific actions. To that end, I'd be fine using soft language to suggest possible courses of action, but I'm not sold on the idea that requiring PermError to be the same as None is the right thing to do. > Putting it another way, what should the Out-of-the-box behaviour for M$ > Exchange 50 user small business edition be as administered by the office > accountant after doing a 5 day course on system administration? > What's the likelihood that the office accountant with a 5-day course on system administration will read the document we're about to produce? Aren't implementers the real targets here? > > > ******************************************************************************************************** > Disclaimer: This email message and any attachments are confidential. > The information contained in this email message and any attachments may be > confidential information. If you are not the intended recipient, any use, > interference with, > disclosure or copying of this material is unauthorised and prohibited. > This email and any attachments are also subject to copyright. > No part of them may be reproduced, adapted or transmitted without the > written > permission of the copyright owner. > If you have received this email in error please immediately advise the > sender > by return email and delete the message from your system. > Although this email has been checked for viruses and other defects, no > responsibility > can be accepted for any loss or damage arising from its receipt or use. > Racing Victoria Limited respects your privacy. Our privacy policy can be > accessed > from our web site: "http://www.racingvictoria.net.au" > > ******************************************************************************************************** > As was already pointed out by one of the co-chairs, this disclaimer contradicts IETF IPR rules, and it means we can't use your contributions as part of our work. You probably should stop sending it. It's also obnoxiously large, and you could get warlorded. :-) -MSK --f46d04083de766cbe704c65661c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 2, 2012 at 10:41 PM, Wayne Doust <W.Doust@racingv= ictoria.net.au> wrote:
I disagree. There are a number of reasons a PermError can be generated.
Rejecting because of PermError simply punishes a domain for publishing
an SPF record. It should be treated no worse than None - and the spec
should indicate that just as it does for Neutral, and for precisely the=A0<= /blockquote>
same reasons.

I can't see how your proposed solution does anything other than red= uce to a statement such as: "SPF attempts to establish a strong email = policy layer, but you should never actually enforce it because there could = be a bug."
=A0

At worst, a 4xx can be issued with a detailed reason why. There are a
HUGE number of syntactically incorrect SPF records out there. This week
alone I've advised five hosting services that their SPF records are
incorrect and will not work. Most of them are simple typos, others
betray a fundamental misunderstanding of how SPF works.

Speaking practically, temp-fails are effectively delayed perm-fails.= =A0 Nobody looks in the queues for things that are temp-failing and attempt= s to debug them before a final bounce occurs.=A0 Or, at a minimum, that cas= e is exceedingly rare.
=A0

Of course, there's nothing stopping you (an informed email sysadmin tha= t
checks their logs) from doing so. What I'm saying is this is the best "default" case for the (unfortunately) vast majority of sysadmins= that
have just heard about SPF or has just ticked a box that says "spf"= ;.

We've been very careful in all protocol doc= uments lately (ADSP, DKIM, SPF, and greylisting all come to mind) to talk o= nly about what one could do with the results of those various systems, and = not prescribing specific actions. That is, enable informed decisions, but d= on't prescribe specific actions.=A0 To that end, I'd be fine using = soft language to suggest possible courses of action, but I'm not sold o= n the idea that requiring PermError to be the same as None is the right thi= ng to do.


Putting it another way, what should the Out-of-the-box behaviour for M$
Exchange 50 user small business edition be as administered by the office accountant after doing a 5 day course on system administration?

What's the likelihood that the office accountant with a 5= -day course on system administration will read the document we're about= to produce?=A0 Aren't implementers the real targets here?
=A0

***************************************************************************= *****************************
Disclaimer: This email message and any attachments are confidential.
The information contained in this email message and any attachments may be<= br> confidential information. If you are not the intended recipient, any use, i= nterference with,
disclosure or copying of this material is unauthorised and prohibited.
This email and any attachments are also subject to copyright.
No part of them may be reproduced, adapted or transmitted without the writt= en
permission of the copyright owner.
If you have received this email in error please immediately advise the send= er
by return email and delete the message from your system.
Although this email has been checked for viruses and other defects, no resp= onsibility
can be accepted for any loss or damage arising from its receipt or use.
Racing Victoria Limited respects your privacy. Our privacy policy can be ac= cessed
from our web site: "http://www.racingvictoria.net.au"
***************************************************************************= *****************************

As was already= pointed out by one of the co-chairs, this disclaimer contradicts IETF IPR = rules, and it means we can't use your contributions as part of our work= .=A0 You probably should stop sending it.

It's also obnoxiously large, and you could get warlorded.=A0 :-)
-MSK

--f46d04083de766cbe704c65661c5-- From W.Doust@racingvictoria.net.au Thu Aug 2 23:55: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 70DE511E809C for ; Thu, 2 Aug 2012 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=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 dDl56i3BlFjU for ; Thu, 2 Aug 2012 23:55:21 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8B21E8034 for ; Thu, 2 Aug 2012 23:55:20 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 0) id ; Fri, 03 Aug 2012 16:55:19 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD7144.7128F64C" Date: Fri, 3 Aug 2012 16:51:37 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] SPF parsing failure should default to SPF NEUTRAL Thread-Index: Ac1xPqur2GzydRqhTqiNgqSggEbsZgAAkKew References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal><5015F1A7.50000@gathman.org><501B2180.9090304@gathman.org><0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> From: "Wayne Doust" To: "Murray S. Kucherawy" Cc: spfbis@ietf.org, Stuart Gathman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 06:55:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD7144.7128F64C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 On Thu, Aug 2, 2012 at 10:41 PM, Wayne Doust wrote: I disagree. There are a number of reasons a PermError can be generated. Rejecting because of PermError simply punishes a domain for publishing an SPF record. It should be treated no worse than None - and the spec should indicate that just as it does for Neutral, and for precisely the=20 same reasons. I can't see how your proposed solution does anything other than reduce to a statement such as: "SPF attempts to establish a strong email policy layer, but you should never actually enforce it because there could be a bug." =20 I don't see that as being equivalent. Consider the possible scenarios: =20 1) (Most likely) Faulty syntax in the SPF record: The publisher should know better, but doesn't. So treat them like they haven't published it all. 2) Incorrect parsing: Less likely, but it DOES happen. =20 In either case, a PermError tells us precisely nothing about the SPF record. So why treat it as anything other than None? We aren't refusing to enforce a policy because we don't know what that policy is. =20 The very name "PermError" can (and does) lead implementers to lump PermError in with Fail. Of course there's nothing stopping someone from consciously doing it, but should that be the default action? =20 =20 =09 At worst, a 4xx can be issued with a detailed reason why. There are a HUGE number of syntactically incorrect SPF records out there. This week alone I've advised five hosting services that their SPF records are incorrect and will not work. Most of them are simple typos, others betray a fundamental misunderstanding of how SPF works. Speaking practically, temp-fails are effectively delayed perm-fails. Nobody looks in the queues for things that are temp-failing and attempts to debug them before a final bounce occurs. Or, at a minimum, that case is exceedingly rare. =20 This is OT: But I temp-fail on SPF Fail with the reason why and a phone number to ring. This gives the sender a chance to call us and have them placed in our white-list. I also auto white-list all outgoing email addresses. The users know that if someone can't email them, then sending the SENDER an email usually "fixes" that. =20 As the adoption of SPF moves forward, I will probably start using an initial temp-fail on SPF SoftFail. We've been very careful in all protocol documents lately (ADSP, DKIM, SPF, and greylisting all come to mind) to talk only about what one could do with the results of those various systems, and not prescribing specific actions. That is, enable informed decisions, but don't prescribe specific actions. To that end, I'd be fine using soft language to suggest possible courses of action, but I'm not sold on the idea that requiring PermError to be the same as None is the right thing to do. No, I'm not saying it should be proscribed either. I'm saying the possibilities should be mentioned, and I do understand the NEUTRAL is a special case. =09 Putting it another way, what should the Out-of-the-box behaviour for M$ Exchange 50 user small business edition be as administered by the office accountant after doing a 5 day course on system administration? What's the likelihood that the office accountant with a 5-day course on system administration will read the document we're about to produce? Aren't implementers the real targets here? =20 Yes they are. The implementers being those who make email filtering software and appliances. In the absence of any defaults in the spec, they will make them up. The "office account" will simply tick a box and be done with it. When someone complains that their email is being blocked because of SPF and says "everyone else can receive my email except YOU guys..", he will simply uncheck that box and do no SPF checking at all. As was already pointed out by one of the co-chairs, this disclaimer contradicts IETF IPR rules, and it means we can't use your contributions as part of our work. You probably should stop sending it. It's also obnoxiously large, and you could get warlorded. :-) Point taken. J ------_=_NextPart_001_01CD7144.7128F64C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

On Thu, Aug = 2, 2012 at 10:41 PM, Wayne Doust <W.Doust@racingvictoria.net.au> = wrote:

I = disagree. There are a number of reasons a PermError can be = generated.
Rejecting because of PermError simply punishes a domain = for publishing
an SPF record. It should be treated no worse than None = - and the spec
should indicate that just as it does for Neutral, and = for precisely the 

same = reasons.


I can't see how your proposed = solution does anything other than reduce to a statement such as: = "SPF attempts to establish a strong email policy layer, but you = should never actually enforce it because there could be a = bug."

 

I don’t see that as being equivalent. Consider the possible = scenarios:

 

1)      = (Most likely) Faulty syntax in the SPF record: The publisher should = know better, but doesn’t. So treat them like they haven’t = published it all.

2)      = Incorrect parsing: Less likely, but it DOES = happen.

 

In either case, a PermError tells us precisely nothing about the SPF = record. So why treat it as anything other than None? We aren’t = refusing to enforce a policy because we don’t know what that = policy is.

 

The very name “PermError” can (and does) lead = implementers to lump PermError in with Fail. Of course there’s = nothing stopping someone from consciously doing it, but should that be = the default action?

 

 


At = worst, a 4xx can be issued with a detailed reason why. There are = a
HUGE number of syntactically incorrect SPF records out there. This = week
alone I've advised five hosting services that their SPF records = are
incorrect and will not work. Most of them are simple typos, = others
betray a fundamental misunderstanding of how SPF = works.


Speaking = practically, temp-fails are effectively delayed perm-fails.  Nobody = looks in the queues for things that are temp-failing and attempts to = debug them before a final bounce occurs.  Or, at a minimum, that = case is exceedingly rare.

 

This is OT: But I temp-fail on SPF Fail with the reason why and a = phone number to ring. This gives the sender a chance to call us and have = them placed in our white-list. I also auto white-list all outgoing email = addresses. The users know that if someone can’t email them, then = sending the SENDER an email usually “fixes” = that.

 

As the adoption of SPF moves forward, I will probably start using an = initial temp-fail on SPF SoftFail.


We've been very = careful in all protocol documents lately (ADSP, DKIM, SPF, and = greylisting all come to mind) to talk only about what one could do with = the results of those various systems, and not prescribing specific = actions. That is, enable informed decisions, but don't prescribe = specific actions.  To that end, I'd be fine using soft language to = suggest possible courses of action, but I'm not sold on the idea that = requiring PermError to be the same as None is the right thing to = do.

No, I’m not saying it should be proscribed either. I’m = saying the possibilities should be mentioned, and I do understand the = NEUTRAL is a special case.


Putting it another way, what should the = Out-of-the-box behaviour for M$
Exchange 50 user small business = edition be as administered by the office
accountant after doing a 5 = day course on system administration?


What's the likelihood that the office accountant = with a 5-day course on system administration will read the document = we're about to produce?  Aren't implementers the real targets = here?
 

Yes they = are. The implementers being those who make email filtering software and = appliances. In the absence of any defaults in the spec, they will make = them up. The “office account” will simply tick a box and be = done with it. When someone complains that their email is being blocked = because of SPF and says “everyone else can receive my email except = YOU guys..”, he will simply uncheck that box and do no SPF = checking at all.

As was already pointed out by one of the = co-chairs, this disclaimer contradicts IETF IPR rules, and it means we = can't use your contributions as part of our work.  You probably = should stop sending it.

It's also obnoxiously large, and you = could get warlorded.  :-)

Point taken. J

------_=_NextPart_001_01CD7144.7128F64C-- From superuser@gmail.com Fri Aug 3 08:00:54 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 9FC2221F8DCC for ; Fri, 3 Aug 2012 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 mykQ7KnTAwtN for ; Fri, 3 Aug 2012 08:00:53 -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 573CC21F8DBD for ; Fri, 3 Aug 2012 08:00:53 -0700 (PDT) Received: by lahm15 with SMTP id m15so454001lah.31 for ; Fri, 03 Aug 2012 08:00:52 -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=oVEVvrrjjrdjLOYbewawYCis7pPQEkPhJfEJLxTbKBs=; b=uLwS0soN+VLEi7fnLHcwYsuRLUFPXJkHxAwSoHfg6IuvZEOZPvZrVmBttGyL8vE9AP ax4z/HWMRPSP34jG3Z8J1mIoUh1ZSCEBMajL2kqfB6mpLjMqOaD+YUi0BvlvRtUn0Ks5 KfbiXvc1FG/1bQ0B1sgb6tX1H+7AAWN4U747pcsF9w8STLszCLCz0WpXifbzhiLhzAf7 uC6tTLOkQ2ZViB0QJbyCjVXVu0OOoeQrXBVfltV8BSLtlnE6dFxkJBgDN9CQUeLvumfq TZYaAiixf7GlmrqEZbkgyWSDOCo4fcmIM2pN/4lnJ4+g+B1MyN/FUpGoFfgbTDdOVEM0 XCBw== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr769780lbk.78.1344006052233; Fri, 03 Aug 2012 08:00:52 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 3 Aug 2012 08:00:52 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <5015F1A7.50000@gathman.org> <501B2180.9090304@gathman.org> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3CFD@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> Date: Fri, 3 Aug 2012 08:00:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: multipart/alternative; boundary=485b390f7a7651c0a404c65dcbff Cc: spfbis@ietf.org, Stuart Gathman Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 15:00:54 -0000 --485b390f7a7651c0a404c65dcbff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 2, 2012 at 11:51 PM, Wayne Doust wrote: > > I can't see how your proposed solution does anything other than reduce to > a statement such as: "SPF attempts to establish a strong email policy > layer, but you should never actually enforce it because there could be a > bug." > > ** ** > > I don=92t see that as being equivalent. Consider the possible scenarios:*= *** > > ** ** > > **1) **(Most likely) Faulty syntax in the SPF record: The publisher > should know better, but doesn=92t. So treat them like they haven=92t publ= ished > it all.**** > > **2) **Incorrect parsing: Less likely, but it DOES happen.**** > > ** ** > > In either case, a PermError tells us precisely nothing about the SPF > record. So why treat it as anything other than None? We aren=92t refusing= to > enforce a policy because we don=92t know what that policy is. > I think in the case where everything's working, PermError indicates, quite emphatically, that the SPF record could not be used to make a positive determination about the message's path authorization. That's far from "precisely nothing". In the case of a parsing bug, it indicates the presence of a problem somewhere, but is ambiguous about where. That's also not "precisely nothing", but it is certainly a less direct indication. Anyway, I believe the issue you're having is that "PermError" rejection is only able to send its message in one direction, namely back to the sender. If the receiver has a bug (less likely, as you said), it's never actively notified of this; one would have to check logs to observe that there's a problem. > **** > > ** ** > > The very name =93PermError=94 can (and does) lead implementers to lump > PermError in with Fail. Of course there=92s nothing stopping someone from > consciously doing it, but should that be the default action? > I don't think that's the logic implementers are applying. It's rather the desire to be as protective of the receiver as possible, essentially a choice between a "default deny" posture and a "default allow" posture. In some sense that's a product decision and not something the document can or should specify. **** > > > We've been very careful in all protocol documents lately (ADSP, DKIM, SPF= , > and greylisting all come to mind) to talk only about what one could do wi= th > the results of those various systems, and not prescribing specific action= s. > That is, enable informed decisions, but don't prescribe specific actions. > To that end, I'd be fine using soft language to suggest possible courses = of > action, but I'm not sold on the idea that requiring PermError to be the > same as None is the right thing to do. > > No, I=92m not saying it should be proscribed either. I=92m saying the > possibilities should be mentioned, and I do understand the NEUTRAL is a > special case. > I think discussion is fine, but I don't think we should go further than that. With that in mind: Scott, do you have usable text from upthread someplace to consider, or would you like some? -MSK --485b390f7a7651c0a404c65dcbff Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 2, 2012 at 11:51 PM, Wayne Doust <W.Doust@racingv= ictoria.net.au> wrote:
<= p class=3D"MsoNormal" style=3D"border:none;padding:0cm">
I can't see= how your proposed solution does anything other than reduce to a statement = such as: "SPF attempts to establish a strong email policy layer, but y= ou should never actually enforce it because there could be a bug."

=A0

I don=92t see that = as being equivalent. Consider the possible scenarios:<= /p>

=A0<= /p>

1)=A0=A0=A0=A0=A0 (Most likely) Faulty syntax in the SPF record: The = publisher should know better, but doesn=92t. So treat them like they haven= =92t published it all.

2)=A0=A0=A0=A0=A0 Incorrect parsing: Less likely, but it DOES happen.=

=A0<= /p>

In either case, a Perm= Error tells us precisely nothing about the SPF record. So why treat it as a= nything other than None? We aren=92t refusing to enforce a policy because w= e don=92t know what that policy is.


I think in the case where eve= rything's working, PermError indicates, quite emphatically, that the SP= F record could not be used to make a positive determination about the messa= ge's path authorization.=A0 That's far from "precisely nothing= ".

In the case of a parsing bug, it indicates the presence of a problem so= mewhere, but is ambiguous about where.=A0 That's also not "precise= ly nothing", but it is certainly a less direct indication.

Anyw= ay, I believe the issue you're having is that "PermError" rej= ection is only able to send its message in one direction, namely back to th= e sender.=A0 If the receiver has a bug (less likely, as you said), it's= never actively notified of this; one would have to check logs to observe t= hat there's a problem.
=A0

=A0<= /p>

The very name =93PermE= rror=94 can (and does) lead implementers to lump PermError in with Fail. Of= course there=92s nothing stopping someone from consciously doing it, but s= hould that be the default action?=A0


I don't think that= 9;s the logic implementers are applying.=A0 It's rather the desire to b= e as protective of the receiver as possible, essentially a choice between a= "default deny" posture and a "default allow" posture.= =A0 In some sense that's a product decision and not something the docum= ent can or should specify.


We've been very careful in all protocol documents lately (ADSP, DKIM, S= PF, and greylisting all come to mind) to talk only about what one could do = with the results of those various systems, and not prescribing specific act= ions. That is, enable informed decisions, but don't prescribe specific = actions.=A0 To that end, I'd be fine using soft language to suggest pos= sible courses of action, but I'm not sold on the idea that requiring Pe= rmError to be the same as None is the right thing to do.

No, I=92m not saying it should be proscribed either.= I=92m saying the possibilities should be mentioned, and I do understand th= e NEUTRAL is a special case.

I think discussion is fine, but I= don't think we should go further than that.

With that in mind: = Scott, do you have usable text from upthread someplace to consider, or woul= d you like some?

-MSK
--485b390f7a7651c0a404c65dcbff-- From spf2@kitterman.com Fri Aug 3 08:14: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 78E0C21F8DD2 for ; Fri, 3 Aug 2012 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO4izaMtw4HQ for ; Fri, 3 Aug 2012 08:14:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0EC21F8D9F for ; Fri, 3 Aug 2012 08:14:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9B5BF20E40D7; Fri, 3 Aug 2012 11:14:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1344006888; bh=QiH7CWRekW3InnD6sxOFIGoU3qi17RgDP2JksncDwSw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DhHN6wkhhR1OYxle+aQVkDuRKaKvc89TSN/QzFSB7ziJzShV29HmguoFBzohW9cRp PZOrlodVG/oTxm5FB9UNeJThwgE9O6yQGb94tQw/jYZ8K4snvvvkyF0wrd4cC9zdBD auSvgceC0BCp0LFWrIFO+Qznrf8jTVb9ClCk+feg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6EE8120E4064; Fri, 3 Aug 2012 11:14:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 03 Aug 2012 11:14:47 -0400 Message-ID: <11791967.6QHX6d2z1B@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Aug 2012 15:14:50 -0000 On Friday, August 03, 2012 08:00:52 AM Murray S. Kucherawy wrote: > > The very name =E2=80=9CPermError=E2=80=9D can (and does) lead imple= menters to lump > > PermError in with Fail. Of course there=E2=80=99s nothing stopping = someone from > > consciously doing it, but should that be the default action? >=20 > I don't think that's the logic implementers are applying. It's rathe= r the > desire to be as protective of the receiver as possible, essentially a= > choice between a "default deny" posture and a "default allow" posture= . In > some sense that's a product decision and not something the document c= an or > should specify. In applications I've developed these are separate knobs that can be tur= ned=20 independently, so I concur with your assessment. In my case I've tende= d to=20 use a default deny approach, but it's easy enough to adjust. Scott K From superuser@gmail.com Sat Aug 4 22:37: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 D45C811E8087 for ; Sat, 4 Aug 2012 22:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 k+bvOnQ+ff14 for ; Sat, 4 Aug 2012 22:37:10 -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 9620521F8569 for ; Sat, 4 Aug 2012 22:37:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so1073353lah.31 for ; Sat, 04 Aug 2012 22:37:08 -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=QvtoKnwBUb0YBslxcoiGrnCane30Rn/KhgnPa6P+4w4=; b=x5O6WnRUSikeb8k4RwkaRxfPKvixQsnhFoFBZZFjujj9uwt9GPIIz2Y0fjzgU0kYbz JPlQUIK+bnz902YbqHNje38DjNgvW8LSfPjhFCppGbC/zmsY1+FEMz/+Svydd4ocfC5+ Qbw0ww6/9Gh/G7/TovfGZym3pCn6mgIwGIl7Oqg3YgvRQ54oeGLIn/WRxAEjbsmk8HUj FxcoAo4khec/vZV1s36hPNlcZEpeNkFl4EFkIEBsZKm7P4UmFIS4PwUeJPnRw4uBNZHR GNPoWyw8fXWkZDdLUpAsCA2NzdDOhrcHT53V+7Y/4NQHAvJV9Js1o0AqEQNP0lgcT+GT pfXg== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr2804410lbz.92.1344145028286; Sat, 04 Aug 2012 22:37:08 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 4 Aug 2012 22:37:08 -0700 (PDT) In-Reply-To: <11791967.6QHX6d2z1B@scott-latitude-e6320> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF010279AC@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D3D13@XCHANGE.rvl.internal> <11791967.6QHX6d2z1B@scott-latitude-e6320> Date: Sat, 4 Aug 2012 22:37:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04016cadf008d404c67e26cb Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF parsing failure should default to SPF NEUTRAL X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Aug 2012 05:37:11 -0000 --f46d04016cadf008d404c67e26cb Content-Type: text/plain; charset=ISO-8859-1 As a suggested resolution to this thread, I propose this for a new subsection of Section 9: 9.x. Handling Of "permerror" Results The "permerror" result (see Section 2.5.y) indicates the SPF processing module at the receiver determined that the received SPF policy record could not be interpreted. This gives no true indication about the authorized use of the data found in the envelope. As with all results, implementers have a choice to make regarding what to do with a message that yields this result. SMTP allows only a few basic options. Rejection of the message is an option, in that it is the one thing a receiver can do to draw attention to the difficulty encountered while protecting itself from messages that do not have a definite SPF result of some kind. However, if the SPF implementation is defective and returns spurious "permerror" results, only the sender is actively notified of the defect (in the form of rejected mail), and not the receiver making use of SPF. The less intrusive handling choice is to deliver the message, perhaps with some kind of annotation of the difficulty encountered and/or logging of a similar nature. However, this will not be desirable to operators that wish to implement SPF checking as strictly as possible, nor is this sort of passive problem reporting typically effective. There is of course the option placing this choice in the hands of the operator rather than the implementer, but this adds one more piece of complexity to an already non-trivial environment. Both implementers and operators need to be cautious of all choices and outcomes when handling SPF results. -MSK --f46d04016cadf008d404c67e26cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a suggested resolution to this thread, I propose this for a new subsecti= on of Section 9:

9.x. Handling Of "permerror" Results
<= br>The "permerror" result (see Section 2.5.y) indicates the SPF p= rocessing module at the receiver determined that the received SPF policy re= cord could not be interpreted.=A0 This gives no true indication about the a= uthorized use of the data found in the envelope.

As with all results, implementers have a choice to make regarding what = to do with a message that yields this result.=A0 SMTP allows only a few bas= ic options.

Rejection of the message is an option, in that it is the= one thing a receiver can do to draw attention to the difficulty encountere= d while protecting itself from messages that do not have a definite SPF res= ult of some kind.=A0 However, if the SPF implementation is defective and re= turns spurious "permerror" results, only the sender is actively n= otified of the defect (in the form of rejected mail), and not the receiver = making use of SPF.

The less intrusive handling choice is to deliver the message, perhaps w= ith some kind of annotation of the difficulty encountered and/or logging of= a similar nature.=A0 However, this will not be desirable to operators that= wish to implement SPF checking as strictly as possible, nor is this sort o= f passive problem reporting typically effective.

There is of course the option placing this choice in the hands of the o= perator rather than the implementer, but this adds one more piece of comple= xity to an already non-trivial environment.

Both implementers and op= erators need to be cautious of all choices and outcomes when handling SPF r= esults.

-MSK
--f46d04016cadf008d404c67e26cb-- From hsantos@isdg.net Tue Aug 7 14:12: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 4D85F11E80A6 for ; Tue, 7 Aug 2012 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 f1misR66I9OP for ; Tue, 7 Aug 2012 14:12:08 -0700 (PDT) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4651821F8608 for ; Tue, 7 Aug 2012 14:12:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3276; t=1344373917; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9cbocsA710YgOEKGC/NFBQbjqoI=; b=HgGjxzhV+lU2VoxSaJgy 5weJhKCJL9hlE2a3FMnDqOVKYtIaEml7NzHdO5b0E+GxbBNmFottI71zfwgz4uxh g5B5uCAeHBDjMX98vfndQs88Wn9CyETGLTpTbC0bfpornU0YezMG1fpDkBWqZjSx +/kIhoKO+0NG2l7BIvyBS0k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 07 Aug 2012 17:11:57 -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 395730023.13997.5952; Tue, 07 Aug 2012 17:11:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3276; t=1344373752; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=28/BiTb 5oosnRKC5RtAVfyAHASlg6wUdAnDwUgISe84=; b=J3sFhaInEP/tZdociO2Oc1I 0uyxJkggZ2Qsj+KHd+v/2jUSmlIAg8F4PEp5PcLi8B7Bfpivr+oxVRnMf9oGgLbl plcIua61C2Vu+puc1Xzt+zyoFr5Eqj98yCBIZRhhOUMW0gJb4Rx+mzx2UNa+GksN q/HGrIhwCHpME0dBIWp4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 07 Aug 2012 17:09:12 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 994550286.9.1396; Tue, 07 Aug 2012 17:09:11 -0400 Message-ID: <50218491.2080807@isdg.net> Date: Tue, 07 Aug 2012 17:11:45 -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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Dealing with Multiple Transactions X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Aug 2012 21:12:09 -0000 Scott et al, While it might be implicit, maybe some text is warranted that points out the ideas of dealing with multiple transactions. A past discussion in IETF-SMTP considered how/what state information is kept and cleared per transaction vs per SMTP session. This began when I pointed out a loophole is possible if a transaction is rejected but the client can try a different transaction and bypass the rejection. In this case, the real example provided was with greylisted transactions where the client did not QUIT (or drop), waited X minutes or seconds enough to get around the greylisted block tracking time. For our software, we now have an option (default ON) to track a GREYLISTED rejected transaction permanently for the entire SMTP session. Once rejected, new transactions are disabled. Reviewing a session in our logs this morning, I was reminded of this possibility for SPF as well with an facebookmail.com session. C: EHLO facebookmail.com S: 250-winserver.com, Pleased to meet you. S: 250-SIZE 10240000 S: 250-8BITMIME S: 250-SUBMITTER S: 250-ETRN S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 S: 250-AUTH=LOGIN S: 250-HELP S: 250 STARTTLS C: MAIL FROM: BODY=7BIT S: 250 ... Sender validation pending. Continue. C: RCPT TO:<############@santronics.com> ** WCX Process: wcsap ret: 550 (156 msecs) (Rejected by WCSAP SPF Fail) S: 550 Return Path not verifiable. Our software does the Sender verification suite of testing after a valid RCPT TO is issued. The testing includes SPF and it failed here with a non-valid IP SPF address for facebookmail.com. C: RSET S: 250 Reset State #1 C: MAIL FROM: BODY=7BIT S: 250 ... Sender validation pending. Continue. C: RCPT TO: ** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP SPF Fail) S: 550 Return Path not verifiable. Here, the sender tried a new transaction in the same session. Again failed with SPF. C: RSET S: 250 Reset State #2 C: MAIL FROM: BODY=7BIT S: 250 ... Sender validation pending. Continue. ** connection drop - error: 10053 state: tMail lastcmd: MAIL ** Completed. Elapsed Time: 55599 msecs Finally, it tried a third time, but did not issue a RCPT TO to trigger the SPF check and it failled dropped after a near minute. Side indirect point: That could be our 1 minute since we do have logic to minimize the session/CPU waste time with clients holding channels for extended minutes (3-5). In our case, it starts with an initial SMTP wait of 5 minutes, but after a 2nd transaction is attempted the timeout drops to 1 min. Anyway, I am not show what ample text may be appropriate for 4408BIS, if any, but an improved optimized logic and simple text could be: For SPF results that would not change in subsequence same session, multiple transactions, the receiver MAY use the same results without calling the check_host() function. [This can help minimize DNS calls and also close possible security loopholes.] The above is just starter text for any consideration. -- HLS From spf2@kitterman.com Tue Aug 7 14:51: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 97DBA11E80A4 for ; Tue, 7 Aug 2012 14:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgwMvnanw0ZM for ; Tue, 7 Aug 2012 14:51:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B25CC11E809B for ; Tue, 7 Aug 2012 14:51:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B3BDB20E40D0; Tue, 7 Aug 2012 17:51:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1344376270; bh=Brwws0ID+F9pcKdqcnXo+ZdyQTKBZAG2bSQw73AfjEI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DbkuJNG2q4/xFaXxbyhtujbJlMWHQdMHmUyxbC7LoNH55CFl3mo4GwlIv01uiVnEm CH7kfSXsr73dA+QNN98WUPSnebCKlij2GonjzucaLoxt5X0cGXxfgwIydzVbaPLnEy ZjEfP01YsQzUlxXCj1J4UWNHgFzwyviVp/pxis+U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8CF4020E4086; Tue, 7 Aug 2012 17:51:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 07 Aug 2012 17:51:09 -0400 Message-ID: <7470854.BffWFDWRcM@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-27-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50218491.2080807@isdg.net> References: <50218491.2080807@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] Dealing with Multiple Transactions X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Aug 2012 21:51:12 -0000 On Tuesday, August 07, 2012 05:11:45 PM Hector Santos wrote: > Scott et al, > > While it might be implicit, maybe some text is warranted that points > out the ideas of dealing with multiple transactions. A past > discussion in IETF-SMTP considered how/what state information is kept > and cleared per transaction vs per SMTP session. > > This began when I pointed out a loophole is possible if a transaction > is rejected but the client can try a different transaction and bypass > the rejection. In this case, the real example provided was with > greylisted transactions where the client did not QUIT (or drop), > waited X minutes or seconds enough to get around the greylisted block > tracking time. > > For our software, we now have an option (default ON) to track a > GREYLISTED rejected transaction permanently for the entire SMTP > session. Once rejected, new transactions are disabled. > > Reviewing a session in our logs this morning, I was reminded of this > possibility for SPF as well with an facebookmail.com session. > > C: EHLO facebookmail.com > S: 250-winserver.com, Pleased to meet you. > S: 250-SIZE 10240000 > S: 250-8BITMIME > S: 250-SUBMITTER > S: 250-ETRN > S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 > S: 250-AUTH=LOGIN > S: 250-HELP > S: 250 STARTTLS > C: MAIL FROM: BODY=7BIT > S: 250 ... Sender validation pending. > Continue. > C: RCPT TO:<############@santronics.com> > ** WCX Process: wcsap ret: 550 (156 msecs) (Rejected by WCSAP SPF Fail) > S: 550 Return Path not verifiable. > > Our software does the Sender verification suite of testing after a > valid RCPT TO is issued. The testing includes SPF and it failed here > with a non-valid IP SPF address for facebookmail.com. > > C: RSET > S: 250 Reset State #1 > C: MAIL FROM: BODY=7BIT > S: 250 ... Sender validation pending. > Continue. > C: RCPT TO: > ** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP SPF Fail) > S: 550 Return Path not verifiable. > > Here, the sender tried a new transaction in the same session. Again > failed with SPF. > > C: RSET > S: 250 Reset State #2 > C: MAIL FROM: BODY=7BIT > S: 250 ... Sender validation pending. > Continue. > ** connection drop - error: 10053 state: tMail lastcmd: MAIL > ** Completed. Elapsed Time: 55599 msecs > > Finally, it tried a third time, but did not issue a RCPT TO to trigger > the SPF check and it failled dropped after a near minute. Side > indirect point: That could be our 1 minute since we do have logic to > minimize the session/CPU waste time with clients holding channels for > extended minutes (3-5). In our case, it starts with an initial SMTP > wait of 5 minutes, but after a 2nd transaction is attempted the > timeout drops to 1 min. > > Anyway, I am not show what ample text may be appropriate for 4408BIS, > if any, but an improved optimized logic and simple text could be: > > For SPF results that would not change in subsequence same session, > multiple transactions, the receiver MAY use the same results without > calling the check_host() function. [This can help minimize DNS calls > and also close possible security loopholes.] > > The above is just starter text for any consideration. How is that different than caching the SPF result, which is already OK? Scott K From hsantos@isdg.net Wed Aug 8 00:23: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 143FC11E80E1 for ; Wed, 8 Aug 2012 00:23:38 -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 CHm3sd+Pz944 for ; Wed, 8 Aug 2012 00:23:36 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9015E11E80D5 for ; Wed, 8 Aug 2012 00:23:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4670; t=1344410608; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VBzRXwkT7zaQns6ytR/MKSCgBWw=; b=smnDXPILWdYTuRajXwmZ KIS2/ZLf9cVzVugtNXnAcpzGSQxkjp/OajGsIccQ+Afk0Zkw4p010ZCSqGG+daPM Lx2v1JRk+9pPlWYR+FX5F+iM/mxU8ToeIu3Nbrn+fFxFLckNXz9R3j7kqWlVqwm6 ouV2EFC/iClY4f6Z13o4BkU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 08 Aug 2012 03:23:28 -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 432420475.14909.3640; Wed, 08 Aug 2012 03:23:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4670; t=1344410443; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qDUqtOa OtCvmC71ZS1WOkgxiKGHgAKtA59LAbQKN/CM=; b=efmIJqzqFbH9ScZH3DUyBIZ BxvCpCj5C+GbqZku8b549pEugijF0CAqWEmPIBvWTM4s/BPferYKjmoxLZYZjlBa wR33xXcYBFepRGibpkmSWmghSy4X3rdHu6/2IjVI+w3jZkA06L7JfgJKYvI7+O3N BmNApZ5cjxV5eD41V+NU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 08 Aug 2012 03:20:43 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1031240474.9.7740; Wed, 08 Aug 2012 03:20:41 -0400 Message-ID: <50221414.5060605@isdg.net> Date: Wed, 08 Aug 2012 03:24: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: <50218491.2080807@isdg.net> <7470854.BffWFDWRcM@scott-latitude-e6320> In-Reply-To: <7470854.BffWFDWRcM@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Dealing with Multiple Transactions X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 08 Aug 2012 07:23:38 -0000 The common factor in all (same session) transactions is a constant IP address and theoretically, the same machine name for EHLO/HELO. The only variable would be the MAIL FROM. If the MAIL FROM is the same, then there is no need to do any SPF shim, hook, call since the result will be the same. Yes, the cache could produce the same (unless there was a timeout in between transactions). The dynamic protocol should work without this, so its probably more to point out the concept and optimizing value for implementations when dynamic functionality is at play. I guess the question is whether a sender is SPF valid (or SPF invalid) for an entire SMTP session/connection or per transaction. Here's a thought, if a rejection is permanent (55z), could that be considered for the entire session vs temporary 45z) for the transaction? -- HLS Scott Kitterman wrote: > On Tuesday, August 07, 2012 05:11:45 PM Hector Santos wrote: >> Scott et al, >> >> While it might be implicit, maybe some text is warranted that points >> out the ideas of dealing with multiple transactions. A past >> discussion in IETF-SMTP considered how/what state information is kept >> and cleared per transaction vs per SMTP session. >> >> This began when I pointed out a loophole is possible if a transaction >> is rejected but the client can try a different transaction and bypass >> the rejection. In this case, the real example provided was with >> greylisted transactions where the client did not QUIT (or drop), >> waited X minutes or seconds enough to get around the greylisted block >> tracking time. >> >> For our software, we now have an option (default ON) to track a >> GREYLISTED rejected transaction permanently for the entire SMTP >> session. Once rejected, new transactions are disabled. >> >> Reviewing a session in our logs this morning, I was reminded of this >> possibility for SPF as well with an facebookmail.com session. >> >> C: EHLO facebookmail.com >> S: 250-winserver.com, Pleased to meet you. >> S: 250-SIZE 10240000 >> S: 250-8BITMIME >> S: 250-SUBMITTER >> S: 250-ETRN >> S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 >> S: 250-AUTH=LOGIN >> S: 250-HELP >> S: 250 STARTTLS >> C: MAIL FROM: BODY=7BIT >> S: 250 ... Sender validation pending. >> Continue. >> C: RCPT TO:<############@santronics.com> >> ** WCX Process: wcsap ret: 550 (156 msecs) (Rejected by WCSAP SPF Fail) >> S: 550 Return Path not verifiable. >> >> Our software does the Sender verification suite of testing after a >> valid RCPT TO is issued. The testing includes SPF and it failed here >> with a non-valid IP SPF address for facebookmail.com. >> >> C: RSET >> S: 250 Reset State #1 >> C: MAIL FROM: BODY=7BIT >> S: 250 ... Sender validation pending. >> Continue. >> C: RCPT TO: >> ** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP SPF Fail) >> S: 550 Return Path not verifiable. >> >> Here, the sender tried a new transaction in the same session. Again >> failed with SPF. >> >> C: RSET >> S: 250 Reset State #2 >> C: MAIL FROM: BODY=7BIT >> S: 250 ... Sender validation pending. >> Continue. >> ** connection drop - error: 10053 state: tMail lastcmd: MAIL >> ** Completed. Elapsed Time: 55599 msecs >> >> Finally, it tried a third time, but did not issue a RCPT TO to trigger >> the SPF check and it failled dropped after a near minute. Side >> indirect point: That could be our 1 minute since we do have logic to >> minimize the session/CPU waste time with clients holding channels for >> extended minutes (3-5). In our case, it starts with an initial SMTP >> wait of 5 minutes, but after a 2nd transaction is attempted the >> timeout drops to 1 min. >> >> Anyway, I am not show what ample text may be appropriate for 4408BIS, >> if any, but an improved optimized logic and simple text could be: >> >> For SPF results that would not change in subsequence same session, >> multiple transactions, the receiver MAY use the same results without >> calling the check_host() function. [This can help minimize DNS calls >> and also close possible security loopholes.] >> >> The above is just starter text for any consideration. > > How is that different than caching the SPF result, which is already OK? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From hsantos@isdg.net Fri Aug 10 13:08: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 D590721F8607 for ; Fri, 10 Aug 2012 13:08:35 -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 3ESaSBcakHEc for ; Fri, 10 Aug 2012 13:08:35 -0700 (PDT) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BE96621F85F3 for ; Fri, 10 Aug 2012 13:08:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2002; t=1344629303; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dfQO7/WNy1rYvMN1nFHU7spX/c8=; b=awM4tD3iZLRx7g00ULmc 1xSyqio1vJ+NYUIOwVrZwqkgvmFLy0lFpTWAZfftE4KWHc9xsdDCyq0t+sEU/iK5 0P5cnUDBEjKPdcpBsmOEDdLBQb5O7O6WAZu0zz5mNOCnjIBgwbQlB5HltZn0FS+g jknjpIDxjYKYdINk1iLIkdU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 10 Aug 2012 16:08:23 -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 651113004.16798.5700; Fri, 10 Aug 2012 16:08:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2002; t=1344629135; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oV95u9C ilPzm6yvCQr/8PwdGRnj2BjGdXj2baA0585Y=; b=rAQtZzxe7M5NqqWz7ySpHtp WO7Z+GmSbWZc0llt80+d7rGoUgfsOPwFCDkSYupzQ3NKPCHA577QIlgGEUqIMAb3 4tC7vYoKrrzQD9kREYmToam1EV9trWy9TnCWzmPLTCNRiuYvS+b7d6qnyq+i6JFH whbhH3UKcgo4fXMOb0DE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 10 Aug 2012 16:05:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1249933239.9.2892; Fri, 10 Aug 2012 16:05:34 -0400 Message-ID: <50256A5A.7040806@isdg.net> Date: Fri, 10 Aug 2012 16:08:58 -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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Issue: Section 5.7 "Exists" - needs clarification X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 Aug 2012 20:08:36 -0000 A major banking customer had a problem sending mail to us today and reviewing the issue, it appears they are now outsourcing outbound mail with another service as part of their hardfail SPF policy. It turned out our SPF implementation of the EXISTS mechanism (section 5.7) followed that of an A mechanism with the misunderstanding it was looking for a A record MATCH of the connecting of IP. Working with Scott off list to get clarification, I believe this section needs some work. First, the statement in the section: This mechanism enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use. Would only be correct if the -exists (prefixed with negative) is used. Only then, would it be mimicking an RBL operation to emulate the idea of lack of an record. With the implicit +exists behavior, the existing of a record is the positive result. I only wish to point out the possible confusion and look to others to prepare some proposed text to clarify it. Here is some starting points I think needs to be made: The specific -exists mechanism (negative qualifier) enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use which suggest the lack of a record is a negative result and ends any further mechanism processing. If the implicit positive qualifier is used, then the existence of a reply yields a match for the mechanism. If I have the following logic correct, I would consider adding an binary logic table too if that make sense and easier for coders to follow: SPF result for exists command +-----------------------------------------------+ | | -exists | +exists | |===============================================| | reply | negative/exit | positive/exit | |------------+----------------+-----------------| | no reply | continue | continue | +-----------------------------------------------+ I'm sure others can write this better than I can. -- HLS From vesely@tana.it Mon Aug 13 23:45: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 2875611E80D1 for ; Mon, 13 Aug 2012 23:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=0.113, 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 qVxL2GKEJF2T for ; Mon, 13 Aug 2012 23:45:21 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2FA11E80C5 for ; Mon, 13 Aug 2012 23:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1344926702; bh=JMfxay24/jhcCGYrFLSwvH2PPJ57/McXxbKHdy6G+dE=; l=1022; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aRNOkRnJcixQxaeDW548i5jd9U7I8s5qgRvfXEKY5ZGVl0tZrjiugE/LpD9GyyIGQ PY+xQ06OBPjoFcMINQbpobrW3s2Bn+u8az9QX4rTKk2jgRcQGI0ctXKvqsI9A9sk6t x5xsbL3UZw3HQuOnGAhnFK8/BGRQY3Q8iGaQF/e4= 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, 14 Aug 2012 08:45:02 +0200 id 00000000005DC039.000000005029F3EE.00002C47 Message-ID: <5029F3EE.4030005@tana.it> Date: Tue, 14 Aug 2012 08:45:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <50256A5A.7040806@isdg.net> In-Reply-To: <50256A5A.7040806@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Issue: Section 5.7 "Exists" - needs clarification X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Aug 2012 06:45:22 -0000 On Fri 10/Aug/2012 22:08:58 +0200 Hector Santos wrote: > > First, the statement in the section: > > This mechanism enables queries that mimic the style of tests that > existing anti-spam DNS blacklists (DNSBL) use. > > Would only be correct if the -exists (prefixed with negative) is used. > Only then, would it be mimicking an RBL operation to emulate the idea > of lack of an record. With the implicit +exists behavior, the > existing of a record is the positive result. > > I only wish to point out the possible confusion and look to others to > prepare some proposed text to clarify it. It is enough to s/DNS blacklists/DNS-based lists/. To informatively cite RFC 6371 may be a useful addition. I hope Scott will fix this issue as soon as he posts 4408bis-04. I agree further clarifications on the use of "exists" with whitelists are also needed. But they deserve additional discussion, and will most likely go in different sections of the document. Hence, they belong to a different issue. From superuser@gmail.com Tue Aug 14 12:26: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 3E89621F86D5 for ; Tue, 14 Aug 2012 12:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtW+TXy+c0Ka for ; Tue, 14 Aug 2012 12:26: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 8028D21F86CE for ; Tue, 14 Aug 2012 12:26:41 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so478619lbb.31 for ; Tue, 14 Aug 2012 12:26: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=Te1uit9k05JSlqr+FHmSKdn6UruYbS35GwLBnUzirVE=; b=AKcZXh4DmqGg+I5Jvhy8YO9JPNV58E5jNKUX0PBmPS2IVMG4i1F2CdpjruuR29dnQk +KQyEYQwj7gLfJ+Wbgwtf7RvWUOm83E1yAJxtRBNS7xft3kO5e6U0XtuIhXiqb/dB/el 74nVkohcGFeFiyehF3V6RWipdUDlNiTbFeMjqfAj/XAvopG9hEjrTNdBTLtU6JKUcOUq PHmfCIQfQW7PHwFPnxohnV5y/Ahd7FagC7dnk9vByAYOdI8l0c9n0UFQZHLonVYhv8XZ 1ozqQutkZLsZIiadOUi8YwKfqPIhY3V6+3vZj+5cF/A48TXa4j51MBanOJIMtAO8yvHl tx2w== MIME-Version: 1.0 Received: by 10.112.83.229 with SMTP id t5mr8512025lby.8.1344972400334; Tue, 14 Aug 2012 12:26:40 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Tue, 14 Aug 2012 12:26:40 -0700 (PDT) In-Reply-To: <5029F3EE.4030005@tana.it> References: <50256A5A.7040806@isdg.net> <5029F3EE.4030005@tana.it> Date: Tue, 14 Aug 2012 12:26:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: Section 5.7 "Exists" - needs clarification X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Aug 2012 19:26:42 -0000 On Mon, Aug 13, 2012 at 11:45 PM, Alessandro Vesely wrote: > It is enough to s/DNS blacklists/DNS-based lists/. To informatively > cite RFC 6371 may be a useful addition. That's an MPLS RFC. Which one did you mean? -MSK From vesely@tana.it Wed Aug 15 00:56: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 E650221F84B5 for ; Wed, 15 Aug 2012 00:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.608 X-Spam-Level: X-Spam-Status: No, score=-4.608 tagged_above=-999 required=5 tests=[AWL=0.111, 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 2yFyUDZOa17b for ; Wed, 15 Aug 2012 00:56:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 11B7F21F8703 for ; Wed, 15 Aug 2012 00:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345017372; bh=IHsigV+q/wBHuy1z2aS0H8gMnZDdY27VMkD2Y/QbRmE=; l=496; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=d1XtSngmXleD0MDWVAq6YvoRZ0ZDoDBPSaJrXmD8Zoq+l3mSdeDR6WFD84zRHh58n oHft53kx0rd2DRhfHRiuYtMCQX3GZ8F0Lk9frKZ/+QwRT3ykh12aEwe9/3BpSlAVHA Ix94v1/xad2tLISvN6/7QknYkX5FVkUMVr3NN0WU= 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; Wed, 15 Aug 2012 09:56:12 +0200 id 00000000005DC033.00000000502B561C.00000367 Message-ID: <502B561C.3000608@tana.it> Date: Wed, 15 Aug 2012 09:56:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <50256A5A.7040806@isdg.net> <5029F3EE.4030005@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Issue: Section 5.7 "Exists" - needs clarification X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 15 Aug 2012 07:56:20 -0000 On Tue 14/Aug/2012 21:26:40 +0200 Murray S. Kucherawy wrote: > On Mon, Aug 13, 2012 at 11:45 PM, Alessandro Vesely wrote: >> It is enough to s/DNS blacklists/DNS-based lists/. To informatively >> cite RFC 6371 may be a useful addition. > > That's an MPLS RFC. Which one did you mean? Ooops, I meant 6471, Overview of Best Email DNS-Based List (DNSBL) Operational Practices. Its title already ratifies the use of a color-free acronym expansion. Thanks for the catch From internet-drafts@ietf.org Wed Aug 15 23:39: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 9CCDB21F8595; Wed, 15 Aug 2012 23:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUIWpFsopu1S; Wed, 15 Aug 2012 23:39:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0203221F85AA; Wed, 15 Aug 2012 23:39:53 -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.33 Message-ID: <20120816063953.12394.49487.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 23:39:53 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-04.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, 16 Aug 2012 06:39:53 -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-04.txt Pages : 66 Date : 2012-08-15 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the author's address 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Wed Aug 15 23:50: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 91FC821F861F for ; Wed, 15 Aug 2012 23:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUEeDY7UvgmJ for ; Wed, 15 Aug 2012 23:50:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB121F861E for ; Wed, 15 Aug 2012 23:50:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9763920E4091; Thu, 16 Aug 2012 02:50:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345099847; bh=Gr1eEJy/wiKZvONHp4YJwZh20y1IUv6JD/Qqm6pNOH4=; h=From:To:Subject:Date:From; b=IopCXyClzPjf1C3oQjzXF06MowNH6L0cK6MuIMoWh9TLVbyMzx+6lMbx42B6YaUef V+trtgtdI0UmKLPO048pjVBCROQCPSWQWmFOH2YyzdnMaDmfrLH7waoBkprHxNOsL9 2Z7qbl+s8hnzkpduMdXU9a84N3egB7XKf6qKNLp8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7256120E403E; Thu, 16 Aug 2012 02:50:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Aug 2012 02:50:46 -0400 Message-ID: <1908971.Uo0Ahn547K@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 06:50:52 -0000 I just uploaded 04 and it's too late for me to wait up for the notification. This version has a lot of changes, mostly based on Murray's excellent and detailed review and some of the discussions that follow up from it. I think it addresses all the on list comments. If I missed something, please remind me and we'll put it in the hopper for 05. It's enough changes that my summary is "go read the diff." I'll try and look at the issue tracker tomorrow and see where we are. Scott K From vesely@tana.it Thu Aug 16 05:52: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 9B70321F85D5 for ; Thu, 16 Aug 2012 05:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPOg8xC6sS7f for ; Thu, 16 Aug 2012 05:52:33 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 006BB21F8594 for ; Thu, 16 Aug 2012 05:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345121549; bh=fNsI5QeAGUrLr5rfS5fyVMYiiY9S8hGnE68a/zb/ax4=; l=10337; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YwCdqz4wg7wVA9Oa1UFBL5u3hrhvdAj0DUjdxmspXPUeJrQsPmCHNDwayoj27MG0z aU9wSS5wEkeVaFYcONyoHGrhWfbSlg+f6D2HuRWECZjqYluvfx/7nC1It4YahMjaGA YjeGGCwL6AqPjXPJl1ij4+CvmPLF1jwR30fz6oWU= 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, 16 Aug 2012 14:52:29 +0200 id 00000000005DC03F.00000000502CED0D.00000AB0 Message-ID: <502CED0C.8000506@tana.it> Date: Thu, 16 Aug 2012 14:52:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> In-Reply-To: <1908971.Uo0Ahn547K@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 12:52:34 -0000 On Thu 16/Aug/2012 08:50:46 +0200 Scott Kitterman wrote: > > It's enough changes that my summary is "go read the diff." Yes, many changes. At last. Here's some comments: 1. *Introduction* This document defines a protocol by which ADMDs can authorize hosts to use their domain names in the RFC5321.MailFrom or RFC5321.HELO/ .EHLO identities. Compliant ADMDs publish Sender Policy Framework (SPF) records in DNS [...] Two notes about that snippet. First the positive one: I like the phrase "Compliant ADMDs". I suggest to stick to this concept as it is much clearer than "compliant domain" (see below). For the negative note: Is it possible to roll back that 5598-based replacement of identity names, _please_? RFC5321.HELO/.EHLO is excessively long and lowers the readability of the document. I don't object on that string appearing in Section 1.3.4. After precisely defining what HELO means, it is not necessary to repeat the whole definition any more. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such email, such as rejecting it. Kudos for Section 9.3! Now that we have it, that last sentence in the Introduction can be reworded so as to anticipate it. For example: Furthermore, receivers can devise local policies (Section 9.3) in order to facilitate processing of messages that get specific results; for example, they can whitelist domains that pass the verification, or reject mail that fails it. 2.3. *Publishing Authorization* An SPF-compliant domain MUST publish a valid SPF record as described in Section 3. This record authorizes the use of the domain name in the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities by the MTAs it specifies. It is possible to address compliance by ADMD, rather than by domain: An SPF-compliant ADMD MUST publish valid SPF records as described in Section 3. These records authorize the use of the relevant domain names in HELO and MAILFROM identities by the MTAs it specifies. That way, the spec can modulate the requirements about which domains MUST/SHOULD have an SPF record. Until the term "domain" is used interchangeably for a DNS label or an ADMD, wording such requirements is difficult. SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. IMHO, constructs like "If you choose X then you MUST Y" are meaningless. I'll never be able to tell whether you are compliant, unless I have a method to determine what you chose. And since you can always change your mind, the normative sense of the verb is completely lost. For the merit, we'll need to discuss this point. Of course, we are defining in what cases an ADMD can be said to be SPF compliant. I'd put that there should no reason a domain wouldn't comply, except for ignorance of mistake. Indeed, there is no advantage in standardizing a protocol that cannot be adhered to. For example, consider a mail admin who is unable to devise an SPF policy, for the time being. While she takes steps for gathering the necessary data, she puts some RRs like "v=spf1 ?all" just to optimize DNS caches. How would we rate her, as far as compliance is concerned? 2.5.4. *Fail* A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of SPF fail messages is a matter of local policy. See Section 9.3 for considerations on developing local policy. For the sake of clarity, cannot we say explicitly that the receiver "MAY reject the message, according to local policy"? It is what that paragraph is actually saying, except that we force the reader to interpret the term "disposition". I realize that being explicit may emphasize a weakness of SPF, which I hope we'll address later on. As a further point on that snippet, that "given identity" sounds obscure. The result doesn't formally depend on which identity is being checked. 3. *SPF Records* The paragraph "Domain owners wishing to be SPF compliant [...]" is redundant after Section 2.3. I'd strike it. In the paragraph next to it, s/in Section 3/above/. Since TXT records have multiple uses, beware of other TXT records published there for other purposes. They might cause problems with size limits (see Section 3.4) and care MUST be taken to ensure only SPF records are used for SPF processing. I'd s/ and care MUST be taken/. Verifiers MUST take care/. 3.3. *Multiple Strings in a Single DNS record* As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. s/[RFC1035] sections 3.3.14 and 3.3/Section 5.1 of [RFC1035]/ Remove the parenthesized phrase. 3.4. *Record Size* Why would TCP be less reliable than UDP? Instead, I'd mention that, in the presence of multiple TXT records, two UDP queries done through a redirection to _spf.example.com still cost less than setting up a TCP connection. 4.6.4. *DNS Lookup Limits* SPF implementations MUST limit the number of mechanisms and modifiers ("terms") that DNS lookups to at most 10 during SPF evaluation. s/that DNS lookups/that cause any DNS query/ if it would make for better English. 5.1. *"all"* Any "redirect" modifier (Section 6.1) has MUST be ignored when there is an "all" mechanism in the record. s/has // 5.5. *"ptr" (deprecated)* I like the numbered algorithm. It's more readable. Does the grammar allow "ptr:example.com/24"? Step 4 doesn't seem to allow fuzzy IP comparisons based on given CIDR-length. Another question: If there was a {temp/perm}error while doing an A RR lookup, and then the mechanism failed to match, MAY a {temp/perm}error be returned instead of non-match? s/yearrs/years/ 7. *Recording The Result* It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. There are two methods for doing this: the Received-SPF Header Field defined here and the more generic Authentication-Results Header Field defined in [RFC5451]. Because these fields are generally used within a receiving ADMD, it is a local policy choice which to include. In general, the more broadly applicable Authentication-Results Header Field ought to be used, but it SHOULD provide the same information as if a Received-SPF Header Field were used. Is there a reason why "Header Field" is capitalized that way? I don't think we can be normative-by-cmparison on what information is actually put on the field, because we don't know which tags would have been filled in the Received-SPF field if the latter were used. For an alternative wording: In general, the more broadly applicable Authentication-Results header field ought to be used, as long as it can convey the same information that the verifier would have written in a Received-SPF header field if the latter had been used. The next paragraph should be split in two: If an SMTP receiver chooses to do so, it SHOULD use one of these header fields for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.) See above for the "If ... SHOULD". I'd propose: An SMTP receiver SHOULD use one and only one of these header fields. In case both of them are used, they MUST be consistent with one another. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.) Note that A-R can convey results for multiple identities within a single header field, so it doesn't make much sense to require to use two of them. 7.2. *SPF Results in the Authentication-Results Header Field* We need to discuss this further: Why "Authserv-id SHOULD be the name of the receiving host performing the check"? What if the check is performed by a different host, or the host has multiple names? Being consistent with the corresponding Received: field seems to be a good idea, but then RFC 5451 allows different strategies. Why overload the "reason" tag? RFC 5451 is extensible and this spec may add any missing tags. The example misses the explanation. 8.1. *Macro Definitions* Implementations SHOULD be aware that if no directive processed during the evaluation of check_host() contains an "s", "l", "o", or "h" macro, then the results of the evaluation can be cached on the basis of and alone for as long as the shortest Time To Live (TTL) of all the DNS records involved. "SHOULD be aware" doesn't mean anything to me. I'd make it non-normative. 9.1.3. *Bounces* Zone file generation for significant numbers of hosts can be consolidated using the redirect modifier and scripted for initial deployment. Administrators might alternatively consider publishing an SPF for *.domain (wildcard domains) in that case if the involved hostnames do not have already any other DNS record. I'd strike the last sentence, or at least recall that wildcard records are discouraged and provide a link to Section 3.5. Further advice is needed for scripting the zone. For example, mention that any host that has an IP address is a good candidate for an SPF record; those that do send mail really deserve one; and so forth. Should we provide a Perl script in an appendix? 9.2.4. *MTA Relays* For mail senders, this means that published SPF records must authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. I believe the last word should be "relaying". *Last and least* I counted 13 occurrences of "SPF client(s)". Since an SPF client is likely an SMTP the server, that term may be confusing. How about using "SPF verifier(s)" instead? From spf2@kitterman.com Thu Aug 16 08:40: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 A153121F85D6 for ; Thu, 16 Aug 2012 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VJoGJbCLymD for ; Thu, 16 Aug 2012 08:40:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39821F8550 for ; Thu, 16 Aug 2012 08:40:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8E9C320E4081; Thu, 16 Aug 2012 11:40:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345131642; bh=eJoIkmRQJse65mIAP8Y4L/bN+61r53c3+RQs7dhQ4Lk=; h=From:To:Subject:Date:From; b=DYv9h6cVuNTV//2EhWY88k/1T7HK1sVkHJDpXa10nYr9ZP/mvweRJeGHw9pO567NE Bt3ywQlxSeGM1pjtXmcADANDxiJT/6yEVv46dgPkw2bBkthZFKQpr036TcvPx71b1m uQReahbmFsoy92mbfw/0ejcG7CUBNm+mJ5Cp5W9I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6529920E4077; Thu, 16 Aug 2012 11:40:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Aug 2012 11:40:41 -0400 Message-ID: <3629422.4uNyJB6DBU@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 15:40:44 -0000 Alessandro: Since you filed this issue: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/12 I would appreciate it if you would review the current -04 draft and comment on if additional changes are needed (text always welcome). In particular, in this revision there is more discussion about redirect and why it is useful. I don't think this is addressed in your comments you already sent today. Scott K From spf2@kitterman.com Thu Aug 16 09:11: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 1A4A121F8533 for ; Thu, 16 Aug 2012 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIYmXB6i5xWi for ; Thu, 16 Aug 2012 09:11:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3A21F852C for ; Thu, 16 Aug 2012 09:11:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E38B020E4081; Thu, 16 Aug 2012 12:11:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345133491; bh=O5HsqMqr30uhlv8AGLZBeWzZly2rzb1quhlD1hfp/zo=; h=From:To:Subject:Date:From; b=QDxI2yMShLpd/5cj9/pwhQCPxrPpHCPuNsu/wiPolbz5rhgdTAdrb+XikPH+nwS1G EmstCAd1Bgh0IJqGqpYAhfudGW/hoyYy4LwbQnyE09eJK6/mylkxzqpK1UxYBG2yQH z8kwmOgdsiIO16pCX68DK7G/A5lxbjEBRW14Rovs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD68520E4077; Thu, 16 Aug 2012 12:11:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Aug 2012 12:11:30 -0400 Message-ID: <1890313.bg7xPqubBI@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] 4408bis 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: Thu, 16 Aug 2012 16:11:33 -0000 I've just gone through the issue tracker and there are nine issues currently open, of which four are (I think) addressed in the new -04 draft and are waiting for WG feedback: http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Those five issues and addressing feedback on the -04 draft are what I have on my TODO list, so if there are other issues, let's get them on the table soon. Scott K From vesely@tana.it Thu Aug 16 11:58: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 B1EC221F853F for ; Thu, 16 Aug 2012 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpih1NGhh4v3 for ; Thu, 16 Aug 2012 11:58:34 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E844E21F85ED for ; Thu, 16 Aug 2012 11:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345143511; bh=kM1HiRjT2IpJU3pSTLQmGId0/Xol4mNSIXuLkhyHRP4=; l=901; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Cl9Zd6GTV30vQzC62UKVgoREV2DWDmJVDDclB7UyhoQ9Q3qqd1ygeITRzzgQShSpE 2jziTBNs4FCpeHU67K/mf4rG0sv7VAw/OyzmJCp8VVqP0/SnLiODqf6SLoZLogQgYm 8PZZfiCniZAZa9I3dCF/uw3nLPq4lmO3ZaaMvlS0= 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, 16 Aug 2012 20:58:31 +0200 id 00000000005DC039.00000000502D42D7.00005AEA Message-ID: <502D42D7.7010900@tana.it> Date: Thu, 16 Aug 2012 20:58:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <3629422.4uNyJB6DBU@scott-latitude-e6320> In-Reply-To: <3629422.4uNyJB6DBU@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 18:58:34 -0000 Hi Scott, On Thu 16/Aug/2012 17:40:41 +0200 Scott Kitterman wrote: > > Since you filed this issue: > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/12 > > I would appreciate it if you would review the current -04 draft and > comment on if additional changes are needed (text always welcome). Briefly, adopting SPF implies a conundrum of endlessly repeated philosophical principles like "No, it is the {sender|receiver} who should do so and so." A protocol that people can adhere to should not cause such issues, or at least indicate a quick way to solve them. We need to discuss this subject, IMHO. > In particular, in this revision there is more discussion about > redirect and why it is useful. The redirect modifier has nothing to do with issue #12. > I don't think this is addressed in your comments you already sent > today. No, that was too long already... From spf2@kitterman.com Thu Aug 16 12: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 F050621F85C5 for ; Thu, 16 Aug 2012 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNpI9Yo5kdi9 for ; Thu, 16 Aug 2012 12:01:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3079A21F8672 for ; Thu, 16 Aug 2012 12:01:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4D2BC20E4081; Thu, 16 Aug 2012 15:01:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345143662; bh=kVLFt298vxbDtflkgBxPti/nlRIiI69U5AjBRmIkLHc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RJ9Rt058jmc6rKaF+0cUFyCZxJaixlyJ9tWnKynAumLcTyeLcZxd05HbwZvA+Z14m 9iGcjHSwnk6G5fut9TaosO/5/vyLOO61ifNhcccSCNsvlA2V/FmvSHlidnOCN12cRE DFmshJbnVfUAdgMf0EpMISweGC5B8faGzSjvDFsM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 23C1220E4077; Thu, 16 Aug 2012 15:01:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Aug 2012 15:01:01 -0400 Message-ID: <1358347.VdGSBTFpxD@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502D42D7.7010900@tana.it> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@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 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 19:01:14 -0000 On Thursday, August 16, 2012 08:58:31 PM Alessandro Vesely wrote: > > In particular, in this revision there is more discussion about > > redirect and why it is useful. > > The redirect modifier has nothing to do with issue #12. In issue #12 it says: "We should encourage the use of _spf labels and redirect= for designing sound and maintainable SPF compliance." So I'm a bit confused why you say it's unrelated. Scott K From sm@elandsys.com Thu Aug 16 12:08: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 B198821F869C for ; Thu, 16 Aug 2012 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfELBSUyhYCY for ; Thu, 16 Aug 2012 12:08:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0DA21F8574 for ; Thu, 16 Aug 2012 12:08:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.144]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7GJ7lqS010930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 12:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345144078; bh=F+qZqQBIX1TaitIw/WXDV+qiKKWmcaj8E1waRO9OA48=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W1yygS76JclBMDhKAwWn/pAuiaoXxR8ZMG+1JDxpWepDk9+uL7H67y8nvNryAesTY tqQR4F9swTui/Gh3J79n4JQ1X/anS6SioWUMnOLKzVwyTZFzYsq6on9ffEMCt+WkzD IcDpWoxgG2bm1Ect8iXM0mRqAUIbOtvbC7F/8mVw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345144078; i=@elandsys.com; bh=F+qZqQBIX1TaitIw/WXDV+qiKKWmcaj8E1waRO9OA48=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ztu5RSh8DbH3qKyeZcxVQWe6/tu8+wjpEPt+iXpf2fQixRihEf3GHZ9xsLHBffwHC N500y16OIoeTk7iaJLmXkSVdcRdb8w8zPt3NgXHyVmerMmxdw88JTqoN8WaiBlCQSx wA55CFoef6m+wlcSUOBxXz2zeLJLcQx1rTKwbwVc= Message-Id: <6.2.5.6.2.20120816115818.09823440@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Aug 2012 12:07:02 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1908971.Uo0Ahn547K@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 19:08:00 -0000 At 23:50 15-08-2012, Scott Kitterman wrote: >I just uploaded 04 and it's too late for me to wait up for the notification. Thanks for moving the draft forward. Andrew and I are waiting for feedback from the Responsible AD about an issue. Meanwhile, could the working group please review draft-ietf-spfbis-4408bis-04 ( http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-04 ) and comment? Thanks, S. Moonesamy From hsantos@isdg.net Thu Aug 16 13:02: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 25EC221F84C8 for ; Thu, 16 Aug 2012 13:02:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol-i+JDNL053 for ; Thu, 16 Aug 2012 13:02:46 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0321F853C for ; Thu, 16 Aug 2012 13:02:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1409; t=1345147364; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yta7ag15TWO/inZiCRHiL2ggHek=; b=az7IuP8hVs1dRB046ak0 Q5ylTE01Q6xWVLr2Y/nulMkPiPmm4WnzLn8SXqqLQCd/uRydRSPi4mM6wKn8DOVm q2P0HHrkdhEvR/sJGonz4u3oVEEN6wmV72XQpxvERrMZjV9CySuXQ9wuLlv0R+9O lXANnmZCIdyiMfKLaI3adEk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 16 Aug 2012 16:02:44 -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 1169167146.21829.2740; Thu, 16 Aug 2012 16:02:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1409; t=1345147185; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UqsYkd9 l6Xsou9KLAUjYEhLe+v1ONch2ODs4oc/45hA=; b=F9dHcvqiT0bkJ1QhDpd9UIO 8cBcfr9UmotPX0/U+hw6a/UniSLQofAgbYZJIa5vw2O2pzPxTWcrHz9sv5ghkF6R //nosr/GPuo/PRCdyaj8+0LusLIFTp/QbkO1rx+o9B4Df84k3he/lMprlA6u/OFG Pyx+VDN9s06qOyB3A8KA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 16 Aug 2012 15:59: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 1767982739.9.3964; Thu, 16 Aug 2012 15:59:43 -0400 Message-ID: <502D51E7.3020300@isdg.net> Date: Thu, 16 Aug 2012 16:02:47 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120816115818.09823440@resistor.net> In-Reply-To: <6.2.5.6.2.20120816115818.09823440@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 20:02:47 -0000 S Moonesamy wrote: > At 23:50 15-08-2012, Scott Kitterman wrote: >> I just uploaded 04 and it's too late for me to wait up for the >> notification. > > Thanks for moving the draft forward. > > Andrew and I are waiting for feedback from the Responsible AD about an > issue. Meanwhile, could the working group please review > draft-ietf-spfbis-4408bis-04 ( > http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-04 ) and comment? > > Thanks, > S. Moonesamy There are massive changes that needs time to review. With a quick perusal, I don't particular agree with and/or needs a lot of work, in particular the new section 9.0. It would of been nice if the editor would of posted for the WG list to first review the substantial changes he intended to make or add because a good bit of it seems highly subjective, not consistent with our 9 years of practice and leans towards to specific deployment concepts. Now we are struck in a repeated OPT-OUT "Rough Consensus" situation where unexpected changes is done first and now a very high bar to reverse it without controversies developing. IMO, an usual source for contention and waste of time. Looking for specific items I was focused with, I can see security aspects and concerns I posted were also ignored. But I hope to read the diff and make sense of it all more thoroughly over the next week or days. Thanks -- HLS From ajs@anvilwalrusden.com Thu Aug 16 13:28: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 97CAF21F85DF for ; Thu, 16 Aug 2012 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5avdBZr3xuV for ; Thu, 16 Aug 2012 13:28:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC4721F85C9 for ; Thu, 16 Aug 2012 13:28:14 -0700 (PDT) Received: from mx1.yitter.info (nat-04-mht.dyndns.com [216.146.45.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 68CD88A031 for ; Thu, 16 Aug 2012 20:28:12 +0000 (UTC) Date: Thu, 16 Aug 2012 16:28:08 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120816202808.GA24136@mx1.yitter.info> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120816115818.09823440@resistor.net> <502D51E7.3020300@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502D51E7.3020300@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 20:28:14 -0000 On Thu, Aug 16, 2012 at 04:02:47PM -0400, Hector Santos wrote: > > It would of been nice if the editor would of posted for the WG list > to first review the substantial changes he intended to make or add Why? This is an Internet Draft. This is the format we have for reviewing and commenting. Sending it to the list in advance is not something we want to encourage. If there are specific things that one sent that one thinks were not reflected, then it is entirely correct to raise that issue. I note that suggested replacement text is more likely to reflect the change one wants (particularly if it also attracts support). Best, A (as co-chair) -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Aug 16 13:42: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 1E82221F84B2 for ; Thu, 16 Aug 2012 13:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV2gXrhLJram for ; Thu, 16 Aug 2012 13:42:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15221F84A7 for ; Thu, 16 Aug 2012 13:42:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C26C820E4081 for ; Thu, 16 Aug 2012 16:42:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345149748; bh=MFA6Q3FS7Ki2/lPCePB84AOQAgrkxBb2u3ZCCtIROE8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=FY5Jj8dtiEoeuDDMlQuIfxGhigqCF4zr6RJW+i1SJ8WXcY6Kka66p2jl7UEkmtz5Q wtRWnsFXsuOY4cHlQcWa78jDEsaM+Grty+oIrMpoe5La9xJVTVarzJGWa3jTDDlq6j cAkh/TRQl1cqcy0HAnCG0r/W4zqofxrLHnOlBIFE= Received: from kitterma-desktop.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 ESMTPS id 953CA20E4077 for ; Thu, 16 Aug 2012 16:42:28 -0400 (EDT) From: Scott Kitterman Organization: Kitterman Technical Services To: spfbis@ietf.org Date: Thu, 16 Aug 2012 16:42:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-42-generic; KDE/4.4.5; i686; ; ) References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120816115818.09823440@resistor.net> <502D51E7.3020300@isdg.net> In-Reply-To: <502D51E7.3020300@isdg.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208161642.26464.spf2@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 20:42:30 -0000 On Thursday, August 16, 2012 04:02:47 pm Hector Santos wrote: ... > It would of been nice if the editor would of posted for the WG list to > first review the substantial changes he intended to make or add > because a good bit of it seems highly subjective, not consistent with > our 9 years of practice and leans towards to specific deployment > concepts. It's called a draft for a reason. It's there for review. I decline to engage in the silliness of pre-reviewing everything before I post drafts for review. Nothing gains consensus on the basis of my having written it. Almost nothing that's new in this draft was written by me without it being stimulated by comments from this list. Please leave the name calling aside and let us know your specific issues. I added explicit language about PTR support being something recipients MUST do based on your concerns. I may not have agreed with or felt like the balance of the group was for some of your comments, but I did not ignore them. Scott K From hsantos@isdg.net Thu Aug 16 14:47: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 C07E621F84D2 for ; Thu, 16 Aug 2012 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZTWHAwPdONF for ; Thu, 16 Aug 2012 14:47:07 -0700 (PDT) Received: from news.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B237821F84F3 for ; Thu, 16 Aug 2012 14:47:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1802; t=1345153619; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=M3pySPfwZX7OM65ap2oruGUDa3g=; b=FavUCVtGJ95ZP99BZVIe 4l0LGehWd4F3i1Ge/4obov11GOFRpYnNEWf2uD+ALarSQUMFv8d6cUZJyWQc2N3O JdvcLBl86gP28gjx0dI8Lub/F/VT8cA8u3gWmWhTU7aFm1DnCoOGNx6XqeeBkU55 fnnFOKRG+DKzALHSW/BekEE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 16 Aug 2012 17:46:59 -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 1175422536.21829.3756; Thu, 16 Aug 2012 17:46:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1802; t=1345153438; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WyO0M2L 9lAJELenIQCfMNXRqj7y8aUDz/NnrNGvyCCY=; b=Fg03uMr151shn7dorNMrctz HPRbgw8jFW/rzCWcUU1Mw9ufGbiGCmTJPEwcGK3wgaDGMEJkacsbC3EBKgjF35zz N38EJtCLTEoZJCObk8SHcwagshTp8yITzmETDX/+Qptw7tE6aVpWaERnZ5UO+7R5 91AtgKlFAtCKeQw52RAs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 16 Aug 2012 17:43:58 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1774236114.9.5272; Thu, 16 Aug 2012 17:43:57 -0400 Message-ID: <502D6A6B.1080804@isdg.net> Date: Thu, 16 Aug 2012 17:47:23 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120816115818.09823440@resistor.net> <502D51E7.3020300@isdg.net> <20120816202808.GA24136@mx1.yitter.info> In-Reply-To: <20120816202808.GA24136@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 21:47:07 -0000 Andrew Sullivan wrote: > On Thu, Aug 16, 2012 at 04:02:47PM -0400, Hector Santos wrote: >> It would of been nice if the editor would of posted for the WG list >> to first review the substantial changes he intended to make or add > > Why? This is an Internet Draft. This is the format we have for > reviewing and commenting. Sending it to the list in advance is not > something we want to encourage. Because of past experience, and I stress only an isolated experience, not my general experience. From quick reading so far, section 9.0 was written without any consensus and now it (and changes) will be much harder to overcome, especially if it originates from me, unfortunately. Look, too more unprofessional ignorance is going on and if thats ok by the group, so be it. But this is not a HOBBY for me. The output of this group directly impacts in my product and how my customers will use SPF and I will have my input or the new document will not get adopted by me, which means changes not implemented, largely ignored. Status quo, picking and choosing what goods vs bad and quite frankly, I am tired of this trend for the RFC documents. I had to bring up a more general issue, but its part of what you see here. Sorry. Section 9.0 is linked to other existing sections which required a much wider engineering review than what was done and I strongly feel there is actual empirical information that is not reflected. No problem if it wasn't so subjective, was more generic protocol material and more reflective of actual practice out there. i.e. some of the stuff we should of extracted during the experiment report, unfortunately, we focused on other things. The issues were/are already on the table (documented) and I don't think they are un-addressable. -- HLS From spf2@kitterman.com Thu Aug 16 15:02: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 A20CB11E809B for ; Thu, 16 Aug 2012 15:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGPiek0M+CJd for ; Thu, 16 Aug 2012 15:02:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFA11E808A for ; Thu, 16 Aug 2012 15:02:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBCC920E4081; Thu, 16 Aug 2012 18:02:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345154540; bh=nLPX2+BVqHudIb+lzPU8qPePTPT+1w67Tv6aK60diy8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hM6aWZu/RDaaYv3LQpt4sCCUD62Cv70NPgOx4uguD0H70moG/Yd59T8+aWn2fxB+q 4tWRk0oeDj+MWKCMvn8zwbs9tj/tNTuV4eLsEPLHqWMByhlv11FLK7rGsuFvu8ZhU3 SGg2R7WraKiUKoD5UTp0pxMNr5xmSJ0dgGYTzjwQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B2EA520E4077; Thu, 16 Aug 2012 18:02:20 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 Aug 2012 18:02:19 -0400 Message-ID: <1367995.li6hrOxpKc@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502D6A6B.1080804@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <20120816202808.GA24136@mx1.yitter.info> <502D6A6B.1080804@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 16 Aug 2012 22:02:22 -0000 On Thursday, August 16, 2012 05:47:23 PM Hector Santos wrote: > Andrew Sullivan wrote: > > On Thu, Aug 16, 2012 at 04:02:47PM -0400, Hector Santos wrote: > >> It would of been nice if the editor would of posted for the WG list > >> to first review the substantial changes he intended to make or add > > > > Why? This is an Internet Draft. This is the format we have for > > reviewing and commenting. Sending it to the list in advance is not > > something we want to encourage. > > Because of past experience, and I stress only an isolated experience, > not my general experience. From quick reading so far, section 9.0 was > written without any consensus and now it (and changes) will be much > harder to overcome, especially if it originates from me, > unfortunately. Look, too more unprofessional ignorance is going on and > if thats ok by the group, so be it. But this is not a HOBBY for me. > The output of this group directly impacts in my product and how my > customers will use SPF and I will have my input or the new document > will not get adopted by me, which means changes not implemented, > largely ignored. Status quo, picking and choosing what goods vs bad > and quite frankly, I am tired of this trend for the RFC documents. I > had to bring up a more general issue, but its part of what you see > here. Sorry. > > Section 9.0 is linked to other existing sections which required a much > wider engineering review than what was done and I strongly feel there > is actual empirical information that is not reflected. No problem if > it wasn't so subjective, was more generic protocol material and more > reflective of actual practice out there. i.e. some of the stuff we > should of extracted during the experiment report, unfortunately, we > focused on other things. The issues were/are already on the table > (documented) and I don't think they are un-addressable. Section 9 is not new. It's in RFC 4408 and every draft that follows. There are three major changes for -04 in section 9: 9.1.1. DNS Resource Considerations: Rewritten/expanded. This is Alessandro Vesely's text that he provided me offline and I posted here almost a month ago for review. 9.1.3. Bounces: New subsection provided by Franck Martin that was previously published on this list. What's in the draft is almost exactly what he posted. 9.3. Receivers: This is new. I wrote the first two subsections in response to comments by Murray Kucherawy. He provided the text (on this list) for the last subsection. So most of the change in the section you are complaining about was previously posted here. Keep in mind that all of section 9 is non-normative. If you've got actual suggestions to make, please make them. Vague assertions that it could be better don't help me get this done. Scott K From johnl@iecc.com Thu Aug 16 20:46: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 D4D8521F8474 for ; Thu, 16 Aug 2012 20:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.848 X-Spam-Level: X-Spam-Status: No, score=-110.848 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_17=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lmlHfgDGd1s for ; Thu, 16 Aug 2012 20:46: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 E00F921F8473 for ; Thu, 16 Aug 2012 20:46:26 -0700 (PDT) Received: (qmail 17310 invoked from network); 17 Aug 2012 03:46:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Aug 2012 03:46:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=502dbe91.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=2lWNkDBmbklYrT3tdJ8IBGo+CfG5keRUZrJpwE6fRWI=; b=JbDThZJf/YwYnhfs4VKNhxsnNd5xjMnwe039lDdx4KhWJCr8sFR3uJ9XRJPNoZcKr0skzLKkdvOQa+fR9Zfp2nM42mmjKXHr6HDpu66v183sAg1IlyV+6hxaMKXZ+hgenhAmIWYOVVcxd7g1uWKgdNaoLMz9sSot4MiYco7dG7I= 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=502dbe91.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=2lWNkDBmbklYrT3tdJ8IBGo+CfG5keRUZrJpwE6fRWI=; b=HcUsECmeiKAFjrunW7HhoF1px8UYbFL4Ew+qBFG7cQPm3wMCS988hxSUY2tbROG8CWcU6kI+meyvA+1zcEBuUyo3PrU8I51vKi9cPhj8utRyuU89AtbnwbPju03Em1gEdNqUTDSHPLPluwPjz6CDxW/mZQUBjLET/1bf7oxppVo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Aug 2012 03:46:03 -0000 Message-ID: <20120817034603.20684.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1908971.Uo0Ahn547K@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 03:46:28 -0000 >It's enough changes that my summary is "go read the diff." Man, what a lot of work, thanks. Most of these are nits: Abstract: Why "author's address"? Usually that means the address in the From: header. Suggest using one of the terms in 1.3.3 2.5.6: suggest adding "software" to the end of the new sentence. As it stands one could read it as referring to problems in the DNS records that the receiver publishes. 3: suggest ref to 4.6.4 as well as 9.1.1 3.3: remove parenthetical ref to SPF RR type 3.4: there's nothing wrong in what this says, but it's a generic problem with all DNS usage, nothing specific to SPF 3.5: in examples X.COM is a real domain (it's Paypal). Suggest using X.EXAMPLE or EXAMPLE.COM Also in 3.5, there are real uses of MX wildcards, typically used to treat mail to foo@bar.example.com as bar-foo@example.com so people can have less obviously tagged addresses. I'd suggest saying to be sure that the SPF records match the domains actually in use in outgoing mail and leave it at that. 4.1: suggest removing last sentence. It's a conceptual function, it might not be coded as a function at all. 5: last pp, throws the exception? I hope you mean that evaluation stops and the topmost check_host() returns temperror. Also in the table in 5.2 5.5: yearrs -> years 6.1: modifier intended -> modifier is intended end of 8.1: what is an implementation supposed to do if a macro expansion creates a bogus domain due to input data, e.g., using %l in a domain name since local parts can contain spaces, punctuation, and other random ASCII crud? 10.3, second bullet: I think TCP spoofing was fixed long enough ago that this item can go From vesely@tana.it Fri Aug 17 00:32:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455B221F8535 for ; Fri, 17 Aug 2012 00:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbE0J03GVJkP for ; Fri, 17 Aug 2012 00:32:04 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 668CC21F853C for ; Fri, 17 Aug 2012 00:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345188721; bh=kQdb8VgKOr9puxA2yYt4i1PtomyhS0G9u+lrNG8LeYo=; l=684; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=S1UEsjROvgTboWy0RED+GDTJPBx+XD98hXksQxeAxfdMmECifHi/AWRKz37HPhyu8 mYEzrpuPLMi51ORkiWkMUulZumHujpl2rAsj+nRZ9n7qmeZKEP3VachRlfjobWs+bx iIEf1LXsD05QsAZgCfm1FAovN1MFoElqZYr+/gsU= 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, 17 Aug 2012 09:32:01 +0200 id 00000000005DC035.00000000502DF371.00007FBB Message-ID: <502DF370.2010203@tana.it> Date: Fri, 17 Aug 2012 09:32:00 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <1358347.VdGSBTFpxD@scott-latitude-e6320> In-Reply-To: <1358347.VdGSBTFpxD@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 07:32:05 -0000 On Thu 16/Aug/2012 21:01:01 +0200 Scott Kitterman wrote: > On Thursday, August 16, 2012 08:58:31 PM Alessandro Vesely wrote: >>> In particular, in this revision there is more discussion about >>> redirect and why it is useful. >> >> The redirect modifier has nothing to do with issue #12. > > In issue #12 it says: > > "We should encourage the use of _spf labels and redirect= for > designing sound and maintainable SPF compliance." A sound SPF compliance is a prerequisite. Redirect allows maintainability, hence is necessary. > So I'm a bit confused why you say it's unrelated. Yes, you're right, sorry. I should have said "has /little/ to do with issue #12". From hsantos@isdg.net Fri Aug 17 02:14: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 5AB4321F84E1 for ; Fri, 17 Aug 2012 02:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifq07efjgHd0 for ; Fri, 17 Aug 2012 02:14:31 -0700 (PDT) Received: from listserv.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD721F84DD for ; Fri, 17 Aug 2012 02:14:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4593; t=1345194860; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=tWRrr7EwKxwady4jvDrltURBwmY=; b=K12Q1H8kYQjZxTrYo09T BihxyvBZ7jh+onJwUd0+H+UwUWzvfwbVyviq3SSAlw6V48B2w/zGpApexUWjpg4p GiauGkja081V3Fa2fO3J+mApzEz3KwEJ59hUPCNcw18818HX0Tr/zSCN7eRM2WrZ uf5XIyef+cc2fE8qV7zuB2o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 05:14:20 -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 1216663007.22748.4348; Fri, 17 Aug 2012 05:14:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4593; t=1345194679; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=F0MnacH faRC7jEhNM9jm/GojsN1UBJqNPiSl7tI3cyg=; b=RGYNywBaukUOwBoZHSp2+S8 k1Q1ZUJ7ZM3JYf4se347h4nKRBi/yscNQLGeBl4qmOHTmHs/a2Uf3MKVFVcxagPK jBm0gCXiWJGk5LIYmA4vDqnH4Dvm4PYh4ZCYWXCyIKyMACKiLwZJ70A1NQnxaow/ g3RKxHJRx8J8UF/YJKxg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 05:11:19 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1815477020.9.5072; Fri, 17 Aug 2012 05:11:18 -0400 Message-ID: <502E0B73.7010408@isdg.net> Date: Fri, 17 Aug 2012 05:14:27 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <20120816202808.GA24136@mx1.yitter.info> <502D6A6B.1080804@isdg.net> <1367995.li6hrOxpKc@scott-latitude-e6320> In-Reply-To: <1367995.li6hrOxpKc@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 09:14:32 -0000 Scott Kitterman wrote: > > 9.3. Receivers: This is new. I will try to be more specific with specific section #s next time. Massive changes across the doc nonetheless and no longer sure its worth the stress to go over the relatively long new set of concerns (or complaints if you wish to label it that way), I believe they are. The more important one changes (or lack there of) related to Issue 29. > So most of the change in the section you are complaining about was previously > posted here. Keep in mind that all of section 9 is non-normative. If you've > got actual suggestions to make, please make them. Vague assertions that it > could be better don't help me get this done. hmmm, I did and you made it quite apparent it would be ignored as the doc shows. My input were specific to certain things, not doc nits. For example, like issue 29, it went a different route and doesn't solve the security loophole. But you made it clear it wasn't a security issue and I strongly disagree and nonchalantly blew it aside. Various inputs regarding REJECT vs MARK, the perhaps with erroneous (IMO) beliefs of how MARK prevails over REJECT in deployments made it clear to me it is a security loophole and now a concern with watering down the publication of -ALL policies and now presenting two different paths for RFC2119 compliant REJECT language and a loophole with non-RFC2119 MARK-ON-FAIL semantics. What was apparent was the MARK "group" was HERE, in this FORA, prevailing and I felt that was an engineering error (for the SPF protocol) if it was not before defined. REJECT is clear with RFC2119 language and the essence of SPF -ALL policies. As with most things we do to not force things per se or to provide protocol features and alternatives, the deployment alternative in the protocol MUST provide at the very least the same level or equivalent security level, otherwise it presents a loophole or entry point for confusion, design complexity, problems and a minimization of problem solving (i.e. purpose is minimized). I provided text that suggest deployments MUST|SHOULD|RECOMMENDED (i prefer MUST) or essentially MUST be highly aware to separate the MARK-ON-FAIL stream from normal accepted mail streams - thats the security loophole. I provided practical product design input how it can affect backends and MUAs - offline vs online, POP3 vs IMAP, etc. In short, a deployment using MARK-ON-FAIL, even if its (erroneously) prevailing in this group, they must be made aware to separate the stream (negatively classify it, isolate, etc) and that may be site specific and/or user connectivity specific. If he reads mail online (HTML, IMAP, etc) and that may be part time, full time), the backend can better handle the MARK-ON-FAIL status message. If he reads mail offline, via POP3, the backend MUST be aware again to separate the MARK-ON-FAIL messages form the normal new mail stream. In general, for any mail reading portal access, the backend offers MUST deal with MARK-ON-FAIL to offer the same level or equivalent of user protection that a SMTP level REJECT-ON-FAIL offers users. We are talking about user level vs system level filtering at this point and IMV, SPF caters to the latter but can work with the former IFF the security offering is the same. I provided some started text - ignored. I could care less how its stated, but it shouldn't be ignored and thrown side as irrelevant input. However, I will note when Issue 29 was finally added to the tracker with a reference message that was not what I expected. I felt maybe that it was the shorter version but it was definitely not as complete as discussed in various messages: http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01486.html So I can see if it was missed because of that. Yet, maybe the issue text was sufficient, I waited but eventually saw it was closed and when noted, you said it wasn't an security issue. I disagree. The spec should via clear what design options need to be considered when alternatives are offered, especially when one is very simple, clear (REJECT) with RFC2119 language and the other (MARK) is left open ended with no RFC2119 language. There are other change I think need to be reviewed, but this issue was long undue and the more critical one IMO from other things. The leap to section 9 from section 2.5.4 should be more clear as the alternative deployment option implementators need to consider in their code. -- HLS From spf2@kitterman.com Fri Aug 17 06:56: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 68DAD21F846F for ; Fri, 17 Aug 2012 06:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvCFowYytNhY for ; Fri, 17 Aug 2012 06:56:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4359021F8449 for ; Fri, 17 Aug 2012 06:56:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4E2BC20E4085; Fri, 17 Aug 2012 09:56:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345211767; bh=ZP4d7y9kWTHd988osl3rT/RnMy45OPQWvmxvO+1YP0o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=m4A6qw/MtBfUjEpEYujJgLybLoFIr52GURgLSDH2Z0GZnjwv1SsBkn3jQ/ZF03mLo Q3/73xPhfjD6MJg7WPT7dVI2IPwEQ1/to/FfrWYCgRZq9rVgBPyfkaDXQ4SENsJr2m iHFcC6W0gYuavEXU9cRZ+9GtH9brA+P1jwdl2ob8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 251C320E4077; Fri, 17 Aug 2012 09:56:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 09:56:06 -0400 Message-ID: <2822506.PhvcAck8hS@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502E0B73.7010408@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <1367995.li6hrOxpKc@scott-latitude-e6320> <502E0B73.7010408@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 13:56:09 -0000 On Friday, August 17, 2012 05:14:27 AM Hector Santos wrote: > Scott Kitterman wrote: > > 9.3. Receivers: This is new. > > I will try to be more specific with specific section #s next time. > Massive changes across the doc nonetheless and no longer sure its > worth the stress to go over the relatively long new set of concerns > (or complaints if you wish to label it that way), I believe they are. > The more important one changes (or lack there of) related to Issue 29. > > > So most of the change in the section you are complaining about was > > previously posted here. Keep in mind that all of section 9 is > > non-normative. If you've got actual suggestions to make, please make > > them. Vague assertions that it could be better don't help me get this > > done. > > hmmm, I did and you made it quite apparent it would be ignored as the > doc shows. My input were specific to certain things, not doc nits. > For example, like issue 29, it went a different route and doesn't > solve the security loophole. > > But you made it clear it wasn't a security issue and I strongly > disagree and nonchalantly blew it aside. Various inputs regarding > REJECT vs MARK, the perhaps with erroneous (IMO) beliefs of how MARK > prevails over REJECT in deployments made it clear to me it is a > security loophole and now a concern with watering down the publication > of -ALL policies and now presenting two different paths for RFC2119 > compliant REJECT language and a loophole with non-RFC2119 MARK-ON-FAIL > semantics. What was apparent was the MARK "group" was HERE, in this > FORA, prevailing and I felt that was an engineering error (for the SPF > protocol) if it was not before defined. SPF was designed for SMTP time rejection. I know that. I was there when it happened. I've distributed software for half a decade that by default rejects on fail during the SMTP session. Whoever that "MARK 'group'" (sic) is, I'm not in it and I'm the one that wrote the words you're apparently unhappy with, so please lay off the conspiracy theories and give me something I can work with. > REJECT is clear with RFC2119 language and the essence of SPF -ALL > policies. As with most things we do to not force things per se or to > provide protocol features and alternatives, the deployment alternative > in the protocol MUST provide at the very least the same level or > equivalent security level, otherwise it presents a loophole or entry > point for confusion, design complexity, problems and a minimization of > problem solving (i.e. purpose is minimized). > > I provided text that suggest deployments MUST|SHOULD|RECOMMENDED (i > prefer MUST) or essentially MUST be highly aware to separate the > MARK-ON-FAIL stream from normal accepted mail streams - thats the > security loophole. I provided practical product design input how it > can affect backends and MUAs - offline vs online, POP3 vs IMAP, etc. I attempted to address this in -04. There was a LOT of email to go through when I was preparing it and it is quite likely I missed something. Please give me a pointer to the text in the archive or resend it. I can assure you I didn't intentionally ignore any useful input. > In short, a deployment using MARK-ON-FAIL, even if its (erroneously) > prevailing in this group, they must be made aware to separate the > stream (negatively classify it, isolate, etc) and that may be site > specific and/or user connectivity specific. If he reads mail online > (HTML, IMAP, etc) and that may be part time, full time), the backend > can better handle the MARK-ON-FAIL status message. If he reads mail > offline, via POP3, the backend MUST be aware again to separate the > MARK-ON-FAIL messages form the normal new mail stream. In general, > for any mail reading portal access, the backend offers MUST deal with > MARK-ON-FAIL to offer the same level or equivalent of user protection > that a SMTP level REJECT-ON-FAIL offers users. We are talking about > user level vs system level filtering at this point and IMV, SPF caters > to the latter but can work with the former IFF the security offering > is the same. I can see this, but at the same time if a receiver it is marking and delivering mail it is because they want that mail to be available in some manner to the end user, so it is inherently not the same. Security is never binary. It is always a trade between risk and benefit. Marking and delivering has the risk that something 'bad' will be delivered. It also has the potential benefit that something otherwise desirable will be delivered. Any language we include (and I could see possibly adding more information about this - although we need to avoid providing an MUA design tutorial) needs to recognize this trade off and provide useful guidance for receivers and implementers. > I provided some started text - ignored. I could care less how its > stated, but it shouldn't be ignored and thrown side as irrelevant input. As I said, I didn't intentionally ignore anything from you. If you have something to add, please provide it or a pointer to it and it won't be just ignored. > However, I will note when Issue 29 was finally added to the tracker > with a reference message that was not what I expected. I felt maybe > that it was the shorter version but it was definitely not as complete > as discussed in various messages: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg01486.html > > So I can see if it was missed because of that. Yet, maybe the issue > text was sufficient, I waited but eventually saw it was closed and > when noted, you said it wasn't an security issue. You are entitled to your own set of opinions, but not your own set of facts. See http://tools.ietf.org/wg/spfbis/trac/ticket/29. The issue is not closed. In fact, the last thing I wrote in the tracker was: > New text in the -04 draft should address this issue. > > Waiting for WG review. So not only is it not closed, it is explicitly waiting for people to comment on it so we can improve it. > I disagree. The spec should via clear what design options need to be > considered when alternatives are offered, especially when one is very > simple, clear (REJECT) with RFC2119 language and the other (MARK) is > left open ended with no RFC2119 language. I think the text in -04 does exactly this. Here's what it says on this exact issue: > 9.3.2. Policy For SPF Fail > > SPF fail results can be used to reject messages during the SMTP > transaction based on either RFC5321.MailFrom or RFC5321.HELO/.EHLO > identity results. This reduces resource requirements for various > content filtering methods and conserves bandwidth since rejection can > be done before the SMTP content is transferred. It also gives > immediate feedback to the sender who might then be able to resolve > the issue. Due to some of the issues described above in this > Section 9 section, SPF based rejection does present some risk of > rejecting legitimate email when rejecting based on RFC5321.MailFrom > results. > > SPF fail results can also be used as one input into a larger set of > evaluations which might, based on the overall evaluation result in > the email being marked negatively in some way (this might be via > delivery to a special spam folder, modifying subject lines, or other > locally determined means). Developing the details of such an > approach have to be based on local conditions and requirements. > Using SPF results in this way does not have the advantages of > resource conservation and immediate feedback to the sender associated > with SMTP rejection, but could produce fewer undesireable rejections > in a well designed system. > > Either general approach can be used as they both leave a clear > disposition of emails. They are either delivered in some manner or > the sender is notified of the failure. Other dispositions such as > "dropping" or deleting email after acceptance are inappropriate > because they leave uncertainty and reduce the overall reliabilility > and utility of email across the Internet. I attempted to provide a balanced view of the advantages and disadvantages of either approach. If you think it needs improvement, please provide text. At this point "I think it should X" is not very helpful. I believe I understand what you think it should do and have attempted to accommodate that. If you think it should be different, I need exact text as I'm already doing the best I can without it. > There are other change I think need to be reviewed, but this issue was > long undue and the more critical one IMO from other things. The leap > to section 9 from section 2.5.4 should be more clear as the > alternative deployment option implementators need to consider in their > code. Please provide text. Scott K From agthisell@yahoo.com Fri Aug 17 06:58: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 824D421F8526 for ; Fri, 17 Aug 2012 06:58: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSkJDVHKPLLl for ; Fri, 17 Aug 2012 06:58:19 -0700 (PDT) Received: from nm31-vm5.bullet.mail.ne1.yahoo.com (nm31-vm5.bullet.mail.ne1.yahoo.com [98.138.229.45]) by ietfa.amsl.com (Postfix) with SMTP id DBC7921F84D1 for ; Fri, 17 Aug 2012 06:58:18 -0700 (PDT) Received: from [98.138.90.55] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 13:58:13 -0000 Received: from [98.138.87.9] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 13:58:13 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 17 Aug 2012 13:58:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 798466.69659.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 29247 invoked by uid 60001); 17 Aug 2012 13:58:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345211893; bh=9jzDstF3V3EqwD/oGGSiWJvsIfNCiSVfmFDdcNGmX2c=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=kuEWdfKwCLaq2yag/uZAuOJ26bPGPHU/Uox/HYqgIhk/vdGdK4C0f1sWmENCp+13bNKplik+GhlDdYsoM5w0oeWEKnowE0EI2Uywr0Qob5L+n+xFwkueAIB13ftjUZlMKC1jzPoer5cKx2369fKIB5sDNFXw1fDZTKjJmQ/TnA8= 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=1n9GjBWzuCxJ9E2xJKKRR6WaBuzEEXvSW0776uUjS1sMMffsrdmaWkXSNYeFihOxYAw6U8FmPrFY5+4NwmpxTgPbFx//L+CjcUF2JRUhelKrUnEtbIsNrw+amJF+JLoceZ66cjuFDC9+NCOKfNXEWNE0dwu9aDuD20zVpBjWxTc=; X-YMail-OSG: Nz2dpDoVM1nudjRMproNdGHru94Zeq2tWgR2IxFqWlyO85Y dM7IJH.U2bWhAXeuP5hKysIyM4Qq7aFLNhqIofbSzwIkYH203kFHonvTqYhn MmFlafRIulS5YXBQziaHSxqoHtMjSja56GamTwArISiSC3BUwvMo9b6415SV WXsaekL1kgHn49z7SAlmS9d3CYypBWE3ZSK8xxxSW_magTl_v8qWyxEsnRPo 8brUmYzNsbI4zwrTB2hhrENrs.wgpZvqf7sM4bektNwK.yB2p1LO86YJB_k2 HlombODIpc6IS2tABrSM_6MKQhMvdDnq5ZD21CV2kKk70E002Z2zDP13.XYx d0xREIUWWeGmnwgAstCOSuGpA5Ctj37rT6BErfSaKXtAI6FuqtDn.9XJOEh0 Ue_Rck.juabcLpU9wa7yEAL1GbweShoFTvg_yn8LsWMO.g0QBkV21ZcQmIDt mpDBOY3AndoCvOfB1.PvAWbpOTkXH8532yQCKr76Hd0xFRBzsYWA2sSPdUhK wXJtxYCqMy_n7B4y2DiyE Received: from [71.61.133.134] by web125402.mail.ne1.yahoo.com via HTTP; Fri, 17 Aug 2012 06:58:13 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1345211893.26649.YahooMailClassic@web125402.mail.ne1.yahoo.com> Date: Fri, 17 Aug 2012 06:58:13 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 13:58:19 -0000 > The macro ABNF does not in itself limit macro expansion so that it > results in a valid domain-spec. Nonsense such as this is permitted: > > %{s.-+,/_=.+,..+.} > > Just because the macro ABNF allows it, does not make it valid. The > result of macro expansion MUST still be a valid domain-spec. I don't understand this section. The macro %{s.-+,/_=.+,..+.} is perfectly valid, although having multiple identical split delimiters is redundant. It says to take the , split it into multiple parts based on the characters ".-+_=", and then glue them back together with dots. As far as being a valid domain-spec, that is bogus. A domain-spec, as defined in the I-D can have macros that are substituted, but SPF doesn't do recursive macro expansion. As far as whether the result is a valid domain name, that is spelled out a few paragraphs above where it says "When the result of macro expansion is used in a domain name query, ...". It doesn't matter if the result isn't a valid host name, the DNS allows for 8-bit data in labels, except \0. Some of the DNS RFCs even give examples of such, and you can enter these labels in bind-format zone files. It may well be that a particular site has valid local parts that can't easily be put into the DNS or queried or due to the "case insensitive" nature of the DNS, multiple EAI local-parts map into a single DNS label. If such is the case, those sites should not use macros that use the local-part. I understand the problem with SPF allowing people to shoot themselves in the foot. I understand that marcos are, in general, not used much, and bugs in the SPF library, the OS (gethostbyame), etc. can easily lurk in little used areas. I understand that things evolve and things that could be done in the past can no longer be used most of the time. If we were designing a new protocol, or a new version of SPF, I would be quite open to the idea of getting rid of or restricting macros, but we aren't. There are some things, such as exist:${ir}._spf.example.com that have to be used if the number of ip addresses that a ADMD uses exceeds all other encoding methods. Arguing that macros can be gotten rid of because there aren't many of them would be like arguing that since there are only 13 root name server IP addresses, we can get rid of root name servers. From spf2@kitterman.com Fri Aug 17 07:23: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 2588621E8043 for ; Fri, 17 Aug 2012 07:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVPO0bi8P9aV for ; Fri, 17 Aug 2012 07:23:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05411E8099 for ; Fri, 17 Aug 2012 07:23:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E1AE620E4085; Fri, 17 Aug 2012 10:23:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345213400; bh=siMDWcmaYpx1R2CHhMhWY1WfJSV55pdj70Agz4pTZwE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ASjcYlHgMHZBaHa4fjHYqwPMKz18b/5Zg2d+jGO1MFCuZQpOFwEQxn2eLhulUYZDx LAJw30RIJlsVWPXMWkZADLbG8kD1duwGNQneoHpAETqFyiEfxt2s+Ks0PedmM5bsZa Q1WOWheKctg9pXwqcf3f51amPyqhLU53HyWFnm24= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B602820E4077; Fri, 17 Aug 2012 10:23:20 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 10:23:19 -0400 Message-ID: <2046753.vHlFavQQNg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1345211893.26649.YahooMailClassic@web125402.mail.ne1.yahoo.com> References: <1345211893.26649.YahooMailClassic@web125402.mail.ne1.yahoo.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 14:23:22 -0000 On Friday, August 17, 2012 06:58:13 AM Arthur Thisell wrote: > > The macro ABNF does not in itself limit macro expansion so that it > > results in a valid domain-spec. Nonsense such as this is permitted: > > > > %{s.-+,/_=.+,..+.} > > > > Just because the macro ABNF allows it, does not make it valid. The > > result of macro expansion MUST still be a valid domain-spec. > > I don't understand this section. The macro %{s.-+,/_=.+,..+.} is perfectly > valid, although having multiple identical split delimiters is > redundant. It says to take the , split it into multiple parts > based on the characters ".-+_=", and then glue them back together with > dots. > > As far as being a valid domain-spec, that is bogus. A domain-spec, as > defined in the I-D can have macros that are substituted, but SPF doesn't do > recursive macro expansion. > > As far as whether the result is a valid domain name, that is spelled out a > few paragraphs above where it says "When the result of macro expansion is > used in a domain name query, ...". It doesn't matter if the result isn't a > valid host name, the DNS allows for 8-bit data in labels, except \0. Some > of the DNS RFCs even give examples of such, and you can enter these labels > in bind-format zone files. It may well be that a particular site has valid > local parts that can't easily be put into the DNS or queried or due to the > "case insensitive" nature of the DNS, multiple EAI local-parts map into a > single DNS label. If such is the case, those sites should not use macros > that use the local-part. OK, so I got that bit a bit wrong (as well as the localpart/EAI text). Thanks. I think I can safely delete this addition. Please suggest appropriate text for the last sentence of the paragraph in section 8.1 that discusses the "s", "l", and "o" macros. I'm not sure how to put it. Scott K From johnl@iecc.com Fri Aug 17 10:11: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 1E4ED11E80A5 for ; Fri, 17 Aug 2012 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.145 X-Spam-Level: X-Spam-Status: No, score=-111.145 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms6jteIbD4uV for ; Fri, 17 Aug 2012 10:11:33 -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 8195811E809B for ; Fri, 17 Aug 2012 10:11:32 -0700 (PDT) Received: (qmail 69495 invoked from network); 17 Aug 2012 17:11:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Aug 2012 17:11:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=502e7b43.xn--9vv.k1208; i=johnl@user.iecc.com; bh=VhB3ocPe6qrDrDjqNhUvq1+/B96lPwnptRYQoyu80bY=; b=End/8bHCDZ82TqYXWQfVsJ5Mz7O8eDdwXQzOFreI2q0w/+xCjzySidmK1XrxknaBnjgt+rmAgZYXFsqF1+8Da/Vk4n6k/GHV+hMl0Rc5lNS8lR9By6EhLmVBgzMLku1x1MEClFHc/VLpXVqXIK/u9F7iNDU7Q/U0QzLwdBkVWXk= 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=502e7b43.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=VhB3ocPe6qrDrDjqNhUvq1+/B96lPwnptRYQoyu80bY=; b=Nsf/usZ7k05Nz0pGehG5HDbFVQurT7tbMq3S+1lNKXnMZxBR6dOnXqn1V14kevSnm2KAN2aX8GXsskUtQOiurfn1ECBw1IPJ1+tFK9Zq4BW9j9IgaiMJ2VX+fvqjO5R4YO//u2QNS8n3K+5ukeUvykAYQ+xo7lUpXwba4/Zk7vM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Aug 2012 17:11:09 -0000 Message-ID: <20120817171109.2800.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2046753.vHlFavQQNg@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 17:11:35 -0000 >OK, so I got that bit a bit wrong (as well as the localpart/EAI text). >Thanks. I think I can safely delete this addition. Please suggest appropriate >text for the last sentence of the paragraph in section 8.1 that discusses the >"s", "l", and "o" macros. I'm not sure how to put it. The point is that those macros can allow hostile senders to inject arbitrary character strings into the names in DNS queries. So you better be sure that the libraries that handle the queries don't assume that the names are well formed, or consist only of printing ASCII characters. If you want to mention EAI, note that an EAI address consists of an arbitrary UTF-8 mailbox and a domain which may be a U-label (UTF-8) or A-label (punycoded.) For %o it would probably be a good idea to convert U- to A-labels before lookup. But other than that, addresses can and probably will contain characters that are difficult or impossible to provision in DNS software, so don't use %s or %l in expansions that are intended to produce names to be looked up. R's, John From hsantos@isdg.net Fri Aug 17 10:29: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 489EC11E80A5 for ; Fri, 17 Aug 2012 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrgoF9lHkA6X for ; Fri, 17 Aug 2012 10:29:57 -0700 (PDT) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD6911E809B for ; Fri, 17 Aug 2012 10:29:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1363; t=1345224587; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=L/TB6y/0R9z3Bt16erMBlcZSuDM=; b=lL+6YkemKXmiLEhZUgIH sjqec9i8V4e0I4FMq8CQbIV5nJN3G1IIH47g0wAQ6sQAHwxu2wnYwqx7B2R7v62E 3QkBQeeQvLj8hDCb6jXPLBfynKyM2CEbMzt+rZ5pdFBoJxrFIeuuICUzVZETUSvb wrgKHJ/H04ilEuls3SCk7Cw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 13:29:47 -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 1246389622.22748.3640; Fri, 17 Aug 2012 13:29:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1363; t=1345224403; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ySXa0dv j5cdIoRYYWat9MoThys/dwC2Ti6buSmvYDAI=; b=ysQjfzezMeN6yVcRr1eh5B+ l3J5ugsQWPuKFKSVLBmyestCLXCWavFFNgOAj/EjSzX8M/vf5s/mtCafLvc/N8DI 9DoA6pmGNkdmA8sn6ftGaO3e/MKMHjSY6zWdJk7ibOmMKveAc3DQbCS5jCLrktWq Rekf8GVpTbq4v1AWwUAg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 13:26:43 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1845201114.7.7724; Fri, 17 Aug 2012 13:26:42 -0400 Message-ID: <502E7FC7.9020701@isdg.net> Date: Fri, 17 Aug 2012 13:30:47 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <1367995.li6hrOxpKc@scott-latitude-e6320> <502E0B73.7010408@isdg.net> <2822506.PhvcAck8hS@scott-latitude-e6320> In-Reply-To: <2822506.PhvcAck8hS@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 17:29:58 -0000 Scott Kitterman wrote: >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01486.html >> >> So I can see if it was missed because of that. Yet, maybe the issue >> text was sufficient, I waited but eventually saw it was closed and >> when noted, you said it wasn't an security issue. > > You are entitled to your own set of opinions, but not your own set of facts. > See http://tools.ietf.org/wg/spfbis/trac/ticket/29. The issue is not closed. Changing perceptions is not something you need to do. Issue 29 has not been addressed because it was indicated as CLOSED. If it was reopen as requested, then you have new facts. I don't wish to waste time going over this with discussions of SM, with direct email to you questioning why it was closed and your eventual posting that it was not a security problem, rude post I may say, then yes, we have a new set of convenient facts you wish to portray. No problem. >> There are other change I think need to be reviewed, but this issue was >> long undue and the more critical one IMO from other things. The leap >> to section 9 from section 2.5.4 should be more clear as the >> alternative deployment option implementators need to consider in their >> code. > > Please provide text. See above links. -- HLS From spf2@kitterman.com Fri Aug 17 11:13: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 1377E21E8045 for ; Fri, 17 Aug 2012 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPiwyn2dS7PH for ; Fri, 17 Aug 2012 11:13:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2E111E809B for ; Fri, 17 Aug 2012 11:13:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1589420E4091; Fri, 17 Aug 2012 14:13:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345227221; bh=c64FaPg13GKPeRv57XjhXSxllTpF9sgU12xaHMz1CU8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nZ3fEi+pb1wxyJPM6tBOTsjXhNKpSSVkgN7l0NljDUcDJyY4KTWH12l2MPTLZzT7x 2ascMIfBa7MXEp6twuiuZDE2h60TqmPmCjUbATNcS82k+KvzNG+hNWmD0tIP2hQWiL myshpbX0C+0+sKsvy+XQcAuWQ4zZLj6DWRGb09bU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E291620E4085; Fri, 17 Aug 2012 14:13:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 14:13:39 -0400 Message-ID: <4206191.rMJEy9IeT9@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502E7FC7.9020701@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2822506.PhvcAck8hS@scott-latitude-e6320> <502E7FC7.9020701@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 18:13:43 -0000 On Friday, August 17, 2012 01:30:47 PM Hector Santos wrote: > Scott Kitterman wrote: > >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html > >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01486.html > >> > >> So I can see if it was missed because of that. Yet, maybe the issue > >> text was sufficient, I waited but eventually saw it was closed and > >> when noted, you said it wasn't an security issue. > > > > You are entitled to your own set of opinions, but not your own set of > > facts. See http://tools.ietf.org/wg/spfbis/trac/ticket/29. The issue is > > not closed. > Changing perceptions is not something you need to do. Issue 29 has > not been addressed because it was indicated as CLOSED. If it was > reopen as requested, then you have new facts. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29 gives the change history. I get you think it was closed, but the history clearly shows it isn't and never was. > I don't wish to waste time going over this with discussions of SM, > with direct email to you questioning why it was closed and your > eventual posting that it was not a security problem, rude post I may > say, then yes, we have a new set of convenient facts you wish to > portray. No problem. Meh. It's not the main point, so whatever. > >> There are other change I think need to be reviewed, but this issue was > >> long undue and the more critical one IMO from other things. The leap > >> to section 9 from section 2.5.4 should be more clear as the > >> alternative deployment option implementators need to consider in their > >> code. > > > > Please provide text. > > See above links. I see there is text in the second link there that's relevant to this issue that I did, indeed, miss: > NEW: > A "Fail" result is an explicit domain policy violation statement that > the client is not authorized to use the domain in the given identity. > > When the result is a "Fail", the checking software MUST offer local > receiver SPF deployments the option to choose between marking and > classifying > > (MARK-ON-FAIL) the the message having failed the domain SPF policy or > rejecting the mail outright (REJECT-ON-FAIL). > > When the REJECT-ON-FAIL option is used, the SMTP server MUST reject the mail > during the SMTP transaction and it SHOULD issue a permanent rejection reply > code of 550 and for servers supporting extended reply code [RFC3463], use a > policy based rejection description subject sub-code of 5.7.1. The following> > are some examples of REJECT-ON-FAIL server responses: > 550 SPF MAIL FROM check failed: > 550-5.7.1 SPF MAIL FROM check failed: > 550-5.7.1 The domain example.com explains: > 550 5.7.1 Please see http://www.example.com/mailpolicy.html > > When the MARK-ON-FAIL option is used, it server SHOULD report this failure > by adding a Receiver-SPF header to the received message. See Section 7. > > The REJECT-ON-FAIL should be regarded a System Level local policy for global > filtering for all users, where the MARK-ON-FAIL should be regarded as a > User Level Policy framework where good vs bad mail is separated for the > user. The first question is what belongs in Section 2 (normative protocol) versus Section 9 (non-normative advice). I don't see benefit in making MUST mark or reject part of the protocol as what you're calling REJECT-ON-FAIL and MARK-ON- FAIL are really the only two options, so I think it's not necessary for it to be normative. MUST do one of the only two choices isn't needed. I think that your suggestion to add a SHOULD add a header field if marking is a good one. It's accurate and a good companion to the how to go about rejecting discussion that's already there. I've added words to that effect (but also including the option of authentication-results since that is now discussed in the draft) for the next update. Here's what I added: > If the checking software chooses not to reject the mail during the > SMTP transaction, then is SHOULD add a Received-SPF or > Authentication-Results header field (see target="results-headers"/>) to communicate this result to downstream > message processors. While this is true for all SPF results, it is > of particular importance for "fail" results since the message is > explicitly not authorized by the domain owner. I tried to make it parallel to what's there about rejection. I think the last bit about system level policy versus user level policy is an interesting idea. Where do you think it would fit in 9.3? I do not like the idea of introducing the all caps terms MARK-ON/REJECT-ON, so I haven't used them in my update. I think they come across as shouting and are distracting. If anyone else thinks I should, please speak up. Scott K From superuser@gmail.com Fri Aug 17 13:48: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 1267111E80DC for ; Fri, 17 Aug 2012 13:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GKXUhEIAJMe for ; Fri, 17 Aug 2012 13:48:04 -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 6589411E80D1 for ; Fri, 17 Aug 2012 13:48:04 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2442934lbb.31 for ; Fri, 17 Aug 2012 13:48:03 -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=H5jmihj0eCMnBZt+Xy4Ps64R/a4qVSzGiA7AkgOsQf0=; b=0dNQaTiIpU5jjR1tzGQVHW2SEYH84I53Y/7PAJuj7JWD/QKqNfXBsnO68r1DQx6i1Q gD7JgmdAaBriv7FefHLNttqNrADVKqddKDgtaDIOJzjIOfTEPd+U7EzIHsNUjpPKfNM8 nKS2duSU9XNYu5C8e42/SaJvDEfT3+7wK0CSOTc29M0E5M/KsZqHif1Gk4nMWZVVIhNU dP4joTus0elUHVPGJuyZWil9ypHpkZPYRZ9VR0KO7pN0MJYxTQaA8NnVkl6ph5JMJfDf f1pUfCz+FXK/5CF7xt1/cOmmdYGygBaEOFJ2xx/rcEyxrcPrd+r8rYxZRuFYJ4nvCyKB LU/g== MIME-Version: 1.0 Received: by 10.112.83.200 with SMTP id s8mr2836374lby.13.1345236483112; Fri, 17 Aug 2012 13:48:03 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 17 Aug 2012 13:48:03 -0700 (PDT) In-Reply-To: <502CED0C.8000506@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502CED0C.8000506@tana.it> Date: Fri, 17 Aug 2012 13:48:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 20:48:06 -0000 On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: > For the negative note: Is it possible to roll back that 5598-based > replacement of identity names, _please_? RFC5321.HELO/.EHLO is > excessively long and lowers the readability of the document. I don't > object on that string appearing in Section 1.3.4. After precisely > defining what HELO means, it is not necessary to repeat the whole > definition any more. I'd settle for something that makes it clear that "HELO Identity" elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), but I disagree that it's a cumbersome notation. That could just be that I'm used to it. > Furthermore, > if a claimed identity fails verification, local policy can take > stronger action against such email, such as rejecting it. > > Kudos for Section 9.3! Now that we have it, that last sentence in the > Introduction can be reworded so as to anticipate it. For example: > > Furthermore, receivers can devise local policies (Section 9.3) > in order to facilitate processing of messages that get specific > results; for example, they can whitelist domains that pass the > verification, or reject mail that fails it. I don't know that it's necessary to add that up front. Referring to Section 9.3 at this point is sufficient. > 2.3. *Publishing Authorization* > > An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3. This record authorizes the use of the domain name in > the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities by the MTAs it > specifies. > > It is possible to address compliance by ADMD, rather than by domain: > > An SPF-compliant ADMD MUST publish valid SPF records as described > in Section 3. These records authorize the use of the relevant > domain names in HELO and MAILFROM identities by the MTAs it > specifies. As above. > That way, the spec can modulate the requirements about which domains > MUST/SHOULD have an SPF record. Until the term "domain" is used > interchangeably for a DNS label or an ADMD, wording such requirements > is difficult. The goal of introducing the term "ADMD" is specifically to avoid using the terms interchangeably. > SPF results can be used to make both positive (source is authorized) > and negative (source is not authorized) determinations. If domain > owners choose to publish SPF records and want to support receivers > making negative authorization determinations, then they MUST publish > records that end in "-all", or redirect to other records that do, > otherwise, no definitive determination of authorization can be made. > > IMHO, constructs like "If you choose X then you MUST Y" are > meaningless. I'll never be able to tell whether you are compliant, > unless I have a method to determine what you chose. And since you can > always change your mind, the normative sense of the verb is completely > lost. I'm not so sure. I read that as saying "the only way to coerce rejection from a receiver willing to do so is to use -all". > 2.5.4. *Fail* > > A "fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. Disposition of > SPF fail messages is a matter of local policy. See Section 9.3 for > considerations on developing local policy. > > For the sake of clarity, cannot we say explicitly that the receiver > "MAY reject the message, according to local policy"? It is what that > paragraph is actually saying, except that we force the reader to > interpret the term "disposition". I realize that being explicit may > emphasize a weakness of SPF, which I hope we'll address later on. It would be equally correct to say "MAY keep the message, according to local policy". I think the language that's there is correct and concise, and we should leave it. > As a further point on that snippet, that "given identity" sounds > obscure. The result doesn't formally depend on which identity is > being checked. How can it not? But you could say "the identity under evaluation" or something like that. > 3. *SPF Records* > > The paragraph "Domain owners wishing to be SPF compliant [...]" is > redundant after Section 2.3. I'd strike it. +1. > In the paragraph next to it, s/in Section 3/above/. +1. > Since TXT records have multiple uses, beware of other TXT records > published there for other purposes. They might cause problems with > size limits (see Section 3.4) and care MUST be taken to ensure only > SPF records are used for SPF processing. > > I'd s/ and care MUST be taken/. Verifiers MUST take care/. Meh. Take it or leave it. > 3.3. *Multiple Strings in a Single DNS record* > > As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > record (either TXT or SPF RR types) can be composed of more than one > string. > > s/[RFC1035] sections 3.3.14 and 3.3/Section 5.1 of [RFC1035]/ Nope. Section 5.1 talks about the zone file format. SPF receivers don't get zone files, they get raw DNS data. The Section 3 references are correct. > Remove the parenthesized phrase. +1. > 3.4. *Record Size* > > Why would TCP be less reliable than UDP? It's not uncommon for operators, out of ignorance, to interfere with DNS over TCP because the need for that fallback is historically rare. There were hints of this family of problems in the experiment document. > 4.6.4. *DNS Lookup Limits* > > SPF implementations MUST limit the number of mechanisms and modifiers > ("terms") that DNS lookups to at most 10 during SPF evaluation. > > s/that DNS lookups/that cause any DNS query/ if it would make for > better English. +1. > 5.1. *"all"* > > Any "redirect" modifier (Section 6.1) has > MUST be ignored when there is an "all" mechanism in the record. > > s/has // +1. > 5.5. *"ptr" (deprecated)* > > I like the numbered algorithm. It's more readable. > > Does the grammar allow "ptr:example.com/24"? Step 4 doesn't seem to > allow fuzzy IP comparisons based on given CIDR-length. I don't believe the grammar does allow that. > Another question: If there was a {temp/perm}error while doing an A RR > lookup, and then the mechanism failed to match, MAY a {temp/perm}error > be returned instead of non-match? Section 4.4 should make it clear that it's only talking about the outermost TXT query in the second paragraph. Section 4.6.2 doesn't actually say what to do in a parent evaluation when a child mechanism is being evaluated and the child throws an exception; does this exception propagate upward and terminate the entire evaluation, or does processing continue? > 7. *Recording The Result* > > It is RECOMMENDED that SMTP receivers record the result of SPF > processing in the message header. There are two methods for doing > this: the Received-SPF Header Field defined here and the more generic > Authentication-Results Header Field defined in [RFC5451]. Because > these fields are generally used within a receiving ADMD, it is a > local policy choice which to include. In general, the more broadly > applicable Authentication-Results Header Field ought to be used, but > it SHOULD provide the same information as if a Received-SPF Header > Field were used. > > Is there a reason why "Header Field" is capitalized that way? It should be lowercased. > I don't think we can be normative-by-cmparison on what information is > actually put on the field, because we don't know which tags would have > been filled in the Received-SPF field if the latter were used. For an > alternative wording: > > In general, the more broadly applicable Authentication-Results header > field ought to be used, as long as it can convey the same > information that the verifier would have written in a Received-SPF > header field if the latter had been used. s/as long as it can convey/in such a way that it conveys/ > The next paragraph should be split in two: +1. > See above for the "If ... SHOULD". I'd propose: > > An SMTP receiver SHOULD use one and only one of these header fields. > In case both of them are used, they MUST be consistent with one > another. "one" is enough; "one and only one" is too wordy. That's fine otherwise. > Note that A-R can convey results for multiple identities within a > single header field, so it doesn't make much sense to require to use > two of them. +1. > 7.2. *SPF Results in the Authentication-Results Header Field* > > We need to discuss this further: > > Why "Authserv-id SHOULD be the name of the receiving host performing > the check"? What if the check is performed by a different host, or > the host has multiple names? Being consistent with the corresponding > Received: field seems to be a good idea, but then RFC 5451 allows > different strategies. I agree; RFC5451 says use of the hostname or ADMD domain name is common, but not necessary. It also doesn't say anything at all about coordinating with Received:, but that seems a sensible thing to do. > Why overload the "reason" tag? RFC 5451 is extensible and this spec > may add any missing tags. What would you do with the client IP address as its own dedicated part of an A-R header field? This was a matter of substantial debate during RFC5451's development. If all you want to do is log it or include it in Received: fields for information, doing it in CFWS is fine. It's useful to register tags of this nature only if something will extract that value and attempt to do something more with it. In the case of DKIM, for example, one might extract the signing domain, compare it to the From: domain, and decide to do something special with message presentation there. But providing the IP address, something the user never sees, doesn't seem to be a useful thing to do. The argument back then is that one might want to evaluate SPF again at the MUA, but there was no support for that and plenty against it. That's why we didn't do that in the first place. > 8.1. *Macro Definitions* > > Implementations SHOULD be aware that if no directive processed during > the evaluation of check_host() contains an "s", "l", "o", or "h" > macro, then the results of the evaluation can be cached on the basis > of and alone for as long as the shortest Time To Live > (TTL) of all the DNS records involved. > > "SHOULD be aware" doesn't mean anything to me. I'd make it non-normative. +1. > 9.1.3. *Bounces* > > Zone file generation for > significant numbers of hosts can be consolidated using the redirect > modifier and scripted for initial deployment. Administrators might > alternatively consider publishing an SPF for *.domain (wildcard > domains) in that case if the involved hostnames do not have already > any other DNS record. > > I'd strike the last sentence, or at least recall that wildcard records > are discouraged and provide a link to Section 3.5. Indifferent on that suggestion. > Further advice is needed for scripting the zone. For example, mention > that any host that has an IP address is a good candidate for an SPF > record; those that do send mail really deserve one; and so forth. > Should we provide a Perl script in an appendix? I don't want to stray too far into operational advice. We're simply describing an algorithm here. The further we go into operational stuff, the more complex this all gets. Including anything more than pseudocode needs to be very carefully considered. > 9.2.4. *MTA Relays* > > For mail senders, this means that published SPF records must > authorize any MTAs that actually send across the Internet. Usually, > these are just the border MTAs as internal MTAs simply forward mail > to these MTAs for delivery. > > I believe the last word should be "relaying". +1. > *Last and least* > > I counted 13 occurrences of "SPF client(s)". Since an SPF client is > likely an SMTP the server, that term may be confusing. How about > using "SPF verifier(s)" instead? +1. -MSK From prvs=569952660=fmartin@linkedin.com Fri Aug 17 14:08: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 C31FE21E804C for ; Fri, 17 Aug 2012 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0SHFYtSJASl for ; Fri, 17 Aug 2012 14:08:06 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id E66CE11E80D1 for ; Fri, 17 Aug 2012 14:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1345237686; x=1376773686; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UivQXRANUytgfQ7fVMj08KGO5BGHF3bfTS7zP5Ig4Mo=; b=hGwnN/nuQ6iYIuE9/zmyB9eTx/6yWyMAkwvpQ8j75xDmR9aMbvHwmyTU I1Dv3oTEV61KAHU075Ztw+Dpd70q7rJ6NsCMv8OROLSo5Nq3++HJvVabT xHLZLN2GhMNc4mjeJkHCBhLt/XXMiarB9rrJGSixcbWZH7zIJ5wJedV/R k=; X-IronPort-AV: E=Sophos;i="4.77,785,1336374000"; d="scan'208";a="23490299" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 14:07:42 -0700 From: Franck Martin To: "Murray S. Kucherawy" , Alessandro Vesely Thread-Topic: [spfbis] 4408bis update Thread-Index: AQHNe3t7c5GzudzU8EOvpP2RAHS5Cpdc2l0AgAIXNYD//5A3gA== Date: Fri, 17 Aug 2012 21:07:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <0458500C9992074C9A869D8AD2D54F19@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 21:08:07 -0000 On 8/17/12 1:48 PM, "Murray S. Kucherawy" wrote: >On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: >> >> 9.1.3. *Bounces* >> >> Zone file generation for >> significant numbers of hosts can be consolidated using the redirect >> modifier and scripted for initial deployment. Administrators might >> alternatively consider publishing an SPF for *.domain (wildcard >> domains) in that case if the involved hostnames do not have already >> any other DNS record. >> >> I'd strike the last sentence, or at least recall that wildcard records >> are discouraged and provide a link to Section 3.5. > >Indifferent on that suggestion. > >> Further advice is needed for scripting the zone. For example, mention >> that any host that has an IP address is a good candidate for an SPF >> record; those that do send mail really deserve one; and so forth. >> Should we provide a Perl script in an appendix? > >I don't want to stray too far into operational advice. We're simply >describing an algorithm here. The further we go into operational >stuff, the more complex this all gets. Including anything more than >pseudocode needs to be very carefully considered. I like the text there, this draws the attention on bounces and similar forgotten folklore. Yes the wildcard thing is a potential issue if you do FCDNS. In rDNS it is fine. So instead mentioning wildcard, may be we could simply suggests the following simple record for each sending hostname. Hostname TXT "v=3DSPF1 a ~all" And for a non sending hostname Hostname TXT "v=3DSPF1 redirect=3Ddomain" As Murray says this go into operations, but that would cover things simply for the seasoned admin. From superuser@gmail.com Fri Aug 17 14:46: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 970EA21E805E for ; Fri, 17 Aug 2012 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19jwqXWSli3P for ; Fri, 17 Aug 2012 14:46:25 -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 8F31C11E80D1 for ; Fri, 17 Aug 2012 14:46:25 -0700 (PDT) Received: by lahm15 with SMTP id m15so2433341lah.31 for ; Fri, 17 Aug 2012 14:46:24 -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=uzXxhQRlzOqnUeeWXEUyVuNNZ9eSgN6WpugNBj2ujr4=; b=h96LA1b2yTyQqatF5tPrEBOynqF691yk/bbVemQk+WhOpUZ/7vd/zyEUt1EKlBvkJM riv7Qsd4x2JcZ3mK2dWOXkTmbhpa4VUtyCH/l0ZoDYCxQcNaD/bfBBajgjnqCTq7ALLI lh5xanPqmtkHuDgLNXJyBHm1pEsvhFdPV3Jcbgwq29OqIQrEbsKR552ihvzU8+wSVnUN gdCFne3aBmmaKev2OpFsCZgTpI5rfjdgI3i05x1zla92huABZce04mUmA5ZhYPchFE9i l37g8HZqvMupAb25t3BL6CiclBb3rQNHlm+ozsgBOpBdhZJ2AEtPEwK73hxblGMDDrTu fXaQ== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr6239386lab.43.1345239984419; Fri, 17 Aug 2012 14:46:24 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 17 Aug 2012 14:46:24 -0700 (PDT) In-Reply-To: <4206191.rMJEy9IeT9@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2822506.PhvcAck8hS@scott-latitude-e6320> <502E7FC7.9020701@isdg.net> <4206191.rMJEy9IeT9@scott-latitude-e6320> Date: Fri, 17 Aug 2012 14:46:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 21:46:26 -0000 On Fri, Aug 17, 2012 at 11:13 AM, Scott Kitterman wrote: > I see there is text in the second link there that's relevant to this issue > that I did, indeed, miss: > >> NEW: >> A "Fail" result is an explicit domain policy violation statement that >> the client is not authorized to use the domain in the given identity. >> >> When the result is a "Fail", the checking software MUST offer local >> receiver SPF deployments the option to choose between marking and >> classifying >> >> (MARK-ON-FAIL) the the message having failed the domain SPF policy or >> rejecting the mail outright (REJECT-ON-FAIL). First, I agree with Scott that we don't need to introduce these as all-caps terms. Second, I think the current text for "Fail" explains perfectly well that the option of what to do with the message is left to the receiver, as it should be. That's what "disposition" is. If we really want more discussion up in Section 2.5.x, we can make reference down to Section 9.3.2 which discusses the point in more detail. But putting more text up here clutters what is now a simple definition. >> When the REJECT-ON-FAIL option is used, the SMTP server MUST reject the mail >> during the SMTP transaction and it SHOULD issue a permanent rejection reply >> code of 550 and for servers supporting extended reply code [RFC3463], use a >> policy based rejection description subject sub-code of 5.7.1. The following> >> are some examples of REJECT-ON-FAIL server responses: I'm not liking the idea of identifying specific SMTP reply codes or enhanced status codes that should be used for SPF rejections. RFC3463 and RFC5321 already define those. We should leave that alone. If we want to give examples, that's fine, but I don't think we should be normative about it. >> When the MARK-ON-FAIL option is used, it server SHOULD report this failure >> by adding a Receiver-SPF header to the received message. See Section 7. This is covered elsewhere already. >> The REJECT-ON-FAIL should be regarded a System Level local policy for global >> filtering for all users, where the MARK-ON-FAIL should be regarded as a >> User Level Policy framework where good vs bad mail is separated for the >> user. I don't even know what the basis for this guidance is, much less that Section 2 is the right place for it. > The first question is what belongs in Section 2 (normative protocol) versus > Section 9 (non-normative advice). I don't see benefit in making MUST mark or > reject part of the protocol as what you're calling REJECT-ON-FAIL and MARK-ON- > FAIL are really the only two options, so I think it's not necessary for it to > be normative. MUST do one of the only two choices isn't needed. +1. > I think that your suggestion to add a SHOULD add a header field if marking is a > good one. It's accurate and a good companion to the how to go about rejecting > discussion that's already there. It's also a current best practice. And we even have a choice of which to use. I like the current text on that topic. > I think the last bit about system level policy versus user level policy is an > interesting idea. Where do you think it would fit in 9.3? I think at best we could discuss the notion of having the two "levels" or application points, but we need to stop short of offering advice of how it should be done unless we have substantial evidence that doing so is useful. Do such (non-anecdotal) data exist? This is Section 9 at best, if not an appendix. But overall I think it makes for more confusion for implementers to bring up this topic at all. > I do not like the idea of introducing the all caps terms MARK-ON/REJECT-ON, so > I haven't used them in my update. I think they come across as shouting and > are distracting. If anyone else thinks I should, please speak up. I agree, don't do it. -MSK From superuser@gmail.com Fri Aug 17 15:38: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 6FC2D21E808D for ; Fri, 17 Aug 2012 15:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN4gmnbfpg1R for ; Fri, 17 Aug 2012 15:38:18 -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 7908711E80D1 for ; Fri, 17 Aug 2012 15:38:18 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2482971lbb.31 for ; Fri, 17 Aug 2012 15:38:17 -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=98hF3tN7ZXxANzT4VR47v9vQomNqQAroU5G3IPnb4sI=; b=DkIjl5SZ7zIZbZnVYMJFdgJZPt1nEM4pzsad3gpS3h7NHmqcAHV2y1HggRgE+50VXV m6beezbFdbiKydUiTxV++L9q9kOEjCtSYHTuD36gYfTlbDVRVYywAEOJGfNKooODLUJd Ncg0oMMDCIRvi/0Rtc+c8Acm0mXVnarUUr93+vifhaAbA9nN9ePNF1pANVa1jEGhoHz6 m2p7Y86EmxXTlKy5CiJLNjBsJZB26TkAxOIbUrajyyRmCZl45CU1GKplese6aRXzC6P1 L4dW46uCMKp0XUlaeXou1Gk57qGQIkF08VQ/ZEWDl3/fYuZ1QuNia9/2C3OXk1KrCy8u VN3A== MIME-Version: 1.0 Received: by 10.152.110.70 with SMTP id hy6mr6321478lab.44.1345243097285; Fri, 17 Aug 2012 15:38:17 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 17 Aug 2012 15:38:17 -0700 (PDT) In-Reply-To: <502D42D7.7010900@tana.it> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> Date: Fri, 17 Aug 2012 15:38:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 17 Aug 2012 22:38:19 -0000 On Thu, Aug 16, 2012 at 11:58 AM, Alessandro Vesely wrote: > Briefly, adopting SPF implies a conundrum of endlessly repeated > philosophical principles like "No, it is the {sender|receiver} who > should do so and so." A protocol that people can adhere to should not > cause such issues, or at least indicate a quick way to solve them. I appreciate the fact that there are people out there who want the silver bullet. For some people, SPF is that. That simply is not true for everyone. I have yet to work for any company (and I now work for a pretty huge one in terms of mail flows) where either it or its customers enabled SPF to reject on "fail", for example. The common point to both of these groups is that SPF's results are input to an overall evaluation of a message. For people that think SPF completely solves the problem, their evaluation system consists solely of SPF, and they do reject-on-fail. It works for them and that's fantastic. There exists, however, a substantial population that wants more than one piece of information to decide upon the fate of a message. The most common reason for that appears to involve SPF's known failure modes, but it's not for us to speculate on what those people have in mind. However, it's important to note that the basic premise I stated above holds true for both camps. Accordingly, the best this document (or any other that specifies something which isn't a silver bullet) can do is make those data available to the operator, accompanied by some pedagogy on the surrounding subject matter, and let the operator decide what to do with it. I think that's what we're doing here, as we did with other email authentication work, and as 4408 itself did. It's the right approach. Thus, it is absolutely the case that this lands us in a space of presenting what you call philosophical principles. But I don't think we can or should do any better than that. So we simply need to do as good a job of that as possible, and then stop. So back to the topic of writing a protocol document: The protocol, then, comprises the steps to collect the inputs to the algorithm, execution of the algorithm, the output of the algorithm, and how to deal with exceptions. As my high school English teachers used to say: precise and concise. I think we're doing that here. All this stuff about doing some things as system settings and others as user settings, picking different evaluation points, rewriting envelopes and HELO, etc., really complicates what's supposed to be a protocol document. If we're seriously inclined to push all of that architecture advice on the reader, I suggest we consider moving all of that to a separate document that we develop once this one publishes and we re-charter to cover it. Or if it's already written down in an existing document, just refer to that. On the particular topic of forwarding, I think RFC5321 Section 3.9.1 is just fine. SMTP works fine the way it is with respect to alias expansion; SPF is in effect an overlay on top of it in this regard. We can say that an alias expander wishing to ensure SPF passes can do what's suggested in ticket #12, but go no further. RFC5598 talked about alias expansion in more detail if we're in need of references to more material on the topic. -MSK From spf2@kitterman.com Fri Aug 17 19:04: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 8585B21F84F3 for ; Fri, 17 Aug 2012 19:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzaaguLh68BH for ; Fri, 17 Aug 2012 19:04:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 325AB21F84F2 for ; Fri, 17 Aug 2012 19:04:04 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5ADFD20E4091; Fri, 17 Aug 2012 22:04:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345255443; bh=8a76UUBr1sSkigq+2rijEs2lcsWprD1FwlOUHSDg2GQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=d/kuGwN70WBgt5YU71k77lWsc+HtyXxCnVR3Xqk6LeTL6eMpj0lTzVFTy96zlFSKa 5BrrCTTGT2ZyweCGZz1N9AZ0kp93iPliFXwFdTLk8qwP8KAe6gwZ3QoOazWMaO5hzS 3x/IkebbgryPGbtfD4u2ZRI68pLbXJTFItg5j7dI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2AEEC20E4085; Fri, 17 Aug 2012 22:04:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 22:04:01 -0400 Message-ID: <1852776.mLCLk6b8J8@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4206191.rMJEy9IeT9@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502E7FC7.9020701@isdg.net> <4206191.rMJEy9IeT9@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 02:04:09 -0000 On Friday, August 17, 2012 02:13:39 PM Scott Kitterman wrote: > On Friday, August 17, 2012 01:30:47 PM Hector Santos wrote: > > The REJECT-ON-FAIL should be regarded a System Level local policy for > > global filtering for all users, where the MARK-ON-FAIL should be regarded > > as a User Level Policy framework where good vs bad mail is separated for > > the user. ... > I think the last bit about system level policy versus user level policy is > an interesting idea. Where do you think it would fit in 9.3? I thought about this some more and I don't think it's helpful after all. Mark/Reject can be done differently on a per-user basis. It sometimes produces odd results for multi-recipient mail, but that's manageable. There are other SMTP time tests that can be done, including, if one is so inclined content filtering and virus checks. The distinction is really a different set of design approaches. It is possible and reasonable to approach design of a "spam defense" system two different ways: 1. A system with a series of discrete steps where each step produces it's own definitive result. A message that fails any single step along the way is rejected or marked 'bad'. It might be Local IP black list check -> DNSBL check -> SPF HELO check (and there might be a whitelist that then skips some or all the rest of the checks for whiltelisted hosts) -> rDNS check -> SPF Mail From check -> anti-virus check -> anti-spam content filtering -> accepted. 2. A system where information about various attributes of the message (e.g. the results of all the above checks and more) are collected and evaluated in some weighted evaluation scheme to produce a decision about what to do with the message. The first one is easier to conceptualize, design, and implement because the problem can be trivially broken down into a series of small, largely independent efforts. The second requires more information to be collect and stored and development/testing of a complex/robust algorithm for integrating and balancing the various results. Neither one of these is inherently better than the other. When I'm doing systems work, I prefer the first kind of approach when I can get a satisfactory result. It's easier to design and to verify it's working as expected. There is no guarantee that the second 'cook it into a stew' approach will produce a better result. Given that, I don't think this kind of design philosophy has a place in 4408bis. I think we should (as I've done) try to limit ourselves to factual advantages and disadvantages of reject and mark and leave it at that. Scott K From spf2@kitterman.com Fri Aug 17 19:51:29 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 6E0CD21E8063 for ; Fri, 17 Aug 2012 19:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C09AzIKS+kIQ for ; Fri, 17 Aug 2012 19:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 89D9E21E805A for ; Fri, 17 Aug 2012 19:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C260B20E4091; Fri, 17 Aug 2012 22:51:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345258287; bh=HYi3ZrVwUA4V9N4cMDRgtbKCSZMtFmATkyudurUixno=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U1ecrHPMeG4h6Q4nW1R8uYqjHRy97lREL424c5Tgg56FPt9E3CUqmHuFt5IZRWxQW 1iuLBEuRdyxVDl8WCXh+MvVFRAtjVgKOzmN/G4S+9Bhz/sNMkhrLENEkgOAEnyVkZA xf7glbaJIHGHNF0isqiWji++QkBI9qWKhHHGsEP0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9B33920E4085; Fri, 17 Aug 2012 22:51:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 22:51:26 -0400 Message-ID: <7559986.vitorJ0zlv@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120817034603.20684.qmail@joyce.lan> References: <20120817034603.20684.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 02:51:29 -0000 On Friday, August 17, 2012 03:46:03 AM John Levine wrote: > >It's enough changes that my summary is "go read the diff." > > Man, what a lot of work, thanks. > > Most of these are nits: > > Abstract: Why "author's address"? Usually that means the address in > the From: header. Suggest using one of the terms in 1.3.3 Done. > 2.5.6: suggest adding "software" to the end of the new sentence. As > it stands one could read it as referring to problems in the DNS > records that the receiver publishes. Done. > 3: suggest ref to 4.6.4 as well as 9.1.1 Done > 3.3: remove parenthetical ref to SPF RR type Done. > 3.4: there's nothing wrong in what this says, but it's a generic > problem with all DNS usage, nothing specific to SPF This is true, but it's all limits you have to keep in mind when developing an SPF record. > 3.5: in examples X.COM is a real domain (it's Paypal). Suggest > using X.EXAMPLE or EXAMPLE.COM 3.5 specifically states it's extending an example in RFC 1034 (which uses X.COM), so I think it should stay as is to match the rest of the example. Since it's in other longstanding RFCs, I think there's no harm in having it here. > Also in 3.5, there are real uses of MX wildcards, typically > used to treat mail to foo@bar.example.com as bar-foo@example.com > so people can have less obviously tagged addresses. I'd suggest > saying to be sure that the SPF records match the domains actually > in use in outgoing mail and leave it at that. I took a whack at this. Please check the next revision and see if you think it's adequate. > 4.1: suggest removing last sentence. It's a conceptual function, > it might not be coded as a function at all. Done. Given the pre-amble we have at the start of Section 4 now, I think that's appropriate. > 5: last pp, throws the exception? I hope you mean that evaluation > stops and the topmost check_host() returns temperror. Also in the > table in 5.2 Fixed those and one other. > 5.5: yearrs -> years Fixed. > 6.1: modifier intended -> modifier is intended Fixed. > end of 8.1: what is an implementation supposed to do if a macro > expansion creates a bogus domain due to input data, e.g., using %l in > a domain name since local parts can contain spaces, punctuation, and > other random ASCII crud? Does today's message from Arthur Thisell answer this: > As far as whether the result is a valid domain name, that is spelled out a > few paragraphs above where it says "When the result of macro expansion is > used in a domain name query, ...". It doesn't matter if the result isn't a > valid host name, the DNS allows for 8-bit data in labels, except \0. Some > of the DNS RFCs even give examples of such, and you can enter these labels > in bind-format zone files. As long as it meets RFC 1034/5 requirements (I don't remember which and I'm too tired to look) then isn't it a matter of issuing a query and seeing what you get back? If it doesn't meet the relevant requirements to do than, then it's got to be a permerror. I'd welcome improved text. > 10.3, second bullet: I think TCP spoofing was fixed long enough ago > that this item can go I don't put it past anyone to mess stuff up, so I'd prefer not to remove it. Instead I added "In a modern, correctly configured system the risk of this is negligible." to the end. Does that work for you? Scott K From johnl@iecc.com Fri Aug 17 19:55: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 A3B1421E805A for ; Fri, 17 Aug 2012 19:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.146 X-Spam-Level: X-Spam-Status: No, score=-111.146 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2RloOJTIH7L for ; Fri, 17 Aug 2012 19:55:49 -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 C459221E8048 for ; Fri, 17 Aug 2012 19:55:48 -0700 (PDT) Received: (qmail 55784 invoked from network); 18 Aug 2012 02:55:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 02:55:46 -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=502f0432.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=//mHiQtRSQS+oV+GqtOTm+6V5qw9BQCB7mMIObO6FUo=; b=nYeGiZccbDtFnED3CGKcyWUMeJIWUe45zEKKcbuIM3vpxU6YQkk/ARre2lJ/nu66WCHSz9+ctKu+l4i6UUEYMf3xhv/PF0wr28dnphSStBzOyNXRpEIJbtxaCJmjOXM1Z8oe4/I9Q1n3wkZaz9SqF7pkNRmFmSAthYigeyiG1hU= 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=502f0432.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=//mHiQtRSQS+oV+GqtOTm+6V5qw9BQCB7mMIObO6FUo=; b=gCcL5EZDg1eov21xo/2UydGsuUHTVPyyyTzqYv+brwif2Kh1kePqQboglP1TjtfTIU6tGlMC/2cztgz6ztIM3+re8lTOFPAWAithlRHZA8asElkR8VNuvONvDJyG8vE46p6ukE9xXU3rOM9B4R1pdInko18ZYVJZy4HJYzM98K4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 02:55:24 -0000 Message-ID: <20120818025524.61675.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1852776.mLCLk6b8J8@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 02:55:49 -0000 >> I think the last bit about system level policy versus user level policy is >> an interesting idea. Where do you think it would fit in 9.3? > >I thought about this some more and I don't think it's helpful after all. Agreed. This is way, way out of scope of this document. Our job is to tell people how to determine SPF's opinion of a message. It is not to to speculate about how one might build a spam filtering system on top of it. Beyond being out of scope, it's also beyond our area of expertise. I think that if you showed some of the proffered advice to people who run large mail systems, the best you'd get would be a polite chuckle. R's, John From johnl@iecc.com Fri Aug 17 20:07: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 E13CF21E809B for ; Fri, 17 Aug 2012 20:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.846 X-Spam-Level: X-Spam-Status: No, score=-110.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_17=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBmUoOPFlCBa for ; Fri, 17 Aug 2012 20:07:17 -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 C260421E8048 for ; Fri, 17 Aug 2012 20:07:16 -0700 (PDT) Received: (qmail 56848 invoked from network); 18 Aug 2012 03:07:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 03:07:14 -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=502f06e2.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=I0nNMC7TK1OQNz+iYJVkzGZpyIHHotGhpfPDZhnT+3E=; b=tIP3/wIVMe+mEhvMDam1GO6HK1b5u0Dghd++hCzVIaeWx8lVnm3qv3Y8J+Ar0a8jD1QC3QAleuUyJuii/oI3sDqbQNc6SYVOtT1M3YUsoD2f/8RE1b3/d+hbsubAptDI/L2cHBv9t/tPfdCR/miyzG/ZJfdgQdq+CGs+MN7MVso= 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=502f06e2.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=I0nNMC7TK1OQNz+iYJVkzGZpyIHHotGhpfPDZhnT+3E=; b=DaCHrDJb1K6a5Z47ag2vbVbvPOTMnipoGsYXzRTl+ks0lTBFWAa7xzVuWFCCMfCpTPTQpEZcIsaXbmTqbdhLIS8pnoaZAsxFNhGaD5LI9Dq7xlQPr+ESaBQo8T/50JQf4d0GMyQJ3NoDDKAIWRIpQsw9PXU5GZxpA2R/rH2yxLg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 03:06:52 -0000 Message-ID: <20120818030652.64796.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <7559986.vitorJ0zlv@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 03:07:18 -0000 >> 3.5: in examples X.COM is a real domain (it's Paypal). Suggest >> using X.EXAMPLE or EXAMPLE.COM > >3.5 specifically states it's extending an example in RFC 1034 (which uses >X.COM), so I think it should stay as is to match the rest of the example. >Since it's in other longstanding RFCs, I think there's no harm in having it >here. Doesn't matter to me, but the IESG has been known to obsess on this. >> Also in 3.5, there are real uses of MX wildcards, typically >> used to treat mail to foo@bar.example.com as bar-foo@example.com >> so people can have less obviously tagged addresses. I'd suggest >> saying to be sure that the SPF records match the domains actually >> in use in outgoing mail and leave it at that. > >I took a whack at this. Please check the next revision and see if you think >it's adequate. OK, will do so. >> end of 8.1: what is an implementation supposed to do if a macro >> expansion creates a bogus domain due to input data, e.g., using %l in >> a domain name since local parts can contain spaces, punctuation, and >> other random ASCII crud? > >Does today's message from Arthur Thisell answer this: Not really. > then isn't it a matter of issuing a query and seeing what >you get back? If it doesn't meet the relevant requirements to do than, then >it's got to be a permerror. I'd welcome improved text. The problem is that it's ill specified. If you give a resolver library an invalid domain name, there's no guarantee that it will politely reject it. It might crash or do other random badness. This isn't a permerror, since the SPF record might well work if used on a message with a less nasty bounce address. Waving my hands, I'd suggest a soft fail if a macro expansion creates an invalid domain name. >> 10.3, second bullet: I think TCP spoofing was fixed long enough ago >> that this item can go > >I don't put it past anyone to mess stuff up, so I'd prefer not to remove it. >Instead I added "In a modern, correctly configured system the risk of this is >negligible." to the end. Does that work for you? You'd have to find a TCP stack more than 15 years old for TCP sequence guessing to be a problem. Really, it's dead. I've been trying to stamp out discussions of TCP spoofing because incompetent system managers still point to them and insist that they're not sending spam, it was spoofed. Not. R's, John From spf2@kitterman.com Fri Aug 17 20:09: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 2043A21E809B for ; Fri, 17 Aug 2012 20:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZNBr2ehZBvU for ; Fri, 17 Aug 2012 20:09:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6513A21E8048 for ; Fri, 17 Aug 2012 20:09:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D6F0020E4091; Fri, 17 Aug 2012 23:09:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345259355; bh=dlELokW2cw4kz/WkGDarsEQivc2GfcSXNE7uVk24AfM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NnJp5u/OpODSsqjIS21UnFMAuQazr+e30rOAmRRIaZ1OYH63WuyR9yzTW2D7i9PZJ 2/crFvfx3/19KrxQZ1ve3bpB6C3gNciPDXIDSi8alDErJYrrJa2xjpvyddEFfrKiRt XXQJMRDX1g5tuytC4ERgHf1wkyRhX++jRGJIAzV4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A8DAC20E4085; Fri, 17 Aug 2012 23:09:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 Aug 2012 23:09:14 -0400 Message-ID: <89686312.gpFrOJr1G6@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120817171109.2800.qmail@joyce.lan> References: <20120817171109.2800.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 03:09:17 -0000 On Friday, August 17, 2012 05:11:09 PM John Levine wrote: > >OK, so I got that bit a bit wrong (as well as the localpart/EAI text). > >Thanks. I think I can safely delete this addition. Please suggest > >appropriate text for the last sentence of the paragraph in section 8.1 > >that discusses the "s", "l", and "o" macros. I'm not sure how to put it. > > The point is that those macros can allow hostile senders to inject > arbitrary character strings into the names in DNS queries. So you > better be sure that the libraries that handle the queries don't assume > that the names are well formed, or consist only of printing ASCII > characters. I think "there may be bugs in software" is not a working group issue. If people have DNS servers answering arbitrary queries from the outside world, all these things can already be queried for. Fundamentally any naive assumptions DNS software developers make are not our problem. If we have some real experience with real problems (I've certainly seen both with use of PTR and relying on DNS over TCP) then we should consider if we are proposing something unreliable. I don't think we ought to do too much hand wringing over uncertain issues that may or may not exist. > If you want to mention EAI, note that an EAI address consists of an > arbitrary UTF-8 mailbox and a domain which may be a U-label (UTF-8) or > A-label (punycoded.) For %o it would probably be a good idea to > convert U- to A-labels before lookup. But other than that, addresses > can and probably will contain characters that are difficult or > impossible to provision in DNS software, so don't use %s or %l in > expansions that are intended to produce names to be looked up. Why not? If I can generate a query for it, but it can't be provisioned, all that can happen is it doesn't match. Under RFC 4408, that's what would happen and so I think we just need to say that if the domain has a local-parts that can't be looked up, then don't use %s or %l in your record. I have a poor try at this in -04, but it needs redoing. Scott K From hsantos@isdg.net Fri Aug 17 20:43: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 A1D4921E8095 for ; Fri, 17 Aug 2012 20:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2LR1QrLLNfB for ; Fri, 17 Aug 2012 20:43:18 -0700 (PDT) Received: from ntbbs.santronics.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3275121E8048 for ; Fri, 17 Aug 2012 20:43:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5082; t=1345261383; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1PDzvXk74C2xZbhR6wale0PdyOU=; b=HNFUfnQJocmF/5LWKhe6 7afCpIxIk+YiK7zkNzaYl34rza5L8YJ9uQ21A1mRif2puGoKERR+D+VrhRBKS59H GjabjK8o3z8OLmM3kzFPW+8Y+U+HcXTYLfRYcU3FSXg8NIMGyoS5frj/YWBZzefz VkUurzsqWOI14uPU5c24JDU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 23:43:03 -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 1283185047.22748.4948; Fri, 17 Aug 2012 23:43:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5082; t=1345261199; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4XbV8vk ZbNXGK1k+GXYkEBol+4WlYpLQD17+xpOwI1c=; b=x+fJSse3zgvGAFBjJ9pgR5l QEaXUGVEp5eikNJSCc/4Qi2KA4vyzQh2PNXmnWT3QCfVS/2fQqyMy3bfP8wR2Ff2 qAdjTSDoR982TNJkU0s/qsz+ePB+2w57xHDebA0QkwM8mZ4RFPVd/H+litNgbdra 0WAZPVZlphwFaNSJVf4k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 17 Aug 2012 23:39: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 1881997427.7.4456; Fri, 17 Aug 2012 23:39:58 -0400 Message-ID: <502F0F68.5000202@isdg.net> Date: Fri, 17 Aug 2012 23:43:36 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502E7FC7.9020701@isdg.net> <4206191.rMJEy9IeT9@scott-latitude-e6320> <1852776.mLCLk6b8J8@scott-latitude-e6320> In-Reply-To: <1852776.mLCLk6b8J8@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 03:43:19 -0000 Note: I was not proposing the terms REJECT/MARK-ON-FAIL, only using it for discussion. I only pointed out how it was being discussed by deployment discussions with MARK-ON-FAIL because once the mail is accepted, any filtering will be a USER LEVEL POLICY concept and that is where it becomes more complex and I am glad to see, the view is now realized. I wanted to emphasize is it not the prevailing idea for SPF as it was made out to be. REJECT is a very much a big part of the SPF protocol and domains publishing strong exclusive -ALL policies do have a high expectation for SPOOF protection where no other INPUT is required, additional input undefined or otherwise. -ALL means its "This Way" and not "That Way!" There is no ambiguity. There is no reputation concept here to muddy the water with. Of course, there could be, but that is a RECEIVER thing, not a SPF PUBLISHER thing. -ALL means a specific thing, well all the mechanisms do, and -ALL (always) had a specific RFC2119 strong compliance language. MARK, quite frankly, I personally believe is only being mentioned as the prevailing method by a few that never quite believed in SPF since the git-go. Thats not a bad rap, its the truth and their publicly expressed viewed for a long time. Many people in the SMTP world don't believe in strong deterministic SMTP level rejection concepts. Many do believe of leaving it all up to the USER. Well, SPF was not one of those "iffy" protocols, we needed something straight forward and the strong hard, even softfail policies, and perhaps that is what bothered many. DKIM tried to changed that and couldn't. Anyway, the whole point is that REJECT-ON-FAIL vs MARK-ON-FAIL are the protocol options for the receiver and MARK-ON-FAIL MUST NOT circumvent the security REJECT-ON-FAIL provides. The only recommendation or additional insights for MARK-ON-FAIL is to make sure accepted mail streams and user mail access, etc are separated otherwise you have a protocol security loophole. How this is stated, I leave to you or others that wish to describe this basic concept here for REJECT vs MARK. The MUA method is very important here. Scott Kitterman wrote: > On Friday, August 17, 2012 02:13:39 PM Scott Kitterman wrote: >> On Friday, August 17, 2012 01:30:47 PM Hector Santos wrote: >>> The REJECT-ON-FAIL should be regarded a System Level local policy for >>> global filtering for all users, where the MARK-ON-FAIL should be regarded >>> as a User Level Policy framework where good vs bad mail is separated for >>> the user. > ... >> I think the last bit about system level policy versus user level policy is >> an interesting idea. Where do you think it would fit in 9.3? > > I thought about this some more and I don't think it's helpful after all. > > Mark/Reject can be done differently on a per-user basis. It sometimes produces > odd results for multi-recipient mail, but that's manageable. > > There are other SMTP time tests that can be done, including, if one is so > inclined content filtering and virus checks. > > The distinction is really a different set of design approaches. > > It is possible and reasonable to approach design of a "spam defense" system > two different ways: > > 1. A system with a series of discrete steps where each step produces it's own > definitive result. A message that fails any single step along the way is > rejected or marked 'bad'. It might be Local IP black list check -> DNSBL > check -> SPF HELO check (and there might be a whitelist that then skips some > or all the rest of the checks for whiltelisted hosts) -> rDNS check -> SPF > Mail From check -> anti-virus check -> anti-spam content filtering -> accepted. > > 2. A system where information about various attributes of the message (e.g. > the results of all the above checks and more) are collected and evaluated in > some weighted evaluation scheme to produce a decision about what to do with > the message. > > The first one is easier to conceptualize, design, and implement because the > problem can be trivially broken down into a series of small, largely > independent efforts. The second requires more information to be collect and > stored and development/testing of a complex/robust algorithm for integrating > and balancing the various results. Neither one of these is inherently better > than the other. > > When I'm doing systems work, I prefer the first kind of approach when I can get > a satisfactory result. It's easier to design and to verify it's working as > expected. There is no guarantee that the second 'cook it into a stew' > approach will produce a better result. > > Given that, I don't think this kind of design philosophy has a place in > 4408bis. I think we should (as I've done) try to limit ourselves to factual > advantages and disadvantages of reject and mark and leave it at that. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Fri Aug 17 21:36: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 55FCD21F8551 for ; Fri, 17 Aug 2012 21:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZYK8+XKbFKK for ; Fri, 17 Aug 2012 21:36:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 331AA21F854C for ; Fri, 17 Aug 2012 21:36:55 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4A4AE20E4091; Sat, 18 Aug 2012 00:36:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345264614; bh=1f4rgJPLoAO+Tau7haQIIa3SK48Y+UmydIKk0kSYISw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=juOey45Ty7Wh8uuYKPJTKKEKxoWV0Cg0lpRGwFN1yTil9LyB8LBrgd0k2qqBTarNs BNpxgCdFkExe0V+Fmi8kVjTwTPB7PdgDqVUZOfyo15U+ke4t/l7J1sZLrwGJ/+0sHp 1d6OHXunzjoxjyqNAJ6uedoiYjV0twUdeHbdfW4Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 20F9220E4085; Sat, 18 Aug 2012 00:36:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 00:36:52 -0400 Message-ID: <1943574.YPYx9u0VDs@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502CED0C.8000506@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 04:36:57 -0000 On Friday, August 17, 2012 01:48:03 PM Murray S. Kucherawy wrote: > On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: > > For the negative note: Is it possible to roll back that 5598-based > > replacement of identity names, _please_? RFC5321.HELO/.EHLO is > > excessively long and lowers the readability of the document. I don't > > object on that string appearing in Section 1.3.4. After precisely > > defining what HELO means, it is not necessary to repeat the whole > > definition any more. > > I'd settle for something that makes it clear that "HELO Identity" > elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), > but I disagree that it's a cumbersome notation. That could just be > that I'm used to it. I'm inclined to put it back, but then that could be just because I'm not used to it. I'll wait for more feedback. > > Furthermore, > > if a claimed identity fails verification, local policy can take > > stronger action against such email, such as rejecting it. > > > > Kudos for Section 9.3! Now that we have it, that last sentence in the > > > > Introduction can be reworded so as to anticipate it. For example: > > Furthermore, receivers can devise local policies (Section 9.3) > > in order to facilitate processing of messages that get specific > > results; for example, they can whitelist domains that pass the > > verification, or reject mail that fails it. > > I don't know that it's necessary to add that up front. Referring to > Section 9.3 at this point is sufficient. > > > 2.3. *Publishing Authorization* > > > > An SPF-compliant domain MUST publish a valid SPF record as described > > in Section 3. This record authorizes the use of the domain name in > > the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities by the MTAs it > > specifies. > > > > It is possible to address compliance by ADMD, rather than by domain: > > An SPF-compliant ADMD MUST publish valid SPF records as described > > in Section 3. These records authorize the use of the relevant > > domain names in HELO and MAILFROM identities by the MTAs it > > specifies. > > As above. > > > That way, the spec can modulate the requirements about which domains > > MUST/SHOULD have an SPF record. Until the term "domain" is used > > interchangeably for a DNS label or an ADMD, wording such requirements > > is difficult. > > The goal of introducing the term "ADMD" is specifically to avoid using > the terms interchangeably. If I used the wrong one in some place, please cite specifics, so I can look at it and fix it. > > SPF results can be used to make both positive (source is authorized) > > and negative (source is not authorized) determinations. If domain > > owners choose to publish SPF records and want to support receivers > > making negative authorization determinations, then they MUST publish > > records that end in "-all", or redirect to other records that do, > > otherwise, no definitive determination of authorization can be made. > > > > IMHO, constructs like "If you choose X then you MUST Y" are > > meaningless. I'll never be able to tell whether you are compliant, > > unless I have a method to determine what you chose. And since you can > > always change your mind, the normative sense of the verb is completely > > lost. > > I'm not so sure. I read that as saying "the only way to coerce > rejection from a receiver willing to do so is to use -all". I think it's reasonable to say if you want X, Y is how you get it. I think that's what this does. It takes the place of a generic "use -all" recommendation in 4408 that isn't particularly defensible IMO. > > 2.5.4. *Fail* > > > > A "fail" result is an explicit statement that the client is not > > authorized to use the domain in the given identity. Disposition of > > SPF fail messages is a matter of local policy. See Section 9.3 for > > considerations on developing local policy. > > > > For the sake of clarity, cannot we say explicitly that the receiver > > "MAY reject the message, according to local policy"? It is what that > > paragraph is actually saying, except that we force the reader to > > interpret the term "disposition". I realize that being explicit may > > emphasize a weakness of SPF, which I hope we'll address later on. > > It would be equally correct to say "MAY keep the message, according to > local policy". I think the language that's there is correct and > concise, and we should leave it. I think the text is precisely correct at the moment. It's a matter of local policy. Period. No more. As part of the protocol I don't think we can do more. If more is needed, I believe it has to be in Section 9 where we provide some advice on what to consider when developing local policy. > > As a further point on that snippet, that "given identity" sounds > > obscure. The result doesn't formally depend on which identity is > > being checked. > > How can it not? > > But you could say "the identity under evaluation" or something like that. The SPF result would be the same either way (mfrom or helo), but the implications of it might be different. I don't see the benefit in the change, but if people think it would be better, I'm fine with it. > > 3. *SPF Records* > > > > The paragraph "Domain owners wishing to be SPF compliant [...]" is > > redundant after Section 2.3. I'd strike it. > > +1. The first sentence is redundant. I've removed it. The second one is not. I've left it. > > In the paragraph next to it, s/in Section 3/above/. > > +1. Changed to "above (Section 3)". > > Since TXT records have multiple uses, beware of other TXT records > > published there for other purposes. They might cause problems with > > size limits (see Section 3.4) and care MUST be taken to ensure only > > SPF records are used for SPF processing. > > > > I'd s/ and care MUST be taken/. Verifiers MUST take care/. > > Meh. Take it or leave it. Me too. IIRC this is unchanged from 4408, so I'd rather leave it unless there's a real problem. > > 3.3. *Multiple Strings in a Single DNS record* > > > > As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > > record (either TXT or SPF RR types) can be composed of more than one > > string. > > > > s/[RFC1035] sections 3.3.14 and 3.3/Section 5.1 of [RFC1035]/ > > Nope. Section 5.1 talks about the zone file format. SPF receivers > don't get zone files, they get raw DNS data. The Section 3 references > are correct. > > > Remove the parenthesized phrase. > > +1. Fixed > > 3.4. *Record Size* > > > > Why would TCP be less reliable than UDP? > > It's not uncommon for operators, out of ignorance, to interfere with > DNS over TCP because the need for that fallback is historically rare. > There were hints of this family of problems in the experiment > document. > > > 4.6.4. *DNS Lookup Limits* > > > > SPF implementations MUST limit the number of mechanisms and modifiers > > ("terms") that DNS lookups to at most 10 during SPF evaluation. > > > > s/that DNS lookups/that cause any DNS query/ if it would make for > > better English. > > +1. Done. > > 5.1. *"all"* > > > > Any "redirect" modifier (Section 6.1) has > > > > MUST be ignored when there is an "all" mechanism in the record. > > > > s/has // > > +1. Done. > > 5.5. *"ptr" (deprecated)* > > > > I like the numbered algorithm. It's more readable. > > > > Does the grammar allow "ptr:example.com/24"? Step 4 doesn't seem to > > allow fuzzy IP comparisons based on given CIDR-length. > > I don't believe the grammar does allow that. I don't think it should. > > Another question: If there was a {temp/perm}error while doing an A RR > > lookup, and then the mechanism failed to match, MAY a {temp/perm}error > > be returned instead of non-match? > > Section 4.4 should make it clear that it's only talking about the > outermost TXT query in the second paragraph. > > Section 4.6.2 doesn't actually say what to do in a parent evaluation > when a child mechanism is being evaluated and the child throws an > exception; does this exception propagate upward and terminate the > entire evaluation, or does processing continue? It does propagate upward. It has to for consistency. In -04 it says: > If it matches, processing ends and the qualifier value is returned as > the result of that record. If it does not match, processing > continues with the next mechanism. If it throws an exception, > mechanism processing ends and the exception value is returned. I think "mechanism processing ends and the exception value is returned" is clear, particularly if you look at it in combination with what's in Section 5.2 on includes: > 3. The recursive evaluation returns either match, not match, or an > error. If it matches, then the appropriate result for the > include: mechanism is used (e.g. include or +include gives a > "pass" result and -include gives "fail). Does either of those need change to make it clear the error isn't somehow discarded? > > 7. *Recording The Result* > > > > It is RECOMMENDED that SMTP receivers record the result of SPF > > processing in the message header. There are two methods for doing > > this: the Received-SPF Header Field defined here and the more generic > > Authentication-Results Header Field defined in [RFC5451]. Because > > these fields are generally used within a receiving ADMD, it is a > > local policy choice which to include. In general, the more broadly > > applicable Authentication-Results Header Field ought to be used, but > > it SHOULD provide the same information as if a Received-SPF Header > > Field were used. > > > > Is there a reason why "Header Field" is capitalized that way? > > It should be lowercased. Fixed in all but a few cases where it was part of a title. > > I don't think we can be normative-by-cmparison on what information is > > actually put on the field, because we don't know which tags would have > > been filled in the Received-SPF field if the latter were used. For an > > > > alternative wording: > > In general, the more broadly applicable Authentication-Results header > > field ought to be used, as long as it can convey the same > > information that the verifier would have written in a Received-SPF > > header field if the latter had been used. > > s/as long as it can convey/in such a way that it conveys/ Done. > > The next paragraph should be split in two: > +1. This one: If an SMTP receiver chooses to do so, it SHOULD use one of these header fields for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in , Explanation.) If so, I don't see it? > > See above for the "If ... SHOULD". I'd propose: > > An SMTP receiver SHOULD use one and only one of these header fields. > > In case both of them are used, they MUST be consistent with one > > another. > > "one" is enough; "one and only one" is too wordy. That's fine otherwise. > > > Note that A-R can convey results for multiple identities within a > > single header field, so it doesn't make much sense to require to use > > two of them. > > +1. I think I cleaned all this up a bit and it should ~OK now. > > 7.2. *SPF Results in the Authentication-Results Header Field* > > > > We need to discuss this further: > > > > Why "Authserv-id SHOULD be the name of the receiving host performing > > the check"? What if the check is performed by a different host, or > > the host has multiple names? Being consistent with the corresponding > > Received: field seems to be a good idea, but then RFC 5451 allows > > different strategies. > > I agree; RFC5451 says use of the hostname or ADMD domain name is > common, but not necessary. It also doesn't say anything at all about > coordinating with Received:, but that seems a sensible thing to do. I took that out. > > Why overload the "reason" tag? RFC 5451 is extensible and this spec > > may add any missing tags. > > What would you do with the client IP address as its own dedicated part > of an A-R header field? This was a matter of substantial debate > during RFC5451's development. If all you want to do is log it or > include it in Received: fields for information, doing it in CFWS is > fine. It's useful to register tags of this nature only if something > will extract that value and attempt to do something more with it. In > the case of DKIM, for example, one might extract the signing domain, > compare it to the From: domain, and decide to do something special > with message presentation there. But providing the IP address, > something the user never sees, doesn't seem to be a useful thing to > do. The argument back then is that one might want to evaluate SPF > again at the MUA, but there was no support for that and plenty against > it. That's why we didn't do that in the first place. I don't think this is the place to extend RFC 5451 and I also don't think providing this information in "reason" is overloading at all. The information I suggest be provided is, in fact, the reason for the result. > > 8.1. *Macro Definitions* > > > > Implementations SHOULD be aware that if no directive processed during > > the evaluation of check_host() contains an "s", "l", "o", or "h" > > macro, then the results of the evaluation can be cached on the basis > > of and alone for as long as the shortest Time To Live > > (TTL) of all the DNS records involved. > > > > "SHOULD be aware" doesn't mean anything to me. I'd make it non-normative. > > +1. I changed it to Note: If .... > > 9.1.3. *Bounces* > > > > Zone file generation for > > > > significant numbers of hosts can be consolidated using the redirect > > modifier and scripted for initial deployment. Administrators might > > alternatively consider publishing an SPF for *.domain (wildcard > > domains) in that case if the involved hostnames do not have already > > any other DNS record. > > > > I'd strike the last sentence, or at least recall that wildcard records > > are discouraged and provide a link to Section 3.5. > > Indifferent on that suggestion. I changed 3.5, so I think it's better to leave it in. > > Further advice is needed for scripting the zone. For example, mention > > that any host that has an IP address is a good candidate for an SPF > > record; those that do send mail really deserve one; and so forth. > > Should we provide a Perl script in an appendix? > > I don't want to stray too far into operational advice. We're simply > describing an algorithm here. The further we go into operational > stuff, the more complex this all gets. Including anything more than > pseudocode needs to be very carefully considered. Implementation specific DNS setup advice is, I think, far beyond what we should provide. I know a lot of people are used to thinking in terms of BIND zone files, but there's more than one way to do it. I was using script in a very generic sense. In many cases these days the tricky part would be the SQL for the back end database. > > 9.2.4. *MTA Relays* > > > > For mail senders, this means that published SPF records must > > authorize any MTAs that actually send across the Internet. Usually, > > these are just the border MTAs as internal MTAs simply forward mail > > to these MTAs for delivery. > > > > I believe the last word should be "relaying". > > +1. Done. > > *Last and least* > > > > I counted 13 occurrences of "SPF client(s)". Since an SPF client is > > likely an SMTP the server, that term may be confusing. How about > > using "SPF verifier(s)" instead? > > +1. I replaced 12. Thanks for all the comments. Scott K From spf2@kitterman.com Fri Aug 17 21:40: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 8F17321F857D for ; Fri, 17 Aug 2012 21:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6tjBfcRRpvR for ; Fri, 17 Aug 2012 21:40:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0821F8551 for ; Fri, 17 Aug 2012 21:40:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E86DF20E4091; Sat, 18 Aug 2012 00:40:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345264806; bh=uNuA5FmpOOCOvFIEbipKdlXELGxE+Fhaw+INJ90mNNc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pE4EKZfvEwsNRaL4677qreFzTLCiJpnwzAwCEoMM7ebMmDpX+Vf760nRFZIiKMqBC zaqfCcIIMh8IKYstRTTXQu9UhtT+VWVqI4zO6c9MBEfRO/8DZgWWgmiSgSPLrj6RYI h8/lT08BelrjPYtzuM0ZZ9rOBIDfKGFG3J8wwqp4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C570820E4085; Sat, 18 Aug 2012 00:40:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 00:40:05 -0400 Message-ID: <2305891.WGo84QJhGW@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 04:40:08 -0000 On Friday, August 17, 2012 09:07:42 PM Franck Martin wrote: > On 8/17/12 1:48 PM, "Murray S. Kucherawy" wrote: > >On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: > >> 9.1.3. *Bounces* > >> > >> Zone file generation for > >> > >> significant numbers of hosts can be consolidated using the redirect > >> modifier and scripted for initial deployment. Administrators might > >> alternatively consider publishing an SPF for *.domain (wildcard > >> domains) in that case if the involved hostnames do not have already > >> any other DNS record. > >> > >> I'd strike the last sentence, or at least recall that wildcard records > >> are discouraged and provide a link to Section 3.5. > > > >Indifferent on that suggestion. > > > >> Further advice is needed for scripting the zone. For example, mention > >> that any host that has an IP address is a good candidate for an SPF > >> record; those that do send mail really deserve one; and so forth. > >> Should we provide a Perl script in an appendix? > > > >I don't want to stray too far into operational advice. We're simply > >describing an algorithm here. The further we go into operational > >stuff, the more complex this all gets. Including anything more than > >pseudocode needs to be very carefully considered. > > I like the text there, this draws the attention on bounces and similar > forgotten folklore. > > Yes the wildcard thing is a potential issue if you do FCDNS. In rDNS it is > fine. > > So instead mentioning wildcard, may be we could simply suggests the > following simple record for each sending hostname. > Hostname TXT "v=SPF1 a ~all" For a sending hostname there's no reason not use -all. If we want to recommend something that should be it. > And for a non sending hostname > Hostname TXT "v=SPF1 redirect=domain" Why would this not be just TXT "v=SPF1 -all" These are two of the safest SPF records to publish. For them to be wrong you either have to get IP addresses of hostnames wrong or have hosts sending mail and not know it. If you want to make a recommendation, don't pussyfoot around here. Scott K From spf2@kitterman.com Fri Aug 17 21:42: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 3781321F8584 for ; Fri, 17 Aug 2012 21:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+m-H7g2tMCe for ; Fri, 17 Aug 2012 21:42:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6252021F8582 for ; Fri, 17 Aug 2012 21:42:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D6EDD20E4091; Sat, 18 Aug 2012 00:42:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345264950; bh=/nQtVOtiKkZ2FLT3SAOjdg4QrhWH8l/dE2SRv09iZkw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iH3wzGBdAhBPbK/4xzTsYdmd6//GelUoLzgXPxYA1ew+E2h2R2DueUjmw+YxRHn9g ZJ03p3ShiHPGdVPh4cXVipPlFtSy1TNtPd5RjV7uHrYufD1ZS5f1YxTnJtqqDqOgfY rwIn3qMifPybF/K72noFcN+Z+1y9AmNKzMfeIdXI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A81B620E4085; Sat, 18 Aug 2012 00:42:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 00:42:29 -0400 Message-ID: <2391814.NLLl84nT3N@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <4206191.rMJEy9IeT9@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 04:42:32 -0000 On Friday, August 17, 2012 02:46:24 PM Murray S. Kucherawy wrote: ... > I'm not liking the idea of identifying specific SMTP reply codes or > enhanced status codes that should be used for SPF rejections. RFC3463 > and RFC5321 already define those. We should leave that alone. If we > want to give examples, that's fine, but I don't think we should be > normative about it. ... We discussed this before. This was in RFC 4408 (modulo one case that was accidentally missed and was an erratum), so including this isn't novel. I view this as part of consistency. I miss what is the case for removing it. Scott K From spf2@kitterman.com Fri Aug 17 22:09: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 EBB0421F8508 for ; Fri, 17 Aug 2012 22:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1UIaQURFZFz for ; Fri, 17 Aug 2012 22:09:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B278A21F84F9 for ; Fri, 17 Aug 2012 22:09:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 139A120E4091; Sat, 18 Aug 2012 01:09:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345266586; bh=x8bOTaRY5Mesp7+vJZK9cpZwY37AQvg7bmJhxe9GuI8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pGyQ6eZYwiM3N4pYXQRdweQHfpo/oyMW/6CfO3roPBRnlW855EPyWfd2dGPj/yVkD CYcrW1m6kCf/RRDJC7QsAq2nwcgf3ZY5ffT+dFcQexLCWe96LRKjajMFl8Bx40p4br flZgl+YoiAi6SHnD4YwcNA3mvcfebNw8ULBE4adg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DAA8D20E4085; Sat, 18 Aug 2012 01:09:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 01:09:44 -0400 Message-ID: <1477429.4Q0UcHrSQQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120818030652.64796.qmail@joyce.lan> References: <20120818030652.64796.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 05:09:48 -0000 On Saturday, August 18, 2012 03:06:52 AM John Levine wrote: > >> 3.5: in examples X.COM is a real domain (it's Paypal). Suggest > >> using X.EXAMPLE or EXAMPLE.COM > > > >3.5 specifically states it's extending an example in RFC 1034 (which uses > >X.COM), so I think it should stay as is to match the rest of the example. > >Since it's in other longstanding RFCs, I think there's no harm in having it > >here. > > Doesn't matter to me, but the IESG has been known to obsess on this. My usual response to such things is "I'll be glad to fix it after you go fix the reference I copied it from". I'll leave it as is I guess unless one there's a upswell to change it. > >> Also in 3.5, there are real uses of MX wildcards, typically > >> used to treat mail to foo@bar.example.com as bar-foo@example.com > >> so people can have less obviously tagged addresses. I'd suggest > >> saying to be sure that the SPF records match the domains actually > >> in use in outgoing mail and leave it at that. > > > >I took a whack at this. Please check the next revision and see if you > >think it's adequate. > > OK, will do so. > > >> end of 8.1: what is an implementation supposed to do if a macro > >> expansion creates a bogus domain due to input data, e.g., using %l in > >> a domain name since local parts can contain spaces, punctuation, and > >> other random ASCII crud? > > > >Does today's message from Arthur Thisell answer this: > Not really. > > > then isn't it a matter of issuing a query and seeing what > > > >you get back? If it doesn't meet the relevant requirements to do than, > >then it's got to be a permerror. I'd welcome improved text. > > The problem is that it's ill specified. If you give a resolver > library an invalid domain name, there's no guarantee that it will > politely reject it. It might crash or do other random badness. This > isn't a permerror, since the SPF record might well work if used on a > message with a less nasty bounce address. Waving my hands, I'd > suggest a soft fail if a macro expansion creates an invalid domain > name. So I think we already have this problem without EAI. If I read the intersection of RFC 5322 correctly, there are non-EAI characters allowed in local-part that aren't allowed in domain names, they can be quoted, I would guess. So leaving EAI aside for a moment, how do we specify it? I think either quote and then look up or raise permerror as this isn't something that's going to change? > >> 10.3, second bullet: I think TCP spoofing was fixed long enough ago > >> that this item can go > > > >I don't put it past anyone to mess stuff up, so I'd prefer not to remove > >it. Instead I added "In a modern, correctly configured system the risk of > >this is negligible." to the end. Does that work for you? > > You'd have to find a TCP stack more than 15 years old for TCP sequence > guessing to be a problem. Really, it's dead. I've been trying to > stamp out discussions of TCP spoofing because incompetent system > managers still point to them and insist that they're not sending spam, > it was spoofed. Not. OK. How about: The client IP address, , is assumed to be correct. In a modern, correctly configured system the risk of this not being true is nil How about that? I put that in for the moment. From superuser@gmail.com Fri Aug 17 23:09: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 9460F21F84EF for ; Fri, 17 Aug 2012 23:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DsETL-9BgMh for ; Fri, 17 Aug 2012 23:09:13 -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 B980421F84E4 for ; Fri, 17 Aug 2012 23:09:12 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2597112lbb.31 for ; Fri, 17 Aug 2012 23:09:11 -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=7aXn9KUtGSvOdkfOH4lQU1Q5gXYnmm6/LJIMge6MNRU=; b=SIRL/gsrXEsJRz8ZBQOktm3weu8e8iQbO38KwjxvN/xufuGjr7TrjmJtrKvKDd0aKg Y8U4aB06ZnDW/8hWN5rjm9vbh+jqqhT48aJLHrU2pVXIAz8dUKBQ1mNjPGgBV6aM2Clv PRCIIM8lvEyqLjlyApYmJnhCvORQql71pKaMg8VNqojQpAK4F2VSmufpti9kHXMCyWiG pL0X0+ret44w20LP/5mYfEVAy66mM/AfvkmX+AtJ2hw8KaRnpdv5LAiYd6rETTd6aPtX rw+omwIPyddaIPjv6WyTwUEgWInmTa11qSBCQEjuYNq4GI9A1q+DXg8vROqJxDd3ouNh S/Tg== MIME-Version: 1.0 Received: by 10.112.83.200 with SMTP id s8mr3286387lby.13.1345270151214; Fri, 17 Aug 2012 23:09:11 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 17 Aug 2012 23:09:11 -0700 (PDT) In-Reply-To: <1943574.YPYx9u0VDs@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502CED0C.8000506@tana.it> <1943574.YPYx9u0VDs@scott-latitude-e6320> Date: Fri, 17 Aug 2012 23:09:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 06:09:13 -0000 On Fri, Aug 17, 2012 at 9:36 PM, Scott Kitterman wrote: >> Section 4.4 should make it clear that it's only talking about the >> outermost TXT query in the second paragraph. >> >> Section 4.6.2 doesn't actually say what to do in a parent evaluation >> when a child mechanism is being evaluated and the child throws an >> exception; does this exception propagate upward and terminate the >> entire evaluation, or does processing continue? > > It does propagate upward. It has to for consistency. > > In -04 it says: > >> If it matches, processing ends and the qualifier value is returned as >> the result of that record. If it does not match, processing >> continues with the next mechanism. If it throws an exception, >> mechanism processing ends and the exception value is returned. > > I think "mechanism processing ends and the exception value is returned" is > clear, particularly if you look at it in combination with what's in Section > 5.2 on includes: > >> 3. The recursive evaluation returns either match, not match, or an >> error. If it matches, then the appropriate result for the >> include: mechanism is used (e.g. include or +include gives a >> "pass" result and -include gives "fail). > > Does either of those need change to make it clear the error isn't somehow > discarded? I think if you were to say "all mechanism processing ends", it's more clear. Right now I think one could read it as "this mechanism processing ends, but continue". Tacking "all" before it is more explicit. > I don't think this is the place to extend RFC 5451 and I also don't think > providing this information in "reason" is overloading at all. The information > I suggest be provided is, in fact, the reason for the result. Yep, that's fine. -MSK From sm@elandsys.com Fri Aug 17 23:22: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 0BF1E21F8517 for ; Fri, 17 Aug 2012 23:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYsgb1M5OEh9 for ; Fri, 17 Aug 2012 23:22: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 D141721F8516 for ; Fri, 17 Aug 2012 23:22:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.237]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7I6MWR6024810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2012 23:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345270963; bh=QLa5z2pKhDscDuY4GhohKam2JfrB5WRl+lLrIXfo5uA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Aod8xnVezAhAbBF8Ze8zhTN0g/Vr0d4QVVTU4Z3UtfjKxHrKKmiTzmO3wbrxM/qLZ 9cKk2EnhF7YGYvOFD0kGSi8rVhc+ktPegrNRRheoIWc7sPZM5pCq8mCtu88Zw06bMH 3tQVGnjA48OwbeVxhuWHNyzuHQLQG8VfdwNdK6pE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345270963; i=@elandsys.com; bh=QLa5z2pKhDscDuY4GhohKam2JfrB5WRl+lLrIXfo5uA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=L6D4HGssP5ulfWJBiqxvAtfz5lDTIkrEusU0T4fpq3lDZ+dvL6FNT6yPbM3k/g4bV fA0C6FsJTe74LX4CbyKZLLwEjAbpSrcYRJNzbLOQVLbPqw8IK4Zj1sq7d4zkxJ6cAj ayn2cB71o7QbEDZULC5drPmL8ZfyJCTG/Vq2QKs4= Message-Id: <6.2.5.6.2.20120817225803.0a507ac8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Aug 2012 23:05:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <7559986.vitorJ0zlv@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <7559986.vitorJ0zlv@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 06:22:47 -0000 At 19:51 17-08-2012, Scott Kitterman wrote: >3.5 specifically states it's extending an example in RFC 1034 (which uses >X.COM), so I think it should stay as is to match the rest of the example. >Since it's in other longstanding RFCs, I think there's no harm in having it >here. Please see https://www.ietf.org/iesg/statement/examples.html I don't think that it is worth arguing about this during an IESG Evaluation. Regards, S. Moonesamy From hsantos@isdg.net Sat Aug 18 00:37: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 08CD621F8527 for ; Sat, 18 Aug 2012 00:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQYANsZYZkBE for ; Sat, 18 Aug 2012 00:37:27 -0700 (PDT) Received: from winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DE20B21F8526 for ; Sat, 18 Aug 2012 00:37:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=796; t=1345275443; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=tUzMx8Z27eEN8Jjy56lsdDTSifs=; b=gz1ji4O95NteK072cvG1 GRWOQTAQqF9wCRe5WZimYSMQBKBOwebq3tAdfNSZ1xq/K0YOkVh+L2HWWXJ1jkvI yp/5qoBM0ArR/qqXAZAvPS5pRRtPWltce3nG/So+6JFywXcODhhH9um6MydHBmxZ lPiLrWluc3SqMHcTZNmxyLA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 03:37:23 -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 1297245183.23649.3708; Sat, 18 Aug 2012 03:37:22 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=796; t=1345275260; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tp3tcRG hvsQMQBpypqpPMQxf/U3zj2dyeV2k+TLjUcI=; b=XRpuNCvuUXS8IN4wlgVn3Od IPGKBqLzrvW7tZYb5HtcKaTRA4wyJgVreHrdPwehdJDrzbZCZDPwNWL1Onz29/S2 bIEUxBNnMSX82OhoAAs1ztzcCKyk7OucfaAKTYuXcrGYEdpTrlZ212e7YFR4ZGn0 S+LmempUOWCeicgGPH1Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 03:34:20 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1896057864.7.8140; Sat, 18 Aug 2012 03:34:19 -0400 Message-ID: <502F4654.2090701@isdg.net> Date: Sat, 18 Aug 2012 03:37:56 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <4206191.rMJEy9IeT9@scott-latitude-e6320> <2391814.NLLl84nT3N@scott-latitude-e6320> In-Reply-To: <2391814.NLLl84nT3N@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 07:37:28 -0000 Scott Kitterman wrote: > On Friday, August 17, 2012 02:46:24 PM Murray S. Kucherawy wrote: > ... >> I'm not liking the idea of identifying specific SMTP reply codes or >> enhanced status codes that should be used for SPF rejections. RFC3463 >> and RFC5321 already define those. We should leave that alone. If we >> want to give examples, that's fine, but I don't think we should be >> normative about it. > ... > > We discussed this before. This was in RFC 4408 (modulo one case that was > accidentally missed and was an erratum), so including this isn't novel. I > view this as part of consistency. I miss what is the case for removing it. Thats a matter of style. I prefer not having multiple documents open. Being specific is terrific, making it easy for readers. -- HLS From hsantos@isdg.net Sat Aug 18 00:42: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 669A321F8557 for ; Sat, 18 Aug 2012 00:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFnnTcHdr847 for ; Sat, 18 Aug 2012 00:42:06 -0700 (PDT) Received: from winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97C0121F8555 for ; Sat, 18 Aug 2012 00:42:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1549; t=1345275723; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zEjFFnIwPhZWBu++S8QOiMHnbXw=; b=OQdEmHu8Rp9VvyLGD3Hu pYDOuKglsFBhIPHpt4mHOYImB56SyE6oSO8VOBt3wX7qMTZXk/cRT0+d0Og0XBiw LS+aS4DYpaIYsQX+prgpwdTH1buDGmvcApds/1KoGdsIHOMSE2x7LjB501WmkFdq SlJNLZplFLCCTMfiPpW66Bw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 03:42:03 -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 1297525221.23649.1068; Sat, 18 Aug 2012 03:42:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1549; t=1345275540; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hw9gA/I 3vg4vW48dLvYNrvlkaGhrtkvyXG0SlKdxS8g=; b=FHQ2WmZJPMY8mrVgcltYmCO /knHsNFdv1kH0kXJnnguf9sHece5qlfUpL+u+WQOUGQL4XaSjRu2Nu4HwUNrK5is E1V8O5M/2ne6DEQT4wvM/qfM+p+XvdXWND/CsgAXVbDhHnpMGDGv2QSO3CLPVtpQ f/o7D4bysxAvsInhUzGU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 03:39:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1896338317.7.5464; Sat, 18 Aug 2012 03:38:59 -0400 Message-ID: <502F476E.5090604@isdg.net> Date: Sat, 18 Aug 2012 03:42:38 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502CED0C.8000506@tana.it> <1943574.YPYx9u0VDs@scott-latitude-e6320> In-Reply-To: <1943574.YPYx9u0VDs@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 07:42:07 -0000 Scott Kitterman wrote: > On Friday, August 17, 2012 01:48:03 PM Murray S. Kucherawy wrote: >> On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: >>> For the negative note: Is it possible to roll back that 5598-based >>> replacement of identity names, _please_? RFC5321.HELO/.EHLO is >>> excessively long and lowers the readability of the document. I don't >>> object on that string appearing in Section 1.3.4. After precisely >>> defining what HELO means, it is not necessary to repeat the whole >>> definition any more. >> I'd settle for something that makes it clear that "HELO Identity" >> elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), >> but I disagree that it's a cumbersome notation. That could just be >> that I'm used to it. > > I'm inclined to put it back, but then that could be just because I'm not used > to it. I'll wait for more feedback. This is among one of the review comment items I will be posting soon. +1. I don't quite like the massive changes to use RFC5321 prefixing from what are otherwise generic SMTP terms well understood for decades. It also places a tight requirement for a specific RFC # when its possible that the # can change in the further. Plus, in good acceptable technical writing style, a first time reference is all that is needed. I don't think we were in trouble with using well understand SMTP terms. It also makes it very redundant, harder to read, to speak out, too technical. Functionality is all that is conveyed. -- HLS From prvs=570d76738=fmartin@linkedin.com Sat Aug 18 02:18: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 8671221F8528 for ; Sat, 18 Aug 2012 02:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kxquEaLWFKd for ; Sat, 18 Aug 2012 02:18:27 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id C116F21F8517 for ; Sat, 18 Aug 2012 02:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1345281507; x=1376817507; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=2n7Geh64iImVKa/y5VoEFheyyspGTrOFs1LpFcvqt0I=; b=fHWnTJAdW3s+pDNr4sGS4lLsUgTw0wC/nuruklRyqGZjx2K5vh0qDhOY UEKWas7s0grG16pNlsaXVU8FuVKHmorGWi7MUsHbVsBfzqDY4Cg41aCw9 ERi4y/lnqJXB3G/5IhvxpjtOsylCHyuYiSHRhuIutGtG92Rqg0omnTuaM o=; X-IronPort-AV: E=Sophos;i="4.77,790,1336374000"; d="scan'208";a="23515674" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 18 Aug 2012 02:18:03 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Sat, 18 Aug 2012 02:18:02 -0700 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] 4408bis update Thread-Index: AQHNe3t7c5GzudzU8EOvpP2RAHS5Cpdc2l0AgAIXNYD//5A3gIAA86uA///YYQA= Date: Sat, 18 Aug 2012 09:18:02 +0000 Message-ID: In-Reply-To: <2305891.WGo84QJhGW@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <088FEFF9D770CD4DB267EC14CD98D930@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 09:18:28 -0000 On 8/17/12 9:40 PM, "Scott Kitterman" wrote: >On Friday, August 17, 2012 09:07:42 PM Franck Martin wrote: >> On 8/17/12 1:48 PM, "Murray S. Kucherawy" wrote: >> >On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely >>wrote: >> >> 9.1.3. *Bounces* >> >>=20 >> >> Zone file generation >>for >> >> =20 >> >> significant numbers of hosts can be consolidated using the redirect >> >> modifier and scripted for initial deployment. Administrators might >> >> alternatively consider publishing an SPF for *.domain (wildcard >> >> domains) in that case if the involved hostnames do not have already >> >> any other DNS record. >> >>=20 >> >> I'd strike the last sentence, or at least recall that wildcard >>records >> >> are discouraged and provide a link to Section 3.5. >> > >> >Indifferent on that suggestion. >> > >> >> Further advice is needed for scripting the zone. For example, >>mention >> >> that any host that has an IP address is a good candidate for an SPF >> >> record; those that do send mail really deserve one; and so forth. >> >> Should we provide a Perl script in an appendix? >> > >> >I don't want to stray too far into operational advice. We're simply >> >describing an algorithm here. The further we go into operational >> >stuff, the more complex this all gets. Including anything more than >> >pseudocode needs to be very carefully considered. >>=20 >> I like the text there, this draws the attention on bounces and similar >> forgotten folklore. >>=20 >> Yes the wildcard thing is a potential issue if you do FCDNS. In rDNS it >>is >> fine. >>=20 >> So instead mentioning wildcard, may be we could simply suggests the >> following simple record for each sending hostname. >> Hostname TXT "v=3DSPF1 a ~all" > >For a sending hostname there's no reason not use -all. If we want to >recommend something that should be it. > >> And for a non sending hostname >> Hostname TXT "v=3DSPF1 redirect=3Ddomain" > >Why would this not be just TXT "v=3DSPF1 -all" > >These are two of the safest SPF records to publish. For them to be wrong >you=20 >either have to get IP addresses of hostnames wrong or have hosts sending >mail=20 >and not know it. If you want to make a recommendation, don't pussyfoot >around=20 >here. > Agreed. I just did not want to look like the usual dictator I am :P From agthisell@yahoo.com Sat Aug 18 07:12: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 7280621F84EC for ; Sat, 18 Aug 2012 07:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzJT1A8zDWLs for ; Sat, 18 Aug 2012 07:12:07 -0700 (PDT) Received: from nm2.bullet.mail.ne1.yahoo.com (nm2.bullet.mail.ne1.yahoo.com [98.138.90.65]) by ietfa.amsl.com (Postfix) with SMTP id 96F5E21F8498 for ; Sat, 18 Aug 2012 07:12:07 -0700 (PDT) Received: from [98.138.90.51] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2012 14:12:03 -0000 Received: from [98.138.89.163] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 18 Aug 2012 14:12:03 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 18 Aug 2012 14:12:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 224045.56949.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 61288 invoked by uid 60001); 18 Aug 2012 14:12:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345299123; bh=5Gg1FCnNMQ/oRX2vDnlVSwQpFtZnN36c1tZKxDiSP1Q=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=itPI0AuRkm5MHhSGAYcDHldLgWXTmzs2Gb71rPuL6JJDmWiJxoy16pUiYXioSagRE4iDmS1AZo5hJ7hOjG68OVV0R9QEL2sxh+zNP/CU8u9KLhycEN5mEYGWb8eScJFFZ+D9bZbk1NHUFjBt/EqeQJYmTzErfggQh3jWJ2OciCU= 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=O2Qf1Ju27UClEwovyIeR51993vpbwsjwW/h3lejUTx/LvqTXvq6WRhPFGqEV0omn8KGk1YDsQTtpwPBqvf75YMYO9GCR1RpxjXnMf1Id2JXJIjJGMGBtLXNyWj7OWVU3m/v3Z36lO7JCvWRjw9n+kyYuyMpM8pglUXijq/1lf3w=; X-YMail-OSG: QIwNQ8MVM1nPQZuGN4wGd9DvVHAI9li1Y6SH8A646ajHRaK tS3Uzg.f3C7.U1X_9_mQtnKhAqOOMtdmhSGL.O4zui7wMUeF6EmiTUwaG6gJ PT5.wxhJwT2In_0nCST2H6q6BnGE2ETF3iHETmFqLerPAQJWvR7wAbj94gnw 8Y0kBGQE52hmfmkKDSC2DxVNPQuBcRfLO0ROHuFvRImnoBWES3aaoW0CeCIP hzhjRdd3f0JGjdW053P7jceWwGQnxXJwJodhFRjoo_WeR77_PM0Hmxc3rS5H noNbO.CQzKQmFfSaUOyUtSYciU6QNMm5hV9wB_jWSzV23wGz3PYuM1vzdEt2 kwjIjvdVq.i1xfsgHjBVy5U1TVRpIh1R.bIh3igHVjQQ.L6zwB9RdoP6HMxK fbAIn1yQeNS1Z_98YmKM4iQnJLIyNr043F9ouGX7g7whj0.wyGvND8zzQlu. jePbQWtV6eVgBTtU9AUw- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 18 Aug 2012 07:12:03 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1345299123.58475.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 18 Aug 2012 07:12:03 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 14:12:08 -0000 >>Does today's message from Arthur Thisell answer this: > >Not really. > >> then isn't it a matter of issuing a query and seeing what >>you get back? If it doesn't meet the relevant requirements to do than, then >>it's got to be a permerror. I'd welcome improved text. > >The problem is that it's ill specified. If you give a resolver >library an invalid domain name, there's no guarantee that it will >politely reject it. It might crash or do other random badness. This >isn't a permerror, since the SPF record might well work if used on a >message with a less nasty bounce address. Waving my hands, I'd >suggest a soft fail if a macro expansion creates an invalid domain >name. OK, I think we need to be very careful with terms here. * "host names" have restrictions defined in various RFCs, and those restrictions have changed over the years. Basically, host names have Letter-Digit-Hyphen restrictions. * "domain names" are things in the DNS and have almost no restrictions beyond what is reiterated in RFC4408bis from DNS RFCs. Basically a null label has to be at the end, no labels more than 63 octets, no more than 253 octets in total. * "stuff commonly thrown at the DNS". This is probably some superset of "host names", but includes things like underscores, all digit labels, etc. Next, any resolver that has any significant use has had random, uninitialized data thrown at it. There were serious proposals for IDNs of just letting UTF-8 being used, but they were ruled out not because of any DNS/resolver problems, but because too many application level programs assumed that all domain names were host names. Last, back before RFC4408 was even being drafted, I did tests on being able to add weird labels to a bind zone file and being able to use dig to look them up, and throwing such labels at libspf2. I don't remember what all I tested, but it was at least labels with "@", "." and " ". We added stuff in RFC4408 about DNS over TCP being less reliable because in real-word tests, we found firewalls that threw out any port 53 traffic that wasn't UDP. Has anyone ever found a real-word resolver that barfs on uncommon domain names? I really resist adding any language to RFC4408bis about "invalid domain names" beyond what the RFCs specify. We don't want to restrict all lookups to being strictly host names. I really don't want to try and define what "common stuff thrown at the DNS" means. Trying to make such a definition would likely yield far more bugs than are in resolvers. I'm really not sure what, if anything, should be added here. Maybe a warning that there might possibly be bugs in some versions of some resolvers that do not handle all domain names? Should we warn about all potential bugs everywhere? I lean toward staying silent until we have some evidence that it is a real problem. >You'd have to find a TCP stack more than 15 years old for TCP sequence >guessing to be a problem. Yeah, I never thought that forging TCP sequence numbers was that much to worry about, but back when RFC4408 was being drafted, problems were more recent. I don't even know if firewalls throwing out port 53 TCP traffic is that common any more. From vesely@tana.it Sat Aug 18 07:31: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 1C1DA21F849B for ; Sat, 18 Aug 2012 07:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWrVlwOQS-N4 for ; Sat, 18 Aug 2012 07:31:29 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6721F849C for ; Sat, 18 Aug 2012 07:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345300286; bh=m1HU1DGZH2xQX2jEDSDCP/DTq08XtL6iGl9WaibEyu0=; l=15599; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WrV5GSPzQNSpl8PyJm45oXAwxx/0j7eA2tXncmi/5lujDNXRqlapJp+pBqatDfkAt rXOVSfUgLvjGhBJLLxye//rfQFysj8+7SOI92s4aXd4OxTJ9WcAO3ta/zkep1quGto BbcfM6w2gmFbMGdcRkyeKDiXwpdCNT2aKEKUUtq8= 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, 18 Aug 2012 16:31:26 +0200 id 00000000005DC039.00000000502FA73E.00001C02 Message-ID: <502FA73D.2040009@tana.it> Date: Sat, 18 Aug 2012 16:31:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502CED0C.8000506@tana.it> <1943574.YPYx9u0VDs@scott-latitude-e6320> In-Reply-To: <1943574.YPYx9u0VDs@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 14:31:31 -0000 On Sat 18/Aug/2012 06:36:52 +0200 Scott Kitterman wrote: > On Friday, August 17, 2012 01:48:03 PM Murray S. Kucherawy wrote: >> On Thu, Aug 16, 2012 at 5:52 AM, Alessandro Vesely wrote: >>> For the negative note: Is it possible to roll back that 5598-based >>> replacement of identity names, _please_? RFC5321.HELO/.EHLO is >>> excessively long and lowers the readability of the document. I don't >>> object on that string appearing in Section 1.3.4. After precisely >>> defining what HELO means, it is not necessary to repeat the whole >>> definition any more. >> >> I'd settle for something that makes it clear that "HELO Identity" >> elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), >> but I disagree that it's a cumbersome notation. That could just be >> that I'm used to it. > > I'm inclined to put it back, but then that could be just because > I'm not used to it. I'll wait for more feedback. >>> Furthermore, >>> if a claimed identity fails verification, local policy can take >>> stronger action against such email, such as rejecting it. >>> >>> Kudos for Section 9.3! Now that we have it, that last sentence in the >>> >>> Introduction can be reworded so as to anticipate it. For example: >>> Furthermore, receivers can devise local policies (Section 9.3) >>> in order to facilitate processing of messages that get specific >>> results; for example, they can whitelist domains that pass the >>> verification, or reject mail that fails it. >> >> I don't know that it's necessary to add that up front. Referring to >> Section 9.3 at this point is sufficient. I just tried to make the reference look smoother. Any change of meaning was unintended. >>> 2.3. *Publishing Authorization* >>> >>> An SPF-compliant domain MUST publish a valid SPF record as described >>> in Section 3. This record authorizes the use of the domain name in >>> the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities by the MTAs it >>> specifies. >>> >>> It is possible to address compliance by ADMD, rather than by domain: >>> An SPF-compliant ADMD MUST publish valid SPF records as described >>> in Section 3. These records authorize the use of the relevant >>> domain names in HELO and MAILFROM identities by the MTAs it >>> specifies. >> >> As above. >> >>> That way, the spec can modulate the requirements about which domains >>> MUST/SHOULD have an SPF record. Until the term "domain" is used >>> interchangeably for a DNS label or an ADMD, wording such requirements >>> is difficult. >> >> The goal of introducing the term "ADMD" is specifically to avoid using >> the terms interchangeably. > > If I used the wrong one in some place, please cite specifics, so I > can look at it and fix it. There are lots of them. Most occurrences of "domain" in sections 2.* and 3 actually mean ADMD, especially "domain owner" or "domain holder". In Section 3.5 the term "zone file" might be better. I'd suggest to dedicate an I-D version entirely to such changes, so as to ease reading the diff. >>> SPF results can be used to make both positive (source is authorized) >>> and negative (source is not authorized) determinations. If domain >>> owners choose to publish SPF records and want to support receivers >>> making negative authorization determinations, then they MUST publish >>> records that end in "-all", or redirect to other records that do, >>> otherwise, no definitive determination of authorization can be made. >>> >>> IMHO, constructs like "If you choose X then you MUST Y" are >>> meaningless. I'll never be able to tell whether you are compliant, >>> unless I have a method to determine what you chose. And since you can >>> always change your mind, the normative sense of the verb is completely >>> lost. >> >> I'm not so sure. I read that as saying "the only way to coerce >> rejection from a receiver willing to do so is to use -all". > > I think it's reasonable to say if you want X, Y is how you get it. I think > that's what this does. I agree with Murray's reading of that snippet. IMHO, the sentence he quotes is much better. It uses no 2119-language, though. Compare it with the worsen rewriting: The RECOMMENDED way to coerce rejection from a receiver willing to do so is to use -all. > It takes the place of a generic "use -all" recommendation in 4408 > that isn't particularly defensible IMO. I agree, otherwise it should be the default. In addition, since -all can only be used by ADMDs that are able to publish a well crafted set of records, we'd have to explain why we prefer that the other ones publish no record at all rather than a coarse ~all. >>> 2.5.4. *Fail* >>> >>> A "fail" result is an explicit statement that the client is not >>> authorized to use the domain in the given identity. Disposition of >>> SPF fail messages is a matter of local policy. See Section 9.3 for >>> considerations on developing local policy. >>> >>> For the sake of clarity, cannot we say explicitly that the receiver >>> "MAY reject the message, according to local policy"? It is what that >>> paragraph is actually saying, except that we force the reader to >>> interpret the term "disposition". I realize that being explicit may >>> emphasize a weakness of SPF, which I hope we'll address later on. >> >> It would be equally correct to say "MAY keep the message, according to >> local policy". While correct that's redundant, since accepting and delivering messages is the normal activity. > I think the text is precisely correct at the moment. It's a matter of local > policy. Period. No more. As part of the protocol I don't think we can do > more. It'd be odd to have no normative statements about rejection, given that that is one of the relevant points of the protocol. >>> As a further point on that snippet, that "given identity" sounds >>> obscure. The result doesn't formally depend on which identity is >>> being checked. >> >> How can it not? >> >> But you could say "the identity under evaluation" or something like that. > > The SPF result would be the same either way (mfrom or helo), but the > implications of it might be different. Yes. > I don't see the benefit in the change, but if people think it would > be better, I'm fine with it. See my next message, in another branch of this thread. >>> 3. *SPF Records* > >>> Since TXT records have multiple uses, beware of other TXT records >>> published there for other purposes. They might cause problems with >>> size limits (see Section 3.4) and care MUST be taken to ensure only >>> SPF records are used for SPF processing. >>> >>> I'd s/ and care MUST be taken/. Verifiers MUST take care/. >> >> Meh. Take it or leave it. > > Me too. IIRC this is unchanged from 4408, so I'd rather leave it unless > there's a real problem. No real problem, both concerns are addressed separately, later in the spec. >>> 3.3. *Multiple Strings in a Single DNS record* >>> >>> As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS >>> record (either TXT or SPF RR types) can be composed of more than one >>> string. >>> >>> s/[RFC1035] sections 3.3.14 and 3.3/Section 5.1 of [RFC1035]/ >> >> Nope. Section 5.1 talks about the zone file format. SPF receivers >> don't get zone files, they get raw DNS data. Uh, I thought it was advice to the publishers. >> The Section 3 references are correct. In that case, may I suggest they be worded as "[RFC1035] Section 3.3.14 and [RFC1035] Section 3.3"? That's to work around a limit of rfcmarkup. >>> 3.4. *Record Size* >>> >>> Why would TCP be less reliable than UDP? >> >> It's not uncommon for operators, out of ignorance, to interfere with >> DNS over TCP because the need for that fallback is historically rare. Fine. Perhaps "[...] that cause DNS over TCP to work intermittently"? That use of "reliable" in a TCP versus UDP discussion sounds odd. >> There were hints of this family of problems in the experiment >> document. Worth a citation? >>> 5.5. *"ptr" (deprecated)* >>> >>> I like the numbered algorithm. It's more readable. >>> >>> Does the grammar allow "ptr:example.com/24"? Step 4 doesn't seem to >>> allow fuzzy IP comparisons based on given CIDR-length. >> >> I don't believe the grammar does allow that. Right, it doesn't. It is "ptr" [ ":" domain-spec ], with no cidr-length. Sorry for doubting. >>> Another question: If there was a {temp/perm}error while doing an A RR >>> lookup, and then the mechanism failed to match, MAY a {temp/perm}error >>> be returned instead of non-match? >> >> Section 4.4 should make it clear that it's only talking about the >> outermost TXT query in the second paragraph. >> >> Section 4.6.2 doesn't actually say what to do in a parent evaluation >> when a child mechanism is being evaluated and the child throws an >> exception; does this exception propagate upward and terminate the >> entire evaluation, or does processing continue? > > It does propagate upward. It has to for consistency. > > In -04 it says: > >> If it matches, processing ends and the qualifier value is returned as >> the result of that record. If it does not match, processing >> continues with the next mechanism. If it throws an exception, >> mechanism processing ends and the exception value is returned. > > I think "mechanism processing ends and the exception value is returned" is > clear, particularly if you look at it in combination with what's in Section > 5.2 on includes: > >> 3. The recursive evaluation returns either match, not match, or an >> error. If it matches, then the appropriate result for the >> include: mechanism is used (e.g. include or +include gives a >> "pass" result and -include gives "fail). > > Does either of those need change to make it clear the error isn't somehow > discarded? Perhaps, a note could be appended to the paragraph after the algorithm, so as to read, say: If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues, but the error is noted so as to eventually return an error code if no match is found. >>> 7. *Recording The Result* >>> >>> It is RECOMMENDED that SMTP receivers record the result of SPF >>> processing in the message header. There are two methods for doing >>> this: the Received-SPF Header Field defined here and the more generic >>> Authentication-Results Header Field defined in [RFC5451]. Because >>> these fields are generally used within a receiving ADMD, it is a >>> local policy choice which to include. In general, the more broadly >>> applicable Authentication-Results Header Field ought to be used, but >>> it SHOULD provide the same information as if a Received-SPF Header >>> Field were used. >>> >>> Is there a reason why "Header Field" is capitalized that way? >> >> It should be lowercased. > > Fixed in all but a few cases where it was part of a title. > >>> I don't think we can be normative-by-cmparison on what information is >>> actually put on the field, because we don't know which tags would have >>> been filled in the Received-SPF field if the latter were used. For an >>> >>> alternative wording: >>> In general, the more broadly applicable Authentication-Results header >>> field ought to be used, as long as it can convey the same >>> information that the verifier would have written in a Received-SPF >>> header field if the latter had been used. >> >> s/as long as it can convey/in such a way that it conveys/ > > Done. > >>> The next paragraph should be split in two: >> +1. > > If so, I don't see it? The idea was two paragraphs instead of one, as exemplified below. >>> See above for the "If ... SHOULD". I'd propose: >>> An SMTP receiver SHOULD use one and only one of these header fields. >>> In case both of them are used, they MUST be consistent with one >>> another. >> >> "one" is enough; "one and only one" is too wordy. That's fine otherwise. I'd like better the short version too, but the meaning is different: "SHOULD use one" was already said at the beginning of the section. "SHOULD use only one" prevents using both (why? See below.) "SHOULD use one and only one" is admittedly too wordy. >>> Note that A-R can convey results for multiple identities within a >>> single header field, so it doesn't make much sense to require to use >>> two of them. >> >> +1. > > I think I cleaned all this up a bit and it should ~OK now. The point here is the phrase "for each identity that was checked" in the second paragraph of Section 7 (before the split). It could be moved to the first sentence of the previous paragraph ("the result of SPF processing for each identity that was checked") --if we decide we won't define a combined result. >>> 7.2. *SPF Results in the Authentication-Results Header Field* >>> >>> We need to discuss this further: > >>> Why overload the "reason" tag? RFC 5451 is extensible and this spec >>> may add any missing tags. >> >> What would you do with the client IP address as its own dedicated part >> of an A-R header field? This was a matter of substantial debate >> during RFC5451's development. If all you want to do is log it or >> include it in Received: fields for information, doing it in CFWS is >> fine. It's useful to register tags of this nature only if something >> will extract that value and attempt to do something more with it. In >> the case of DKIM, for example, one might extract the signing domain, >> compare it to the From: domain, and decide to do something special >> with message presentation there. But providing the IP address, >> something the user never sees, doesn't seem to be a useful thing to >> do. The argument back then is that one might want to evaluate SPF >> again at the MUA, but there was no support for that and plenty against >> it. That's why we didn't do that in the first place. I read part of those threads in mail-vet-discuss. SPF wasn't different at the time, and the same argument seems to be valid here today. Besides "client-ip", A-R only misses "problem", and "mechanism": authserv-id doesn't match "receiver" exactly, but bears the same semantics. The "identity" can be implicit as in: Authentication-Results: receiver.example; spf=pass smtp.mailfrom=sender.example; spf=none smtp.helo=mail.sender.example The explanation is a comment in Received-SPF and can stay that way. > I don't think this is the place to extend RFC 5451 and I also don't > think providing this information in "reason" is overloading at all. > The information I suggest be provided is, in fact, the reason for > the result. It worsens a field that is already difficult to parse, especially if you also add problem and mechanism. Users who currently set those tags in Received-SPF and have software for parsing it downstream will never want to convert it to a new format for whatever reason --and that's why I wouldn't insist on "SHOULD use only one" above. After all, that information is internal to the given ADMD, and the missing info seems to be only relevant for debugging. We have better means to do that, nowadays. If passing those values in the headers is what users really want, so be it. But setting a value to a name=value string to be interpreted on its own is clearly a kludge that we shouldn't even suggest, let alone putting a SHOULD for doing so. From vesely@tana.it Sat Aug 18 07:31:37 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 06DF421F849B for ; Sat, 18 Aug 2012 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqT4RqSPhn7A for ; Sat, 18 Aug 2012 07:31:36 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA121F8499 for ; Sat, 18 Aug 2012 07:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345300295; bh=rLByP+GrlodgefLGi68WPgVV6fju/Nuqlpq7mEpU+dU=; l=2681; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bby4c/Fep5GuzFLpo4jBk/44ZRM70gJPdlJv9kEXcHiCfCfXV4Duvpkq3OmQ61ew3 v14NJ5gP/Oga8WBNFIvL28Mb/xHoOLLA3aTE/mle+BpdTDQYFdGAR4k3MMQxfE5m34 zZhekhufddgZClR0ol+2zJstIFGCCYPjfiiZyflw= 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, 18 Aug 2012 16:31:35 +0200 id 00000000005DC039.00000000502FA747.00001C2D Message-ID: <502FA747.4000309@tana.it> Date: Sat, 18 Aug 2012 16:31:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2822506.PhvcAck8hS@scott-latitude-e6320> <502E7FC7.9020701@isdg.net> <4206191.rMJEy9IeT9@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 14:31:37 -0000 On Fri 17/Aug/2012 23:46:24 +0200 Murray S. Kucherawy wrote: > > I think the current text for "Fail" explains perfectly well that > the option of what to do with the message is left to the receiver, > as it should be. That's what "disposition" is. I beg to disagree. The current wording resembles a generic statement that receivers can do as they like: Disposition of SPF fail messages is a matter of local policy. Does that mean local policy doesn't have a say in case the result is "none"? In other 2.5.x sections we may want to say something like Section 2.5.5 does: Receiving servers SHOULD NOT reject mail based solely on this SPF result. Not "In this case disposition is not a matter of local policy." BTW, there is still a lowercase "should interpret" in the first paragraph of Section 2.5. > If we really want more discussion up in Section 2.5.x, we can make > reference down to Section 9.3.2 which discusses the point in more > detail. A reference to Section 9.3 is there already. > I'm not liking the idea of identifying specific SMTP reply codes or > enhanced status codes that should be used for SPF rejections. RFC3463 > and RFC5321 already define those. We should leave that alone. If we > want to give examples, that's fine, but I don't think we should be > normative about it. +1! In addition, the current spec doesn't mention that a server may want to decline a whole session as a result of a failed HELO check. SHOULD a server reject each and every transaction instead? Although this was in RFC 4408 and not novel, the relevant SMTP text was moved from Section 3.7 of RFC 2821 to its own Section 3.6.2 of RFC 5321, where the "policy reasons" are further characterized by using the term "SPF". Repeating normative parts introduces ambiguity as to whether the two protocols overlap. >>> When the MARK-ON-FAIL option is used, it server SHOULD report this failure >>> by adding a Receiver-SPF header to the received message. See Section 7. > > This is covered elsewhere already. Correct, just in Section 7's opening words. >> I do not like the idea of introducing the all caps terms MARK-ON/REJECT-ON, so >> I haven't used them in my update. I think they come across as shouting and >> are distracting. If anyone else thinks I should, please speak up. > > I agree, don't do it. +1. However, a note somewhere in Section 1.3 might say: We use the verb "reject" in predicates involving email messages or sessions as a shortcut for rejecting the corresponding SMTP [RFC5321] commands; that is, replying a 5xx code to them. The phrase "temporarily reject" indicates 4xx codes instead. From johnl@iecc.com Sat Aug 18 08:15: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 BB6CC21F84A5 for ; Sat, 18 Aug 2012 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.144 X-Spam-Level: X-Spam-Status: No, score=-111.144 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1zLCROxTsw7 for ; Sat, 18 Aug 2012 08:15:34 -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 8AEC421F84A1 for ; Sat, 18 Aug 2012 08:15:34 -0700 (PDT) Received: (qmail 84965 invoked from network); 18 Aug 2012 15:15:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 15:15:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=502fb193.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=Nd8lA7bdtzOf/sodzc3CRfSTK0UrXOeLJO9AIhFSVZ0=; b=egB7zgGgohStznRpFZFs02Wjz1xAdbJdGizIg4JRwLX6aIp2TgB/xea0qRI97EpTZsCSq9yLnLD3pPxa8R6j3QmxcNKlg872npE8PNpD4MWuHQl79Rl3EBula1CkfKImZOhF7oj3wx/ZkgZYq0xGBBCx+E5Tibu7VNGakryyUt4= 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=502fb193.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=Nd8lA7bdtzOf/sodzc3CRfSTK0UrXOeLJO9AIhFSVZ0=; b=CIudDk/xDDPRHPNaqjJ6dhQOqAEmTc6rsC30OYuHa9MwE8U0s7GlBcAvPILYEbvJded4NMRkNXeVVReNhE+cHfdkzVpnrDckc+V3xdnBo5s9D8t7qhfpNjF9yoLBsGexZNEVRTDuzujhZRrsrGjudv2SAnp6+sr6Y/5BSXPULog= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 15:15:09 -0000 Message-ID: <20120818151509.65059.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1943574.YPYx9u0VDs@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 15:15:35 -0000 >> I'd settle for something that makes it clear that "HELO Identity" >> elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), >> but I disagree that it's a cumbersome notation. That could just be >> that I'm used to it. > >I'm inclined to put it back, but then that could be just because I'm not used >to it. I'll wait for more feedback. It reads better if you put it back. Anyone who can't understand that the HELO identity can come from either HELO or EHLO is unlikely to be able to understand the rest of the document, either. R's, John From dhc@dcrocker.net Sat Aug 18 08:29: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 54FA021F8498 for ; Sat, 18 Aug 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ins-taOsjj3V for ; Sat, 18 Aug 2012 08:29:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 393FC21F848A for ; Sat, 18 Aug 2012 08:29:51 -0700 (PDT) Received: from [172.17.143.202] (50-78-155-157-static.hfc.comcastbusiness.net [50.78.155.157]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7IFTmUQ007685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Aug 2012 08:29:50 -0700 Message-ID: <502FB4DF.7090803@dcrocker.net> Date: Sat, 18 Aug 2012 11:29:35 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: John Levine References: <20120818151509.65059.qmail@joyce.lan> In-Reply-To: <20120818151509.65059.qmail@joyce.lan> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 18 Aug 2012 08:29:50 -0700 (PDT) Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] 4408bis update 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: Sat, 18 Aug 2012 15:29:52 -0000 On 8/18/2012 11:15 AM, John Levine wrote: >>> I'd settle for something that makes it clear that "HELO Identity" >>> elsewhere means RFC5321.HELO or RFC5321.EHLO (whichever is available), >>> but I disagree that it's a cumbersome notation. That could just be >>> that I'm used to it. >> >> I'm inclined to put it back, but then that could be just because I'm not used >> to it. I'll wait for more feedback. > > It reads better if you put it back. Anyone who can't understand that > the HELO identity can come from either HELO or EHLO is unlikely to be > able to understand the rest of the document, either. There is a pattern of confusion about transport commands vs. message field names. the spec.name convention disambiguates. Use of the name alone makes sense when the context has been set. Using the name alone without setting that context (by an initial use of the qualified name) invites confusion even when the name is unique. As for HELO vs. EHLO, they really are two different 'commands'. Hence, saying HELO is a precise reference that excludes EHLO, even though that's not what's meant. Would that we had the practice of saying SMTP Greeting, or some other generic term. I'll suggest RFC5321.[E]HELO as a compromise. Really demanding sticklers might be more comfortable with RFC5321.HELO/EHLO d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Sat Aug 18 08:37:02 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 3CF1E21F849D for ; Sat, 18 Aug 2012 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rousf-1aEirt for ; Sat, 18 Aug 2012 08:37:01 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2B021F84A1 for ; Sat, 18 Aug 2012 08:36:58 -0700 (PDT) Received: (qmail 89325 invoked from network); 18 Aug 2012 15:36: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:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15cec.502fb699.k1208; bh=DFFnls+VJTC2HJbJzN6mvsjiDKQCtPK1Uuh15rcw1fU=; b=cNJLXxOqt3AQQmrS+nRiX5XHPDNywfYVG8ohX89UjnUXu/rNdWW85QD9Phas9qLxJCUY+bwHMJho8Y4ELlyGV/ECa6wOpTn3puvJik5rnEQIWKlWtBGKoLhMhWYRLIHHUvP5ndlWTsG0+rbk3FUwPWiy6/7je0yJriTYF66nQvM= 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=15cec.502fb699.k1208; bh=DFFnls+VJTC2HJbJzN6mvsjiDKQCtPK1Uuh15rcw1fU=; b=UFbuNW9kqrtrU8mMZ+Yt4dUf6HkPy4YlsPyTQWxQ8Cx7xn8I2N7gPO5Pj0C1tYpYo28OxHi7G9F69m/eAgp0mNFALgbdxFHdMsDLoOqlAQpnIUgtYnkkM8EO9F+bpStROrMcGjloG1ci2xxVsTZ4F+LtAsrUWPfUIufuXV63omA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 18 Aug 2012 15:36:35 -0000 Date: 18 Aug 2012 11:36:57 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <502FB4DF.7090803@dcrocker.net> References: <20120818151509.65059.qmail@joyce.lan> <502FB4DF.7090803@dcrocker.net> 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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 15:37:02 -0000 > Really demanding sticklers might be more comfortable with RFC5321.HELO/EHLO This grouch thinks it would be nice to say something like "The HELO identity is the RFC5321.HELO or RFC5321.EHLO field from the beginning of the SMTP session" and thereafter say something less stilted. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From vesely@tana.it Sat Aug 18 09:17: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 2879321F8438 for ; Sat, 18 Aug 2012 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.615 X-Spam-Level: X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDiBzMjcw7v3 for ; Sat, 18 Aug 2012 09:17:37 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8B21F8455 for ; Sat, 18 Aug 2012 09:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345306655; bh=VDIOlz6c4/nMWMz+H6Ff0GhrKrlrF9ez+FIgV1LktXw=; l=5166; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Fnpm3L3vCzsXQXxuVtcegZGfGA58K6dPmafMIHEE8F71yzpFt1b/oz62mDXc/2wcc r9UmNlSYrampWzTXwMW+0Go6vCoR8kfv/pN5IVyYmJr9FCGbJyEh4qCXFWXGn7bA++ wpcD63hw/aW/8fzh8Ywa9VNUgjUgRjfrZT/NHFmY= 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, 18 Aug 2012 18:17:35 +0200 id 00000000005DC039.00000000502FC01F.000032FA Message-ID: <502FC01F.8050509@tana.it> Date: Sat, 18 Aug 2012 18:17:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:17:38 -0000 On Sat 18/Aug/2012 00:38:17 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 16, 2012 at 11:58 AM, Alessandro Vesely wrote: >> Briefly, adopting SPF implies a conundrum of endlessly repeated >> philosophical principles like "No, it is the {sender|receiver} who >> should do so and so." A protocol that people can adhere to should not >> cause such issues, or at least indicate a quick way to solve them. > > I appreciate the fact that there are people out there who want the > silver bullet. For some people, SPF is that. That simply is not true > for everyone. I have yet to work for any company (and I now work for > a pretty huge one in terms of mail flows) where either it or its > customers enabled SPF to reject on "fail", for example. I wouldn't strive for a silver bullet, but regular ammo, at least, rather than a naked gun, would seem to be advisable. > The common point to both of these groups is that SPF's results are > input to an overall evaluation of a message. For people that think > SPF completely solves the problem, their evaluation system consists > solely of SPF, and they do reject-on-fail. It works for them and > that's fantastic. There exists, however, a substantial population > that wants more than one piece of information to decide upon the fate > of a message. The most common reason for that appears to involve SPF's > known failure modes, but it's not for us to speculate on what those > people have in mind. Agreed. Scott mentioned the pros and cons of both approaches, recently. > However, it's important to note that the basic premise I stated above > holds true for both camps. Accordingly, the best this document (or > any other that specifies something which isn't a silver bullet) can do > is make those data available to the operator, accompanied by some > pedagogy on the surrounding subject matter, and let the operator > decide what to do with it. I think that's what we're doing here, as > we did with other email authentication work, and as 4408 itself did. > It's the right approach. Agreed, except that "the document defines a protocol" is a little more than making the data --the protocol's results-- available. In particular, SPF defines both the policy and the algorithm to get the results. > Thus, it is absolutely the case that this lands us in a space of > presenting what you call philosophical principles. But I don't think > we can or should do any better than that. So we simply need to do as > good a job of that as possible, and then stop. I read that as trying to avoid opening cans of worms larger than what we are prepared to deal with. > So back to the topic of writing a protocol document: The protocol, > then, comprises the steps to collect the inputs to the algorithm, > execution of the algorithm, the output of the algorithm, and how to > deal with exceptions. As my high school English teachers used to say: > precise and concise. I think we're doing that here. Yes. > All this stuff about doing some things as system settings and others > as user settings, picking different evaluation points, rewriting > envelopes and HELO, etc., really complicates what's supposed to be a > protocol document. If we're seriously inclined to push all of that > architecture advice on the reader, I suggest we consider moving all of > that to a separate document that we develop once this one publishes > and we re-charter to cover it. Or if it's already written down in an > existing document, just refer to that. I'd like the idea of a deployment guide. But we cannot say "a receiver can shoot itself in the foot if it wishes to do so", whatever the language (and bullets) we use. The workaround I suggested, helo-pass prevents rejection, isn't really that complicate. It can be explained precisely and concisely within a single short paragraph. But different participants dislike it, for different reasons that I never fully understood. There's plenty of other ways. For example, the receiver could check a DNSWL before rejecting, and advertize which one it uses. Instead, Section 9.3.2 suggests that "the sender [...] might then be able to resolve the issue". What if it is not able to do so, discuss for ever? > On the particular topic of forwarding, I think RFC5321 Section 3.9.1 > is just fine. SMTP works fine the way it is with respect to alias > expansion; SPF is in effect an overlay on top of it in this regard. > We can say that an alias expander wishing to ensure SPF passes can do > what's suggested in ticket #12, but go no further. RFC5598 talked > about alias expansion in more detail if we're in need of references to > more material on the topic. Neither Section 3.9.1 of RFC 5321 nor Section 5.1 of RFC 5598 consider it makes a difference whether the expanded aliases land within the same ADMD or to external domains. It makes a relevant difference for SPF. If we don't update that, we should make it clear that applying local policy is an arbitrary and unilateral action that interferes with mail delivery. At least, that will save people useless discussions. From spf2@kitterman.com Sat Aug 18 09:25: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 7F58221F8498 for ; Sat, 18 Aug 2012 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WB3KElymE4Q for ; Sat, 18 Aug 2012 09:25:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D99E821F8494 for ; Sat, 18 Aug 2012 09:25:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D7D9120E4091; Sat, 18 Aug 2012 12:25:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345307122; bh=k/Niu0jV3USKzo+7/kdIeUW8iivcXE9EivO88H5YYFw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hvaLwqgGy6ljiK6RHALQZSG7EiKXxZ7u6viAKlpnvDHwk//nuuvQi341qPw4XFs9P HYUEJ/pHz5qQHeDoD3LyaU7AX8gzZQNAsJuldmy5G10H5yujrd/VC9Xe5v1ql0AdM0 poIKAV+DDRBJZHJrzfcfu6nn7i3plRPqdB3epJVc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B13CD20E4071; Sat, 18 Aug 2012 12:25:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 12:25:21 -0400 Message-ID: <5003497.dxG3XNAxyi@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120817225803.0a507ac8@resistor.net> References: <20120817034603.20684.qmail@joyce.lan> <7559986.vitorJ0zlv@scott-latitude-e6320> <6.2.5.6.2.20120817225803.0a507ac8@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:25:24 -0000 On Friday, August 17, 2012 11:05:53 PM S Moonesamy wrote: > At 19:51 17-08-2012, Scott Kitterman wrote: > >3.5 specifically states it's extending an example in RFC 1034 (which uses > >X.COM), so I think it should stay as is to match the rest of the example. > >Since it's in other longstanding RFCs, I think there's no harm in having it > >here. > > Please see https://www.ietf.org/iesg/statement/examples.html I don't > think that it is worth arguing about this during an IESG Evaluation. The statement speaks of harm. Since this exact information is already in RFC 1035, there is no harm. Was this message sent as chair or participant? Scott K From spf2@kitterman.com Sat Aug 18 09:26: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 2696821F8498 for ; Sat, 18 Aug 2012 09:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+wQb6vUNrTu for ; Sat, 18 Aug 2012 09:26:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AC4DE21F8494 for ; Sat, 18 Aug 2012 09:26:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2FBC520E4091; Sat, 18 Aug 2012 12:26:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345307206; bh=nIQlq+0JdYjqjwR6mUqc80RbXOo4EM0RbK1moPY7Qw4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F8gAJphnPfn9eiM/qy5UiiJ87QV9XLUlp7NQwP/7++ZvbkMFJdpvPBZwuRQEGRwLj mo6uKgXC8szlgDe/GxxSAiGNwJp6JsIw0F66n2rYwm3TBcOvD3e/zQPqgfdG7flwhp F7kuX0UVaFh52nSLlQN/h8rAihKAhTKpo0Nd2fjs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1B45B20E4071; Sat, 18 Aug 2012 12:26:46 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 12:26:45 -0400 Message-ID: <2019308.MtKQSGQXFr@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120818151509.65059.qmail@joyce.lan> <502FB4DF.7090803@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:26:47 -0000 On Saturday, August 18, 2012 11:36:57 AM John R Levine wrote: > > Really demanding sticklers might be more comfortable with > > RFC5321.HELO/EHLO > > This grouch thinks it would be nice to say something like "The HELO > identity is the RFC5321.HELO or RFC5321.EHLO field from the beginning of > the SMTP session" and thereafter say something less stilted. This one too. Scott K From superuser@gmail.com Sat Aug 18 09:39: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 D32CD21F84AF for ; Sat, 18 Aug 2012 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoosqMcCCe92 for ; Sat, 18 Aug 2012 09:39:53 -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 F106821F84A6 for ; Sat, 18 Aug 2012 09:39:52 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2770181lbb.31 for ; Sat, 18 Aug 2012 09:39:52 -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=hXXjtni/f/vtq2uyBTwOpwjUYVGb2KnS9L+SERcJXmE=; b=iJ+E+3+D8KMGx4tJybYcP4ltqX6MKF04W7oBYh123jPyM5i5FL91WNE8QQIqW1BKLA AL1PJAICcWC+6v0emTI6Xv9cNUx1EUFWnzenqwCfLI2suGZXaWBD3xKzFcEeRhuY/L6Z 4TCUeneh04ox+KBJp2KitJiRNKNyR33T+Q8FeJETO5c1AjKTyXLCyEfplowuWwKqRuPt ZVC+1ZcjZGwXmnmf9Pq8ASQtxKzBS2KTdUrpYCfqaA5a66qjrA8J02aWshJg7O6Z8jiK LavTlfl1j7IZMVpsvbiKrQ7wDASwTyEl4URcBTVtPhQ20QY+V4BJ74QE+j6fUMjj4t3H cLAg== MIME-Version: 1.0 Received: by 10.112.29.131 with SMTP id k3mr3913695lbh.53.1345307991882; Sat, 18 Aug 2012 09:39:51 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 18 Aug 2012 09:39:51 -0700 (PDT) In-Reply-To: <502FC01F.8050509@tana.it> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <502FC01F.8050509@tana.it> Date: Sat, 18 Aug 2012 09:39:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:39:53 -0000 On Sat, Aug 18, 2012 at 9:17 AM, Alessandro Vesely wrote: > Agreed, except that "the document defines a protocol" is a little more > than making the data --the protocol's results-- available. In > particular, SPF defines both the policy and the algorithm to get the > results. Yes, but SPF cannot demand enforcement of that policy. >> Thus, it is absolutely the case that this lands us in a space of >> presenting what you call philosophical principles. But I don't think >> we can or should do any better than that. So we simply need to do as >> good a job of that as possible, and then stop. > > I read that as trying to avoid opening cans of worms larger than what > we are prepared to deal with. That's certainly true. > I'd like the idea of a deployment guide. But we cannot say "a > receiver can shoot itself in the foot if it wishes to do so", whatever > the language (and bullets) we use. We certainly can say that, by presenting the landscape in which this operates. Hopefully the reader then makes an intelligent decision, and we can encourage this in the way we write. > The workaround I suggested, helo-pass prevents rejection, isn't really > that complicate. It can be explained precisely and concisely within a > single short paragraph. But different participants dislike it, for > different reasons that I never fully understood. What I want us to avoid is presenting a pile of things that, individually, are not that complicated, but as a group they simply give the reader far too many variants of basic SPF to consider. > There's plenty of other ways. For example, the receiver could check a > DNSWL before rejecting, and advertize which one it uses. Instead, > Section 9.3.2 suggests that "the sender [...] might then be able to > resolve the issue". What if it is not able to do so, discuss for ever? That's further added complication. This shouldn't be in the protocol document. > Neither Section 3.9.1 of RFC 5321 nor Section 5.1 of RFC 5598 consider > it makes a difference whether the expanded aliases land within the > same ADMD or to external domains. It makes a relevant difference for SPF. SMTP is relevant to SPF, but SPF is irrelevant to SMTP. That's why an update is the wrong thing to do. > If we don't update that, we should make it clear that applying local > policy is an arbitrary and unilateral action that interferes with mail > delivery. At least, that will save people useless discussions. I'm sure it's not arbitrary to the receiver, but the rest of that sounds right to me. -MSK From spf2@kitterman.com Sat Aug 18 09:51:29 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 5DE7921F84C5 for ; Sat, 18 Aug 2012 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GUoK4ghC+3l for ; Sat, 18 Aug 2012 09:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B697721F84A6 for ; Sat, 18 Aug 2012 09:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 38ADC20E4091; Sat, 18 Aug 2012 12:51:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345308688; bh=LImh4Fl6jfDW0nUKOp4Vy1TV4gYIj91xNpiAS2jeiFY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kfPDQKjSXjSsIAwe/sr/YWDnj9m+BoGGgsGzvhkLBcxvrOZbhp3430XSz04aIYUQi dWAHVM6sun6GTt6opt2AE1Gd0MDB24CidKwUU2tqfGm4kc4Tvv8Kal2KjNESMDABcl dzNGDHNlgkny+8xzg0T7rNbPNsOSFGGhO1ODZ0/k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0F3C720E4071; Sat, 18 Aug 2012 12:51:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 12:51:26 -0400 Message-ID: <1733770.Hb4tYKEB6O@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:51:29 -0000 On Saturday, August 18, 2012 09:18:02 AM Franck Martin wrote: > On 8/17/12 9:40 PM, "Scott Kitterman" wrote: > >On Friday, August 17, 2012 09:07:42 PM Franck Martin wrote: ... > >> So instead mentioning wildcard, may be we could simply suggests the > >> following simple record for each sending hostname. > >> Hostname TXT "v=SPF1 a ~all" > > > >For a sending hostname there's no reason not use -all. If we want to > >recommend something that should be it. > > > >> And for a non sending hostname > >> Hostname TXT "v=SPF1 redirect=domain" > >Why would this not be just TXT "v=SPF1 -all" > >These are two of the safest SPF records to publish. For them to be wrong > >you > >either have to get IP addresses of hostnames wrong or have hosts sending > >mail > >and not know it. If you want to make a recommendation, don't pussyfoot > >around > >here. > > Agreed. > > I just did not want to look like the usual dictator I am :P I've included something similar to this for the next draft. Please have a look when I've published it. Scott K From spf2@kitterman.com Sat Aug 18 09:58: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 DD8BA21F848F for ; Sat, 18 Aug 2012 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3LFI92dFQ1I for ; Sat, 18 Aug 2012 09:58:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9721F847F for ; Sat, 18 Aug 2012 09:58:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C44F720E4091; Sat, 18 Aug 2012 12:58:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345309089; bh=JqppBhBeOtB7CwpTnzSjvd16uW+6mRNdbMVgZIMlXaw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mM7NeXSg7aVgLh8GvYh1jY1RCirGnD9zoTmv+gWwwvq6XEqPFx6MmS+vHoy0KpScX y1bF27dr4tzgE06BidOp7Yge6cAoO4Yg8S+7RxX4v7JqAO9lN1XQZ1XUrbXZnG/jxF zCm+xA8+IAMfpmdjQ8hZvjJu/W9rkrv+eYO0TD7I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AE54920E4071; Sat, 18 Aug 2012 12:58:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 12:58:08 -0400 Message-ID: <6796846.KG974O4WuX@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1345299123.58475.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1345299123.58475.YahooMailClassic@web125403.mail.ne1.yahoo.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 16:58:11 -0000 On Saturday, August 18, 2012 07:12:03 AM Arthur Thisell wrote: ... > Yeah, I never thought that forging TCP sequence numbers was that much to > worry about, but back when RFC4408 was being drafted, problems were more > recent. I don't even know if firewalls throwing out port 53 TCP traffic > is that common any more. It's sufficiently common that we still need to warn about it, IMO. There are also resource considerations that also make UDP preferred even if reliability weren't a concern. Scott K From spf2@kitterman.com Sat Aug 18 10:00: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 D0FAF21F84B2 for ; Sat, 18 Aug 2012 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a15tIIHRj+4e for ; Sat, 18 Aug 2012 10:00:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 591C721F848F for ; Sat, 18 Aug 2012 10:00:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D202420E4091; Sat, 18 Aug 2012 13:00:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345309229; bh=Y6n7PBFChRgNEOjzNzK+3bJybqXcGX6nb96QFD02/ro=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jcwCGiNAxy99yTE+MZmUkDEXhZMMlrn21HuwjmrdIytlKrfhA+KMTaHDggCDIBgDL nKtIbsb4zS9MCG9RzgaJ5a46A/Vc/p4HCisHO/RK8CWWrYg7asMotGJuqM/1E3YDnx S99oOl5GR9/F9Lh394TgXjdzSMyJ/R+SQxXoVkLI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AB18720E4071; Sat, 18 Aug 2012 13:00:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 13:00:28 -0400 Message-ID: <2776189.eUBS9SyEHi@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502FC01F.8050509@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 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:00:30 -0000 On Saturday, August 18, 2012 09:39:51 AM Murray S. Kucherawy wrote: > > If we don't update that, we should make it clear that applying local > > policy is an arbitrary and unilateral action that interferes with mail > > delivery. At least, that will save people useless discussions. > > I'm sure it's not arbitrary to the receiver, but the rest of that > sounds right to me. Right. It's supposed to interfere with mail delivery. Scott K From spf2@kitterman.com Sat Aug 18 10:02: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 E1E2F21F8468 for ; Sat, 18 Aug 2012 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUW24whCEmfw for ; Sat, 18 Aug 2012 10:02:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9E21F8466 for ; Sat, 18 Aug 2012 10:02:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9D48B20E4091; Sat, 18 Aug 2012 13:02:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345309360; bh=xL1lTGqjXgf2cUh1Z7DFF2fJCbEjPNZpmvfVfLl+YbE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eECm+nt2/PfaBZgvAvLvLe3YD63M7wYi2aySbwVvy5StiFfraOaSEtCu5R44B0rL+ 1vor31HyF1Qwslcaj7/xVBZBVmHJJKLtvMfFgbPzw0WzmPIYOlRQPcgV12EeTlGQRE CYEhAuIzVwU0AO9CmuPAX8d/Y2MiffbHwEkOx5E8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6F39120E4071; Sat, 18 Aug 2012 13:02:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 13:02:39 -0400 Message-ID: <4948346.vhSgBJIQcB@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502FA73D.2040009@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <1943574.YPYx9u0VDs@scott-latitude-e6320> <502FA73D.2040009@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:02:42 -0000 On Saturday, August 18, 2012 04:31:25 PM Alessandro Vesely wrote: > >> The goal of introducing the term "ADMD" is specifically to avoid using > >> the terms interchangeably. > > > > > > > > If I used the wrong one in some place, please cite specifics, so I > > can look at it and fix it. > > There are lots of them. Most occurrences of "domain" in sections 2.* > and 3 actually mean ADMD, especially "domain owner" or "domain > holder". In Section 3.5 the term "zone file" might be better. > > I'd suggest to dedicate an I-D version entirely to such changes, so as > to ease reading the diff. Or: I uploaded the XML with -04 so if someone wants to send me a patch, that'd be lovely. Scott K From spf2@kitterman.com Sat Aug 18 10:10: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 578FF21F8495 for ; Sat, 18 Aug 2012 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJq4EU-Yb+IN for ; Sat, 18 Aug 2012 10:10:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A0A4E21F8494 for ; Sat, 18 Aug 2012 10:10:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2042C20E4091; Sat, 18 Aug 2012 13:10:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345309806; bh=keZofhT+8+ae0AllH1kA1QDygQ49YoWfZJk0R3s8n7Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nyI2351gLoMpLdZmDWzD+PqC2xGfChPfo9Vl6aCnqoDKyhyCdalSXfpA2T39icKJZ 9vwBWiegFh1k0qwzRej0gIGDpuaJ24O3YNtUnp+qvjPluva9FIOueqYd4AKfhS1GlW Eaf0Q2BS3wnIIEYMaKL6wM8cNA+OQbQg8HOeSJI4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F235020E4071; Sat, 18 Aug 2012 13:10:05 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 13:10:04 -0400 Message-ID: <1876046.SJ0VbSqUoN@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502FA73D.2040009@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <1943574.YPYx9u0VDs@scott-latitude-e6320> <502FA73D.2040009@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:10:09 -0000 On Saturday, August 18, 2012 04:31:25 PM Alessandro Vesely wrote: > >>> For the sake of clarity, cannot we say explicitly that the receiver > >>> "MAY reject the message, according to local policy"? It is what that > >>> paragraph is actually saying, except that we force the reader to > >>> interpret the term "disposition". I realize that being explicit may > >>> emphasize a weakness of SPF, which I hope we'll address later on. > >> > >> > >> > >> It would be equally correct to say "MAY keep the message, according to > >> local policy". > > While correct that's redundant, since accepting and delivering > messages is the normal activity. Your ham/spam ratio must be much higher than mine. I think in most cases 'bad' mail significantly outnumbers good mail and figuring out how not to deliver those message is the predominate activity. Given that the next paragraph starts with "If the checking software chooses to reject the mail ..." I don't think adding what you proposed says anything that isn't already said. That and no matter what we say in 4408bis, receivers can reject whatever they want anyway. With my free software developer hat on, I've had feature requests to enable rejecting mail from all domains that don't publish SPF records (I said no, there's a limit to the degree of foot shooting I'm willing to write code for). I don't think anyone is confused that the possibility of rejection doesn't exist. Scott K From spf2@kitterman.com Sat Aug 18 10:40:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF5321F8489 for ; Sat, 18 Aug 2012 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lScIBJIwB-3o for ; Sat, 18 Aug 2012 10:40:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2024F21F847F for ; Sat, 18 Aug 2012 10:40:04 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7B1E520E40A6; Sat, 18 Aug 2012 13:40:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345311603; bh=Jtb2B0qSQX13iMaL5RZN9kZOHc6EyjRfq+7B3pljioY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F58H8brtg189tpOEDsRwstAGaLUhrZOM9xlvUdKyw2QRR7N40bUNxXuyXkYjUftoy tXV+H/HxWx6UypeizYfv8/noJgWYXsyaKogqArCh14lPm7ozUhdobDQYcalagFnepy yqexepuEzBTYPw4UmFLWFMPHphltpmnqQKqRtWIY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4D99B20E4091; Sat, 18 Aug 2012 13:40:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 13:40 -0400 Message-ID: <2609549.aGaQhnMI7j@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <502FA747.4000309@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:40:05 -0000 On Saturday, August 18, 2012 04:31:35 PM Alessandro Vesely wrote: > On Fri 17/Aug/2012 23:46:24 +0200 Murray S. Kucherawy wrote: > > I think the current text for "Fail" explains perfectly well that > > the option of what to do with the message is left to the receiver, > > as it should be. That's what "disposition" is. > > I beg to disagree. The current wording resembles a generic statement > that receivers can do as they like: > > Disposition of SPF fail messages is a matter of local policy. It does and it's correct. Receivers can do as they like. They don't get to decide how to determine if an SPF result is "fail", that is standardized, but once they have that result they get to decide what to do with it. > Does that mean local policy doesn't have a say in case the result is > "none"? In other 2.5.x sections we may want to say something like > Section 2.5.5 does: > > Receiving servers SHOULD NOT reject mail based solely on this > SPF result. > > Not "In this case disposition is not a matter of local policy." If there's no SPF result there can be no SPF related policy, so I don't see a need for a change. > BTW, there is still a lowercase "should interpret" in the first > paragraph of Section 2.5. Fixed. > > If we really want more discussion up in Section 2.5.x, we can make > > reference down to Section 9.3.2 which discusses the point in more > > detail. > > A reference to Section 9.3 is there already. > > > I'm not liking the idea of identifying specific SMTP reply codes or > > enhanced status codes that should be used for SPF rejections. RFC3463 > > and RFC5321 already define those. We should leave that alone. If we > > want to give examples, that's fine, but I don't think we should be > > normative about it. > > +1! In addition, the current spec doesn't mention that a server may > want to decline a whole session as a result of a failed HELO check. > SHOULD a server reject each and every transaction instead? I think that's up to local policy/an implementation detail. HELO/EHLO can change during a session, so it's not axiomatic that one should. > Although this was in RFC 4408 and not novel, the relevant SMTP text > was moved from Section 3.7 of RFC 2821 to its own Section 3.6.2 of RFC > 5321, where the "policy reasons" are further characterized by using > the term "SPF". Repeating normative parts introduces ambiguity as to > whether the two protocols overlap. Perhaps. I agree it's reasonably obvious what one should pick for the SMTP reply code. For enhanced status codes, it's much less clear. Reviewing http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced- status-codes.xml does not lead me to one obviously correct solution. I think providing additional specificity is useful. > >>> When the MARK-ON-FAIL option is used, it server SHOULD report this > >>> failure > >>> by adding a Receiver-SPF header to the received message. See Section 7. > > > > This is covered elsewhere already. > > Correct, just in Section 7's opening words. > > >> I do not like the idea of introducing the all caps terms > >> MARK-ON/REJECT-ON, so I haven't used them in my update. I think they > >> come across as shouting and are distracting. If anyone else thinks I > >> should, please speak up.> > > I agree, don't do it. > > +1. However, a note somewhere in Section 1.3 might say: > > We use the verb "reject" in predicates involving email messages or > sessions as a shortcut for rejecting the corresponding SMTP > [RFC5321] commands; that is, replying a 5xx code to them. The > phrase "temporarily reject" indicates 4xx codes instead. Since we have the SMTP reply and enhanced status codes, I think this is already clear. If removing them would make this unclear, I think that's another reason not to remove them. Scott K From vesely@tana.it Sat Aug 18 10:52: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 3F2A621F8470 for ; Sat, 18 Aug 2012 10:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.617 X-Spam-Level: X-Spam-Status: No, score=-4.617 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1xbZiLul3u0 for ; Sat, 18 Aug 2012 10:52:46 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B221F845F for ; Sat, 18 Aug 2012 10:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345312365; bh=aX0+ONgNDVxWeng0FroK0lFGPNb0PB9r0T3Wj45l62I=; l=2969; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IOubBUII/6zUWLt8yXufXdzD/taa5BRZ/og4RNjUqvumgiOZJrWC66RH1+XFEtQ+I F3rbWPBwHv3jEebHvR9Fo9kFC8ktLfVMkjY4xU6IKKu6bfSp3ZytJyelwp0V9Kwr00 cumHc9uJKDUIvkuvYiewMzhUzscRviGd2rd4ihqU= 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, 18 Aug 2012 19:52:45 +0200 id 00000000005DC039.00000000502FD66D.00004797 Message-ID: <502FD66C.40607@tana.it> Date: Sat, 18 Aug 2012 19:52:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <502FC01F.8050509@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:52:47 -0000 On Sat 18/Aug/2012 18:39:51 +0200 Murray S. Kucherawy wrote: > On Sat, Aug 18, 2012 at 9:17 AM, Alessandro Vesely wrote: >> Agreed, except that "the document defines a protocol" is a little more >> than making the data --the protocol's results-- available. In >> particular, SPF defines both the policy and the algorithm to get the >> results. > > Yes, but SPF cannot demand enforcement of that policy. Of course not. It just says a receiver may enforce it, albeit it currently doesn't spell "MAY". >> I'd like the idea of a deployment guide. But we cannot say "a >> receiver can shoot itself in the foot if it wishes to do so", whatever >> the language (and bullets) we use. > > We certainly can say that, by presenting the landscape in which this > operates. Hopefully the reader then makes an intelligent decision, > and we can encourage this in the way we write. Yes, but we cannot write "you can shoot without drawing" bald and bold in the intro, and "take care of you feet, though" using font size 6 down in Section 9. It sounds fraudulent. >> The workaround I suggested, helo-pass prevents rejection, isn't really >> that complicate. It can be explained precisely and concisely within a >> single short paragraph. But different participants dislike it, for >> different reasons that I never fully understood. > > What I want us to avoid is presenting a pile of things that, > individually, are not that complicated, but as a group they simply > give the reader far too many variants of basic SPF to consider. OTOH, if we were able to define a compound result for receivers who check both identities, that would be a relevant simplification. If an added paragraph could save endless discussions times implementers, it'd be worth. >> There's plenty of other ways. For example, the receiver could check a >> DNSWL before rejecting, and advertize which one it uses. Instead, >> Section 9.3.2 suggests that "the sender [...] might then be able to >> resolve the issue". What if it is not able to do so, discuss for ever? > > That's further added complication. "As simple as possible, but not simpler." > This shouldn't be in the protocol document. Sorry... "this" refers to? >> Neither Section 3.9.1 of RFC 5321 nor Section 5.1 of RFC 5598 consider >> it makes a difference whether the expanded aliases land within the >> same ADMD or to external domains. It makes a relevant difference for SPF. > > SMTP is relevant to SPF, but SPF is irrelevant to SMTP. That's why an > update is the wrong thing to do. You know this better than I, so I'd bet you're right. However, RFC 6409 warns against message modifications that can affect signatures, while pre-DKIM RFC 4409 didn't. RFC 4871 has no "updates: 4409". Is there a hidden update? I recently mentioned a similar example in the passage from 2821 to 5321. I don't mind not having "updates: 5321" if that's the way it works. From hsantos@isdg.net Sat Aug 18 10:52:54 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 747C021F8487 for ; Sat, 18 Aug 2012 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MwQR+aZYxiZ for ; Sat, 18 Aug 2012 10:52:53 -0700 (PDT) Received: from news.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 458DF21F845F for ; Sat, 18 Aug 2012 10:52:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3824; t=1345312364; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=u2IAzemzB4bpqiSMfnERUYlsZk8=; b=u0utO2czpnZaxwrcEYMm wnUXi2FEPG31vuHpGQgyg6Db5/LaV7cYViqiHKfj4RUBwQ8Ku+7C9K0AP3CoIcwF U2OeLpT4IFqNwDaFd++1AvJZYjJGeMhFPCR7b+xBEcVfPtoO1CFLRfxoin8aZUWl L0x6AQotit1Gl61vrJtHVP8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 13:52:44 -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 1334165846.23649.3160; Sat, 18 Aug 2012 13:52:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3824; t=1345312178; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RAodKvZ RB3sVuyRSW/tmscviP9psZbQ77r7CUWx0g2s=; b=k46YBitL2Otfnas+W/sQ3sH LB42XKFLDKogy+NXMnp2HIWtt6w6Bd3paDq3xCiMv9P02G83GBvbB1HRv+gNwE/b ES27LMeaKFcAZUCfhYzfOQSQ+x67LgPFPlZWXpuISW8Tfd7VUDOCLpEWFOKDUJEC DyeGMJXfdzkvwJw0X0pI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 13:49:38 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1932976630.7.1404; Sat, 18 Aug 2012 13:49:37 -0400 Message-ID: <502FD66F.5080907@isdg.net> Date: Sat, 18 Aug 2012 13:52:47 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <502FC01F.8050509@tana.it> In-Reply-To: <502FC01F.8050509@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 17:52:54 -0000 Alessandro Vesely wrote: > On Sat 18/Aug/2012 00:38:17 +0200 Murray S. Kucherawy wrote: >> On Thu, Aug 16, 2012 at 11:58 AM, Alessandro Vesely wrote: >>> Briefly, adopting SPF implies a conundrum of endlessly repeated >>> philosophical principles like "No, it is the {sender|receiver} who >>> should do so and so." A protocol that people can adhere to should not >>> cause such issues, or at least indicate a quick way to solve them. >> I appreciate the fact that there are people out there who want the >> silver bullet. For some people, SPF is that. That simply is not true >> for everyone. I have yet to work for any company (and I now work for >> a pretty huge one in terms of mail flows) where either it or its >> customers enabled SPF to reject on "fail", for example. > > I wouldn't strive for a silver bullet, but regular ammo, at least, > rather than a naked gun, would seem to be advisable. > >> The common point to both of these groups is that SPF's results are >> input to an overall evaluation of a message. For people that think >> SPF completely solves the problem, their evaluation system consists >> solely of SPF, and they do reject-on-fail. It works for them and >> that's fantastic. There exists, however, a substantial population >> that wants more than one piece of information to decide upon the fate >> of a message. The most common reason for that appears to involve SPF's >> known failure modes, but it's not for us to speculate on what those >> people have in mind. > > Agreed. Scott mentioned the pros and cons of both approaches, recently. Disagreed with the introduction of a "Guessing Game" when there is no need to be guessing. When it comes to -ALL policy there is a SILVER BULLET view by domains who go to that level and if a receiver is going to claim SPF compliance, it is not its job to 2nd guess that 100% exclusive nature of a -ALL policy, even with ~ALL (SoftFail), but definitely with -ALL - there is no dispute what the domains desires and if they felt that receivers are too stupid to know what they wanted with -ALL, well, they could a) easily not use SPF and/or B) use a weaker policy such as ~ALL or the the wasteful ?ALL. We need to keep the eye on the prize of what SPF is and it was definitely NOT about reputation modeling or even DKIM. People wanted SPF for a single purpose and those who could use -ALL, did and a growing amount of domains who started with ~ALL or ?ALL, did eventually learn what a waste it was with little value in protecting against spoofing. So if they could do so, they switched to a HARDFAIL -ALL for the sole purpose of remove any guessing on the receiver part. The key thing to remember about a domain public announcement of a security policy, and for many businesses, a CORPORATE MANDATE, trhe SPF compliance receiver who ignores the -ALL is at risk of harming a DOMAIN with an uninvited uncertainty it introduces on its own. The DOMAIN is no longer legally responsible. So its now a legal disclaimer for the SPF domain. If facebook.com says -ALL for its policy, and the so-called SPF compliant receivers ignores a detectable SPOOF based on the -ALL policy, legally, a mal-practice claim can be made against the receiver if there is measurable harm caused on the domain or user. Facebook will not be at fault here. The Receiver will. The only lawsuit here would be against the Receiver So the best legal way to get around it, is to stop playing guessing games the domain did not want you to do in the first place. If he says -ALL, if a spoof is detectable, then rejecting it is the safest bet across the board. Marking it is fine, but it better have a near equivalent security outcome for the end-users and that pretty much means stream separation. -- HLS From sm@elandsys.com Sat Aug 18 11:46: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 3BE9F21F8498 for ; Sat, 18 Aug 2012 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8229Vsz8uuC for ; Sat, 18 Aug 2012 11:46:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4521F8467 for ; Sat, 18 Aug 2012 11:46:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.237]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7IIkcpa012009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2012 11:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345315609; bh=0nCFsGUPoTXLmrqeIQFfg7oQSWWa9JX0GvZ3bTTeJTo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=gX2cRJVvu+DhgKv36c9FQWkmxanWUFVNV1KSwHWy0Fa0ZCfMthfxpucIei6qEbBLg 3R+1MRPKdKT8ZIZy7hyyH559F9QoHjUPDIylg7D1/0aP0b+28ftqyd0W2h/o9ftdck Xd02iG12jXjtxpk3ifBTc/vnrE25ZF5PW67o5OUs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345315609; i=@elandsys.com; bh=0nCFsGUPoTXLmrqeIQFfg7oQSWWa9JX0GvZ3bTTeJTo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2UusMhxUo6BPWpcoK85Arc52SKi/mAFkjbiROLnSCoxBvoaTrQtYCEINqXq1qV3g1 t/9C9WsTfrCrlXrHwZ6myV8VEeek6KiOCvBBihuGBjOVTGQpA//K9TIuMr01ZdVoEK TOgSA740mdLG6jfVps5M/mbeWwu138dILUt/r0jQ= Message-Id: <6.2.5.6.2.20120818111205.09e404f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Aug 2012 11:23:04 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <5003497.dxG3XNAxyi@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <7559986.vitorJ0zlv@scott-latitude-e6320> <6.2.5.6.2.20120817225803.0a507ac8@resistor.net> <5003497.dxG3XNAxyi@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 18:46:52 -0000 At 09:25 18-08-2012, Scott Kitterman wrote: >The statement speaks of harm. Since this exact information is already in RFC >1035, there is no harm. Was this message sent as chair or participant? It was not as WG co-chair as I usually explicitly mention that. As WG co-chair, I would like to remind the working group of the IESG statement at https://www.ietf.org/iesg/statement/examples.html Regards, S. Moonesamy SPFBIS WG co-chair From johnl@iecc.com Sat Aug 18 12:33: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 425E921F8494 for ; Sat, 18 Aug 2012 12:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.144 X-Spam-Level: X-Spam-Status: No, score=-111.144 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc7-KLbhLei4 for ; Sat, 18 Aug 2012 12:33: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 2D9F221F8487 for ; Sat, 18 Aug 2012 12:33:39 -0700 (PDT) Received: (qmail 30386 invoked from network); 18 Aug 2012 19:33:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 19:33: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=502fee12.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=oo3RBc7/hOSr1oVSdlxO63GxGQ6QWpAzz6jGxwyHppc=; b=Sw0rJHK1aq9ssoZMz3AaiLKMJ4X1w+D6zOQWD2iF3RlTgpHHF5Zj83JLmsbOB5a342+xkroM69vzXJ4hdhknfUO0iSy/yycBaSxbgcP3cMIVThrZ1jvdUw27BmYYLrygKSC4SqiXcHKbkt3YpoAwN/lJgRcsGJcAiFofTlWXUzg= 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=502fee12.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=oo3RBc7/hOSr1oVSdlxO63GxGQ6QWpAzz6jGxwyHppc=; b=gkakMALTDQb/JUkHy6AxxqG3St95K409JVbGqsCRggPEzmBE4yiKINF/+gXwPZibhS/XfoCN7FJ55c7787elOJ7qQ2n9dm22a1fU1388WoowCACQsKUypneIsiE46tGPF0gAXTdhiq7JEfzf7HfPCt4CmMjX3QyPyzp++0DLq6Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 19:33:16 -0000 Message-ID: <20120818193316.35320.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <89686312.gpFrOJr1G6@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] macros, threat or menace, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 19:33:41 -0000 >> The point is that those macros can allow hostile senders to inject >> arbitrary character strings into the names in DNS queries. So you >> better be sure that the libraries that handle the queries don't assume >> that the names are well formed, or consist only of printing ASCII >> characters. > >I think "there may be bugs in software" is not a working group issue. It's not just bugs, although I think it would polite to point out that it's likely to send stuff to your resolver library that the library is not prepared to handle. (I do not share Arthur's confidence that resolver libraries have all been hardened against obscure inputs.) The worse problem is that the interface to resolver libraries is surprisingly ill specified once you get very far away from host names. Most painfully, dot and null (zero) are valid characters in a component of a domain name, but most resolver libraries don't deal with that. So let's say your SPF record has exists:%{l}.users.example.com The bounce address is john.doe@example.com, so it looks up john.doe.users.example.com. Is that first dot a delimiter between two components or part of the first component? What if the address is john..doe@example.com? Does that create a valid or an invalid domain name? Before you say this is totally off the wall, look at the RNAME field of the SOA RR, which has the same problem, the first component of the name is a mailbox. I have seen people stick a dot in there using \. which works in master files, but as far as I know not in resolver libraries. Since approximately nobody has noticed this before, it just confirms that approximately nobody uses macros. That's why I don't suggest trying to nail down the right thing to do, just note that macros allow hostile senders to inject arbitrary text into your DNS queries, so you should defend against that. EAI makes it somewhat more likely that names will include hard to handle text, but the problem's been there all along. R's, John From johnl@iecc.com Sat Aug 18 13:06: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 9DED421F8497 for ; Sat, 18 Aug 2012 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.145 X-Spam-Level: X-Spam-Status: No, score=-111.145 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUNGOpCT+-AU for ; Sat, 18 Aug 2012 13:06:50 -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 A25DC21F8495 for ; Sat, 18 Aug 2012 13:06:49 -0700 (PDT) Received: (qmail 34366 invoked from network); 18 Aug 2012 20:06:47 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 20:06:47 -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=502ff5d7.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=D+MKbpbRhSIEf8ZnbqR2tqj24GFBZVxXfFrYNeq5GBU=; b=iclRlYPka5YLddJjzvpgimQWQsWmjSdywg6hOQZdI1kIpt9Ey/Kd3MVJ+xLbs33Csw6jt4kRcwmF75Y+1H3uqC+A45Tfi7ueBv6Yc3/ZZjW1HjWiUpVWOabgk/lk9UbS2EPvf724q/a6YCuyDNDv/mqlVzh89wLb8ac6X6bjljQ= 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=502ff5d7.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=D+MKbpbRhSIEf8ZnbqR2tqj24GFBZVxXfFrYNeq5GBU=; b=h2dbp0CVI0q9HMmhCeK1yHcMwLBQIOwYz6vk8RPSWbOtVxdlNvXepf2xM3l7NkPb4czTkvvQ7j+ikOPxAXXxMwhBFNHrUch/KpG6Wvu9geieva7sFcnbxoK9I7gTwmEvJeA0K7x4X4RrDKx8faPY1JP0KEeawwtsAzJlsOet40M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 20:06:25 -0000 Message-ID: <20120818200625.44332.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1477429.4Q0UcHrSQQ@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 20:06:50 -0000 >> Doesn't matter to me, but the IESG has been known to obsess on this. > >My usual response to such things is "I'll be glad to fix it after you go fix the >reference I copied it from". I'll leave it as is I guess unless one there's a >upswell to change it. Like I said, it doesn't matter to me, but when the IESG puts a discuss on this for X.COM, we told you so. R's, John From sm@resistor.net Sat Aug 18 13:29: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 D6A2821F8494 for ; Sat, 18 Aug 2012 13:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho0pcMdZoZf3 for ; Sat, 18 Aug 2012 13:29: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 BF35421F8491 for ; Sat, 18 Aug 2012 13:29:23 -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 q7IKTGV0011759; Sat, 18 Aug 2012 13:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345321762; bh=3l5bu9EnsAfM+qKnDwZaYsMNH789tA48jQF323kpwOY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Nk625T1DdYBzSAolfRGySg6hviQsgpaykLtRg9G9x3J7r4DhTgRR0PszPcZl+osrJ nUV8AHeynX4L1oE+TtEO29PviG0U9CqlKBMyDK0AuOdvHLmMMxlkyew1VoQdwvKpG6 GbT4R8Ur/JC9XhUaYYHf6SKrRCej6FN8RYlCTZ5o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345321762; i=@resistor.net; bh=3l5bu9EnsAfM+qKnDwZaYsMNH789tA48jQF323kpwOY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bl5hVyIn8cVjaRH4bAlVDI72uKmkRkw7gnt5L9xBCsk20c9tZx+yd9U+4RJRoDajE qZYVzy66YXUsGkVCKC15Gv3wrWQxZJuUay6D/GS4y8H5ehb+tARyJ7ixKV9AwqXNya MkqwIfecvK+MaezX77WjNKUUaAyLFZF609WrPGgY= Message-Id: <6.2.5.6.2.20120818131523.098c5190@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Aug 2012 13:28:53 -0700 To: Alessandro Vesely From: SM In-Reply-To: <502FD66C.40607@tana.it> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <502FC01F.8050509@tana.it> <502FD66C.40607@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 20:29:25 -0000 Hi Alessandro, At 10:52 18-08-2012, Alessandro Vesely wrote: >You know this better than I, so I'd bet you're right. However, RFC >6409 warns against message modifications that can affect signatures, >while pre-DKIM RFC 4409 didn't. RFC 4871 has no "updates: 4409". Is >there a hidden update? No. There was a discussion about message modifications during the update that lead to RFC 6409. Regards, -sm From hsantos@isdg.net Sat Aug 18 14:54: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 D87C621F84CE for ; Sat, 18 Aug 2012 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTOWDVdRvcNn for ; Sat, 18 Aug 2012 14:54:26 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECCE21F84B9 for ; Sat, 18 Aug 2012 14:54:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8158; t=1345326859; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=j0Df8vQ3RjeIsMeM0ipLTRzwNlg=; b=aw/AvXZq5406QBO3F0pt C+m/o9raLcv+L33EFRxPYQXWi87O4LutPusAFOvzjXr8rOyJvRgdE4XwWbNb+vlz jSw++HETJc0OCnCr/j9HbMCC4E79cqm3j6uwo4lXjnPm+1BaQke4ueWf1jlcaoXi jJmGpA6T+0I4+gg57ehFzE0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 17:54:19 -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 1348661116.23649.5868; Sat, 18 Aug 2012 17:54:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8158; t=1345326673; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Yg9QvpZ 81QMGdGtV+jVpQI5edpjaxaL4vi2TEKZFDOc=; b=p26Y08oCN8b7Pq6yE1PcDsO ddoRYo4mJvuri4rW0jR48e5ws+u2fWKYAT2SAQ65uX7OrmyMUSxwdSH2o2cjatQi 9pTNzGVu3/bOWNc0dVB9IR5dBVcwEDHdr4U2U1+RGRlmc8jFnFnRdYsajitdiezE 2N3wb23UX8cfN5EDniQs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 17:51:13 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1947471130.7.5220; Sat, 18 Aug 2012 17:51:12 -0400 Message-ID: <50300F0E.1080409@isdg.net> Date: Sat, 18 Aug 2012 17:54:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1908971.Uo0Ahn547K@scott-latitude-e6320> In-Reply-To: <1908971.Uo0Ahn547K@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 21:54:28 -0000 My review: o Abstract. I prefer the previous version with the reverse-path. SPF protects the REVERSE PATH, not the AUTHOR'S ADDRESS. The abstract can provide the wrong idea on what SPF attempts to protect. o Introduction In the introduction, it introduces a new vague term with a vague definition. .... "reverse pointer" which is the purported hostname of the SMTP client as far as the DNS is concerned [RFC1035]. SPF attempts to offer technology to help protect against the forging of the EHLO/HELO and MAIL FROM domain fields. No mas. I suggest that we keep with long time terms we know these two fields to be. MAIL FROM -> Reverse Path EHLO/HELO -> host, primary host name, host domain name, machine host name, address literals, etc. In practice, I have used Primary Host Name (PHN) or generally Client Domain Name (CDN) in process modeling and that is not far off from how SMTP described it: fully-qualified domain name of the SMTP client o usage of RFC5321 prefixes I don't quite like the massive changes to use RFC5321 prefixing from what are otherwise generic SMTP terms well understood for decades. It also places a tight requirement for a specific RFC # when its possible that the # can change in the further. Plus, in good acceptable technical writing style, a first time reference is all that is needed. I don't think we were in trouble with using well understand SMTP terms. It also makes it very redundant, harder to read, to speak out, too technical. Functionality is all that is conveyed. o 1.3.5. Deprecated There are [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of the feature in question. Here you made a specific definition of what "deprecated" means making that much harder to use the term in general form across the board. I suggest to remove the section and just be specific where it is necessary to describe when PUBLISHING is not recommended. This allows us to use the generic and open ended form of the term deprecation when and where applicable. As you have it now, its a puzzle! You locked it in for the publishing usage, but its quite possible that there could be a receiver feature that we may deprecate, i.e. suggest ideas such as deprecating Receiver-SPF if we can get the Auth-Res correctly matched for SPF. It is not a far fetch idea for Receiver designs to offer to customers especially for those designs that are have integrated concepts with other protocols using Auth-Res. o 2.1. The HELO RFC5321.HELO/.EHLO Identity I don't like how this is written - too strong and needs more information. Practical deployments and experience suggest a continue high rate of false and bad client domain names (EHLO/HELO) and thus will continue to be a high yield of wasted lookup overhead. I prefer this to be a MAY with more details gathered from what we learned over the 9 years and also probably debate if there is a trend towards correction which was the main reason I pushed Meng Wong to re-add HELO checking - to promote RFC5321 (RFC2821 back then) strong SMTP compliance and correctness especially for the primary client machine name. What I am saying is that an automatic Check_Host() function can not be always be applied without other syntax and local domain checking considerations. Implementators need to make this very flexible otherwise there is a high overhead. For the sake of example, you don't need to do an EHLO/HELO SPF check for fields such as: - loopback domains such as "localhost" - square bracketed ip literals - strings without a dot (could be a netbios name) The field should syntactically correct before the SPF check is done and at this expected point, I believe it should remain as a MAY, not RECOMMENDED with local domain spoof protection being the #1 benefit you can get here. o 2.2. The RFC5321.MailFrom Identity I don't like this section beginning with a NULL discussion without describing this field. The prev revision paragraph removed was sufficient - suggest to add back then lead to NULL use cases. I never quite noticed this before, but the sentence with the usage of "postmaster" When the reverse-path is null, this document defines the RFC5321.MailFrom identity to be the mailbox composed of the local-part "postmaster" .... Two things: - Confusing. RFC5321.MailFrom is NULL. Do you mean the RFC5322.From with have the "postmaster" for the local part? So would this be a correction? When the reverse-path is null, this document expects the RFC5322.From identity to be the mailbox composed of the local-part "postmaster" .... - There may not be any control of the SMTP receiver what local part address is used for the bounce since the bounce could be done outside the completion and SMTP reception of mail with a gateway or mail importer. It is still very common to see mailer-daemon and there is RFC2142 for decades old mailbox names for what are acceptable local-parts for NULL addresses and other functions. Overall, this is implying that an SPF implementation SHOULD or MUST use "postmaster" for any bounce/dsn message it creates and in additional, it implies if you get a bounce (NULL reverse path), then expect the 5322.From to have a local-part "postmaster". I suggest that this sentence is vague and should be removed to avoid any false logic checks that may not exist. The bounce can be from "mailer-daemon" or other mailbox names. What makes it a true SMTP defined bounce is the NULL reverse path - not the mailbox name. The different kinds of mailbox name generally drives different mail bots or translations. o 2.3. Publishing Authorization An SPF-compliant domain MUST publish a valid SPF record as described in Section 3. This record authorizes the use of the domain name in the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities by the MTAs it specifies. The last sentence implies ONE record (via use of "This record" ...) is sufficient to cover both fields when in practice it usually does not. When changing SPF records, care must be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate email has can reasonably expect to have been checked. This can be as much as 30 days. Where does this 30 days come from? IME, that could be 4, 5, 7 days, 2 weeks or even more than 30 days. It must be some particular setup/experience, but certainly not universal. As far as adding some "SMTP" related factor, it would be 4-5 days for the recommended exhaustive transport retries where it is very much applicable to SPF. In other words, if a message does not get sent within 4-5 SMTP "example guideline" days, it usually gets bounced. That is the guideline we used for other things too like DKIM revoked records as well. Whatever the limit, it should be pretty close to the SMTP practiced of 4-5 days. - Address the security issues first. Per issue 29 and section 2.5.4 and the links I provided in a previous post for additional info, overall, IMO, we need to define what "marking" the SPF hard failed message means and how this deployment alternative can expose a security level difference compared the RFC2119 compliance option of REJECT. We need to note that implementators SHOULD offer both options to deployments (operators, admins, etc). I think we should state what is the MINIMUM requirement for SPF compliance, and one can argue since REJECT is the only RFC2119 level language, it should be the minimum offering. The alternative is MARKING and I believe, we only need to describe the responsibility regarding mail separation at this point. I personally believe even adding a section or paragraph regarding System Level vs User Level Filtering is warranted as a nice way to introduce and/or reference the SMTP level REJECT vs mail acceptance MARKing and the recommended mail stream separation design/deployment guideline. o TBD - other items to comment on -- HLS From sm@elandsys.com Sat Aug 18 16:00: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 4919421F84EF for ; Sat, 18 Aug 2012 16:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I7eLsxqTPPJ for ; Sat, 18 Aug 2012 16:00:39 -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 C778821F84EE for ; Sat, 18 Aug 2012 16:00:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.72]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7IN0PLq018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Aug 2012 16:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345330836; bh=tCvCZXf3xRUn01lNHRu3x1yPkMLk0Yh3R6YyS6nM81c=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2hkwnvHyf9Ka78miLIXdaaShomhXXWk9L2EMq1aPtA07FVgKXT5xqAe47nJNHFHuK rsbU5QU9ynTXb2ZjbTeNFRokox4GEVpCnKLDY1Z+q8DNEypvsIKn0jwm90Ed7p4xYW sVm0LDR3FX+BhgF0pYgZHtABAGXhalsrGqqmT06M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345330836; i=@elandsys.com; bh=tCvCZXf3xRUn01lNHRu3x1yPkMLk0Yh3R6YyS6nM81c=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=rgE8n01MkgB4WQJfdud7fM/Q34l/b9lQ6WicYWl19As7m4yTjUWp3vwwEjr2ImAXI W8EdGSlaI52Zc2wI7jYKTgJCoTbPWrcRhc+ny64RB8q7locj40UVbgLzy/kLFV2NY0 yoXuEtWq8wDd8JA/Nmnj4FcJGT8yvn2NwCDPmz1A= Message-Id: <6.2.5.6.2.20120818151248.0977e7a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Aug 2012 16:00:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120818111205.09e404f8@resistor.net> References: <20120817034603.20684.qmail@joyce.lan> <7559986.vitorJ0zlv@scott-latitude-e6320> <6.2.5.6.2.20120817225803.0a507ac8@resistor.net> <5003497.dxG3XNAxyi@scott-latitude-e6320> <6.2.5.6.2.20120818111205.09e404f8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Aug 2012 23:00:40 -0000 At 13:06 18-08-2012, John Levine wrote: >Like I said, it doesn't matter to me, but when the IESG puts a discuss on >this for X.COM, we told you so. I am using the above comment from John Levine for context. A DISCUSS from the IESG is not an unsolvable problem. It means that an Area Director has identified an issue and he/she would like to talk about it with the working group. Let's assume that there is a DISCUSS about X.COM. The DISCUSS is for the working group and it is up to the working group to agree on a text change or an explanation about why it decided not to make any change. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Sat Aug 18 18:00: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 0FC0021F84D8 for ; Sat, 18 Aug 2012 18:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTH3oAtCdWrN for ; Sat, 18 Aug 2012 18:00:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 598E021F84D1 for ; Sat, 18 Aug 2012 18:00:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A127820E40EA; Sat, 18 Aug 2012 21:00:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345338049; bh=nx8mA+6jFXf1d0QR9TWL8YDRgbtLM1vclxbORxdQlT0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RgDOW5Wm8Z3X/XkVS/n1wM3v32amU7Pf6bXoG+Y10Bab8Sh5aPh/sQFUV1wnVEbqW xKcvyI8jY3tTNpPX9tm4dP33NkXJ0wo7GlgDL3pdxJbYv9QJ6gm82an3Iyb0NAMzOz tG4XdSFmPzmmXaRlJoDE84QxNWszXjOcofHz4ju0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6489920E40A6; Sat, 18 Aug 2012 21:00:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 21:00:45 -0400 Message-ID: <2137477.zzX3vIWz46@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120818111205.09e404f8@resistor.net> References: <20120817034603.20684.qmail@joyce.lan> <5003497.dxG3XNAxyi@scott-latitude-e6320> <6.2.5.6.2.20120818111205.09e404f8@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 01:00:51 -0000 On Saturday, August 18, 2012 11:23:04 AM S Moonesamy wrote: > At 09:25 18-08-2012, Scott Kitterman wrote: > >The statement speaks of harm. Since this exact information is already in > >RFC 1035, there is no harm. Was this message sent as chair or > >participant? > It was not as WG co-chair as I usually explicitly mention that. > > As WG co-chair, I would like to remind the working group of the IESG > statement at https://www.ietf.org/iesg/statement/examples.html > > Regards, > S. Moonesamy > SPFBIS WG co-chair I've reviewed it. The operative bit is: > The IETF should minimize any potential impact on the entity having been > assigned such a codepoint from unwanted traffic or other concerns. To help > ensure this the IESG will expect the author of any Internet Draft that > defines a new specification to use values assigned for examples whenever > possible. The IESG also recommends new protocol specifications creating new > codepoint, address or names spaces to consider if some part of the space > should be reserved for documentation and example usage. I don't think it insists on a change between 4408 and 4408bis. We are not defining a new protocol in 4408bis. It was defined in 4408. Additionally, I don't think the current use in an example will have any affect or if it does, it's de minimus in comparison to that same example being in RFC 1035. The statement does not suggest document writers should go back and rewrite existing examples. I am assuming if the IESG wanted people to do that, they would have said so. Scott K From hsantos@isdg.net Sat Aug 18 18:11: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 32BCC21F84CE for ; Sat, 18 Aug 2012 18:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cttw2qVlyOUb for ; Sat, 18 Aug 2012 18:11:54 -0700 (PDT) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9729621F8474 for ; Sat, 18 Aug 2012 18:11:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2237; t=1345338705; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1BI38LvqXuFyS658jzFng4nJ4j8=; b=I4sLfaFHZ65KOlPOvplG PcZoYNz8RGF8433RWfcENavjoPrxKgwCFh/5DUaTRJsV2mGL8fM8SHSwyPfZUJor 4QQW8Oqjx57xhfnZTcSVM9O36id5GQTUqZiQAFsA/uaK3b0CrxPex9k51KG8ifuI hzYc5koNxpx/1IZceywIHa8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 21:11:45 -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 1360506397.23649.3560; Sat, 18 Aug 2012 21:11:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2237; t=1345338521; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LjRHEfS YVMzDHlDO6BNUSXz66khsgH0ep3LTRZEdtLQ=; b=FU6ma2PKO3YnnizekbPNacE gpufEhlxe1N5PD5SH+oB3r9wFZ9gAMj8jA0ihSjO2xIepLMGVAHpr9PEZaJuBnDe TVbrlm/5oXNgas8aw3eGDH1+R+ROYKnHXkZQD0+ZRMt8Wde+PU17a68DPQ7vJ6mo nplRtg5TtWxmjIXOg6v4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 21:08:41 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1959319739.7.5532; Sat, 18 Aug 2012 21:08:40 -0400 Message-ID: <50303D6C.7040002@isdg.net> Date: Sat, 18 Aug 2012 21:12:12 -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: <20120818193316.35320.qmail@joyce.lan> In-Reply-To: <20120818193316.35320.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] macros, threat or menace, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 01:11:56 -0000 John Levine wrote: > So let's say your SPF record has > > exists:%{l}.users.example.com > > The bounce address is john.doe@example.com, so it looks up > john.doe.users.example.com. Is that first dot a delimiter between two > components or part of the first component? What if the address is > john..doe@example.com? Does that create a valid or an invalid domain > name? > > Before you say this is totally off the wall, look at the RNAME field > of the SOA RR, which has the same problem, the first component of the > name is a mailbox. I have seen people stick a dot in there using \. > which works in master files, but as far as I know not in resolver > libraries. One poor resolver should not suggest its applies to all. > Since approximately nobody has noticed this before, it just confirms > that approximately nobody uses macros. Incredible. Darn if spf.messagelabs.com (just one of many) doesn't use the exist macros for its customers SPF related services. Our bnymellon.com customer has this hardfail -ALL policy: v=spf1 include:spf.messagelabs.com include:pacificlife.com ip4:198.181.8.23 ip4:198.181.8.24 ip4:207.218.135.22 ip4:207.218.135.23 ip4:147.249.37.42 mx -all and the first include yields: v=spf1 exists:%{ir}.nets.messagelabs.com What it seems to suggest is maybe people only used certain macros, those that are not going to cause issues or questions like the one you suggest. > That's why I don't suggest trying to nail down the right thing to do, > just note that macros allow hostile senders to inject arbitrary text > into your DNS queries, so you should defend against that. IMO, SPF macros is not the key issue here. But I do agree, we should point out the particular complexities where there might be some conflicts and developers (also publishers) need to be aware of. Per your example %{l}, using local parts has always been problematic for protocols, including SMTP and especially within DNS, i.e. user level granularity concepts. > EAI makes it > somewhat more likely that names will include hard to handle text, but > the problem's been there all along. Right, SPF lives in the same screwed up world of EMAIL. -- HLS From agthisell@yahoo.com Sat Aug 18 18:59: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 569D821F84D8 for ; Sat, 18 Aug 2012 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-1.545, BAYES_05=-1.11, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh9e1yAXWg-U for ; Sat, 18 Aug 2012 18:59:37 -0700 (PDT) Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) by ietfa.amsl.com (Postfix) with SMTP id 9101421F845F for ; Sat, 18 Aug 2012 18:59:37 -0700 (PDT) Received: from [98.138.90.56] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 01:59:33 -0000 Received: from [98.138.89.171] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 01:59:33 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 01:59:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 747118.64941.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 14849 invoked by uid 60001); 19 Aug 2012 01:59:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345341573; bh=p9doAMwtuXnp+6YRUNiwDyC6WBD/L0c2ihmycoWcUak=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=bXBchBYgT+SC43AzYFPHGvS3mRmy/TI9eO+sn5z7+0ofng9qcoWC/ezJvYTOR8WUBqan/pW5T9ZwpfUjGwsvvWWOuJEpOsfRuG3uGjGtcVn8bj4d0fPwwThGwwh7XmwhwOenTJB/yfS2IXp08lnIKL86aq47FXcTHOvRkA+q0ss= 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:In-Reply-To:MIME-Version:Content-Type; b=KGaN3wMKKD2MJlObT7we7Fg+H1ORxHyLHEu5zKToaKM1MdUgqDHGl8vRcWFz0w32LCXqseDtBFENq8TKFmZeWXA39chcnImOzQ8sCIVKJML9Qb0W4E9/VQ6e6FLlEg1kCDBqjIl70My5dVdB7F1oFySk8h7lON3mVznWnuInwvA=; X-YMail-OSG: 8Xl5CIAVM1niBP7kkpxj2NRtBU5tWBPW2BLE..y8CYrVKQj 2Nn_h89Qu.ExII7swpmTAOqjjer2pkv3Xrj4lsMlBdix1oGITRG8PySUMTFJ 8lcRvFh0NJX0K0LXxXg8JQyM3R0I6iaun_XxZDh7_Xo.CyJ6zG3pvPU9mTgp Iv04E17HOe.oV2zpXmm.HTbmsMoz9hL50DIOj8I0PXz2yPizmZL.bCgwJ86j mH_D73ZVa1LcPK5eXJLv3EuSo8mc.b.HZKjOHGuZ4cnM8cyywS4qqeoQRLQ4 3Eru8VclIl0ifzokSeYch810X1NZKxRxHuqr4bbVjdaTLY91OLScGXWmFpGv I0BSYTzUbfCQSCjkM2PjijR3DiuPH.I4QjUmBiwXFjcG9BlW7Xo.dG2TRc5y bwUJODzUOFpOZkDek1fLeMGF3kAMNoEL7TRhjuCykgCxVByHSL7nUTQAc4D3 hUxHmvYxXdAJeEAY9_UQTVp6piwhbv27OalNqDg_Iy9T8RtcepSQp7.t5L45 XPHZB3D3SdhteI7_uvsQ_s9qP6Y7qunR.e1PlNxt3adG6YDuzQ4wTWNucolH ju7KeP_I- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Sat, 18 Aug 2012 18:59:33 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1345341573.6866.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Sat, 18 Aug 2012 18:59:33 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] spfbis Digest, Vol 10, Issue 21 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 01:59:38 -0000 > So let's say your SPF record has > > exists:%{l}.users.example.com > > The bounce address is john.doe at example.com, so it looks up > john.doe.users.example.com. Is that first dot a delimiter between two > components or part of the first component? John, you are the first person I've seen who as wondered if the first dot might be part of the first label. It isn't. People have been depending on it not since 2004 or so. What is passed to the resolver is the string. Please note that even RFC4408 said "The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters)." A dot is another character SPF can't generate. > What if the address is > john..doe at example.com? Does that create a valid or an invalid domain > name? yes, two dots in a row (null label) creates an invalid domain name. > I have seen people stick a dot in there using \. > which works in master files, but as far as I know not in resolver > libraries. I am not longer easily able to test this, but as I said in earlier posts, yes, I've tested it years ago. It worked. > Since approximately nobody has noticed this before, it just confirms > that approximately nobody uses macros. I glad to hear a whole bunch of people are nobodies. The use of %{l} being used to inject potentially bad stuff was discussed several times in the years 2003-2005 (e.g., before RFC4408 was published). There was a long discussion about a contrived example of mx:%{l} with "aol.com" used as a local part. The conclusion was "it is stupid to publish such a SPF record". I guess I don't have any objections adding something to the draft that points out that using SPF causes queries to other DNS servers. Those DNS servers can send back answers such as referring to another name server which has malicious characters in the labels of that NS which can cause your name server to blow up. Or, we could just remain silent until there is some evidence that this is a problem worth worrying about. From spf2@kitterman.com Sat Aug 18 18:59:54 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 3C04F21F84E1 for ; Sat, 18 Aug 2012 18:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi3Qf6AwTe8N for ; Sat, 18 Aug 2012 18:59:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7E21F845F for ; Sat, 18 Aug 2012 18:59:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0FB2020E40EA; Sat, 18 Aug 2012 21:59:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345341592; bh=ES82dpLoLmikmA/BcWBhBIPugEAZKNl7sssyNOKsY2M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J81LBdocNTkzfAIDqhTmuaQLFILpOhNIxuQDO3rLO/Oz6AQSySANnSWGnFe6Ul8Mq MJhRJul3jpboWjKxXtRGeH74HaIIDu8gRrhCR+VMk+0GRoB7iuvOFqZjv8waIC6Htp 0G3z04BiLlHOpW5zqPSGp9r54i//fPf7j9cL27UA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D5FEF20E40A6; Sat, 18 Aug 2012 21:59:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 21:59:51 -0400 Message-ID: <2569465.PHZWXk9PS2@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50300F0E.1080409@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <50300F0E.1080409@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 01:59:54 -0000 On Saturday, August 18, 2012 05:54:22 PM Hector Santos wrote: > My review: > > o Abstract. > > I prefer the previous version with the reverse-path. SPF protects the > REVERSE PATH, not the AUTHOR'S ADDRESS. The abstract can provide the > wrong idea on what SPF attempts to protect. I've already removed author's address for the next revision based on a previous comment, so please check -05 when it's published. > o Introduction > > In the introduction, it introduces a new vague term with a vague > definition. > > .... "reverse pointer" which is the purported hostname > of the SMTP client as far as the DNS is concerned [RFC1035]. I went back and looked and in RFC 1035, Section 3.5 the actual term used is "primary domain names", which I don't think is particularly helpful either. Looking over it again, I think that the ", plus ... " clause isn't necessary and have deleted it. > SPF attempts to offer technology to help protect against the forging > of the EHLO/HELO and MAIL FROM domain fields. No mas. I suggest that > we keep with long time terms we know these two fields to be. > > MAIL FROM -> Reverse Path > EHLO/HELO -> host, primary host name, host domain name, machine > host name, > address literals, etc. > > In practice, I have used Primary Host Name (PHN) or generally Client > Domain Name (CDN) in process modeling and that is not far off from how > SMTP described it: > > fully-qualified domain name of the SMTP client > > o usage of RFC5321 prefixes > > I don't quite like the massive changes to use RFC5321 prefixing from > what are otherwise generic SMTP terms well understood for decades. It > also places a tight requirement for a specific RFC # when its possible > that the # can change in the further. Plus, in good acceptable > technical writing style, a first time reference is all that is needed. > I don't think we were in trouble with using well understand SMTP > terms. It also makes it very redundant, harder to read, to speak out, > too technical. Functionality is all that is conveyed. Based on quite a number of comments, including this one, I'm switching back to using "HELO" or "MAIL FROM" in the document with the 5321.XXX forms being included in the definitions for each for technical clarity. I'm reworking this a bit, so please review the next draft. > o 1.3.5. Deprecated > > There are [RFC4408] features that are marked "deprecated". In the > context of this document, deprecated means that senders SHOULD NOT > publish SPF records that make use of the feature in question. > > Here you made a specific definition of what "deprecated" means making > that much harder to use the term in general form across the board. I > suggest to remove the section and just be specific where it is > necessary to describe when PUBLISHING is not recommended. This allows > us to use the generic and open ended form of the term deprecation when > and where applicable. As you have it now, its a puzzle! You locked > it in for the publishing usage, but its quite possible that there > could be a receiver feature that we may deprecate, i.e. suggest ideas > such as deprecating Receiver-SPF if we can get the Auth-Res correctly > matched for SPF. It is not a far fetch idea for Receiver designs to > offer to customers especially for those designs that are have > integrated concepts with other protocols using Auth-Res. So far we didn't have to deprecate anything that didn't fit this definition and I don't think we will. If we do, that would be the time to revisit it. This is here because there were a number of questions about what does deprecated mean. I think it's useful to answer it once. > o 2.1. The HELO RFC5321.HELO/.EHLO Identity > > I don't like how this is written - too strong and needs more > information. Practical deployments and experience suggest a continue > high rate of false and bad client domain names (EHLO/HELO) and thus > will continue to be a high yield of wasted lookup overhead. > > I prefer this to be a MAY with more details gathered from what we > learned over the 9 years and also probably debate if there is a trend > towards correction which was the main reason I pushed Meng Wong to > re-add HELO checking - to promote RFC5321 (RFC2821 back then) strong > SMTP compliance and correctness especially for the primary client > machine name. > > What I am saying is that an automatic Check_Host() function can not be > always be applied without other syntax and local domain checking > considerations. Implementators need to make this very flexible > otherwise there is a high overhead. For the sake of example, you don't > need to do an EHLO/HELO SPF check for fields such as: > > - loopback domains such as "localhost" > - square bracketed ip literals > - strings without a dot (could be a netbios name) > > The field should syntactically correct before the SPF check is done > and at this expected point, I believe it should remain as a MAY, not > RECOMMENDED with local domain spoof protection being the #1 benefit > you can get here. This is RECOMMENDED in RFC 4408, so MAY would be a change, not RECOMMENDED. I added "SPF checks can only be performed when the "HELO" string is a valid fully qualified domain." to the end of the "Note ..." paragraph to clarify when SPF checks have to be skipped. > o 2.2. The RFC5321.MailFrom Identity > > I don't like this section beginning with a NULL discussion without > describing this field. The prev revision paragraph removed was > sufficient - suggest to add back then lead to NULL use cases. Nothing was removed. It was moved up into 1.3.3, the definition. I agree though that diving right into the bounce case was a bit rough. I reversed the two paragraphs in the section and I think it flows much better. > I never quite noticed this before, but the sentence with the usage of > "postmaster" > > When the reverse-path is null, this document defines the > RFC5321.MailFrom identity to be the mailbox composed of the local-part > "postmaster" .... > > Two things: > > - Confusing. RFC5321.MailFrom is NULL. Do you mean the RFC5322.From > with have the "postmaster" for the local part? So would this be a > correction? > > When the reverse-path is null, this document expects the > RFC5322.From identity to be the mailbox composed of the local-part > "postmaster" .... > > - There may not be any control of the SMTP receiver what local part > address is used for the bounce since the bounce could be done outside > the completion and SMTP reception of mail with a gateway or mail > importer. It is still very common to see mailer-daemon and there is > RFC2142 for decades old mailbox names for what are acceptable > local-parts for NULL addresses and other functions. > > Overall, this is implying that an SPF implementation SHOULD or MUST > use "postmaster" for any bounce/dsn message it creates and in > additional, it implies if you get a bounce (NULL reverse path), then > expect the 5322.From to have a local-part "postmaster". > > I suggest that this sentence is vague and should be removed to avoid > any false logic checks that may not exist. The bounce can be from > "mailer-daemon" or other mailbox names. What makes it a true SMTP > defined bounce is the NULL reverse path - not the mailbox name. The > different kinds of mailbox name generally drives different mail bots > or translations. Here's the full sentence (updated for my terminology changes I mentioned above): > When the reverse-path is null, this document defines the "MAIL FROM" > identity to be the mailbox composed of the local-part "postmaster" and the > "HELO" identity (which might or might not have been checked separately > before). All this says is that if he reverse-path is null, the construct to use for an SPF "MAIL FROM" check is "postmaster@" + "HELO identity". This is unchanged from RFC 4408 and I think is fine. I think you may be reading too much into it. > o 2.3. Publishing Authorization > > An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3. This record authorizes the use of the domain name in > the RFC5321.HELO/.EHLO and RFC5321.MailFrom identities > by the MTAs it specifies. > > The last sentence implies ONE record (via use of "This record" ...) is > sufficient to cover both fields when in practice it usually does not. For a single domain it is. This is an SPF-compliant domain, not an SPF- compliant ADMD. Yes, every domain needs it's own record, but it needs only one and that one can be used either for "MAIL FROM" or "HELO". > When changing SPF records, care must be taken to ensure that there is > a transition period so that the old policy remains valid until all > legitimate email has can reasonably expect to have been checked. This > can be as much as 30 days. > > Where does this 30 days come from? I got a comment that the RFC 4408 language was too vague and we should provide specificity. It used to say: > When changing SPF records, care must be taken to ensure that there is > a transition period so that the old policy remains valid until all > legitimate E-Mail has been checked. The problem is that there's really no way to do that, so I tried to improve it. > IME, that could be 4, 5, 7 days, 2 weeks or even more than 30 days. It > must be some particular setup/experience, but certainly not universal. > As far as adding some "SMTP" related factor, it would be 4-5 days for > the recommended exhaustive transport retries where it is very much > applicable to SPF. In other words, if a message does not get sent > within 4-5 SMTP "example guideline" days, it usually gets bounced. > That is the guideline we used for other things too like DKIM revoked > records as well. Whatever the limit, it should be pretty close to the > SMTP practiced of 4-5 days. The problem is that there is no universal. The only spec I recall seeing a specific recommendation on this is the original Microsoft Caller ID for Email specification. It suggested 30 days. I asked a few people with experience (which I don't have) in supporting domains with large consumer mail flows and the feedback I got was that 30 days would cover most, but not all cases. I had been thinking a week should be enough, similar to your suggestion, but if we're going to try and bound the problem, I think we need to do it keeping in mind something that will broadly cover many situations. > - Address the security issues first. > > Per issue 29 and section 2.5.4 and the links I provided in a previous > post for additional info, overall, IMO, we need to define what > "marking" the SPF hard failed message means and how this deployment > alternative can expose a security level difference compared the > RFC2119 compliance option of REJECT. I went back over your previous posts and I think that what we have in section 9 does this. Please review -05 and provide updated text based on that if you don't feel it does. > We need to note that implementators SHOULD offer both options to > deployments (operators, admins, etc). I think we should state what is > the MINIMUM requirement for SPF compliance, and one can argue since > REJECT is the only RFC2119 level language, it should be the minimum > offering. The alternative is MARKING and I believe, we only need to > describe the responsibility regarding mail separation at this point. > > I personally believe even adding a section or paragraph regarding > System Level vs User Level Filtering is warranted as a nice way to > introduce and/or reference the SMTP level REJECT vs mail acceptance > MARKing and the recommended mail stream separation design/deployment > guideline. I don't see how to put this in a protocol document. As I mentioned in a previous mail, system/user level designs can both do reject or 'marking' so it seems orthogonal to this discussion. Scott K From spf2@kitterman.com Sat Aug 18 19:17: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 B871C21F84D8 for ; Sat, 18 Aug 2012 19:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiPQPs6Rkssd for ; Sat, 18 Aug 2012 19:17:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB321F84CE for ; Sat, 18 Aug 2012 19:17:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B8A9C20E40EA; Sat, 18 Aug 2012 22:17:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345342645; bh=ldOeSPJ+DrP3k1NZCcomne0paMxHrYCalR0VAlnpKdg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LgGfnG02I64yluwulJ+9aVhtYgjkP9MF/E0jCpYVZW6PgfRiDagBtdGrsLf5MX0cC aTEl+ZKpicpngTqy64+BOMph9ZpZL1Au9eJ9YpwMQU2VnnaE/Cp3HesbEwM5ocC/Qb E3rMyULHzpW050a3OkGBaZYl4D5Cv74HauCqyeeg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8DEAA20E40A6; Sat, 18 Aug 2012 22:17:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 22:17:24 -0400 Message-ID: <6230458.bYJkCMvPgu@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120818193316.35320.qmail@joyce.lan> References: <20120818193316.35320.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] macros, threat or menace, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 02:17:27 -0000 On Saturday, August 18, 2012 07:33:16 PM John Levine wrote: > Since approximately nobody has noticed this before, it just confirms > that approximately nobody uses macros. That's why I don't suggest > trying to nail down the right thing to do, just note that macros allow > hostile senders to inject arbitrary text into your DNS queries, so you > should defend against that. EAI makes it somewhat more likely that > names will include hard to handle text, but the problem's been there > all along. The way I have addressed this is to remove the attempt at an EAI discussion in the local-part macro, which I think is a can of worms that we don't need to open and to rework the untrusted data security consideration into three sub- sections, one if which is about macros: allow senders to inject arbitrary text (any non-null character) into your DNS queries. It is necesary to be prepared for hostile or unexpected content. That's in for -05 and we can tweak it from there. Scott K From internet-drafts@ietf.org Sat Aug 18 19:42: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 1C92221F844A; Sat, 18 Aug 2012 19:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h22s-o429uwd; Sat, 18 Aug 2012 19:42:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08AE21F844B; Sat, 18 Aug 2012 19:42:37 -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.33 Message-ID: <20120819024237.29913.24186.idtracker@ietfa.amsl.com> Date: Sat, 18 Aug 2012 19:42:37 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-05.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, 19 Aug 2012 02:42:38 -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-05.txt Pages : 66 Date : 2012-08-18 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Sat Aug 18 19:47: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 75E9121F844E for ; Sat, 18 Aug 2012 19:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpOMzaQV486I for ; Sat, 18 Aug 2012 19:47:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D2F9321F8444 for ; Sat, 18 Aug 2012 19:47:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 511AC20E40EA; Sat, 18 Aug 2012 22:47:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345344466; bh=bOMrd76H+4djHlnqWgT+vSCFQq+IWDskmeFiMmLUkRI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MWEyc9VwT6NJ69RclqezT9py91VJIhmIYe7AoqM8YwvoKvaVVacGlDF3TAUmK0hx7 h/F7Auaty+xyMWE7jeHJcXnkWkBcZffwm+OAfU6NAQ8O3k+51JctucwDdJ2vYScGBa 21tLyiDZ6UnCl8byHEKU/sxfTeWnXHgtY3dqAIiI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 241C620E40A6; Sat, 18 Aug 2012 22:47:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 Aug 2012 22:47:44 -0400 Message-ID: <1590384.urf1VNe3Yz@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120819024237.29913.24186.idtracker@ietfa.amsl.com> References: <20120819024237.29913.24186.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-05.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, 19 Aug 2012 02:47:47 -0000 On Saturday, August 18, 2012 07:42:37 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-05.txt > Pages : 66 > Date : 2012-08-18 In several cases over the last couple of days, I asked people to review the text in -05 when it came out. Now's your chance. I believe that virtually all the changes in this update have been discussed already. I did finish moving the normative aspects of processing limits out of section 10 and into section 4.6.4. As a result, I've changed issue 6 to waiting for WG review. Scott K From hsantos@isdg.net Sat Aug 18 20:17: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 14F0721F846E for ; Sat, 18 Aug 2012 20:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kohpBfZ4FkPR for ; Sat, 18 Aug 2012 20:17:47 -0700 (PDT) Received: from secure.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8D021F845E for ; Sat, 18 Aug 2012 20:17:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1661; t=1345346255; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=quKkugfJ9BxccPjIcadPKRR0iQM=; b=YzjRtpjs2tVAOyGNoQE7 NkwW1uGm8A9OThE35mGiWrCHfeGOym+rlzJDawSX079gLqsxkmxjLr8WmeWf7g4k FOldIUVFn+pqa0+Dlr8zI5jlni1XvOzr36g4+2ObKx0X72dzDfTvRR77fps+5X7g YtkHxJIa4zXY8zxzJhVipgg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 23:17:35 -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 1368056658.23649.4612; Sat, 18 Aug 2012 23:17:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1661; t=1345346073; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CPZhiqu CHM03XP5uTc75hof6LKCiGzKYPl4iW8DCOJ8=; b=X6pnjH4kjIAjW8gtYDAzIC2 NX8nUL45GckGT30sFPvrIEQMWXSyb+5atC6TPQkEqXD2ryfbyZSFhw5Q+k7gsf2p UUpFUkX+2BOmrT2uLQkvVOdyHqxCOZSyYT8x/uzYE9zOfDY6MXhMPQ9PvKtEb1fg DU2k3/UBT925E88W3oT8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 23:14: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 1966870833.7.3596; Sat, 18 Aug 2012 23:14:32 -0400 Message-ID: <50305AEB.5090304@isdg.net> Date: Sat, 18 Aug 2012 23:18:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Optimization consideration X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 03:17:48 -0000 SPF, like many DNS related protocols, get a bad rap with overhead and correctly so, IMV, most of it still overhead. Since 2003, we learned immediately that we can get 60% reduction in SPF overhead simply by following the ideas in RFC 2821/5321 section 3.3 Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. Is there similar text for SPF? The 60% is unique to our server as that as been the consistent amount of bad/unknown RCPT attempts on our server over the many years in service. We still get stupid #######@compuserve.com attempts, and once upon a time, winserver.com was a free domain for our customers to use an alias on our server using the old school MHS email address formatting. But it was abused so we stopped it in 98, but the spamming attempts has never stopped. So SPF checking is delayed under RCPT TO is a valid local user account. For remote user addresses, it is only allowed for authenticated senders so SPF is skipped here. Its only used for anonymous local user mail transactions where authentication is not required (for public service port 25). If SPFBIS does not have some insight here, I believe it valuable insight to have to help minimize DNS overhead/wasted lookups when mail is not going to be accepted anyway. -- HLS From superuser@gmail.com Sat Aug 18 20:44: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 762DF21F8498 for ; Sat, 18 Aug 2012 20:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C25NHY7CyxIQ for ; Sat, 18 Aug 2012 20:44:46 -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 89FF821F848F for ; Sat, 18 Aug 2012 20:44:46 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2908042lbb.31 for ; Sat, 18 Aug 2012 20:44: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=xH3LM2ifw4MVMN5GXdcvSUj/NLellHNp6mCxIN2FXtg=; b=rOYPou9LfbAcSnnl6q41HsQzYPTOMRSn9wHJKPXRCyzzjqDVJ3eKeiPtub3hBwO7tQ Q0aCluWeFqXYHbm3szGrkQO4byXFlYNY8eFD4kOYnetFDX6m9DxCYDgWDE4teA3DswHr eXSpgNe3fmGIR9XMyHhGbBx8q4fu+GVRZOcj1L2sQW79n31RNk3cdTVGLxMJw8HZa5Hi R31qN+aMwtAFSMOlWGjhwMKGKo+RykUuEi+A0mo8QIB96i2FavxccMLxGae5UHsV8ElP oyHNQHXkIhiuK/7NSZ64gpg+uKy29n0g6D2qbrX3SezpeTxV7a9h++FcmuINjebCNnPG kDkg== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr9605320lab.25.1345347885489; Sat, 18 Aug 2012 20:44:45 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 18 Aug 2012 20:44:45 -0700 (PDT) In-Reply-To: <502FD66C.40607@tana.it> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <502FC01F.8050509@tana.it> <502FD66C.40607@tana.it> Date: Sat, 18 Aug 2012 20:44:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 03:44:47 -0000 On Sat, Aug 18, 2012 at 10:52 AM, Alessandro Vesely wrote: >>> The workaround I suggested, helo-pass prevents rejection, isn't really >>> that complicate. It can be explained precisely and concisely within a >>> single short paragraph. But different participants dislike it, for >>> different reasons that I never fully understood. >> >> What I want us to avoid is presenting a pile of things that, >> individually, are not that complicated, but as a group they simply >> give the reader far too many variants of basic SPF to consider. > > OTOH, if we were able to define a compound result for receivers who > check both identities, that would be a relevant simplification. If an > added paragraph could save endless discussions times implementers, > it'd be worth. I believe we're constrained against adding things like this. It would constitute an extension to what check_host() currently does. A receiver could decide to execute check_host() twice, once per identifier, to get two results if it so chooses. That's not an extension to the algorithm, however. I would argue it constitutes an applicability statement. To be entirely procedural, the SPFbis charter limits us to "addition of any enhancements that have already gained widespread support", and although of course the co-chairs are the abiters of such calls, I personally don't think this qualifies. >>> There's plenty of other ways. For example, the receiver could check a >>> DNSWL before rejecting, and advertize which one it uses. Instead, >>> Section 9.3.2 suggests that "the sender [...] might then be able to >>> resolve the issue". What if it is not able to do so, discuss for ever? >> >> That's further added complication. > > "As simple as possible, but not simpler." Right. Otherwise, why not also suggest correlating with DKIM results, WHOIS data, content analysis, REPUTE results, etc.? All plausible, but all outside of the core of SPF, and I'd wager all relatively untested in terms of protocol development. And they also exceed the charter, as above. We need not to dive into ways to complicate matters. >>> Neither Section 3.9.1 of RFC 5321 nor Section 5.1 of RFC 5598 consider >>> it makes a difference whether the expanded aliases land within the >>> same ADMD or to external domains. It makes a relevant difference for SPF. >> >> SMTP is relevant to SPF, but SPF is irrelevant to SMTP. That's why an >> update is the wrong thing to do. > > You know this better than I, so I'd bet you're right. However, RFC > 6409 warns against message modifications that can affect signatures, > while pre-DKIM RFC 4409 didn't. RFC 4871 has no "updates: 4409". Is > there a hidden update? Section 8 of RFC6409 refers not only to DKIM, but also to PGP and S/MIME, technologies that easily pre-date RFC4409. I read it as an acknowledgement by the authors that RFC4409 should've done that in the first place, and this is going back and fixing that problem. DKIM happened to come along in the interim. Also, in my experience, "Updates" in terms of RFCs tends to be used only to add to the normative language of a specification, not as a means of providing more information to implementers. Correcting ABNF, adding normative constraints, applicability statements, adding extensions, etc., are when you'd use it. That's why RFCs 4871 and 6376 didn't do so. -MSK From hsantos@isdg.net Sat Aug 18 20:46: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 CF1A321F84C9 for ; Sat, 18 Aug 2012 20:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iC7sW70bY8p for ; Sat, 18 Aug 2012 20:46:18 -0700 (PDT) Received: from secure.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5954221F8498 for ; Sat, 18 Aug 2012 20:46:18 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=22924; t=1345347971; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nIw0iPcaz31UZuSFMT6MLZFA1no=; b=msmF1A+E+tbgEY2V1Ip1 5yzci73/6RM+8bOupP+mkztwfgFOj/RZW9bWifiESxKlRKNlex02it7AXCB0Nfmz KRhZ1H+8Sm1HjNJtKXKkE7IdoaTc8F8OCeqAjZGFBFQa4sqN0rpWuavMDo3NF59/ TYXTR6YG1ACAyqzWesmCg54= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 23:46:11 -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 1369771639.23649.3544; Sat, 18 Aug 2012 23:46:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=22924; t=1345347786; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CoHoa3K X47BsoI9QZkzWF2nYxwtJ6keRi9+rczSOYZE=; b=o1zh0xcQlmBkxnico3Xkx5o PJtADp7cLdWjMJQ/UX7UnJNtajfVhNC++prklXuJR8eqpwEAuRrzjv4nS5cIQvhK CGAi1VdUomiXMIlfeVLew4BUc4GBOtKehOHp3ds71OcsS1Jqb+07WD+2pjE8DNBJ I1rjaE7SvufWrdB4SyoQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 Aug 2012 23:43:06 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1968584802.7.5664; Sat, 18 Aug 2012 23:43:06 -0400 Message-ID: <5030619D.4060104@isdg.net> Date: Sat, 18 Aug 2012 23:46:37 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <50300F0E.1080409@isdg.net> <2569465.PHZWXk9PS2@scott-latitude-e6320> In-Reply-To: <2569465.PHZWXk9PS2@scott-latitude-e6320> Content-Type: multipart/mixed; boundary="------------000804030901030308080905" Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 03:46:19 -0000 This is a multi-part message in MIME format. --------------000804030901030308080905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Scott Kitterman wrote: >> I never quite noticed this before, but the sentence with the usage of >> "postmaster" >> >> When the reverse-path is null, this document defines the >> RFC5321.MailFrom identity to be the mailbox composed of the local-part >> "postmaster" .... > > Here's the full sentence (updated for my terminology changes I mentioned > above): > >> When the reverse-path is null, this document defines the "MAIL FROM" >> identity to be the mailbox composed of the local-part "postmaster" and the >> "HELO" identity (which might or might not have been checked separately >> before). > > All this says is that if he reverse-path is null, the construct to use for an > SPF "MAIL FROM" check is "postmaster@" + "HELO identity". This is unchanged > from RFC 4408 and I think is fine. I think you may be reading too much into > it. Yes I was. Perhaps as you stated here would clear this because I didn't catch this before. I can see how it can help to fill in data for macros, i.e. %{l}. Perhaps necessary to add something for the 8.2 Expansion examples for the special case: 8.2. Expansion Examples .. macro expansion ------- ------------------- ... %{l} strong-bad %{l} postmaster (when reverse path is NULL, see section 2.2) ... > >> o 2.3. Publishing Authorization >> >> An SPF-compliant domain MUST publish a valid SPF record as described >> When changing SPF records, care must be taken to ensure that there is >> a transition period so that the old policy remains valid until all >> legitimate email has can reasonably expect to have been checked. This >> can be as much as 30 days. >> >> Where does this 30 days come from? > > I got a comment that the RFC 4408 language was too vague and we should provide > specificity. It used to say: > >> When changing SPF records, care must be taken to ensure that there is >> a transition period so that the old policy remains valid until all >> legitimate E-Mail has been checked. > > The problem is that there's really no way to do that, so I tried to improve > it. > >> IME, that could be 4, 5, 7 days, 2 weeks or even more than 30 days. It >> must be some particular setup/experience, but certainly not universal. >> As far as adding some "SMTP" related factor, it would be 4-5 days for >> the recommended exhaustive transport retries where it is very much >> applicable to SPF. In other words, if a message does not get sent >> within 4-5 SMTP "example guideline" days, it usually gets bounced. >> That is the guideline we used for other things too like DKIM revoked >> records as well. Whatever the limit, it should be pretty close to the >> SMTP practiced of 4-5 days. > > The problem is that there is no universal. The only spec I recall seeing a > specific recommendation on this is the original Microsoft Caller ID for Email > specification. It suggested 30 days. I asked a few people with experience > (which I don't have) in supporting domains with large consumer mail flows and > the feedback I got was that 30 days would cover most, but not all cases. I > had been thinking a week should be enough, similar to your suggestion, but if > we're going to try and bound the problem, I think we need to do it keeping in > mind something that will broadly cover many situations. There are two delays: - SMTP Transport Delays - SMTP Acceptance/Mail Pickup Delays (Transport is complete) Transport delays are well defined in practice. SMTP long recommended 4-5 days. But once received, Local Mail Storage policies come into play. Despite what offline MUAs attempt to take control of, the backend is in full control. For our system, see attach image showing an example mail conference policies. I intentionally set some typical past values for email you may see in the customer base. But these days, its archived forever anyway, unlimited or huge disk storage allocations for users allows for more server side storage which make the offline MUA work better too, especially for Roaming Users. Unless I am missing something, I don't see how SPF applies to accepted mail payload pickup delays going beyond the 4-5 transport UNLESS we are time shifting the SPF checking application to the MUA. In this case, yes, I can see the offlist time shift need to have a MUA related delay. For DKIM, I had written a 2006 I-D related to this time shifting problem. http://tools.ietf.org/html/draft-santos-dkim-rcvd-00 allowing for a migration and partial DKIM receiver support to add the DKIM dns record to the headers so that delayed checkers can validate the message in the future just in case the DKIM record was revoked before the MUA picked up the mail. I guess, for SPF, this would allow a Partial SPF Support receiver to just lookup, save the SPF policy record in the RFC3522 payload to allow a more complete SPF checker to do the work. This could be the MUA. -- HLS --------------000804030901030308080905 Content-Type: image/png; name="mailpolicy.PNG" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mailpolicy.PNG" iVBORw0KGgoAAAANSUhEUgAAAZkAAAG0CAIAAABv9c1xAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA MYZJREFUeF7tnff/f0lV3ze/xpioaSamaKJYQFEEG4JfwIqogAUVFSxYlrJLZ2F3WXpfeu9V LKACigWkWbDGGJOoiaaZGE39D8y892yGeZwzM3dun3vu8/2Yx/fx/t73lDOvmXnOmfnMvfev /cHvffQqPiiAAihwZAUecu3jrgos+ys+KIACKHBYBW666aYrV67cyrJANAIKoAAKHFEBzbK/ /ulXh/Bxn/HgEP7GbUJ4yMd/ZggP/fjPeujfDOGzH/a3bgmf8DnXXMJtr/nE2177ibe79pNu 9/BP+tyH/+0QPu8RIfydEG7/yL8bwueH8Ki/9wUhPPrv3+ESPvkOj/nkL7yEf3DHx4bwD+/0 uBA+5YtCuO5Tvvi6f3QJj//HX3IJ/+RLn3AJX3b9Pw3hztd/6p1v+NQvv+HTLuHGT7vLjf8s hLs+8Z+H8BU3fXoIV0J40meEcLcn3eZuT77N3S/hM+/xlBA+6yufGsJnf1UITwvhc746hKff 9msu4XZf+4xL+Lpnfm4I93zm593zWSHc/utDePbt7/Xszw/hG57zBSF843PvEMI3hfC8Lwzh 3s+7471vvuN9br7TfZ5/p/tewhd98wtC+OIQvuWFIXzJt4bwoi/9thBe/GX3uyV8+0vufEv4 8u94aQh3+c4QXnaX+7/srvd/+V2/6+VfEcJ3v+KKhO955d1CeMAr7/6AV939ga+6xwNffY/v vYSv/L7XhPBVIXz/a786hB8I4XVf86AQXv+1PyjhDV/3Q5dwzx9+Ywhf/yNvuoSr33Svq998 rwe/+Rsu4S3f+JBbwkPf+k0hPOxt9w7hmrfd55ofvc+1l3Dfa99+34e//ZtDeMSPfUsIj/zx EL71USH8xLc9+hLu9+ifvN9jLuHbH/uOEL7jce+8hOve+Z3X/VQI9398CD/9XU+4JVz/M98d wg3v+p4QbnzXA2589yU88d0PfOJ7HnjTe743hCf97PeF8OSfC+H7nxLCe38ghKe+90FP/fkH PS2EX/jBp1/CDz3jF0P44WeG8Esh/MizQnjf1c8O4f1XP+f9Dw7hub/8kFvCQ5/3gUu4+QMP u/mDD3v+B695/oeuecGHrg3hhR8O4eEhvOgjjwjhxR955It/5ZEvCeFXH/XSS3j0y34thMeE 8PJfD+Gxrwjho497ZQi/cd2rbgmv/s3H3xKe8JrfuoTX/tb1r/3t61/32ze87ndueP3v3HgJ v3vjG373iSG88V/cFMKbfu9JIbw5hH/55LdcwlPe8vtPeevvPzWEt/2rEJ72o38QwtPfHsK/ fsaPSfg3z/zxS3jWT/zbEJ79k394Ce/4w+e844+e884/eu4l/PFzf+qPnxfCT/+7m0P4mX// /BDeFcKfvCCEd//JC9/9py98z5++KISf/Q8hvPjn/mMIL3lvCP/ppSH8fAj/+WW/cAkv/8X/ EsIrfunPLuF9f/bK9/3XEF71/hD+26t/OYQ/f/UH/vw1IXzwv782hA+F8BevC+HDf/H6D//l 6z/yl2/4yP94w69cwht/9X+G8KYQfu1/vTmEXw/hf7/loyH8n7f+xiW87Tf/75YhwBeWwTJY BstgGX4Zfhl+GX5ZwS8btfMWtrrEj5uWCr+MNSZrTNaYa60xA5Ua991keRhZNiHVRJYJOLvd L4tc33e/TMw4w36Z1DTsl8kXu18m1yfsl0lC9ssOul9mWZae90iBtSLLlJun9v4jy+RL2PuX L3HvX/47ee9flT5q71/S9rD3L5YElqnqZPf+Jc6ovX9J0rj3r2ywe/8SQe39y8XS3r/8Gvb+ 5UuJZfKr2vsPV2TvP3yJe/+pkXHvXy6y93/Evf/QcCmwBGRyJf0eXSrrl6loKmFKwKJfJh2o 9HdM+TX1y+TKIn/HlKwm/x1TknfIMvk7ppi3yN8xJatRLKv8HVNyC5/4d8x4ZfDvmBJzJssk E/k7pnyXv2PKd1h2TpYpeFUIOI5lsXPLl8Ay+RL9MvlvOJMhX4JfppLEMxnqenomQ36yLEuT yJkMlYmcyYgX5UxGGkfOZMiVcCAj/CtnMtI4ciZD5RzPZKTX5UxGeqV0JkPiKJbJxXAmI/wb zmTIf4NfJl/kTIZ8lzMZaUFyJiO9Imcy0ivqTIb81MKyEC2cyUizEpalV+RMhlxJ/TJ7JkPi pGcy0nzi93AmQ75blqU440zGsc5khAbN7nxZb6u+xmxZmQ6wLHa1sMaU73K+TL5bltk1psSU 82XyPZwvky9yvky+D7JMosn5MvkeWSbny+RiZJn4ZXJRzpfJ98gy+W8EmZwvk4uRZXK+TC6G 82XyJT1fJlfkfJl8z54vk5+yLJOfWlgWz5dJksiy6JfJdTlfJt/T82VyJX6ya8xwviyNEw6X yX+VXyYXYRnnywbPl4V+YllmQVZZY8bkg6lG+GXSg4/IsnR8pn6ZnJVVgzz8dyzL0hwqLIvR ZL9M/hvPysp/Zb8szTCelVV2lliWRrMsS/2yNGY4KBv+K2dl5bqclZXv1i+bw7JwVjYkl7Oy 4Us8Kytl4Zd5OisbGnQRli3gl6X7ZdLVjsgyde5fKhLP/ct/1bl/uTjKL6uc+5fc1Ll/udjI Moks5/7le90vs+f+JVV9jWnP/UuqwDL5Iuf+5fs0v0zSqo/s/ctFWOaeZdlVZ2WN2fgXg1P4 ZYdjWbiHSQZ2vIdJ/gvL2C9zsF82uFoMXb2ytEyTj/g7Zpw/5UyGmk7T/bJwP2b81e79q/2y cDOmykrdj6l+lTMZ6cV077+yX6b2/kMOdo1pl5mlNWa4HzO1we79h18H98vi/ZiSVdYvsyxT e/8hodyPGe2xe//hpwn7ZZUzGapRGv2ycD+mJIxnMsJ3uR8zfFH3Y6ZFcCbDwf2YKZXad76y qQa9uYlnZRe8t1y6L/eWO763vJ1l2XvLJTlnMhycyaic5l/xrOzaz8lIZ2Cek+H+ORm34mz8 czL+P8h4TsYhn5MRmi9AqvGT3sPUmKRpjbk2y3jmD8/84Zk/7p/5E/A06iPn/kcliQTcf43J 88t4fhnPL+P5ZfOfdAbLeE4Gz8ngORlrPSdjPqHac8iwrPFpG0RDARRAga4U4Hn/vOIABVDA gwKwzEMrdjU9YgwK7KIALINlKIACHhSAZR5acZdpkEJRoCsFYBksQwEU8KAALPPQil1NjxiD ArsoAMtgGQqggAcFWlmmHpPQw393YT+FogAK9KlAE8van8KxZSXDrVhbFkdZKIACPSswzLI+ QRZvWdjeQ0ybc/vSSyX2adUG+vQ8urBtSwUOz7ItxZKyoj/YFeX7tGqD1sE930DkQxQBy0bv eopkXYEs9VIP0e0WNFKaY8EMyeqgCsxlWekVKcvKEV93nGa7VyeGZcs27szc9uoGM80m+eIK zGKZQkyWOItYDMsGZeyTsINmz48Ay+Zr6COHJVm2niLtLEv9xBa2tsRR9apTIxowSo0JZoyy KkSeX8SoGo2KLLal/7Ynh2XtWvmOuRbL1JCO3TQdUTZO/DWbPDt61cVGVzEtaGwDV1imalfK eU7ppTwH/bJuWdbYZPWKj21E4vtTYBmWVdBjKWan38qEXPkpOyE3Dow5NGlkWaWvzCl9Gsum uTzbdPfGJoNl2zTHcUtZhmVSf+tVCePUAielWwrBrMu2FMtKPmDFYZxAjZLvUyk9rWDFmKik iGkLGlz52mWmsirmnG2IqIYqPWtMzFl1idhPstVRbV0yr8U9P+6AxPLJCqzFssrSr4SntN+n I8cOQvm15JfZgZQakx0wKYuzZqQ5DFLDjvZSdVRZaoSX5gA1c6RqlN6uqgyo5xx/VVBT05X9 ry3FZtWY52C0WBb7ZZMHv7OEi7HMjsMsINrHSSl5vRMPekaWZfVxbtt7cGdKsSZla6l0y/fS lTrZp7EsC0cpKOth2blBqdRIoqwa8eJg0ZUpzdkopTotCsxiWdrd7VRfp5tKW0pecuJC/Jb9 MjtKW1hW4kU6eAbPylb8O/vTKJZlzavv4rVwwU4DlYmhjrNFWJbtvtYk/LKWcX6GOHNZtqNG K7GswqBBltkxbBmdXlFlVRBg/Vk1qkssKxFqVFml0ktaLcuyyvRTmtJ27JYUvZcCp2CZWi6l zlqJPiWXJA6ekl8WPSDluaReqsVZyS8rWV5yT6xVFW/Lmtp+JdZO1Stqq7JSOqepSkAvGaOG Cn7ZXuzorVxvLNtA38b9ssUtqeB1kLCLG1PPsG7qssbAsmX1PG5usKzre8vtPlepq+1F2Kw9 sOy4RDiu5bCsa5a1d6yuWNZu9vyY+GXzNfSRAyyDZaMV6Krrw7KummNHYw7Psg2eXEoRKIAC /ShQelzdgVm24wxA0SiAArsoUHHDYdmxV1i79CcKRYG9FIBlAAsFUMCDArDMQyvuNRNSLgr0 owAsg2UogAIeFIBlHlqxn7kRS1BgLwVgGSxDARTwoAAs89CKe82ElIsC/SgAy2AZCqCABwVg mYdW7GduxBIU2EsBWAbLUAAFPCgAyzy04l4zIeWiQD8KwDJYhgIo4EEBWOahFfuZG7EEBfZS AJbBMhRAAQ8KwDIPrbjXTEi5KNCPAh2xTD0JfssHw/fTHliCAigwTYG+WJZ9jdu0ipEKBVDg VArAMtaYKIACHhToi2VhGsm+79q+HTa+Eda+KDd75VQTFJVFgRMqsCnLQmH2E0VXL+jO7peV 4pRe7m3JmLWBiyiAAv0oEF6GMoHFW7PMvrJFsSy6ZmrvLHXNLKEiy+wbcBUT+3lnDJagAApY BQKSDsOyEnEtvCSm/YNAhWXZzPmT6IRZjiQosIsCsOyqRurt0jwUigIo0KiAN5ZZMLWsMSUV e/+NnYZoKNChAh5Y1qGsmIQCKLCxArDMwwGZjTsNxaFAhwrAMliGAijgQQFY5qEVO5wkMQkF NlYAlsEyFEABDwrAMg+tuPEESHEo0KECsAyWoQAKeFAAlnloxQ4nSUxCgY0VgGWwDAVQwIMC sMxDK06bAPt5vAGWnFyBafeEq24Py07Nsit8UGBvBQKSYNl5MTTNEbPzWOjGPD0GBfZVAJYB srkKyCPo9u3HlI4CsGzuSF7EtTl0JrAMjvSgACyDZXMVSFmWPlY3fFdd3F6ZMwbGllUpXX5a 1rw5VSPtBAVgWX4k20ddN7pOJ3yErGJZ2gsn06ElYT3OBJK2FDphjJFkGwVgWYZlikfteGqP 2UjGQ0TrlmUpm2Ryqg+qwQjbjElKmaYALBtmWTtQYJnCQVy7pYs4hRjpuNERTv+b/Sl29EG/ rMIyWxxrzGkE6ScVLBvBsjgAhG5CLrkYr6jvjT+pfOJ/Uziq0iNhrRk2eZo2NTgbs53dEnNw vywyJSVa5FR2T00lyUaOlcpCzdKzMVo/gxNLRikAy1pZprBiKRbpln5JkZcSsELDenL1a9aM FEaRdKp0dd1m2060yhpTMagOtdRXSmOWmFViU4li1k2TnKNHls1w1HAi8o4KwLJZLLPOUeqg KW9o8CcLvjT/dEhbWllUlUq3GC15fI04m88yRZl0uVfhSx091rOr+HrWYdxxTFL0NAVg2Vos UyCIbl3q31U8tVJyy5esw1iBrGJZI7Aq0SawTG1ONbJMwQuWTRvzXlPBsmGWlZZjFYhM+ynr lw0uBpdimYVsI+bmsyzd+8/6U3ExmI7D1FG1XKtfSdOyxvRBN1g24nyZWosNQkTiZ52vyk9q KWqXmRWXLS0utdaaYWNaOyewzMeooBZHVACWzT313jjgHUfjHqYjjnx/NsMyWDZXAVjmjwtH rBEsmzuSHTtcjVWDZUcc+f5shmWwbK4CsMwfF45YI1g2dyQ3Oi+OowWWOa4dVTuQAgHB863l GdnnZeIR53Bs9qoALDsviea3PTmggCcF8MugIQqggAcFYJmHVvQ0u1IXFJimACyDZSiAAh4U gGUeWnHaPEYqFPCkACyDZSiAAh4UgGUeWtHT7EpdUGCaArAMlqEACnhQAJZ5aMXJ81hofj49 K7DIgfhp3eNwqWDZqVl2hU/HCix1o+LhqDTNYFh2dpZ5vSfGQb1g2SiowTJYdnnHpYOR768K sAyWnRdPY9s+LLDU60j8EeG4NYJlY/vztO1FefhVtiz56fK8/FLWY4ts9B7TF1uMUmHy6z9G ldJb5Pj8MvyyPnkHy0YNmUZK2Dy7Y5niUTue2mOOUrb/yLCsT4RFq2DZqEHklmXtKsAy/LI+ oQbL2kdxiOmfZdkXyqlXw1Ve1FZ/h1uaT1BTlZW9Epsn+3o6VZyKXHr1nBQ0quGl7dkv65Ni YhUsG9WlnbMs+ypM9dLJ0qswU0CMyicmtKlSNsl3iVM3KVu6zWpUw8OynikGy8Z2Zv9+WQsF ss6ORYz6w0I958ipyp8jsqSrgDXLvmkemWSFX9Y5zvDLRhHtjH6Z8miy+EjBkeVFI8vqjWGL rgOuxeNrb35YBsvae0v/Md2yTDlWFQpMXmOWmNhCnCzFSmhr8S4ndDVYBssmdJtuk/hhmRAk flLQyEXlapWIU4lczyc1oFR62g/S3KzrZ39Vpauaprxr7G2wDJY1dpVDRHPFskMoXjJyFIxG RS6VCMtg2aGHjDIelu1/w5NywVq6FyzrHEOLmBd6wtg7ZFo6j9c4sGx/lu3Vt6JftsjAI5PF FYBlo4YGLINli49BMlxGAVgGy86Lp7FtL+f++fSpACwb25+nLcm7u7d8VLWJHBQITYgOnSsw bXB2XqmVzGONeV4nrk9nBKuUAiuNfH/ZwrLzssxfb6ZGZ1YAlsEyFEABDwrAMg+teObZmLqj gCgAy2AZCqCABwVgmYdWZGZGARSAZbAMBVDAgwKwzEMrMiejAArAMliGAijgQQFY5qEVp83J oe35oMC+Cix4YwMsOzXLwv2YfFBgLwWWveEUlp2dZdwzhAJ7KQDLzkufaWvJUiqeX7bXGKbc NV6ah192XjLCMpiyrwL4ZXn6VN5EaR2T9mdMV2K2Z7KsP7VUbrBs35FM6bCsyLI4yOuUGcUg +246KWVUJkvRZ9l8YBk02VcBWDbMsjprRmEIlu3b3SndsQKwbDTL7Ksk09dltrw9074qKV7J vrYy+m7ZaMp/bHwVpgA6BfHMV2TilznGxCGqBsvGsUwN/pLLZv2v9Ip15VIa2lWnys1GTmFX WrTWM7H1GrsChWWHGPCOjYRlo1mm/iyQdW32Ypnd4ytZq4CYRhu1ao4lwjLHmDhE1WDZaJYp hyXrJXXCsooXaVk21hFT8WHZIQa8YyNh2TDLSuuv0qotLjxTXmyzxrR7Z6UrFZbhlzke8I6r BstGny+r7JGrBV26v14BX7rp1rIZX9kvm7zGjKaWMh/02vDLHGPiEFWDZec9qT+Ip1ERYNkh BrxjI2EZLFtGAVjmGBOHqBosW2Ykj3JhXEaGZYcY8I6NhGWwbBkFYJljTByiarBsmZHs0tUa VSlYdogB79hIWAbLllEgsGwU+4iMAosrEEi9VJ48v2wZLizVHlvm43jCp2oHUmCpPg/Lzsuy pfoQ+aBADwrAMliGAijgQQFY5qEVe5gVsQEF9lUAlsEyFEABDwrAMg+tuO98SOko0IMCsAyW oQAKeFAAlnloxR5mRWxAgX0VgGWwDAVQwIMCsMxDK+47H1I6CvSgACyDZSiAAh4UOAzLgqF8 UAAFUKCiwLS7O+UhC1nXUn66qnIT/NgiD3RzGaaiAArsqMCE1e6mLJtgH0lQAAVQoEUBWOZh i6GlpYmDAr4VgGWwDAVQwIMCsMxDK/qeb6kdCrQoAMtgGQqggAcFYJmHVmyZtYiDAr4VgGWw DAVQwIMCsMxDK/qeb6kdCrQoAMtgGQqggAcFYJmHVmyZtYiDAr4V6ItlVyWfUbqHdKPiz49s S6zYID+pCGllx6ZtsT9bqDVDZVVXcnudW2pKHBQICnTEMjvUG1tolwE2imVSkXoFS7WYVruY amZy2wTTMmxsSqKhwGQF+mVZe5V2GV3iVUUj1X+zxsOy9jYlJgqMVeAALItrsdS7Sdlhv6de ifquHJYskiyksl5YhWUlm9PmKaGtnjb7a8XpK/mPaT5KQMktq+HgEnVs/yM+CiylwKYsyz6x KHVt6isaGV3ZgWcXcTFy5SfLNWWMopUlUVqKpUYc+cqYaFIEirJEUVvlY3+dxjKlTLYu1rB4 hSdwocDiCox9jFg6JLdmmX0i0gSWlYiTosGyTIHDcqrkfClXqBE0yvGp4KbkrFm4lJys9VhW yXnHh1tRtEsFJj9RVkbQDiwruZQVvybriVhvpX2oqyGa9ZvsMM5Cp+K5DPpljX5o1i/LelV2 YihpUjK75ELWp5xSm3IdBdoVcMsyO6gGr1RcrboXNphzi+PTuE6c5oeWLBTDJkC8kWV1Urd3 U2KiwKACflgWh6UanGqJN0ilNLmKXPkpujn10iskypZl14mDDk62vilTrIUV/y7mFlMpLCpa ZeFlNR/sl0RAgbEKuGLZ2MoTv7QQtp7aUlqtl/NSFpLPQRWAZee9CSm7uhz0++Z0dEA2Rz3S 1hWAZedlGWMDBTwpAMtgGQqggAcFYJmHVvQ0u1IXFJimACyDZSiAAh4UgGUeWnHaPEYqFPCk ACyDZSiAAh4UgGUeWtHT7EpdUGCaArAMlqEACnhQAJZ5aMVp8xipUMCTArAMlqHA5Xkv5/zM eeBXbxyEZYxkFLj12VVXTvYJMIJlkcgdPb+st1kCew6kgPRjl08orFQKlqVdFJbh1HhQAJYd aOIpmcoa08NQdNAR960CLNtX/0VKh2WwDAVu3S+Ly7H4BErfq07WmKwxGfzeFEj9sgCyFGqO cQbLjsGyyjPsF3FoycSTArDMQWu6XWPCMge9c7MqwLLNpF6vIM8ss28DWU9Hcj60ArDs0M0n xp+UZaWXMylvLo02+IKlbITYRVSJ4Xr6iiOJVooTf3XQ4fqsAizrs11GWeWZZUIH9a9Sp/SG NIWP0pvTbOb1DLPGqCSlPEe1K5FHKQDLRsnVZ+STsqzkE2VJF+GSUiabQ5q85OJVyDWYZ599 yIFVsMxHI865Javfc//Zl87axVoarfLngopfVudXqUT7+tvS+9Z4D9sGw0ydleV82QaaL16E c7/MulTplcHVXAmIFRJl15h1crHGXLxbj82Qc/9jFeswvn+WRdHtnzXjbr1lVn2/TCAYk8fI toi0dJWktM4tZYKDtt74gWXrabtZzm5ZtpmC8wsCUvM1nJkDLJspYA/JYdk+t+NYp6yH3nBa G2CZg6aHZfuwzEHX8VQFWOagNWEZLEOBy5FxB4N5QhXmHGKYUNyqSWAZIxkFLo+KPu1nVb5s mTksYySjAAp4UACWeWjFLWc/ykKBPhWAZbAMBVDAgwKwzEMr9jlPYhUKbKkALINlKIACHhSA ZR5accvZz2VZYRic88OZjNif+31OhsshR6VWUkD68dk+QUxYBsvw5lwpwLn/lSaJLbNljelq TG7ZdTyVBcsctCYsg2UooN/1e5J7AFhjpgRnvwwQeFCA58ril3XNssozrw/Ucls+3WzLsiY3 wRpGpiwL+fPe8smts2NCz2vMM7OsZcC3xNmxa5aKXsNsWNZhQ481yTnLKg+tHqvUXvGnDd2W VC1x9qp1pdw1zIZlHTb0WJPOy7LJD+yPErc8sF8ix7eTZF8skP6ajVkyNc1NjfD0XQQ2ebRK FacyzGZi46jclD7pr6r6Kv80oYgWI9QtUZHjf6Pyg6MClg1K1H8E5yxLOZL2bOWv2Z+y0FFg smNPXSmNajXGIlDS/JXl7UVnM1EXS3GUJevZYCk22CIzjakPRVjWP6oGLTwvy7JeVapX1tNJ PYWSH5EOVAuRQV5Y52WwIGVqndoWuC0lzrRBqV0hl2VWi3mV/AfHQIgAy1pU6jyOf5ZlB7Yd /I2eS6N3oFp98aFbyX97vywrXYmnK8F9UBD8MntoLmjCPUyxYxzjTIZdMA6uaFp8AeuqWJdn cOhaR29m0duzzHqagzbU9V9j0d3OsjC8o5fn+9AsLEt7xTFYlkVM7K/pr2qM2f+qjR6Vic2z xDJxW9JBWwKuWj3FDJUldqymGaaR05gVapSqVsrWurpZ9TYWpOSAK7m4h6nz9WOLeZ7XmC31 XyRO44BZpKyNM6kTamNj1isOlq2n7WY5w7KJt+Bk3aXNmm3VgmzVHFdWlIRlq/aobTKHZRNZ tk3zUMo2CsCybXRetRRYBstQAL/MQx+AZR5acdXp7gyZh2FwhmraOnImI2rS9d8xz9k7qfUE BXyfvajXboJcfSbBL8MvQwEU8KAALPPQin3Ok1iFAlsqAMtgGQqggAcFYJmHVtxy9qMsFOhT AVgGy1AABTwoAMs8tGKf8+SBrArD4JwfzmRwJgMCulJAzhad7ROGMSyDZa5G8oEcqJVM5R6m lYTdMlvWmFAJBbiHyUMfgGUeWnHL2c9lWfhlDpoVlsEyFMj4ZeExR/bWn+zF497/xH5ZSvCu 78fc5alb/TyXsd2S9pjLzt7qqbbLZj4qN/XuEuk5ClLZi8cFmez6s/d/jL1/9YzmUZ07G7ll zLfEmW9JSw5rWHKUPFv0sXNyCiZYNlbD3eN7XmOqgTd/HLbk0BJnm1Zfw5Kj5DlWYbtfplgm /2WNOVbYLeOflGVx+SlaxyGafrHjVlLFJOl/Y5vZrCR/FdkaYOOkBZUKreRsUZ4tNFY/jV+q ZqMCMdpgrbOlbzkApCxYtr3mi5d4UpYp9CgAZXmURV56McVilgsVapTiNxZa55HitY0spVds KCWxOZcmBtVx0xLtnLF4Lx/MsM6yYKEsP+OXQ2+TReODLOyXxb7R+95/2onVWE2dFAuv7AAr +VyqlIpDFMdwLH2QI9ZFyjpH7flUwJTNpCSUqkLFM81WoROPrMUvS2vqCWewLB25h2SZdUBa INXoIg0yxbpydZ+o5CRmU7X4d+0saxQq63NZuUq59e+XRUfGE8j4O6bqt4dhWWmQK5dBLZqs h1Var7V4JZWVYAuDKmRZZI1Zr5pi9CiDS3y31wcXgytFGNwvY425kvILZut8vyxdH9mVoFqs 1ZeKFnNpcssy5ZioyMqw0nrNOl+lfErruNQwW2gLmiup6gpYj1JVM2XZvt4Z5/4XZMpeWXlm 2ShN9x1LG5S+QRGjBO8qMizrqjmmGQPLbj0wMU2+pVJtAJoNilhKje3zgWXba754ibCMuxFR gOdkeOgDsMxDKy4+xZ0tQ/wyBy0Oy2AZClz8MgeDeUIVOCsbRev6TMaEpiXJORXwcY5/Wi3c tDh+GV4JCqCABwVgmYdWdDO1UhEUmKwALINlKIACHhSAZR5acfJURkIUcKMALINlKIACHhSA ZR5a0c3UuldFwjA454czGZzJgICuFJCzRWf7hGEMy2CZq5G8lzfUT7mc+++nLSZbwhoTKqEA 92N66AOwzEMrTp7KSCgK4Jc56AmwDJahgGZZfGZk+nRsuTjtPqE+U7FflhK86/sxKw9rXW8W OtZjwlay1ma7+OOwl80w9ctSYMl3e6VPNo21CpYdiWXR1kUGbUsmLXHWI+nYnFeytsSyseYN xl/K/tIaE5YNNkE/ETyvMVVHn9/vW3JoidNP869kLSwb6yLtEh+/7JB+WTA6HWBx+SmViT+l X7IDUkWoDNpKcVKifKIB6krWo5T48d+stTafypVSHSs6xNysaMo2VUGlc/prWtl4XUXINlkq yJwZwvplUpx9/VK8uAt9li0UlnlgmSKFGpbZUZpFnkJkOpgHYZRiVIEvldj+VGdEZVltR75i WbYsxYh6nFIRisIlI63yWdpmdV6WZSnFUn7Bsjk6r5r2pGtM5Vy0DKF2lllA2OJKBpTgWAdf ar/KOfUBO2RZCZTZFklds6U8MjGA/bJVKbNN5mdkWcWzqPhH7SxTPCp5FnXna5pbVy/ruCwr NZmt77Rhw98xp+nWVaqzsKwEKeXRpO5PxUWqIK/u4tWXYKp0a8xg8mkLwEZuWvOUPeI3ZVGe Xp+g3pYsk0MY8uF8WVe0qhvjnGXpqkT5QeonNcPHYVlZBGXjZAeqNcOWXjI1LhKzm0RZdijD Ys4pZweVyYLVrlhjNEWrrLzWgEXWmKrtJgw/zv1PEK23JJ5ZNkrr+eNhVHGlMTwnk23S7ivU SnWEZSsJu2W2sOws7y1fqlfBsmUPRuyYW+gSPPMnjouu72FaavSSj3sF8MscNDF+GXdWowDP yfDQB2CZh1Z0MKnuW4UwDPY1YK/SWWOyxoSArhTYcdNq96L3wuji5eKXuRqTi/cPMkSBoygA y2AZCqCABwVgmYdWPMrMiZ0osJ4CsAyWoQAKeFAAlnloxfXmupPkzIt+HTQ0LINlKHDr+bJT vevX2aH/UB1YxkhGgTOelYVlyhXlHiZA4EGBE97DBMtgmYeh62BzZNkqwLJl9dwlN89rTPvc rg0kPu5jJPa13D6IbYPGUvevxGf8pz1n93P5KxmAX3Ykvyz7WMQ5I6RltLfEmWODTbtUiUvl M6d2e9lQf97/SjTZN1tYdlSWBbvnj5OWHFrizBntsGxZ9SS3LMtCU+6Lm1VLh2VOWJZ9gnPK O/WYaal2erHyjOkYOYplI1sDShnGctMHTKdFVKyKP8UVnPJVVdq0dbNerZIlWwuVSWrDYOl7 rTRh2RozxMZ5Ot8vKw3OlDIKYfa/KrJy8ZQjZkejhULLFVtoLFdBzTIuGzMbTTGxzrJSuba4 imLWb00V296rLfllvp0yedSPpwf+iHM9p0Zdn8nIUib1sJTbUqGYcrWyPov13WxZqX+UOjWD GVY8oBQxMZpCasXJsiJk/cqKs1nKIatn1toKDbeZ261fBsu2UX7BUs7IsopbVGFKiXSj/DJL hAo4SpHFEutnlVyerCNZ9w0rvuegf5d17hp9uk78Mvcgwy+zDD2MX1aClHITKv7XKJbVI9c5 Uncnbc5ZuAz6Ze0ss26XynzCGrNUOixbdb8/zZw1psJZ7yyLay5lt1qLKTdEOT4lRyN1jmKc +moujaZ8q5Kp0ZiKI6aIXHfZbGTLJrVezhK/YphVI2tSWuXUhu2JptaY+GULLv02y8rzGnOU iNuPnywiR9lM5KUU4Nz/UkrumA8s4/2Y3JXFveUe+gAs89CKO06GPorGL3PQjrAMlqEAfpmH PgDLPLSig0l13yqc8/2Yc06W7tte2dJhGSxDgcsJ+HN+OkTSZJNgGSMZBVDAgwKwzEMrTp7K SIgCbhSAZbAMBVDAgwKwzEMruplaqQgKTFYAlsEyFEABDwrAMg+tOHkqIyEKuFEAlsEyFEAB Dwr4ZFmo1eDH2UFBN7MrFUGBaQq4ZdmV6ieIBcum9RhSoUCfCnhmWeUkd4ll9rlmpWbb9xlB jZ2pNyNLD0prrM6EaCUFVrKk8hzNQePtA+ys8dlnz9UvDpbrJsLpWCaP2auwLDZtHQT1QTKz fyzFoKXymVkdlXxLq1ZtJivLZJalCe1zK0t9sl7cljov20Om5XYulsnU18iyIGilN6w6SJbq hUvlM61v9eDSrtpMK7EsJZdi3Ch49dn6y/alNDfnLBNyySf68NNYppYA1rEXWSVa+j3bpSq5 1TOJ+Uu2aXHxv6WJvTT52wGjqmAdq1I1W+yxgmTVqGdlK5saGTOsNFOcqyqyZHVQ1qaWWNbU G7q+CMgqoKrZ/t/1INJJzv5ZJjhLQTaBZba7R5So7pjliO3i9VSVTEqjK7uOm1xudpxHQA9W OUurUp5ZbZUCJf2tScqbrjfTYCNam5eyZBDoqmhrqqqpQqrNvxPirGfGKVimQDaNZWqqj30r e73esdIkdTbZmHVWlowpYciO/HoO2XpZk1Slon8xOCBb4BLrokzN+jj1ZioRsy57RaKxk0d2 YGetGpTOom09avSZs3OWWY9M1puhMbJnMkp9MTuLZntPljVZp8lerEDBDtQWB2FwaCnGlaqZ mlqJU0JD1sWoo6fk+mVTVeTNIqDkbVXaruWnrKNUqoiVsdLEpdIr7dsnbla1yj/LBGfqfEYL yyws0pE/6EGUkltXKL2isq0Aaw7LxLOolGtHewt6tmFZSfkWCytUbWnuetu1sEzi1OeMypRW h1eFj6tCpJPMT8Eye9CswjLpatnell5PO5yKX/kpHW+l3KyvVI+pkJTaX6qFTTJomHLNxhqf Aqhd22zVSqZmLSy1RQsQs3WMMFLsy3abeLEEyoqqlox1Vmbjd0KZbcxwy7JB+Tj3PygREdZQ 4OTe0xqSSp4+Wdb47Pb1ZCVnFLAKZP19hFpKAZ8sW0od8kEBFDiKArDMw9NOjtLbsBMF1lMA lsEyFEABDwrAMg+tuN5cR84ocBQFYBksQwEU8KCAT5YNPlR2ZrWPMlNhJwqcR4GZgzokD89v zcolP10Ol5dOco094dVuq5Rd+VSsOk/bU1MU8KRAOx8qwOqUZROeKys1yd4pMvmIY3r4e3Im Y/tctgppJhVL7Jl40SR7tN0aNljHwQhjK0t8FAgKnI5lYSBV7i1fiWWNEFmwR85hWUWE7E/K 7BKqQNiC7UtWVoFzsUw8izrLSnfqTR6Kg1hZo1/aQu39g/Vy62YPunUT/LU1dCDP8yjgnGVC rvbnysYFpr0ZOF5RS630+qBHky5gbT6qiNgLsyXKxXoc9Wv9v6oi7SyrCJIaGb/XlVT1Os9Q pKYzFfDPMsFZHG/tzy/Lju0640osi6Vb8Fl6VpgiPylAZJd4WRLF5ClS7fo3jZbiL7tSLgky KFQ2QlafmV2c5CdR4BQsUyBrfBbjKJZVMKGwEnmnAGfHtiWjpYz1cSokKhmZtSRLQ4u2NK3K v1TBUi1KCpxkKFLNmQo4Z9mE58qWfKj6CJzAsqw/lYWFulhxebJrZLWwVYhscaysH1dxoLIw tTa01GJm5yb5qRTwz7L258paB8oSKus71B2Kkl9WIlTWH0wB1EKBkldlGTSBZXUXctDtGoxQ WgKfamRS2bEKnIJljc+VbWFZ3K6qj+fs1pJ1xMQHzK4lVf6VmHbRWnGjrN+X1qjuXUaPtbEi Nr6imIpQnxLG9mzin00BtywbbMixdx0MZkgEFECBHRXwyTKeK7tjl6JoFNhFAZ8s20VKCkUB FNhRAVjm4WknO3YgikaBThSAZbAMBVDAgwKwzEMrdjIxYgYK7KgALINlKIACHhSAZR5accfJ kKJRoBMFYBksQwEU8KAALPPQip1MjJiBAjsqcDCWtbyUhDgogALnVGDOzTybvruk8TQ/0VAA BU6rwGTHcFOWTbaShCiAAihQVwCWsd2GAijgQQFY5qEVmbFRAAVgGSxDARTwoAAs89CKzMko gAKwDJahAAp4UACWeWhF5mQUQAFYBstQAAU8KADLPLQiczIKoAAsg2UogAIeFIBlHlqRORkF UACWwTIUQAEPCsAyD63InIwCKADLYBkKoIAHBWCZh1ZkTkYBFIBlsAwFUMCDArDMQysyJ6MA CsAyWIYCKOBBgbksO+dTyak1CqBAhwpcuXIl658K5q4Kv5VeKBB+5oMCKIAC/SgwkWUs0VEA BVCgfwWG/bL+64CFKIACKADLPGyI0o9RAAVgGSxDARTwoAAs89CKzMkogAKwDJahAAp4UODU LLvK+8fO1eHkjeNP9uSR4/qGqlHl2MnPzjKvHf1yaPCqy7FBFUqnCB2sUEonwqmyg8ZVwOJ8 mR7YYbS77Oi3TlCw7BaUu2xiGczgO4UaftlfeZq10i6OXyZqwDJPPXzW/ZiehFB1wS/z1Lg4 KbE1T4jv6KXW7sf01N1h2Ql7OVX2NITxy/J/cl7bL0v/TBr7U7r0yy4D5/e8tffLsvWab3bI YY4gm/lloaCxlZ2QpKWIzaqs2qXSTHNacE6V8ctW3PsvNX+8vl6rr8qy9m7d0jWtpzwh1cYb 4UHesb7ehCQtOsAy9v5vddNW9cvqLFsPZB+boNb5O+aqls/JfJuBLR7WWD8LlrWguSUOa8wd 1pgVls0Zse3tvdLfMUvGx4WnWCjR5GK6vq5fmaPMZiwLTlnKpvRphdFDjBfjFUkV/9vSjoNx tqmyXftX2jRtd9XWg9VpiQDLYNmtCoxdHNnuNYgbS7F4RW0aqiHR/36ZwEg0TMEUT1xHry17 JRJwKTdtS5bFuSolVKkF7fUWTrXEgWV9sWzmoB1s8i33y6zP1UKu6LulI2SmLBsMbOWORajF GUIi2Gjq+hFZlva6iCoLuFLrD3baxgiwrDuWzRy39YbfnmV1D8v273Qdmh0kjT07jbYNy9IV JSyzTjos2+c2/aD7/DVXadSpZk6nMrXUmjBu+2FZixc2Lc5YWdZmWVxgZtePcSOs4pfJyjRd qI6to4q/dpVLHbXSmWGZQ5aJ5xU/g91iZre2Hkp2Y2sRdpfqlVY2u2OSVaO0/zJWkLUHtl0Y xpVjutMvLLNXUidukVYQMpaekzFWvXr80sScdvLU1872kEVMYo25wxpzkZablsmqa8xpJm2Q aoOBbRkUvbDorAli0uevSN3tgnS+JhtUeZqR2Xl0WlaNrmgkO/cw7eMYLtK6NhNYlmqyoBOU OlxxtVjy1+wgXHB1GZe02/hlYzsqLNsaKKvul41t/gXjw7I1WCa+lf1En2uwUEm7eEPbDJct ZUGD52fFGpM15mLny+Z3x5Vy6HbBtVJ946oKlqVeKmvMrV3C9fr3xzYO1rmHaVXL52QOy6J6 +GVLer9zOuVmaWWNaTdBHFzhGdlnHtiw7IwsC2Pe66d0JsMBqUtVKG2EU2VPCmRbmb9jqnsw vP3XerhewR3rRZWDAids5bOzbLPFLAWhAAqsrcCtf77P/l157bLJHwVQAAWWUgCWufoL5lLd gnxQ4HAKwDJYhgIo4EEBWOahFQ83hWIwCiyuACyDZSiAAh4UgGUeWnHxKY4MUeBwCsAyWIYC KOBBgY+xzNPJYOqCAihwQgUut+65PyhMBVEABc6gwOUWaz4ogAIocHQF/h+JPwi13BrJlAAA AABJRU5ErkJggg== --------------000804030901030308080905-- From superuser@gmail.com Sat Aug 18 20:53: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 0A97D21F8491 for ; Sat, 18 Aug 2012 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39Uf+bo3JeTH for ; Sat, 18 Aug 2012 20:53:29 -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 4805421F848F for ; Sat, 18 Aug 2012 20:53:29 -0700 (PDT) Received: by lahm15 with SMTP id m15so2877329lah.31 for ; Sat, 18 Aug 2012 20:53:28 -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=tfbwIC4U2QC5oi0rLT9iD/YM05KUn4YNqxetD5AVsvo=; b=a6ZFa7Q0XVf62moYZXHvfzteirH4XLCUo9udGE68NXo8B3JvKTQbI9BTWF5vJ3GbZe AQ5ttohlwiNwVIjN+6Ua1Z4ZVthUny3Pua/l9B8gL5TTgp2MFf578HTctbJQcGo3FzKg 1JK6MCCs6WHCOFg6On1Rx1NhzhPAxxTygWJEM/cEX/icRCy38bQU2uHKBSOTtcdvIoyd Hu+sDtgCs3q/W7GXYzgsw0/lC4kqvJSzI5pPfcagcg/It9GzvAskwuL/5nQbVFT65dDv OhGImAdbtM0Cp56M0GPWZbEOPxxHW60L7oDaFXdJC/6chWR7cKeoGh3a41tWce89atZA 0kzQ== MIME-Version: 1.0 Received: by 10.112.83.229 with SMTP id t5mr4360183lby.8.1345348408213; Sat, 18 Aug 2012 20:53:28 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 18 Aug 2012 20:53:27 -0700 (PDT) In-Reply-To: <2137477.zzX3vIWz46@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <5003497.dxG3XNAxyi@scott-latitude-e6320> <6.2.5.6.2.20120818111205.09e404f8@resistor.net> <2137477.zzX3vIWz46@scott-latitude-e6320> Date: Sat, 18 Aug 2012 20:53:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 03:53:30 -0000 I believe we are compelled by the IESG statement to change it. And even without that, I would push to change it anyway. As the IESG Note on RFC4408 points out, it was published as-is for all the reasons that applied at the time. It never underwent official IETF review of any kind, and the climate surrounding this work probably means that even if this IESG statement had come out by then (note that it came out some years later), it would've sidestepped any such checking. And as I would guess Andrew will happily attest, few people hold up RFC103[45] as high examples of quality writing. And our (ahem) standards are a lot higher since then. We are going to have bigger battles to fight when this document gets to IESG evaluation. Let's not burn much energy on this one. -MSK From agthisell@yahoo.com Sat Aug 18 20:58: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 2327821F844A for ; Sat, 18 Aug 2012 20:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAhOoeRSelLs for ; Sat, 18 Aug 2012 20:57:59 -0700 (PDT) Received: from nm6-vm1.bullet.mail.ne1.yahoo.com (nm6-vm1.bullet.mail.ne1.yahoo.com [98.138.91.71]) by ietfa.amsl.com (Postfix) with SMTP id 90D5E21F8447 for ; Sat, 18 Aug 2012 20:57:59 -0700 (PDT) Received: from [98.138.90.50] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 03:57:54 -0000 Received: from [98.138.89.168] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 03:57:54 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 19 Aug 2012 03:57:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 186643.93347.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 9489 invoked by uid 60001); 19 Aug 2012 03:57:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345348674; bh=BmWyTqkUdolGI9w44T4IIEgNCvh1CxkcTBhjO/DYWZM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=RsCobLXfmEFkK25m80pAJvjIoe99mrseQPFIfXuNqwPdzaMAdW9P452L58IkrKOPvMDV39+ISKn13JbgbiVgTZmC8sXuoT37u6jMhMZoOfkphIhoiONZ87T7ldeKhZSMj1hxmS9FMwF3pQM8yxpdzH5aJbJnYefOEwom67jAItU= 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=dD9xnT8AciYyrY3XTcaj4v7UbQX9HgfONihw72gWsQniJpZXTCEDrR8y5247LcsekoyhKOnVuw4IDTEfvamEUebLK0PyNF1J2LZWKYnRISV7vHQuW3rk06i9/GrfyPgP8NQry2tL2R0SLyd1oa6152lBbwpg6zMtm6UsOuGE/Uw=; X-YMail-OSG: xXrU9fMVM1lywIX58rUolkqOA_IJhCgc_iqhq6Wew_Rh9Lg eoDGPopnEVSS7eOTCc0tziiqjrT8RI8T48qkSfzEU3mNUpoW_dwlDeg4R24J zAOKBLk_.OVnLhwKi4zdpEgXbeLShQWAvCyTzwsyKgvE9tly9UutyGLzquVF 7JD0nD10FXwWquFO66ygKikWqgxQ3oNifQ2zNqrBhgqXwTNlil7X6jx15LM0 6nPAYfAfKnDb_gxVya_GHPIcyH_BNBa9Xsf4v4HfnmtASKoEIB9sqLtx.FmJ 9L2vL_iFwjaee1edlchYpa3eTZRzbB3ceYxr5qT29ecY8gJCt0NKzyIS_KXP A7zMkN.0XFNXrAqQrWuDCNS76b5_yJwkZLlMYJK41z_uDyfBzj4tHKQ.iIqi Re3_4vzSOOrJ6njxKzguT0JHyj8xxyQKS.G2QQh0oOhMOtyS.9DzfVV9YLYH _YA4IwUoEfiDNWpzcE9M- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Sat, 18 Aug 2012 20:57:53 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1345348673.86790.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Sat, 18 Aug 2012 20:57:53 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-05.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, 19 Aug 2012 03:58:00 -0000 Minor nit: The "all" mechanism should have a process limit of either 11 or unlimited. Process limits are the sum across all SPF records, including included ones. So there can be 11 records, each of which can have an all mechanism. Actually, I think the SPF grammar allows multiple all mechanism, and doesn't force the all mechanism to be the last mechanism. *shrug* It is a pretty minor nit to begin with. From spf2@kitterman.com Sat Aug 18 21:20: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 01C1321F84CE for ; Sat, 18 Aug 2012 21:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIAokQmPUyHV for ; Sat, 18 Aug 2012 21:20:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6E721F84C2 for ; Sat, 18 Aug 2012 21:20:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EB5FF20E40EA; Sun, 19 Aug 2012 00:20:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345350042; bh=KHRw893kuZ22EG9N/wM9Lgk2txnBnnddu8jTG7UodRQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GNDsNSBAJu35EH++vSlqoKOb534GVmA8DatUFsLWqX9MHgowRo3Uzsfiq7fxgsDKr KkQI1XcV1Bxpv9YMwyBxY9UraP5WkfK+a4kmjX6YpUMoLcYWYG1Qm9bdcowgbleQMx 2f9BjAmwYwbXnUfJY1cwFk9rlbzEHOGCfmvYYcUQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C26C320E40A6; Sun, 19 Aug 2012 00:20:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 00:20:40 -0400 Message-ID: <2225739.fMcSdBkSbi@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1345348673.86790.YahooMailClassic@web125401.mail.ne1.yahoo.com> References: <1345348673.86790.YahooMailClassic@web125401.mail.ne1.yahoo.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-05.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, 19 Aug 2012 04:20:45 -0000 On Saturday, August 18, 2012 08:57:53 PM Arthur Thisell wrote: > Minor nit: > > The "all" mechanism should have a process limit of either 11 or unlimited. > Process limits are the sum across all SPF records, including included ones. > So there can be 11 records, each of which can have an all mechanism. > Actually, I think the SPF grammar allows multiple all mechanism, and > doesn't force the all mechanism to be the last mechanism. > > *shrug* > > It is a pretty minor nit to begin with. Good point though. I had "-" instead of 1 at first and then changed it. I'll put it back. Scott K From superuser@gmail.com Sat Aug 18 21:34: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 3054C21F84DD for ; Sat, 18 Aug 2012 21:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geaeOnIqdI2q for ; Sat, 18 Aug 2012 21:34:48 -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 30A2421F84D8 for ; Sat, 18 Aug 2012 21:34:47 -0700 (PDT) Received: by lahm15 with SMTP id m15so2884395lah.31 for ; Sat, 18 Aug 2012 21:34:47 -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=Aae4JCN7gMpw6fC6tvmHqGsSyrwEf8+t0cFsTxxHMv4=; b=PHlOuKaV7UPwydUmh//2UNRHuqFpIsI/yA+QTEIhQ8+R47r/KE9b7bu8ceDoHKm1w0 6v3a4+dFRoQOBDfGi5hgcHe9WStPxT9+Kw84u3zAfO3xuWltZ9swhEWsHZEhkRWvIkC7 Dz1wSXZhH1Gcr85CkQuWmf4cfPeInPFVdwLqpiS3DqGKpvWhY1GXtsO5krQUVYJQQj/N 77mAPFUPbihNeL2UCED84DdhBw2Lwh4DiNYZcIJuP0lD2t4FyNAMPnpd+mVdwEvBEYf2 G8rTU8u1kWXCzqxAVzXw3zBhVIfTFBOZQZbzFtBXwPMcvpCnT9fNyDMWsT7WumKRj6hm QduQ== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr9665100lab.36.1345350887020; Sat, 18 Aug 2012 21:34:47 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 18 Aug 2012 21:34:46 -0700 (PDT) In-Reply-To: <2569465.PHZWXk9PS2@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <50300F0E.1080409@isdg.net> <2569465.PHZWXk9PS2@scott-latitude-e6320> Date: Sat, 18 Aug 2012 21:34:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 04:34:49 -0000 On Sat, Aug 18, 2012 at 6:59 PM, Scott Kitterman wrote: >> Per issue 29 and section 2.5.4 and the links I provided in a previous >> post for additional info, overall, IMO, we need to define what >> "marking" the SPF hard failed message means and how this deployment >> alternative can expose a security level difference compared the >> RFC2119 compliance option of REJECT. > > I went back over your previous posts and I think that what we have in section > 9 does this. Please review -05 and provide updated text based on that if you > don't feel it does. +1. There's no need to embellish what we're saying about handling of "Fail" any more than what's there. (Note a typo in the changed text in 2.5.4: "is" should be "it".) >> We need to note that implementators SHOULD offer both options to >> deployments (operators, admins, etc). I think we should state what is >> the MINIMUM requirement for SPF compliance, and one can argue since >> REJECT is the only RFC2119 level language, it should be the minimum >> offering. The alternative is MARKING and I believe, we only need to >> describe the responsibility regarding mail separation at this point. >> >> I personally believe even adding a section or paragraph regarding >> System Level vs User Level Filtering is warranted as a nice way to >> introduce and/or reference the SMTP level REJECT vs mail acceptance >> MARKing and the recommended mail stream separation design/deployment >> guideline. > > I don't see how to put this in a protocol document. As I mentioned in a > previous mail, system/user level designs can both do reject or 'marking' so it > seems orthogonal to this discussion. "REJECT" isn't an RFC2119 word last I checked, so I don't even understand this claim. There is no normative requirement to reject or even mark a message, and there shouldn't be. The operator gets to decide what to do with a "fail" result and in the aggregate there are good reasons to do either. This isn't a new notion. System vs. user level filtering and stream separation constitute applicability statements in my view, and are not part of the base protocol. Finally, please, let's not get into the mess of minimum compliance statements. -MSK From spf2@kitterman.com Sat Aug 18 21:37: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 DD3D921F844F for ; Sat, 18 Aug 2012 21:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18pks6-+y1+y for ; Sat, 18 Aug 2012 21:37:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B121F8448 for ; Sat, 18 Aug 2012 21:37:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4D37C20E40EA; Sun, 19 Aug 2012 00:37:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345351058; bh=k28TCNJChTBPcvI55GXZ4tUrgvka/qEYzdbGpibHT4A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n/pSUbItiMj0gq5hdR+YLj1U2gp787NK9b8FRdl4IUjoTzeCq1zggQZ8YW4nfTALg 2q5h06ISNMTp8dVt/B/ncpiZjTWU7Hw98D4AjC0XxNz+CMHdK6MxmaJF5GXOXDH4gz fal4BcjcHfV6JXO1E6jt+iswHTGgX7i5p84DuMmE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 20C6520E40A6; Sun, 19 Aug 2012 00:37:37 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 00:37:37 -0400 Message-ID: <1445529.SatBtdG5jD@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120817034603.20684.qmail@joyce.lan> <2137477.zzX3vIWz46@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 04:37:42 -0000 On Saturday, August 18, 2012 08:53:27 PM Murray S. Kucherawy wrote: > I believe we are compelled by the IESG statement to change it. And > even without that, I would push to change it anyway. > > As the IESG Note on RFC4408 points out, it was published as-is for all > the reasons that applied at the time. It never underwent official > IETF review of any kind, and the climate surrounding this work > probably means that even if this IESG statement had come out by then > (note that it came out some years later), it would've sidestepped any > such checking. That's not consistent with the record. If you go back and look at http://datatracker.ietf.org/doc/rfc4408/history/ you'll find that the IESG did not just rubber stamp draft-schlitt-spf-classic. Some significant changes were made between the initial submission and the final approval. While your statement that "It never underwent official IETF review of any kind" is literally true it was reviewed on the namedroppers, ietf-smtp, and ietf-822 lists in addition to the IESG review. > And as I would guess Andrew will happily attest, few people hold up > RFC103[45] as high examples of quality writing. And our (ahem) > standards are a lot higher since then. It's not about them being well written, but that since the example is already there, there's no harm in reusing it. > We are going to have bigger battles to fight when this document gets > to IESG evaluation. Let's not burn much energy on this one. Perhaps. Is the IESG generally requiring examples to be rewritten in $bis documents? Scott K From spf2@kitterman.com Sat Aug 18 21:39: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 4BDEE21F84E1 for ; Sat, 18 Aug 2012 21:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zib+7k0p1ibr for ; Sat, 18 Aug 2012 21:39:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 930A321F84DF for ; Sat, 18 Aug 2012 21:39:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 139CF20E40EA; Sun, 19 Aug 2012 00:39:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345351192; bh=ppj/AiuVvyrRESwLDbKzUlgXbH0/ArdKBE4NMtiurqA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=euJVuiD/N5l0GUNksYyHXN0NHTDRwdD/sNRkIn9bc3MVWvJz8p5s/qaVlE9hZGQIl UOW5M1q++yVnQe6XNz5pdVLsg7aW82Cb7FvRT08FAvjqctauaEMeaHOHktZsiMPtpv XNHK0g1ccQWRW82ER1C9D2nD90DyFvnCxGIxIQzk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DBD5620E40A6; Sun, 19 Aug 2012 00:39:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 00:39:51 -0400 Message-ID: <2178963.CY81ZKX585@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2569465.PHZWXk9PS2@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 04:39:53 -0000 On Saturday, August 18, 2012 09:34:46 PM Murray S. Kucherawy wrote: > On Sat, Aug 18, 2012 at 6:59 PM, Scott Kitterman wrote: > >> Per issue 29 and section 2.5.4 and the links I provided in a previous > >> post for additional info, overall, IMO, we need to define what > >> "marking" the SPF hard failed message means and how this deployment > >> alternative can expose a security level difference compared the > >> RFC2119 compliance option of REJECT. > > > > I went back over your previous posts and I think that what we have in > > section 9 does this. Please review -05 and provide updated text based on > > that if you don't feel it does. > > +1. There's no need to embellish what we're saying about handling of > "Fail" any more than what's there. > > (Note a typo in the changed text in 2.5.4: "is" should be "it".) Fixed. Thanks. > >> We need to note that implementators SHOULD offer both options to > >> deployments (operators, admins, etc). I think we should state what is > >> the MINIMUM requirement for SPF compliance, and one can argue since > >> REJECT is the only RFC2119 level language, it should be the minimum > >> offering. The alternative is MARKING and I believe, we only need to > >> describe the responsibility regarding mail separation at this point. > >> > >> I personally believe even adding a section or paragraph regarding > >> System Level vs User Level Filtering is warranted as a nice way to > >> introduce and/or reference the SMTP level REJECT vs mail acceptance > >> MARKing and the recommended mail stream separation design/deployment > >> guideline. > > > > I don't see how to put this in a protocol document. As I mentioned in a > > previous mail, system/user level designs can both do reject or 'marking' > > so it seems orthogonal to this discussion. > > "REJECT" isn't an RFC2119 word last I checked, so I don't even > understand this claim. There is no normative requirement to reject or > even mark a message, and there shouldn't be. The operator gets to > decide what to do with a "fail" result and in the aggregate there are > good reasons to do either. This isn't a new notion. > > System vs. user level filtering and stream separation constitute > applicability statements in my view, and are not part of the base > protocol. > > Finally, please, let's not get into the mess of minimum compliance > statements. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Sat Aug 18 22:20: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 0328421F84C8 for ; Sat, 18 Aug 2012 22:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWAQoP7gyNHl for ; Sat, 18 Aug 2012 22:20:48 -0700 (PDT) Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EFFA221F84A7 for ; Sat, 18 Aug 2012 22:20:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5142; t=1345353640; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=G7RUiwbF+5/G4CWqcgGyTejt1z8=; b=IBS6AW2Bd4MvqG2Rga5f f58V5PhQtijOFt6t9kQ/rmKuzqxVbk4tOTVEfr/LnI58HULL6mIbM2xBPRLZF3bB 7tHkVeQgBERHlev2ftLMOe5XxQ57jOzC4DzOilfYojNbI7vYSYLj4BxOLTtWkocc lFPwHRPKvti1zws+iJHh6LU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 19 Aug 2012 01:20:40 -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 1375441730.24601.3556; Sun, 19 Aug 2012 01:20:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5142; t=1345353453; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UotnGpi TEq1C4DXKsLpVseQy69uxZoY/JEdcVds+q7A=; b=ly+f6n+yZCJPoFQ0X/C/275 9AA3V6ho6ZvDO75kp9Ck/sqfDnZ9YYgyOPJ+5wYm+i23Fk8ohqYvhAUIMgUsYqNB faUEDIYTQ+8uMoDw+AXOG9uUGuLJrM7RY8g+H4H+rwf0Hv1NuVpvaz6kXSQpZ60u PTr5CEavCBo9Rgc8Am0Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 19 Aug 2012 01:17: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 1974251411.7.4556; Sun, 19 Aug 2012 01:17:32 -0400 Message-ID: <503077C0.70405@isdg.net> Date: Sun, 19 Aug 2012 01:21: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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <50300F0E.1080409@isdg.net> <2569465.PHZWXk9PS2@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 05:20:49 -0000 Scott, (first, in 2.5.4. I don't agree with it, but it should reference 9.3.2, not 9.3) I disagree with the weakening of the SPF "Hard Fail" protocol crafted into section 2.5.4. The previous text was MORE clear. The only issue is defining Marking. No Receiver can claim SPF compliance when it comes to section 2.5.4 and dealing with hard fails if it does not honor the publisher policy with either a dynamic SMTP level permanent 55x reject or a undefined "marking" of the messages. Short of being non-SPF compliant, there are no other choices here, Its that simple. This is not about reputation modeling, DKIM or DMARC, reporting or whatever, this is a straight forward nine year old deterministic protocol which for some here was very hard to swallow, but nonetheless, very much highly successful in the market place with a very clear understanding and fast entry point unlike anything else the past 30 years. The issue here is defining what the alternative MARKING means and in my opinion section 9.3.2 is too vague on the subject. Its not clear. Section 2.5.4 is where the PROTOCOL options are introduced for rejection and marking and that is where it should be clear with the functionality is expected. We don't need more mumbo jumbo, redundant, obvious "its local policy" claims, that only adds more confusion. of course, its local policy what a system will do with SPF. But as far as the protocol is concern, its very clear: o Implementations (coders) MUST offer two options: - SMTP level permanent rejection - SMTP level acception with SPF hardfail marking o Deployment MAY choose rejection or marking. I am stating which is all that is being proposed added to 2.5.4 is that the MARKING functionality is an Security Loophole IFF you don't talk about stream separation. More review into: 9.3.1. Policy For SPF Pass We don't need a SPF if the client is already part of a white list. Who does what is described in this section? Is this is a SPF specific WHITE LIST? We keep getting lost with a GOOD MODELING concept when SPF is about detecting SPOOFS for pete sake. I can see advance parsing of the policy to look at the final yield, -ALL, ~ALL, ?ALL, etc and try to create some magic source formula, neural network, fuzzy or what have you for a PASS: > 1.0 for a PASS ending with a -ALL > 0.5 for a PASS ending with a ~ALL = 0.0 for a PASS ending with a ?ALL Or some stuff like this, but a pass is not going to be usually against a white list. in fact, I suggest, SPF will be SKIPPED - like on our system if the sender is already white listed. -- HLS Murray S. Kucherawy wrote: > On Sat, Aug 18, 2012 at 6:59 PM, Scott Kitterman wrote: >>> Per issue 29 and section 2.5.4 and the links I provided in a previous >>> post for additional info, overall, IMO, we need to define what >>> "marking" the SPF hard failed message means and how this deployment >>> alternative can expose a security level difference compared the >>> RFC2119 compliance option of REJECT. >> I went back over your previous posts and I think that what we have in section >> 9 does this. Please review -05 and provide updated text based on that if you >> don't feel it does. > > +1. There's no need to embellish what we're saying about handling of > "Fail" any more than what's there. > > (Note a typo in the changed text in 2.5.4: "is" should be "it".) > >>> We need to note that implementators SHOULD offer both options to >>> deployments (operators, admins, etc). I think we should state what is >>> the MINIMUM requirement for SPF compliance, and one can argue since >>> REJECT is the only RFC2119 level language, it should be the minimum >>> offering. The alternative is MARKING and I believe, we only need to >>> describe the responsibility regarding mail separation at this point. >>> >>> I personally believe even adding a section or paragraph regarding >>> System Level vs User Level Filtering is warranted as a nice way to >>> introduce and/or reference the SMTP level REJECT vs mail acceptance >>> MARKing and the recommended mail stream separation design/deployment >>> guideline. >> I don't see how to put this in a protocol document. As I mentioned in a >> previous mail, system/user level designs can both do reject or 'marking' so it >> seems orthogonal to this discussion. > > "REJECT" isn't an RFC2119 word last I checked, so I don't even > understand this claim. There is no normative requirement to reject or > even mark a message, and there shouldn't be. The operator gets to > decide what to do with a "fail" result and in the aggregate there are > good reasons to do either. This isn't a new notion. > > System vs. user level filtering and stream separation constitute > applicability statements in my view, and are not part of the base > protocol. > > Finally, please, let's not get into the mess of minimum compliance statements. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Sat Aug 18 22:49: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 1F36421F845B for ; Sat, 18 Aug 2012 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yXBDq8AIZDp for ; Sat, 18 Aug 2012 22:49:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 512EB21F845A for ; Sat, 18 Aug 2012 22:49:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9C52120E40EA; Sun, 19 Aug 2012 01:49:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345355391; bh=qIA+PtAu1bcMMsdjupx4kkTBIs29Jtva63yZ5UkG0k0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SfSRIesISY5j45TgvDKbqxx8H/UrmgDxxgW0zV6j41Bb3B/xCCzDaO8O3ONDEjU1w cPRs7p2zLRIHReHpUbowTbEVG4vg/g1RY/KVWEIQbXIrTLkoW5bc309qOxlde1OERc NSe+zsJxBIgeWOj17BvY5BQ6BDq1ZKZ1niFhaoeQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6F4D420E40A6; Sun, 19 Aug 2012 01:49:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 01:49:50 -0400 Message-ID: <7733947.LvW5INK1oG@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503077C0.70405@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 05:49:53 -0000 On Sunday, August 19, 2012 01:21:04 AM Hector Santos wrote: > Scott, > > (first, in 2.5.4. I don't agree with it, but it should reference > 9.3.2, not 9.3) Fixed. > I disagree with the weakening of the SPF "Hard Fail" protocol crafted > into section 2.5.4. The previous text was MORE clear. The only > issue is defining Marking. > > No Receiver can claim SPF compliance when it comes to section 2.5.4 > and dealing with hard fails if it does not honor the publisher policy > with either a dynamic SMTP level permanent 55x reject or a undefined > "marking" of the messages. > > Short of being non-SPF compliant, there are no other choices here, Its > that simple. This is not about reputation modeling, DKIM or DMARC, > reporting or whatever, this is a straight forward nine year old > deterministic protocol which for some here was very hard to swallow, > but nonetheless, very much highly successful in the market place with > a very clear understanding and fast entry point unlike anything else > the past 30 years. > > The issue here is defining what the alternative MARKING means and in > my opinion section 9.3.2 is too vague on the subject. Its not clear. > > Section 2.5.4 is where the PROTOCOL options are introduced for > rejection and marking and that is where it should be clear with the > functionality is expected. We don't need more mumbo jumbo, redundant, > obvious "its local policy" claims, that only adds more confusion. of > course, its local policy what a system will do with SPF. But as far as > the protocol is concern, its very clear: > > o Implementations (coders) MUST offer two options: > > - SMTP level permanent rejection > - SMTP level acception with SPF hardfail marking > > o Deployment MAY choose rejection or marking. > > I am stating which is all that is being proposed added to 2.5.4 is > that the MARKING functionality is an Security Loophole IFF you don't > talk about stream separation. As far as I understand this comment, I think what you are saying is that instead of having 2.5.4 say this is a matter of local policy, see 9.3.2 (which then goes on to say something like you have to reject or mark) you want 2.5.4 to say you have to reject or mark with further discussion about marking in 9.3.2? Which section would you propose have the discussion about the advantages and disadvantages of each approach? If you think 9.3.2 is insufficient, please provide text based on what's there now. I know you've provided text before, but it's difficult for me to relate and adapt it to where we are now since I don't understand your objections to the current text. > More review into: > > 9.3.1. Policy For SPF Pass > > We don't need a SPF if the client is already part of a white list. > Who does what is described in this section? Is this is a SPF > specific WHITE LIST? It's a name based white list. It's risky to whitelist domains without some kind of authorization check first. > We keep getting lost with a GOOD MODELING concept when SPF is about > detecting SPOOFS for pete sake. It's been about both since the beginning. > I can see advance parsing of the policy to look at the final yield, > -ALL, ~ALL, ?ALL, etc and try to create some magic source formula, > > neural network, fuzzy or what have you for a PASS: > > 1.0 for a PASS ending with a -ALL > > 0.5 for a PASS ending with a ~ALL > > = 0.0 for a PASS ending with a ?ALL > > Or some stuff like this, but a pass is not going to be usually against > a white list. in fact, I suggest, SPF will be SKIPPED - like on our > system if the sender is already white listed. If the SMTP client is already whitelisted, then you're probably right. The idea is name based whitelists (and it's not a new idea). For those you need to check that you're not applying a whitelist based on a spoofed name. Scott K From sm@resistor.net Sun Aug 19 01:10: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 9251721F8498 for ; Sun, 19 Aug 2012 01:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L86pcgke1PN1 for ; Sun, 19 Aug 2012 01:10: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 230FB21F8491 for ; Sun, 19 Aug 2012 01:10:44 -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 q7J8AcW0011054 for ; Sun, 19 Aug 2012 01:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345363842; bh=HttZi3HbPNztSnxvasG7QhfWfUFKp57aQWjPRWzRu4A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=3gczWOs6DPAxgEO1Mj0MacUlUfi31AwGSgCv+K7VR/+DAJ6bjIzd6CeVwgE401ArG F2CdKlWDlDBW0ociVFzoP0EWFj8SRgEwXJOR1b8D+/U3HEBA1Oa59CP7AXIe0wRCiA mkODWhFMUg60nJz2/SV0vj2QXaCM54y5I5ci/ozE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345363842; i=@resistor.net; bh=HttZi3HbPNztSnxvasG7QhfWfUFKp57aQWjPRWzRu4A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qfWIAoitCWK/Ksilf1hvRlRFpW33KAN0A+Vy/TtBWmOmivwSvZrWwjzhW0WQr9+f+ htOIjwmr0fQOvzxu+oKFeHKFGgjnN/syM/s1u8TTb86xdjGAU/XWXVuob6wiIJyq0i PwmzOCVYze/veVd3nOEPAB9IodEc/tUpyWqS0qSQ= Message-Id: <6.2.5.6.2.20120819003212.09518f28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Aug 2012 01:10:19 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <1445529.SatBtdG5jD@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <2137477.zzX3vIWz46@scott-latitude-e6320> <1445529.SatBtdG5jD@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 08:10:47 -0000 At 21:37 18-08-2012, Scott Kitterman wrote: >Perhaps. Is the IESG generally requiring examples to be rewritten in $bis >documents? It has been pointed out during the IESG Evaluation of a specification which was advanced on the Standards Track. There were two DISCUSSes. Regards, -sm From sm@resistor.net Sun Aug 19 09:56: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 6EC7821F855D for ; Sun, 19 Aug 2012 09:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9zNvdKDKEPw for ; Sun, 19 Aug 2012 09:56:47 -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 BE26F21F855B for ; Sun, 19 Aug 2012 09:56:47 -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 q7JGuebN010701 for ; Sun, 19 Aug 2012 09:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345395406; bh=WwCnzzhRqnYgOOcH8ZIBYGgiBKUf8zj0pMhJWry+7vY=; h=Date:To:From:Subject:Cc; b=BS99pAT30LQPJ0NIGnwhUSQELbyQroTs4wdfjtoqOEHupAaZ63YhpCPAZYjDJbaAo HAzE6ziKjeHZrJBLnMwhCrYM/Uh4BBN7yodnuekdRWsCJc/oHPyZ43fwOEN5C5sYF5 VS4SQEAvYvy5aJqL4giHthxpAoOfdv9B8FxnvyUc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345395406; i=@resistor.net; bh=WwCnzzhRqnYgOOcH8ZIBYGgiBKUf8zj0pMhJWry+7vY=; h=Date:To:From:Subject:Cc; b=JoLNl44dxVlNWOA9YPAfEX8nVKYAO3XHCCapUP/8ULTGO7u7dck168585QXcxWdVz zYPXqXH1nKYtR2igDCl8qFqd3S5lbFgCDKux+nMOFEwmsYtE3/S6Lu0fmyIzYDocJt hHpJ/bNZC+YFZS1lgLgMk84jIVnH/GZDDwWsLd7k= Message-Id: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Aug 2012 09:35:59 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 16:56:48 -0000 Hello, The following text is from Section 7 of RFC 4408: 'It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. If an SMTP receiver chooses to do so, it SHOULD use the "Received-SPF" header field defined here for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.)' And the text below is from draft-ietf-spfbis-4408bis-05: 'It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. There are two methods for doing this: the Received-SPF header field defined here and the more generic Authentication-Results header field defined in [RFC5451]. Because these fields are generally used within a receiving ADMD, it is a local policy choice which to include. In general, the more broadly applicable Authentication-Results header field ought to be used, but it SHOULD be used in such a way that it conveys the same information that the verifier would have provided in a Received-SPF header field if that had been used. If an SMTP receiver chooses to do so, it SHOULD use one of these header fields for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.)' My reading of the old text is that SMTP receivers record the result of SPF processing for the recipient. The new text proposes two methods of conveying the information to the recipient. This is the kind of text which causes debates. If which header to add is a matter of local policy, the receiver also have the ability to follow the specification; RFC 5451 in this case. I suggest adding (non-normative) guidance if anyone would like to have the Authentication-Results: header. Anything more than that ends up as not picking one option and trying to satisfy everyone. I have read the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html I have also read the other messages about the topic. Regards, -sm From superuser@gmail.com Sun Aug 19 10:07: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 C429921F856D for ; Sun, 19 Aug 2012 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQtuUs-mcn15 for ; Sun, 19 Aug 2012 10:07: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 EF68221F8555 for ; Sun, 19 Aug 2012 10:07:49 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3084942lbb.31 for ; Sun, 19 Aug 2012 10:07: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=Q4Rczan9R02cqDg0ENr7xx9s9/51ANJSOdr+rFdHy9s=; b=yOPQFOzCV6Zaj3fErveN/YurXiamcFolw1flVaAxy1CiAsshRx3sIur1QeDA6VK+Gu 8083k2iAKN5ZddPQCoAQspd5VGkw7PfyDxT37CFNH/QoVsg6PUK4giIKG+UeFJRotCrC Rc6WEKuGHl4Rww90asO9imbyRwZKLZnVTssJ6axZksdiqJuZULlkBOtDjSBuGeVs1Eix Qi4ZFRPOa42JJbzxyDaUQFOyOjT1NDj3A2mFlQXNcRUK1zgWqvOMyGDGVKmkHAUsif0A Sy5T/LsAj5wCRivETTTX0Gg7atkAnvoy8hOTGzTcOqKfATO/zKC0Jde+iTSYn1BcmN7J z8Bg== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr11253909lab.10.1345396068829; Sun, 19 Aug 2012 10:07:48 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 19 Aug 2012 10:07:48 -0700 (PDT) In-Reply-To: <1445529.SatBtdG5jD@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <2137477.zzX3vIWz46@scott-latitude-e6320> <1445529.SatBtdG5jD@scott-latitude-e6320> Date: Sun, 19 Aug 2012 10:07:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 17:07:50 -0000 On Sat, Aug 18, 2012 at 9:37 PM, Scott Kitterman wrote: > That's not consistent with the record. If you go back and look at > http://datatracker.ietf.org/doc/rfc4408/history/ you'll find that the IESG did > not just rubber stamp draft-schlitt-spf-classic. Some significant changes were > made between the initial submission and the final approval. While your > statement that "It never underwent official IETF review of any kind" is > literally true it was reviewed on the namedroppers, ietf-smtp, and ietf-822 > lists in addition to the IESG review. Was this particular point discussed in those venues? >> We are going to have bigger battles to fight when this document gets >> to IESG evaluation. Let's not burn much energy on this one. > > Perhaps. Is the IESG generally requiring examples to be rewritten in $bis > documents? I believe so, yes. Regardless what's the harm in correcting the examples to be more acceptable to common document conventions? -MSK From spf2@kitterman.com Sun Aug 19 10:18: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 2D8EC21F853F for ; Sun, 19 Aug 2012 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFS5jYUB4762 for ; Sun, 19 Aug 2012 10:18:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4441921F853D for ; Sun, 19 Aug 2012 10:18:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5BDD420E411E; Sun, 19 Aug 2012 13:18:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345396736; bh=u9BJGsWllFOc6nTuPY14BsLGBkN1ckzTmPKaWQem06o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PGnAz9/F/Z5dqWAbalCh7gp3nWPUPVf5qEjBMYr7DAJ5nyQnKrwZ1oDzwva2vQaZu MWm8e92RQdIAFg85GVgnZuJqd9V2eTsij3AJ39QN9E66ji2MJdj8XH/3ak8NCzFsNv D0Si6IE8xwNUglRpTE/M+pyHM9y8Uv2d1TGWWTOM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 339DB20E411C; Sun, 19 Aug 2012 13:18:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 13:18:49 -0400 Message-ID: <7120600.Hl6UPnNzLg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> References: <6.2.5.6.2.20120819082527.0925a9d8@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] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 17:18:58 -0000 On Sunday, August 19, 2012 09:35:59 AM SM wrote: > Hello, > > The following text is from Section 7 of RFC 4408: > > 'It is RECOMMENDED that SMTP receivers record the result of SPF > processing in the message header. If an SMTP receiver chooses to do > so, it SHOULD use the "Received-SPF" header field defined here for > each identity that was checked. This information is intended for the > recipient. (Information intended for the sender is described in > Section 6.2, Explanation.)' > > And the text below is from draft-ietf-spfbis-4408bis-05: > > 'It is RECOMMENDED that SMTP receivers record the result of SPF > processing in the message header. There are two methods for doing > this: the Received-SPF header field defined here and the more generic > Authentication-Results header field defined in [RFC5451]. Because > these fields are generally used within a receiving ADMD, it is a > local policy choice which to include. In general, the more broadly > applicable Authentication-Results header field ought to be used, but > it SHOULD be used in such a way that it conveys the same information > that the verifier would have provided in a Received-SPF header field > if that had been used. > > If an SMTP receiver chooses to do so, it SHOULD use one of these > header fields for each identity that was checked. This information > is intended for the recipient. (Information intended for the sender > is described in Section 6.2, Explanation.)' > > My reading of the old text is that SMTP receivers record the result > of SPF processing for the recipient. The new text proposes two > methods of conveying the information to the recipient. This is the > kind of text which causes debates. If which header to add is a > matter of local policy, the receiver also have the ability to follow > the specification; RFC 5451 in this case. I suggest adding > (non-normative) guidance if anyone would like to have the > Authentication-Results: header. Anything more than that ends up as > not picking one option and trying to satisfy everyone. > > I have read the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html I > have also read the other messages about the topic. The suggestion in the current text about how to create an Authentication- Results header field that is a suitable replacement for Received-SPF goes beyond the minimal requirements of RFC 5451, so, in my opinion, merely using the mandatory elements of the field from RFC 5451 is not sufficient. Are you objecting to "In general, the more broadly applicable Authentication- Results header field ought to be used "? I think that giving guidance on how to use A-R in this context is important and appropriate (Use of A-R is, I believe, in scope as a widely used extension, but until now there's no standardized guidance on use as a replacement for SPF-Received). In IETF terms, I believe this is an applicability statement I think I'm not following your concern. Perhaps if you proposed specific text I would understand it better. Scott K From spf2@kitterman.com Sun Aug 19 10:27: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 A624421F8469 for ; Sun, 19 Aug 2012 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHPF06-dyH90 for ; Sun, 19 Aug 2012 10:27:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E872621F8455 for ; Sun, 19 Aug 2012 10:27:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6893720E4129; Sun, 19 Aug 2012 13:27:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345397278; bh=13AnvhOChyMaBSsYQ24eSJkrJoK0xO65L2EM7LR8FLI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nryp0iLClqft0aRPJGPsUtepX1ws1As5JlVSVnD6JAKNzy8EuNfGMQw6nPVwQMDB8 j+96/fLDn4W6tZtgo2Zsmgi8ay8mM/u7Wd7IgK09QDLmJRntX9fqMO25GvcHcb7/t/ OVeeZKEEoHm7e/CENGzGGsADYl1R4EVVnCoBvm90= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3AE9720E411C; Sun, 19 Aug 2012 13:27:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 13:27:57 -0400 Message-ID: <3213071.7NdDxgTL5r@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120817034603.20684.qmail@joyce.lan> <1445529.SatBtdG5jD@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 17:27:59 -0000 On Sunday, August 19, 2012 10:07:48 AM Murray S. Kucherawy wrote: > On Sat, Aug 18, 2012 at 9:37 PM, Scott Kitterman wrote: > > That's not consistent with the record. If you go back and look at > > http://datatracker.ietf.org/doc/rfc4408/history/ you'll find that the IESG > > did not just rubber stamp draft-schlitt-spf-classic. Some significant > > changes were made between the initial submission and the final approval. > > While your statement that "It never underwent official IETF review of any > > kind" is literally true it was reviewed on the namedroppers, ietf-smtp, > > and ietf-822 lists in addition to the IESG review. > > Was this particular point discussed in those venues? No. The point is that it was reviewed. > >> We are going to have bigger battles to fight when this document gets > >> to IESG evaluation. Let's not burn much energy on this one. > > > > Perhaps. Is the IESG generally requiring examples to be rewritten in $bis > > documents? > > I believe so, yes. > > Regardless what's the harm in correcting the examples to be more > acceptable to common document conventions? I think it's very odd for the text to say "For example, the example given in [RFC1034], Section 4.3.3, could be extended with the following:" and then not extend it, but completely rewrite it. It totally loses the point of taking a standard example and showing how it changes. So it's potentially confusing. I'm against making things more confusing for the sake of ... Well I'm not sure what it would be for the sake of. There is no way this creates any harm, which is what the IESG note was about. I guess it must be for the sake of applying a tangentially related rule to the text in advance of IESG review to avoid potential negative feedback. That's what I've come up with as a reason and I don't think it makes sense. I'm reasonably certain I'm in the rough part of the consensus, so if someone sends me a patch I'll apply it (I uploaded the XML with -05) because I'm about 98% sure that whatever text I wrote would need revision due to excessive snarkyness anyway. Scott K From sm@resistor.net Sun Aug 19 10:42: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 EF48221F845F for ; Sun, 19 Aug 2012 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsaU3zntiurD for ; Sun, 19 Aug 2012 10:42:52 -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 F287221F8456 for ; Sun, 19 Aug 2012 10:42:51 -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 q7JHgiJ9028656; Sun, 19 Aug 2012 10:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345398170; bh=CA4dBFKSK3sLrFY9q0JdOxtztW0Y2N+9Yxacf90Cg7U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HCKEKm9CizzoN+sQTj2vL6jqvArM6mvGJwEDyBU/XjFrRFAM4U0kg7UjeIGR46K5a me6sUY+NdTlrDIsCFbj6R/XfD6616i666sd36Jf8KCjNm688VMibvV0tBWBlHIJ0n4 n1EPpZCNf9Wvz6dmIMXqwSQMeBtRmY+o8jYoKPWI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345398170; i=@resistor.net; bh=CA4dBFKSK3sLrFY9q0JdOxtztW0Y2N+9Yxacf90Cg7U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yiiDVBvZ8EGRlgF7/92XK7x6LaFDqpx6AiebnBbEeUiQl+LuCjPQwxQZc/WaYnDi5 CyaiIzO2hDxNoa9XXQBwnwd5jPUiQMFQDe/IsJ+g3n1ivbs3qta6uO7Gd19AeMFlUE evcfGF8n0Eq/mtsYE9ytY+Gg52oIqrBDiRv1n3d8= Message-Id: <6.2.5.6.2.20120819102249.09296c58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Aug 2012 10:38:17 -0700 To: Scott Kitterman From: SM In-Reply-To: <7120600.Hl6UPnNzLg@scott-latitude-e6320> References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> <7120600.Hl6UPnNzLg@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 17:42:53 -0000 Hi Scott, At 10:18 19-08-2012, Scott Kitterman wrote: >Are you objecting to "In general, the more broadly applicable Authentication- >Results header field ought to be used "? My comment, which is not an objection, is about picking one option. The consequences of having two options is documented in RFC 6686. >I think that giving guidance on how to use A-R in this context is important >and appropriate (Use of A-R is, I believe, in scope as a widely used >extension, but until now there's no standardized guidance on use as a >replacement for SPF-Received). In IETF terms, I believe this is an >applicability statement I am ok with providing guidance. Having a SHOULD is not guidance. It is a recommendation (see RFC 2119). I don't see how 4408bis can be an applicability statement about RFC 5451. Regards, -sm From spf2@kitterman.com Sun Aug 19 10: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 9367021F84A5 for ; Sun, 19 Aug 2012 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mGMPI+qDb+P for ; Sun, 19 Aug 2012 10:52:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E1D5121F849B for ; Sun, 19 Aug 2012 10:52:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5FBDF20E411E; Sun, 19 Aug 2012 13:52:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345398729; bh=NWfzXIgzh6khhtSTl5390Azk5o7COxTOFrF79gZH/uU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Kq5YBsVaV2k6Tc5ZU7DexN58fjInRRY/3FGzfYJ8b6QLvpomSW7dI0kgZw0JkLaSb LEESf/cAK4YbEcUVUxMWJo12BdGnmxItXQhs9tIHvYp0hs3/Kpx7U7DhPqBhtvevhq AeL3kTzx1YJrO2B9fg14SgtwDtLI4/p7ZGmIuF7Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3816E20E411C; Sun, 19 Aug 2012 13:52:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 13:52:08 -0400 Message-ID: <28627603.NIrZbkTSgU@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120819102249.09296c58@resistor.net> References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> <7120600.Hl6UPnNzLg@scott-latitude-e6320> <6.2.5.6.2.20120819102249.09296c58@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 17:52:10 -0000 On Sunday, August 19, 2012 10:38:17 AM SM wrote: > Hi Scott, > > At 10:18 19-08-2012, Scott Kitterman wrote: > >Are you objecting to "In general, the more broadly applicable > >Authentication- Results header field ought to be used "? > > My comment, which is not an objection, is about picking one > option. The consequences of having two options is documented in RFC 6686. > > >I think that giving guidance on how to use A-R in this context is important > >and appropriate (Use of A-R is, I believe, in scope as a widely used > >extension, but until now there's no standardized guidance on use as a > >replacement for SPF-Received). In IETF terms, I believe this is an > >applicability statement > > I am ok with providing guidance. Having a SHOULD is not > guidance. It is a recommendation (see RFC 2119). I don't see how > 4408bis can be an applicability statement about RFC 5451. There are two options. We can't remove Received-SPF as it is in use. RFC 5451 exists. Use of A-R as specified in RFC 5451 contains less information than Received-SPF does, so it's not a fully suitable replacement. So there isn't, at this time, a basis for picking. I also don't think there's a reason to pick. As long as one is picked and used within an ADMD, it doesn't matter which it is. AIUI, an applicability statement is about how to combine two technologies to meet a certain goal. I think that's exactly what the current text does between A-R and SPF. 4408bis is not formally an applicability statement, but it accomplishes the same goal in this case. Also the only SHOULD we have is that the result SHOULD be recorded. There's no 2119 preference for either and I think that is appropriate. Scott K From dhc@dcrocker.net Sun Aug 19 10:55: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 BB14821F8594 for ; Sun, 19 Aug 2012 10:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0L93hHBubJ4 for ; Sun, 19 Aug 2012 10:55:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC62C21F8581 for ; Sun, 19 Aug 2012 10:55:50 -0700 (PDT) Received: from [172.17.143.202] (50-78-155-157-static.hfc.comcastbusiness.net [50.78.155.157]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7JHtl0m003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Aug 2012 10:55:48 -0700 Message-ID: <503128A1.8010701@dcrocker.net> Date: Sun, 19 Aug 2012 13:55:45 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120817034603.20684.qmail@joyce.lan> <2137477.zzX3vIWz46@scott-latitude-e6320> <1445529.SatBtdG5jD@scott-latitude-e6320> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 19 Aug 2012 10:55:49 -0700 (PDT) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Examples in drafts X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 17:55:51 -0000 On 8/19/2012 1:07 PM, Murray S. Kucherawy wrote: > Regardless what's the harm in correcting the examples to be more > acceptable to common document conventions? I, too, am curious about this. Certainly there are times when it's important to preserve the details of an example, even when those details are problematic. The linkage to its original occurrence is required, then. I don't see how this is one of those time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Sun Aug 19 11:55: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 2F6F721F8599 for ; Sun, 19 Aug 2012 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3csTi+IHpqZ for ; Sun, 19 Aug 2012 11:55: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 9495021F857D for ; Sun, 19 Aug 2012 11:55:20 -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 q7JItFUn028052 for ; Sun, 19 Aug 2012 11:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345402520; bh=T+hcHImSk4InyFDCxPswAoCQLtU1qC1P/A4EHbNfFJQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ErHCdNaXuapMvOzPoIR9i/I5CDzCaUwfTHrN/o3TaQjOeCneGUyyVA9+MSBDJu86L 48HWy7Na+iJ/oq8O80VOSB5C0qvdPyfRILmikMOHDWsdCipm1SPhtODfE9nvgciHUg AlxWCOyfc48i5j/93+r31+DkFqN3kdDaS5diy0sc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345402520; i=@resistor.net; bh=T+hcHImSk4InyFDCxPswAoCQLtU1qC1P/A4EHbNfFJQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=OcAIUQSU+AmkQPlI+znOkqIChVT+57lT6QIpEK0if9LRZLRDp5PMknuYl6CgqOnzq g2vxqnIqDaIM2Va275LPy5LQaUxLKnS+yEWqrFflwVW9OifCwOZ8pzEKfB0UWJxLvz wKoIzXTmDjA9N4tmNTX1nIyh1qNhMlQssGJDQHe4= Message-Id: <6.2.5.6.2.20120819111807.06153cf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Aug 2012 11:51:38 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <28627603.NIrZbkTSgU@scott-latitude-e6320> References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> <7120600.Hl6UPnNzLg@scott-latitude-e6320> <6.2.5.6.2.20120819102249.09296c58@resistor.net> <28627603.NIrZbkTSgU@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 18:55:21 -0000 At 10:52 19-08-2012, Scott Kitterman wrote: >There are two options. We can't remove Received-SPF as it is in use. RFC >5451 exists. Use of A-R as specified in RFC 5451 contains less information >than Received-SPF does, so it's not a fully suitable replacement. > >So there isn't, at this time, a basis for picking. > >I also don't think there's a reason to pick. As long as one is picked and >used within an ADMD, it doesn't matter which it is. I'll comment without taking any position on "in use". I do not have an opinion for or against the Authentication-Results: header. There are days when it is good to have an IESG. It can point out the uncomfortable choices that a working group does not want to make. As the MTA operator, I get to decide whether to use Received-SPF: or Authentication-Results: as it is mentioned that it is a policy matter. I can pick either. Assuming I sell an add-on for MUAs, if the recipient asks whether the software supports SPF, I say yes as the Received-SPF: header can be parsed. The MTA the recipient uses adds an Authentication-Results: header. The recipient does not get the SPF result because of that. This is the type of operational issue that occurs when there isn't any standardized method to convey information. Regards, -sm From spf2@kitterman.com Sun Aug 19 13:09: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 6545421F85A3 for ; Sun, 19 Aug 2012 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwzGIPFAsHZL for ; Sun, 19 Aug 2012 13:09:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AE01E21F8493 for ; Sun, 19 Aug 2012 13:09:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EE5C320E411E; Sun, 19 Aug 2012 16:09:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345406974; bh=U4CPx4LmEdKg5YYHfkwNkg2mKPYgl9cqqQpsdLd4rng=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n50Eqai3i1IvvQlZgwNVIEV3BpXXI43Zjw0UxbJ0VMmBdvYUuWkoydUR5Ixq6l4vn 7XwdZkhVk0xNECErhyzqyT5xeOQkPFnXleeH+Hrpnc3TFSkacZa1aAJJprVG8x+YcW 37IMJuEL+K8INZMZqhh35gkrZvgakm7bqNHBmByg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C047020E411C; Sun, 19 Aug 2012 16:09:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 19 Aug 2012 16:09:32 -0400 Message-ID: <64069097.N0WMcmZ7LS@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120819111807.06153cf0@resistor.net> References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> <28627603.NIrZbkTSgU@scott-latitude-e6320> <6.2.5.6.2.20120819111807.06153cf0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Aug 2012 20:09:35 -0000 On Sunday, August 19, 2012 11:51:38 AM SM wrote: > At 10:52 19-08-2012, Scott Kitterman wrote: > >There are two options. We can't remove Received-SPF as it is in use. RFC > >5451 exists. Use of A-R as specified in RFC 5451 contains less information > >than Received-SPF does, so it's not a fully suitable replacement. > > > >So there isn't, at this time, a basis for picking. > > > >I also don't think there's a reason to pick. As long as one is picked and > >used within an ADMD, it doesn't matter which it is. > > I'll comment without taking any position on "in use". I do not have > an opinion for or against the Authentication-Results: header. There > are days when it is good to have an IESG. It can point out the > uncomfortable choices that a working group does not want to make. > > As the MTA operator, I get to decide whether to use Received-SPF: or > Authentication-Results: as it is mentioned that it is a policy > matter. I can pick either. > > Assuming I sell an add-on for MUAs, if the recipient asks whether the > software supports SPF, I say yes as the Received-SPF: header can be > parsed. The MTA the recipient uses adds an Authentication-Results: > header. The recipient does not get the SPF result because of > that. This is the type of operational issue that occurs when there > isn't any standardized method to convey information. Currently, the field this is handled by supporting both. As an example, my pypolicyd-spf policy server for postfix will cause postfix to add Received-SPF: by default. It can optionally be configured to add A-R. I've also provided documentation on how to provide both if desired. Spamassassin will gladly consume either (I didn't check what it does if there are two from the same MTA). SMTP Auth provides multiple mechanisms and if the client and server have none in common, no authorization is possible. I think that's fine and this is no different. Scott K From barryleiba.mailing.lists@gmail.com Sun Aug 19 17:01: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 D5B2221F8620 for ; Sun, 19 Aug 2012 17:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUlO3mwA0O2 for ; Sun, 19 Aug 2012 17:01:32 -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 01BE121F85F9 for ; Sun, 19 Aug 2012 17:01:31 -0700 (PDT) Received: by lahm15 with SMTP id m15so3149137lah.31 for ; Sun, 19 Aug 2012 17:01:30 -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=kL28rGpaHXtl6wOsr0qmTinvfW8nQJgT7dvc5htXWd8=; b=0PIaxg3Y6++4DsoPQ1JtzUpxQL+e6v0JX/OjFHhdRWwfVDO3OVrThSVrY5X56gnm6k IFaZGz8fMWIGyR1ueGAX1z5g4qlqDYLAxkIP0q0s/yRH8eRHxSH3jnrT9IabQVAeRrZu wM/OuL+QL+S9y8Bjt+kRWHYEA4w9vkMz+SGZ4xxVfEtURtkiBvbglgXra/xRa5E32z4/ HFCLa1tkyByP4KtfbJ+/tQ52Pyjg5t2uWN0q8J80ilxMSoF3nW/KND9+VU6xGcgrPFZV fkcfEcozpDqZmlZbG7zuI/jdKFWHF9pAMSW7QUlO8jjw6lR+YJbvoTBLBp6GHnLQq4CU j5Fg== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr12011632lab.36.1345420890461; Sun, 19 Aug 2012 17:01:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Sun, 19 Aug 2012 17:01:30 -0700 (PDT) In-Reply-To: <3213071.7NdDxgTL5r@scott-latitude-e6320> References: <20120817034603.20684.qmail@joyce.lan> <1445529.SatBtdG5jD@scott-latitude-e6320> <3213071.7NdDxgTL5r@scott-latitude-e6320> Date: Sun, 19 Aug 2012 20:01:30 -0400 X-Google-Sender-Auth: n3srgY7X0QLvd_TzPJaJlVFpIVw Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d040839193fd60304c7a736c6 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 00:01:32 -0000 --f46d040839193fd60304c7a736c6 Content-Type: text/plain; charset=ISO-8859-1 > > II think it's very odd for the text to say "For example, the example given > in > [RFC1034], Section 4.3.3, could be extended with the following:" and then > not > extend it, but completely rewrite it. It totally loses the point of > taking a > standard example and showing how it changes. So it's potentially > confusing. You could certainly say , "Consider the example in RFC 1034, Section 4.3.3. Based on that, we can do the following:" Trust me: it will be lots easier to use currently acceptable examples, and this is not an issue that's worth making a big stink and falling on your sword about. Really, it's not. Barry --f46d040839193fd60304c7a736c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
II think it's very odd for the text to s= ay "For example, the example given in
[RFC1034], Section 4.3.3, could be extended with the following:" and t= hen not
extend it, but completely rewrite it. =A0It totally loses the point of taki= ng a
standard example and showing how it changes. =A0So it's potentially con= fusing.

You could certainly say , "Con= sider the example in RFC 1034, Section 4.3.3. =A0Based on that, we can do t= he following:"

Trust me: it will be lots easier to use currently accep= table examples, and this is not an issue that's worth making a big stin= k and falling on your sword about. =A0Really, it's not.

Barry=A0
--f46d040839193fd60304c7a736c6-- From spf2@kitterman.com Sun Aug 19 17:07: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 46F1121F8627 for ; Sun, 19 Aug 2012 17:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dogCPWhjRSqw for ; Sun, 19 Aug 2012 17:07:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59421F8622 for ; Sun, 19 Aug 2012 17:07:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5BE4120E411E; Sun, 19 Aug 2012 20:07:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345421253; bh=4PRGdzLr3yxjbPysc0gDSk7sz0PHzfVBcPkEcRLjB6s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iksA6juS+pd+CPgBqb2RHeWIJfT/q2Teuw/yEJLUPZod7g5AcFjnwD1wcPzr92x7x rNxQXng4iL1uJRy0DPLjSHp1fkFOQwkJ2W5udpm5kmvY1XD/+0kTWEysuyK8KinjpT UPTwppyhFVrA5OcfhN7Oe9EtdU2m/ry9NdgOsJ5w= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2D84720E411C; Sun, 19 Aug 2012 20:07:26 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Sun, 19 Aug 2012 20:07:26 -0400 Message-ID: <1910497.1vn0145RCs@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120817034603.20684.qmail@joyce.lan> <3213071.7NdDxgTL5r@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 00:07:35 -0000 On Sunday, August 19, 2012 08:01:30 PM Barry Leiba wrote: > > II think it's very odd for the text to say "For example, the example given > > in > > [RFC1034], Section 4.3.3, could be extended with the following:" and then > > not > > extend it, but completely rewrite it. It totally loses the point of > > taking a > > standard example and showing how it changes. So it's potentially > > confusing. > > You could certainly say , "Consider the example in RFC 1034, Section 4.3.3. > Based on that, we can do the following:" > > Trust me: it will be lots easier to use currently acceptable examples, and > this is not an issue that's worth making a big stink and falling on your > sword about. Really, it's not. I get that that's true as a practical matter, which is why I said I'd change it. That doesn't change my opinion about it's ridiculousness. Thanks for the suggestion. Scott K From superuser@gmail.com Sun Aug 19 21:16: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 D995721F866E for ; Sun, 19 Aug 2012 21:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcd1BY4ozsy7 for ; Sun, 19 Aug 2012 21:16:00 -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 A87F221F866A for ; Sun, 19 Aug 2012 21:15:59 -0700 (PDT) Received: by lahm15 with SMTP id m15so3212711lah.31 for ; Sun, 19 Aug 2012 21:15: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=UwD3+UvfEpBa/2J5AEq+Ocq43R3/Qs4rbKseTyxb0eU=; b=x7xRQZelY4zufeQDH9+hyppkGvhlFedOEhb44W7gJMJXP1liGKvdkkSQcFpXoLotjz E/8VBPWIxovVdZHBKbElBQbR/djh71nCPHFFWZzcs7O4plDHR0IleEWZqwMOogvvWReW uakWpzKy0uBTveC/YhOFzF6CExP1peCq/fNmAwLVI3hDBrFNYwNNiFbRu1QhyDBm5CKS GnibjRvxfo18fY6ItvdPUZXZD7+SjU8At3thJyTSZqIvGmn1vzNIQmMQO/F8BrNYxTnB DBO+1VLikg01gNFFZevM8F/6mn9kLfbWlvo4LdZ0tVZrWl1Cw+CMr5uq7Ixm8ypeYkCT kXCQ== MIME-Version: 1.0 Received: by 10.112.29.131 with SMTP id k3mr5654810lbh.53.1345436158388; Sun, 19 Aug 2012 21:15:58 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 19 Aug 2012 21:15:58 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> Date: Sun, 19 Aug 2012 21:15:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 04:16:01 -0000 On Sun, Aug 19, 2012 at 9:35 AM, SM wrote: > My reading of the old text is that SMTP receivers record the result of SPF > processing for the recipient. The new text proposes two methods of > conveying the information to the recipient. This is the kind of text which > causes debates. If which header to add is a matter of local policy, the > receiver also have the ability to follow the specification; RFC 5451 in this > case. I suggest adding (non-normative) guidance if anyone would like to > have the Authentication-Results: header. Anything more than that ends up as > not picking one option and trying to satisfy everyone. I imagine this can be resolved by pointing out the reason support for two schemes is included, namely that one is historic but still in some use while the other is an established proposed standard used by several other mechanisms. It is in effect a migration path. Essentially, a receiving ADMD can use either one, but there's more momentum behind one of them to have more wide adoption in the long term, and implementers should be aware of that. -MSK From superuser@gmail.com Sun Aug 19 21:32: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 7B19C21F85F4 for ; Sun, 19 Aug 2012 21:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdC6YXXdLHzQ for ; Sun, 19 Aug 2012 21:32:57 -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 6657D21F857E for ; Sun, 19 Aug 2012 21:32:57 -0700 (PDT) Received: by lahm15 with SMTP id m15so3217276lah.31 for ; Sun, 19 Aug 2012 21:32: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=ezvaa7MSlwhuCIePLS3ddhHzOk0iULDWk+TucrlYGE8=; b=wnrGUKY45mYUqdmpfGXyxA2YFh1PCJcMfr+g/aRDLgRiFNQi4A65h/nzDD/nIzyV3z qspNrwsqk77nABv6TEjUWRF7di+g+DgyX0ebMZ4fgA3c7j7AzrY8bjnLYqRtaiCwAsl1 FRSZXlOF7R5TCVDOXeMxRT6Y9yegMZPIVS1W3wulBuLNQ7kcv8uqbd5PB0Xt/8FPZd+G 7udnIHqXHZhOwHUNzXmj4SvFT7f+ffSnWfzRVPRGt6x5ySonTCYtg9bzZ+lr7L8XNmz4 GNwgB6DV1fMKz/d1G4qqPHomopl6z3k89MYonYyEO24g+65GfditXMeX+QItWq76sKXD vFGg== MIME-Version: 1.0 Received: by 10.112.37.102 with SMTP id x6mr5427704lbj.66.1345437176275; Sun, 19 Aug 2012 21:32:56 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 19 Aug 2012 21:32:56 -0700 (PDT) In-Reply-To: <7733947.LvW5INK1oG@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> Date: Sun, 19 Aug 2012 21:32:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 04:32:58 -0000 On Sat, Aug 18, 2012 at 10:49 PM, Scott Kitterman wrote: > If you think 9.3.2 is insufficient, please provide text based on what's there > now. I know you've provided text before, but it's difficult for me to relate > and adapt it to where we are now since I don't understand your objections to > the current text. +1. There's a complaint that we haven't defined "marking", but we also don't use that term anywhere in the document, only on this mailing list. Adding a definition for it doesn't make any sense. The current 2.5.4 text lays out the two most obvious actions an operator can take on SPF "fail" evaluations. I can't imagine what's missing. We are all aware that some people believe that those who don't treat "-all" as a mandatory rejection are nuts. That opinion is not unanimous, nor is it even a consensus opinion, and hasn't been since RFC4408 and probably before. It's not likely to get added now. Therefore, I don't believe this line of debate is a wise use of our remaining energy. -MSK From W.Doust@racingvictoria.net.au Sun Aug 19 21:34: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 7CECA21F85F9 for ; Sun, 19 Aug 2012 21:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUOe0+JfGyhc for ; Sun, 19 Aug 2012 21:34:26 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 746F121F85C4 for ; Sun, 19 Aug 2012 21:34:25 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 0) id ; Mon, 20 Aug 2012 14:34:22 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2012 14:34:05 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D430F@XCHANGE.rvl.internal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: Ac18yQRpFn3MrF3lRp60kArR9VYhzgBwagZQ References: <3629422.4uNyJB6DBU@scott-latitude-e6320><502D42D7.7010900@tana.it> From: "Wayne Doust" To: "Murray S. Kucherawy" Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 04:34:26 -0000 -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Saturday, 18 August 2012 8:38 AM To: Alessandro Vesely Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities ... I appreciate the fact that there are people out there who want the silver bullet. For some people, SPF is that. That simply is not true for everyone. I have yet to work for any company (and I now work for a pretty huge one in terms of mail flows) where either it or its customers enabled SPF to reject on "fail", for example. The common point to both of these groups is that SPF's results are input to an overall evaluation of a message. For people that think SPF completely solves the problem, their evaluation system consists solely of SPF, and they do reject-on-fail. It works for them and that's fantastic. There exists, however, a substantial population that wants more than one piece of information to decide upon the fate of a message. The most common reason for that appears to involve SPF's known failure modes, but it's not for us to speculate on what those people have in mind. ---------------------------- At the risk of rehashing stuff that may have already been discussed.... To me (at least) the publication of "-all" is a very bold statement. The sender is saying two things: 1) No email will originate from any address other than the one's listed 2) No email will be forwarded=20 I include point 2 because the sender is not in control of the initial receiver and therefore cannot guarantee that SRS is implemented everywhere, nor can it guarantee that whitelists are in use at the final destination. Considering this, it would seem reasonable to assume that the SPF "Silver Bullet" is determined by the sending domain, rather than a policy of the receiver - that's why it's a "Sender Policy". Any domain that publishes "-all" is saying that SPF is a silver bullet - for THEM. Also considering this, one would think that "-all" would be less common that "~all", however that does not appear to be the case from the email that I receive. Regards, Wayne Doust (disclaimer remove) From superuser@gmail.com Sun Aug 19 21:47: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 3132D21F8470 for ; Sun, 19 Aug 2012 21:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT5bl4me8qwh for ; Sun, 19 Aug 2012 21:47: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 E575721F84D3 for ; Sun, 19 Aug 2012 21:47:18 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3253556lbb.31 for ; Sun, 19 Aug 2012 21:47:14 -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=XrlfwFTIRbaOsyQMj1icGkn2x9OvLK6wk/Au3IsmgvE=; b=vcV3q3aNJJrSIJfWGu3T0o9aNv0mHpS8PPkzREUNLdFLknx0UQEzttXSCZqOt52FIv /hTHK4f6s4mQwI/npwoJElPJ1xar9iR7MkYMmrUzcvFAeKcf6vI3FrNgOPWvOLybtQ5f ENGNmMrvjFOpFQSFyoJFyDxahWtVgekXYh9kVmPpBxXrQIHGzw/GeDWwesfw3tsF7DNA keE0soUoIW19FZ4blm/9sdlWrNWX76jIby7UngOEDUYq5m2JUAPJbAN+yvJ+4bEtg6hM vbqaMV/+B+kC7XqZxi3elJFbi540ncfBXL0z55PEUojgVCjnxarmrmgV9C23UiMVxqF/ U4bg== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr12502782lab.36.1345438034865; Sun, 19 Aug 2012 21:47:14 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 19 Aug 2012 21:47:14 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D430F@XCHANGE.rvl.internal> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D430F@XCHANGE.rvl.internal> Date: Sun, 19 Aug 2012 21:47:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 04:47:21 -0000 On Sun, Aug 19, 2012 at 9:34 PM, Wayne Doust wrote: > At the risk of rehashing stuff that may have already been discussed.... > > To me (at least) the publication of "-all" is a very bold statement. The > sender is saying two things: > > 1) No email will originate from any address other than the one's listed > 2) No email will be forwarded > > I include point 2 because the sender is not in control of the initial > receiver and therefore cannot guarantee that SRS is implemented > everywhere, nor can it guarantee that whitelists are in use at the final > destination. > > Considering this, it would seem reasonable to assume that the SPF > "Silver Bullet" is determined by the sending domain, rather than a > policy of the receiver - that's why it's a "Sender Policy". Any domain > that publishes "-all" is saying that SPF is a silver bullet - for THEM. > > Also considering this, one would think that "-all" would be less common > that "~all", however that does not appear to be the case from the email > that I receive. The survey I did shows "~all" over "-all" at better than 2:1. Cisco's survey is better than 3:1. Undoubtedly there are plenty of ADMDs that think "-all" as you're defining it is right for them. Some of them are correct, but experience has shown that many are unaware that they can't actually make those assertions, leading to accidental rejection of important messages. That causes either (a) the sender to back down from "-all" to "~all"; (b) the sender to split streams by creating a new domain name; or (c) the recipient to treat "-all" as advisory. That doesn't sound like a silver bullet to me. -MSK From W.Doust@racingvictoria.net.au Sun Aug 19 22:34: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 7773621F8565 for ; Sun, 19 Aug 2012 22:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zM+9jZJYX4V for ; Sun, 19 Aug 2012 22:34:22 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7939521F8543 for ; Sun, 19 Aug 2012 22:34:20 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 0) id ; Mon, 20 Aug 2012 15:34:18 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2012 15:32:19 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D4319@XCHANGE.rvl.internal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: Ac1+juLDlWFRKG1gSoWpR7c23zgfRgAA88eQ References: <3629422.4uNyJB6DBU@scott-latitude-e6320><502D42D7.7010900@tana.it><0D2A0D5F64179F4F9556D3DEDE39F9AF010D430F@XCHANGE.rvl.internal> From: "Wayne Doust" To: "Murray S. Kucherawy" Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 05:34:22 -0000 -----Original Message----- From: Murray S. Kucherawy [mailto:superuser@gmail.com]=20 Sent: Monday, 20 August 2012 2:47 PM To: Wayne Doust Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities The survey I did shows "~all" over "-all" at better than 2:1. Cisco's survey is better than 3:1. Undoubtedly there are plenty of ADMDs that think "-all" as you're defining it is right for them. Some of them are correct, but experience has shown that many are unaware that they can't actually make those assertions, leading to accidental rejection of important messages. That causes either (a) the sender to back down from "-all" to "~all"; (b) the sender to split streams by creating a new domain name; or (c) the recipient to treat "-all" as advisory. That doesn't sound like a silver bullet to me. -MSK ----------------------------- As with all things, YMMV and generalisations rarely fit with local experience. My stats for yesterday were: Fail : 4672 SoftFail : 814 PermError : 323 TempError : 134 None : 12144 Neutral : 758 Pass : 10454 Regardless of whether people realise by adding "-all" they are making a bold statement doesn't diminish that they ARE making a bold statement. Perhaps this can be stated better in the rfc, however for me it does seem clear from the text that it *is* a bold statement.=20 So, the question is: Do we make allowances for the fact that implementers are making bold statements they cannot back up? Now IMO THAT is a separate question altogether - one I think should be lumped in with those that cannot even publish a syntactically correct record to start with. It has been stated that accommodations should not be made for software bugs. I think the same is true here - we shouldn't be lenient with "-all" just in case the record publisher doesn't understand what it means. Are wizards to blame for this? FWIW - I TempFail (451 with detailed explanation and a phone number) on SPF Fail with a whitelist. This gives the sender a chance to ring me and be added to the whitelist.=20 From superuser@gmail.com Mon Aug 20 00:49: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 3925221F869D for ; Mon, 20 Aug 2012 00:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cdH8aQYQjFW for ; Mon, 20 Aug 2012 00:49: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 6B40421F867A for ; Mon, 20 Aug 2012 00:49:06 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3319372lbb.31 for ; Mon, 20 Aug 2012 00:49:05 -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=S4KvwZHiRE2+XckXbiImSrxFMF6hzO3hrivz5S2pHF4=; b=Zu8mmIp5c9fBN75RQejwXMR04zWPkArhsXZ0WDqPC/nHz1C8FbTbf3HRaDeDBZbavM Dr3iPTb3lxnJ2Lc/ANZOfMbn+5ajCq5xxKDOI/9jxC0jAJqij+c26Ehz8BjOuueguJG1 re0hHQLZvmG2AuDCu6K6ZsQ+a1mbT1bcux3ucLUoUtDkPe83AfMeuJ08ILpKw0jGvBZm TaUosFXZsNDLcLykfpN5UYNw3WGeAMxz+6mGx1Jjdofxbr6nJYTYpEnDlpBufdSFfuP0 ZTmvd5eA/5vdOqoWvi0G4aGcpmIEJtK7llPaEbpvtgXYYzVVUBHasnTZjyDAw9+XZS51 IMxw== MIME-Version: 1.0 Received: by 10.112.104.3 with SMTP id ga3mr5709138lbb.77.1345448944965; Mon, 20 Aug 2012 00:49:04 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 00:49:04 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D4319@XCHANGE.rvl.internal> References: <3629422.4uNyJB6DBU@scott-latitude-e6320> <502D42D7.7010900@tana.it> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D430F@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D4319@XCHANGE.rvl.internal> Date: Mon, 20 Aug 2012 00:49:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 07:49:07 -0000 On Sun, Aug 19, 2012 at 10:32 PM, Wayne Doust wrote: > It has been stated that accommodations should not be made for software > bugs. I think the same is true here - we shouldn't be lenient with > "-all" just in case the record publisher doesn't understand what it > means. Are wizards to blame for this? RFC4408 already leaves the option of what to do with "-all" to the receiver. That "leniency" is already well established as an operational necessity. We're not changing anything here, and I don't think we should. -MSK From vesely@tana.it Mon Aug 20 05:01: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 EA65421F8667 for ; Mon, 20 Aug 2012 05:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEGgoFni4Uzs for ; Mon, 20 Aug 2012 05:01:43 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 495E721F8627 for ; Mon, 20 Aug 2012 05:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345464100; bh=aZDB1fm+s5VtnfNiqNUVmb9KRmsRGecjpCJvhVM6KUU=; l=12184; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=fWPzrUBprj9zArBkdZOCN4fTym4tIRQD199bqrTYFp/mUAR+CNdxBy8eOtB423U9E bP06x/U04UXLY52QcX8Y0NCwTZHTWDB5jIAHyuLLah5ttkdBYQLYtPw9s0RWq2qAa/ yXFHNs4CSfci+tL0lMuQKlHAMTRlfgXOL8I0cKNc= 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, 20 Aug 2012 14:01:40 +0200 id 00000000005DC042.0000000050322724.00006E92 Message-ID: <50322723.8010702@tana.it> Date: Mon, 20 Aug 2012 14:01:39 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-28306-1345464100-0001-2" To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <1943574.YPYx9u0VDs@scott-latitude-e6320> <502FA73D.2040009@tana.it> <4948346.vhSgBJIQcB@scott-latitude-e6320> In-Reply-To: <4948346.vhSgBJIQcB@scott-latitude-e6320> Subject: [spfbis] Publishing domains, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 12:01:45 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-28306-1345464100-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Sat 18/Aug/2012 19:02:39 +0200 Scott Kitterman wrote: > On Saturday, August 18, 2012 04:31:25 PM Alessandro Vesely wrote: >>>> The goal of introducing the term "ADMD" is specifically to avoid using >>>> the terms interchangeably. >>> >>> If I used the wrong one in some place, please cite specifics, so I >>> can look at it and fix it. >> >> There are lots of them. Most occurrences of "domain" in sections 2.* >> and 3 actually mean ADMD, especially "domain owner" or "domain >> holder". In Section 3.5 the term "zone file" might be better. >> >> I'd suggest to dedicate an I-D version entirely to such changes, so as >> to ease reading the diff. > > Or: > > I uploaded the XML with -04 so if someone wants to send me a patch, that'd be > lovely. I did that for -05. I've left many "domain owner" as that is shorter than "ADMD that owns/controls the domain". I put a couple of very some minor changes, but I resisted relevant changes. In particular, in: 2.3. *Publishing Authorization* I would put this: ADMDs MAY publish SPF records that explicitly authorize no hosts for domain names that are neither used in the domain part of email addresses nor expected to originate mail. That "MAY" is currently "can". I'd also move that paragraph from the third to the second place, so as to have normative stuff at the beginning of the section. Please note that the "MUST" in the first paragraph bears a slightly different meaning after the change. An ADMD could get away with some compliant domains only, according to the previous wording. Now, it has to define a record for each relevant host. Should we relax that "MUST" to a "SHOULD"? Or maybe keep it at "MUST" for mfrom and relax to "SHOULD" for helo identities only? --=_north-28306-1345464100-0001-2 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-spfbis-4408bis-05-patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-05-patch.txt" LS0tIGRyYWZ0LWlldGYtc3BmYmlzLTQ0MDhiaXMtMDUueG1sCTIwMTItMDgtMjAgMTI6MjU6 MTEuMDAwMDAwMDAwICswMjAwCisrKyBkcmFmdC1pZXRmLXNwZmJpcy00NDA4YmlzLTA1LWFs ZS54bWwJMjAxMi0wOC0yMCAxMzoyNDozOC4wMDAwMDAwMDAgKzAyMDAKQEAgLTY4LDkgKzY4 LDkgQEAKICAgICAgICAgcGFydGljdWxhciwgZXhpc3RpbmcgcHJvdG9jb2xzIHBsYWNlIG5v IHJlc3RyaWN0aW9uIG9uIHdoYXQgYSBzZW5kaW5nCiAgICAgICAgIGhvc3QgY2FuIHVzZSBh cyB0aGUgIk1BSUwgRlJPTSIgb2YgYSBtZXNzYWdlIG9yIHRoZSBkb21haW4gZ2l2ZW4gb24K ICAgICAgICAgdGhlIFNNVFAgSEVMTy9FSExPIGNvbW1hbmRzLiAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgdmVyc2lvbiAxIG9mCi0gICAgICAgIHRoZSBTZW5kZXIgUG9saWN5IEZyYW1l d29yayAoU1BGKSBwcm90b2NvbCwgd2hlcmVieSBhIGRvbWFpbiBjYW4KKyAgICAgICAgdGhl IFNlbmRlciBQb2xpY3kgRnJhbWV3b3JrIChTUEYpIHByb3RvY29sLCB3aGVyZWJ5IGFuIEFE TUQgY2FuCiAgICAgICAgIGV4cGxpY2l0bHkgYXV0aG9yaXplIHRoZSBob3N0cyB0aGF0IGFy ZSBhbGxvd2VkIHRvIHVzZSBpdHMgZG9tYWluCi0gICAgICAgIG5hbWUsIGFuZCBhIHJlY2Vp dmluZyBob3N0IGNhbiBjaGVjayBzdWNoIGF1dGhvcml6YXRpb24uCisgICAgICAgIG5hbWVz LCBhbmQgYSByZWNlaXZpbmcgaG9zdCBjYW4gY2hlY2sgc3VjaCBhdXRob3JpemF0aW9uLgog ICAgICAgPC90PgogICAgICAgPHQ+VGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDNDQwOC4K ICAgICAgIDwvdD4KQEAgLTg1LDcgKzg1LDcgQEAKICAgICAgICAgZWFjaCBvZiB0aGUgdmFy aW91cyBpZGVudGlmaWVycyBzcGVjaWZpZWQgYnkgPHhyZWYgdGFyZ2V0PSJSRkM1MzIxIi8+ CiAgICAgICAgIGFuZCA8eHJlZiB0YXJnZXQ9IlJGQzUzMjIiLz4uICBBbHRob3VnaCB0aGlz IGZlYXR1cmUgaXMgZGVzaXJhYmxlIGluCiAgICAgICAgIHNvbWUgY2lyY3Vtc3RhbmNlcywg aXQgaXMgYSBtYWpvciBvYnN0YWNsZSB0byByZWR1Y2luZyBVbnNvbGljaXRlZCBCdWxrCi0g ICAgICAgIGVtYWlsIChVQkUsIGFrYSBzcGFtKS4gIEZ1cnRoZXJtb3JlLCBtYW55IGRvbWFp biBvd25pbmcgQURNRHMKKyAgICAgICAgRW1haWwgKFVCRSwgYWthIHNwYW0pLiAgRnVydGhl cm1vcmUsIG1hbnkgZG9tYWluIG93bmluZyBBRE1EcwogICAgICAgICAoQURtaW5pc3RyYXRp dmUgTWFuYWdlbWVudCBEb21haW5zLCBzZWUgPHhyZWYgdGFyZ2V0PSJSRkM1NTk4Ii8+KSBh cmUKICAgICAgICAgdW5kZXJzdGFuZGFibHkgY29uY2VybmVkIGFib3V0IHRoZSBlYXNlIHdp dGggd2hpY2ggb3RoZXIgZW50aXRpZXMgY2FuCiAgICAgICAgIG1ha2UgdXNlIG9mIHRoZWly IGRvbWFpbiBuYW1lcywgb2Z0ZW4gd2l0aCBtYWxpY2lvdXMgaW50ZW50LgpAQCAtOTQsNyAr OTQsNyBAQAogICAgICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBwcm90b2NvbCBieSB3 aGljaCBBRE1EcyBjYW4gYXV0aG9yaXplIGhvc3RzIHRvCiAgICAgICAgIHVzZSB0aGVpciBk b21haW4gbmFtZXMgaW4gdGhlICJNQUlMIEZST00iIG9yICJIRUxPIgogICAgICAgICBpZGVu dGl0aWVzLiAgQ29tcGxpYW50IEFETURzIHB1Ymxpc2ggU2VuZGVyIFBvbGljeSBGcmFtZXdv cmsgKFNQRikKLSAgICAgICAgcmVjb3JkcyBpbiBETlMgc3BlY2lmeWluZyB3aGljaCBob3N0 cyBhcmUgcGVybWl0dGVkIHRvIHVzZSB0aGVpciBuYW1lcywKKyAgICAgICAgcmVjb3JkcyBp biB0aGUgRE5TIHNwZWNpZnlpbmcgd2hpY2ggaG9zdHMgYXJlIHBlcm1pdHRlZCB0byB1c2Ug dGhlaXIgbmFtZXMsCiAgICAgICAgIGFuZCBjb21wbGlhbnQgbWFpbCByZWNlaXZlcnMgdXNl IHRoZSBwdWJsaXNoZWQgU1BGIHJlY29yZHMgdG8gdGVzdCB0aGUKICAgICAgICAgYXV0aG9y aXphdGlvbiBvZiBzZW5kaW5nIE1haWwgVHJhbnNmZXIgQWdlbnRzIChNVEFzKSB1c2luZyBh IGdpdmVuCiAgICAgICAgICJIRUxPIiBvciAiTUFJTCBGUk9NIiBpZGVudGl0eSBkdXJpbmcg YSBtYWlsCkBAIC0yMjcsOCArMjI3LDggQEAKICAgICAgICAgICBOb3RlIHRoYXQgcmVxdWly ZW1lbnRzIGZvciB0aGUgZG9tYWluIHByZXNlbnRlZCBpbiB0aGUgRUhMTyBvciBIRUxPCiAg ICAgICAgICAgY29tbWFuZCBhcmUgbm90IGFsd2F5cyBjbGVhciB0byB0aGUgc2VuZGluZyBw YXJ0eSwgYW5kIFNQRiB2ZXJpZmllcnMKICAgICAgICAgICBNVVNUIGJlIHByZXBhcmVkIGZv ciB0aGUgIkhFTE8iIGlkZW50aXR5IHRvIGJlIG1hbGZvcm1lZAotICAgICAgICAgIG9yIGFu IElQIGFkZHJlc3MgbGl0ZXJhbC4gIFNQRiBjaGVja3MgY2FuIG9ubHkgYmUgcGVyZm9ybWVk IHdoZW4gdGhlCi0gICAgICAgICAgIkhFTE8iIHN0cmluZyBpcyBhIHZhbGlkIGZ1bGx5IHF1 YWxpZmllZCBkb21haW4uCisgICAgICAgICAgb3IgYW4gSVAgYWRkcmVzcyBsaXRlcmFsLiAg VGhpcyBTUEYgY2hlY2sgY2FuIG9ubHkgYmUgcGVyZm9ybWVkIHdoZW4KKyAgICAgICAgICB0 aGUgIkhFTE8iIHN0cmluZyBpcyBhIHZhbGlkIGZ1bGx5IHF1YWxpZmllZCBkb21haW4uCiAg ICAgICAgIDwvdD4KICAgICAgIDwvc2VjdGlvbj4KICAgICAgIDxzZWN0aW9uIHRpdGxlPSJU aGUgJnF1b3Q7TUFJTCBGUk9NJnF1b3Q7IElkZW50aXR5IiBhbmNob3I9Im1mcm9tLWlkZW50 Ij4KQEAgLTI1MSwxMCArMjUxLDEwIEBACiAgICAgICA8L3NlY3Rpb24+CiAgICAgICA8c2Vj dGlvbiB0aXRsZT0iUHVibGlzaGluZyBBdXRob3JpemF0aW9uIj4KICAgICAgICAgPHQ+Ci0g ICAgICAgICAgQW4gU1BGLWNvbXBsaWFudCBkb21haW4gTVVTVCBwdWJsaXNoIGEgdmFsaWQg U1BGIHJlY29yZCBhcwotICAgICAgICAgIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9InJl Y29yZHMiLz4uICBUaGlzIHJlY29yZCBhdXRob3JpemVzIHRoZQotICAgICAgICAgIHVzZSBv ZiB0aGUgZG9tYWluIG5hbWUgaW4gdGhlICJIRUxPIiBhbmQgIk1BSUwgRlJPTSIKLSAgICAg ICAgICBpZGVudGl0aWVzIGJ5IHRoZSBNVEFzIGl0IHNwZWNpZmllcy4KKyAgICAgICAgICBB biBTUEYtY29tcGxpYW50IEFETUQgTVVTVCBwdWJsaXNoIHZhbGlkIFNQRiByZWNvcmRzIGFz CisgICAgICAgICAgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0icmVjb3JkcyIvPi4gIFRo ZXNlIHJlY29yZHMgYXV0aG9yaXplIHRoZQorICAgICAgICAgIHVzZSBvZiB0aGUgcmVsZXZh bnQgZG9tYWluIG5hbWVzIGluIHRoZSAiSEVMTyIgYW5kICJNQUlMIEZST00iCisgICAgICAg ICAgaWRlbnRpdGllcyBieSB0aGUgTVRBcyBzcGVjaWZpZWQgdGhlcmVpbi4KICAgICAgICAg PC90PgogICAgICAgICA8dD4KICAgICAgICAgICBTUEYgcmVzdWx0cyBjYW4gYmUgdXNlZCB0 byBtYWtlIGJvdGggcG9zaXRpdmUgKHNvdXJjZSBpcyBhdXRob3JpemVkKQpAQCAtMjY3LDgg KzI2Nyw5IEBACiAgICAgICAgICAgZGV0ZXJtaW5hdGlvbnMgYXJlIGRpc2N1c3NlZCBpbiA8 eHJlZiB0YXJnZXQ9ImltcGxpY2F0aW9ucyIvPi4KICAgICAgICAgPC90PgogICAgICAgICA8 dD4KLSAgICAgICAgICBEb21haW4gaG9sZGVycyBjYW4gcHVibGlzaCBTUEYgcmVjb3JkcyB0 aGF0IGV4cGxpY2l0bHkgYXV0aG9yaXplIG5vCi0gICAgICAgICAgaG9zdHMgaWYgbWFpbCBp cyBub3QgZXhwZWN0ZWQgdG8gb3JpZ2luYXRlIHVzaW5nIHRoYXQgZG9tYWluLgorICAgICAg ICAgIEFETURzIGNhbiBwdWJsaXNoIFNQRiByZWNvcmRzIHRoYXQgZXhwbGljaXRseSBhdXRo b3JpemUgbm8KKyAgICAgICAgICBob3N0cyBmb3IgZG9tYWluIG5hbWVzIHRoYXQgYXJlIG5l aXRoZXIgdXNlZCBpbiB0aGUgZG9tYWluIHBhcnQgb2YKKyAgICAgICAgICBlbWFpbCBhZGRy ZXNzZXMgbm9yIGV4cGVjdGVkIHRvIG9yaWdpbmF0ZSBtYWlsLgogICAgICAgICA8L3Q+CiAg ICAgICAgIDx0PgogICAgICAgICAgIFdoZW4gY2hhbmdpbmcgU1BGIHJlY29yZHMsIGNhcmUg bXVzdCBiZSB0YWtlbiB0byBlbnN1cmUgdGhhdCB0aGVyZQpAQCAtNDQ5LDcgKzQ1MCw3IEBA CiAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJTb2Z0ZmFpbCIgYW5jaG9yPSJvcC1yZXN1bHQt c29mdGZhaWwiPgogICAgICAgICAgIDx0PgogICAgICAgICAgICAgQSAic29mdGZhaWwiIHJl c3VsdCBvdWdodCB0byBiZSB0cmVhdGVkIGFzIHNvbWV3aGVyZSBiZXR3ZWVuICJmYWlsIgot ICAgICAgICAgICAgYW5kICJuZXV0cmFsIi8ibm9uZSIuICBUaGUgZG9tYWluIGJlbGlldmVz IHRoZSBob3N0IGlzIG5vdAorICAgICAgICAgICAgYW5kICJuZXV0cmFsIi8ibm9uZSIuICBU aGUgZG9tYWluIG93bmVyIGJlbGlldmVzIHRoZSBob3N0IGlzIG5vdAogICAgICAgICAgICAg YXV0aG9yaXplZCBidXQgaXMgbm90IHdpbGxpbmcgdG8gbWFrZSBhIHN0cm9uZyBwb2xpY3kg c3RhdGVtZW50LgogICAgICAgICAgICAgUmVjZWl2aW5nIHNvZnR3YXJlIFNIT1VMRCBOT1Qg cmVqZWN0IHRoZSBtZXNzYWdlIGJhc2VkIHNvbGVseSBvbgogICAgICAgICAgICAgdGhpcyBy ZXN1bHQsIGJ1dCBNQVkgc3ViamVjdCB0aGUgbWVzc2FnZSB0byBjbG9zZXIgc2NydXRpbnkg dGhhbgpAQCAtNTEyLDcgKzUxMyw3IEBACiAgICAgICAgICJhOmNvbG8uZXhhbXBsZS5jb20v MjgiICh0aGUgKyBpcyBpbXBsaWVkKSwgYW5kICItYWxsIi4KICAgICAgIDwvdD4KICAgICAg ICAgPHQ+Ci0gICAgICAgICAgVGhlIFNQRiByZWNvcmRzIGFyZSBwbGFjZWQgaW4gdGhlIERO UyB0cmVlIGF0IHRoZSBob3N0IG5hbWUgaXQKKyAgICAgICAgICBFYWNoIFNQRiByZWNvcmQg aXMgcGxhY2VkIGluIHRoZSBETlMgdHJlZSBhdCB0aGUgaG9zdCBuYW1lIGl0CiAgICAgICAg ICAgcGVydGFpbnMgdG8sIG5vdCBhIHN1YmRvbWFpbiB1bmRlciBpdCwgc3VjaCBhcyBpcyBk b25lIHdpdGggU1JWCiAgICAgICAgICAgcmVjb3JkcyA8eHJlZiB0YXJnZXQ9IlJGQzI3ODIi Lz4uCiAgICAgICAgIDwvdD4KQEAgLTUzMyw5ICs1MzQsOSBAQAogICAgICAgICAgIGVuc3Vy ZSBvbmx5IFNQRiByZWNvcmRzIGFyZSB1c2VkIGZvciBTUEYgcHJvY2Vzc2luZy4KICAgICAg ICAgPC90PgogICAgICAgICA8dD4KLSAgICAgICAgICBEb21haW5zIHB1Ymxpc2hpbmcgcmVj b3JkcyBTSE9VTEQgdHJ5IHRvIGtlZXAgdGhlIG51bWJlciBvZgorICAgICAgICAgIEFETURz IHB1Ymxpc2hpbmcgU1BGIHJlY29yZHMgU0hPVUxEIHRyeSB0byBrZWVwIHRoZSBudW1iZXIg b2YKICAgICAgICAgICAiaW5jbHVkZSIgbWVjaGFuaXNtcyBhbmQgY2hhaW5lZCAicmVkaXJl Y3QiIG1vZGlmaWVycyB0byBhIG1pbmltdW0uCi0gICAgICAgICAgRG9tYWlucyBTSE9VTEQg YWxzbyB0cnkgdG8gbWluaW1pemUgdGhlIGFtb3VudCBvZiBvdGhlciBETlMKKyAgICAgICAg ICBBRE1EcyBTSE9VTEQgYWxzbyB0cnkgdG8gbWluaW1pemUgdGhlIGFtb3VudCBvZiBvdGhl ciBETlMKICAgICAgICAgICBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gZXZhbHVhdGUgYSByZWNv cmQuICA8eHJlZiB0YXJnZXQ9ImV2YWwtbGltaXRzIi8+CiAgICAgICAgICAgYW5kIDx4cmVm IHRhcmdldD0ic2VuZGluZy1yZXNvdXJjZXMiLz4gcHJvdmlkZSBzb21lIHN1Z2dlc3Rpb25z IG9uIGhvdwogICAgICAgICAgIHRvIGFjaGlldmUgdGhpcy4KQEAgLTYwMyw3ICs2MDQsNyBA QAogICAgICAgICA8c2VjdGlvbiB0aXRsZT0iV2lsZGNhcmQgUmVjb3JkcyI+CiAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICBVc2Ugb2Ygd2lsZGNhcmQgcmVjb3JkcyBmb3IgcHVibGlz aGluZyBpcyBOT1QgUkVDT01NRU5ERUQuIENhcmUKLSAgICAgICAgICAgIG11c3QgYmUgdGFr ZW4gaWYgd2lsZGNhcmQgcmVjb3JkcyBhcmUgdXNlZC4gSWYgYSBkb21haW4gcHVibGlzaGVz CisgICAgICAgICAgICBtdXN0IGJlIHRha2VuIGlmIHdpbGRjYXJkIHJlY29yZHMgYXJlIHVz ZWQuIElmIGEgem9uZSBwdWJsaXNoZXMKICAgICAgICAgICAgIHdpbGRjYXJkIE1YIHJlY29y ZHMsIGl0IG1pZ2h0IHdhbnQgdG8gcHVibGlzaCB3aWxkY2FyZAogICAgICAgICAgICAgZGVj bGFyYXRpb25zLCBzdWJqZWN0IHRvIHRoZSBzYW1lIHJlcXVpcmVtZW50cyBhbmQgcHJvYmxl bXMuIEluCiAgICAgICAgICAgICBwYXJ0aWN1bGFyLCB0aGUgZGVjbGFyYXRpb24gTVVTVCBi ZSByZXBlYXRlZCBmb3IgYW55IGhvc3QgdGhhdApAQCAtNjI4LDkgKzYyOSw5IEBACiAgICAg ICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICAgPHQ+ Ci0gICAgICAgICAgICBTUEYgcmVjb3JkcyBNVVNUIGJlIGxpc3RlZCB0d2ljZSBmb3IgZXZl cnkgbmFtZSB3aXRoaW4gdGhlIGRvbWFpbjoKKyAgICAgICAgICAgIFNQRiByZWNvcmRzIE1V U1QgYmUgbGlzdGVkIHR3aWNlIGZvciBldmVyeSBuYW1lIHdpdGhpbiB0aGUgem9uZToKICAg ICAgICAgICAgIG9uY2UgZm9yIHRoZSBuYW1lLCBhbmQgb25jZSB3aXRoIGEgd2lsZGNhcmQg dG8gY292ZXIgdGhlIHRyZWUgdW5kZXIKLSAgICAgICAgICAgIHRoZSBuYW1lIGluIG9yZGVy IHRvIGNvdmVyIGFsbCBkb21haW5zIGluIHVzZSBpbiBvdXRnb2luZyBtYWlsLgorICAgICAg ICAgICAgdGhlIG5hbWUsIGluIG9yZGVyIHRvIGNvdmVyIGFsbCBkb21haW5zIGluIHVzZSBp biBvdXRnb2luZyBtYWlsLgogICAgICAgICAgIDwvdD4KICAgICAgICAgPC9zZWN0aW9uPgog ICAgIDwvc2VjdGlvbj4KQEAgLTIwNzIsNyArMjA3Myw3IEBACiAgICAgICAgICAgICBub3Jt YWwgdG8gaGF2ZSB0aGUgSEVMTyBpZGVudGl0eSBzZXQgdG8gaG9zdG5hbWUgaW5zdGVhZCBv ZiBkb21haW4uCiAgICAgICAgICAgICBab25lIGZpbGUgZ2VuZXJhdGlvbiBmb3Igc2lnbmlm aWNhbnQgbnVtYmVycyBvZiBob3N0cyBjYW4gYmUKICAgICAgICAgICAgIGNvbnNvbGlkYXRl ZCB1c2luZyB0aGUgcmVkaXJlY3QgbW9kaWZpZXIgYW5kIHNjcmlwdGVkIGZvciBpbml0aWFs Ci0gICAgICAgICAgICBkZXBsb3ltZW50LiAgU3BlY2lmaWMgZGVwbG95bWVudCBhZHZpY2Ug aXMgZ2l2ZW4gYWJvdmUgaW4gU2VjdGlvbgorICAgICAgICAgICAgZGVwbG95bWVudC4gIFNw ZWNpZmljIGRlcGxveW1lbnQgYWR2aWNlIGlzIGdpdmVuIGFib3ZlIGluCiAgICAgICAgICAg ICA8eHJlZiB0YXJnZXQ9InNlbmRpbmctYWRtaW4iLz4uCiAgICAgICAgICAgPC90PgogICAg ICAgICA8L3NlY3Rpb24+Cg== --=_north-28306-1345464100-0001-2-- From hsantos@isdg.net Mon Aug 20 05:22: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 9EED821F862A for ; Mon, 20 Aug 2012 05:22:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7ihyfS2ahg0 for ; Mon, 20 Aug 2012 05:22:20 -0700 (PDT) Received: from ntbbs.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC721F8667 for ; Mon, 20 Aug 2012 05:22:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=871; t=1345465328; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=AaFnzwbpneURuEb+lrxpKnf5E+c=; b=i7DqImjJFCVmdScMETni h8Dc66Y5g9NNCKI6IM7Gf+yWZwriOkzr4CZu5nbhjPTE1LyXhDcsybT+4g00ViMh RAuyBTfF351Fxnrw9oM1DFNPvzaNgo7+5wLZuD3fr+sT/h6kx1YBvKK52fSSRZqr wjYiTlkqScqcluMrtzu0PUs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 08:22:08 -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 1487127931.25431.5108; Mon, 20 Aug 2012 08:22:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=871; t=1345465139; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=U7oytYo CdPzEluOkShJujZs4kYILKh7OGEvifLfOZcI=; b=d10RTkfAOSCM7X1VTvvwcsK HefIPq1o1z69s0ONVMPWm8BU7E94PaVVCiz8zLcoB2W7ht4rsNhvA2vq+HLyJJoT jH0vQWEAHphk4TZh9ha/CFtwD6pv1hC4owal3krDHsIeEaWCId3gXn+sn+ht0fZt NVZaDWztojrNJB9RJ+ts= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 08:18: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 2085936739.7.1328; Mon, 20 Aug 2012 08:18:57 -0400 Message-ID: <50322C0E.8080803@isdg.net> Date: Mon, 20 Aug 2012 08:22:38 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 12:22:24 -0000 Murray S. Kucherawy wrote: > On Sat, Aug 18, 2012 at 10:49 PM, Scott Kitterman wrote: >> If you think 9.3.2 is insufficient, please provide text based on what's there >> now. I know you've provided text before, but it's difficult for me to relate >> and adapt it to where we are now since I don't understand your objections to >> the current text. > > +1. There's a complaint that we haven't defined "marking", but we > also don't use that term anywhere in the document, only on this > mailing list. Adding a definition for it doesn't make any sense. Not so. It was defined in 2.5.4 in RFC4408. You moved it to 9.3.2 in a vague way. I can suggeste you strengthen RFC2119 reading with SMTP level rejection, so maybe I should no longer be "complaining" - no, both are needed. I hope to provide example text later today. -- HLS From hsantos@isdg.net Mon Aug 20 05:24: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 A507C21F859F for ; Mon, 20 Aug 2012 05:24:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHBqd4Sc++PG for ; Mon, 20 Aug 2012 05:24:09 -0700 (PDT) Received: from ntbbs.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF5421F859B for ; Mon, 20 Aug 2012 05:24:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=594; t=1345465448; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=X9s058FFT1n66Zj3sZvUKN3Brbc=; b=tFM1Aqtf7SW+vz0FWbQt AHAj6/12IiWLrHttBt3b/MBZ1nrhzhMqEpuohxVHECLLXo55D8kHR0ltu7jDQm/4 L6YA5rqMs5A7Rnv7LcUJ1/lMao94EWaAIrxhBai4NLsg8ItqJZqK2Pfd5F4doJaC kaulHs3CBc3TjRgSDyolOLI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 08:24:08 -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 1487248036.25431.1840; Mon, 20 Aug 2012 08:24:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=594; t=1345465260; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=6zzZKrh 0ElGIT4s2R2A4W/KSvfVgjv8gmdGEx8K2No8=; b=WyKS9p8DeNVh8/zu4ZxsSnz uZYeamP1+McKYT3AtSYgRguF6Y7IOhCQy65I3ff/EsxDXCGb23HCEmXgB+hwPn6Z L0+H/BCR9TV8MwfSqoV5ZNFo1Rb4YSwMsdlRuZJIskhMtuKs/4iWUXV9+nOFEh4C gf4uOzBzvlvFOdJpn2CQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 08:21:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2086058677.7.4692; Mon, 20 Aug 2012 08:20:59 -0400 Message-ID: <50322C89.6040005@isdg.net> Date: Mon, 20 Aug 2012 08:24:41 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> In-Reply-To: <50322C0E.8080803@isdg.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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 12:24:09 -0000 Hector Santos wrote: >> Murray stated: >> +1. There's a complaint that we haven't defined "marking", but we >> also don't use that term anywhere in the document, only on this >> mailing list. Adding a definition for it doesn't make any sense. > > Not so. It was defined in 2.5.4 in RFC4408. You moved it to 9.3.2 in a > vague way. Sorry, it was mentioned, not defined. > I can suggest you strengthen RFC2119 reading with SMTP level > rejection, so maybe I should no longer be "complaining" - no, both are > needed. > > I hope to provide example text later today. -- HLS From sm@elandsys.com Mon Aug 20 08:42:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5ED21F8674 for ; Mon, 20 Aug 2012 08:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGh0B1+Z5T-f for ; Mon, 20 Aug 2012 08:42: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 44A6321F866E for ; Mon, 20 Aug 2012 08:42:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.30]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7KFfpQS014136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 08:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345477323; bh=WWYZcI4Ey+yNxiICbTSRQkx3EnsSVeYi7fphfszfyjc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sFaArAnE6DblEj66ve8FUb6wD4nno9qxhyFhQVqPTrLh0muuXbs6POt1dr1dM/Cfc XkRSc+w5glx+gPdDuO4W7TUAZB+5teIwxCyefmAQFzB/6H1Ms+eG/WcjO7tP8CuMP0 lVxpNkNhlGjbayr+/2LlYUJyhRG1Rcbn7e288N6w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345477323; i=@elandsys.com; bh=WWYZcI4Ey+yNxiICbTSRQkx3EnsSVeYi7fphfszfyjc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=atMdcQOO+hfTxyD7sMztBN6q+xYWQ56w2DNDib4jUnck/BUbtsSJ6suXDPiglNxgy cYisuo7v9yoM11O9xLAB4YsTtXwPhMgB3A/W+nMN5USwFvkWW0caNoVqk4mh9cCfCt 8dsdydnFVMiSTwkFiBA3XScAU7wlfb4JyoeSJJkA= Message-Id: <6.2.5.6.2.20120820082447.0af4e268@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Aug 2012 08:41:19 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50322C0E.8080803@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] SMTP level rejection (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 15:42:05 -0000 Hello, [Bcc to spfbis-chairs@tools.ietf.org] This is the text from RFC 4408: 'A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see [RFC3464]), in addition to an appropriate reply text.' My reading of the above is that there isn't any RFC 2119 [1] requirement or RFC 2119 recommendation to do SMTP level rejection. Am I reading the text incorrect? Regards, S. Moonesamy SPFBIS WG co-chair 1. http://www.rfc-editor.org/rfc/rfc2119.txt From agthisell@yahoo.com Mon Aug 20 08:55:02 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 68A0221F854F for ; Mon, 20 Aug 2012 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcwhx-+mUOV3 for ; Mon, 20 Aug 2012 08:55:02 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by ietfa.amsl.com (Postfix) with SMTP id C120921F8518 for ; Mon, 20 Aug 2012 08:55:01 -0700 (PDT) Received: from [98.138.90.57] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2012 15:54:56 -0000 Received: from [98.138.226.169] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2012 15:54:56 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 20 Aug 2012 15:54:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 412342.87101.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 96451 invoked by uid 60001); 20 Aug 2012 15:54:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345478096; bh=Mg+wjeEcBK3Fw1ghU4YMmz+Pm9aPCu+9PA2PPFO6p4U=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=oksZfMvTsPDPlHIOUkD4WTyalspLfVdAyRpj8nj5fGDTvdjUnV0hxVAszakpxGNYOs6K1dlvDM8GdyhReiUIqHpP5NAoW1RDVfloZnLhWvHDrKL/4FPs961OykZOUNeX05bbub5mbHjr9TJWCFDmuodQvgaJdznkzUXE7fKA2c0= 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=Fv+pujuLhWCx70canPc4C42sGs0znwwsS0gFm1w0BL4uC2fDp41bWLUKVkjicsCv+TQsKyNz1qqgWuMoIObpGqqmFeieW4CTm39NzsLLpItER0JGeJojUXG5AEzjOcV8/SXmWxxKGSSHIvqoy9XzeEzPYH3u7zTT+577LUzT+9Q=; X-YMail-OSG: kFIXKGYVM1lSW4IR1cp.td_jwntfM_e53W8XX5pauX3qEF7 2trWyLpIlDirtQcea92MAb0.UZ_ZsAWpQDTVpxizPZCiKVSIQ4Qfm9HvmlU4 s9YMZ.wOFgXZ_ctUW7Pkpk6nkrd.F.td7LhiZBjMG8N6rs0yppOBwVys92Aj J33JLCtCwjqDnaT.2EUCSpviPX67ToAiJ.ZGy5j8HpxFfp58duAR9N7j3r6z 0d1gveMMwdTOPZ9JxKjUAL3ULKXgj5Zf1XjsriKUUenbXAzFJkyq_oVslOMe 63YmOWfX8cZeiZyIy_2QmvuAOVyIquv8S3cFn8hlQ3amGCodnnUn3wSXgJF5 s7ld2jB3rkgYTlQgMh5FLyr5W9mFQGDe8z_LD6N5Wu95dl9al1AvONPCevCw SLmFk0rgOCCD7.LQrVe3I5rE1C_sU98eBT_X_oczYlMaq8ZNefCDMiSpPidF iF7n6.6go5KgEeXvTVIU- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Mon, 20 Aug 2012 08:54:56 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1345478096.96088.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Mon, 20 Aug 2012 08:54:56 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Are "unknown modifiers" ever used? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 15:55:02 -0000 Pardon my ignorance, I have done a very poor job keeping up on this list, but has there been any discussion about "unknown modifiers"? Are they actually used by anyone, or are they misspellings of redirect=/exp=? For those that don't know about them, RFC4408 didn't allow new/unknown mechanisms to be added, but did allow future expansion via new/unknown modifiers. The idea was that you could create an SPF record that said "v=spf1 dkim=always", as your sender policy, and SPF would become the accepted sender policy framework. To the best of my knowledge, no one ever used this feature and I suspect it reduces the reliability of SPF records by allow typos such as redir= to be silently ignored. From vesely@tana.it Mon Aug 20 09: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 2D6A121F86C6 for ; Mon, 20 Aug 2012 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.62 X-Spam-Level: X-Spam-Status: No, score=-4.62 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjx5yberB7I4 for ; Mon, 20 Aug 2012 09:45:22 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFE21F86BE for ; Mon, 20 Aug 2012 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345481120; bh=5PIQlz4rSTDcQKppfl2Gue4Pnu2raFUytwSlTfp5bu8=; l=3979; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Mwm7304gdtgpUt41m9jop5/ZvHOd8p51+zSDvhLdJmLWgkvnSrkQ2Pz+YKBCf7/bZ IXHFPNOzNlBpVf1Thh4mxjWM9dm4PcrOKPhRt5gGCpyGUlPREulpDUjXDclZCs/e1+ dyDliImzkAHBf035ichZZihefFrEza30PcP5Mf9A= 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, 20 Aug 2012 18:45:20 +0200 id 00000000005DC039.00000000503269A0.00002F6B Message-ID: <5032699F.1070104@tana.it> Date: Mon, 20 Aug 2012 18:45:19 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> In-Reply-To: <2609549.aGaQhnMI7j@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 16:45:23 -0000 On Sat 18/Aug/2012 19:40:00 +0200 Scott Kitterman wrote: > On Saturday, August 18, 2012 04:31:35 PM Alessandro Vesely wrote: >> On Fri 17/Aug/2012 23:46:24 +0200 Murray S. Kucherawy wrote: >>> I think the current text for "Fail" explains perfectly well that >>> the option of what to do with the message is left to the receiver, >>> as it should be. That's what "disposition" is. >> >> I beg to disagree. The current wording resembles a generic statement >> that receivers can do as they like: >> >> Disposition of SPF fail messages is a matter of local policy. > > It does and it's correct. Receivers can do as they like. They don't get to > decide how to determine if an SPF result is "fail", that is standardized, but > once they have that result they get to decide what to do with it. > >> Does that mean local policy doesn't have a say in case the result is >> "none"? In other 2.5.x sections we may want to say something like >> Section 2.5.5 does: >> >> Receiving servers SHOULD NOT reject mail based solely on this >> SPF result. >> >> Not "In this case disposition is not a matter of local policy." > > If there's no SPF result there can be no SPF related policy, so I don't see a > need for a change. Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted is from Section 2.5.5 (softfail). The question is why is the latter normative while the advice for "fail" is not. >>> I'm not liking the idea of identifying specific SMTP reply codes or >>> enhanced status codes that should be used for SPF rejections. RFC3463 >>> and RFC5321 already define those. We should leave that alone. If we >>> want to give examples, that's fine, but I don't think we should be >>> normative about it. >> >> +1! In addition, the current spec doesn't mention that a server may >> want to decline a whole session as a result of a failed HELO check. >> SHOULD a server reject each and every transaction instead? > > I think that's up to local policy/an implementation detail. HELO/EHLO can > change during a session, so it's not axiomatic that one should. Thus, a receiver may reject whichever command it likes. That's fine for me. However, from the second paragraph onward, the text of Section 2.5.4 is written assuming that the failed identity is MAIL FROM. (I partially retract the "+1" I gave on http://www.ietf.org/mail-archive/web/spfbis/current/msg01844.html ) Technically, "during the SMTP transaction" means that the transaction has to be started, which is after the last HELO/EHLO command. Can we say "before accepting the SMTP transaction" instead? >> Although this was in RFC 4408 and not novel, the relevant SMTP text >> was moved from Section 3.7 of RFC 2821 to its own Section 3.6.2 of RFC >> 5321, where the "policy reasons" are further characterized by using >> the term "SPF". Repeating normative parts introduces ambiguity as to >> whether the two protocols overlap. > > Perhaps. I agree it's reasonably obvious what one should pick for the SMTP > reply code. For enhanced status codes, it's much less clear. Reviewing > http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced- > status-codes.xml does not lead me to one obviously correct solution. I think > providing additional specificity is useful. Yes, it is useful, but putting the codes in the example is clear enough. That "SHOULD" is spurious. Besides, the description in the page you cite, although not SPF-specific, is quite clear: X.7.1 Delivery not authorized, message refused 451, 454, 502, 503, 533, 550, 551 The sender is not authorized to send to the destination. Thus, we could say: The receiving server MAY reject messages using codes as specified by SMTP ([RFC5321]) and, if supported, Enhanced Mail System Status Codes ([RFC3463]). That way, we'd use normative language for the point pertaining to the SPF protocol, while sparing it for what pertains to other standards. From hsantos@isdg.net Mon Aug 20 10:06: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 2F22521F8557 for ; Mon, 20 Aug 2012 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgq+QyHw57Zz for ; Mon, 20 Aug 2012 10:06:38 -0700 (PDT) Received: from news.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1893921F853B for ; Mon, 20 Aug 2012 10:06:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4108; t=1345482394; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=JSeXHarj7fpwUxxDvsqSq+1JtHM=; b=folVn65wMppwSrd879XQ ED0w6npo3fOZ8caHZvA3M/CQsXD7kxYh7ePXyAUCsQ4tGHHu724dLjAtozRFXObm 4eWJb9R1PJvLp3c4kz7LddcBzqnZWqVIqbnu8YKS/ywV32ILGXrhNI4k+Ll1lBcj QJ4lKccU521LH6YfjWdAEn8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 13:06:34 -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 1504193395.25431.1884; Mon, 20 Aug 2012 13:06:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4108; t=1345482206; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PmRczY4 KmrR8zqKkQrxOYdmaLgLAQyEjxdEPksXtNfU=; b=QalKk/Be6dvRoUtzhZQV+8C tKwkBpBlxmWg64h6vc5yVhxZX4cSp0FaiZjNy4bMvtg1DFebQY71l8q1u8DLpZBq pHwp5r7EPPWfypD97YGmvTVwha6OrqHaFQmzPk9SjBV4HpqSCXUmxjQ2GkNaaMjy 9xwSzEvmAaavu6my2fhA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 13:03:26 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2103005099.7.6484; Mon, 20 Aug 2012 13:03:26 -0400 Message-ID: <50326EA1.7030107@isdg.net> Date: Mon, 20 Aug 2012 13:06:41 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> In-Reply-To: <6.2.5.6.2.20120820082447.0af4e268@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] SMTP level rejection X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 17:06:39 -0000 S Moonesamy wrote: > Hello, > > [Bcc to spfbis-chairs@tools.ietf.org] > > This is the text from RFC 4408: > > 'A "Fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject the > mail outright. > > If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 (see > [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification > (DSN) code (see [RFC3464]), in addition to an appropriate reply text.' > > My reading of the above is that there isn't any RFC 2119 [1] requirement > or RFC 2119 recommendation to do SMTP level rejection. Am I reading the > text incorrect? We can really lost with rhetorical judo RFC2119 semantics games. I prefer to design protocol software from an practical engineering standpoint, but lets go ahead and play it out. What it the difference in the following three sentences for the SOFTWARE ENGINEER or his programmer writing the "checking software?" The checking software can choose to mark the mail based on this or to reject the mail outright. The checking software CAN choose to mark the mail based on this or to reject the mail outright. The checking software MAY choose to mark the mail based on this or to reject the mail outright. In my view, the first two are the same but a RFC2119 purist may argue the first one is not standard compliance material "throw book in your face" enforcement stuff. We can get into the CAN vs MAY semantics game and suggest the CAN is the mechanical form of what is possible in the protocol, where as MAY may imply there is another lay of human level considerations and options, authorization permission based concept such as ON/OFF. So the CAN or can suggest the software SHOULD have in place the software capability to reject or accept+mark the SMTP transaction, and the MAY or may would suggest that none of it is enforceable per RFC2119 "Book in face" compliance. It could be presented as follows by the software engineer, programmer, GUI designer implementing this stuff: [X] Enable honoring HARD FAIL SPF results (o) Reject HARD FAIL results (_) Mark HARD FAIL results Note: [_] is a checkbox (on/off switch), (_) is a radio checkbox offering mutual exclusive optioms. So again, if we really want to go this deep into what it all means, then maybe we should: If we have a group that believe SPF receivers DO NOT REQUIRED to honor HARD FAIL publications, then I believe the sentence needs to be: The checking software MAY choose to mark the mail based on this or to reject the mail outright. I don't agree with it personally, but I can't argue one's justification for it. IMV, one should not call itself supportive of SPF if it doesn't want to honor the HARD FAIL, but again, if we want to get picky, how it was written in 4408 with lower case can, to me, as an software engineer suggest the compliant protocol software MUST have the option to do both. At the end of the day, what are we offering the protocol implementation, is one, two or three options? What additional doubt are we adding here? The checking software MAY choose to mark the mail based on this or to reject the mail outright, but it NOT REQUIRED to honor the hard fail and therefore the DOMAINS should not expect it to be either rejected or marked. Anyway, I plan later to provide my text version that basically clarifies what the receiver responsibility here either with REJECT or MARK. Despite if the receiver does either, SPFBIS should be very clear what is the expected protocol for each. My only real original point is that a reject is a very powerful actiom and of acception + mark is done, stream separation SHOULD be in place. With the 04/05 change done, I am suggestion just make it clear in 2.5.4 where the options are mentioned, RFC2119 defined for one (reject), left open-ended for the marking option. -- HLS From superuser@gmail.com Mon Aug 20 10:29:54 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 0004821F8678 for ; Mon, 20 Aug 2012 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjIzkER8WY35 for ; Mon, 20 Aug 2012 10:29:53 -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 3476121F861A for ; Mon, 20 Aug 2012 10:29:53 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3626334lbb.31 for ; Mon, 20 Aug 2012 10:29:52 -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=ookdgtcSMGnaZrWLngo2fDlLLH6D54mTR+SB/QZtU/8=; b=g11cRI5Ea+9TflB5GbgXF3HzGELygr2mz5yV0ttXuDqZT909uSrNNBLQVf53mg/2pR yEsq4ycmJu2Cc0Q4y28UgUjd9TYSB852MvMJsaYnv3Gwr8Af4gD8r+TCQj27B04C2t48 TS8ZhATH83T45E2AbX22nWN89wRTbas29WiBRFE/WZIrQvJDpD5w8GXvUVof3ddPkRW6 t5naRitzVKpZeZWyjZW1Dbq/ALBhEQl/I+Ob5JoJoN0abdRbtMx5TxVXAb1zIHgnlZ2o EkbII1qfvkKFtCu+UKXJG/iM/Q9fw9SdNBlP8pfVkpBNsq8UHvZmYHrxvO638joFuIRJ rNeg== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr14568192lab.25.1345483792082; Mon, 20 Aug 2012 10:29:52 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 10:29:51 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120820082447.0af4e268@resistor.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> Date: Mon, 20 Aug 2012 10:29:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] SMTP level rejection (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 17:29:54 -0000 On Mon, Aug 20, 2012 at 8:41 AM, S Moonesamy wrote: > This is the text from RFC 4408: > > 'A "Fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity. The checking > software can choose to mark the mail based on this or to reject the > mail outright. > > If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 (see > [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification > (DSN) code (see [RFC3464]), in addition to an appropriate reply text.' > > My reading of the above is that there isn't any RFC 2119 [1] requirement or > RFC 2119 recommendation to do SMTP level rejection. Am I reading the text > incorrect? That's also how I read it. See also http://www.ietf.org/mail-archive/web/spfbis/current/msg01340.html. -MSK From superuser@gmail.com Mon Aug 20 10:31: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 59B2F21F861A for ; Mon, 20 Aug 2012 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hF+OmarBlbZ for ; Mon, 20 Aug 2012 10:31: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 964A021F85BB for ; Mon, 20 Aug 2012 10:31:05 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3627042lbb.31 for ; Mon, 20 Aug 2012 10:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A1aGQcXidGtWu2ofWLV+XhRtcDT65RAqZUpREP4LjZI=; b=wFbv9zkMvpRXF6ak7Bc46lQgwwKhX5MsBh6Q3QjHSGuQkGKCJwnBgZ21TGHEE3Rxy9 8DLAyNpGYHkkHiFdqqMmeZzU0MxsAmxmjtU476kY+8U2uyxyUUWGVuR5eZtVHcgX/qPf cQGlsf7TP5s86itytJgG/+f8MVAUG9Tv5RqEjwhveq2NPjtm8pznMNSncQOesGIhAGx+ CA/3mknHV5zzQQETes/iOaY3AkIFLeE6ExIMLTT1YmsfpNhbO2aWa/wBUKal86WUG4g9 Nkhu1gjdOuhtmZ8FcPvh7kud/R+J0d92p2wQ7MtRYig3kcCUEYklG2IsGJWqMm/NXdRn Uh5g== MIME-Version: 1.0 Received: by 10.112.29.131 with SMTP id k3mr6572079lbh.53.1345483864433; Mon, 20 Aug 2012 10:31:04 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 10:31:04 -0700 (PDT) In-Reply-To: <1345478096.96088.YahooMailClassic@web125401.mail.ne1.yahoo.com> References: <1345478096.96088.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Mon, 20 Aug 2012 10:31:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Are "unknown modifiers" ever used? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 17:31:06 -0000 On Mon, Aug 20, 2012 at 8:54 AM, Arthur Thisell wrote= : > Pardon my ignorance, I have done a very poor job keeping up on this list,= but has there been any discussion about "unknown modifiers"? Are they ac= tually used by anyone, or are they misspellings of redirect=3D/exp=3D? > > For those that don't know about them, RFC4408 didn't allow new/unknown me= chanisms to be added, but did allow future expansion via new/unknown modifi= ers. The idea was that you could create an SPF record that said "v=3Dspf1= dkim=3Dalways", as your sender policy, and SPF would become the accepted s= ender policy framework. To the best of my knowledge, no one ever used thi= s feature and I suspect it reduces the reliability of SPF records by allow = typos such as redir=3D to be silently ignored. There was one proposed when this working group was chartered, but we opted to remove it from the charter for the sake of simplicity through the first round. That's the only one of which I am aware. -MSK From superuser@gmail.com Mon Aug 20 10:44: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 388D421F8559 for ; Mon, 20 Aug 2012 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxPiZBl1zXWs for ; Mon, 20 Aug 2012 10:44:19 -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 445BB21F8557 for ; Mon, 20 Aug 2012 10:44:19 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3634369lbb.31 for ; Mon, 20 Aug 2012 10:44:17 -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=sdM45PBre6+ofRBsoROXwPQtweOLiyP17+8fXA0bVpk=; b=r2EhsMoYAHAdUzCASrU+Pb+Mh3OuPuJLKMSiZYE7/+0AhJo9mYZH50PtaAWN5uYLQ7 /0MbwCOa+Atw/lp/eyIbyBmkKdvvO2BFeIpP0/C5amhG+T8vzG1TRFavwEmPsG/2mba5 d5RLwmcGfj813wyF2oNbcYupRCYxdKKX49uQHqs7VoMcpUeM54NsVsfXk+WhsJdpvX99 9UvrueFXBmiIdia/Qyz5KmbOB/XmojpBoJNKjWZe8eg84TRw7u6jWmEg38c52tX/BxBw 3af/feE9WA88b4UcV/cScEYXBuwaOQhMDz0yX6VWyEWdJUW4PXG2L/FOTl9gpTBvl8X3 k2/Q== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr14643377lab.10.1345484657868; Mon, 20 Aug 2012 10:44:17 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 10:44:17 -0700 (PDT) In-Reply-To: <5032699F.1070104@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> Date: Mon, 20 Aug 2012 10:44:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 17:44:20 -0000 On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >> If there's no SPF result there can be no SPF related policy, so I don't see a >> need for a change. > > Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted > is from Section 2.5.5 (softfail). The question is why is the latter > normative while the advice for "fail" is not. Interesting point. I think what's there is fine, actually. That's based on the fact that DKIM (Section 6.1 of RFC6376) does what we're doing here; things that fail SHOULD NOT get negative treatment to a message because of the known failure modes. In effect, this applies not only to "softfail" but also to what we're calling the "mark" option of "fail". >> I think that's up to local policy/an implementation detail. HELO/EHLO can >> change during a session, so it's not axiomatic that one should. > > Thus, a receiver may reject whichever command it likes. That's fine > for me. However, from the second paragraph onward, the text of > Section 2.5.4 is written assuming that the failed identity is MAIL > FROM. (I partially retract the "+1" I gave on > http://www.ietf.org/mail-archive/web/spfbis/current/msg01844.html ) So change "during the SMTP transaction" to "via the SMTP session"? Or "dialog" instead of "session"? Then it doesn't matter whether you're inside a transaction or not (meaning it applies to HELO/EHLO or MAIL or RCPT equally). > Technically, "during the SMTP transaction" means that the transaction > has to be started, which is after the last HELO/EHLO command. Can we > say "before accepting the SMTP transaction" instead? Not quite. Sessions begin with HELO/EHLO; transactions begin with MAIL. -MSK From dhc@dcrocker.net Mon Aug 20 10:51: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 73BD821F8667 for ; Mon, 20 Aug 2012 10:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR9qSq2V02Uy for ; Mon, 20 Aug 2012 10:51:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5FCD21F866E for ; Mon, 20 Aug 2012 10:51:11 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7KHp9sA020788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Aug 2012 10:51:09 -0700 Message-ID: <5032790D.2090005@dcrocker.net> Date: Mon, 20 Aug 2012 10:51:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 20 Aug 2012 10:51:10 -0700 (PDT) Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:51:12 -0000 On 8/20/2012 10:44 AM, Murray S. Kucherawy wrote: > On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >>> If there's no SPF result there can be no SPF related policy, so I don't see a >>> need for a change. >> >> Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted >> is from Section 2.5.5 (softfail). The question is why is the latter >> normative while the advice for "fail" is not. > > Interesting point. > > I think what's there is fine, actually. That's based on the fact that > DKIM (Section 6.1 of RFC6376) does what we're doing here; things that > fail SHOULD NOT get negative treatment to a message because of the > known failure modes. In effect, this applies not only to "softfail" > but also to what we're calling the "mark" option of "fail". The asymmetry in handling failure vs. success, for these types of mechanisms, should come naturally from the questions: What do we know when there is success? What do we know when there is failure. Because failure can be due to many factors -- both malign and benign -- we know rather little when it happens. In contrast, we know quite a lot, when there is success. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Aug 20 11:06: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 73E4B21F866E for ; Mon, 20 Aug 2012 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDXU7rHGwtx0 for ; Mon, 20 Aug 2012 11:06:31 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E485E21F861A for ; Mon, 20 Aug 2012 11:06:30 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9899A8A031 for ; Mon, 20 Aug 2012 18:06:29 +0000 (UTC) Date: Mon, 20 Aug 2012 14:06:38 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120820180638.GD29830@mx1.yitter.info> References: <89686312.gpFrOJr1G6@scott-latitude-e6320> <20120818193316.35320.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120818193316.35320.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] macros, threat or menace, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:06:31 -0000 No hat. On Sat, Aug 18, 2012 at 07:33:16PM -0000, John Levine wrote: > Before you say this is totally off the wall, look at the RNAME field > of the SOA RR, which has the same problem, the first component of the > name is a mailbox. I have seen people stick a dot in there using \. > which works in master files, but as far as I know not in resolver > libraries. Apparently the resolver libraries you used didn't read RFC 1035 when implementing (this is not surprising; a large number of them seem not to have done). See, for example, this text from 1035 section 5.1: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. This is about master files, which are "text files that contain RRs in text form." In the wire format, of course, the separator dot doesn't appear, so we don't have a problem distinguising "." on the wire from the others. > Since approximately nobody has noticed this before, it just confirms > that approximately nobody uses macros. Either that, or people's resolver libararies are somewhat better than you seem to think in coping with features of the DNS that have been there since day 1 (approximately the same text as I quote above is in RFC 883). > trying to nail down the right thing to do, just note that macros allow > hostile senders to inject arbitrary text into your DNS queries, so you > should defend against that. Note that I have no objection to text along those lines. I'd prefer "be prepared to deal with" instead of "defend against". I don't think that to be a substantive change, since it was something that was always possible. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Mon Aug 20 11:16: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 047AE21F84FD for ; Mon, 20 Aug 2012 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb1xsKkLMySm for ; Mon, 20 Aug 2012 11:16: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 4F07A21F84C4 for ; Mon, 20 Aug 2012 11:16:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.30]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7KIGg4h000854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 11:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345486614; bh=IJYGhY6rUURrqH9SHdFN7BY+Zgc+Pl31QhRCgcHk9u8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=WF99/S1gV1q4sI2E6of3JIibTQJffwtoqJiS9i8lnqDy0D40Qma+bw+g9e/rLxDvf qqads1DeiJ59ydK4yzss/3Xrdqfmlfu/xF3xwFcrgi5hTkYg4TAamaYPVPp8C7Wl7A BDqsgrBEwZjSwMuQzyEwO0KnV+6dBehS4xHdNm2k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345486614; i=@elandsys.com; bh=IJYGhY6rUURrqH9SHdFN7BY+Zgc+Pl31QhRCgcHk9u8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=H7l4BFc9fbJj2wTjBYd1upqUVzWhotZPT4kLG9lsY2qw8ACYR5UNjyVlhp+n80sOZ Lp4/FDeeSmSGPWRkGI82Rr7EEyyGyOzdRuo3TejKJC0FjBK5/ZuI6F/QzUUdSyUxYy Yixw19YxSjmqOaV9I9cSyIqvTPicAe96oSBKNM2Q= Message-Id: <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Aug 2012 11:12:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50326EA1.7030107@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] SMTP level rejection X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:16:57 -0000 At 10:06 20-08-2012, Hector Santos wrote: >We can really lost with rhetorical judo RFC2119 semantics games. I >prefer to design protocol software from an practical engineering >standpoint, but lets go ahead and play it out. There is nothing in a RFC which forces anyone to follow it. If anyone decides to follow a RFC it would help me if the person says so. If the person wants to cherry-pick what to follow, it is not for me to tell him or her to what to follow. This mailing list is used by the IETF SPFBIS working group to discuss about the IETF work on RFC 4408. I am ok if anyone does not like the IETF, the way it works or the way this working group works. I follow IETF process and practices as that is what I am tasked to do. >What it the difference in the following three sentences for the >SOFTWARE ENGINEER or his programmer writing the "checking software?" That is a question for the above-mentioned persons to determine. > The checking software can choose to mark the mail based on this or > to reject the mail outright. > > The checking software CAN choose to mark the mail based on this or > to reject the mail outright. > > The checking software MAY choose to mark the mail based on this or > to reject the mail outright. > >In my view, the first two are the same but a RFC2119 purist may >argue the first one is not standard compliance material "throw book >in your face" enforcement stuff. We can get into the CAN vs MAY >semantics game and suggest the CAN is the mechanical form of what is >possible in the protocol, where as MAY may imply there is another >lay of human level considerations and options, authorization >permission based concept such as ON/OFF. I do not do standard compliance on this mailing list. I am ok with RFC 2119 purist labels or any other label which people want to use as long as it does not give me cause to have to read a process BCP to the working group. I look at RFC 2119 key words in terms of interoperability. I do not see any interoperability problem here. >So the CAN or can suggest the software SHOULD have in place the >software capability to reject or accept+mark the SMTP transaction, >and the MAY or may would suggest that none of it is enforceable per >RFC2119 "Book in face" compliance. The above mentions compliance. I cannot comment about compliance. >If we have a group that believe SPF receivers DO NOT REQUIRED to >honor HARD FAIL publications, then I believe the sentence needs to be: > > The checking software MAY choose to mark the mail based on this or > to reject the mail outright. I do not see any explanation in terms of interoperability for the suggested text. I see a proposed change to RFC 4408. I will interpret it in IETF terms. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Mon Aug 20 11:26: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 A08E621F86D3 for ; Mon, 20 Aug 2012 11:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFPr5qdQK9lQ for ; Mon, 20 Aug 2012 11:26:21 -0700 (PDT) Received: from dkim.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 455D121F85FF for ; Mon, 20 Aug 2012 11:26:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3032; t=1345487169; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MVuBsphIC0afOCjFCY5HA93d75c=; b=ESpiPKUmOwK3M2wo078f 7JkyHv9jQFtiixna26y7fD6kwkC6G3n8nMbwvSIfLWzgUFhzMN/ftr0jUt5JBpN8 AzN9u6KxOqkdStDcO2oqblaEwwsULFrloNMmhA4gOSWegsJ/vbf364mt1yKamkjk sLCQTndY2YXDUVOY7aFhrNw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 14:26: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 1508968555.25431.620; Mon, 20 Aug 2012 14:26:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3032; t=1345486981; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=imJnqxA tjwuvpJAsS+4bNR4Xl6HdnQH6wUZ7MpZntgU=; b=N+cXl75aOMCA/7NOcM5F5+z WZId6SKXMDpEKa68HUHyQiSM/JvNw+KHGmjOuI57NyWTCoz6GRGs9gi3IIvFkiDi N0zWHbIEJliJ2WSTnemXjO2hz0nMwYaDwZL2QUAi/0vdSz67kYBb2uPY2+h8ZVOQ hBsVn8DyOMt5pQOVSylA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 14:23:01 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2107778942.7.4900; Mon, 20 Aug 2012 14:23:00 -0400 Message-ID: <50328147.2030409@isdg.net> Date: Mon, 20 Aug 2012 14:26:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> In-Reply-To: <5032699F.1070104@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:26:22 -0000 Alessandro Vesely wrote: >>> Not "In this case disposition is not a matter of local policy." >> If there's no SPF result there can be no SPF related policy, so I don't see a >> need for a change. > > Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted > is from Section 2.5.5 (softfail). The question is why is the latter > normative while the advice for "fail" is not. That depends on your view on lower case can vs upper case CAN in the sentence: The checking software can choose to mark the mail based on this or to reject the mail outright. Never mind this services no justice to the visually impaired or audio world without one reasons one's pitch, but semantically, there is only one practical meaning. Second, in rfc 4408, section 2.3, 2nd paragraph: If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made. This has a direct implication of what a domain expects a receiver to be doing with a -ALL, and for the protocol to work. Now I see rev 05, has: SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. To me, this reinforces properly protocol client/server design to make sure 2.5.4 is very clear about domains MUST rfc2119-level requirement to get a definitive negative result. That means REJECT must be clear (which is already is) and the alternative "mark the mail" MUST also be very clear and to result in a negative classification. That means "Spam box" and/or stream separation for the user level filter. I really do not like how SPFBIS is shaping into a deja-vu "DKIM" spec full of engineering doubt and too many cross section semantics confusing the reader, leaving items falling the RFC2119 and protocol cracks. Folks, SPF is not NEW! its 9 years OLD! Its well established and now is not the time to question's domains logic and reasoning for using -ALL. If the domain wants DOUBT, then it easily use ~ALL or ?ALL and it will get it 100%. But -ALL has a special meaning and also has been that way. What is surpising to me, and I'm not convince how much truth is there is that many implementations actually just do accept/mark rather than the reject for a -ALL result. We don't even know if that is mostly a result of SPF2.0 (SENDERID) support where the payloads is already accepted. As far as I am concern, a reject is the only RFC2119 item, while a accept/mark is open-ended, IMV it needs to be corrected to say the stream has to be separated or negatively classified from the POV of the end-user. -- HLS From superuser@gmail.com Mon Aug 20 11:37:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62F721F8673 for ; Mon, 20 Aug 2012 11:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag68IZKMutq6 for ; Mon, 20 Aug 2012 11:37: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 EAE2E21F854B for ; Mon, 20 Aug 2012 11:37:04 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3663437lbb.31 for ; Mon, 20 Aug 2012 11:37:03 -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=xyHCqzdx3uV31HFeFMA4BwKNWFcSdmh5FgpiAKd561M=; b=YrjHa873rKZmw5R4tUyN0u/bx0h7Or42dYZFThSsigBDiJo/2hCn/6G6V2WNTamycR VYz+yV1SLZh/oUblIdXjBSdGnyf4jWMzzyhjMn4AmWJCZjjppePo9I6db8P5UYcLcLaL CKrqjveYLU8LOUwnUW9WkQ2R3AQ/9W+dDlCpVAGk74pLsEVHQgUvRhjmvIdSHGY+LoqR EUnyNdHHGLGcAuu2h1x0azSpHDQYKrGQrfBr79H0thgcwHANyOayVcVA5+iwKojQ2459 Y1SSOoDc70NpW+XSFKrjkekCLo6/o8JK1Xj6MAJBeJLZ11hdg4tobXFSzuPh9A9bsNmX x8dA== MIME-Version: 1.0 Received: by 10.112.28.4 with SMTP id x4mr1422234lbg.105.1345487823735; Mon, 20 Aug 2012 11:37:03 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 11:37:03 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> Date: Mon, 20 Aug 2012 11:37:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] SMTP level rejection X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:37:05 -0000 On Mon, Aug 20, 2012 at 11:12 AM, S Moonesamy wrote: >> What it the difference in the following three sentences for the SOFTWARE >> ENGINEER or his programmer writing the "checking software?" > > That is a question for the above-mentioned persons to determine. Since you asked: >> The checking software can choose to mark the mail based on this or >> to reject the mail outright. >> >> The checking software CAN choose to mark the mail based on this or >> to reject the mail outright. >> >> The checking software MAY choose to mark the mail based on this or >> to reject the mail outright. Those three things are synonymous to me. Furthermore, "CAN" isn't an RFC2119 word, so capitalizing it just looks strange to me. > I do not do standard compliance on this mailing list. I am ok with RFC 2119 > purist labels or any other label which people want to use as long as it does > not give me cause to have to read a process BCP to the working group. I > look at RFC 2119 key words in terms of interoperability. I do not see any > interoperability problem here. +1. >> If we have a group that believe SPF receivers DO NOT REQUIRED to honor >> HARD FAIL publications, then I believe the sentence needs to be: >> >> The checking software MAY choose to mark the mail based on this or >> to reject the mail outright. > > I do not see any explanation in terms of interoperability for the suggested > text. I see a proposed change to RFC 4408. I will interpret it in IETF > terms. Moreover, the proposed change introduces no clarification or new ideas, so I don't see the point. It already says that. -MSK From hsantos@isdg.net Mon Aug 20 11:57: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 8F6F821F855A for ; Mon, 20 Aug 2012 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.09 X-Spam-Level: X-Spam-Status: No, score=-102.09 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoVF+scg9nKd for ; Mon, 20 Aug 2012 11:57:27 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A9DE121F8559 for ; Mon, 20 Aug 2012 11:57:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1455; t=1345489039; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vCy4PX5feWPLvvUO52qjYAGO1O4=; b=pMZZDi+YZ5p3pK65iOoN b4qCyeubouxwhfftJJkJNRmXjyY+fZb+UH3wJ8JQWqjICTcV2VcVAHe0IaeKZo3h xJM7vW9z0RrPhbNU76TvNk4BxR/0dr1oSJWNqmrIBI/7avrfJoc6Iozkg/K+IIWl NwTDjsVQS0fQ5GKSzj8FsWk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 14:57:19 -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 1510838664.25431.3180; Mon, 20 Aug 2012 14:57:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1455; t=1345488851; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ExGSVG1 hYr+sx7l2mzNybINIahQZHV9N3XhPzC3hRr0=; b=npX7LA2ufRb0ho+BIHUC6pq VD592Ara2TyVT6dDV+trmgG6Rtb57UUMAdMOzoXmJJlvJhZDF5RTJg63KjrR9j5O 7PKgcCbTvQvrPKLuy8ESMQ4d/cIFUiazqJVKHz2mcPKZ0lHDLp+TysTsqrIzz72Q Eh6uobGuyKx4TLKIFp+k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 14:54:11 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2109648849.7.5732; Mon, 20 Aug 2012 14:54:10 -0400 Message-ID: <50328895.8060906@isdg.net> Date: Mon, 20 Aug 2012 14:57:25 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: S Moonesamy Subject: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:57:28 -0000 Murray S. Kucherawy wrote: > Those three things are synonymous to me. > > Furthermore, "CAN" isn't an RFC2119 word, so capitalizing it just > looks strange to me. One may argue or suggest, and have, that "CAN" and "can" are in the same boat "may" vs "MAY" have also been argued, as well as SHOULD vs should. So want it implied, others like to see specifics. To me? The protocol engineering speaks for itself. >> I do not do standard compliance on this mailing list. I am ok with RFC 2119 >> purist labels or any other label which people want to use as long as it does >> not give me cause to have to read a process BCP to the working group. I >> look at RFC 2119 key words in terms of interoperability. I do not see any >> interoperability problem here. > > +1. Then we have a BUG conflict between section 2.3 with a very strong RFC2119 language regarding DOMAIN expectation for a -ALL to translate to a negative classification where in 2.5.4, based on what is begin stated we have three options: (o) DO NOT SUPPORT HARD FAIL RESULTS (_) REJECT HARD FAIL (_) ACCEPT and MARK HARD FAIL (By the way, what is the default?) The point is, depending on how one reads the new 2.3, 2.5.4 with 9.3.2, we raised doubt, and lowered the effectiveness of the SPF -ALL policy. > Moreover, the proposed change introduces no clarification or new > ideas, so I don't see the point. It already says that. See above. -- HLS From hsantos@isdg.net Mon Aug 20 12:12:29 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 B45A521F84E4 for ; Mon, 20 Aug 2012 12:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA-Bd3+50LEw for ; Mon, 20 Aug 2012 12:12:29 -0700 (PDT) Received: from ftp.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C625021F84CF for ; Mon, 20 Aug 2012 12:12:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2296; t=1345489939; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=e/laH0QiH6Sjvw1Ibe/dZz87DlU=; b=pOzU5JucEoqax5cYMUpx a9ioQC3IJq29/jDZLXrk4AQmoqKocS/X7qDp3PH2Y9fcWqGD+sHgPHtxKLs8xio/ wEPhBxgXbGh1BetvV0XfeiL6atJq77KU7iJ1Lot5XkFr0xlUjB7cucOwDJM/P9Dx rUfHXpRiwpkbBrpknVbL08k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 15:12:19 -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 1511738914.25431.3132; Mon, 20 Aug 2012 15:12:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2296; t=1345489750; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=99G/8AX uCZfEwbmSHKwqmDDwo4hm0h6V8qGEWUjYVao=; b=pROz0S9zDDo0BYZcDW8gIwj HrY9Mlz3x5EwIvY9yU2OJml7ZyEwHk44eSNc3xEshPqYagIiqBwYvhKhhiGg3ekH qPtIIWY7KoH6HZRPs1J/ndSlyMeCszLScD4rf0EfsdGW/i8nwfYYf48GnzR9kxCi fnBSTuC20yevPPPq8o54= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 15:09:10 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2110547817.7.5116; Mon, 20 Aug 2012 15:09:09 -0400 Message-ID: <50328C18.1020402@isdg.net> Date: Mon, 20 Aug 2012 15:12:24 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <5032790D.2090005@dcrocker.net> In-Reply-To: <5032790D.2090005@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alessandro Vesely Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 19:12:29 -0000 Dave Crocker wrote: > On 8/20/2012 10:44 AM, Murray S. Kucherawy wrote: >> On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >>>> If there's no SPF result there can be no SPF related policy, so I don't see a >>>> need for a change. >>> Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted >>> is from Section 2.5.5 (softfail). The question is why is the latter >>> normative while the advice for "fail" is not. >> Interesting point. >> >> I think what's there is fine, actually. That's based on the fact that >> DKIM (Section 6.1 of RFC6376) does what we're doing here; things that >> fail SHOULD NOT get negative treatment to a message because of the >> known failure modes. In effect, this applies not only to "softfail" >> but also to what we're calling the "mark" option of "fail". > > > The asymmetry in handling failure vs. success, for these types of > mechanisms, should come naturally from the questions: > > What do we know when there is success? > > What do we know when there is failure. > > Because failure can be due to many factors -- both malign and benign -- > we know rather little when it happens. > > In contrast, we know quite a lot, when there is success. > > d/ > Dave, you should take into account many system engineers, especially those with experience in the unit ops world (like chemical, process, industrial engineers), have deep training in optimization, fault detection, dissemination of detectable errors, faults and spoofs as can be provided with strong domain policies like SPF before you can get a steady state stream of "good" material. Section 2.3 in RFC4408 provide well understood strong RFC2119 language regarding the strong exclusive -ALL policy and the high payoff expectation it provides for query dissemination optimization concepts. It works so well, its scary to many. Take into account that receivers do see many spoofs attempted on their own local mail on their own system. I suspect as a well to make it look like its a local client. SPF provide the highest benefit for local domain or locally hosted domain protection at the receiver. The overhead begins when SPF receivers begins to attempt to provide this protection to remote domains. -- HLS From ajs@anvilwalrusden.com Mon Aug 20 13:05: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 C49E211E808E for ; Mon, 20 Aug 2012 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfqw1lgIjyht for ; Mon, 20 Aug 2012 13:05:38 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF411E808A for ; Mon, 20 Aug 2012 13:05:38 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 62BB18A031 for ; Mon, 20 Aug 2012 20:05:37 +0000 (UTC) Date: Mon, 20 Aug 2012 16:05:46 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120820200545.GH29830@mx1.yitter.info> References: <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50328895.8060906@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:05:38 -0000 Dear colleagues Procedural hat. On Mon, Aug 20, 2012 at 02:57:25PM -0400, Hector Santos wrote: > One may argue or suggest, and have, that "CAN" and "can" are in the > same boat "may" vs "MAY" have also been argued No, they're not. MAY and other 2119 friends are reasonably well-defined and widely accepted within the community. CAN is a novel use. Given our charter, we are certainly not going to be innovators in the area of standards level words. We shall stick to 2119, please. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Aug 20 13:13: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 A910C21F8568 for ; Mon, 20 Aug 2012 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQy7BxGDs8rv for ; Mon, 20 Aug 2012 13:13:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68521F8566 for ; Mon, 20 Aug 2012 13:13:20 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B6CE78A031 for ; Mon, 20 Aug 2012 20:13:19 +0000 (UTC) Date: Mon, 20 Aug 2012 16:13:28 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120820201328.GI29830@mx1.yitter.info> References: <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <20120820200545.GH29830@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120820200545.GH29830@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:13:26 -0000 By the way, "STTN" expands to "Stop This Thread Now." Sorry for failing to expand on first use. On Mon, Aug 20, 2012 at 04:05:46PM -0400, Andrew Sullivan wrote: > Dear colleagues > > Procedural hat. > > On Mon, Aug 20, 2012 at 02:57:25PM -0400, Hector Santos wrote: > > > One may argue or suggest, and have, that "CAN" and "can" are in the > > same boat "may" vs "MAY" have also been argued > > No, they're not. > > MAY and other 2119 friends are reasonably well-defined and widely > accepted within the community. CAN is a novel use. Given our > charter, we are certainly not going to be innovators in the area of > standards level words. > > We shall stick to 2119, please. > > Thanks, > > A > > -- Andrew Sullivan ajs@anvilwalrusden.com From presnick@qualcomm.com Mon Aug 20 13:16: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 B0F0921F8566 for ; Mon, 20 Aug 2012 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.298 X-Spam-Level: X-Spam-Status: No, score=-105.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDpCbJOWaCH6 for ; Mon, 20 Aug 2012 13:16:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id B03A621F843F for ; Mon, 20 Aug 2012 13:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1345493781; x=1377029781; 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=9jezNaS7iu+BLt3GX2/pzJJDQvX19AXIlVFCI8ynmjA=; b=JymiIE/IfnXxE5dT+1T4uB+AqjyLFBSTs/LOS2FmmBw19OoXZNLH3bw9 p8zlxUfP5gmrHjwmbTWsILDZT+N68NSGH0FsodBgJerSg08Hmhr6uozW5 G0Ewbu2izhANZF0P1k6jJfixEmYsdpinHcAfQD2LezD3QPKgjKv7LvYIu Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="227362974" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2012 13:16:21 -0700 X-IronPort-AV: E=Sophos;i="4.77,798,1336374000"; d="scan'208";a="315801857" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2012 13:16:21 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 20 Aug 2012 13:16:19 -0700 Message-ID: <50329B11.7030405@qualcomm.com> Date: Mon, 20 Aug 2012 15:16:17 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Dave Crocker , "Murray S. Kucherawy" , John R Levine References: <501AD4B3.4030505@bbiw.net> In-Reply-To: <501AD4B3.4030505@bbiw.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: SPFbis WG , SM , Andrew Sullivan Subject: Re: [spfbis] Appeal of SPFbis WG charter interpretation by wg chairs X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:16:22 -0000 [To the SPFBIS WG, cc'ed on this message: During the IETF meeting, I received a formal appeal of the chairs' interpretation of the charter, specifically regarding the removal of "unused" features. I want the WG to understand that this is a normal (albeit thankfully infrequent) part of our process. As it says in RFC 2026: Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved, however there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion. Indeed, in this case, I had spoken informally to both the chairs and the appellants prior to the appeal being filed, asking that the chairs make an explicit and final call on their interpretation and asked the appellants respond to that final call by writing an appeal to me if they disagreed with it. Everyone involved thought this was a good idea; it avoided the WG "rat-holing" on what is entirely a process point, and it allowed everyone to get their thoughts written up in clear text so that we could figure out the right path forward. In fact, I think the process point raised in this appeal is an important one, and one for which there is a reasonable interpretation on both sides. I think using the appeal process was exactly the right thing to do in this case and I thank both the chairs and the appellants for handling this in a professional and personally agreeable manner. This message is a reply to that appeal (which I have included in its entirety below). By the way: I had intended to publish the appeal itself to the mailing list much sooner. However, a bout of illness -- just a nasty cold -- and a broken primary computer caused me to be behind, getting me into the "I'm almost done with the reply; I'll just post it all together" cycle. I apologize for the delay.] Dave, Murray, and John, I have considered the appeal you sent 2 August 2012 regarding the WG chairs' (Andrew and SM) interpretation of the SPFBIS WG charter regarding the removal of "unused" features in the SPF protocol as it was moved from it's current Experimental document to the WG's Standards Track document. I have reviewed discussions from the WG mailing list archive, my archive of IESG messages, and messages I received privately in order to suss out the the intention of the participants and IESG as to the meaning of the charter text as well as the technical and procedural merit of choosing a path different from that of the chairs' decision. In summary: There was no obvious decision for me to make on this appeal, but I have concluded that the chairs' decision was the most reasonable interpretation of the charter text and that any problems associated with that interpretation can be safely addressed after work completes on the present draft. I therefore deny the appeal. Details: This appeal comes down to the basic question: What was the intention of the charter with regard to the words "unused features" and "existing features that are in current use"? Though the appeal does indicate generally that there might be negative consequences to leaving certain particular features in the protocol (i.e., that such features might not be able to be removed through future work because we have a history of leaving such things in and that we would end up with a Proposed Standard protocol potentially with items which are "known to be a bad idea"), I was not asked to consider the particular technical choices of the WG or the chairs. That is, even though I know that two features in particular, the PTR feature and the local-part macro feature, are what drove this particular appeal, you have not asked me to make a particular call on those features. Rather, I was asked the more procedural question of interpretation. I think this is fine: If another feature is discovered with similar circumstances, we would want the answer to the general question to be answered. I reviewed mail from the SPFBIS mailing list, from the IESG, and personal correspondence. The SPFBIS mailing list archive is not at all clear to me with regard to intention. You and the chairs are correct that the general attitude was to make the "barest minimum of changes", which I admittedly took to include being as conservative as possible in the removal of features. However, you are also correct that the discussion was almost entirely centered around not having *additional* features added. There are some early notes that indicate Murray's belief that the charter was intended to "prevent rat-holing on any of the contentious stuff" and that there was no need to worry about "fundamental changes to the SPF protocol" because "the charter specifically proscribes these" . However, Murray provides us with no direct language about the intention of "unused". Dave did state his intention pretty clearly , though this view was not universally affirmed in the messages that replied to his. Meanwhile, as you point out in footnote [2] of your appeal, Doug Otis did bring up the topic of the local-part macro feature during the "SPFis WG scope" discussion , and discussion continued on that topic into the beginning of January. At that time, Alessandro Vesely said in one post , "The current charter does not allow us to ban local macros...", indicating his view was that the charter prohibited removal of the feature. More recently, messages have indicated that at least some of the participants understanding of the intent was different. (For example, see this message from Scott Kitterman: .) So from the participants in the original discussion on the list, I can't come to a definitive conclusion regarding intent. However, on the IESG list, the issue of "unused features" was specifically asked about. On 27 December 2011 (after the original charter text had gone out for IETF Review), Doug Otis had sent a message to the IESG list, reflecting concerns noted above regarding the local-part macros. Stephen Farrell replied that day, in part (quoted with his permission): I do wonder if the charter here should explicitly either a) allow removal of SPF features with the aim of improving overall DoS resistance, or b) exclude discussion of this issue [...] Deciding to include or exclude this while forming the SPFbis WG might in any case be a good plan (take the pain once up front, rather than having to fight the battle loads of times if the charter isn't explicit). Discussion of this point took place on the 5 January 2012 IESG telechat . My commentary there was: Pete R: There's also the comment from Doug Otis about the local-part macro. I'm inclined to declare that out of scope, maybe after a recharter. That's not documenting current practice, but is an overt change. Subsequently, on 1 February 2012, I distributed a new version of the charter to the IESG and the SPFBIS list with some additional text that I and (I believe) the IESG intended to address this specific issue: [Specifically out-of-scope for this working group:] * Removal of existing features that are in current use. Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group. Note especially that until this point (and particularly, after the discussion I cited above that conveyed people's intentions), the above text did not appear in the charter. And here, unfortunately, was the breakdown in communication: I never explicitly said to the list why the changes were put in, and nobody on the list ever asked about the changes, let alone commenting on them or their intent. A failure on all of our parts, no doubt. But that leaves me with the history of the list not having a clear intent on the particular point, and the history of the IESG having a more clear intent. So far, that leaves me leaning toward the stricter interpretation that I believe the IESG had, and that the chairs stated in their message on the list. During discussions of this appeal with the appellants, it was pointed out that people might have had the impression that the criteria for removal of features would be similar to what occurs when a document moves along the standards track (Proposed Standard to Draft Standard as described in 2026, or Proposed Standard to Internet Standard as described in 6410). However, neither document is terribly enlightening on this point, and in fact lends credence to the argument that extremely minimal use is sufficient to call something "used". In 2026, section 4.1.2: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. That is, if there are simply *two* independent interoperable implementations of a given feature, that is enough to leave the feature in. In 6410, section 2.2, it says that a document may advance if: (3) There are no unused features in the specification that greatly increase implementation complexity. Here, features are allowed to remain even if they are completely unused, so long as complexity is not greatly increased. Neither 2026 nor 6410 give criteria for what features *may* be removed, but there is certainly no requirement that features that are "almost totally unused" be removed. Given all this, I conclude that it is perfectly reasonable to interpret the charter as meaning that the barest minimum of use is enough to leave a feature in, and that the intent of all involved is either inconclusive or leans a bit toward this barest minimum interpretation. As I said above, this was a failure of communication all around, and we need make sure that our intentions are clear in the charters we write in the future. Unfortunately, all parties relied on "special knowledge" of the meanings of the words we used (folks assuming that when we said "unused" it was a special meaning that would be understood by all, when in fact each group had a different meaning in mind), and we need to be more explicit in the future. That leaves the question of whether it is reasonable or problematic to expect the WG to complete work on simply moving the protocol from Experimental to Proposed Standard and only then re-chartering to take on more controversial subjects like the removal or addition of features. You make two arguments for tackling the work of removing features now: 1. The IETF (among others) is historically unsuccessful at delaying known work to the future, and leaving such work for the future creates an "unstable market". 2. Leaving a feature in that is either a known bad idea or is relatively unused and complex would not stand review scrutiny for a Proposed Standard document. I find the first argument completely unconvincing. First of all, we have many examples of charters that have future work delayed (though admittedly most of these are extensions rather than deletions), and they deploy successfully. The idea of an "unstable market" might hold a bit more weight for me if it weren't the case that the market is already quite stable in the case of SPF: There are many deployments that already have the features in question and no signs that such deployments are obviously problematic. I see no evidence that this delay in removal of this feature (if that is what is eventually decided) is going to have a significant impact on the deployment of this protocol, let alone "kill" the effort. (In response to your footnote regarding the new standards track with its reduction in number of maturity levels, I simply disagree with the analysis. The problem such a reduction addressed was *not* that Proposed Standards were always completely embedded in stone. Indeed, we continue to have incremental development and deployment as old Proposed Standards get replaced by new Proposed Standards, as 6410 rightly points out. The problem, I would argue, was that we had no incentive to document -- to the extent required by 2026 -- when a protocol had actually stabilized, and the new one-step advancement lowers the bar to declare something as having stabilized. I think we can, and do, continue to do reasonable incremental development and deployment.) As to the second argument, I believe discussion has been curtailed on the merits of whether any of the features in question are "known bad ideas" or whether the complexity of the features in question is problematic. Indeed, as you state in footnote [2] below, whether there is an actual security problem with one of the features is "unverified", and as far as I can tell, the claim was at best controversial. So I think the IESG would have little room to claim that the feature should be removed on "known bad idea" or "security" grounds. Furthermore, I believe that from the above analysis of the intent of the charter, it is clear that the IESG did not desire the WG to do extensive analysis where such claims were not immediately obvious to the WG as "errors"; instead, the intention was to move the document properly to the standards track, with change control moving to the IETF proper, and then undertaking discussion of controversial topics at a later date. (On two smaller statements: My conclusion is that this is not a "usual bis effort", as you put it below, in that the publication of the original protocol as Experimental was far from usual, and moving it into the standards track is equivalently not the normal such effort. Furthermore, though the number of implementations and sites using the features in question is quite small, it is entirely hyperbole to claim that this constitutes "that a single implementation has veto power over feature removal.") In denying this appeal, I am willing to ask the IESG for clarification, making absolutely explicit in the charter the desire to leave these sorts of features in the protocol. However, I will refrain from bringing this to the IESG in case you wish to appeal my decision to the IESG as a whole. I would ask that discussion of this decision be kept off of the sbfbis mailing list, as I'm afraid it will be a distraction to other work. If folks would like me to set up a mailing list for discussion, I'm happy to do so. Pete Resnick Applications Area Director for SPFBIS On 8/2/12 2:27 PM, Dave Crocker wrote: > To: Pete Resnick / cognizant area director > From: Dave Crocker, Murray Kucherawy, John Levine > > Pete, > > { See below for notes on the distribution of this memo. [1] } > > RFC 2026: > >> 6.5.1 Working Group Disputes > ... >> If the disagreement cannot be resolved in this way, any of the >> parties involved may bring it to the attention of the Area >> Director(s) for the area in which the Working Group is chartered. >> The Area Director(s) shall attempt to resolve the dispute. > > This is a formal appeal of the just-issued SPFbis working group > chairs' decision concerning scope of acceptable work: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02010.html > > Their interpretation of the charter does not match the intent of those > of us who wrote it. > > Alternative wording is offered for the charter, to ensure that the > protocol revision effort is determined by pragmatic concerns, rather > than nuances and vagaries of vocabulary interpretation and rather than > relying on hypothetical futures that expect rapid repetition of > protocol revisions. > > http://datatracker.ietf.org/wg/spfbis/charter/ > > The chairs have decided the charter's use of the word "unused" means > that certain items for possible removal from the specification are out > of scope, since their usage is merely "extremely low" rather than > "zero". In this case "extremely low" has been empirically measured as > somewhere between zero and 0.5% of the large installed base for global > Internet mail infrastructure. > > The chairs' interpretation has blocked discussions that could simplify > the protocol and its implementation, as well as improve its > interoperability. > > The formal note from the chairs, explaining their decision, > acknowledges that it runs contrary to normal IETF practice for 'bis' > efforts: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02010.html > >> We appreciate that this is not the way we as a community normally >> proceed when advancing a document on the standards track. > > However the latter sentences in that paragraph provide likely insight > to the foundation for the current problem: > >> At the >> time the WG was chartered, the aim was to move RFC 4408 to the >> standards track with the barest minimum of changes. This is why the >> charter says in more than one place that we're not allowed to change >> things that are in use. We are not moving a document along the >> standards track; we are converting from the experimental track to the >> standards track, and we want to do that with maximal backward >> compatibility. > > The issue is not whether your, their or our interpretations of the > word 'unused' is justified, but that the interpretations diverged. > > From recent discussions with you, we have learned that the chairs and > ADs had discussions about this extremely constrained interpretation of > the scope but did not pursue it with the rest of us who were active in > formulating the working group (and writing its charter). Our own > interpretation during the charter-writing process was for the more > typical constraint that permits judicious removals. > > To emphasize, none of the predicates quoted above were discussed on > the group's mailing list.[2] > > From the recent discussions it appears that your own expectation was > that this working group effort would be fairly quickly followed by > another that dealt with "substantive" changes. > > This represents problematic thinking on at least two axes. First, the > IETF -- and every other standards group -- has an extremely poor track > record when doing current work that is based on an expectation of > future work. Second, any plan to do additional revisions anytime soon > creates an unstable market: when the first round comes out, > implementers tend to delay adoption, waiting for the next round. Such > a rate of change has classically killed many standards efforts.[3] > > Rather than being subtle or clever, at least some of us who were > writing the actual charter text intended exactly the usual constraint > on changes. That is, protect the installed base while removing cruft. > > As cited in the above quoted text, apparently the background, > pre-chartering management discussions placed emphasis upon the SPF > specification's moving from Experimental to standards track, with the > view of having this justify deferring some technical concerns. That > is, planning for substantive changes to be made in a later revision > effort. However the idea of putting something on the standards track > that includes any (or both, in SPF's case) aspects known to be (a) a > bad idea, or (b) relatively unused complexity would typically be > expected to prompt an AD Discuss or vigorous SecDir criticism. > > In practical terms this was, again, a decision based on formalities > rather than pragmatism. And it certainly was/is not relevant to > some/most/all of us who are involved in the actual use of SPF. > > SPF is a deployed protocol. For more than six years, the global email > operations community has counted it as an essential tool in anti-abuse > efforts. > > The decision to first publish SPF as Experimental was entirely > reasonable at the time, in terms of IETF formalities. However it is > important to distinguish between those IETF-specific, institutional > formalities from the real-world pragmatics of protocol use and > maturity. That distinction appears to be missing in the current > working group management and its oversight. > > The SPFbis working group effort certainly does need to attend to > protection of the installed base, as the chairs and the rest of us > agree. However, as is usual for IETF 'bis' efforts on deployed, > successful protocol efforts, this does not automatically mean that a > single implementation has veto power over feature removal. > > In order to ensure that the charter is interpreted according to > criteria common for conservative 'bis' efforts, while still permitting > reasonable changes, here are suggestions for alternative text: > >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. > > should be changed to: > > Changes to the SPF specification will be limited to the removal > of features that have had no significant deployment, removal of > features that have caused serious interoperability problems, addition > of any enhancements that have already gained widespread support, > correction of any simple textual errors, and the addition of > clarifying language. > > and > >>> Specifically out-of-scope for this working group: > ... >>> * Removal of existing features that are in current use. > > should change the bullet to be: > > * Removal of existing features that have developed significant, > interoperable use. > > We look forward to timely resolution of this appeal so that the > working group can again attempt to refine SPFbis according to its > extensive field experience. > > > /Dave Crocker > /Murray Kucherawy > /John Levine > > [1] Although an appeal to the IESG is quite public, nothing in the > formal process requires that an appeal to an AD be circulated > publicly. In order to simplify the dynamics of this appeal, we are > sending it only to the ADs and Chairs. You may, of course, choose to > circulate it further, but we don't feel that that's necessary for our > purposes. If it happens that the charter changes recommended by the > appeal is approved by you, then that can be pursued purely as a > charter change, rather than an appeal, thereby avoiding the more > charged tone of an appeal. > > And since Pete and I discussed it, I'll note that I tried to > make the From: field contain all the authors of this appeal. Alas, > Thunderbird wouldn't let me... > > [2] The pre-chartering mailing list discussions that did take > place, with respect to issues that could be called "barest minimum of > changes", were actually focused on not /adding/ anything. That's > where most of the contention was. There was also some intent around > blocking an attempt to remove a specific feature, but that was because > the proposed removal was justified in terms of unverified security > concerns. What we discovered later is that, threat or not, it is > almost totally unused. That's a far stronger basis for removing > something as it advances in status, in our view. > > [3] In fact predicating improvements on the notion of a follow-up > revision draft appears to fly in the face of the recent IETF effort to > reduce the number of standards track maturity levels. The premise of > that work was realization that once something reaches Proposed > Standard, there is rarely industry interest in a further 'tuning' > exercise. In the face of that standards track formal change, it runs > contrary to have current work plan for a successive revision for SPF. -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From hsantos@isdg.net Mon Aug 20 13:29: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 4A58321F8598 for ; Mon, 20 Aug 2012 13:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBgVMnowiGfp for ; Mon, 20 Aug 2012 13:29:46 -0700 (PDT) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 64F9B21F8597 for ; Mon, 20 Aug 2012 13:29:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1657; t=1345494580; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bx1DqW+MzdwH2alEQCR5hSTpZaU=; b=sCmqE5jS2jMGdDgr58b9 VxgFuOiBkrPWOdfSH/FsMwm5VCjZVcGH5yB5QNM9olbukm7nl7wtpxkttcjdmg2K 0buqh7L3C04oNJh7aYCVFQm3QQhWb4XV2SoIN16+1wDvP+FH/fotedLByfbi0b1s pOHjQK4mtI/mEs+TjmMLKyw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 16:29:40 -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 1516379211.25431.5184; Mon, 20 Aug 2012 16:29:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1657; t=1345494393; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Nx+Wtub Vq0K4kX4Td4mvKjYvm3WN6r7gAyBBQ2uQXaw=; b=pWseeahxl5SrGCe0EXeXdyP k1UruIsEmOL9vT4i8Y+FUV9izbChXwh30qbD7aU+G14nXIxDFAW1hLJt+sqwC9WR zWGTDi9IS+B4jgzcw1Mg0cVTiPMd6+kSWy7t/h72N3JCt/Zf3Iv1IkdXLrrbdkEH iIjzohwD0nJuRBsKGWhc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 16:26: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 2115190833.7.2540; Mon, 20 Aug 2012 16:26:32 -0400 Message-ID: <50329E47.6010009@isdg.net> Date: Mon, 20 Aug 2012 16:29:59 -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: <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <20120820200545.GH29830@mx1.yitter.info> In-Reply-To: <20120820200545.GH29830@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:29:47 -0000 Andrew Sullivan wrote: > Dear colleagues > > Procedural hat. > > On Mon, Aug 20, 2012 at 02:57:25PM -0400, Hector Santos wrote: > >> One may argue or suggest, and have, that "CAN" and "can" are in the >> same boat "may" vs "MAY" have also been argued > > No, they're not. > > MAY and other 2119 friends are reasonably well-defined and widely > accepted within the community. CAN is a novel use. Given our > charter, we are certainly not going to be innovators in the area of > standards level words. > > We shall stick to 2119, please. So not sticking to 2119 is just the same as advocating a protocol design? RFC 4408 has: The checking software can choose to mark the mail based on this or to reject the mail outright. Which by your definition, the PROTOCOL has the compliance level or lack there of option to NOT mark NOR reject. We can argue this many ways and thats by sticking with 2119 sir. It means the technical specification is to design a protocol with a mutual exclusive option: (o) do not honor hard fail (_) honor using SMTP REJECT (RFC 2119 compliance) (_) honor using SMTP ACCEPT+RECEIVE-SPF We are presuming a "Mark" means adding RECEIVER-SPF header. If this is the case, then we have a RFC2119 conflict in 2.3 made even more pronounced in the rev 04/05 version which does have a 2119 MUST expectation for -ALL translating to a negative dissemination of the transaction. At some point, we need to end the rhetoric judo and just work with common since. Relying squaring on RFC2119 is fine, if you are consistent across the board and everyone is one board on what means what. -- HLS From spf2@kitterman.com Mon Aug 20 13: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 6D87621F8597 for ; Mon, 20 Aug 2012 13: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVzinYY0mfBg for ; Mon, 20 Aug 2012 13:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40321F8595 for ; Mon, 20 Aug 2012 13:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7C16920E411E; Mon, 20 Aug 2012 16:34:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345494858; bh=Vl3y6Sc1edIQmqS+DDG/Lp2eGwICsyork3NEID07ets=; h=From:To:Subject:Date:In-Reply-To:References:From; b=D53/9mmI6FoLKVQLwOJY5rduu2R3tO3kuxi/upe5NowEew3erMJrxxAfpdnPACY4o FDeVIY3lKJNsT9z5Xz7mro21pOiqh+dSye7tyex7FKiR19RVpoUKyYkhl8JqzU2gGT Xmk9uM5FYjt9UYjGLtkSpp2kRdXESZgOD/8bfMIg= Received: from scott-latitude-e6320.localnet (unknown [74.82.102.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 34C1620E410F; Mon, 20 Aug 2012 16:34:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Aug 2012 16:34:16 -0400 Message-ID: <2158340.7pKr411vxr@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1345478096.96088.YahooMailClassic@web125401.mail.ne1.yahoo.com> References: <1345478096.96088.YahooMailClassic@web125401.mail.ne1.yahoo.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] Are "unknown modifiers" ever used? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:34:20 -0000 On Monday, August 20, 2012 08:54:56 AM Arthur Thisell wrote: > Pardon my ignorance, I have done a very poor job keeping up on this list, > but has there been any discussion about "unknown modifiers"? Are they > actually used by anyone, or are they misspellings of redirect=/exp=? > > For those that don't know about them, RFC4408 didn't allow new/unknown > mechanisms to be added, but did allow future expansion via new/unknown > modifiers. The idea was that you could create an SPF record that said > "v=spf1 dkim=always", as your sender policy, and SPF would become the > accepted sender policy framework. To the best of my knowledge, no one > ever used this feature and I suspect it reduces the reliability of SPF > records by allow typos such as redir= to be silently ignored. Up until recently I would have agreed with you. However, thanks to RFC 6652 there is now an IANA registry for modifiers and the first new modifiers officially defined. Scott K From sm@resistor.net Mon Aug 20 13:36:02 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 F123821F8598 for ; Mon, 20 Aug 2012 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+Cx-QiwjAdb for ; Mon, 20 Aug 2012 13:36:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11A21F8597 for ; Mon, 20 Aug 2012 13:36:02 -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 q7KKZtln013753; Mon, 20 Aug 2012 13:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345494960; bh=KbRlOsTmnmJLwfoSpl6NM0RJ/shhnFcPSm4u6KTISGM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=VrDZUO1xIdIsVJOVh0QGCIK4HjUcR3LK9mkJ71peqvc9nRgaOm2qOoz8Z+Xyf5B/o duznR9mXIyqjqwYWhOZPPdmfUK1+Xj8B2PkpJyjySZgcrM02GVp5VOKj9qBVD17sVR XDAvpoewJiZhBqcVUEyY8+RyfWi6n+mM3vwbd6CI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345494960; i=@resistor.net; bh=KbRlOsTmnmJLwfoSpl6NM0RJ/shhnFcPSm4u6KTISGM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=YrKDjinTW3Wo4hSR9KTuSYTNAG2HfwXUPM9cJoOknU45aKeZNWaLr78FY+HWQ2Nsg C1nsBv/X3Sw4mjnNiYd8JvFYzrf3rAIq0WtEJcHYdrbPC8phiLL69J+hmBfeClP0Hn hYaa2jLWK2+yLQfBTfph9LIfVXtnSr29ghZbG2lU= Message-Id: <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Aug 2012 13:16:20 -0700 To: Hector Santos , spfbis@ietf.org From: SM In-Reply-To: <50328895.8060906@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:36:03 -0000 Hi Hector, At 11:57 20-08-2012, Hector Santos wrote: >One may argue or suggest, and have, that "CAN" and "can" are in the >same boat "may" vs "MAY" have also been argued, as well as SHOULD vs >should. So want it implied, others like to see specifics. To me? >The protocol engineering speaks for itself. There is a thread about the boat at http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html This topic has been a recurring in the IETF since a long time. >Then we have a BUG conflict between section 2.3 with a very strong >RFC2119 language regarding DOMAIN expectation for a -ALL to >translate to a negative classification where in 2.5.4, based on what >is begin stated we have three options: The problem with an error in a specification is that it generally translates into a software bug. Regards, -sm From spf2@kitterman.com Mon Aug 20 13:46:29 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 8283721F8606 for ; Mon, 20 Aug 2012 13:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOPARI4Izhzh for ; Mon, 20 Aug 2012 13:46:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6E21F85B4 for ; Mon, 20 Aug 2012 13:46:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 07D3C20E411E; Mon, 20 Aug 2012 16:46:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345495588; bh=wgPpUVKIIr09CeOPr9tj9BsnFhVRdvvki2IBJxa1cjo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZdOVdgPpcbekJUsGhZfWHsevlwWTOMKgIb0eynYgjevbn3T549WDdI931J2EDj2aQ I48QEQXtxeNfcrVavbnXIWpA37eCGoJBa5ZTu6yHRur8Mp9ls3d1mSWfzG2Ice+Mww bwoyNGIG5bmWHV5tRKcnHXVsQlAUWQBUUdq/CnQY= Received: from scott-latitude-e6320.localnet (unknown [74.82.102.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 98AAA20E410F; Mon, 20 Aug 2012 16:46:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Aug 2012 16:46:25 -0400 Message-ID: <2748008.To0uIurt7Z@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5032699F.1070104@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@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] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 20:46:29 -0000 On Monday, August 20, 2012 06:45:19 PM Alessandro Vesely wrote: > On Sat 18/Aug/2012 19:40:00 +0200 Scott Kitterman wrote: > > On Saturday, August 18, 2012 04:31:35 PM Alessandro Vesely wrote: > >> On Fri 17/Aug/2012 23:46:24 +0200 Murray S. Kucherawy wrote: > >>> I think the current text for "Fail" explains perfectly well that > >>> the option of what to do with the message is left to the receiver, > >>> as it should be. That's what "disposition" is. > >> > >> I beg to disagree. The current wording resembles a generic statement > >> > >> that receivers can do as they like: > >> Disposition of SPF fail messages is a matter of local policy. > > > > It does and it's correct. Receivers can do as they like. They don't get > > to decide how to determine if an SPF result is "fail", that is > > standardized, but once they have that result they get to decide what to > > do with it. > > > >> Does that mean local policy doesn't have a say in case the result is > >> "none"? In other 2.5.x sections we may want to say something like > >> > >> Section 2.5.5 does: > >> Receiving servers SHOULD NOT reject mail based solely on this > >> SPF result. > >> > >> Not "In this case disposition is not a matter of local policy." > > > > If there's no SPF result there can be no SPF related policy, so I don't > > see a need for a change. > > Well, "none" /is/ an SPF result, isn't it? The "SHOULD NOT" I quoted > is from Section 2.5.5 (softfail). The question is why is the latter > normative while the advice for "fail" is not. > > >>> I'm not liking the idea of identifying specific SMTP reply codes or > >>> enhanced status codes that should be used for SPF rejections. RFC3463 > >>> and RFC5321 already define those. We should leave that alone. If we > >>> want to give examples, that's fine, but I don't think we should be > >>> normative about it. > >> > >> +1! In addition, the current spec doesn't mention that a server may > >> want to decline a whole session as a result of a failed HELO check. > >> SHOULD a server reject each and every transaction instead? > > > > I think that's up to local policy/an implementation detail. HELO/EHLO can > > change during a session, so it's not axiomatic that one should. > > Thus, a receiver may reject whichever command it likes. That's fine > for me. However, from the second paragraph onward, the text of > Section 2.5.4 is written assuming that the failed identity is MAIL > FROM. (I partially retract the "+1" I gave on > http://www.ietf.org/mail-archive/web/spfbis/current/msg01844.html ) > > Technically, "during the SMTP transaction" means that the transaction > has to be started, which is after the last HELO/EHLO command. Can we > say "before accepting the SMTP transaction" instead? > > >> Although this was in RFC 4408 and not novel, the relevant SMTP text > >> was moved from Section 3.7 of RFC 2821 to its own Section 3.6.2 of RFC > >> 5321, where the "policy reasons" are further characterized by using > >> the term "SPF". Repeating normative parts introduces ambiguity as to > >> whether the two protocols overlap. > > > > Perhaps. I agree it's reasonably obvious what one should pick for the > > SMTP > > reply code. For enhanced status codes, it's much less clear. Reviewing > > http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced- > > status-codes.xml does not lead me to one obviously correct solution. I > > think providing additional specificity is useful. > > Yes, it is useful, but putting the codes in the example is clear > enough. That "SHOULD" is spurious. Besides, the description in the > page you cite, although not SPF-specific, is quite clear: > > X.7.1 Delivery not authorized, message refused > 451, 454, 502, 503, 533, 550, 551 > The sender is not authorized to send to the destination. > > Thus, we could say: > > The receiving server MAY reject messages using codes as specified > by SMTP ([RFC5321]) and, if supported, Enhanced Mail System Status > Codes ([RFC3463]). > > That way, we'd use normative language for the point pertaining to the > SPF protocol, while sparing it for what pertains to other standards. The problem with this is that the rationale is about the recipient and not the sender. Why would it be appropriate to pick x.7.1 over x.7.0: X.7.0 Other or undefined security status While the overall designation includes the word policy: X.7.XXX Security or Policy Status None of the X.7.? codes mention it at all (unlike 550). I don't think there is an obvious best choice and so I think that for consistency we recommend one that should be used. Scott K From superuser@gmail.com Mon Aug 20 14:15: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 BDAF221F8599 for ; Mon, 20 Aug 2012 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUQrBcPWOq5J for ; Mon, 20 Aug 2012 14:15:22 -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 D63E521F8597 for ; Mon, 20 Aug 2012 14:15:21 -0700 (PDT) Received: by lahm15 with SMTP id m15so3710713lah.31 for ; Mon, 20 Aug 2012 14:15:20 -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=51DnuUT3ro2sjKYTCJt06b7omdF7l+t9BtZ4wdGuv2A=; b=s2LuWtmyEv1577xYttHFYxWWbWNjJZ78muja6b3Ju0bFyU0ujulCUQ1RgH1gIXFzvt IYj4jPeAclkl+u5WhnhM/Xl2g3PQVTPDQoaGHymeVNNV3QgWcK2/6aHrqUhUPbVuNSiZ 7RWxPzj3GN1zn1Ma7h8nOiE2s2CrNVf5HRlqNmSbSuAgeVVwMaPIv5pyadRuAHQi4ws5 EcSf9Ax/kIej9VWYWMbXsEXTXb95Z4Vbzeuy2qj9fq/lDgqBfcJ9ej5aHUDsPPkaf03T ItqoVXElQVbIIMAytv0jJFIWl8uOzC/opclxdifj8jDWFCYR4gRVNW38IAiVfWwzrAZX 7TfQ== MIME-Version: 1.0 Received: by 10.112.39.41 with SMTP id m9mr6813779lbk.80.1345497320748; Mon, 20 Aug 2012 14:15:20 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 14:15:20 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> Date: Mon, 20 Aug 2012 14:15:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Hector Santos Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 21:15:22 -0000 On Mon, Aug 20, 2012 at 1:16 PM, SM wrote: >> Then we have a BUG conflict between section 2.3 with a very strong RFC2119 >> language regarding DOMAIN expectation for a -ALL to translate to a negative >> classification where in 2.5.4, based on what is begin stated we have three >> options: > > The problem with an error in a specification is that it generally translates > into a software bug. The current Section 2.3 text says, in essence: If you want to give receivers the ability to make a definite negative conclusion ("fail") about an incoming message, you have to use "-all". It says nothing whatsoever about what a receiver does upon reaching that conclusion. Section 2.5.4 then goes into detail about what choices a receiver has when a "fail" conclusion is reached. I don't see a conflict or "bug" here. They're complementary. -MSK From hsantos@isdg.net Mon Aug 20 14:20: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 733F911E808D for ; Mon, 20 Aug 2012 14:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTT3GJF4iovs for ; Mon, 20 Aug 2012 14:20:51 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCD11E8091 for ; Mon, 20 Aug 2012 14:20:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1546; t=1345497644; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zcTdI3koeMgcI8yU4JIY4AA0z+E=; b=NqfYKDfPZYP5Td7KCzYg njdciOxozSnbau7Uz0pW3w4Y5V2ZPr0FyZghKW/f1sz2n5QFlG29bNjnyderAWNs SrSrffO1RUJFlLq0fNvPRnIKhz6yaOclWGETKptW+b/xSKfbbDpK+w8HybGydUB1 pe3S0gxeU5xrJ2GT4f01Z/Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 17:20:44 -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 1519444474.25431.3420; Mon, 20 Aug 2012 17:20:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1546; t=1345497457; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CWxF/tC HGVDXBWLl672BC0vEPv/FB2UgDX1otx5xTMk=; b=vTgZUKcqJ+Ylln3Go1MPh9o IlUJ/TebGakwFGxsemL3s+A0Tjej0+a28Hf/DaKgZs1jTxXpaI8MtSCD9CEP4fqw 95+pxlF0hTpIgP02rNwT4q3GK3oprHoRI71ZnW6LYSRGt0fC+xPOv6cdr4V4vhop 8Q7JsLoGQotSKRJVOMrg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 17:17:37 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2118255130.7.6804; Mon, 20 Aug 2012 17:17:36 -0400 Message-ID: <5032AA40.1000902@isdg.net> Date: Mon, 20 Aug 2012 17:21:04 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SM References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <503077C0.70405@isdg.net> <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 21:20:52 -0000 SM wrote: > Hi Hector, > At 11:57 20-08-2012, Hector Santos wrote: >> One may argue or suggest, and have, that "CAN" and "can" are in the >> same boat "may" vs "MAY" have also been argued, as well as SHOULD vs >> should. So want it implied, others like to see specifics. To me? The >> protocol engineering speaks for itself. > > There is a thread about the boat at > http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html This > topic has been a recurring in the IETF since a long time. Well, I tend to come from the school of thought gracefully cited here: http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html >> Then we have a BUG conflict between section 2.3 with a very strong >> RFC2119 language regarding DOMAIN expectation for a -ALL to translate >> to a negative classification where in 2.5.4, based on what is begin >> stated we have three options: > > The problem with an error in a specification is that it generally > translates into a software bug. And in my engineering opinion, the new revs will greatly increase - increase the complexity of designs, - interoperability issues, - lower the SPF -ALL payoff - increase doubt in the minds of SPF domains We need to separate the documentation people from the software engineers and technical programmers! That use to be separate disciplines in the SE process, you know? Today, everyone wants to be everything - and that causes issues, well, management problems and a status quo for the IETF process. -- HLS From spf2@kitterman.com Mon Aug 20 14:23:02 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 4C99221F8541 for ; Mon, 20 Aug 2012 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8ISZsjGvOAd for ; Mon, 20 Aug 2012 14:23:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 130CA21F8501 for ; Mon, 20 Aug 2012 14:22:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 85DAD20E411E; Mon, 20 Aug 2012 17:22:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345497775; bh=yf8RF7+BVUQvmebMg4FDOPm3tAyhA3hoLj3aN1TbSGo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FEqIryNZpI8GfQGmfLNbjQd38sMYZltbmDjsxyv28w/TQAOsliKu7wK1n/iG5+Ed6 EVv7ZrEBiCSenuCze2uw5qjfO3NuX54g5pxJloxeR2MgG3oXReccH2uHGkBr7SGleF gIr/2IdvOaaOCND8jdR/KWO/5YPZ0Zap2mu0zqmM= Received: from scott-latitude-e6320.localnet (unknown [74.82.102.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 51B1D20E410F; Mon, 20 Aug 2012 17:22:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Aug 2012 17:22:55 -0400 Message-ID: <2444018.ypz086Sogk@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@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] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 21:23:02 -0000 On Monday, August 20, 2012 02:15:20 PM Murray S. Kucherawy wrote: > On Mon, Aug 20, 2012 at 1:16 PM, SM wrote: > >> Then we have a BUG conflict between section 2.3 with a very strong > >> RFC2119 > >> language regarding DOMAIN expectation for a -ALL to translate to a > >> negative > >> classification where in 2.5.4, based on what is begin stated we have > >> three > > > >> options: > > The problem with an error in a specification is that it generally > > translates into a software bug. > > The current Section 2.3 text says, in essence: If you want to give > receivers the ability to make a definite negative conclusion ("fail") > about an incoming message, you have to use "-all". It says nothing > whatsoever about what a receiver does upon reaching that conclusion. > > Section 2.5.4 then goes into detail about what choices a receiver has > when a "fail" conclusion is reached. > > I don't see a conflict or "bug" here. They're complementary. Agreed. In any case, 4408 was very careful not to prescribe what receivers should do with "fail" mail. Changing that in 4408bis would be a substantiative change that's out of scope of the charter even if there was consensus for it. Scott K From superuser@gmail.com Mon Aug 20 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 5C96321F8594 for ; Mon, 20 Aug 2012 14:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN0mxB4XBm9x for ; Mon, 20 Aug 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 87AC521F854F for ; Mon, 20 Aug 2012 14:24:15 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3750514lbb.31 for ; Mon, 20 Aug 2012 14:24:14 -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=q8OParYR5KXrJQGn/cp31SJhimRni0CWwFPFBmIkIxQ=; b=0ihtWCnhgND+OI84rBWmjLEfE6qG3S99wheff5HuiCGxpUTeNjOm6uoLXtKcK510R6 zlwgVgt7JNVayGQqwNbs2W8Yb8qaEQNGhwbINldD/WzYOpgO66MNG8+Ez1heLxoQoDtD kzKA2ft/z3Znwy7I4v3gknqBLJa0yu3eyyfZaKcDSjK1hYVrG0eWxYjtO37/tO7dbxe8 M4/gdo9yRmetdN3hv5yioXwfAXLf3ALiR24MuBWBBOQo9xRDyUbzMf20aZxtI/FJEyiz YbuOujc9SCp7Mi23eDPOGEo7ZPTqkK0E30GGgaSTBv0xhW4pTGlcmP/Ba5IoOjidKzXU Axbw== MIME-Version: 1.0 Received: by 10.112.28.4 with SMTP id x4mr1592140lbg.105.1345497854434; Mon, 20 Aug 2012 14:24:14 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 14:24:14 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> Date: Mon, 20 Aug 2012 14:24:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 21:24:16 -0000 On Sun, Aug 19, 2012 at 9:15 PM, Murray S. Kucherawy wrote: > On Sun, Aug 19, 2012 at 9:35 AM, SM wrote: >> My reading of the old text is that SMTP receivers record the result of SPF >> processing for the recipient. The new text proposes two methods of >> conveying the information to the recipient. This is the kind of text which >> causes debates. If which header to add is a matter of local policy, the >> receiver also have the ability to follow the specification; RFC 5451 in this >> case. I suggest adding (non-normative) guidance if anyone would like to >> have the Authentication-Results: header. Anything more than that ends up as >> not picking one option and trying to satisfy everyone. > > I imagine this can be resolved by pointing out the reason support for > two schemes is included, namely that one is historic but still in some > use while the other is an established proposed standard used by > several other mechanisms. It is in effect a migration path. > Essentially, a receiving ADMD can use either one, but there's more > momentum behind one of them to have more wide adoption in the long > term, and implementers should be aware of that. A further thought: Use of A-R or Received-SPF is not a part of the SPF protocol itself. Where SPF is a protocol between the SMTP client and server, this stuff is a protocol between the SPF verifier and internal filters and MUAs. Put another way: If an SPF verifier doesn't add either of these, do we claim it's non-compliant? We might instead drop all the normative stuff from Section 7 and just say: If the verifier wishes to communicate SPF results to internal agents like filters or MUAs, it can use either of these two mechanisms; the reason we present two mechanisms instead of one is because one (Received-SPF) was in RFC4408 and in popular use among SPF implementations, while the other (A-R) is the more general proposed standard gaining wider adoption. We'd probably make the IESG happier to converge on one, but I suspect they'd let this slide under the guise of an implicit migration path. -MSK From spf2@kitterman.com Mon Aug 20 14:29:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670321F8541 for ; Mon, 20 Aug 2012 14:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0QwDciQIFpB for ; Mon, 20 Aug 2012 14:29:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9733021F85BB for ; Mon, 20 Aug 2012 14:29:04 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 148C320E411E; Mon, 20 Aug 2012 17:29:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345498144; bh=wGSfj3el5p30/fc0elfbCFACQRK5I+cqtTndZUv49mk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YAtmc9tX3ZBDP/rSkZhNGx0OuebpuikP+XqseCZ6hukDj97tDzuFTYlSYmzpPl+BB dFpHGujChUPw1qli1AESz5dxjLGjzuuf53OqDKzm9X/79ZNe6kZ620BqXPtgZ+AZLQ TG1tXvAe0wBufGeUV6fPPDkJOERBq3Ux8qRrohOE= Received: from scott-latitude-e6320.localnet (unknown [74.82.102.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CD40B20E410F; Mon, 20 Aug 2012 17:29:03 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 Aug 2012 17:29:03 -0400 Message-ID: <1644953.F7dC6kdRo1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5032AA40.1000902@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@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] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 21:29:05 -0000 On Monday, August 20, 2012 05:21:04 PM Hector Santos wrote: > SM wrote: > > Hi Hector, > > > > At 11:57 20-08-2012, Hector Santos wrote: > >> One may argue or suggest, and have, that "CAN" and "can" are in the > >> same boat "may" vs "MAY" have also been argued, as well as SHOULD vs > >> should. So want it implied, others like to see specifics. To me? The > >> protocol engineering speaks for itself. > > > > There is a thread about the boat at > > http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html This > > topic has been a recurring in the IETF since a long time. > > Well, I tend to come from the school of thought gracefully cited here: > > http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html > > >> Then we have a BUG conflict between section 2.3 with a very strong > >> RFC2119 language regarding DOMAIN expectation for a -ALL to translate > >> to a negative classification where in 2.5.4, based on what is begin > > > >> stated we have three options: > > The problem with an error in a specification is that it generally > > translates into a software bug. > > And in my engineering opinion, the new revs will greatly increase > > - increase the complexity of designs, > - interoperability issues, > - lower the SPF -ALL payoff > - increase doubt in the minds of SPF domains > > We need to separate the documentation people from the software > engineers and technical programmers! That use to be separate > disciplines in the SE process, you know? Today, everyone wants > to be everything - and that causes issues, well, management problems > and a status quo for the IETF process. The new revisions present exactly the same technical requirements that RFC 4408 presented. There is no change. There is some change in how the words are arranged and some added background about why certain choices might be made, but the design choices that are available to the implementer are exactly the same. Nothing has changed. Also, while you're throwing your accusations about documentation people versus real software engineers and technical programmers around, please don't forget that the guy that's editing the document is also an implementer. So far the only change I'm going to make in the current implementations I support is to format the Authentication-Results header fields the way that is suggested in -05. None of the changes you are complaining about affect implementation. Scott K From hsantos@isdg.net Mon Aug 20 15:02: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 CA05321F8532 for ; Mon, 20 Aug 2012 15:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-B7-anQxCSu for ; Mon, 20 Aug 2012 15:02:05 -0700 (PDT) Received: from secure.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2A21F852E for ; Mon, 20 Aug 2012 15:02:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2808; t=1345500115; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=WmxgF5YZtE4ElPlonkDtXRYhj1A=; b=njNO6/1PXYlIP5StaqUx M8EcistfMngyn5WmBPoupkjkKrfCL8pUhcZmQIQHr3rSTRh6RLCKlQAC0xjsK+Jf jMRYkgbzy2lL2ytUjcxYMkX08N9h8uJ4H90B1CPbygFVU7e1wiIMplHfKCsd/gcm Pa/eYZNFp7uVNbPdmWAzur8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 18:01: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 1521914688.25431.3288; Mon, 20 Aug 2012 18:01:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2808; t=1345499928; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lScEKKl 2y+n6jKhinJu5bjfe2BEk1c6ai8x+2wPttcs=; b=sQ22bLvQKXFB6UlToSlINGy KZPeI2FpkeBIRlhWB5SEhU6oHnTu31iJ9ElXa/ACNTERNe/ib8YDjZtr/2q3hjuT YLmQNHIPspElQ5brnsM1etVUk2rg12Dbd8B9ZwBtswBy7cxEZYMV00XwlBVa8G2d dxXhGlP4fMY3ENUnzUvk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 17:58: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 2120726864.7.4720; Mon, 20 Aug 2012 17:58:48 -0400 Message-ID: <5032B3E8.5070703@isdg.net> Date: Mon, 20 Aug 2012 18:02:16 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> In-Reply-To: <1644953.F7dC6kdRo1@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 22:02:10 -0000 Scott Kitterman wrote: > On Monday, August 20, 2012 05:21:04 PM Hector Santos wrote: >> And in my engineering opinion, the new revs will greatly increase >> >> - increase the complexity of designs, >> - interoperability issues, >> - lower the SPF -ALL payoff >> - increase doubt in the minds of SPF domains >> >> We need to separate the documentation people from the software >> engineers and technical programmers! That use to be separate >> disciplines in the SE process, you know? Today, everyone wants >> to be everything - and that causes issues, well, management problems >> and a status quo for the IETF process. > > The new revisions present exactly the same technical requirements that RFC > 4408 presented. There is no change. There is some change in how the words > are arranged and some added background about why certain choices might be > made, but the design choices that are available to the implementer are exactly > the same. Nothing has changed. The effacy for SPF -ALL publication has been greatly diminished with the changed in the revs. Today, unlike yesterday, we will now be put into a change position for our documentation SPF references to say: NOTE: Publishing -ALL no longer guarantees SPF receivers will honor your HARD FAIL -ALL policy. While between you, I and that post over that knows that was always the case - for anything, the revision now certainly raises doubt, and in addition unlike over the years where casual discussions or support had no dispute on what -ALL meant and does, you and murray have now added a new level of debate anytime it now even comes up by throwing the RFC4408BIS book at them. 4408 2.5.4 said the checking software can mark or reject. It does not say it does not have to do either or it can be silent although there was no point in saying that a receiver would do anything at all. The rev have made that clear now, the new 2.5.4 does now ever mention marking the mail any more and moved it to a discussion of doubt. > Also, while you're throwing your accusations about documentation people versus > real software engineers and technical programmers around, please don't forget > that the guy that's editing the document is also an implementer. Exactly, I know that. But the point still remains, sometimes these things need to be separated. Of course, thats the beauty of the RFC process - the merging of disciplines, and keeping aware of the mixed discipline readers is part of the process. > None of the changes you are complaining about affect implementation. I believe it does. At the rudimentary level its harder to read, more vague and odds are now higher, it inadvertently lowered the "mark the message" aspect and strengthen the RFC2119 reject behavior. -- HLS From sm@elandsys.com Mon Aug 20 15:56: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 B044B21F8541 for ; Mon, 20 Aug 2012 15:56:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V24ruGnIjQSu for ; Mon, 20 Aug 2012 15:56:49 -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 1912321F853E for ; Mon, 20 Aug 2012 15:56:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.30]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7KMuZnB029982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 15:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345503406; bh=kkq0Xaby4pdGVesjjFJzbpf1T20WVpg3Csn2cd/k27k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=euPJjfBoROMKMVqKtXbiXq0sAfO7uv282T8wVgss8m4lq8QVHUTYSMz4jX4oSraCn FoF9dFnaouF5imcdJjgbQFgZGll8WbyWFffjmcmLEb2dWdumtONs/ulLhhvfmNT3k8 yNwZAPH2eSl72PhTZIHTjzsLtZ4kI5t0XVyaBzrg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345503406; i=@elandsys.com; bh=kkq0Xaby4pdGVesjjFJzbpf1T20WVpg3Csn2cd/k27k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fOPhPb82RhzMEyktXp/bbQFeifsKm07VpfMEmOl0eru21H5osPi0Z0slhDwPz+jpd yuq1OFUW69bD6vG0LUtJ2c5HmtugWeubu/OWB6/ioHY7L0goY5uRb/2Q0RflNtrgSR V2hMz5RKPGfF8ACibhryXWTiIqShJeAtMRN+1n04= Message-Id: <6.2.5.6.2.20120820144122.09169ef8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Aug 2012 15:32:59 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120819082527.0925a9d8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 22:56:49 -0000 At 14:24 20-08-2012, Murray S. Kucherawy wrote: >A further thought: > >Use of A-R or Received-SPF is not a part of the SPF protocol itself. >Where SPF is a protocol between the SMTP client and server, this stuff >is a protocol between the SPF verifier and internal filters and MUAs. >Put another way: If an SPF verifier doesn't add either of these, do we >claim it's non-compliant? If I had to describe this I would say that we would like to have interoperability between the SPF publisher and the "mail receiver". If the "mail receiver" would like to interoperate with a MUA (it can be another filtering option) that's another part. If you want everything as a whole, you cannot have local policy in between the SPF publisher and the MUA. >We might instead drop all the normative stuff from Section 7 and just >say: If the verifier wishes to communicate SPF results to internal >agents like filters or MUAs, it can use either of these two >mechanisms; the reason we present two mechanisms instead of one is >because one (Received-SPF) was in RFC4408 and in popular use among SPF >implementations, while the other (A-R) is the more general proposed >standard gaining wider adoption. We'd probably make the IESG happier >to converge on one, but I suspect they'd let this slide under the >guise of an implicit migration path. If there isn't any interoperability issues, it less of a problem. I suggest keeping matters simple unless someone has a good reason for X or Y. The above is one alternative. If anyone has other alternative to suggest, I would like to hear it. Regards, S. Moonesamy SPFBIS WG co-chair From superuser@gmail.com Mon Aug 20 16:15: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 D188C11E8098 for ; Mon, 20 Aug 2012 16:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h92l8VvenOZt for ; Mon, 20 Aug 2012 16:15:31 -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 1693B11E8097 for ; Mon, 20 Aug 2012 16:15:30 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3793193lbb.31 for ; Mon, 20 Aug 2012 16:15:30 -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=CJe/7mjyFam5FSpvuVwYhu0BA5x9SCneTbnIjfDyEso=; b=jYYXkOxcZ6HdF/dh+PCamM1O5F11UXA/iECxAwMsgd2SIcYiM4k9GlhGLBK900S7Ms Ni0fuMRMVSuzzngsTBnq3j5+AEJu2O0ymEwZIWlQDOgvZL6B+UvEVg7yttjF4lQSUZbd m+6ydIOzmRociNLUzTlXWqnxlY5SorjZwX9RRXzqX3xK22AUbJqe+L/2VKPk0cZ8+XgL qN1Hvcg7URhHFYvyd/Ra53U1p0iI9lotLEdK9anVAH+Dp4GmA3GAlQ1EfUPuLKDsSOxD oEv8KpAPNDGdLcbWMaKnIEcFSkuEguGM2HnZuxOU/AuTWewLsSoy2AmSn2cswMXfwJcq P/+w== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr15402771lab.10.1345504529946; Mon, 20 Aug 2012 16:15:29 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 20 Aug 2012 16:15:29 -0700 (PDT) In-Reply-To: <1644953.F7dC6kdRo1@scott-latitude-e6320> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> Date: Mon, 20 Aug 2012 16:15:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 20 Aug 2012 23:15:31 -0000 On Mon, Aug 20, 2012 at 2:29 PM, Scott Kitterman wrote: > The new revisions present exactly the same technical requirements that RFC > 4408 presented. There is no change. There is some change in how the words > are arranged and some added background about why certain choices might be > made, but the design choices that are available to the implementer are exactly > the same. Nothing has changed. +1. Moreover, the chairs declared this a closed topic back in April. Could we please spend our energy on topics that are open? I'd like to get this work finished before my daughter hits high school. -MSK From hsantos@isdg.net Mon Aug 20 18:34: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 4247D21F856F for ; Mon, 20 Aug 2012 18:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuXk-Jt9pHqI for ; Mon, 20 Aug 2012 18:34:05 -0700 (PDT) Received: from catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 87DCE21F8569 for ; Mon, 20 Aug 2012 18:34:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1276; t=1345512836; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=G/pGoZgKscqG3qE5/Eo0ZAkNrtQ=; b=M88wJDOJM2iVG8PdDu8l XmhMs3g5OUOLtvpXMASQpHaT7VtvTvAcobXF7maSTa/nsT7wGRD9geJy8cYx0510 2Y4bKGpoqmpwRrrIAbo7+s7PsuRoTYwDd6PAVBQ3wKhhOHOMZ3v3rVsaeyazwtV5 aLfppQCvvCPR+0+oTbxHFZk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 21:33:56 -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 1534634884.25431.6096; Mon, 20 Aug 2012 21:33:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1276; t=1345512647; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4UF7w0I WIVu9EOk2fYWJDhC3sai8WjPybZen5t6d4lY=; b=l0urZKdxT5vLxF8kM8xEPDI ISjMokpkwUgpS/FZTDEZddv0sovZO/c4O718lz0kKCMqxD9mzG51OzRZBQY3WA7p bVLwA+kZWfv7/NXwfKT/qRdlSbLRZT/stcgjS/hqg6wRmGpXOC7UN9ad9GzeNUj2 AKnyUZ32Y+vfl8240c7o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 20 Aug 2012 21:30:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2133445286.7.5636; Mon, 20 Aug 2012 21:30:46 -0400 Message-ID: <5032E596.5020507@isdg.net> Date: Mon, 20 Aug 2012 21:34:14 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 01:34:07 -0000 Murray S. Kucherawy wrote: > On Mon, Aug 20, 2012 at 2:29 PM, Scott Kitterman wrote: >> The new revisions present exactly the same technical requirements that RFC >> 4408 presented. There is no change. There is some change in how the words >> are arranged and some added background about why certain choices might be >> made, but the design choices that are available to the implementer are exactly >> the same. Nothing has changed. > > +1. Moreover, the chairs declared this a closed topic back in April. > Could we please spend our energy on topics that are open? What topic is that? Issue 29? Is this ISSUE 29 closed? Scott indicated it was still open. > I'd like to get this work finished before my daughter hits high school. You are the one that is creating a mess for SPF. Not me buddy. The controversies have begins with you, saying dumb stuff like above. I am not the one ignoring input from participants and then finding you were wrong in the end. There is a still a problem with the rev text. The rev changes, which I presumed is your work, needs serious work with added doubt added to the protocol. Learn to accept the criticism and concerns and work with it rather than ignoring it and brushing it off. -- HLS From sm@elandsys.com Mon Aug 20 19:08: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 41D5121F8525 for ; Mon, 20 Aug 2012 19:08:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B220aJa2fr5c for ; Mon, 20 Aug 2012 19:08:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E72221F8526 for ; Mon, 20 Aug 2012 19:08:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.30]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7L28Kwa026420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 19:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345514916; bh=1NdltIczPD8iNLKQHsx5ZpKHEPcXNWX6i5rmr9mfnDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BFS8J6sRm8bh8VUI6spCxzBGTRmCZE1rU9ElvdETkSaJDDKQ/ANMHc8gFycjQf9Kn aQjPrsMJrkNRQ53M8ecrOoox1X81G6creXXG9t2GbfR3tNIAzogb2Yq51Na3mnn/Rl 01uMDSGCvRROuco37JTdg2sPAGN4M8IwdhBfs6dw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345514916; i=@elandsys.com; bh=1NdltIczPD8iNLKQHsx5ZpKHEPcXNWX6i5rmr9mfnDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BiUSBmkUDKf4aMcdD+SNWMvheawh362MZ97uFbooqyLJeXlu3FgLxhJbtUy4Nz5FI i516qJAFkiVQ4AnHRZhm8yQAzot+2jOeQoYyJPRONa6CQL5p0QHmJKtaP92eQG5xxg xU0h9Q3qqU6uKTr94+keqISOC0dJtLSEyzId/W4I= Message-Id: <6.2.5.6.2.20120820185655.092e0c48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Aug 2012 19:07:36 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <5032E596.5020507@isdg.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> <5032E596.5020507@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 02:08:42 -0000 Hi Hector, At 18:34 20-08-2012, Hector Santos wrote: >What topic is that? Issue 29? Is this ISSUE 29 closed? Scott >indicated it was still open. Issue #29 is at http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29 This is part of the current text in Section 2.5.4 of draft-ietf-spfbis-4408bis-05: "If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 If the mail receiver decides to reject the message it should use the designated SMTP reply code. The following text is from RFC 4408: "If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550" There hasn't been any change to the sentence except for an update to the references and the change from "Delivery Status Notification" to "enhanced status code". Is the following text an issue: "Disposition of SPF fail messages is a matter of local policy. See Section 9.3 for considerations on developing local policy." Regards, S. Moonesamy SPF WG co-chair From vesely@tana.it Tue Aug 21 00:40: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 21D3921F8648 for ; Tue, 21 Aug 2012 00:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPmprCrpFxyl for ; Tue, 21 Aug 2012 00:40:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 52EEE21F862A for ; Tue, 21 Aug 2012 00:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345534843; bh=W2732BjIMzafKfLOVK0T6yGcR/mopiAYbborF4bls34=; l=819; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SdhYL4SSuOV2jmLEYcV4H0Pq/CYOL4DgdOVdmJm8F6dsbx0H+xmrJ7IwwI7hMom1S miFAQVaiQXaBi237SbpGV3y2vUcv+eHZiCKrgrGer54QKhoQK8l4a4F54H5WoryGgN VeStfpKUwWXFPWmEzKOx+xSLX8a+wzpTevxl5+YQ= 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, 21 Aug 2012 09:40:43 +0200 id 00000000005DC039.0000000050333B7B.00007225 Message-ID: <50333B7B.6040300@tana.it> Date: Tue, 21 Aug 2012 09:40:43 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> <5032E596.5020507@isdg.net> <6.2.5.6.2.20120820185655.092e0c48@resistor.net> In-Reply-To: <6.2.5.6.2.20120820185655.092e0c48@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 07:40:46 -0000 On Tue 21/Aug/2012 04:07:36 +0200 S Moonesamy wrote: > > Is the following text an issue: > > "Disposition of SPF fail messages is a matter of local policy. See > Section 9.3 for considerations on developing local policy." IMHO it should be: Local policy MAY dispose to reject SPF fail messages. See [...] That specifies the interoperability among the receiver, the domain owner, and any unauthorized senders abusing its domain name. No change of meaning is implied, as there is no magic in "MAY", except to have a somewhat uniform method of specifying standards throughout the whole RFC series. I suggest we follow that rule by adding such clarifying language. There may be good reasons to specify SPF in its own way, using the text you quoted. I'd imagine the IETF can accommodate that too. From vesely@tana.it Tue Aug 21 00:40: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 25F3D21F8653 for ; Tue, 21 Aug 2012 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8dqYInpJWI7 for ; Tue, 21 Aug 2012 00:40:51 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5421F862A for ; Tue, 21 Aug 2012 00:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345534850; bh=FQLgRHiYmekkJv5YPbrg7LTJ72EVW61bM365gKCFlDY=; l=1675; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gyeg5ph5/JayhVuC4ci8bbU7BYr283rfFkedQIZUt7MVsZxLXtAV1m3rz6uDV+yCG QyllswxmA1C+qM54/vs443wVBqrJINBRVJs3R6/PSEIdXEGcZ4FU27fyOLtbE7QTn2 aNF8RMJjDDMOGvp/WjfXUAPLq3i5DwdtzbQ3AF9M= 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, 21 Aug 2012 09:40:50 +0200 id 00000000005DC039.0000000050333B82.0000723E Message-ID: <50333B83.5060603@tana.it> Date: Tue, 21 Aug 2012 09:40:51 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> In-Reply-To: <2748008.To0uIurt7Z@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 07:40:52 -0000 On Mon 20/Aug/2012 22:46:25 +0200 Scott Kitterman wrote: > On Monday, August 20, 2012 06:45:19 PM Alessandro Vesely wrote: >> Thus, we could say: >> >> The receiving server MAY reject messages using codes as specified >> by SMTP ([RFC5321]) and, if supported, Enhanced Mail System Status >> Codes ([RFC3463]). >> >> That way, we'd use normative language for the point pertaining to the >> SPF protocol, while sparing it for what pertains to other standards. > > The problem with this is that the rationale is about the recipient and not the > sender. Why would it be appropriate to pick x.7.1 over x.7.0: > > X.7.0 Other or undefined security status In a previous message you said "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." http://www.ietf.org/mail-archive/web/spfbis/current/msg01693.html Since 5.7.1 is given in the example, the added meaning of a SHOULD is that there are serious issues that the receiver should be aware of before using a different code. Correct? In that case, would it be overly picky to remove the SHOULD for 550 and just use it for X.7.1? E.g. The receiving server MAY reject messages using codes as specified by SMTP ([RFC5321]). If Enhanced Mail System Status Codes are supported, it SHOULD use 5.7.1 ([RFC3463]). > While the overall designation includes the word policy: > > X.7.XXX Security or Policy Status > > None of the X.7.? codes mention it at all (unlike 550). I don't think there > is an obvious best choice and so I think that for consistency we recommend one > that should be used. From agthisell@yahoo.com Tue Aug 21 06:05: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 698B321F8611 for ; Tue, 21 Aug 2012 06:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8-Y2uslCaor for ; Tue, 21 Aug 2012 06:05:09 -0700 (PDT) Received: from nm21.bullet.mail.ne1.yahoo.com (nm21.bullet.mail.ne1.yahoo.com [98.138.90.84]) by ietfa.amsl.com (Postfix) with SMTP id C463621F8600 for ; Tue, 21 Aug 2012 06:05:09 -0700 (PDT) Received: from [98.138.90.54] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 13:05:05 -0000 Received: from [98.138.88.232] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 13:05:05 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 13:05:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 121607.70729.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 25772 invoked by uid 60001); 21 Aug 2012 13:05:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345554304; bh=GdXZEjniZ8mo/1CfUPSW1VZ8S8YDsz2Ft7AJXC4iJNc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Y4MIYm26SF80Gu1+FAC9KyI2DzVL1VCcFgWU2GM+DyvDavU2RhFoGUpQnLjkG3alZTzcslBBtn+ZpM+6DafaCaQ1vqgfRhSNYpIWi5E3GmDN75pFZxiiN83AtWQTFVR52Nd08vx2HvZMhFIfqWfHMrtIIdI6U0oSfPtsX2vaWyM= 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=4aXLsZVoervFTUPY/SymPyrttBg3ZH7c5s3+nekaQ0oSqBQGj6ymaCaihGPwIcMdRIMK8mEv2ZTZ1btMhrGwOELotAwXeXiMNmucD4+kBwfqtEHcdq9uXBL/xFr3+EG2/Ve+wadKyhMqXsNPhAXYSQqTPhGYqtJkkY45pGhnuaU=; X-YMail-OSG: pV4qTxYVM1nN4ywu5sTMjWGZQo24579b015Ma8LOMmAVyZe sR3N_1.nwXZR7PnVN2rz7HBTf1GG3AHd9ZK24XT86PmnFfZ6iO_SPiw1rpJV 1tslnGASnTkHchmdy.QwUin3k_2wrSpbua7ub4slpCkwX1HVFBRpoWEpJKM8 VgD3_fKjyxw4KDfwlvo4RB0r3ovuTGcaecl51e0zvKf2Vy5yzfwYces9cjV5 xep66dVteTuNcihWGbPrNrXkpYVEYhKfoCCIMjDdIde1fUCNxXpTYR1hfA6V FDZ421kz00QB0QuZXr09xUh4A5KIEE.lMIF77.xpqb.KDJe24ctqdaahRF6R 4uLiFCrLfW5NqGpIcQr0ZI6sBd6Vc4rgDlU7HkY0AWm43z0smtQbhVwo1frn t3xSaYQvYRgj1DK9pIxXGoHFUInzLgZhjdW7MYd_rpX77VUTg87dGghAtQ_P jAqggjF03BeeLoKop2PM- Received: from [71.61.133.134] by web125402.mail.ne1.yahoo.com via HTTP; Tue, 21 Aug 2012 06:05:04 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1345554304.25404.YahooMailClassic@web125402.mail.ne1.yahoo.com> Date: Tue, 21 Aug 2012 06:05:04 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 13:05:10 -0000 > Agreed. In any case, 4408 was very careful not to prescribe what receivers > should do with "fail" mail. Changing that in 4408bis would be a > substantiative change that's out of scope of the charter even if there was > consensus for it. Indeed, the mantra on the spf lists was SPF is a Sender Policy Framework, not a Receiver Policy Framework. RFC 4408 was very careful not to prescribe what receivers do because there are no protocol police to enforce what receivers do. Any implication that receivers had to take some particular policy would be deceptive. From ajs@anvilwalrusden.com Tue Aug 21 07:29: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 1BBD621F866A for ; Tue, 21 Aug 2012 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smgQWDBh1KeW for ; Tue, 21 Aug 2012 07:29:52 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9E19E21F8668 for ; Tue, 21 Aug 2012 07:29:52 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 92EED8A031 for ; Tue, 21 Aug 2012 14:29:50 +0000 (UTC) Date: Tue, 21 Aug 2012 10:29:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120821142956.GA33255@mx1.yitter.info> References: <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <20120820200545.GH29830@mx1.yitter.info> <50329E47.6010009@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50329E47.6010009@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 14:29:53 -0000 No hat. On Mon, Aug 20, 2012 at 04:29:59PM -0400, Hector Santos wrote: > > So not sticking to 2119 is just the same as advocating a protocol > design? What I intended to say was simply, "No new all-caps terms." > Which by your definition, the PROTOCOL has the compliance level or > lack there of option to NOT mark NOR reject. No. There is no "compliance level" to the protocol. A protocol specifies the necessary and sufficient conditions of behaviour for something to be called an implementation of it. If an implementation does not follow those conditions, then it is not conforming to the protocol specification; but the IETF does not do "compliance", and there are no protocol cops. > ways and thats by sticking with 2119 sir. It means the technical > specification is to design a protocol with a mutual exclusive > option: > > (o) do not honor hard fail > (_) honor using SMTP REJECT (RFC 2119 compliance) > (_) honor using SMTP ACCEPT+RECEIVE-SPF > > We are presuming a "Mark" means adding RECEIVER-SPF header. While these may be mutually exclusive options, it is entirely possible for the text to leave open to the receiver which of the options to use. This would still provide a complete specification, with behaviour that covers all the possibilities while yet leaving local policy to the local operator. As nearly as I can tell from your message downthread, you actually agree that RFC 4408 leaves the options open to the receiver. You appear to be arguing that we should tighten this portion of the specification. But given the chairs' recent ruling on a procedural question, and the results of the appeal to the responsible AD, I argue that the WG could not tighten this portion anyway. Therefore, what is correct for the text to do is to lay out more clearly perhaps than it was in 4408 what the options are. You seem to think it does that. If I have misunderstood your argument, perhaps you can state it less colourfully so that I may understand it properly. If I have correctly stated your argument, then it is time to let this thread die. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Aug 21 07:45: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 F01D021F86A4 for ; Tue, 21 Aug 2012 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eTYuGwTx3Go for ; Tue, 21 Aug 2012 07:45:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2145321F853E for ; Tue, 21 Aug 2012 07:45:24 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 3AF9CD0408D; Tue, 21 Aug 2012 09:45:23 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345560323; bh=7Trlk8yg7OVuBzEaEEmnVct6oQf37I4C9upIdpm/GN8=; h=References:In-Reply-To:Subject:From:Date:To:From; b=WipPKTOeInkfI07CsV0O2qcZAbHi4lYKUQbgBh8tInPBd0TygSfW3vZGlhtUzL2ce ks4r5mybrHoce7e0TTZs4WIgvZ1euy2Go3TWVbi20M1fv2eId0UdTjIGOBdLt7ZKAv TgZAc9+fdUm2mHTpvyoQ1HYg6yHCKc2uNS0mNeTE= Received: from [IPV6:2600:1002:b01a:22ea:d8e4:c592:1273:650e] (unknown [IPv6:2600:1002:b01a:22ea:d8e4:c592:1273:650e]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AD1A7D0408A; Tue, 21 Aug 2012 09:45:22 -0500 (CDT) References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <50333B83.5060603@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 21 Aug 2012 10:45:18 -0400 To: spfbis@ietf.org Message-ID: <0d5d8a66-48e1-4183-b381-436a6d0e19aa@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 14:45:38 -0000 Alessandro Vesely wrote: >On Mon 20/Aug/2012 22:46:25 +0200 Scott Kitterman wrote: >> On Monday, August 20, 2012 06:45:19 PM Alessandro Vesely wrote: >>> Thus, we could say: >>> >>> The receiving server MAY reject messages using codes as specified >>> by SMTP ([RFC5321]) and, if supported, Enhanced Mail System >Status >>> Codes ([RFC3463]). >>> >>> That way, we'd use normative language for the point pertaining to >the >>> SPF protocol, while sparing it for what pertains to other standards. >> >> The problem with this is that the rationale is about the recipient >and not the >> sender. Why would it be appropriate to pick x.7.1 over x.7.0: >> >> X.7.0 Other or undefined security status > >In a previous message you said "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." >http://www.ietf.org/mail-archive/web/spfbis/current/msg01693.html > >Since 5.7.1 is given in the example, the added meaning of a SHOULD is >that there are serious issues that the receiver should be aware of >before using a different code. Correct? > >In that case, would it be overly picky to remove the SHOULD for 550 >and just use it for X.7.1? E.g. > > The receiving server MAY reject messages using codes as specified > by SMTP ([RFC5321]). If Enhanced Mail System Status Codes are > supported, it SHOULD use 5.7.1 ([RFC3463]). I think it's quite awkward to specify one and not the other. I think we should keep them both. Scott K >> While the overall designation includes the word policy: >> >> X.7.XXX Security or Policy Status >> >> None of the X.7.? codes mention it at all (unlike 550). I don't >think there >> is an obvious best choice and so I think that for consistency we >recommend one >> that should be used. > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From sm@elandsys.com Tue Aug 21 10:32:37 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 9E2AC21F851A for ; Tue, 21 Aug 2012 10:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-Khr4CY8CRk for ; Tue, 21 Aug 2012 10:32:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EBB21F8779 for ; Tue, 21 Aug 2012 10:32:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.100]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7LHWKf4018154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2012 10:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345570354; bh=Lj/qBk0KBVLIYfvLPfJuQED9t2Osc2ZX2KT+G5Th4dU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fUdsQFq+Sy+o2YLMnWC6wO94x5gAkRciff1eobWq7w74Gy4TyQL/gPaA3WOZPcGlm z+aF4dzxg1DmeVgIDRBhiWJ7NC+KVtBDzmzzb6cE7FW28texsE+mPIdGMGFy39Iu4l P5KMnEge42e64L1AuU09420soXwqnNLddPYVSAmo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345570354; i=@elandsys.com; bh=Lj/qBk0KBVLIYfvLPfJuQED9t2Osc2ZX2KT+G5Th4dU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=QSHXtbvvm+mCclapWlngvG2ra2M8JTjWdAMMGiMstWkunm6BZEt4iBuSb5mzfgAOk Ex3EUPOahTw0kY3lSEaDGDUKTtjVuyj3rlXduKHnX5gBQhjd6UNaDNWl7p2YIIDFWp 02iechxtC58fW+hzIsJf0D5yuSlANxRvuVOjkSpE= Message-Id: <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Aug 2012 10:23:48 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50333B83.5060603@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Picky on RFC 2119 key words already in RFC 4408 (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 17:32:37 -0000 At 00:40 21-08-2012, Alessandro Vesely wrote: >Since 5.7.1 is given in the example, the added meaning of a SHOULD is >that there are serious issues that the receiver should be aware of >before using a different code. Correct? > >In that case, would it be overly picky to remove the SHOULD for 550 >and just use it for X.7.1? E.g. > > The receiving server MAY reject messages using codes as specified > by SMTP ([RFC5321]). If Enhanced Mail System Status Codes are > supported, it SHOULD use 5.7.1 ([RFC3463]). The above question is one which I might ask. One of the problem, which is generally referred to as a rathole, is that the working group would have to be picky about all the RFC 2119 key words which are already in RFC 4408. That's going to end up as a lot of work. The WG Chairs would have to see whether there is an adequate number of WG participants to review the changes. I am aware that some individuals who committed to review the WG work have not done that. My opinion is that all this would end up as a WG Chair problem. It is unlikely that the Responsible AD would try to convince me to the contrary as he might have a guess about I would do then. :-) Regards, S. Moonesamy SPFBIS WG co-chair From superuser@gmail.com Tue Aug 21 11:08: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 32FB221F852E for ; Tue, 21 Aug 2012 11:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGrvVgmbytzA for ; Tue, 21 Aug 2012 11:08:48 -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 1169221F866A for ; Tue, 21 Aug 2012 11:08:47 -0700 (PDT) Received: by lahm15 with SMTP id m15so54756lah.31 for ; Tue, 21 Aug 2012 11:08:47 -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=p6+ttGywkduUYizFDNnGC9gidOWQLMX3Gxf9XzBYsCA=; b=gK11Hv337lajkCMspDvJsgpulEa2tcdvdf6vTfF7e+b05X0q4jcI9fU9VLozBSoDMF KnqvKAe/kfBDj1jotSgiWEFDinOJIIfv4YfA7h+MVdgJLlA+doQ03RizHH+wK7nWqmp7 +HhZNBEBhLsmFLoHY5MwDiuPE7t0urwsg4iw3pVY41KZ188GIU1qDz6zxh1gFcHz0xHR aGSrqjJaqJCmKOi+vffVd/0MtGkNWOTWnTWyFOrITTv6oWq+Bjx/AS2Id6ufm6lFT1Ty tNVXRwhx5wTaSyzb/URBZbtMzaNHJccUgEZkM/vLfXTwAUqpTdwxfuE0tHtu11upznqA C5UQ== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr18338638lab.10.1345572526866; Tue, 21 Aug 2012 11:08:46 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Tue, 21 Aug 2012 11:08:46 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> Date: Tue, 21 Aug 2012 11:08:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 18:08:49 -0000 On Tue, Aug 21, 2012 at 10:23 AM, S Moonesamy wrote: > The above question is one which I might ask. One of the problem, which is > generally referred to as a rathole, is that the working group would have to > be picky about all the RFC 2119 key words which are already in RFC 4408. > That's going to end up as a lot of work. The WG Chairs would have to see > whether there is an adequate number of WG participants to review the > changes. I am aware that some individuals who committed to review the WG > work have not done that. My opinion is that all this would end up as a WG > Chair problem. It is unlikely that the Responsible AD would try to convince > me to the contrary as he might have a guess about I would do then. :-) In this particular case, the question is around interoperability between the SMTP client and server. The question we need to ask is: If someone doesn't do this, what's the impact? I think we can be certain that using 5yz codes is the right thing to do. Is there any harm in picking the wrong 5yz code? What do we need to say that RFC5321 doesn't, that's specific to SPF? Same question for enhanced status codes: 5.y.z is obviously correct, but beyond that, why is there a need to be more precise? Perhaps more generally: What problem are we trying to solve? Is it simply a question of trying to avoid sending implementers off to read those other documents? -MSK From sm@elandsys.com Tue Aug 21 15:20: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 DD5A921F8597 for ; Tue, 21 Aug 2012 15:20:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kbIrYHUVuYV for ; Tue, 21 Aug 2012 15:20:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B821F8596 for ; Tue, 21 Aug 2012 15:20:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7LMKEvU024511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2012 15:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345587626; bh=CsZ1uwKmEPRN2sVZ/kBF4PoRMZR6edkWUTIT48tbns4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=i1JKG4HJSwsyxEv6egV3SEkGB5vABZZrYzmJZAUehseh6JnHIgCxCv91CEXIVoXw6 z4rsqJEG0oR0He7C9RgYdHCo9soPftFbtzOeIYskgGz2MWet8jqvKxIvHopgrmdf4R TJfP2QVrU/L8NOiWnLDKP7f7Kr22GdRhqGveBMvY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345587626; i=@elandsys.com; bh=CsZ1uwKmEPRN2sVZ/kBF4PoRMZR6edkWUTIT48tbns4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=I+fx8Eutgb/I2ZKEYMY/RT/95HzqernaZ8zOtk1JGXchFDouQFtoJ7gcC+DaqZQHR V6RwOo8wAQ1HEbbSc0zjbO+1kaaDvFlTGmBcb7iMOYl/CiwJbgCfrADoR4eDIQFpjn z4Z4o8oPe0WRg11EZoVFtpptXZFec/pV0IB7ijDA= Message-Id: <6.2.5.6.2.20120821141625.0a560a68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Aug 2012 15:16:59 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 22:20:28 -0000 At 11:08 21-08-2012, Murray S. Kucherawy wrote: >In this particular case, the question is around interoperability >between the SMTP client and server. The question we need to ask is: >If someone doesn't do this, what's the impact? Yes. I am in favor of the "think about it". I might ask which implementation encounters an irrecoverable error because of an interoperability issue in RFC 4408. >I think we can be certain that using 5yz codes is the right thing to >do. Is there any harm in picking the wrong 5yz code? What do we need >to say that RFC5321 doesn't, that's specific to SPF? > >Same question for enhanced status codes: 5.y.z is obviously correct, >but beyond that, why is there a need to be more precise? This is more of a matter of style. Some specifications defer to the ones referenced normatively for that level of detail. Some specifications attempt to be self-contained by providing all the details. Let's look at this another way. If RFC 5321 changes the 5yz code to 6yz, what is the effect? By the way, the answer to the question might end up as a rewrite of the specification. Regards, S. Moonesamy From spf2@kitterman.com Tue Aug 21 15:39: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 4689011E80D3 for ; Tue, 21 Aug 2012 15:39: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcO9kt3jhdIZ for ; Tue, 21 Aug 2012 15:39:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 461CC11E8091 for ; Tue, 21 Aug 2012 15:39:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 65A4920E4129; Tue, 21 Aug 2012 18:39:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345588784; bh=oE+JW0NL6KRusa2VqUMoqN6fcXVOOupoERoFivvMMB8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nJEK1kJDrbgGYIx54FfXeAQ3D+LN7gOAJTl4aogTlMGoN6unLgOyVJ05UgQILDkHQ HcYixKzeMoMMwRuOZgdqqS0NJpdOK8csOoJ8O/RrrCwqZ0LFldNypaGHJU8gxIROID QjYfQCziG4UGKRxtfQqre3YKldtm4v32nh0FbWTY= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 350DF20E408E; Tue, 21 Aug 2012 18:39:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 Aug 2012 18:39:42 -0400 Message-ID: <4042906.FYNB9DcbUd@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@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] Picky on RFC 2119 key words already in RFC 4408 (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Aug 2012 22:39:51 -0000 On Tuesday, August 21, 2012 11:08:46 AM Murray S. Kucherawy wrote: > On Tue, Aug 21, 2012 at 10:23 AM, S Moonesamy wrote: > > The above question is one which I might ask. One of the problem, which is > > generally referred to as a rathole, is that the working group would have > > to > > be picky about all the RFC 2119 key words which are already in RFC 4408. > > That's going to end up as a lot of work. The WG Chairs would have to see > > whether there is an adequate number of WG participants to review the > > changes. I am aware that some individuals who committed to review the WG > > work have not done that. My opinion is that all this would end up as a WG > > Chair problem. It is unlikely that the Responsible AD would try to > > convince me to the contrary as he might have a guess about I would do > > then. :-) > In this particular case, the question is around interoperability > between the SMTP client and server. The question we need to ask is: > If someone doesn't do this, what's the impact? > > I think we can be certain that using 5yz codes is the right thing to > do. Is there any harm in picking the wrong 5yz code? What do we need > to say that RFC5321 doesn't, that's specific to SPF? > > Same question for enhanced status codes: 5.y.z is obviously correct, > but beyond that, why is there a need to be more precise? > > Perhaps more generally: What problem are we trying to solve? Is it > simply a question of trying to avoid sending implementers off to read > those other documents? Particularly the problem I'm trying to solve is having change for unimportant reasons. While some have argued the codes don't need to be in 4408bis, I don't think anyone has suggested it's a problem. Given that these codes are (with one exception that was a mistake) in 4408, I think there needs to some positive benefit associated with removing them. I do think there's value in uniformity on this. Not so much for hard core interoperability between computers but to aid in human understanding of what the various systems are doing. If different implementations use different codes, then there is some potential for confusion. Finally, I think it's better in this case to simply give the preferred answer in 4408bis than to send implementers off to read two references, particularly since one of which does not give a clear answer about how to proceed. If we're going to remove things, I think there needs to be more to it than "I feel like that's not the best way to have done it." Scott K From hsantos@isdg.net Wed Aug 22 00:23: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 BFF7921F8463 for ; Wed, 22 Aug 2012 00:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pojgR3zvcmsb for ; Wed, 22 Aug 2012 00:23:41 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EDBDF21F8462 for ; Wed, 22 Aug 2012 00:23:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5565; t=1345620212; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=HRu4TK0Z9q9WwCLUFGl4hAK9rFA=; b=ipqBxTb0IaUnb+q7z+X6 j/c7LSqJEfRZxT7ksgm1P4Gc5VI56FhezNzD3KiWupJBgTYOvn22NkFr6nI2hEK+ lecyFG3RyYD2gZHF7hZcAsWr9/6mlgJIU49Tv2ol4H0uDoTlIIz2R1wnD02+k1p6 3wWoXHEaO8GRCvG13faZKkI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 03:23:32 -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 1642010981.367.5048; Wed, 22 Aug 2012 03:23:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5565; t=1345620020; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jJUoDrF 7/NyadGdRuFCOGDvOLkxnrceQ5amzWJIZgIA=; b=l6pidj4J4Ic+phCz5DbOuWj F4jMNybfWXrC9Tdj1+lrCQCAgdqCLZKHtUqAMdw5xlPaUXoVMBjPtPlF7bNrBfRp SI0YBehQuZixXLT8o0b5n4/wfL0Z++V6tbQkszkFzvpVyTGTZpYH/5rUIDbsuGAx DmVhswbfwPDvYRe+zi4s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 03:20:20 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2240818020.7.7932; Wed, 22 Aug 2012 03:20:19 -0400 Message-ID: <503488E1.50101@isdg.net> Date: Wed, 22 Aug 2012 03:23:13 -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: <7733947.LvW5INK1oG@scott-latitude-e6320> <50322C0E.8080803@isdg.net> <6.2.5.6.2.20120820082447.0af4e268@resistor.net> <50326EA1.7030107@isdg.net> <6.2.5.6.2.20120820101837.0ad6f458@elandnews.com> <50328895.8060906@isdg.net> <20120820200545.GH29830@mx1.yitter.info> <50329E47.6010009@isdg.net> <20120821142956.GA33255@mx1.yitter.info> In-Reply-To: <20120821142956.GA33255@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 07:23:45 -0000 Andrew, This has already taken more time that I anticipated, but wasn't surprise. I believe BIS has been watered down with this increase obvious emphasis on local policies (DUH!). The goal is to provide insight for designers to provide operators flexibility (i.e. local policies). I was simply looking for a definition or clear description of "Mark the mail" as this has direct implication on backend storage methods based on MUA method of access. Security is provided with a hard SMTP reject. Marking "should not" be a way to circumvent this security provided and domain intent and expectation for using a hard -ALL failure policy. Anyway, the following is my last input on this and let scott and others decide from here. Yes, in theory we can PULL all the parts from the revisions. I just don't like how its written which in my view does change the SPF practice and view of the protocol to new level of awareness of more, not less doubt. My proposal for 2.5.4 which hopefully is on par in codifying 9 years worth of experience plus what I have read from others "views" in this less in regards to a true or false notion for the prevailing nature of "marking" the message in lieu of rejecting it outright. 2.5.4. Fail Per section 2.3, a "fail" result is an explicit domain policy violation statement that the client is not authorized to use the domain in the given identity. The -ALL policy is the domains intent to obtain a negative classification for the transaction with the client not authorized to use the domain in the given MAIL FROM or EHLO/HELO identity. For a negative classification, the checking software SHOULD choose one of two options: - reject the transaction at the SMTP level, or - accept, add a Receiver-SPF header and it SHOULD separate the message stream from the user's normal access to mail. If the checking software chooses to reject the transaction 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. The check_host() function will return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided by the sender's domain. For example: 550 SPF MAIL FROM check failed 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: 550 5.7.1 Please see http://www.example.com/mailpolicy.html If the checking software chooses to accept the message, it MUST trace|mark|report this failure by adding a Receiver-SPF header to the received message. See Section 7. In addition, it SHOULD separate the mail stream from the user as this can open a security issue for the user. Despite the out of scope nature of local mail policies, rejecting the failed SPF transaction is regarded a System Level local policy for global filtering for all users, where accepting and marking the message is regarded as a User Level Policy framework where good versus bad mail policies are implemented by separating mail on behalf of the user before the MUA access the mail. -- HLS Andrew Sullivan wrote: > No hat. > > On Mon, Aug 20, 2012 at 04:29:59PM -0400, Hector Santos wrote: >> So not sticking to 2119 is just the same as advocating a protocol >> design? > > What I intended to say was simply, "No new all-caps terms." > >> Which by your definition, the PROTOCOL has the compliance level or >> lack there of option to NOT mark NOR reject. > > No. There is no "compliance level" to the protocol. A protocol > specifies the necessary and sufficient conditions of behaviour for > something to be called an implementation of it. If an implementation > does not follow those conditions, then it is not conforming to the > protocol specification; but the IETF does not do "compliance", and > there are no protocol cops. > >> ways and thats by sticking with 2119 sir. It means the technical >> specification is to design a protocol with a mutual exclusive >> option: >> >> (o) do not honor hard fail >> (_) honor using SMTP REJECT (RFC 2119 compliance) >> (_) honor using SMTP ACCEPT+RECEIVE-SPF >> >> We are presuming a "Mark" means adding RECEIVER-SPF header. > > While these may be mutually exclusive options, it is entirely possible > for the text to leave open to the receiver which of the options to > use. This would still provide a complete specification, with > behaviour that covers all the possibilities while yet leaving local > policy to the local operator. As nearly as I can tell from your > message downthread, you actually agree that RFC 4408 leaves the > options open to the receiver. You appear to be arguing that we should > tighten this portion of the specification. But given the chairs' > recent ruling on a procedural question, and the results of the appeal > to the responsible AD, I argue that the WG could not tighten this > portion anyway. Therefore, what is correct for the text to do is to > lay out more clearly perhaps than it was in 4408 what the options > are. You seem to think it does that. > > If I have misunderstood your argument, perhaps you can state it less > colourfully so that I may understand it properly. If I have correctly > stated your argument, then it is time to let this thread die. > > Best regards, > > A > From agthisell@yahoo.com Wed Aug 22 03:57: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 5F44421F8615 for ; Wed, 22 Aug 2012 03:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IawqBxUUHoxl for ; Wed, 22 Aug 2012 03:57:34 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) by ietfa.amsl.com (Postfix) with SMTP id C77AB21F84B5 for ; Wed, 22 Aug 2012 03:57:33 -0700 (PDT) Received: from [98.138.90.48] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 10:57:30 -0000 Received: from [98.138.87.9] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 10:57:30 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 10:57:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 748940.39203.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 77642 invoked by uid 60001); 22 Aug 2012 10:57:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345633050; bh=srKPSiqeHNbyOVt8vc3T6IfYHAKZMns8HMaL1X57IMY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=OuH4VvVjJln623oByw+iZTRI5B9/8NyMvi/YDoKD+zMXwG9Wv1aDjt/cKEIFnSh6CX+bKTXVjKYsv6KtZ3i+uBqNuwedNrFuAOTjvfwMCw+0fP657Sf6J9zQAc2nlwCGi1umFhp8m20OXyQN/OmVJTnP8ZBi5eq1SKw/qiqjjoA= 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=L8HBwQJbJvVwHd1xkUJlycwWtVjZaiy46m1FpDjSvfXZSXhWUCilt+/pnEu0HiooWdmfLYGyMw7FNThP/OeLBEZfIytETV5Vqss11QnK/QtFUCvPUTq0rPTsz0Jwifu20OWG113okHZR+W7SuIv0EzPCUT/IGSjq6WW6BCpD+F0=; X-YMail-OSG: cG19D3IVM1nmNdG_Ce4hBuEWa2pbdV2ZzNNz9FeGRvGApgB fIwf9kIzKp6R.Tny2o7fEUhXB4v9vSon3elmUnRjI1v.kPIznfBQBI46W.wy dosQCMSo055Kz50QxHR3v7B2COK2v40pD.5_3C5ElodNjHsTJZEWsxBQlDi8 kXLbcC2WFex1psH3lwcjiCMSixxRq.LhowLxPJxnpQa4qAVE35oD.LfG34Zh l4Sx7ERrd_jOdsffWo4uvjx66BJWLSznUWlFUPJb9MEUZL6AJnbfWOqpsSER 2vVW.ZwiC2on6itAYkefcrc9Zocn2XNYetiHRDu4qL2uHSLjWLWVxEhjtVoU yYBxk29CxXQm5.XxMFBPaXNU1dHJ2QlFqdS7xjCC851tffkUq0aGaBBcX0XY Iy0EN_h59CJZ457J21lzVSIzVKrdGiycspNzNQcyem_xbnjoRFcPeyaMiDPR RqfcU_Z1FYsRwEC80J2o- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Wed, 22 Aug 2012 03:57:30 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1345633050.76287.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Wed, 22 Aug 2012 03:57:30 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 10:57:34 -0000 First, let me say that I have reviewed all changes since RFC4408. > I believe BIS has been watered down with this increase obvious emphasis on > local policies (DUH!). No it hasn't. If the new wording makes you see what has always been there, then the new wording is good. From hsantos@isdg.net Wed Aug 22 08:00: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 3464F21F85AD for ; Wed, 22 Aug 2012 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+r6aNAq4mIe for ; Wed, 22 Aug 2012 08:00:13 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50C5C21F85AA for ; Wed, 22 Aug 2012 08:00:12 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1498; t=1345647608; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bxuDlX4XCnwir1/mbLwu2Fwyp6c=; b=jrLG/p5odgKJoUt+XN2i w3cIUD37v6Dr1jx5Vz9mPkcD9Pd8pba8O+GKzLX27XIGhRTejcs4/6ZXQ3ti5TzM mdxV/A+mcjAd36oZQZ+WojOVYT6L8nDWBp1NN/9TtROZtB1F5E1i9BqzCGsZLA4z CvAGXgMW2V+mJyxlJt9LJww= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 11:00:08 -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 1669406597.367.2924; Wed, 22 Aug 2012 11:00:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1498; t=1345647417; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Z345Iqk d54ZztIeEltwQIPOGvwgmAosbs+CoVuVrT9I=; b=sZ709/1DGCuSNtqBsX4wM8i DY+3J9FfL94vw5lxFuUGFGxHV/wOWQ9nD6f2ElUQTTYJv9/MCADTWAqvsygvH6Ju D0K4AhC6mPb5d0vsTXqtZWY8LuB2I8esMtNgQaz1hPupWOSczyvDV7YrdBRtZqG4 8JY1s6HefjQK5X+v6u4Q= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 10:56:57 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2268215755.7.8100; Wed, 22 Aug 2012 10:56:56 -0400 Message-ID: <5034F418.8090905@isdg.net> Date: Wed, 22 Aug 2012 11:00:40 -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: <1345633050.76287.YahooMailClassic@web125401.mail.ne1.yahoo.com> In-Reply-To: <1345633050.76287.YahooMailClassic@web125401.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Arthur Thisell Subject: [spfbis] Issue 29 (part 2) New 10.7 Security Section Required X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 15:00:18 -0000 Arthur Thisell wrote: > First, let me say that I have reviewed all changes since RFC4408. > >> I believe BIS has been watered down with this increase obvious emphasis on > local policies (DUH!). > > No it hasn't. If the new wording makes you see what has always been there, then the new wording is good. Then lets get back to basic and address the original issue 29 by adding a new security section 10.7. 10.7 Marked Failed Mail Exposure Section 2.5.4 and 9.3.2 reinforces the local policies concept that SPF receivers have no formal protocol requirement to enforce rejection of mail which were detected using -ALL policies. Section 2.3 highlights the domain intent and expectation for such negative classification. However, the receiver is under no technical obligation to take any action for SPF failed results. If the alternative marking is done, it is conceivable local backends will still pass the mail to users with no additional red flags or indicators of SPF fail. This will require more advanced MUA to understand the Receive-SPF headers. Thus under such cases, there is a possibility users can be exposed to harmful mail when the backend added the Receiver-SPF but did not further separate the message from the user's normal everyday mode of reading/accessing mail. Backends needs to take precautions of marking messages resulting from SPF -ALL failed transactions but were not rejected as prescribed in section 2.5.4. -- HLS From ajs@anvilwalrusden.com Wed Aug 22 08:37: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 91D9B21F8598 for ; Wed, 22 Aug 2012 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HznCnCWchfM5 for ; Wed, 22 Aug 2012 08:37:06 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC721F8595 for ; Wed, 22 Aug 2012 08:37:05 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2682E8A031; Wed, 22 Aug 2012 15:37:04 +0000 (UTC) Date: Wed, 22 Aug 2012 11:36:56 -0400 From: Andrew Sullivan To: Hector Santos Message-ID: <20120822153655.GA41334@mx1.yitter.info> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> <5032E596.5020507@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5032E596.5020507@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, presnick@qualcomm.com Subject: [spfbis] Notice of unacceptable behaviour under BCP 94 (was: Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection]) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 15:37:06 -0000 Dear Hector, Your message of 20 August, quoted in its entirety below, included _ad hominem_ attacks against another participant. _Ad hominem_ is a fallacious form of argument wherein the person arguing attacks the person holding an opposing position, rather than attacking the position itself. This is not acceptable, and we believe you have been warned before. My co-chair SM has contacted you off-list, under the procedures in BCP 94, but you have refused to take what we regard as rectifying action. Accordingly, please understand this message as a formal warning under the procedures of BCP 94 that, if we observe continued behaviour of the sort you have exhibited, we shall suspend your posting privileges to the spfbis mailing list for 30 days. Behaviour of the sort includes anything that we believe to be needlessly personalized, and especially includes _ad hominem_ forms of argument. We will also treat returning to points that have been closed without raising new arguments as attempts to disrput the functioning of the Working Group. We will act without further warning in such an event. If we take that action, and, after restoration of your privileges, we observe you to return to disrupting the work of the group, we shall undertake action under BCP 83. Sincerely, Andrew (for the chairs) On Mon, Aug 20, 2012 at 09:34:14PM -0400, Hector Santos wrote: > Murray S. Kucherawy wrote: > >On Mon, Aug 20, 2012 at 2:29 PM, Scott Kitterman wrote: > >>The new revisions present exactly the same technical requirements that RFC > >>4408 presented. There is no change. There is some change in how the words > >>are arranged and some added background about why certain choices might be > >>made, but the design choices that are available to the implementer are exactly > >>the same. Nothing has changed. > > > >+1. Moreover, the chairs declared this a closed topic back in April. > >Could we please spend our energy on topics that are open? > > What topic is that? Issue 29? Is this ISSUE 29 closed? Scott > indicated it was still open. > > >I'd like to get this work finished before my daughter hits high school. > > You are the one that is creating a mess for SPF. Not me buddy. The > controversies have begins with you, saying dumb stuff like above. I > am not the one ignoring input from participants and then finding you > were wrong in the end. > > There is a still a problem with the rev text. The rev changes, > which I presumed is your work, needs serious work with added doubt > added to the protocol. Learn to accept the criticism and concerns > and work with it rather than ignoring it and brushing it off. > -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Wed Aug 22 08:56: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 EDF2D21F85AD for ; Wed, 22 Aug 2012 08:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBSOrUF539nl for ; Wed, 22 Aug 2012 08:55:59 -0700 (PDT) Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D27521F85F4 for ; Wed, 22 Aug 2012 08:55:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1514; t=1345650948; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XDpkpE5YPmf9rOH21azHauyelSY=; b=LeCxfl8qTraOggkCyc7w HhSFAQKy4fNj4mSPgY1le+bVGSKUMoeX0TW+hHJWo4OYwGR5jc4CBqlMeeItpwJS tWBHynqZbN1ftm7+enHSMbk6fm7VkV+0RkhZcsfwpEDh1p0TI/jgJ9nEH6/ZcNji Q+bZEfWnwqscKtGb/TJvxhQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 11:55:48 -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 1672746579.367.3096; Wed, 22 Aug 2012 11:55:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1514; t=1345650756; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/BydaoC 10DLXo+5WMZFWzGNveKCzmLA2G9HTH7gg6pU=; b=VEcRQgAOzKd6weSXh/Cj0bx qxodOovXjXHGbtNAIvFejUArxaMGbCk64hGNIJElvYrfLLw7kcijNo4hyRCGtUdC kMNWnjo6qAe3Vhi81J0a21hdl839+/iE3W5kZ+pMh1yPcCcv5jWkm16xPGdh5qR9 VwgEksuCRcaneACDGDa0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 11:52:36 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2271554192.7.5960; Wed, 22 Aug 2012 11:52:35 -0400 Message-ID: <50350126.2010506@isdg.net> Date: Wed, 22 Aug 2012 11:56:22 -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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 15:56:00 -0000 I am getting mixed input on issue 29 as closed or not. I would like to have it reopen and proposed a new 10.7 section added to help implementators closed the SPF fail result security loophole. 10.7 Marked Failed Mail Exposure Section 2.5.4 and 9.3.2 reinforces the local policies concept that SPF receivers have no formal protocol requirement to enforce rejection of mail which were detected using -ALL policies. Section 2.3 highlights the domain intent and expectation for such negative classification. However, the receiver is under no technical obligation to take any action for SPF failed results. If the alternative marking is done, it is conceivable local backends will still pass the mail to users with no additional red flags or indicators of SPF fail. This will require more advanced MUA to understand the Receive-SPF headers. Thus under such cases, there is a possibility users can be exposed to harmful mail when the backend added the Receiver-SPF but did not further separate the message from the user's normal everyday mode of reading/accessing mail. For example, for POP3, the stream may need to be separated and not made available for pickup. For online access, like Web-based Mail or IMAP, the backend has better control of how mail is filtered, sorted, displayed and rendered. Backends needs to take precautions of marking messages resulting from SPF -ALL failed transactions but were not rejected as prescribed in section 2.5.4. -- HLS From hsantos@isdg.net Wed Aug 22 09:12: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 0959D21F859C for ; Wed, 22 Aug 2012 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgU+R-YckzIy for ; Wed, 22 Aug 2012 09:12:31 -0700 (PDT) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 929EA21F857D for ; Wed, 22 Aug 2012 09:12:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3459; t=1345651944; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lSQ4+iXTTX/l+aAbiCnSCszbxsc=; b=JSgJdnNXL2mR7B+eBW3z AMbEFXxPDh6c6S3x1uCiSiYV4enTtpozNkcfQ5UgmzhEw+1LL4wfmPY9Z+FTX3iu RA+PcuwG3YzXM/gfgWtqSXuq8G6NpwrgNUkErGL4tc3rwuE6VAbHXearZU1b0IdK SxOBAl1RXVKhvshNaqGhhdg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 12:12:24 -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 1673741803.367.4484; Wed, 22 Aug 2012 12:12:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3459; t=1345651755; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hRgjuX/ mva4M1CNjWLfLI/UmGjDYX0TcMOR3nRhppbM=; b=26NYe8e0XDdahfu1JVq1X86 Aqt7eJ3DrApbrTR6u06zE1F2cC9oa654OK0ubkb0ZADecJnX/Tr6yjuQQIlaYZ53 iZC8CsUeAhMVDlAnwnAIbRaG7cVv6AcvzFt2HcSN/ATWl05Xu4QJb+zIFQnpy7ij MDAZ+pJgS8vGK6JT3TS8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 12:09:15 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2272553208.7.8152; Wed, 22 Aug 2012 12:09:14 -0400 Message-ID: <5035050D.1090006@isdg.net> Date: Wed, 22 Aug 2012 12:13:01 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120820120924.098e65a0@elandnews.com> <5032AA40.1000902@isdg.net> <1644953.F7dC6kdRo1@scott-latitude-e6320> <5032E596.5020507@isdg.net> <20120822153655.GA41334@mx1.yitter.info> In-Reply-To: <20120822153655.GA41334@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, presnick@qualcomm.com Subject: Re: [spfbis] Notice of unacceptable behaviour under BCP 94 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 16:12:32 -0000 I will not apologize for this incident as the person in question has continued to offend me with indirect ad hominem attacks with attempts to shut off my input, despite making blatant statement of facts that are questionable and in many cases incorrect. I will minimize my input to serve my SPF interest for our product line and will avoid Murray to the fullest extent but I will issue a formal complaint on my own if his indirect unprofessional offenses continue towards me to limit and shut down my input does not stop. Do as you wish. Sincerely, Hector Santos, CEO/CTO Santronics Software, Inc. http://www.santronics.com Andrew Sullivan wrote: > Dear Hector, > > Your message of 20 August, quoted in its entirety below, included _ad > hominem_ attacks against another participant. _Ad hominem_ is a > fallacious form of argument wherein the person arguing attacks the > person holding an opposing position, rather than attacking the > position itself. This is not acceptable, and we believe you have been > warned before. My co-chair SM has contacted you off-list, under the > procedures in BCP 94, but you have refused to take what we regard as > rectifying action. > > Accordingly, please understand this message as a formal warning under > the procedures of BCP 94 that, if we observe continued behaviour of > the sort you have exhibited, we shall suspend your posting privileges > to the spfbis mailing list for 30 days. Behaviour of the sort > includes anything that we believe to be needlessly personalized, and > especially includes _ad hominem_ forms of argument. We will also > treat returning to points that have been closed without raising new > arguments as attempts to disrput the functioning of the Working Group. > We will act without further warning in such an event. > > If we take that action, and, after restoration of your privileges, we > observe you to return to disrupting the work of the group, we shall > undertake action under BCP 83. > > Sincerely, > > Andrew (for the chairs) > > On Mon, Aug 20, 2012 at 09:34:14PM -0400, Hector Santos wrote: >> Murray S. Kucherawy wrote: >>> On Mon, Aug 20, 2012 at 2:29 PM, Scott Kitterman wrote: >>>> The new revisions present exactly the same technical requirements that RFC >>>> 4408 presented. There is no change. There is some change in how the words >>>> are arranged and some added background about why certain choices might be >>>> made, but the design choices that are available to the implementer are exactly >>>> the same. Nothing has changed. >>> +1. Moreover, the chairs declared this a closed topic back in April. >>> Could we please spend our energy on topics that are open? >> What topic is that? Issue 29? Is this ISSUE 29 closed? Scott >> indicated it was still open. >> >>> I'd like to get this work finished before my daughter hits high school. >> You are the one that is creating a mess for SPF. Not me buddy. The >> controversies have begins with you, saying dumb stuff like above. I >> am not the one ignoring input from participants and then finding you >> were wrong in the end. >> >> There is a still a problem with the rev text. The rev changes, >> which I presumed is your work, needs serious work with added doubt >> added to the protocol. Learn to accept the criticism and concerns >> and work with it rather than ignoring it and brushing it off. >> > -- HLS From sm@elandsys.com Wed Aug 22 10:01: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 8A2BC21F860B for ; Wed, 22 Aug 2012 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jI+uxuTAkrQ for ; Wed, 22 Aug 2012 10:01: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 DB67221F8606 for ; Wed, 22 Aug 2012 10:01:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MH18eU025310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 10:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345654881; bh=gq6LAjqE5UOewnoOYJXGDwMku4wpDvtp/KHKigY1O9M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sgEnGMd91k7b/EkFdCvA4th5GTezUhBNYx88fQJcH4Zgpcfw6SR81QvgGz43Km5JG P7imr8xu7ceNoatqiWIQ12qhG0KY/ABMdQCLmzfCEceB57aAMiDGT8WIsyae8Znemd G/8SrTwfhF4yna71P0bgk0eny1+FF8dsmsMCLBrg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345654881; i=@elandsys.com; bh=gq6LAjqE5UOewnoOYJXGDwMku4wpDvtp/KHKigY1O9M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oyCi11BnPNFUnEYZXKs47YaXCot+1a6o2Y0x95puWJ1T8rWPFu+uIgg2b5GC8Vr8p QCq6oS2TVnCExMH7dJi/Szie0VbjWXwToGPCgq8Ti5ndTLn1NQ7oisnCmwN6NVop2L nmy7yCtH3igBXjMWTT5sQI2S7x0URIV/qsjLYUNw= Message-Id: <6.2.5.6.2.20120822090840.09fecb90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 10:01:01 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <50350126.2010506@isdg.net> References: <50350126.2010506@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 17:01:25 -0000 Hi Hector, At 08:56 22-08-2012, Hector Santos wrote: >I would like to have it reopen and proposed a new 10.7 section added >to help implementators closed the SPF fail result security loophole. Issue #33 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/33 ) has been opened in response to the above request. I will post a message to the SPFBIS mailing list when the topic is open for discussion. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Wed Aug 22 10:03: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 BB7A321F8545 for ; Wed, 22 Aug 2012 10:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_NOSCRIP=2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ6Uuzr-ynDs for ; Wed, 22 Aug 2012 10:03:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9812621F84A0 for ; Wed, 22 Aug 2012 10:03:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EE59920E410A; Wed, 22 Aug 2012 13:03:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345655027; bh=rNw/atFPUF9vmczymT8d1utbJg4gPhjjlmAqbg3GECc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GnTpLQDTy8zV+FPPXl4wBUDCPUe1Y9MR+aaN8pOLj5yIF8iVFTUxTRZ2em20Ihj5f NE2wTrrWfq0/wZMS+02One07KiAXXGVjXvV22ojoKHqjSHFfvNMW+61UMMzg+aPsVm sq6P/LtkBTeYFE4oh/h2xLP1goTAWv009x9oY9qw= Received: from scott-latitude-e6320.localnet (c-76-111-154-68.hsd1.de.comcast.net [76.111.154.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9FA7A20E4086; Wed, 22 Aug 2012 13:03:46 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 13:03:45 -0400 Message-ID: <22809811.9sJZkmpsv2@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50350126.2010506@isdg.net> References: <50350126.2010506@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] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 17:03:59 -0000 On Wednesday, August 22, 2012 11:56:22 AM Hector Santos wrote: > I am getting mixed input on issue 29 as closed or not. It's still open in the issue tracker. The last status I put there is: " New text in the -04 draft should address this issue. Waiting for WG review.' As I've said many times before, me putting something in a draft doesn't carve it in stone. > I would like to have it reopen and proposed a new 10.7 section added > to help implementators closed the SPF fail result security loophole. > > 10.7 Marked Failed Mail Exposure > > Section 2.5.4 and 9.3.2 reinforces the local policies concept > that SPF receivers have no formal protocol requirement to > enforce rejection of mail which were detected using -ALL policies. > Section 2.3 highlights the domain intent and expectation for > such negative classification. However, the receiver is under > no technical obligation to take any action for SPF failed results. > > If the alternative marking is done, it is conceivable local backends > will still pass the mail to users with no additional red flags or > indicators of SPF fail. This will require more advanced MUA to > understand the Receive-SPF headers. > > Thus under such cases, there is a possibility users can be exposed > to harmful mail when the backend added the Receiver-SPF but did not > further separate the message from the user's normal everyday mode of > reading/accessing mail. For example, for POP3, the stream may need > to be separated and not made available for pickup. For online access, > like Web-based Mail or IMAP, the backend has better control of how > mail is filtered, sorted, displayed and rendered. > > Backends needs to take precautions of marking messages resulting > from SPF -ALL failed transactions but were not rejected as > prescribed in section 2.5.4. There's no prescription for rejection in 2.5.4. I think this gets into too much detail about internals of final delivery to the user. I think it would be sufficient to add a sentence to the second paragraph of 9.3.2. How about: SPF fail results can also be used as one input into a larger set of evaluations which might, based on the overall evaluation result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). Developing the details of such an approach have to be based on local conditions and requirements. Using SPF results in this way does not have the advantages of resource conservation and immediate feedback to the sender associated with SMTP rejection, but could produce fewer undesirable rejections in a well designed system. Such an approach might result in email that was not authorized by the sending ADMD being unknowingly delivered to end users. Scott K From agthisell@yahoo.com Wed Aug 22 10:25: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 6657A21F85BB for ; Wed, 22 Aug 2012 10:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF5S6Q+eKM-n for ; Wed, 22 Aug 2012 10:25:25 -0700 (PDT) Received: from nm26-vm6.bullet.mail.ne1.yahoo.com (nm26-vm6.bullet.mail.ne1.yahoo.com [98.138.91.119]) by ietfa.amsl.com (Postfix) with SMTP id 8BA5B21F8545 for ; Wed, 22 Aug 2012 10:25:25 -0700 (PDT) Received: from [98.138.90.54] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 17:25:20 -0000 Received: from [98.138.226.165] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 17:25:20 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 17:25:20 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 19517.45520.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 67586 invoked by uid 60001); 22 Aug 2012 17:25:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345656319; bh=SRAvkpJMfQUk4G7PXX/JWBFaDKULHcUjxhzgUnQ2Sr8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=o6ytOLLpZ3vBf2cNud8SEolofqJdMiexI26jo4Ft4d4vSELIt7M58NO7QzdtRGMKXXsUmNaCjaYxC67WludZuct3wIMdnLWLNKIi3oSJwNi4GpaxKfbkprmeiiGU2Clgv1UHB5P5PV+h2eLaqFMRI8ZuXOMPNePdM35uLZApjkA= 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=eT/wTvVmMZ0oca0biPPhWQE762wwXEmiglHOuvmwKxbgRw3qDt4KJLzh6lcgziG0V3v7GxS1H1ubNNKB4hu7JnemlfCYRMTvtCBAJfWKT6KKLcl1tnHwTibvMhYIQD7fsYXTZKtM7331A3SmNGjpxzceFhKP625ZqgvT2Ryho4c=; X-YMail-OSG: loeA0qgVM1moyCooeh7Elm0DrVAA3XeTSY8CimizvoNPNu8 8jUh8FIvXWhx.SDtd1sMtf._Qe_TCGuZtDIMfb9OUyhR.Yu9F06pxSUUm2Tt sh9UaeWDgDBNl71OQBwtOxX5ZEGAH97qQuQN9SD1_EmodokfE4cGvHEvt_Eb 2eKv0ASaTTo.mDyrp0faBIjivH7DcchTCfNtS7F3de5HMBIFaDY4dy2b3Ayo z7N7bmW9H06XSlyJTDCSwiAfe2_rUNq4ZxQSjmHAR6ieX4HDJQKTcjuQjaPb dJZxhRQ214oaSMvmugcKa7UyZ6EUeQroDMhIpMysSvefkc3yyVp_H_sd8sbn hBEgIfCfD6Izh7ebjG8mHgjr6BSceS8YWvEKTRN5XlU1f2cZ9dVzpPRjUxqC dQU24L.tiCV13bcydW7_jptYqqJmC.Q55feG5iGgl6DI5aJDnxVgRhFJHyEd B8rz5uUq9HdtJd9erJcY- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Wed, 22 Aug 2012 10:25:19 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1345656319.64623.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Wed, 22 Aug 2012 10:25:19 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] review of 4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 17:25:26 -0000 I mentioned this in a message earlier today that I had reviewed all changes since RFC 4408, and I had mentioned to Scott off-list that I hadn't found anything worth mentioning. But, what the heck, here is my list anyway. First, I cringe at how much 4408bis has grown. RFC 4408 was already 46 pages long, all of RFC 2821 was only 79. RFC 4408bis is now 63 pages (with 3 pages of change notes that I've excluded). I realize a lot of the new text is in the non-normative section 9, but there is a lot of other stuff added here and there. Just like unneeded features/options make it harder to implement a spec correct, adding unimportant verbiage makes it harder to find the important stuff. Second, in the table in section 5.2, it still says to "throw" a temperror. I thought we were trying to get rid of that term. Last, in section 9.1.1, an A record domain name "authorized_spf" is used, which isn't a valid host name. I'm not sure if that was intentional or not, but most real SPF records would use a real host name. There are a huge number of other changed that I really don't care about. Ok, changing lowercase "may" to lowercase "might" is probably an improvement, but I could live with it either way. Removing the perl heritage of using camel-case for the SPF results is a little sad, a lot of the early development was on the perl list. It really isn't important though. I know there are a few open issues on the problem tracker, but I would happy to see -05 sent off just the way it is. I fear that with so much time before our dec deadline, people are going to start filling up 4408bis with unimportant personal pet peeves. (We all have them. I personally hate the complexity of the macros, ptr: in general, and many others.) From superuser@gmail.com Wed Aug 22 10:49: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 1214521F8576 for ; Wed, 22 Aug 2012 10:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8lN2Q9G52zC for ; Wed, 22 Aug 2012 10:49:24 -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 221D921F8567 for ; Wed, 22 Aug 2012 10:49:13 -0700 (PDT) Received: by lahm15 with SMTP id m15so753225lah.31 for ; Wed, 22 Aug 2012 10:49: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=ZRBmoyOnBX0tzHIWETxuDJqt4WVxK1cUB1iU70Vo1SE=; b=OZe7F7owpyDeyzj+MT2zKAPTG4QCMiHRC6Vlg8djTd0sKNfClFTgwZ/o8L9m2vyQD/ +xmJmpl6mGLW7NWg88j9dspr1qM+dgSUK4VlF97KGaiQrJkRqoEAINQ7/4GciHamsCuu gpslyPZPmVlDdNYHIwYbADvEBTZUJ+wcCZuBPBi45rlIo9ycqgtThndkDjdDYSO4Dx1q lsW8/r5SeA41lKCqsxfVIpzaJb6B9mSyDQjf/IrSZPDrZWcdwxxmDO8bV/RQ6SFC4V4L TnwNTVu6FlhZaS8jHVfcJIVlDTRqcjUFa4WqwDNmgLt6HwlXzph3RHgjFcTjmQVe6iZ7 qPPw== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr21949464lab.25.1345657753095; Wed, 22 Aug 2012 10:49:13 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 10:49:12 -0700 (PDT) In-Reply-To: <22809811.9sJZkmpsv2@scott-latitude-e6320> References: <50350126.2010506@isdg.net> <22809811.9sJZkmpsv2@scott-latitude-e6320> Date: Wed, 22 Aug 2012 10:49:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 17:49:25 -0000 I still think all of this is unnecessary. The current document doesn't demand either rejection or marking, and that's the right thing to do, and in fact reflects the varied current practices. With respect to the proposal: On Wed, Aug 22, 2012 at 10:03 AM, Scott Kitterman wrote: > I think this gets into too much detail about internals of final delivery to the > user. I think it would be sufficient to add a sentence to the second paragraph > of 9.3.2. How about: > > SPF fail results can also be used as one input into a larger set of > evaluations which might, based on the overall evaluation result in > the email being marked negatively in some way (this might be via > delivery to a special spam folder, modifying subject lines, or other > locally determined means). Developing the details of such an > approach have to be based on local conditions and requirements. > Using SPF results in this way does not have the advantages of > resource conservation and immediate feedback to the sender associated > with SMTP rejection, but could produce fewer undesirable rejections > in a well designed system. Such an approach might result in email that was > not authorized by the sending ADMD being unknowingly delivered to end > users. I guess I hadn't read 9.3.2 in a while. The first sentence of this paragraph seems to be mangled. Apart from that, the added sentence seems fine to me. -MSK From vesely@tana.it Wed Aug 22 11:01: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 5421B21F8630 for ; Wed, 22 Aug 2012 11:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPKR-5hqzGUd for ; Wed, 22 Aug 2012 11:01:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5D721F8625 for ; Wed, 22 Aug 2012 11:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345658505; bh=AZM8A0XjgeS4tpsqZiFyPOIaP5GJJJGx2LA/gXxKAk4=; l=1245; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=CElVB7jT40eQDuHcI3tZt0+neWs4FesDnHlD7T2yN4EjZh3t89Pdz6/jTHHjHDn5c hISgZEvsanzMD4towUA+W07bQv1236h82GpBUB/M0hczNRDDBtTZvknAwQ7vuMrwjy pzxKy54c+9YJy7a8yk1rn/n2R54ozxJOM2vJEqAA= Received: from [109.113.208.58] ([109.113.208.58]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 22 Aug 2012 20:01:44 +0200 id 00000000005DC035.0000000050351E89.00003CA9 Message-ID: <50351E82.10502@tana.it> Date: Wed, 22 Aug 2012 20:01:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 18:01:49 -0000 On Mon 20/Aug/2012 19:44:17 +0200 Murray S. Kucherawy wrote: > On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >> for me. However, from the second paragraph onward, the text of >> Section 2.5.4 is written assuming that the failed identity is MAIL >> FROM. (I partially retract the "+1" I gave on >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01844.html ) > > So change "during the SMTP transaction" to "via the SMTP session"? Or > "dialog" instead of "session"? Then it doesn't matter whether you're > inside a transaction or not (meaning it applies to HELO/EHLO or MAIL > or RCPT equally). Something like that... I guess "on the fly" would require a detailed definition. There are some 8 occurrences of that phrase. >> Technically, "during the SMTP transaction" means that the transaction >> has to be started, which is after the last HELO/EHLO command. Can we >> say "before accepting the SMTP transaction" instead? > > Not quite. Sessions begin with HELO/EHLO; transactions begin with MAIL. So what? If rejection comes before a transaction starts, then there is no transaction. Rejection was still before the transaction end. Like turning off the alarm before it rings... no? From superuser@gmail.com Wed Aug 22 11:03: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 46A4E21F8497 for ; Wed, 22 Aug 2012 11:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Eg8c4mvJxGb for ; Wed, 22 Aug 2012 11:03:14 -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 A851D21F8448 for ; Wed, 22 Aug 2012 11:03:13 -0700 (PDT) Received: by lahm15 with SMTP id m15so761550lah.31 for ; Wed, 22 Aug 2012 11:03:12 -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:content-transfer-encoding; bh=KUf0U2dLfDLvPq3YYVEK2zZX/xn8RDae26hWQxGQW/k=; b=RZVTePkJtQ0qg0cqKSI7fG2YDIsGpYbjMGQG+97LrBe25v2rf9bpuWOlyDjz0TerCl Tyn7KSQYfnnprYhHb68h1K9Sex4K3cqv5Gy3+l17husIHMPu+tjPcwHfTeTvTm9mzfx7 qE7asrYS0yxIrr/OaOJdIpZbgWkWSv4opQLoRJUr5RzPPHYkSQ+Focp51FBq6eZTf7MJ DF58q5HEGNY8p0Akv5dfdcwoYL/UaLldS77y1jWhcOKlbBqLU+B7/oLRGfcve9mHylGj zdSUstSjJVyK8rHqTRlPg8DGrH1HK6PdWWVhlLgB5h9CElAgVnyuRjrE5Y03IORY9j3R w9Ag== MIME-Version: 1.0 Received: by 10.112.83.229 with SMTP id t5mr9699253lby.8.1345658592491; Wed, 22 Aug 2012 11:03:12 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 11:03:10 -0700 (PDT) In-Reply-To: <1345656319.64623.YahooMailClassic@web125405.mail.ne1.yahoo.com> References: <1345656319.64623.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Wed, 22 Aug 2012 11:03:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] review of 4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 18:03:16 -0000 On Wed, Aug 22, 2012 at 10:25 AM, Arthur Thisell wrot= e: > I mentioned this in a message earlier today that I had reviewed all chang= es since RFC 4408, and I had mentioned to Scott off-list that I hadn't foun= d anything worth mentioning. But, what the heck, here is my list anyway. > > First, I cringe at how much 4408bis has grown. RFC 4408 was already 46 p= ages long, all of RFC 2821 was only 79. RFC 4408bis is now 63 pages (with = 3 pages of change notes that I've excluded). I realize a lot of the new te= xt is in the non-normative section 9, but there is a lot of other stuff add= ed here and there. Just like unneeded features/options make it harder to = implement a spec correct, adding unimportant verbiage makes it harder to fi= nd the important stuff. Here's a side-by-side diff of the two documents: http://www.blackops.org/~msk/spfbis/draft-ietf-spfbis-4408bis-05-from-rfc44= 08.diff.html A cursory review of this, which mainly involved me spinning the mouse wheel until big sections of added/removed text came up, didn't cause me much alarm. Most of the added text covers evolutionary history or things we've agreed are useful clarifications, or the aforementioned "change since" stuff. (A couple of scan-time notes: (a) typo in 9.3 while I was scrolling around: "dispositive on it's own" should be "dispositive on its own"; (b) 4.5 "must be discarded" should be "MUST be discarded".) -MSK From superuser@gmail.com Wed Aug 22 11:10: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 C408921F8610 for ; Wed, 22 Aug 2012 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQV4XD5IEZkS for ; Wed, 22 Aug 2012 11:10:44 -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 BA4C721F85C0 for ; Wed, 22 Aug 2012 11:10:43 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so846280lbb.31 for ; Wed, 22 Aug 2012 11:10:42 -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=MWwx5gssQD9eiIYIURSbrVn+uafzbNDrLTZfdjckdg8=; b=XWBYsK7nlTZdqXj0mOViVw61tjVQj3RLZvZVH7YPyBvM7s16wpe5UDf8UqgGsp/aNv 9dM/oZmGg+qMTflyYmyDjpTvdtlCnaOeCMwq7rmwziJSLvm9KivWbgZDw40t9ETD6EW1 /2AgOUt1rrDq/z0jRyrYI5hGtWgn8vKi9R6PdKjNGiGUkO3Z7REnjwB0I8mfwSgrUO2Z vYMm3KkcAaNJiMTqRjk6QdamoMQFd2j1mIvDZTZdaekhWeNPE4fGyDgcS87AkDvwIs0y 2UObOSw3G2276NzeFjgI1/G/z777PtY2+Z4HEUFZkuC+JUACGzMr9rFONzRjLBLdW7XD W4JQ== MIME-Version: 1.0 Received: by 10.112.83.229 with SMTP id t5mr9708877lby.8.1345659042713; Wed, 22 Aug 2012 11:10:42 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 11:10:42 -0700 (PDT) In-Reply-To: <50351E82.10502@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <50351E82.10502@tana.it> Date: Wed, 22 Aug 2012 11:10:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 18:10:44 -0000 On Wed, Aug 22, 2012 at 11:01 AM, Alessandro Vesely wrote: > On Mon 20/Aug/2012 19:44:17 +0200 Murray S. Kucherawy wrote: >> On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >>> Technically, "during the SMTP transaction" means that the transaction >>> has to be started, which is after the last HELO/EHLO command. Can we >>> say "before accepting the SMTP transaction" instead? >> >> Not quite. Sessions begin with HELO/EHLO; transactions begin with MAIL. > > So what? If rejection comes before a transaction starts, then there > is no transaction. Rejection was still before the transaction end. > Like turning off the alarm before it rings... no? I'm challenging your definition of "transaction" in the context of SMTP, not with respect to SPF. In both cases there's no completed transaction (which is all SPF cares about), but you can't say "during a transaction" if the only thing that's happened so far is HELO. -MSK From vesely@tana.it Wed Aug 22 11:29: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 2715D21F8665 for ; Wed, 22 Aug 2012 11:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Rj4UhiyCBSU for ; Wed, 22 Aug 2012 11:29:25 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A53BE21F8610 for ; Wed, 22 Aug 2012 11:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345660161; bh=gKhn7wbtcs+U8+4uDvA1kP2k4pQNneMq0180tn3n3Ys=; l=1852; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ewmhr4wNJrZlIJvnDT7s43q4wA9SsmwAo78nWOIspoZP71ucBnqYJtlBAj52QUIgI ArHlSTz+gYGMyEeXnvBi5gWc19w9dJtx1/PhYlOA/j7fmSypbDa2HhtLhCsqdqllDp TN0hLX4eMhtt8wcMx/qWzoGVATVSfhxMp7t4Ec1w= Received: from [37.182.16.37] ([37.182.16.37]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 22 Aug 2012 20:29:18 +0200 id 00000000005DC03F.0000000050352500.0000429F Message-ID: <503524F7.1020802@tana.it> Date: Wed, 22 Aug 2012 20:29:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> In-Reply-To: <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:29:26 -0000 On Tue 21/Aug/2012 19:23:48 +0200 S Moonesamy wrote: > At 00:40 21-08-2012, Alessandro Vesely wrote: >> Since 5.7.1 is given in the example, the added meaning of a SHOULD is >> that there are serious issues that the receiver should be aware of >> before using a different code. Correct? >> >> In that case, would it be overly picky to remove the SHOULD for 550 >> and just use it for X.7.1? E.g. >> >> The receiving server MAY reject messages using codes as specified >> by SMTP ([RFC5321]). If Enhanced Mail System Status Codes are >> supported, it SHOULD use 5.7.1 ([RFC3463]). > > The above question is one which I might ask. One of the problem, > which is generally referred to as a rathole, is that the working group > would have to be picky about all the RFC 2119 key words which are > already in RFC 4408. That's going to end up as a lot of work. In general, I prefer clarity over formal purity. But this particular knot isn't overly clear either. Discussing the semantics seems to be one of those thing, like defining spam, that can go on for ages without reaching any useful conclusion. Formalism, in this case, seems to offer a neat hold, allowing us to handle the question of how to gear policies into protocols without generating too much heat. As we have a restricted charter and the protocol is well established already, it should be easy... > The WG Chairs would have to see whether there is an adequate number > of WG participants to review the changes. I am aware that some > individuals who committed to review the WG work have not done that. > My opinion is that all this would end up as a WG Chair problem. It > is unlikely that the Responsible AD would try to convince me to the > contrary as he might have a guess about I would do then. :-) I hope the WG can stay away from drastic measures. From agthisell@yahoo.com Wed Aug 22 11:56: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 6E20421F867F for ; Wed, 22 Aug 2012 11:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBIRSA0uJXlf for ; Wed, 22 Aug 2012 11:56:00 -0700 (PDT) Received: from nm26-vm4.bullet.mail.ne1.yahoo.com (nm26-vm4.bullet.mail.ne1.yahoo.com [98.138.91.186]) by ietfa.amsl.com (Postfix) with SMTP id 4E47021F867D for ; Wed, 22 Aug 2012 11:56:00 -0700 (PDT) Received: from [98.138.90.57] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 18:55:55 -0000 Received: from [98.138.87.3] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 18:55:55 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 22 Aug 2012 18:55:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 191304.7816.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 56334 invoked by uid 60001); 22 Aug 2012 18:55:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345661755; bh=BURisFuHjJZ4QXQWwkj9iYtBXGg4VP9iBecOjr4EcxU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=DomjkmPDLIR+fJix7I/fvaQhKL23hAFHxQm4sa5c/1eNkyqmjDn+GoRRXY+HcBtFpC9hYZ5Y5mhKeY/uTcNlS5/23Ud9J+cP/3PeNqi6tBjrDImC0WSC28y7nuNhHkf87tx5M2neevaOYhtC/sPqIHFTAVTF+5ozhJw9o7pRwao= 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=huanXaJFs5ACEjTGV5Xutfg8JOIZCjG6WRX5h7W8MDtKLA44g0gn6MsT5EEkGz2ETQCtg8dlybqo7iCqyoX7KhpOr8TE4ARVEt7TZnxVwTp+y3ZwN+2VJCdO3OPF0CoCMzxnWF38yeBNRCjvnllV2394i7sRtsPcRqfySwg3bqU=; X-YMail-OSG: sxKObCAVM1nK0FPSPPCT9FEiCpN2U60Odbyg7UxsrdlNwuf .bjpxRCqFg0bWshTic8E8UfPmL90bI1.3f5puYuBR_HZJJfXdleskzypRh6F cpz4Eh0_rAidyt5M3o5owATRl5ZGNmgN_FIiN83OBSCM0gILuDja_HyFi._D NS4p3g6f_TGX_c3FSUNWloeyzCs8myZiEeNOvQnsBCLor2L1AZ.jvQbjOvYs ZVCTpVq3G9GqZTGMhfiv6Ipzj0FG6HBT6DgwPRkbN6nk8KgYZuwJUb0ocQdf kdUe7xGT5QY3JZLj5kCk4nTJnBEEGvLu2IodGT2y3P.KFzQ_r8FTBKBB9vye 9xVZSurLTBW0dlXOv6Wz1ixXBLQbgjEe7Q1Yvj.qIdFzonVECyqxfK3JgiYb LCz6g8yN7GDhgI4UFiNtwxQIOb8FrYvCSWZV3DjyT3OWhQFy8gJ8nI5byEIM UAkHYCAwx_2sSBBBc5_tWVfP6xjNXZsJbFRBdt3TH3z0BpjVwUziKAJ1iAJ3 QBPjCWrOAVqSthL2obUXI4YzX6HG1mfdfQJSTFg2POKGn2JIewhJCHhaLGhM N1vnZAahqqD.4Rdswq3Vn2NMb8ImtqQJnU5XO7nyWFV8zIRYrSmFY50bWiaX UjUqgqy2MTEgoJydbvJu_T5.TP.a1Wc1QZLFg67Rtz971NUv6npZ7oXi9RrE e2FytOmv875A3io9_udiH.WPTHr28U193Q0sQazfvFiTU.oUXy30- Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Wed, 22 Aug 2012 11:55:54 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1345661754.55928.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Wed, 22 Aug 2012 11:55:54 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] review of 4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 18:56:01 -0000 > Here's a side-by-side diff of the two documents: > > http://www.blackops.org/~msk/spfbis/draft-ietf-spfbis-4408bis-05-from-rfc4408.diff.html I used: http://tools.ietf.org/rfcdiff?url1=rfc4408.txt&url2=draft-ietf-spfbis-4408bis-05.txt I'll check out yours when I have time... From superuser@gmail.com Wed Aug 22 12:13: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 D3F9D21F8648 for ; Wed, 22 Aug 2012 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcqfbA8c9nE8 for ; Wed, 22 Aug 2012 12:13:51 -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 F32BF21F867E for ; Wed, 22 Aug 2012 12:13:50 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so883964lbb.31 for ; Wed, 22 Aug 2012 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yJO2DhJ27v/DGi2mj084wJI8NZ0lzZd9PT8WDhSlfTA=; b=XaYiaR0JbtIQL4qMpIN+28wZ10UhhOGaWSY9pMjJzPuvc32kri5aHA77cxx7K5Ranz DwN3toM5y4ti8enZjsf6Pl3Ms2y/Xr581YKKYL3UDxunr1OAmDRYY0kLoD4BsBo1PPhU QKC+tKOuxmJtTMYAFEEqsZNeUrL9Vt0ffwx0L48Y2jHXSgWMO47ojHg6oUKp9xcutYi4 u54SnZNODwOu5CuOCY7HBQwXcbgO2kOGrcwMCZDGTrPxlp9hMhlmczxgUiYdNuyL4+wJ 72JvQBayEFt18iJZ6mkzxUs0q5RwzS7atkQig3wH46RlSiG1cuieYdMfF1tE883d0nHa mcRg== MIME-Version: 1.0 Received: by 10.152.130.3 with SMTP id oa3mr2011119lab.27.1345662829905; Wed, 22 Aug 2012 12:13:49 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 12:13:49 -0700 (PDT) Date: Wed, 22 Aug 2012 12:13:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 19:13:52 -0000 We have Section 1.3.5 that defines what it means for an SPF feature to be deprecated in the context of this document. I think it would be a good idea in terms of setting reader expectations to list the things that are deprecated in a bullet list in this section. That way, when readers run into them, they understand the material is something that's likely to go away soon/later/whenever/something and can plan accordingly. It also provides a good early summary for those already familiar with RFC4408. Given that we're not able to get rid of macros outright despite their very low usage until a later version of the spec, I submit that macros should also be on that list. My understanding of the technical discussion is not that removing them would be a bad idea overall, but that removing them now is simply not permitted. -MSK From sm@elandsys.com Wed Aug 22 12:19: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 65A7221F8685 for ; Wed, 22 Aug 2012 12:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMOVJWYmLSiV for ; Wed, 22 Aug 2012 12:19:09 -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 398A521F866E for ; Wed, 22 Aug 2012 12:19:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MJIvQt015695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 12:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345663148; bh=5oOQ7dJS/2oTKcQiwHlNBRyQ6UJOt9Lin95tXW0KJNY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=nxTqymvxsOaW2knoX9+Ck9NMLLh1kr0mWe+hR4J18aDwpx+Ri+3G+84JAKEURSCZc YZRcznmbvurH3OauUSxI1i3dKYxLn2hiRTf0aCnXzIovR9KTFJOzGDilvlx2+3LIP5 MjTu8C1sZxCUGLVWp/voj1cX4csT+H0qffoYERWc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345663148; i=@elandsys.com; bh=5oOQ7dJS/2oTKcQiwHlNBRyQ6UJOt9Lin95tXW0KJNY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=zOZfXqwWcSiXQDMUaNG63Fz9YJSDDrt8K8x3r5/kawIM16sL4PHHFfDMdSN+RESaI kr+GXC8xagriy84MD3K0KlnoBZ/RthiSQcnNyihbg4mMZihAaqgluTbKje7mN5XN8D tJJmalfAbkl9Jf+BMb3z3XRcHG8c8e8lhGYQo6y4= Message-Id: <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 12:16:36 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120420124423.21010.qmail@joyce.lan> References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 19:19:10 -0000 Hello, Issue #12 has been open for some time. Please review the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html and Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 22 12:19: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 6019921F869F for ; Wed, 22 Aug 2012 12:19:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgGaf6KVO3SS for ; Wed, 22 Aug 2012 12:19: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 41A4321F866E for ; Wed, 22 Aug 2012 12:19:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MJIvQv015695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 12:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345663151; bh=A93RjK5dvVFClBGIupFQ8mjlep2VQMUFO5xITz9kUqQ=; h=Date:To:From:Subject:Cc; b=HlERkMQKVpu9vFs1OHAc/seYqDcSOerCBNUMD5BFr3aHwV48kOc7d+/1LW3g5Yvtu Az1ofklt6XWu4TbrCuXokrwhCb00GwzHlJ4otyjCmLbCEvX8qX7ed3GBxhSObYmReN wwg+n6oASeav8Tv7jpeu7XGapy6UAXiI2pF42G1k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345663151; i=@elandsys.com; bh=A93RjK5dvVFClBGIupFQ8mjlep2VQMUFO5xITz9kUqQ=; h=Date:To:From:Subject:Cc; b=YGpartE/qYG6XOihZIH+azDiCfRtE7sJMlk7Co9LgYy3x9hBIlxuxc4j1MXWk7rPi 61TyUqk5v660gMP60m/ICJ39VD4iQnd2q9fwGQaQ6AmoN02cOJknmnFI9PYV6yjssr xoarsRgYpRe9MemgUPTfXxRHW8EqdTFBKcfxabWo= Message-Id: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 12:17:16 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:19:13 -0000 Hello, Issue #13 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/13 ) is about Best-Guess SPF. Please see the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html and comment on the issue. Regards, S. Moonesamy From dhc@dcrocker.net Wed Aug 22 12:32: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 2254321F867F for ; Wed, 22 Aug 2012 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTZFJLzZs4Mu for ; Wed, 22 Aug 2012 12:32:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2621F845E for ; Wed, 22 Aug 2012 12:32:26 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7MJWNab003360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Aug 2012 12:32:24 -0700 Message-ID: <503533C4.2070900@dcrocker.net> Date: Wed, 22 Aug 2012 12:32:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> In-Reply-To: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 22 Aug 2012 12:32:24 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF 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, 22 Aug 2012 19:32:27 -0000 On 8/22/2012 12:17 PM, S Moonesamy wrote: > http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html > and comment on the issue. ... > I’d like to have a section, or at least an appendix, that talks about > best-guess SPF: What it is, why/when it is or isn’t a good idea, > etc. my fingers always start quivering, and I seem to start stuttering, when anyone uses the word 'guess' as part of a discussion about a protocol specification. so... what do you have in mind? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Wed Aug 22 12:36: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 5F74321F86AA for ; Wed, 22 Aug 2012 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.54 X-Spam-Level: X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, GB_NOSCRIP=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYf61VgUMEVM for ; Wed, 22 Aug 2012 12:36:11 -0700 (PDT) Received: from pop3.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1691C21F86A1 for ; Wed, 22 Aug 2012 12:36:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5675; t=1345664165; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qeUo5iFkpHzDTsPnT0uhfcKCtcI=; b=jQ3ifCjkZQuvrTp+CEt5 iQCl7MjxR+YcQZkpkhqBwr7h0/26+vJxv0oA7RPNwgDBd4lKaGTFWidBocOB7teF WWd8s6JiWtalW/whBt7yrPuYWWd0ScSnXi2naIUjkpQE0ZjjQbu1yw6adJ7ko8VC iAhVmgkucjdc2wfOygd7apw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 15:36:05 -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 1685962282.367.4088; Wed, 22 Aug 2012 15:36:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5675; t=1345663975; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xCVMBFl GHyS/B+8DWvGqjq+KNSGSqawA1x/MdJlg1S8=; b=pNMD2EYSgiTLGR8362s005F MZj8OBSjhmrvGioVsmVtZBSaw6+CRbLqwFpPxcQNXlbqnHQ+AwQnZN/lxYNiYQht oxRzJ/Kj+WKcT/UF8+cZLIJz3YX2jyQ+znjWjGuFkJttwOLxFeb887sn3f1xtBfE u3fp2EKaF+rmiF4lRKk8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 15:32:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2284773177.7.2624; Wed, 22 Aug 2012 15:32:54 -0400 Message-ID: <503534CA.9010506@isdg.net> Date: Wed, 22 Aug 2012 15:36:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <50350126.2010506@isdg.net> <22809811.9sJZkmpsv2@scott-latitude-e6320> In-Reply-To: <22809811.9sJZkmpsv2@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 19:36:12 -0000 My engineering assessment: Either 2.5.4 is very clear and precise with formal protocol design behavior for -ALL policy operations, or a new security section as proposed is added to highlight the possible repercussions of borrowing too much on the new Local Policies highlighting being added to 4408BIS. Scott, this is the same thing that happen to DKIM with SSP when at the last minute with the same concerns, the following informative note regarding local policies as added to section 5.3. item 10 to the SSP requirements document RFC5016: 5.3. Practice and Expectation Requirements 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. The same mindset is materializing and in my strong opinion, this late minute information note not only begin the demise of POLICY for DKIM, it altered and redefined how optimization designs could or would be done. I see the same thing happening here. Thats my concern. So being very explicit about both operations (reject and mark) is necessary despite the obvious that this is already a local policy mode of operation - they can be doing what they want. Some will be slapped for being broken, others will not. So what. that shouldn't change what we want in the protocol and if REJECT is one option, what is the other option? Well, its marking - define it and don't leave holes in it. The question I poise, well the reader of this RFC doc will be able pull all everything he/she need to do for implementation some code? Maybe, sure, I think so, but we are also very close to understanding all this. Can't expect that of the next reader. Anyway, my answer is your sentence is fine, but I believe the proposed 10.7 section as it or with a rewritten/revised text (I don't care) is needed in the security section to highlight it is indeed a security issue relative to both the DOMAIN and the END-USER, and quite frankly, a personal opinion, the receiver as well who should care about filtering -ALL failures first, ask questions later. I'm done with expression my part for this. Scott Kitterman wrote: > On Wednesday, August 22, 2012 11:56:22 AM Hector Santos wrote: >> I am getting mixed input on issue 29 as closed or not. > > It's still open in the issue tracker. The last status I put there is: > > " New text in the -04 draft should address this issue. > > Waiting for WG review.' > > As I've said many times before, me putting something in a draft doesn't carve > it in stone. > >> I would like to have it reopen and proposed a new 10.7 section added >> to help implementators closed the SPF fail result security loophole. >> >> 10.7 Marked Failed Mail Exposure >> >> Section 2.5.4 and 9.3.2 reinforces the local policies concept >> that SPF receivers have no formal protocol requirement to >> enforce rejection of mail which were detected using -ALL policies. >> Section 2.3 highlights the domain intent and expectation for >> such negative classification. However, the receiver is under >> no technical obligation to take any action for SPF failed results. >> >> If the alternative marking is done, it is conceivable local backends >> will still pass the mail to users with no additional red flags or >> indicators of SPF fail. This will require more advanced MUA to >> understand the Receive-SPF headers. >> >> Thus under such cases, there is a possibility users can be exposed >> to harmful mail when the backend added the Receiver-SPF but did not >> further separate the message from the user's normal everyday mode of >> reading/accessing mail. For example, for POP3, the stream may need >> to be separated and not made available for pickup. For online access, >> like Web-based Mail or IMAP, the backend has better control of how >> mail is filtered, sorted, displayed and rendered. >> >> Backends needs to take precautions of marking messages resulting >> from SPF -ALL failed transactions but were not rejected as >> prescribed in section 2.5.4. > > There's no prescription for rejection in 2.5.4. > > I think this gets into too much detail about internals of final delivery to the > user. I think it would be sufficient to add a sentence to the second paragraph > of 9.3.2. How about: > > SPF fail results can also be used as one input into a larger set of > evaluations which might, based on the overall evaluation result in > the email being marked negatively in some way (this might be via > delivery to a special spam folder, modifying subject lines, or other > locally determined means). Developing the details of such an > approach have to be based on local conditions and requirements. > Using SPF results in this way does not have the advantages of > resource conservation and immediate feedback to the sender associated > with SMTP rejection, but could produce fewer undesirable rejections > in a well designed system. Such an approach might result in email that was > not authorized by the sending ADMD being unknowingly delivered to end > users. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Wed Aug 22 12:43: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 E58C821F859F for ; Wed, 22 Aug 2012 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awNvkKd8adix for ; Wed, 22 Aug 2012 12:43:14 -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 A90FB21F859C for ; Wed, 22 Aug 2012 12:43:13 -0700 (PDT) Received: by lahm15 with SMTP id m15so819583lah.31 for ; Wed, 22 Aug 2012 12:43:12 -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:content-transfer-encoding; bh=rORbwbw4yCdhF7QK7gaHpXHHVLAaq/KzBfWgFGZ72fU=; b=SqkfjR6MW3EQ9MNWFu4+PSP8ARns5+5+pX+bqRUjQJpKUtWDW1n485Gw1htQzdFWuk wst53t2d8INcPg0nptBRuBZj5YS43BwPi2c18YJQNN804XYbrUIvSkPr34E3BY8Hn6OB pR+GI3EQVoYuNUxerP3tw5UQ1lMVtdMarUibJwwDaJmykm/upMJyl7Yp6RHeidjsHqtF iKo/5cxPK+bwekk5SBU7JcSSnDmiwyW4sogcgZb2uCB2mDLOD7YGca36ppRlr2dBL57x 48Op7wpUPXlc42J7VTKQqlhKmCk3JiS49b9kYKOginSf7eQ6bRPHLSVD2QGo+TlIUHmB uxcQ== MIME-Version: 1.0 Received: by 10.152.110.70 with SMTP id hy6mr22467733lab.44.1345664592419; Wed, 22 Aug 2012 12:43:12 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 12:43:12 -0700 (PDT) In-Reply-To: <503533C4.2070900@dcrocker.net> References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> Date: Wed, 22 Aug 2012 12:43:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: dcrocker@bbiw.net Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:43:15 -0000 On Wed, Aug 22, 2012 at 12:32 PM, Dave Crocker wrote: > On 8/22/2012 12:17 PM, S Moonesamy wrote: >> http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html >> and comment on the issue. > ... >> I=92d like to have a section, or at least an appendix, that talks about >> best-guess SPF: What it is, why/when it is or isn=92t a good idea, >> etc. > > my fingers always start quivering, and I seem to start stuttering, when > anyone uses the word 'guess' as part of a discussion about a protocol > specification. > > so... what do you have in mind? Best Guess SPF is a well-documented "default" to use when there's no SPF policy published for a given domain. It's in use, among other places, at Gmail. Since we're basically undertaking the work of formal documentation of SPF for the standards track, it seems prudent to me to give this a formal definition and then comment on whether we think it's a good or bad idea. No normative text at all. Stick it in an appendix, perhaps. It looks like the OpenSPF web site has the material we need here in terms of both definition and pedagogy, so what I have in mind isn't much in the way of new work for us. -MSK From hsantos@isdg.net Wed Aug 22 12:49:02 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 C1E6221F8680 for ; Wed, 22 Aug 2012 12:49:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3m2mwzXkw8V for ; Wed, 22 Aug 2012 12:49:02 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8D21F85BB for ; Wed, 22 Aug 2012 12:49:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=518; t=1345664940; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=YJ+zovvlCHA4psqHQD+uR+x/+SE=; b=rjR2ruQVvjoA5DbrTafV 86NiH1btFKlEwTXyi7VANnFCJk8NMI+cy8wtAAxLf9lBb2h6nXIN4wkg6Aum1AIV mMw60AGi5WSHPHDxkaQatda5O3MmkoIyx7pvpHIzJDnu0pgZbUjhUHMlHgQKF1SN grxRgOPfOPWgIwpJZKSbToI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 15:49:00 -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 1686737513.367.5304; Wed, 22 Aug 2012 15:48:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=518; t=1345664747; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gQePZSZ S1YGkv/kStL+3Y2WAbrPO1adHwAKXxK9A9+o=; b=0w/1LcuZQBH6Fd3a2l2GagV P3srrL6OcfomkY4rN+V61gRwpV4FIHyxw8z4sjbQvrwCycURanapU1d6TZBBsIZL x2y3YVb5EOZ3HcLc05+h+BImYWD5jdUGz/xddMvTLwBWFYY9NmtoFLGfidnv9Srv JOwhisctM6w2BRIQ1JZ8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 15:45:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2285545505.7.7488; Wed, 22 Aug 2012 15:45:46 -0400 Message-ID: <503537CD.1020909@isdg.net> Date: Wed, 22 Aug 2012 15:49:33 -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: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> In-Reply-To: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:49:02 -0000 -1 on Best-Guess SPF. Write a separate I-D in SPF Add-on Technology. S Moonesamy wrote: > Hello, > > Issue #13 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/13 ) is > about Best-Guess SPF. Please see the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html and > comment on the issue. > > Regards, > S. Moonesamy > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From dcrocker@bbiw.net Wed Aug 22 12:51: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 0278821F86AA for ; Wed, 22 Aug 2012 12:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5BOhpekTq+1 for ; Wed, 22 Aug 2012 12:51:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 072AE21F8680 for ; Wed, 22 Aug 2012 12:51:43 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7MJpfeY003664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Aug 2012 12:51:41 -0700 Message-ID: <5035384A.3090802@bbiw.net> Date: Wed, 22 Aug 2012 12:51:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 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, 22 Aug 2012 12:51:42 -0700 (PDT) X-Mailman-Approved-At: Wed, 22 Aug 2012 13:02:51 -0700 Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:51:46 -0000 On 8/22/2012 12:43 PM, Murray S. Kucherawy wrote: > Best Guess SPF is a well-documented "default" to use when there's no > SPF policy published for a given domain. It's in use, among other > places, at Gmail. > > Since we're basically undertaking the work of formal documentation of > SPF for the standards track, it seems prudent to me to give this a > formal definition and then comment on whether we think it's a good or > bad idea. No normative text at all. Stick it in an appendix, > perhaps. Hmmm. SPF in the Absence of SPF... With the terms and placement you suggest, given the history, it makes sense (possibly unfortunately...) The most clean distinction is usually a separate document that discusses operations procedures and best practices, distinct from the formal protocol specification, but this is the IETF and we allow flexibility about such things... as long as the distinction is kept clear. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Wed Aug 22 13:03: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 40AB421F851B for ; Wed, 22 Aug 2012 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnFlgQaLShe9 for ; Wed, 22 Aug 2012 13:03: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 71C1E21F8514 for ; Wed, 22 Aug 2012 13:03: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 q7MK3ZCA014382 for ; Wed, 22 Aug 2012 13:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345665819; bh=oCmMiCFc1cXJFqYNp1yvng/2Y6KTKnJT40udbCSbQf8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=lba9hBl/vMEes1a0EBjLKzI/XbSDYspeNGyqV0LvI1lhgRNbcp3Go5cFcERzqrYod dsWB5pcq/zG9ov4nJ0fpVz+3QlmAU5+hBquBNE9Ksd9IIuPypYBYz4UI2cg2xOPjOS Pcgr1JHxs5Y8K0QGn6ZpUy6dJdI709phTmMDyX/c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345665819; i=@resistor.net; bh=oCmMiCFc1cXJFqYNp1yvng/2Y6KTKnJT40udbCSbQf8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ba0HeKphiJQJdmGK7z+4kUgPqD06q9zv5Qba1DyWjKO1O/pseMyKXq/5JLQNBg0UU HxGLywzJKDJfqc2Lr2TXnKNDfcBBy8K3ux9ztpKcjgivnJZwAty/6+0NxU1GCTsXrK VnbyTs0jSXDPdV5LxaPeYUSLXNjK24tmWTpVED2Q= Message-Id: <6.2.5.6.2.20120822123921.0a11b130@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 12:55:56 -0700 To: spfbis@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 20:03:41 -0000 At 12:13 22-08-2012, Murray S. Kucherawy wrote: >Given that we're not able to get rid of macros outright despite their >very low usage until a later version of the spec, I submit that macros >should also be on that list. My understanding of the technical >discussion is not that removing them would be a bad idea overall, but >that removing them now is simply not permitted. I would have to discuss the matter with Andrew to provide a formal answer. Informally, I don't want to go down that rabbit hole. I will push back on any attempt to push me down a rabbit hole. Regards, S. Moonesamy SPFBIS WG Chair From sm@elandsys.com Wed Aug 22 13:03:54 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 49D4D21F8514 for ; Wed, 22 Aug 2012 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9asT-pE+Rp6 for ; Wed, 22 Aug 2012 13:03:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B021F866A for ; Wed, 22 Aug 2012 13:03:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MK3feF014762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 13:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345665832; bh=Dn64qryu6VXwU1oRfO/IQCn75NHVpvQu0v2AkAF5jrY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=WEHA7PyYo9Qi3Drx5oDCVMItFht82ozHXYwo6dukEzSglohtX/iS2876jkUWOVpL/ Dugxji9RDjvQ65VhJ6Y9LJdfRBjsqnfLMWkU5yPrl6X1LJYAASWXTNd2quPpLlWRXR kWKs1hGMkgGqFg2LpYR30lAZuM0ZjNMkSU6ECk1U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345665832; i=@elandsys.com; bh=Dn64qryu6VXwU1oRfO/IQCn75NHVpvQu0v2AkAF5jrY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qUAavJ7CZ6xZ8BAztcQt1Y8OLMWcTiilhoOu3nlB321Q2jqsMo8Msb2IzvBn5rUZj S4Q91Cq9iCiutogTEhLeN7/ZE7F90d7alkNqTL25BXeGHnwNzIuJ9PtSmjAAhhERt8 cmuVbSvv25yK48tuYR2E7LxIp7Xeo5+TXkOEAPus= Message-Id: <6.2.5.6.2.20120822125653.0a11b278@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 13:01:36 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <503534CA.9010506@isdg.net> References: <50350126.2010506@isdg.net> <22809811.9sJZkmpsv2@scott-latitude-e6320> <503534CA.9010506@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 20:03:54 -0000 Hello, I would like to close this thread. Please do not post any messages on it or about Issue #29. I have already mentioned that I will post a message to the mailing list when Issue #29 is open for discussion ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02197.html ). Regards, S. Moonesamy SPFBIS WG co-chair From johnl@iecc.com Wed Aug 22 13:04: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 5353221F8534 for ; Wed, 22 Aug 2012 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.147 X-Spam-Level: X-Spam-Status: No, score=-111.147 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZacQOkOPS-XS for ; Wed, 22 Aug 2012 13:04:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 304C421F8514 for ; Wed, 22 Aug 2012 13:04:54 -0700 (PDT) Received: (qmail 19688 invoked from network); 22 Aug 2012 20:04:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2012 20:04:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50353b64.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=Kqg0TaSoy6n3ba0DwwAgvsw0MyskLG7wrEWUEHSpzI4=; b=gyquFhAkto3NG8dO/wgOBTDj1Vm0YRCm3X0hZ5m066rjNmn71c2Miqh1XKYPy7klP1nE3KiV7lldVMnLmrZXW2BvIslvTrdfb2UmJhV+u7K04aWilr1jXIuEDFIOU/GeERTOmq/hY8xKZGeS2aotvKKsMq+LSOt+Q/txX2EqPvM= 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=50353b64.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=Kqg0TaSoy6n3ba0DwwAgvsw0MyskLG7wrEWUEHSpzI4=; b=D79LwtoeOtiyK5LATFOAwkOUZRLUwfUKOZmiSLquc7lJv8gX8itUsAHCv/Z8GZDgGh3lp4GvW++I+kq5enr2O2eNbdsjqGc8i6pgr7bpxKV/yNIOSZFAZBUwQ8gu9oujtCosB3VJSzJPZ2fOYp4nPXBmtqj9vwgLIicDWsYcAGU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Aug 2012 20:04:29 -0000 Message-ID: <20120822200429.6145.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] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 20:04:56 -0000 In article you write: >I still think all of this is unnecessary. Agreed. SPF does what it does, and we're not going to invent a whole new framework of what mail systems do with its results. R's, John From john@jlc.net Wed Aug 22 13:15: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 9F38921F8679 for ; Wed, 22 Aug 2012 13:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.773 X-Spam-Level: X-Spam-Status: No, score=-105.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4y2rmw0rLhw for ; Wed, 22 Aug 2012 13:15:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F370821F8551 for ; Wed, 22 Aug 2012 13:15:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6E36933C28; Wed, 22 Aug 2012 16:15:55 -0400 (EDT) Date: Wed, 22 Aug 2012 16:15:55 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120822201555.GO85937@verdi> References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:15:56 -0000 Murray S. Kucherawy wrote: > > Best Guess SPF is a well-documented "default" to use when there's no > SPF policy published for a given domain. It's in use, among other > places, at Gmail. Whatever Gmail may do today has limited correlation with what they may do next year, least of all five years from now. But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so I object to calling it "Best Guess SPF". Call it "BGPF" if you must refer to it at all. (There might evolve services which put together very-good-guesses of the appropriate policy -- but that still wouldn't be _sender_ policy framework.) > Since we're basically undertaking the work of formal documentation of > SPF for the standards track, it seems prudent to me to give this a > formal definition and then comment on whether we think it's a good or > bad idea. No normative text at all. Stick it in an appendix, > perhaps. I'm hesitant to even try to define it. The _only_ thing I think it appropriate to say would be it MUST NOT replace the "none" SPF result. (We can't forbid the practice of applying check_host to some random string; but anyone doing it is outside this protocol, however helpful the result might be in some situations.) -- John Leslie From superuser@gmail.com Wed Aug 22 13:34: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 0FB8221F86C8 for ; Wed, 22 Aug 2012 13:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+OxhR3HCkeb for ; Wed, 22 Aug 2012 13:34: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 341A121F85EA for ; Wed, 22 Aug 2012 13:34:05 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so10305lbb.31 for ; Wed, 22 Aug 2012 13:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OugJs3+IURkOpoKe5pMG29GxhORowANccCc1Es9hREg=; b=wB1AeAPyctlJLqsg9a/41uSTzpvYSzWsOStFEr5xbKcPE38mSZ5Wu00pCuVTEf7284 aKvJxotQvXrVqas0YgufKB9m5FOCP/XfX7u9dqJ8X39T4IbZPnqukzJVG83MFfnwAETl WimWjWwq3mB3WVGuR0F5wYJHiwvqyzAu3HGpIa/PcPoCAReX7gOacmEM5kGSJcu+o2ks oy9siu9tECXvgPx3NQ+6tU/2o9XkDAMuldu/GUVjQe2r0Ef3lJ5Bkn6wD9Ku0hIGmnvP gtzkeWfA30wRdhUxvWSZ4Zaf3QA9TrCHE44f2uqcSAAbqK4jBFKdqaha8Zq7RyujOZhe CSCA== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr22410239lab.36.1345667644058; Wed, 22 Aug 2012 13:34:04 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Wed, 22 Aug 2012 13:34:03 -0700 (PDT) In-Reply-To: <20120822201555.GO85937@verdi> References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822201555.GO85937@verdi> Date: Wed, 22 Aug 2012 13:34:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:34:06 -0000 On Wed, Aug 22, 2012 at 1:15 PM, John Leslie wrote: >> Best Guess SPF is a well-documented "default" to use when there's no >> SPF policy published for a given domain. It's in use, among other >> places, at Gmail. > > Whatever Gmail may do today has limited correlation with what they > may do next year, least of all five years from now. > > But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so > I object to calling it "Best Guess SPF". Call it "BGPF" if you must > refer to it at all. > > (There might evolve services which put together very-good-guesses > of the appropriate policy -- but that still wouldn't be _sender_ > policy framework.) I understand, and I'm not trying to make any claim that it's even a good idea. What I'm wondering about is what a reader looking for guidance will do with the fact that we don't talk about it at all, but there's non-trivial usage of it today. We're writing a proposed standard for a specific environment that's already deployed, and it seems to me omitting this entirely would leave some readers wondering why. I'd even be fine with us saying that "Best-Guess SPF" is a total misnomer and a bad idea, as you've done. I just feel that omitting it entirely might be a worse idea. We have an opportunity to provide guidance here, and I think we should. -MSK From sm@elandsys.com Wed Aug 22 14:11: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 9E4E421F86DE for ; Wed, 22 Aug 2012 14:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE-B0peWnbuN for ; Wed, 22 Aug 2012 14:11:52 -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 1193E21F86D9 for ; Wed, 22 Aug 2012 14:11:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MLBdoH009460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 14:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345669910; bh=bACt6+QgB74Yghe24pLGXLu9z6Kw5CDyLd+Kgpn4hzY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X7jkTrivehX2cegG0p/vnzKY8bShsvDcHj5+1EMvoFEvbduV0jwvoRxkfsNm0MYR5 BLQV6o+BrRdbZACnPTPSWV0DYX7Vx5YiW7kZfI5GggTWWocmDrSYCcVX2RXtdwvlcR OE/KBSkEp041GEq0L7gKlby1y9z6/l7IBUJz99rM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345669910; i=@elandsys.com; bh=bACt6+QgB74Yghe24pLGXLu9z6Kw5CDyLd+Kgpn4hzY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Rd68Uo4z7pgh+QImXFyyu2xirk3VcZwp8E26o7b0I+8RhxvxzWEoqFnq4DqJTwJKP +H/71lBUdihqjSwAPSWOCTi7nVs+IhK0QgXLACNEWx6zckhD9fKSR4yk+slAhGZAUm ha3HqTyZuqVSxg4j7PBbRaP691eoceDkiWLATrug= Message-Id: <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 14:05:06 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4F6116A6.2090307@mail-abuse.org> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <22187973.cpWMZthzO6@scott-latitude-e6320> <4F579E33.4000102@tana.it> <5370057.tXlR2v9Toq@scott-latitude-e6320> <4F6116A6.2090307@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:11:52 -0000 Hi Scott, Issue #24 is based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html Could you suggest a resolution? Thanks, S. Moonesamy From sm@elandsys.com Wed Aug 22 14:11: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 B164521F86F4 for ; Wed, 22 Aug 2012 14:11:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcrI-1afB1kL for ; Wed, 22 Aug 2012 14:11: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 51A1B21F86EF for ; Wed, 22 Aug 2012 14:11:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MLBdoJ009460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 14:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345669914; bh=/5kiWYL+WKQTECpKEaFYg3tAIiltI2jpR5m3y3gJXp0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NcEul2SiS9BsaXoVM+Bk36QzJ1DFRllANYZ6m7iakChX9lTRb175ys0ddNDQQm3Bx Tmv9ZupHRrgYAzGmhc4Qe07Y5KmraWSRpTNXPlKBiRsslvI9cf76EdzY1sHxcsF8A3 m7ASm4za+ovXMwqif7q3LxXRJjfGcO9YiFCiy/nE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345669914; i=@elandsys.com; bh=/5kiWYL+WKQTECpKEaFYg3tAIiltI2jpR5m3y3gJXp0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sfS0PWW8Pur4otQnBN3os4932Pvxp3wP1hNuKWJdzoveyCY47urOQO41kIYr4RziV C61GdO2MDEd9yN638z4bOHfkJHyRc80N9Ez/qN66ke5burfziKWQ2xPBOlJ5gNwKar YRBwY+fk7dtVnckhP2pA/eqiqsI4LXCVphgiixM8= Message-Id: <6.2.5.6.2.20120822140855.0a66f230@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 14:10:37 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <079.f8285949b12723d36f663116f590549a@tools.ietf.org> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <079.f8285949b12723d36f663116f590549a@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 21:11:55 -0000 Hi Scott, What was the text change to address Issue #28? The message about the issue is at http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html Regards, S. Moonesamy From ajs@anvilwalrusden.com Wed Aug 22 14:22: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 CC31021F854F for ; Wed, 22 Aug 2012 14:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VFv8pd74gZ7 for ; Wed, 22 Aug 2012 14:22:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3321F84C4 for ; Wed, 22 Aug 2012 14:22:39 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 544018A031 for ; Wed, 22 Aug 2012 21:22:37 +0000 (UTC) Date: Wed, 22 Aug 2012 17:22:30 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120822212230.GD43925@mx1.yitter.info> References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:22:42 -0000 No hat. On Wed, Aug 22, 2012 at 12:43:12PM -0700, Murray S. Kucherawy wrote: > Best Guess SPF is a well-documented "default" to use when there's no > SPF policy published for a given domain. If I put "best guess spf" into google, the first real hit I got was from http://www.openspf.org/FAQ/Best_guess_record, which says this: > Best-guess processing is a crude, non-standard attempt at guessing the > IP address range of a domain's outgoing mailservers. "Non-standard" > means it is not standardized and specific to the implementation. […] > The practice is deprecated and should generally be avoided. While it > may be useful in certain specific circumstances it's not part of the > SPF protocol and results of guessing SPF like records should not be > referred to as SPF results. That doesn't sound to me like something I'd like to add to the formal SPF protocol document at all. But I emphasise, I have no hat on. Best (guess!), A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Aug 22 14:25: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 8048521F855D for ; Wed, 22 Aug 2012 14:25: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-kJTN9ZmVul for ; Wed, 22 Aug 2012 14:25:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id C37F421F8545 for ; Wed, 22 Aug 2012 14:25:37 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id CA8BDD0408D; Wed, 22 Aug 2012 16:25:36 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345670736; bh=shdG9oWPZDgp/t2+2uCOYzhc16k7MWENiPvYXhdoBJA=; h=References:In-Reply-To:Subject:From:Date:To:From; b=VeCA37skF+NZbvSZ4Tnvb0MYIxqQlpS4XRJr9oEpNftSz+NW8fI+SFfN13Er6HpgN rFOVTehIFjsI+9aLNbYlKFxuSc5uwYUCTabp1DTqiAZ10viTtF/8RdQ37mYlHzUvvf 5IfLcNiIrOIqDwiz75D738KUzqJteGasmDQpT+Lw= Received: from [IPV6:2600:1002:b017:a091:238:b480:bee9:a769] (unknown [IPv6:2600:1002:b017:a091:238:b480:bee9:a769]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E19F5D04051; Wed, 22 Aug 2012 16:25:35 -0500 (CDT) References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822212230.GD43925@mx1.yitter.info> User-Agent: K-9 Mail for Android In-Reply-To: <20120822212230.GD43925@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 22 Aug 2012 17:25:29 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:25:38 -0000 Andrew Sullivan wrote: >No hat. > >On Wed, Aug 22, 2012 at 12:43:12PM -0700, Murray S. Kucherawy wrote: > >> Best Guess SPF is a well-documented "default" to use when there's no >> SPF policy published for a given domain. > >If I put "best guess spf" into google, the first real hit I got was >from http://www.openspf.org/FAQ/Best_guess_record, which says this: > >> Best-guess processing is a crude, non-standard attempt at guessing >the >> IP address range of a domain's outgoing mailservers. "Non-standard" >> means it is not standardized and specific to the implementation. > >[…] > >> The practice is deprecated and should generally be avoided. While it >> may be useful in certain specific circumstances it's not part of the >> SPF protocol and results of guessing SPF like records should not be >> referred to as SPF results. > >That doesn't sound to me like something I'd like to add to the formal >SPF protocol document at all. But I emphasise, I have no hat on. > +1. Scott K From sm@elandsys.com Wed Aug 22 14:45: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 E026E21F8508 for ; Wed, 22 Aug 2012 14:45:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCebY+CNj3eo for ; Wed, 22 Aug 2012 14:45: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 F1FFD21F8456 for ; Wed, 22 Aug 2012 14:45:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MLj4UM029198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 14:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345671915; bh=iH/8Ib95OUxR8+utI+rhCcSam8oNaj5PLlzWM2TZemo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=RtQC9gOqRx6tD+SzwQOQwtpjQiI9p3cH+nWhKkd7+v8SD3g4e/6NWlvrY3XVLPGOe vLRj6dH9MeQh5BEqqSEwyneOXyvY3V3oLaNv6Z//w3oG+yRH4vABr8HCOgdLctDBJ4 0vYXmkCItMOth2Z7xJuBDJ6bRU7TKqJyOrAlDIeU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345671915; i=@elandsys.com; bh=iH/8Ib95OUxR8+utI+rhCcSam8oNaj5PLlzWM2TZemo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jkTegThbFIhCnRzsVAJR6zMX9DOSjfIwD/V3KNXfnx0f0brZCRzVjKNdBU/bWqA13 58IF/jJ4HZiP+v3LvGIiBa90iP41D/6/zp1w+Q8HyYwIr1Ptq/DYsJTX+GFwYcbmK+ Q6ret92qPiNP1BjDA5bqo1tz72KUDwXLfIJXtqdg= Message-Id: <6.2.5.6.2.20120822141618.09972010@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 14:25:49 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 21:45:17 -0000 At 09:26 22-08-2012, spfbis issue tracker wrote: >#33: Marked Failed Mail Exposure > > Message posted on 22 Aug 2012: > > I would like to have it reopen and proposed a new 10.7 section added to > help implementators closed the SPF fail result security loophole. > > > 10.7 Marked Failed Mail Exposure > > Section 2.5.4 and 9.3.2 reinforces the local policies concept > that SPF receivers have no formal protocol requirement to > enforce rejection of mail which were detected using -ALL policies. > Section 2.3 highlights the domain intent and expectation for > such negative classification. However, the receiver is under > no technical obligation to take any action for SPF failed results. > > If the alternative marking is done, it is conceivable local backends > will still pass the mail to users with no additional red flags or > indicators of SPF fail. This will require more advanced MUA to > understand the Receive-SPF headers. > > Thus under such cases, there is a possibility users can be exposed > to harmful mail when the backend added the Receiver-SPF but did not > further separate the message from the user's normal everyday mode of > reading/accessing mail. For example, for POP3, the stream may need > to be separated and not made available for pickup. For online access, > like Web-based Mail or IMAP, the backend has better control of how > mail is filtered, sorted, displayed and rendered. > > Backends needs to take precautions of marking messages resulting > from SPF -ALL failed transactions but were not rejected as > prescribed in section 2.5.4. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html Please review the change suggested and comment. Scott Kitterman commented at http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html Please note that Section 10 is about Security Considerations. Please refer to BCP 72 for guidelines about that section. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 22 14:45: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 92D5821F865B for ; Wed, 22 Aug 2012 14:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48tTqrYwubja for ; Wed, 22 Aug 2012 14:45: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 07BB821F8508 for ; Wed, 22 Aug 2012 14:45:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MLj4UO029198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 14:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345671918; bh=ib9SlgmZ8WmHJXQd6waIx36cc/PAE9sQWKd1yCuH8cA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=maopchrE5v4ooWpit1DaJOEv+Q7DatV5N3cl7E31pPL5wZclz/pFqAppV08LWFSVV bFf8xl5QSpYlfVBkCzMYNaM/T0S7TEV4LfrVW588a0AMI24AkczRkZpVzuLhhyKlqB SjXY0gULky1wmZO5OTiUq3in5A/zQsg5mlHpToxY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345671918; i=@elandsys.com; bh=ib9SlgmZ8WmHJXQd6waIx36cc/PAE9sQWKd1yCuH8cA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=LCgJqH7K33hkhJ33S0ytEEWPhP1wp64UlTKJrgTqZyYAalgv3ATLKlLtgBFrwOeVO CQXd+Q50L6SCVjPvXL2KZayAmFF61yPdKUjsUsn8rPjy6ZWg3r+5OZWNW/OyhWRBKG MusXG0foToHzhOIYTki2XEcvhUQc9F3wF20ky2nI= Message-Id: <6.2.5.6.2.20120822142850.0a490de0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 14:44:20 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120312112159.0adb24c8@resistor.net> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120307150701.0a0c7d28@elandnews.com> <20802005.zxzKu6fIYM@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EFAD@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120312112159.0adb24c8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:45:20 -0000 Hello, I posted a summary of Issue #6 at http://www.ietf.org/mail-archive/web/spfbis/current/msg00860.html It is about moving protocol requirements from the Security Considerations section to the mail part of the draft. I suggest a thorough review of the "MUST" and "SHOULD" and "MAY" used for protocol requirements to ensure that RFC 4408 implementations are not negatively affected by this change. Regards, S. Moonesamy From hsantos@isdg.net Wed Aug 22 14:51: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 EA5C821F85F4 for ; Wed, 22 Aug 2012 14:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nacJqXV8gDuu for ; Wed, 22 Aug 2012 14:51:04 -0700 (PDT) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E764621F8513 for ; Wed, 22 Aug 2012 14:51:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2040; t=1345672255; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=SmL0cbGP0zOrtj5zNZSe4D1+oeA=; b=Tk/3kV2GCg6cFDyut4cG gh5mfAuZtFpBCq/qql6gL5hZXZPEpdzPd2gwWKqOE7GSHfAwONW0Acp3zpe4+CBZ jUcSA24C8ezSXxUZlfRO9atVhQMAQhP3/Lf1A3lWVMa00B+QXFjb19VaiZpjYedX 8IFe8YUDxblrgPgQrQWX3Ok= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 17:50: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 1694052696.367.3816; Wed, 22 Aug 2012 17:50:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2040; t=1345672064; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=l8rTdGU mt50YkE8Bn/I7lt5lGcDWDfgor3IzB+5X0VI=; b=cVxBK2S/B7nCg8T/70g6nvM 1MfIfg9Y8AEM+O/GaL6dnnq8g1bj+y//sRkySs/IEUDDnbHr++54IEdb82yebNqx PZTZws6haYo4fU1Wx7dzkCBLsLUIrHChY8lDOV7FWhSAnUTgVrTwhdI/qLv+o6qk Inqd7Bx/2oPk2ngZ48Z8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 17:47: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 2292862427.7.8048; Wed, 22 Aug 2012 17:47:43 -0400 Message-ID: <50355465.7090508@isdg.net> Date: Wed, 22 Aug 2012 17:51:33 -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.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822201555.GO85937@verdi> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:51:05 -0000 In that case, lets open the case for something more relevant to SPF: SPF 2.0 and how it 100% related to SPF operations in the market. I think it is an engineering sin to not discuss SPF 2.0 in a SPF related document. best-guest SPF is a kludge that pertains to the idea that senders and receivers are part of the same computer, which may be true or reflective of a market where there is less ISPs/ESPs (they abandoned this business, etc) and also a market where there are less scaled out farms (more machines) and more scaled up (more CPUs/Multi-Core) operations thus the same IP/MX, etc. -- HLS Murray S. Kucherawy wrote: > On Wed, Aug 22, 2012 at 1:15 PM, John Leslie wrote: >>> Best Guess SPF is a well-documented "default" to use when there's no >>> SPF policy published for a given domain. It's in use, among other >>> places, at Gmail. >> Whatever Gmail may do today has limited correlation with what they >> may do next year, least of all five years from now. >> >> But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so >> I object to calling it "Best Guess SPF". Call it "BGPF" if you must >> refer to it at all. >> >> (There might evolve services which put together very-good-guesses >> of the appropriate policy -- but that still wouldn't be _sender_ >> policy framework.) > > I understand, and I'm not trying to make any claim that it's even a > good idea. What I'm wondering about is what a reader looking for > guidance will do with the fact that we don't talk about it at all, but > there's non-trivial usage of it today. We're writing a proposed > standard for a specific environment that's already deployed, and it > seems to me omitting this entirely would leave some readers wondering > why. > I'd even be fine with us saying that "Best-Guess SPF" is a total > misnomer and a bad idea, as you've done. I just feel that omitting it > entirely might be a worse idea. We have an opportunity to provide > guidance here, and I think we should. From spf2@kitterman.com Wed Aug 22 14:53: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 E76A921F84FB for ; Wed, 22 Aug 2012 14:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR0Be3enKseu for ; Wed, 22 Aug 2012 14:53:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFF921F84A7 for ; Wed, 22 Aug 2012 14:53:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F33C420E410A; Wed, 22 Aug 2012 17:52:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345672377; bh=TlCXnWHb1DbsJpC/fYjVn2tVuOy/WKeHPcZm+sepzJY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I3uDCfaBCCUs4LPpRW/n0ayNLb9EIdA341jWkG7arXMjIys2KgliCcugOvYyNeY5A x9U3rOp5drn/68j576KIv8uuik7oZ7Xmc0Br754dXt8nmjSoi7O6E0vXZcQwuRA1lH IbT1vkyZ4L1KYQBs6FfeKwdFQ8vUcFfgPL+YgRjc= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BCBBF20E4086; Wed, 22 Aug 2012 17:52:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 17:52:55 -0400 Message-ID: <3825031.BJt5oWj9RA@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822142850.0a490de0@resistor.net> References: <061.6bd7631aa74ff75bc011ac2769322b92@tools.ietf.org> <6.2.5.6.2.20120312112159.0adb24c8@resistor.net> <6.2.5.6.2.20120822142850.0a490de0@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] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:53:02 -0000 On Wednesday, August 22, 2012 02:44:20 PM S Moonesamy wrote: > Hello, > > I posted a summary of Issue #6 at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00860.html It > is about moving protocol requirements from the Security > Considerations section to the mail part of the draft. > > I suggest a thorough review of the "MUST" and "SHOULD" and "MAY" used > for protocol requirements to ensure that RFC 4408 implementations are > not negatively affected by this change. I attempted to be quite careful about it when reorganizing/clarifying, but more review is, of course, welcom. Scott K From superuser@gmail.com Wed Aug 22 14:57: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 B7A7E21F85F4 for ; Wed, 22 Aug 2012 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qG3GXiEt8DN for ; Wed, 22 Aug 2012 14:57:19 -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 1743B21F848F for ; Wed, 22 Aug 2012 14:57:19 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so206666obb.31 for ; Wed, 22 Aug 2012 14:57:18 -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:content-transfer-encoding; bh=aYanIlRQgko94XUw8jUEpVgQMDlWX1pDihmNEd1M/X8=; b=IhnVlBmaDDKxG7aQzeDsFnWbt+JTm2lY926P81xtme+XqrRsp4FtZ4bmCCqbRmCkFI Fv45TLQDYkw379crF0RpTqSy3X6umLGtLqB5x/89nHPvV9OZkIvvQr/rXyiYD5TrVU7v rVMFfRo23uuyHELeF1SRY/ulZEnS2RQLqz4Sso99639l6p5CgFIkOQIep+5p99yByoS5 XBoxWYolCzRc7skyWxjn4Dp60AlDyukH1lT7YCtQx9WB3ynGb8VPtJw+1qDvoiMb+296 on0PiKfVcVNbwgYMXm3IUvAjmTYJ++90bv9+NldKKqFWXOU1ds7g7BMPzzIGBo+2uRcO f9cA== MIME-Version: 1.0 Received: by 10.60.2.134 with SMTP id 6mr16701336oeu.62.1345672638511; Wed, 22 Aug 2012 14:57:18 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Wed, 22 Aug 2012 14:57:18 -0700 (PDT) In-Reply-To: <20120822212230.GD43925@mx1.yitter.info> References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822212230.GD43925@mx1.yitter.info> Date: Wed, 22 Aug 2012 14:57:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:57:19 -0000 On Wed, Aug 22, 2012 at 2:22 PM, Andrew Sullivan w= rote: > If I put "best guess spf" into google, the first real hit I got was > from http://www.openspf.org/FAQ/Best_guess_record, which says this: > >> Best-guess processing is a crude, non-standard attempt at guessing the >> IP address range of a domain's outgoing mailservers. "Non-standard" >> means it is not standardized and specific to the implementation. > > [=85] > >> The practice is deprecated and should generally be avoided. While it >> may be useful in certain specific circumstances it's not part of the >> SPF protocol and results of guessing SPF like records should not be >> referred to as SPF results. > > That doesn't sound to me like something I'd like to add to the formal > SPF protocol document at all. But I emphasise, I have no hat on. It's fine with me if consensus is "no". I just wanted to have the conversa= tion. -MSK From hsantos@isdg.net Wed Aug 22 15:04: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 5799421F8658 for ; Wed, 22 Aug 2012 15:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8InxKROVt80O for ; Wed, 22 Aug 2012 15:04:24 -0700 (PDT) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 94CF721F8653 for ; Wed, 22 Aug 2012 15:04:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=684; t=1345673055; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=nFD8IhaP5Sk66thFGHbDGWoO4ro=; b=NU9n4H+4PlhdAom+niyh rspW91A+vdQuw29as/RHm0/Q7T4K/tWEgBUlSaGPrjf+EjGjxhagm1T0GgZijQM6 aFZz1hzHfbytGsp9VzhPEojGGLFrvd8l1I928pj678+kM6NGUfkch/s8F5GYsrjP tRDPYHJemqBWuJdCif0uci4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 18:04:15 -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 1694852747.367.3260; Wed, 22 Aug 2012 18:04:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=684; t=1345672863; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=0q01Sge tqoE2ym9nZfqxzL0lZrDNagi1MTRPdJl/W6M=; b=yyFJpUoCB4ymmTK7NpAjdry /PICj4XAHzMm5WgqQt4PUYn3PEuzLJB32mskrYlHdGFYs6N3SFSuagaNyvj+Oc+4 tEXq7xvDoMvQhYCK2DZFLFSgX0IhUq7f+ZDA5RasmKuzKKzuncMt8du+Scu5G86g gz1O9cMKJ9c5zqeKBWeE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 18:01:03 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2293661333.7.6916; Wed, 22 Aug 2012 18:01:02 -0400 Message-ID: <50355785.3050200@isdg.net> Date: Wed, 22 Aug 2012 18:04:53 -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: <20120822200429.6145.qmail@joyce.lan> In-Reply-To: <20120822200429.6145.qmail@joyce.lan> 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: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:04:25 -0000 John Levine wrote: > Murray wrote: >> I still think all of this is unnecessary. > > Agreed. SPF does what it does, and we're not going to invent a whole new > framework of what mail systems do with its results. Agreed, but there is no suggestion to do so. It is prudent that we close all possible loopholes and that is what this issue and proposed new section section 10.7 addresses. No new framework, just adding implementator awareness for the responsibility to make sure users are not harmed when implementators add code for deployments to use SMTP accept/mark modes of operation as opposed to SMTP rejection modes of operation for -ALL policy results. -- HLS From superuser@gmail.com Wed Aug 22 15:05: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 AB12D21F8658 for ; Wed, 22 Aug 2012 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI-eUppD0101 for ; Wed, 22 Aug 2012 15:05:46 -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 21AB721F8644 for ; Wed, 22 Aug 2012 15:05:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so232046obb.31 for ; Wed, 22 Aug 2012 15:05: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=Dj5LZWMcw02Kt9Mre/RRUbpoxTr0VRdLCTszr17weM0=; b=dxxAZt7Z6uT3tflJVctGRnBYDtNX5AVpsuA4WGky28r05Xf3ZAk+WePiMPNjU4QFfU g/AT/gsFL1JbyaOHE06IhAZYwpL2ARAfrwen3+iNdXQeft2geKYydJfdwLP4pIcor07Y BsoTELaJGNbT+4n7m1OqQpCAkMXkRzvVVcsbZ1ZGDnxqtbDSqNtf62RoZgY2Dn23yDui iKwjCWoEVhVO/sRrj4TDK3uMv2zDg7CMALJvYk+LZ2wzE0RGogZDnITi7FslJZFdHjzc cC/5CITX6Ra+jP0rjrRVmgyN1Mz99M/rgIBx4ix2P4ACdOppqI7ZvtRcGqkbWGXGsCUY R3Og== MIME-Version: 1.0 Received: by 10.60.12.8 with SMTP id u8mr16714331oeb.46.1345673145670; Wed, 22 Aug 2012 15:05:45 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Wed, 22 Aug 2012 15:05:45 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120822141618.09972010@elandnews.com> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> Date: Wed, 22 Aug 2012 15:05:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:05:46 -0000 On Wed, Aug 22, 2012 at 2:25 PM, S Moonesamy wrote: > Please review the change suggested and comment. Scott Kitterman commented > at http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html I prefer no change, though I find Scott's single-sentence counterproposal to be preferable to an entire new section. -MSK From spf2@kitterman.com Wed Aug 22 15:16: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 3721F21F85FC for ; Wed, 22 Aug 2012 15:16: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF-hPHQmsnmG for ; Wed, 22 Aug 2012 15:16:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5870621F8452 for ; Wed, 22 Aug 2012 15:16:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CD1E120E410A; Wed, 22 Aug 2012 18:16:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345673785; bh=dEnZbW16nn6Bfp/uYxhNpv/dSSbipaS67MN14jsQXxk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qHffjLFkKTiAeAkWFdVWtmaayFNi+R0Z1ZPNFCoWUvgfNzSqWeoT6WVy7/EOvlHky HRKlzxDQwrMB5X63oQCLf8CLrs3aIuy5VUl9cthbO2Y36ZeZGTNyhjnQ9e0nNzhpQK DNHNx2KqwniTDgfzglm7uZwGMEvqUq4RTXQDmJyk= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9F43720E4086; Wed, 22 Aug 2012 18:16:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 18:16:24 -0400 Message-ID: <20086782.TyIbvIWLSl@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822141618.09972010@elandnews.com> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:16:27 -0000 On Wednesday, August 22, 2012 02:25:49 PM S Moonesamy wrote: > At 09:26 22-08-2012, spfbis issue tracker wrote: > >#33: Marked Failed Mail Exposure > > > > Message posted on 22 Aug 2012: > > > > I would like to have it reopen and proposed a new 10.7 section added to > > help implementators closed the SPF fail result security loophole. > > > > > > 10.7 Marked Failed Mail Exposure > > > > Section 2.5.4 and 9.3.2 reinforces the local policies concept > > that SPF receivers have no formal protocol requirement to > > enforce rejection of mail which were detected using -ALL policies. > > Section 2.3 highlights the domain intent and expectation for > > such negative classification. However, the receiver is under > > no technical obligation to take any action for SPF failed results. > > > > If the alternative marking is done, it is conceivable local backends > > will still pass the mail to users with no additional red flags or > > indicators of SPF fail. This will require more advanced MUA to > > understand the Receive-SPF headers. > > > > Thus under such cases, there is a possibility users can be exposed > > to harmful mail when the backend added the Receiver-SPF but did not > > further separate the message from the user's normal everyday mode of > > reading/accessing mail. For example, for POP3, the stream may need > > to be separated and not made available for pickup. For online access, > > like Web-based Mail or IMAP, the backend has better control of how > > mail is filtered, sorted, displayed and rendered. > > > > Backends needs to take precautions of marking messages resulting > > from SPF -ALL failed transactions but were not rejected as > > prescribed in section 2.5.4. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html > > Please review the change suggested and comment. Scott Kitterman > commented at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html > > Please note that Section 10 is about Security Considerations. Please > refer to BCP 72 for guidelines about that section. For this issue, I think it requires a two step answer: 1. Is the issue a security issue that should be mentioned in security considerations 2. If it was, what should be said about it. I've reviewed BCP 72 and I think that the concern that is expressed falls within the scope of a "Message Insertion" attack as described in Section 3.3.2. So I think that as far as step 1 is concerned, it qualifies. I think that the proposed addition goes into far more detail than we need, however. I would propose the following alternative: 10.7 Unauthorized Message Insertion Section 7.1 of [RFC5321] describes security considerations associated with the SMTP protocol and spoofing. SPF is an attempt to address this issue. When receivers deliver mail that has failed SPF checks then the affect SPF has on this issue is reduced. In order to mitigate this concern it is important that the results of SPF check be recorded (See [Section 7]) to make it possible for MUAs to display message status to end users. Scott K From spf2@kitterman.com Wed Aug 22 15:22: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 CC3A421F8671 for ; Wed, 22 Aug 2012 15: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psqobNIXIxCu for ; Wed, 22 Aug 2012 15:22:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2021F8665 for ; Wed, 22 Aug 2012 15:22:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6599D20E410A; Wed, 22 Aug 2012 18:22:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345674157; bh=ZSMR3iyThoTg8nTwvkfus6AsH+Lwttf9OWIc8ARpGa8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jR6zOFrezeUYAwL9kYv/hVRDYoOJXeehv47XkZoqdQQOHc/+h2uDsAYP2bWD3fL/b nT4J0ABLHAzcxz58W1ti42J2YyWEQgYZpqPQSGzkBYnA7yWy3JIL+Xw2cpYWqpkRXO QzdO9QIvzd67IjKq0+dITEjg7A8AQ9VivkAGEiQw= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3336220E4086; Wed, 22 Aug 2012 18:22:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 18:22:36 -0400 Message-ID: <2503352.tTzaICpeS8@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822140855.0a66f230@elandnews.com> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <079.f8285949b12723d36f663116f590549a@tools.ietf.org> <6.2.5.6.2.20120822140855.0a66f230@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] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:22:38 -0000 On Wednesday, August 22, 2012 02:10:37 PM S Moonesamy wrote: > Hi Scott, > > What was the text change to address Issue #28? The message about the > issue is at > http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html It was the addition of this to Section 4.3: Properly formed domains are fully qualified email domains as described in [RFC5321] Section 2.3.5. Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]. There was some discussion about changes relative to local-part macros, but in the end I believe we converged on not making any change for that (and this is what the current draft reflects) because there wasn't a way to be more broadly compatible with IDN local-parts and maintain backward compatibility. Scott K From spf2@kitterman.com Wed Aug 22 15:31: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 EE5B721F867D for ; Wed, 22 Aug 2012 15:31: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJOAjOYgnITb for ; Wed, 22 Aug 2012 15:31:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 463A821F8673 for ; Wed, 22 Aug 2012 15:31:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BB86D20E410A; Wed, 22 Aug 2012 18:31:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345674701; bh=Z2FY/IHO+s8RQoA1YzMj6Qe0JQhtf/zMdzmNKcAX4u4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=M0dJ0aNjvVZQ2hxorB1mYGgmGHj8qLT8dkuUGknP34xBu2tneimaKcdn9ZmjScs1U hS3hmfJfmEkstDh1w0vXxCkI22nhOaFZfhpTuSEgxZnGdua8QebUG6Z5yplcYhrVDy twy4sy67aCQYxRcs5tCqY3cF+KWOmvxHuCATRprw= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8B17320E4086; Wed, 22 Aug 2012 18:31:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 18:31:40 -0400 Message-ID: <4563708.iYIAOlqAVf@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:31:43 -0000 On Wednesday, August 22, 2012 12:13:49 PM Murray S. Kucherawy wrote: > We have Section 1.3.5 that defines what it means for an SPF feature to > be deprecated in the context of this document. I think it would be a > good idea in terms of setting reader expectations to list the things > that are deprecated in a bullet list in this section. That way, when > readers run into them, they understand the material is something > that's likely to go away soon/later/whenever/something and can plan > accordingly. It also provides a good early summary for those already > familiar with RFC4408. I think this makes sense. Once it seems like we have a final list of what will be marked deprecated I'll be glad to add it. Feel free to remind me if I forget. > Given that we're not able to get rid of macros outright despite their > very low usage until a later version of the spec, I submit that macros > should also be on that list. My understanding of the technical > discussion is not that removing them would be a bad idea overall, but > that removing them now is simply not permitted. I'm not aware of any technical specific technical issues with macros that would cause us to do this. OTOH, if we do, we are not just deprecating specific functions within the protocol, but deprecating functional capabilities such as per-user policies, logging specifics of remote SPF checks to support deployment verification and others. I know a number of people want macros removed (and if not removed deprecated) because it would simplify the protocol. Given that there are protocol features that cannot be accomplished without macros, I don't think this is a sufficient argument. Scott K P.S. In our last go-round on macros there was one mention by someone of a macro related implementation defect. I had an off list dialog with the vendor in question and the issue wasn't related to macro processing. It was related to the way they implemented processing limits. It was just coincidence that an error occurred during macro processing. From spf2@kitterman.com Wed Aug 22 15:45:37 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 BE0D121F8683 for ; Wed, 22 Aug 2012 15:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI4iJEdsCXOA for ; Wed, 22 Aug 2012 15:45:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 31D8921F8673 for ; Wed, 22 Aug 2012 15:45:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 34C4320E410A; Wed, 22 Aug 2012 18:45:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345675536; bh=1D5sUoKQXXr/8qd8uelRuhmQHzYyfHpEAbvXgPy9L+g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EfTH+YZrNTvt15/oCiQTvh9XGoclQ/oPiJQr70aBpTdYwVNNwGDp5wCjhNyUaAOPP S5I7nJCU12kVvkEuontholdiga9kEHKLXVAnuyXKYy/feDifbAp3O6FVnxY2Dsutoo EvEAHdN/fvucOhJ50oeM/jBSgZlAYYQqPQUCiDUY= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EEF3620E4086; Wed, 22 Aug 2012 18:45:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 18:45:34 -0400 Message-ID: <2165564.7dxLrmajVl@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <4F6116A6.2090307@mail-abuse.org> <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:45:37 -0000 On Wednesday, August 22, 2012 02:05:06 PM S Moonesamy wrote: > Hi Scott, > > Issue #24 is based on the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html > > Could you suggest a resolution? In general, I think that the current processing limits are reasonable and well documented and the text in the security considerations is appropriate. It might be prudent to provide some additional constraint, provided we can do it in a backward compatible way. This is discussed in: http://www.ietf.org/mail-archive/web/spfbis/current/msg00850.html It would be good to know if the information that's needed to assess the impact of such a void lookup limit can be garnered from the existing surveys and if the authors of one or more of the surveys would be up for gathering the data for us? Scott K From sm@elandsys.com Wed Aug 22 15:59: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 DE7E021F8680 for ; Wed, 22 Aug 2012 15:59:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXKGs1sXOVtN for ; Wed, 22 Aug 2012 15:59:25 -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 5346021F85A5 for ; Wed, 22 Aug 2012 15:59:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MMxCxt019735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 15:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345676363; bh=zG+mlO4xgPw3/ic1bASEledTi/zgjOdK6gmm4J/msIo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sugip7P42LMfUvisRZ7pbUi/ibe0PnvM6gFQum1mmGuKPOBwvKYegvvVRjPz3971a JR9nXoYs7IbdqysqS8IQdfB/j1e7uj+dg8q4CJgzKtE07WBjxY1m3Fiw1PzMzYaO8I mBQrF2Zlu5EXVZEMLGWJvpxfKaBuPy/pZY7GHDQ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345676363; i=@elandsys.com; bh=zG+mlO4xgPw3/ic1bASEledTi/zgjOdK6gmm4J/msIo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=TD69OIQ82qk6yQmnqagYwnhXGjUELWz11NGiaZkRBvXP8ya+8OLaxVZx0VCEBGEbt mzYUzM+O7ORxWepruUDrZRvkPTVV5kaOh+qxolxfa16aItUCdppJWgGsmh9WoAu6Kx D1nH/UEilCYOujOrbHsr+aXvoYnZYDkn+pbwcfuE= Message-Id: <6.2.5.6.2.20120822150519.0a4bff88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 15:10:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822212230.GD43925@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:59:26 -0000 At 14:57 22-08-2012, Murray S. Kucherawy wrote: >It's fine with me if consensus is "no". I just wanted to have the >conversation. Dave Crocker said [1]: "Hmmm. SPF in the Absence of SPF...". John Leslie mentioned [2] that: 'But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so I object to calling it "Best Guess SPF". Call it "BGPF" if you must refer to it at all.' I'll consider this issue as addressed. Regards, S. Moonesamy SPFBIS WG co-chair 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02213.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02217.html From sm@elandsys.com Wed Aug 22 15:59: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 CAD4221F86B3 for ; Wed, 22 Aug 2012 15:59:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQyh6xt85rhq for ; Wed, 22 Aug 2012 15:59: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 625C421F86B2 for ; Wed, 22 Aug 2012 15:59:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MMxCxv019735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 15:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345676367; bh=RZ/mSEPq3WpCw0fi0Kl07EAQp0daf8A8q08KhijdTE0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hnv13nje76MQsP7ubcb1tMPHtJv12nqoiTx0Y777ig/9CuOiyF6GShuihGy6AzqlS m6lebPAA6BJJ6RBGuUP7K+dt+xI3efEv62yMF+6bvN4eVCZFkS9d5qhZJgBcXjt+p4 2bC3U+7CIj43q5vVx2ktSJxkBmbsdNvdgr34if7w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345676367; i=@elandsys.com; bh=RZ/mSEPq3WpCw0fi0Kl07EAQp0daf8A8q08KhijdTE0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cnOH7t3A8jM2RLosOmEVw3cJcO+1Sexew1GgdWwwp6ck27BuksPeRsYXv+o3aMtxg ds5ixKj9M2h2C3+N6T+1/diUKx1aOEflq1y0+NiGF9PhuTcv5xCAqbVmu2KZxIr9mY 4+36EHvb49Pei8j+Q9gsFNv56Qu21mB3EAhvCRfI= Message-Id: <6.2.5.6.2.20120822153007.0a670d18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 15:48:24 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2503352.tTzaICpeS8@scott-latitude-e6320> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <079.f8285949b12723d36f663116f590549a@tools.ietf.org> <6.2.5.6.2.20120822140855.0a66f230@elandnews.com> <2503352.tTzaICpeS8@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 22:59:29 -0000 Hi Scott, At 15:22 22-08-2012, Scott Kitterman wrote: >It was the addition of this to Section 4.3: > > Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5. Internationalized > domain names > MUST be encoded as A-labels, as described in Section 2.3 of > [RFC5890]. I'll close the ticket if I do not hear any objections to the above. >There was some discussion about changes relative to local-part macros, but in >the end I believe we converged on not making any change for that (and this is >what the current draft reflects) because there wasn't a way to be >more broadly >compatible with IDN local-parts and maintain backward compatibility. Thanks. There is a "MUST" in the text that was added. It may affect existing RFC 4408 implementations. I'll leave this to the Responsible AD to decide. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 22 15:59: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 B7FA621F8680 for ; Wed, 22 Aug 2012 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK3HZNcwnu3F for ; Wed, 22 Aug 2012 15:59:39 -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 5FD1221F86B2 for ; Wed, 22 Aug 2012 15:59:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7MMxCxx019735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 15:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345676373; bh=P2CZuKLLVnFH6P1RAORxdk6NzwVZI/Gibcw45kO8Ifg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tcfNX5YPBh/1YTSYpn5ykXz7zHtkiE5CD27triTc3D91KZLsHnUS2jarx7OoZ4R5r rDyxJc+AHPA7k1AizpHljvf/A+TZz1VkLDJNXj7yzsG9fvmSqUrRIkd2FBx8A1LO4P Dl8J0lduYckcIhei4fN11SsfTcOlh+8R6iWygOVU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345676373; i=@elandsys.com; bh=P2CZuKLLVnFH6P1RAORxdk6NzwVZI/Gibcw45kO8Ifg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LgNxmj67OrvoZiohO7BHpGqFKnqYCSxGg8EPxpzgboeg3ozqnVVVMRz9ZxFcP0Uad g9qYmU8k08ySEhMfdNng2JLJu1AQsoqphaCV2DWPCv4ahOVUg/OCZPht87+28quJE2 S6O4KeCYH8E7WmUUiaDmGvPmE8Ca2xaoIcH/OhRU= Message-Id: <6.2.5.6.2.20120822155203.0a1090e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 15:59:02 -0700 To: "Murray S. Kucherawy" , Hector Santos , John Levine , Philip Gladstone , spfbis@ietf.org From: S Moonesamy In-Reply-To: <2165564.7dxLrmajVl@scott-latitude-e6320> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <4F6116A6.2090307@mail-abuse.org> <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> <2165564.7dxLrmajVl@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Scott Kitterman Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:59:39 -0000 Hello, I am addressing this message to the persons who did the surveys for RFC 6686. At 15:45 22-08-2012, Scott Kitterman wrote: >In general, I think that the current processing limits are >reasonable and well >documented and the text in the security considerations is appropriate. It >might be prudent to provide some additional constraint, provided we can do it >in a backward compatible way. This is discussed in: > >http://www.ietf.org/mail-archive/web/spfbis/current/msg00850.html > >It would be good to know if the information that's needed to assess >the impact >of such a void lookup limit can be garnered from the existing surveys and if >the authors of one or more of the surveys would be up for gathering the data >for us? Could you please help with the above? SPFBIS WG participants are also welcome to comment on this issue. Regards. S. Moonesamy SPFBIS WG co-chair From W.Doust@racingvictoria.net.au Wed Aug 22 16:37: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 195AE21F862B for ; Wed, 22 Aug 2012 16:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT1PLrxXD32b for ; Wed, 22 Aug 2012 16:37:23 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9F21F8625 for ; Wed, 22 Aug 2012 16:37:22 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v6, 8, 4, 0) id ; Thu, 23 Aug 2012 09:37:20 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Aug 2012 09:36:49 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D44D8@XCHANGE.rvl.internal> In-Reply-To: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] #13: RFC 4408: Best-Guess SPF Thread-Index: Ac2Amwd/fhmrg1aTSdW2RzZKGiv9vQAHrxAg References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> From: "Wayne Doust" To: Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 23:37:24 -0000 IMO Best guess SPF immediately sounds like a bad idea. However, if someone were to make an assumption "v=3Dspf1 mx ?all" = wouldn't be a bad starting point - certainly better that the PTR lookups that commonly take place. The problem with inserting best guess is that there is no counterpart to SoftFail on the positive side (no "SoftPass"). Which IMO would be a mandatory starting point and therefore outside of the scope.=20 (As an aside note, I've always regarded the lack of a "SoftPass" a limitation of SPF) Wayne From spf2@kitterman.com Wed Aug 22 16:42: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 0281521F8650 for ; Wed, 22 Aug 2012 16:42: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEdITQpWNTuc for ; Wed, 22 Aug 2012 16:42:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3621F8665 for ; Wed, 22 Aug 2012 16:42:08 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 65F97D0408D; Wed, 22 Aug 2012 18:42:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345678927; bh=3c1rzlrhKKdoF4gewqfNey/YZSncikOSDNkGOdxG+v0=; h=References:In-Reply-To:Subject:From:Date:To:From; b=qI5E4g8juwWqmz9HRVQB69TfrRHpxQmmOTV8/RUYoR9Adt18j3y/1u6X2ySwY2bGd waXxr+DPh6hpIEMim8hP/Fi4gRJ+OzAqRSD3UV0XCxW7OLzkf0nrLFN/8jXug2sgyF 7ePeHUkjOdl+MBU3KHOSwDjXTyK8bTvxmzBtO0Ag= Received: from [IPV6:2600:1002:b017:3a1d:cb54:1392:7951:efff] (unknown [IPv6:2600:1002:b017:3a1d:cb54:1392:7951:efff]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D8E80D04051; Wed, 22 Aug 2012 18:42:06 -0500 (CDT) References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <0D2A0D5F64179F4F9556D3DEDE39F9AF010D44D8@XCHANGE.rvl.internal> User-Agent: K-9 Mail for Android In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D44D8@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 22 Aug 2012 19:42:03 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 23:42:10 -0000 Wayne Doust wrote: >IMO Best guess SPF immediately sounds like a bad idea. > >However, if someone were to make an assumption "v=spf1 mx ?all" >wouldn't >be a bad starting point - certainly better that the PTR lookups that >commonly take place. > >The problem with inserting best guess is that there is no counterpart >to >SoftFail on the positive side (no "SoftPass"). Which IMO would be a >mandatory starting point and therefore outside of the scope. > >(As an aside note, I've always regarded the lack of a "SoftPass" a >limitation of SPF. You can't have a "Sender Policy Framework" without a sender policy. Whatever "Best Guess" is, it's not SPF. Scott K From superuser@gmail.com Wed Aug 22 16:53: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 F03EE21F8646 for ; Wed, 22 Aug 2012 16:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU0dIp7u0LxD for ; Wed, 22 Aug 2012 16:53:49 -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 6C07121F862B for ; Wed, 22 Aug 2012 16:53:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so435756obb.31 for ; Wed, 22 Aug 2012 16:53: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=nXH/baNiZIvGisH4L9r9bHZ55V+/fUCf+ITl3Mm7hPg=; b=bg1rcRPxXJNvrOPe7qIvfQmU7iWaUEfvTzHIBUfgn1pCQjWeAJugxQIC7jId2wgeiV XRoooPoWrm8Z81msIsAkQsnxpGRmTFQBjgbW2SX6d3Q+ixYiW0tOEOG7bllS9vSzYJRS Q01Wd3A+SKm7q129oDm2mubdPPQEEWs0ymVGRQn7iFWqO1+ovUfxYOl8XI7saMlFg80e xey3xDuhdowbahajegtGeCdO6FA4iV8oFyFC41MfMWdGCsfl5Ky6JYOklU2qUHT+Lseb 9q5IdOpEIeM7JbHf6vD1bQOocYEEW/z5K9/HDpwA7Io4oJMWIxd+scR32KNLpOikgRM4 /6pQ== MIME-Version: 1.0 Received: by 10.60.12.8 with SMTP id u8mr16893102oeb.46.1345679628925; Wed, 22 Aug 2012 16:53:48 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Wed, 22 Aug 2012 16:53:48 -0700 (PDT) In-Reply-To: <20086782.TyIbvIWLSl@scott-latitude-e6320> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> Date: Wed, 22 Aug 2012 16:53:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 22 Aug 2012 23:53:50 -0000 On Wed, Aug 22, 2012 at 3:16 PM, Scott Kitterman wrote: > For this issue, I think it requires a two step answer: > > 1. Is the issue a security issue that should be mentioned in security > considerations > > 2. If it was, what should be said about it. > > I've reviewed BCP 72 and I think that the concern that is expressed falls > within the scope of a "Message Insertion" attack as described in Section > 3.3.2. So I think that as far as step 1 is concerned, it qualifies. > > I think that the proposed addition goes into far more detail than we need, > however. I would propose the following alternative: > > 10.7 Unauthorized Message Insertion > > Section 7.1 of [RFC5321] describes security considerations associated with > the SMTP protocol and spoofing. SPF is an attempt to address this issue. > When receivers deliver mail that has failed SPF checks then the affect SPF > has on this issue is reduced. In order to mitigate this concern it is > important that the results of SPF check be recorded (See [Section 7]) to > make it possible for MUAs to display message status to end users. I generally like it, but the language here doesn't acknowledge SPF's failure modes (e.g., forwarding). Perhaps: s/the affect SPF has on this issue/any protection SPF offers (modulo Section 9.2 and Section 9.3)/ ...or something along those lines? -MSK From barryleiba.mailing.lists@gmail.com Wed Aug 22 16:53: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 C165021F8670 for ; Wed, 22 Aug 2012 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q763cycgMELr for ; Wed, 22 Aug 2012 16:53:51 -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 7FB3121F8646 for ; Wed, 22 Aug 2012 16:53:50 -0700 (PDT) Received: by lahm15 with SMTP id m15so92517lah.31 for ; Wed, 22 Aug 2012 16:53:49 -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=Bfjv+QoTbTx+WAfce7rC+VpvVBEjCw/wxCB7xTkQfc4=; b=gXFqiDZFG2DNG58sRDKmBnUK+TioxKlGMHrsZHr9lmu3Ix0CX1WMZh9AMnkP3X95h5 AKQ+Dbki6LkwJkOmIEBskHxBaF8QEs28E7J1oMIXD6fMaMw7V+gvW//v1mqpnKafmxUM zy/mBMG0x4lMAFviaHMjmjzbNN0ucSPyMLd0qkyvyaX4y9FIVAOb0gU9uxFXM3RtWYf6 yFh7M/QQyKo25ky16YNtgU+Dq7RVw7BF9/vNwb9votnc53r2gXSb2x7rnEBJVtfwyQFs vo/78+m3TY5Ql2dAMO5uC4oNsWUgwTIy+q13e0SB6ovGWLEb3P79ggp0UybmS6b176kv A3HA== MIME-Version: 1.0 Received: by 10.152.123.140 with SMTP id ma12mr23322901lab.22.1345679629263; Wed, 22 Aug 2012 16:53:49 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Wed, 22 Aug 2012 16:53:49 -0700 (PDT) In-Reply-To: <503524F7.1020802@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <2748008.To0uIurt7Z@scott-latitude-e6320> <50333B83.5060603@tana.it> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <503524F7.1020802@tana.it> Date: Wed, 22 Aug 2012 19:53:49 -0400 X-Google-Sender-Auth: 8sZNXBbhgc3PQllvQ834BMki_Jg Message-ID: From: Barry Leiba To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d042fde3048a1ef04c7e3746e Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 23:53:51 -0000 --f46d042fde3048a1ef04c7e3746e Content-Type: text/plain; charset=ISO-8859-1 Anyone who's been following IESG reviews knows that Pete has been very picky about "bad" 2119 language. I have been less picky than he, but I've also been pushing back on it when I've seen it as detrimental to proper protocol documentation. I can't speak for Pete, but I will say for myself that I expect 4408bis to be an exception, in that I see the goal as minimizing changes in the process of moving the spec to Standards Track. I therefore expect that my review will be especially lenient about existing 2119 language, preferring to leave it unless it looks not just wrong, but specifically harmful. On the other hand, I expect to treat changes with due scepticism, with the idea that the change was made to fix a real problem, and it had better be right. Barry, AD On Wednesday, August 22, 2012, Alessandro Vesely wrote: > On Tue 21/Aug/2012 19:23:48 +0200 S Moonesamy wrote: > > At 00:40 21-08-2012, Alessandro Vesely wrote: > >> Since 5.7.1 is given in the example, the added meaning of a SHOULD is > >> that there are serious issues that the receiver should be aware of > >> before using a different code. Correct? > >> > >> In that case, would it be overly picky to remove the SHOULD for 550 > >> and just use it for X.7.1? E.g. > >> > >> The receiving server MAY reject messages using codes as specified > >> by SMTP ([RFC5321]). If Enhanced Mail System Status Codes are > >> supported, it SHOULD use 5.7.1 ([RFC3463]). > > > > The above question is one which I might ask. One of the problem, > > which is generally referred to as a rathole, is that the working group > > would have to be picky about all the RFC 2119 key words which are > > already in RFC 4408. That's going to end up as a lot of work. > > In general, I prefer clarity over formal purity. But this particular > knot isn't overly clear either. Discussing the semantics seems to be > one of those thing, like defining spam, that can go on for ages > without reaching any useful conclusion. Formalism, in this case, > seems to offer a neat hold, allowing us to handle the question of how > to gear policies into protocols without generating too much heat. As > we have a restricted charter and the protocol is well established > already, it should be easy... > > > The WG Chairs would have to see whether there is an adequate number > > of WG participants to review the changes. I am aware that some > > individuals who committed to review the WG work have not done that. > > My opinion is that all this would end up as a WG Chair problem. It > > is unlikely that the Responsible AD would try to convince me to the > > contrary as he might have a guess about I would do then. :-) > > I hope the WG can stay away from drastic measures. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d042fde3048a1ef04c7e3746e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anyone who's been following IESG reviews knows that Pete has been very = picky about "bad" 2119 language. =A0I have been less picky than h= e, but I've also been pushing back on it when I've seen it as detri= mental to proper protocol documentation.

I can't speak for Pete, but I will say for myself that I= expect 4408bis to be an exception, in that I see the goal as minimizing ch= anges in the process of moving the spec to Standards Track. =A0I therefore = expect that my review will be especially lenient about existing 2119 langua= ge, preferring to leave it unless it looks not just wrong, but specifically= harmful.

On the other hand, I expect to treat changes with due s= cepticism, with the idea that the change was made to fix a real problem, an= d it had better be right.

Barry, AD
On Wednesday, August 22, 2012, Alessandro Vesely wrote:
On Tue 21/Aug/2012 19:23:48 +0200 S Moonesamy wrote: > At 00:40 21-08-2012, Alessandro Vesely wrote:
>> Since 5.7.1 is given in the example, the added meaning of a SHOULD= is
>> that there are serious issues that the receiver should be aware of=
>> before using a different code. =A0Correct?
>>
>> In that case, would it be overly picky to remove the SHOULD for 55= 0
>> and just use it for X.7.1? =A0E.g.
>>
>> =A0 =A0The receiving server MAY reject messages using codes as spe= cified
>> =A0 =A0by SMTP ([RFC5321]). =A0If Enhanced Mail System Status Code= s are
>> =A0 =A0supported, it SHOULD use 5.7.1 ([RFC3463]).
>
> The above question is one which I might ask. =A0One of the problem, > which is generally referred to as a rathole, is that the working group=
> would have to be picky about all the RFC 2119 key words which are
> already in RFC 4408. =A0That's going to end up as a lot of work.
In general, I prefer clarity over formal purity. =A0But this particular
knot isn't overly clear either. =A0Discussing the semantics seems to be=
one of those thing, like defining spam, that can go on for ages
without reaching any useful conclusion. =A0Formalism, in this case,
seems to offer a neat hold, allowing us to handle the question of how
to gear policies into protocols without generating too much heat. =A0As
we have a restricted charter and the protocol is well established
already, it should be easy...

> The WG Chairs would have to see whether there is an adequate number > of WG participants to review the changes. =A0I am aware that some
> individuals who committed to review the WG work have not done that. > My opinion is that all this would end up as a WG Chair problem. =A0It<= br> > is unlikely that the Responsible AD would try to convince me to the > contrary as he might have a guess about I would do then. :-)

I hope the WG can stay away from drastic measures.

_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis
--f46d042fde3048a1ef04c7e3746e-- From superuser@gmail.com Wed Aug 22 16:58: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 3C19521F8619 for ; Wed, 22 Aug 2012 16:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyP2ky4GjlIY for ; Wed, 22 Aug 2012 16:58:44 -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 0014F21F8607 for ; Wed, 22 Aug 2012 16:58:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so442201obb.31 for ; Wed, 22 Aug 2012 16:58:43 -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=36GZk8AcRCi4n7ZQrvh8LjCgfyWsB+gUjBnbszaRc3s=; b=k+6fUexkv6AXuzslJq2atqAysIwCloprWxku6Nk2xcvYNX/kRil6Qu8J5W8FaJT1/j AEEBcJFNXzaTIKpbgf6Y1K+/l6tVlJJtvOd+ZtM53eyLpN86OVOD+OGBIFF3T7u+8LJe BSx+1Ntzxy9kSlEk8s37thUsgD0r5shYQlgcaIkb0v2HO/i5jIpi1mTM3hw+0BN91GRB DL1knW6tV7tOFCxpJiY1iyIBO/Iu22E1Q5OYBNtbfYNY8YzEDCUJ4DlEbHrXtmTZKSIy DfA9Zoa6Jr1o+5zeR86mfnd5JWnkU98tstGKJUlMuPw+bf21qR5ni7cTdcTb4oBY3SiT armQ== MIME-Version: 1.0 Received: by 10.60.6.6 with SMTP id w6mr3544980oew.129.1345679923507; Wed, 22 Aug 2012 16:58:43 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Wed, 22 Aug 2012 16:58:43 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120822155203.0a1090e8@resistor.net> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <4F6116A6.2090307@mail-abuse.org> <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> <2165564.7dxLrmajVl@scott-latitude-e6320> <6.2.5.6.2.20120822155203.0a1090e8@resistor.net> Date: Wed, 22 Aug 2012 16:58:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, John Levine , Hector Santos , Scott Kitterman , Philip Gladstone Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 23:58:45 -0000 On Wed, Aug 22, 2012 at 3:59 PM, S Moonesamy wrote: > I am addressing this message to the persons who did the surveys for RFC > 6686. I guess that's just me. I think Philip has dropped off the list, although I do have his original database available for anyone to query. >> It would be good to know if the information that's needed to assess the impact >> of such a void lookup limit can be garnered from the existing surveys and if >> the authors of one or more of the surveys would be up for gathering the data >> for us? > > Could you please help with the above? I don't think I have the background to know what a "void lookup" is. Can someone explain? Or even easier, what specific query do you need me to run? I can also export the database to a MySQL script if someone wants to run it without the intermediary. -MSK From superuser@gmail.com Wed Aug 22 17:02: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 5C47A21F866A for ; Wed, 22 Aug 2012 17:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwhzfpgNxCxT for ; Wed, 22 Aug 2012 17:02:18 -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 A7A8821F8653 for ; Wed, 22 Aug 2012 17:02:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so447260obb.31 for ; Wed, 22 Aug 2012 17:02:18 -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=FAp6ZuS/I/DmlBU8vBGnMp8LL5hOYVGnb/caTIO+EzI=; b=YPaAZota4Tc9uCLhgVVW8uaO2qk/BZ27M+NCrA6ybsWPGnXRwk4qTjDtBrl6XRdTtv xD2VKioI39OdKRP0pvxjQPR8oIUb1hKBqVXS3ytajnpKyDjnIALcWfNQKDkqK75M5GYG g4olsDJTDqvz7bjdqKt7kJzS+t2xTgu9Njh/OA1zZikOyYJZo07AdYoyFg67ufXLrHbI m8mZ0ap1nBWXGBUTJScs6fgLlt2U19bQcI/KOTouFtreb4iqkatBZHaRsMjECFVgd0kC f9MYIc9+iuPJEAuaGWKwnne2HF9fuftLvlB3Pc9hxrdXT8kvomSWTjNZf3PicRp/2nbW iPXA== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr16723601oeg.37.1345680138317; Wed, 22 Aug 2012 17:02:18 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Wed, 22 Aug 2012 17:02:18 -0700 (PDT) In-Reply-To: <4563708.iYIAOlqAVf@scott-latitude-e6320> References: <4563708.iYIAOlqAVf@scott-latitude-e6320> Date: Wed, 22 Aug 2012 17:02:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 00:02:34 -0000 On Wed, Aug 22, 2012 at 3:31 PM, Scott Kitterman wrote: >> Given that we're not able to get rid of macros outright despite their >> very low usage until a later version of the spec, I submit that macros >> should also be on that list. My understanding of the technical >> discussion is not that removing them would be a bad idea overall, but >> that removing them now is simply not permitted. > > I'm not aware of any technical specific technical issues with macros that would > cause us to do this. OTOH, if we do, we are not just deprecating specific > functions within the protocol, but deprecating functional capabilities such as > per-user policies, logging specifics of remote SPF checks to support deployment > verification and others. I think given the usage statistics, that's making some presumptions of what the users of macros are getting out of it. Since I have those data, I'll ask them and hopefully that will provide some insight. Could be that they'd be fine without. > I know a number of people want macros removed (and if not removed deprecated) > because it would simplify the protocol. Given that there are protocol > features that cannot be accomplished without macros, I don't think this is a > sufficient argument. It's true that the functionality can't be replaced, and it's a clever idea, but that doesn't mean it's actually needed. -MSK From spf2@kitterman.com Wed Aug 22 17:27: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 1B66C21F8665 for ; Wed, 22 Aug 2012 17:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUvBR7b2HCsf for ; Wed, 22 Aug 2012 17:27:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8396921F860D for ; Wed, 22 Aug 2012 17:27:09 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id DD239D0408D; Wed, 22 Aug 2012 19:27:08 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345681628; bh=zHqaC2Sj2WMdu6ifeQDDCiwwKeuLQzOcMpPoCDns+VQ=; h=References:In-Reply-To:Subject:From:Date:To:From; b=p78dEYewZbuLDb0nQd0M0nKdzuZN2CDxYQWjBOANkPxaiZ8V39YJux3LwDrnL8JJ7 YxjHKOnHMyE2yiKIhRgecMHWwb8tBC3PT2okmJ59+6Cr3YTtgO9X6N7rUa4pbY40cv 5cNb/uJh+74wPdHfTkwTHCNRMsQ2eDj1V4IxAM5Y= Received: from [IPV6:2600:1002:b017:3a1d:cb54:1392:7951:efff] (unknown [IPv6:2600:1002:b017:3a1d:cb54:1392:7951:efff]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6B572D0408A; Wed, 22 Aug 2012 19:27:08 -0500 (CDT) References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <4F6116A6.2090307@mail-abuse.org> <6.2.5.6.2.20120822140310.0a66f4c0@resistor.net> <2165564.7dxLrmajVl@scott-latitude-e6320> <6.2.5.6.2.20120822155203.0a1090e8@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 22 Aug 2012 20:27:05 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 00:27:10 -0000 "Murray S. Kucherawy" wrote: >On Wed, Aug 22, 2012 at 3:59 PM, S Moonesamy >wrote: >> I am addressing this message to the persons who did the surveys for >RFC >> 6686. > >I guess that's just me. I think Philip has dropped off the list, >although I do have his original database available for anyone to >query. > >>> It would be good to know if the information that's needed to assess >the impact >>> of such a void lookup limit can be garnered from the existing >surveys and if >>> the authors of one or more of the surveys would be up for gathering >the data >>> for us? >> >> Could you please help with the above? > >I don't think I have the background to know what a "void lookup" is. >Can someone explain? > >Or even easier, what specific query do you need me to run? > >I can also export the database to a MySQL script if someone wants to >run it without the intermediary. > It's a lookup for a mechanism/modifier that returns NXDOMAIN. For example, the A lookup for example.com that results from a:example.com. The goal is to determine if we can set a maximum number without impacting existing records. I suspect the impact will be low or nil since Mail:: SPF has had such a limit for some time without issue. Scott K From srs0=fvkhi=gx=gathman.org=stuart@fairfax.gathman.org Wed Aug 22 18:02: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 A6B8D21F84E2 for ; Wed, 22 Aug 2012 18:02: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NvXojOCDX2S for ; Wed, 22 Aug 2012 18:02:32 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA521F84D3 for ; Wed, 22 Aug 2012 18:02:31 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q7N12Ssq018588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 21:02:28 -0400 Received: from silver.gathman.org ([192.168.10.214]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id q7N12Kfs020173 for ; Wed, 22 Aug 2012 21:02:27 -0400 Message-ID: <50358119.7040603@gathman.org> Date: Wed, 22 Aug 2012 21:02:17 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120822121703.0a11bf48@elandnews.com> <503533C4.2070900@dcrocker.net> <20120822212230.GD43925@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 01:18:45 -0000 On 08/22/2012 05:25 PM, Scott Kitterman wrote: > The practice is deprecated and should generally be avoided. While it > may be useful in certain specific circumstances it's not part of the > SPF protocol and results of guessing SPF like records should not be > referred to as SPF results. >> That doesn't sound to me like something I'd like to add to the formal >> SPF protocol document at all. But I emphasise, I have no hat on. >> > It certainly isn't SPF, but it is a good idea IMO when there is no SPF record. 4408bis should explicitly forbidding calling it (or any other heuristic) an SPF result in Received-SPF or Authentication-Results. (And note that both Received-SPF and Authentication-Results provide extension frameworks for user-defined results.) From srs0=fvkhi=gx=gathman.org=stuart@fairfax.gathman.org Wed Aug 22 18:18: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 707EE21F8565 for ; Wed, 22 Aug 2012 18:18: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBKaVaTD6bVd for ; Wed, 22 Aug 2012 18:18:21 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id B7C2921F8564 for ; Wed, 22 Aug 2012 18:18:20 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q7N1IJSN018723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2012 21:18:19 -0400 Received: from silver.gathman.org ([192.168.10.214]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id q7N1IIh4021010 for ; Wed, 22 Aug 2012 21:18:19 -0400 Message-ID: <503584DA.8070403@gathman.org> Date: Wed, 22 Aug 2012 21:18:18 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> In-Reply-To: <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 01:18:49 -0000 On 08/22/2012 03:16 PM, S Moonesamy wrote: > > Issue #12 has been open for some time. Please review the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html and > Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue. Using <> to forward emails is a bad idea. Empty mail from is reserved for error/status returns. In fact, many MTAs use a VERP like scheme to reject <> for emails they did not send. -1 for using <> as a solution to the mis-configured user of forwarding services problem BTW, section 9.2.2 part 2 does not mention one effective scheme: the forwarder simply rejects the email with 552 status (redirect IIRC) and the target email. And for that matter, if the target email simply rejects an email that fails SPF due to a forwarder, the sender has the target email in the bounce. Using that info is not as easy to automate as with 552, but a somewhat savy end-user could do so manually. From hsantos@isdg.net Wed Aug 22 20:14: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 481B521F85F7 for ; Wed, 22 Aug 2012 20:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[AWL=-1.803, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_38=0.6, MANGLED_LOOK=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vxJ5L-0-2+H for ; Wed, 22 Aug 2012 20:14:44 -0700 (PDT) Received: from groups.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 36E8821F8503 for ; Wed, 22 Aug 2012 20:14:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5794; t=1345691676; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=CXn9Yup4FoDzIYM/HVHLuLDoIXk=; b=q8SHNt8umKGynUwaattc Er1ploQpEQ/0QupzHBRrPERSXUMHyVP/aTyIu1aGx+MHybNZhRjGzsJIlU0xIXJH 1m1QijlDi2J+FaqTIZb43fejGTwlyOQdb2v+2BFz9K6j+wlal70jOt/o/RhAikvO xyDy0ICHLAywL99bob/Yv/w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 23:14:36 -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 1713473307.367.2152; Wed, 22 Aug 2012 23:14:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5794; t=1345691482; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0x/4Agn uy72XFXUf8BqGYpTNX3VKSFCv9tq5hlrqCpI=; b=dJRA4NyZPXQGqgWn+hvmpmf 8B3ixLQHAhGlPARjFk1j2ONIYUWLJ6TkRcHjcOhQDwUT4cW4wkDBPQ8YVN2Dcqp1 pbgeZklyjJrS6milWVvE1qPdpRCb1497QoQ/HBUagZsSFpv0C8WIPRaBWRuNKmxm gcutnLFCDeX+OO7cmVqQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 23:11:22 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2312279380.7.612; Wed, 22 Aug 2012 23:11:20 -0400 Message-ID: <5035A047.1030604@isdg.net> Date: Wed, 22 Aug 2012 23:15:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> In-Reply-To: <20086782.TyIbvIWLSl@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 03:14:45 -0000 Scott Kitterman wrote: > I think that the proposed addition goes into far more detail than we need, > however. I would propose the following alternative: > > 10.7 Unauthorized Message Insertion > > Section 7.1 of [RFC5321] describes security considerations associated with > the SMTP protocol and spoofing. SPF is an attempt to address this issue. > When receivers deliver mail that has failed SPF checks then the affect SPF > has on this issue is reduced. In order to mitigate this concern it is > important that the results of SPF check be recorded (See [Section 7]) to > make it possible for MUAs to display message status to end users. This is ok, however, with two critical points. 1) We have a history of MUAs that do not qualify to do the things we need done and also consistently across the board, as a result backends has taken responsibility in much of this area. 2) We have different MUAs, Online vs Offline. There are other forms, i.e. mixed that 5321 touches base with with SPLIT-UI concepts, but overall, as an implementator of 4-6 different MUAs, they generally fall in two categories - online which means the backend has control and offline where we have a store and forward protocol for a time-shifted Mail Reader/Writer application. The latter also has backend control and is one area that should be part of the security highlight. The classic examples are dial up, telnet, IMAP, even NNTP and web-mail and others for online and POP3, QWK, FIDONET etc for offline. I tried to KISS this with the two sentences I had: ...... For example, for POP3, the stream may need to be separated and not made available for pickup. For online access, like Web-based Mail or IMAP, the backend has better control of how mail is filtered, sorted, displayed and rendered. Another way to look at it, is that SPF is more for the backend than for the OFFLINE MUA. I can understand how in practice we tend to lump the "MUA" as one idea for all types, but that is where we get into trouble sometimes in generalization and we never do much for the MUA concepts. I think we can preempt that by simply highlighting there are different ways to access mail and we can only really talk about standard protocols like POP3, IMAP, even NNTP but also perhaps the common understood method we call WebMail which is generally a proprietary access format. Perhaps a better ending sentence may be to use MFA (Mail Filtering Agent) along with MUA. ... to make it possible for MFA (Mail Filtering Agents) to separate mail storage streams, i.e. Junk MailBoxes/Filters, etc, and for advanced MUAs to display message status to end users. I prefer to use term "advanced" with MUAs because not all offline mail readers have the extra RBM (Rule Based Messaging) technology (btw, once patented - expired years ago) and some MUAs presume and rely on the backend not passing the junk anyway. The latter is where POP3 comes into play because that is one single stream from the backend. IMAP, NNTP are multiple streams protocols where you can have separation at the backend. But as indicated about, one goal is to highlight that pop3 mail pickup does not get the SPF failed mail for example. I believe I mentioned that with HOTMAIL.COM, I had forced a SPF FAIL message and it was junk mail saved only viewable online only. Via POP3, I didn't get it. We can easily run a few test here at various ESPs that purportedly support SPF using manual TELNET port 25 transactions, using a spoofed MAIL FROM from a domain that has a -ALL policy. Let me try it at gmail.com using a facebook.com return path with a RCPT TO: to my gmail account..... -------------------------- 220 mx.google.com ESMTP g67si5696422yhk.95 EHLO LOCALHOST 250-mx.google.com at your service, [208.247.131.8] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250 ENHANCEDSTATUSCODES MAIL FROM: 250 2.1.0 OK g67si5696422yhk.95 RCPT TO: 250 2.1.5 OK g67si5696422yhk.95 DATA 354 Go ahead g67si5696422yhk.95 Date: Wed, 22 Aug 2012 17:51:33 -0400 From: Hector Santos Organization: Santronics Software, Inc. TEST MESSAGE MIME-Version: 1.0 To: sant9442@gmail.com Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF Test of the american broadcasting system . 250 2.0.0 OK 1345690848 g67si5696422yhk.95 quit 221 2.0.0 closing connection g67si5696422yhk.95 Connection to host lost. -------------------------- Now checking my sant9442@gmail.com account.... It was placed in a SPAM BOX with this notification at the top of the basic header display: Why is this message in Spam? It's similar to messages that were detected by our spam filters. Learn more and viewing the original message headers shows the two trace lines: Received-SPF: fail (google.com: domain of testuser@facebookmail.com does not designate 208.247.131.8 as permitted sender) client-ip=208.247.131.8; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of testuser@facebookmail.com does not designate 208.247.131.8 as permitted sender) smtp.mail=testuser@facebookmail.com This is exact behavior we want for a accept/mark mode of operation. But keep in mind this is online access. I believe the goal is to add the highlight regarding POP3 access and that its recommended it should not be part of the normal pop3 mail pick up. In most cases, it will naturally be the case because the backend already separated the stream and I believe (without actually do it) if I used a POP3 access to gmail.com (and I don't recall if they do offer it), I would not get the spoofed message. However, via IMAP access, I see it in the spam folder using my Thunderbird. -- HLS From spf2@kitterman.com Wed Aug 22 20:31: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 3189D21F851B for ; Wed, 22 Aug 2012 20:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, MANGLED_LOOK=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A5iw-BLmXvo for ; Wed, 22 Aug 2012 20:31:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 32F0A21F8517 for ; Wed, 22 Aug 2012 20:31:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 81ED820E410A; Wed, 22 Aug 2012 23:31:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345692702; bh=sO228v5ugYJJNtT3wNrZ/+0lnp8Jh6n8hnGflGzhrI0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HOAykJ4y3H6QaZNBvP0OYt5XDQkYcSnmC2J3GUNEVhlgk48rXm73p655ipVxanIL7 eKdX6CVN4KLkiWj98Prhyzvfh+8XdFjQwKVtrQnwoAdix1Vb/FkfwdoWdU2VKKT9JJ ParbFxd3EJreU0hLpWBMlM46YZtVfrcj0uK5WFfc= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 51EBF20E4086; Wed, 22 Aug 2012 23:31:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 23:31:40 -0400 Message-ID: <2267574.6GQXnqNoLg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5035A047.1030604@isdg.net> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@scott-latitude-e6320> <5035A047.1030604@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 03:31:44 -0000 On Wednesday, August 22, 2012 11:15:19 PM Hector Santos wrote: > Scott Kitterman wrote: > > I think that the proposed addition goes into far more detail than we need, > > however. I would propose the following alternative: > > > > 10.7 Unauthorized Message Insertion > > > > Section 7.1 of [RFC5321] describes security considerations associated > > with > > the SMTP protocol and spoofing. SPF is an attempt to address this > > issue. > > When receivers deliver mail that has failed SPF checks then the affect > > SPF > > has on this issue is reduced. In order to mitigate this concern it is > > important that the results of SPF check be recorded (See [Section 7]) > > to > > make it possible for MUAs to display message status to end users. > > This is ok, however, with two critical points. > > 1) We have a history of MUAs that do not qualify to do the things we > need done and also consistently across the board, as a result backends > has taken responsibility in much of this area. > > 2) We have different MUAs, Online vs Offline. There are other forms, > i.e. mixed that 5321 touches base with with SPLIT-UI concepts, but > overall, as an implementator of 4-6 different MUAs, they generally > fall in two categories - online which means the backend has control > and offline where we have a store and forward protocol for a > time-shifted Mail Reader/Writer application. The latter also has > backend control and is one area that should be part of the security > highlight. > > The classic examples are dial up, telnet, IMAP, even NNTP and web-mail > and others for online and POP3, QWK, FIDONET etc for offline. I > tried to KISS this with the two sentences I had: > > ...... For example, for POP3, the stream may need > to be separated and not made available for pickup. For online access, > like Web-based Mail or IMAP, the backend has better control of how > mail is filtered, sorted, displayed and rendered. > > Another way to look at it, is that SPF is more for the backend than > for the OFFLINE MUA. > > I can understand how in practice we tend to lump the "MUA" as one idea > for all types, but that is where we get into trouble sometimes in > generalization and we never do much for the MUA concepts. I think we > can preempt that by simply highlighting there are different ways to > access mail and we can only really talk about standard protocols like > POP3, IMAP, even NNTP but also perhaps the common understood method we > call WebMail which is generally a proprietary access format. Perhaps > a better ending sentence may be to use MFA (Mail Filtering Agent) > along with MUA. > > ... to make it possible for MFA (Mail Filtering Agents) to separate > mail storage streams, i.e. Junk MailBoxes/Filters, etc, and for > advanced MUAs to display message status to end users. > > I prefer to use term "advanced" with MUAs because not all offline mail > readers have the extra RBM (Rule Based Messaging) technology (btw, > once patented - expired years ago) and some MUAs presume and rely on > the backend not passing the junk anyway. The latter is where POP3 > comes into play because that is one single stream from the backend. > IMAP, NNTP are multiple streams protocols where you can have > separation at the backend. But as indicated about, one goal is to > highlight that pop3 mail pickup does not get the SPF failed mail for > example. I believe I mentioned that with HOTMAIL.COM, I had forced a > SPF FAIL message and it was junk mail saved only viewable online only. > Via POP3, I didn't get it. > > We can easily run a few test here at various ESPs that purportedly > support SPF using manual TELNET port 25 transactions, using a spoofed > MAIL FROM from a domain that has a -ALL policy. > > Let me try it at gmail.com using a facebook.com return path with a > RCPT TO: to my gmail account..... > > -------------------------- > 220 mx.google.com ESMTP g67si5696422yhk.95 > EHLO LOCALHOST > 250-mx.google.com at your service, [208.247.131.8] > 250-SIZE 35882577 > 250-8BITMIME > 250-STARTTLS > 250 ENHANCEDSTATUSCODES > MAIL FROM: > 250 2.1.0 OK g67si5696422yhk.95 > RCPT TO: > 250 2.1.5 OK g67si5696422yhk.95 > DATA > 354 Go ahead g67si5696422yhk.95 > Date: Wed, 22 Aug 2012 17:51:33 -0400 > From: Hector Santos > Organization: Santronics Software, Inc. TEST MESSAGE > MIME-Version: 1.0 > To: sant9442@gmail.com > Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF > > Test of the american broadcasting system > . > 250 2.0.0 OK 1345690848 g67si5696422yhk.95 > quit > 221 2.0.0 closing connection g67si5696422yhk.95 > > Connection to host lost. > -------------------------- > > > Now checking my sant9442@gmail.com account.... > > It was placed in a SPAM BOX with this notification at the top of the > basic header display: > > Why is this message in Spam? It's similar to messages that were > detected > by our spam filters. Learn more > > and viewing the original message headers shows the two trace lines: > > Received-SPF: fail (google.com: domain of testuser@facebookmail.com > does not designate 208.247.131.8 as permitted sender) > client-ip=208.247.131.8; > Authentication-Results: mx.google.com; spf=hardfail (google.com: > domain of testuser@facebookmail.com does not designate 208.247.131.8 > as permitted sender) smtp.mail=testuser@facebookmail.com > > This is exact behavior we want for a accept/mark mode of operation. > > But keep in mind this is online access. I believe the goal is to add > the highlight regarding POP3 access and that its recommended it should > not be part of the normal pop3 mail pick up. In most cases, it will > naturally be the case because the backend already separated the stream > and I believe (without actually do it) if I used a POP3 access to > gmail.com (and I don't recall if they do offer it), I would not get > the spoofed message. However, via IMAP access, I see it in the spam > folder using my Thunderbird. SPF is an MTA to MTA protocol. I don't think it's appropriate to include an MUA design missive in the security considerations. I think it's enough to document the consideration and let MUA designers deal with it appropriately. If you look at RFC 5451 Section 7.1 there is some discussion about similar concerns for authentication-results header fields. This can get very complicated very quickly and should, if more detail really needs to be standarized, done in a different document as it's a different problem. Scott K From spf2@kitterman.com Wed Aug 22 20:50: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 39F5121F8545 for ; Wed, 22 Aug 2012 20:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc+zKaZ2WZZp for ; Wed, 22 Aug 2012 20:50:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 831F021F8543 for ; Wed, 22 Aug 2012 20:50:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 01F9120E410A; Wed, 22 Aug 2012 23:50:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345693852; bh=8E9bJOmPR2KhR7lNFgsaEyDLZxfv3uYMws5HYp4JihA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PhsODYuvD310hVNdvmlvt40dILrPV0+dOSUd4LNtPAZJif97TRgwsw5P3vqBMRyv4 ZY5qETVkPa6kt7ty47zcNWMwZv/ta6j/KafNIf3XM2M0QLkJ8o/mUlqmUAxYouTZpD EQnR/YeIrXrjj+mgM23ghcQIjrC8pO9uaxidKQP0= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C4E3820E4086; Wed, 22 Aug 2012 23:50:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 22 Aug 2012 23:50:50 -0400 Message-ID: <2050339.9cOfrxQYRQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <50350126.2010506@isdg.net> <22809811.9sJZkmpsv2@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] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 03:50:53 -0000 On Wednesday, August 22, 2012 10:49:12 AM Murray S. Kucherawy wrote: > I still think all of this is unnecessary. The current document > doesn't demand either rejection or marking, and that's the right thing > to do, and in fact reflects the varied current practices. > > With respect to the proposal: > > On Wed, Aug 22, 2012 at 10:03 AM, Scott Kitterman wrote: > > I think this gets into too much detail about internals of final delivery > > to the user. I think it would be sufficient to add a sentence to the > > second paragraph> > > of 9.3.2. How about: > > SPF fail results can also be used as one input into a larger set of > > evaluations which might, based on the overall evaluation result in > > the email being marked negatively in some way (this might be via > > delivery to a special spam folder, modifying subject lines, or other > > locally determined means). Developing the details of such an > > approach have to be based on local conditions and requirements. > > Using SPF results in this way does not have the advantages of > > resource conservation and immediate feedback to the sender associated > > with SMTP rejection, but could produce fewer undesirable rejections > > in a well designed system. Such an approach might result in email that > > was > > not authorized by the sending ADMD being unknowingly delivered to end > > users. > > I guess I hadn't read 9.3.2 in a while. The first sentence of this > paragraph seems to be mangled. It seems OK to me. SPF fail results can also be used as one input into a larger set of evaluations which might, based on the overall evaluation result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). What did you have in mind? Reading it again, I think can also is probably better put as can alternately, but I don't think that qualifies as mangled. Scott K From spf2@kitterman.com Wed Aug 22 21:01: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 79FA921F857D for ; Wed, 22 Aug 2012 21:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prjLhMgWs02h for ; Wed, 22 Aug 2012 21:01:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A940D21F8503 for ; Wed, 22 Aug 2012 21:01:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2712420E410A; Thu, 23 Aug 2012 00:01:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345694466; bh=vkaHrz5VM/Ed08IAlvn/rRyJsu0XqlYndKx4kJfjk6M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=leYZ8KKtib1wvA1FrBHLBgeIlJGgmU4Pxwoxvg0ldJtkGdlUw10cnHVHgVhSAqPav rysG8alGEX3Flde7FFlMD8pw9IXENpCyj1EgNi7A+X1JIUZE3qSBRF9NCfvTJEIMw4 dE2wja7zkHr4xDyPD5GyoWUMTwIEE9AP3XkCFcIE= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ED59E20E4086; Thu, 23 Aug 2012 00:01:05 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:01:04 -0400 Message-ID: <4707324.GTeE9m1GuQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1345656319.64623.YahooMailClassic@web125405.mail.ne1.yahoo.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] review of 4408bis-05 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:01:09 -0000 On Wednesday, August 22, 2012 11:03:10 AM Murray S. Kucherawy wrote: > On Wed, Aug 22, 2012 at 10:25 AM, Arthur Thisell wrote: > > I mentioned this in a message earlier today that I had reviewed all > > changes since RFC 4408, and I had mentioned to Scott off-list that I > > hadn't found anything worth mentioning. But, what the heck, here is my > > list anyway. > > > > First, I cringe at how much 4408bis has grown. RFC 4408 was already 46 > > pages long, all of RFC 2821 was only 79. RFC 4408bis is now 63 pages > > (with 3 pages of change notes that I've excluded). I realize a lot of > > the new text is in the non-normative section 9, but there is a lot of > > other stuff added here and there. Just like unneeded features/options > > make it harder to implement a spec correct, adding unimportant verbiage > > makes it harder to find the important stuff. > Here's a side-by-side diff of the two documents: > > http://www.blackops.org/~msk/spfbis/draft-ietf-spfbis-4408bis-05-from-rfc440 > 8.diff.html > > A cursory review of this, which mainly involved me spinning the mouse > wheel until big sections of added/removed text came up, didn't cause > me much alarm. Most of the added text covers evolutionary history or > things we've agreed are useful clarifications, or the aforementioned > "change since" stuff. > > (A couple of scan-time notes: (a) typo in 9.3 while I was scrolling > around: "dispositive on it's own" should be "dispositive on its own"; > (b) 4.5 "must be discarded" should be "MUST be discarded".) Fixed. This caused me to do a case sensitive search for "must" and it returned a depressing number of results, which I also fixed. Scott K From hsantos@isdg.net Wed Aug 22 21:01: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 58BD421F8581 for ; Wed, 22 Aug 2012 21:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.748 X-Spam-Level: X-Spam-Status: No, score=-100.748 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MANGLED_LOOK=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILkHvVPwrkyV for ; Wed, 22 Aug 2012 21:01:18 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C83B21F8503 for ; Wed, 22 Aug 2012 21:01:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7686; t=1345694476; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qVvUqT2MJm2PP/SHiOHn/SWuFY4=; b=GQLF+GQpJ0VfoMHoy6j7 YbEmfvtGt7YrtiSh3LD7mkyVx4FEp5Mc9gcyqGm7QBJ84E+gzaGf6ri+7WwLBlXF e1nmvIx5IPoLJYgeFPsXVAv7YG1s6VCzjRZGspoI1DmWd7vzekSPa49ZuCrusOu8 NjyNVlLgyQhd0Yd/8xI9UgY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 00:01:16 -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 1716273447.367.3320; Thu, 23 Aug 2012 00:01:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7686; t=1345694285; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qV/z58P mLzTPSgr7l8sLXI89EFZMMn3aF8URw/ub9o4=; b=s2ttNGsIYwQm33C02VhjaML 7GSDz9WwyCiio4ZecT1zDwkpO/6L/sG+6YKlr5lcARC/Qtf9h4zIaGJZYkwKn615 rJWuGc7Zo4nnmXbggwG70UFZVRxqwgT3acOfbsV1sqHkrjWcJqNuq8/AG7BkhQi6 euPIAvvyQAB+KfmUhWlM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 22 Aug 2012 23:58: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 2315083239.7.5148; Wed, 22 Aug 2012 23:58:04 -0400 Message-ID: <5035AAFF.1070402@isdg.net> Date: Thu, 23 Aug 2012 00:01:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@scott-latitude-e6320> <5035A047.1030604@isdg.net> <2267574.6GQXnqNoLg@scott-latitude-e6320> In-Reply-To: <2267574.6GQXnqNoLg@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:01:19 -0000 Maybe I am not reading you right. Are you agreeing that the SPF trace lines is more for the backend (MDA) then for the MUAs? Separation is the key here for the security note and that will basically remove the MUA factor or rather move the ergonomics to the MUA (spam boxes, showing notifiers, etc). Overall, we can never depend on MUAs and there is different types. Consider that a MDA that does not have "Spam Folders" for users, they are at a higher risk when using ACCEPT+MARK mode that is 100% resolved by using as REJECT mode. Separation for Accept/Mark - that is all the point is about the security note of my posted issue. Its not a mandate for design, its a security note implementators need to be aware off. Scott Kitterman wrote: > On Wednesday, August 22, 2012 11:15:19 PM Hector Santos wrote: >> Scott Kitterman wrote: >>> I think that the proposed addition goes into far more detail than we need, >>> however. I would propose the following alternative: >>> >>> 10.7 Unauthorized Message Insertion >>> >>> Section 7.1 of [RFC5321] describes security considerations associated >>> with >>> the SMTP protocol and spoofing. SPF is an attempt to address this >>> issue. >>> When receivers deliver mail that has failed SPF checks then the affect >>> SPF >>> has on this issue is reduced. In order to mitigate this concern it is >>> important that the results of SPF check be recorded (See [Section 7]) >>> to >>> make it possible for MUAs to display message status to end users. >> This is ok, however, with two critical points. >> >> 1) We have a history of MUAs that do not qualify to do the things we >> need done and also consistently across the board, as a result backends >> has taken responsibility in much of this area. >> >> 2) We have different MUAs, Online vs Offline. There are other forms, >> i.e. mixed that 5321 touches base with with SPLIT-UI concepts, but >> overall, as an implementator of 4-6 different MUAs, they generally >> fall in two categories - online which means the backend has control >> and offline where we have a store and forward protocol for a >> time-shifted Mail Reader/Writer application. The latter also has >> backend control and is one area that should be part of the security >> highlight. >> >> The classic examples are dial up, telnet, IMAP, even NNTP and web-mail >> and others for online and POP3, QWK, FIDONET etc for offline. I >> tried to KISS this with the two sentences I had: >> >> ...... For example, for POP3, the stream may need >> to be separated and not made available for pickup. For online access, >> like Web-based Mail or IMAP, the backend has better control of how >> mail is filtered, sorted, displayed and rendered. >> >> Another way to look at it, is that SPF is more for the backend than >> for the OFFLINE MUA. >> >> I can understand how in practice we tend to lump the "MUA" as one idea >> for all types, but that is where we get into trouble sometimes in >> generalization and we never do much for the MUA concepts. I think we >> can preempt that by simply highlighting there are different ways to >> access mail and we can only really talk about standard protocols like >> POP3, IMAP, even NNTP but also perhaps the common understood method we >> call WebMail which is generally a proprietary access format. Perhaps >> a better ending sentence may be to use MFA (Mail Filtering Agent) >> along with MUA. >> >> ... to make it possible for MFA (Mail Filtering Agents) to separate >> mail storage streams, i.e. Junk MailBoxes/Filters, etc, and for >> advanced MUAs to display message status to end users. >> >> I prefer to use term "advanced" with MUAs because not all offline mail >> readers have the extra RBM (Rule Based Messaging) technology (btw, >> once patented - expired years ago) and some MUAs presume and rely on >> the backend not passing the junk anyway. The latter is where POP3 >> comes into play because that is one single stream from the backend. >> IMAP, NNTP are multiple streams protocols where you can have >> separation at the backend. But as indicated about, one goal is to >> highlight that pop3 mail pickup does not get the SPF failed mail for >> example. I believe I mentioned that with HOTMAIL.COM, I had forced a >> SPF FAIL message and it was junk mail saved only viewable online only. >> Via POP3, I didn't get it. >> >> We can easily run a few test here at various ESPs that purportedly >> support SPF using manual TELNET port 25 transactions, using a spoofed >> MAIL FROM from a domain that has a -ALL policy. >> >> Let me try it at gmail.com using a facebook.com return path with a >> RCPT TO: to my gmail account..... >> >> -------------------------- >> 220 mx.google.com ESMTP g67si5696422yhk.95 >> EHLO LOCALHOST >> 250-mx.google.com at your service, [208.247.131.8] >> 250-SIZE 35882577 >> 250-8BITMIME >> 250-STARTTLS >> 250 ENHANCEDSTATUSCODES >> MAIL FROM: >> 250 2.1.0 OK g67si5696422yhk.95 >> RCPT TO: >> 250 2.1.5 OK g67si5696422yhk.95 >> DATA >> 354 Go ahead g67si5696422yhk.95 >> Date: Wed, 22 Aug 2012 17:51:33 -0400 >> From: Hector Santos >> Organization: Santronics Software, Inc. TEST MESSAGE >> MIME-Version: 1.0 >> To: sant9442@gmail.com >> Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF >> >> Test of the american broadcasting system >> . >> 250 2.0.0 OK 1345690848 g67si5696422yhk.95 >> quit >> 221 2.0.0 closing connection g67si5696422yhk.95 >> >> Connection to host lost. >> -------------------------- >> >> >> Now checking my sant9442@gmail.com account.... >> >> It was placed in a SPAM BOX with this notification at the top of the >> basic header display: >> >> Why is this message in Spam? It's similar to messages that were >> detected >> by our spam filters. Learn more >> >> and viewing the original message headers shows the two trace lines: >> >> Received-SPF: fail (google.com: domain of testuser@facebookmail.com >> does not designate 208.247.131.8 as permitted sender) >> client-ip=208.247.131.8; >> Authentication-Results: mx.google.com; spf=hardfail (google.com: >> domain of testuser@facebookmail.com does not designate 208.247.131.8 >> as permitted sender) smtp.mail=testuser@facebookmail.com >> >> This is exact behavior we want for a accept/mark mode of operation. >> >> But keep in mind this is online access. I believe the goal is to add >> the highlight regarding POP3 access and that its recommended it should >> not be part of the normal pop3 mail pick up. In most cases, it will >> naturally be the case because the backend already separated the stream >> and I believe (without actually do it) if I used a POP3 access to >> gmail.com (and I don't recall if they do offer it), I would not get >> the spoofed message. However, via IMAP access, I see it in the spam >> folder using my Thunderbird. > > SPF is an MTA to MTA protocol. I don't think it's appropriate to include an > MUA design missive in the security considerations. I think it's enough to > document the consideration and let MUA designers deal with it appropriately. > If you look at RFC 5451 Section 7.1 there is some discussion about similar > concerns for authentication-results header fields. This can get very > complicated very quickly and should, if more detail really needs to be > standarized, done in a different document as it's a different problem. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Wed Aug 22 21:03: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 9F70F11E808D for ; Wed, 22 Aug 2012 21:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G67pXTIENEm for ; Wed, 22 Aug 2012 21:03:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 220AD21F8501 for ; Wed, 22 Aug 2012 21:03:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9670920E410A; Thu, 23 Aug 2012 00:03:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345694589; bh=CJrTPDWzNrVKHDTp/oIgMh/V+yvbgGFHkaPOnL17prg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TJoqn2NiaHQ74wHom4sAugu+OVzYa5+2UNnOqhXXzq1LRAxALzyQDKOS1M4novGZv FBO0HCeU9ihFOidpjJWINx1AjI436v6GmgVgUTbp44o4VrD7i6ForUPlIS5V5R54a+ Omco1tJINJfgO3x4hwfuWnzwb4TqqsWh6aeYOhiU= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 62B0820E4086; Thu, 23 Aug 2012 00:03:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:03:08 -0400 Message-ID: <1449082.EbgXUPjcEi@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:03:10 -0000 On Wednesday, August 22, 2012 04:53:48 PM Murray S. Kucherawy wrote: > On Wed, Aug 22, 2012 at 3:16 PM, Scott Kitterman wrote: > > For this issue, I think it requires a two step answer: > > > > 1. Is the issue a security issue that should be mentioned in security > > considerations > > > > 2. If it was, what should be said about it. > > > > I've reviewed BCP 72 and I think that the concern that is expressed falls > > within the scope of a "Message Insertion" attack as described in Section > > 3.3.2. So I think that as far as step 1 is concerned, it qualifies. > > > > I think that the proposed addition goes into far more detail than we need, > > however. I would propose the following alternative: > > > > 10.7 Unauthorized Message Insertion > > > > Section 7.1 of [RFC5321] describes security considerations associated > > with > > the SMTP protocol and spoofing. SPF is an attempt to address this > > issue. > > When receivers deliver mail that has failed SPF checks then the affect > > SPF > > has on this issue is reduced. In order to mitigate this concern it is > > important that the results of SPF check be recorded (See [Section 7]) > > to > > make it possible for MUAs to display message status to end users. > > I generally like it, but the language here doesn't acknowledge SPF's > failure modes (e.g., forwarding). Perhaps: > > s/the affect SPF has on this issue/any protection SPF offers (modulo > Section 9.2 and Section 9.3)/ > > ...or something along those lines? I think it's the other way around. Those failure modes are reasons why someone might choose not to reject at SMTP time, but they aren't part of this issue, I don't think. Scott K From spf2@kitterman.com Wed Aug 22 21:11: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 996C111E808D for ; Wed, 22 Aug 2012 21:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqMsbPzGWBxl for ; Wed, 22 Aug 2012 21:11:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA911E808A for ; Wed, 22 Aug 2012 21:11:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6D68820E410A; Thu, 23 Aug 2012 00:11:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345695075; bh=Ia14ozpdUJH09acseVVf075Ud9IHeKYA3T3p1ujm0yE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P+AXKnekslFlvlqtaUVcgYDqkw5X47aHcyxruI7GJb9/9ZaySJ+/2ipOSDA0KqJoY 54jda4FTynhH1aUg0gGF4ncA54kVhYdMARpNERXenXrQ5qHKLMhS6qPOsEtAR8zven Xqk5QJVpkBLMyvtcCVwEdvpISD2k8ud6cpPvYc6U= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3F0E820E4086; Thu, 23 Aug 2012 00:11:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:11:14 -0400 Message-ID: <3506513.hK06SY5Wpb@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503584DA.8070403@gathman.org> References: <4F912ADF.1070201@tana.it> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:11:16 -0000 On Wednesday, August 22, 2012 09:18:18 PM Stuart Gathman wrote: > On 08/22/2012 03:16 PM, S Moonesamy wrote: > > Issue #12 has been open for some time. Please review the message at > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html and > > Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue. > > Using <> to forward emails is a bad idea. Empty mail from is reserved > for error/status returns. In fact, many MTAs use a VERP like scheme to > reject <> for emails they did not send. > > -1 for using <> as a solution to the mis-configured user of forwarding > services problem > > > BTW, section 9.2.2 part 2 does not mention one effective scheme: the > forwarder simply rejects the email with 552 status (redirect IIRC) and > the target email. And for that matter, if the target email simply > rejects an email that fails SPF due to a forwarder, the sender has the > target email in the bounce. Using that info is not as easy to automate > as with 552, but a somewhat savy end-user could do so manually. Good point. I had forgotten about that one. Added. Scott K From spf2@kitterman.com Wed Aug 22 21:17: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 45E7811E808D for ; Wed, 22 Aug 2012 21:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnqS88YSSOhM for ; Wed, 22 Aug 2012 21:17:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 32FBE11E809B for ; Wed, 22 Aug 2012 21:17:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 81EE320E410A; Thu, 23 Aug 2012 00:17:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345695435; bh=tG4cZUJWX69Gu6DGAO85LRaz/X5sw44gMCA+fZkrDWA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oqKp/+aQCG5xP++gfFmc9ucJIxpM7f596SvTIAh2IqHXzAgoMCjXd1DtbyjG+WMGI 7A0crFMC/ahMtO+/1aOAEOps6lTttozSWup69Hxc8PnV8iLtUJLX/vd5+a0tAUXQhF k2cJ25VVQU5ht9LXhwi0xgYoS8zWVOtMTEAlBoC0= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 512FB20E4086; Thu, 23 Aug 2012 00:17:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:17:13 -0400 Message-ID: <8573407.21b1GNdW29@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120817034603.20684.qmail@joyce.lan> <3213071.7NdDxgTL5r@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] Examples in drafts (was: 4408bis update) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:17:17 -0000 On Sunday, August 19, 2012 08:01:30 PM Barry Leiba wrote: > > II think it's very odd for the text to say "For example, the example given > > in > > [RFC1034], Section 4.3.3, could be extended with the following:" and then > > not > > extend it, but completely rewrite it. It totally loses the point of > > taking a > > standard example and showing how it changes. So it's potentially > > confusing. > > You could certainly say , "Consider the example in RFC 1034, Section 4.3.3. > Based on that, we can do the following:" > > Trust me: it will be lots easier to use currently acceptable examples, and > this is not an issue that's worth making a big stink and falling on your > sword about. Really, it's not. Done. For added political correctness points I also changed the IP address to one from the designated block for documentation while I was at it. Scott K From spf2@kitterman.com Wed Aug 22 21:23:29 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 E4BDD11E8097 for ; Wed, 22 Aug 2012 21:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4X2Y+0yftH4 for ; Wed, 22 Aug 2012 21:23:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3560711E808A for ; Wed, 22 Aug 2012 21:23:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9E44E20E410A; Thu, 23 Aug 2012 00:23:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345695808; bh=7/d3pb17hcpOHPDjeChjMYTjFR3jcM0RorfTa9RsKTc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GMyHKcPX8QJWgZOhJWNawV0FuFeHmgqP+pUb8H++CbTlG+EY7PRUwOcGKAlQWtko8 4Vb9LzdSMLoggzMFnlfQ+nWr9ZmoVdfGbFqLFz2U/PUEXnrF/TKRQENvtC2d3j0Kl7 8i5hYkBgoiEKg5QJpagcy51HL2Xo6wWWfbP+RAvQ= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6770820E4086; Thu, 23 Aug 2012 00:23:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:23:27 -0400 Message-ID: <19226324.vgg9iN3rkJ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50322723.8010702@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <4948346.vhSgBJIQcB@scott-latitude-e6320> <50322723.8010702@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] Publishing domains, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:23:30 -0000 On Monday, August 20, 2012 02:01:39 PM Alessandro Vesely wrote: > On Sat 18/Aug/2012 19:02:39 +0200 Scott Kitterman wrote: > > On Saturday, August 18, 2012 04:31:25 PM Alessandro Vesely wrote: > >>>> The goal of introducing the term "ADMD" is specifically to avoid using > >>>> the terms interchangeably. > >>> > >>> If I used the wrong one in some place, please cite specifics, so I > >>> can look at it and fix it. > >> > >> There are lots of them. Most occurrences of "domain" in sections 2.* > >> and 3 actually mean ADMD, especially "domain owner" or "domain > >> holder". In Section 3.5 the term "zone file" might be better. > >> > >> I'd suggest to dedicate an I-D version entirely to such changes, so as > >> to ease reading the diff. > > > > Or: > > > > I uploaded the XML with -04 so if someone wants to send me a patch, that'd > > be lovely. > > I did that for -05. I've left many "domain owner" as that is shorter > than "ADMD that owns/controls the domain". > > I put a couple of very some minor changes, but I resisted relevant > changes. In particular, in: > > 2.3. *Publishing Authorization* > > I would put this: > > ADMDs MAY publish SPF records that explicitly authorize no hosts for > domain names that are neither used in the domain part of email > addresses nor expected to originate mail. > > That "MAY" is currently "can". I'd also move that paragraph from the > third to the second place, so as to have normative stuff at the > beginning of the section. > > Please note that the "MUST" in the first paragraph bears a slightly > different meaning after the change. An ADMD could get away with some > compliant domains only, according to the previous wording. Now, it > has to define a record for each relevant host. Should we relax that > "MUST" to a "SHOULD"? Or maybe keep it at "MUST" for mfrom and relax > to "SHOULD" for helo identities only? Patch applied. For 2.3, I changed "domain MUST publish" to "domain MUST have" so that it makes it about the DNS domain and not an ADMD, which is consisten with what we have now. Thanks, Scott K From spf2@kitterman.com Wed Aug 22 21:26: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 9578C11E809B for ; Wed, 22 Aug 2012 21:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GQ92RjCvjSL for ; Wed, 22 Aug 2012 21:26:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8A11E808A for ; Wed, 22 Aug 2012 21:26:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 417E420E410A; Thu, 23 Aug 2012 00:26:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345696012; bh=Nae2PDgddQiIcU4pXpG01wDenNpN44g7W/KB5IFG9jM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bMFp+Uu9eIgfvS5xFhnGiAF5arxf4LdesfYJ2qDqh93PNrvTXg9c0czQAbEFctnXm kYCwfeh9SwUNhNne0JaYsMLuAa7/+hlV6DZV46FED9Eup+y6j5IeFnoG2RcgyWhSjR oDrOPSogyQ/hBBHNanugbdy89DGlF56qJ9v6j4yA= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 113DD20E4086; Thu, 23 Aug 2012 00:26:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:26:50 -0400 Message-ID: <3341295.LpOckjlBGy@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5035AAFF.1070402@isdg.net> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <2267574.6GQXnqNoLg@scott-latitude-e6320> <5035AAFF.1070402@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:26:53 -0000 On Thursday, August 23, 2012 12:01:03 AM Hector Santos wrote: > Maybe I am not reading you right. Are you agreeing that the SPF trace > lines is more for the backend (MDA) then for the MUAs? > > Separation is the key here for the security note and that will > basically remove the MUA factor or rather move the ergonomics to the > MUA (spam boxes, showing notifiers, etc). Overall, we can never depend > on MUAs and there is different types. > > Consider that a MDA that does not have "Spam Folders" for users, they > are at a higher risk when using ACCEPT+MARK mode that is 100% resolved > by using as REJECT mode. > > Separation for Accept/Mark - that is all the point is about the > security note of my posted issue. Its not a mandate for design, its a > security note implementators need to be aware off. ... If the goal is something user visible, it has to carry to the MDA and through to the MUA. I don't think we can or should mandate MUA design to include SPF specific indicators. I think my proposed note captures the issue that needs to be considered by MDA/MUA developers and administrators. Do you disagree? Scott K From spf2@kitterman.com Wed Aug 22 21:34: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 93D5D21F84CD for ; Wed, 22 Aug 2012 21:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbsl5IdydRnd for ; Wed, 22 Aug 2012 21:34:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 21CCF21F84C2 for ; Wed, 22 Aug 2012 21:34:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 65A0C20E410A; Thu, 23 Aug 2012 00:34:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345696488; bh=IVM2CoYbWv3F6jjPkNYrr4GnFGrE8qKdwK9TNzXSTlk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hRZwD9VtIJb5LI+Ae6MBwAbDmEX00y4b3OK5oGtSITObMW8kMI3cDNhtP7TZdeKho FNT2CDtozefukeB0pwjBELbOlu5VbYUMNEZ1p/an5WecDGVhhEFZA1STAQgWY70cPw md48y1eXun1I88DAJZjHyZTz/xFWzP3CLsQRVRfU= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2FABC20E4086; Thu, 23 Aug 2012 00:34:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:34:46 -0400 Message-ID: <1476027.UdxMWrdmeL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822153007.0a670d18@resistor.net> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <2503352.tTzaICpeS8@scott-latitude-e6320> <6.2.5.6.2.20120822153007.0a670d18@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] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 04:34:50 -0000 On Wednesday, August 22, 2012 03:48:24 PM S Moonesamy wrote: > Hi Scott, > > At 15:22 22-08-2012, Scott Kitterman wrote: > >It was the addition of this to Section 4.3: > > Properly formed domains are fully qualified email domains as > > described in [RFC5321] Section 2.3.5. Internationalized > > > > domain names > > > > MUST be encoded as A-labels, as described in Section 2.3 of > > [RFC5890]. > > I'll close the ticket if I do not hear any objections to the above. > > >There was some discussion about changes relative to local-part macros, but > >in the end I believe we converged on not making any change for that (and > >this is what the current draft reflects) because there wasn't a way to be > >more broadly > >compatible with IDN local-parts and maintain backward compatibility. > > Thanks. > > There is a "MUST" in the text that was added. It may affect existing > RFC 4408 implementations. I'll leave this to the Responsible AD to decide. This is a good point. Upon reflection, perhaps it would be better put like this: Properly formed domains are fully qualified email domains as described in [RFC5321] Section 2.3.5. For implementations that support Internationalized domain names, such domains MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]. I think that might be more appropriate. I don't think 4408bis is the right document to be mandating IDN support in MTAs. Scott K From internet-drafts@ietf.org Wed Aug 22 21:40: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 1639111E809B; Wed, 22 Aug 2012 21:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9xNv5xljPkp; Wed, 22 Aug 2012 21:40:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874A721F84D4; Wed, 22 Aug 2012 21:40:25 -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.34 Message-ID: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2012 21:40:25 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 23 Aug 2012 04:40:56 -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-06.txt Pages : 66 Date : 2012-08-22 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Wed Aug 22 21:44: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 5C92011E80C5 for ; Wed, 22 Aug 2012 21:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFw58XZaPmgE for ; Wed, 22 Aug 2012 21:44:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6E11E80D3 for ; Wed, 22 Aug 2012 21:44:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B6AAC20E410A; Thu, 23 Aug 2012 00:44:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345697092; bh=YQ42C/MNyKqX454K32M6M+/ECBdTcCZ+Al0bUCZPx0g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FqRgc/rlv+sEmI2FkWhkrtZDwZqIptEdN3ALuGgI12vxbJLClEJzu3OKAbLgOljbn TPYBrFtABQSb7E/8fLD6sr6sW4jX6zk28xOkoePWaIFC+Ls+IhdwH4w/lurVJKnYbd 9qcAhi8VIXG+/C2OOpupSlr06rnPSj652IQQibKo= Received: from scott-latitude-e6320.localnet (c-98-192-254-221.hsd1.de.comcast.net [98.192.254.221]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7447820E4086; Thu, 23 Aug 2012 00:44:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 Aug 2012 00:44:50 -0400 Message-ID: <16215316.XYRRSdKXvA@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> References: <20120823044025.11984.71550.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-06.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, 23 Aug 2012 04:44:56 -0000 On Wednesday, August 22, 2012 09:40:25 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-06.txt > Pages : 66 > Date : 2012-08-22 > > Abstract: > Email on the Internet can be forged in a number of ways. In > particular, existing protocols place no restriction on what a sending > host can use as the "MAIL FROM" of a message or the domain given on > the SMTP HELO/EHLO commands. This document describes version 1 of > the Sender Policy Framework (SPF) protocol, whereby an ADMD can > explicitly authorize the hosts that are allowed to use its domain > names, and a receiving host can check such authorization. > > This document obsoletes RFC4408. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ There is nothing radical in this update, but it seemed like there was enough change to make it better to publish the latest. This includes many changes discussed on the list, but not yet the new security consideration that Hector proposed (Issue #33), since we don't seem to have converged on anything yet. I believe that I've addressed all the other recent suggestions for changes. If I've missed something, please let me know. Scott K From hsantos@isdg.net Wed Aug 22 22:18:37 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 DE95511E80A4 for ; Wed, 22 Aug 2012 22:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16G+c0mZrpCb for ; Wed, 22 Aug 2012 22:18:37 -0700 (PDT) Received: from mail.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB63211E80A3 for ; Wed, 22 Aug 2012 22:18:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1355; t=1345699111; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=RPJYUCKXGt2Tncy97UrLfJ17eFY=; b=o2Ta+NvR/Wcl4DgYCDas 64CtkEMo1OldQeS5VsKyjPPiEjBmGFz9fE0UFXFX7L8KAwAL/gF7RNL/zz4KI0bt otQuXZjaJt1bomb9B59ZV554HL1EubkKIWIoVSYDyzYhjGc9nV8GI/Is0DG/0III FNzlPZbOUEDkLLKSxf7FyfE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 01:18:31 -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 1720908471.1305.3012; Thu, 23 Aug 2012 01:18:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1355; t=1345698922; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zlMY0K7 E3v8r10FXgm0iuD5bXLjJiwfD3enoAEHByPo=; b=Ll6IDu2NZ6jVJ4XkJgTyO6v q8MhDh6YHcS5XuVfwfPJUvhmmye5dQBwSFIE2LUrRHZhpOmModCWBpFXnwVoO+hS 40U63hLCfDfs0dA5UA0eXDKXsDvZaZYV+0cZXGNxHoASspC5irUWTzumO7WrCR7c mobccJB5V2N5TtnTryPE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 01:15:22 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2319720583.7.6544; Thu, 23 Aug 2012 01:15:21 -0400 Message-ID: <5035BD24.7020304@isdg.net> Date: Thu, 23 Aug 2012 01:18:28 -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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 05:18:38 -0000 Just notice that Auth-Res was added (which I agree with) but not as an exclusive replacement for Received-SPF at this stage. Wouldn't that make this a SPF protocol change? Specifically, in 2.5.4, it has an OR If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 7) to communicate this result to downstream message processors. For 4408BIS implementators who choose Auth-Res, would this not open an possible interop or compatibility issue with any 3rd party mail filtering applet still focused on Received-SPF? I don't have any control over 3rd party filters. If were to do this tomorrow, we would to add Receiver-SPF AND Authentication-Result, a new one or append to the existing Authentication-Result that may come from some other mail authentication protocol check. Anyway, I think this and related sections should convey this as migration feature because I don't think it will cater to all existing systems that already have bots (theirs or 3rd party) that rely on Receiver-SPF. I suspect most will add both since they may not be able to technically afford breaking existing operations with just Auth-Res version for SPF. I'm not sure if this also violates "Don't Break SPF" concerns. -- HLS From sm@elandsys.com Wed Aug 22 22:28: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 19BB421F84C5 for ; Wed, 22 Aug 2012 22:28:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFOphIj-rKFi for ; Wed, 22 Aug 2012 22:28: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 6232221F8462 for ; Wed, 22 Aug 2012 22:28:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7N5RmV6023103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 22:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345699680; bh=XTJZu+//Kd6FR43F5rWn84aVJZWNFOZzj8Sf60osAQs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=U5/GLggmPLbvYHzhhZ8Ui0keLocNViNqQJilrXhyCnj9lCn6Fi3dhuTd+Wi7Mc4nh JUYBXnTR4Xy3VfCt9Rmta2jNUslrbq6po1eigSGgSuOnAaYqIFzIbeTFaUBx7RfEKS F1yzBLSzttywXlHVN0gSnDGoONhoLhBcLnRBiuBU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345699680; i=@elandsys.com; bh=XTJZu+//Kd6FR43F5rWn84aVJZWNFOZzj8Sf60osAQs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3waF9+jsaFdWm8CoRep26dpHI8Q2uYOLIx7eBU5ESoqX32PEVQgGuvNTfqLU0UlyY 2kT6/QBvu31ZZRWd6GDb+fLT+VJi9SBdkCiCE/PcxXjuInMBY6sITHkcV1wWTDhY7Y K4vSYGbA45QmCzWJZhtuujCjhEUZeh/CZxOr4Kd4= Message-Id: <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Aug 2012 22:23:33 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1476027.UdxMWrdmeL@scott-latitude-e6320> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <2503352.tTzaICpeS8@scott-latitude-e6320> <6.2.5.6.2.20120822153007.0a670d18@resistor.net> <1476027.UdxMWrdmeL@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 05:28:07 -0000 Hi Scott, At 21:34 22-08-2012, Scott Kitterman wrote: >This is a good point. Upon reflection, perhaps it would be better put like >this: > > Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5. For implementations that > support Internationalized domain names, such domains MUST be > encoded as A-labels, as described in Section 2.3 of [RFC5890]. > >I think that might be more appropriate. I don't think 4408bis is the right >document to be mandating IDN support in MTAs. I have not discussed about this with Andrew. There are different ways to tackle the issue. In my humble opinion the text suggested above may be flagged during external review or it may generate a DISCUSS. I suggest leaving the text as it is for now unless the working group agrees on the text suggested above or any other text. Regards, S. Moonesamy From prvs=575c13fbe=fmartin@linkedin.com Wed Aug 22 22:52: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 C005421F8474 for ; Wed, 22 Aug 2012 22:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93acC9qP+C2B for ; Wed, 22 Aug 2012 22:52:40 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id E543E21F8445 for ; Wed, 22 Aug 2012 22:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1345701160; x=1377237160; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+kGYdcokd0CTZz7svWplnlM/Ys0zTdlLk91oSl86ScM=; b=MxbwIcwxU7ph+Zgyd05ulcFoxWmPFe9xXV6qp1mto9EfjO02DywRf4y8 IeAY77Kp0a7gPxfYXWCnf5iY3kopzeT5unPbaaf7r5qquySu7XmTbQfko M1443dZjK0ebFUfWe6q+UDpXJU8B6selya7oSCiiDzuo9dQVN9kgc6vQp 4=; X-IronPort-AV: E=Sophos;i="4.80,298,1344236400"; d="scan'208";a="23866481" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 Aug 2012 22:52:13 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Wed, 22 Aug 2012 22:52:12 -0700 From: Franck Martin To: Stuart Gathman , "spfbis@ietf.org" Thread-Topic: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities Thread-Index: AQHNgPNwr6dyR+z9KEuUy8BTdnnphQ== Date: Thu, 23 Aug 2012 05:52:12 +0000 Message-ID: In-Reply-To: <503584DA.8070403@gathman.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 05:52:41 -0000 +1 I don't like forwarding looking like bounces or worst bounces looking like forwarding. It really mess up figuring out what email you just received. If I don't know what it is, it is likely ending up not being processed correctly, creating issues for the sender and/or receiver. On 8/22/12 6:18 PM, "Stuart Gathman" wrote: >On 08/22/2012 03:16 PM, S Moonesamy wrote: >> >> Issue #12 has been open for some time. Please review the message at >> http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html and >> Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue. >Using <> to forward emails is a bad idea. Empty mail from is reserved >for error/status returns. In fact, many MTAs use a VERP like scheme to >reject <> for emails they did not send. > >-1 for using <> as a solution to the mis-configured user of forwarding >services problem > > >BTW, section 9.2.2 part 2 does not mention one effective scheme: the >forwarder simply rejects the email with 552 status (redirect IIRC) and >the target email. And for that matter, if the target email simply >rejects an email that fails SPF due to a forwarder, the sender has the >target email in the bounce. Using that info is not as easy to automate >as with 552, but a somewhat savy end-user could do so manually. >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Wed Aug 22 23:37:02 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 E43A411E80A5 for ; Wed, 22 Aug 2012 23:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.148 X-Spam-Level: X-Spam-Status: No, score=-111.148 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd0VKHhg2C89 for ; Wed, 22 Aug 2012 23:36: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 9481311E80A2 for ; Wed, 22 Aug 2012 23:36:57 -0700 (PDT) Received: (qmail 20699 invoked from network); 23 Aug 2012 06:36:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Aug 2012 06:36:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5035cf85.xn--3zv.k1208; i=johnl@user.iecc.com; bh=hABijRuDNYaZoGy+OAuY5Nl1Sl4cCq/GRzawsbS60kM=; b=rPnUucLRuE8OlbGZjbw/jTIqVgfh7zS6i2prOXSqn1Ohrq3rY1UcVDna3j/CvzmrtifiUrKgL5GKHiXwOuvZDy2Q8QSEpmn5iv+iw439hv9CyAkSLG72mNGb8eqU/QR/nYmEW7bGGBt6+ypn771Q9eRHsBsyXuoiuQ9FsMQcG14= 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=5035cf85.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=hABijRuDNYaZoGy+OAuY5Nl1Sl4cCq/GRzawsbS60kM=; b=mPDao1nt1/jo0yGcxTHi4q3JQmuE0Sc8mUvQqx5azeO49Bf5/hZIT5xly0nevKsBBPL/hQ0zjnsl9n39xdyJbTJoLDJRlIDRKZQh4M9MVXD2VWnoaYnlGCO0tfeFrOBxHE6IRgmaGD7SjGZcqnhlhoXPtLn1qfZmIXg+q+DJQ1A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Aug 2012 06:36:30 -0000 Message-ID: <20120823063630.94818.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] #13: RFC 4408: Best-Guess SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:37:03 -0000 >I understand, and I'm not trying to make any claim that it's even a >good idea. What I'm wondering about is what a reader looking for >guidance will do with the fact that we don't talk about it at all, but >there's non-trivial usage of it today. I'd rather put it in a separate non-standards track document. R's, John From vesely@tana.it Thu Aug 23 00:51: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 6A1C221F84A1 for ; Thu, 23 Aug 2012 00:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq-UKehA6i2z for ; Thu, 23 Aug 2012 00:51:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 38A7A21F854C for ; Thu, 23 Aug 2012 00:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345708271; bh=u9nIIkXTjLPs9cO54jGBjo5ZX6rAihOiMily3EaiiGA=; l=1221; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B9W+GxtnmxgfzRUMaSKJBn0S1UBKP06vtTwRt1ORGlNXeGcTOAoB8tE6Drd6iY3VQ eF2NsdtkLWnGjxlFVW9kzQaMjFgdEZtCNMQr2PYtF5ohrayvqKgkjBV4PUHrXjH35h W1aWDQc/uz2Qjpy2InkItfWL9p8QyMbpgq1cwC8I= Received: from [109.113.54.135] ([109.113.54.135]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 09:51:09 +0200 id 00000000005DC033.000000005035E0EE.000074ED Message-ID: <5035E0E3.60700@tana.it> Date: Thu, 23 Aug 2012 09:50:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <502FA747.4000309@tana.it> <2609549.aGaQhnMI7j@scott-latitude-e6320> <5032699F.1070104@tana.it> <50351E82.10502@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 07:51:16 -0000 On Wed 22/Aug/2012 20:10:42 +0200 Murray S. Kucherawy wrote: > On Wed, Aug 22, 2012 at 11:01 AM, Alessandro Vesely wrote: >> On Mon 20/Aug/2012 19:44:17 +0200 Murray S. Kucherawy wrote: >>> On Mon, Aug 20, 2012 at 9:45 AM, Alessandro Vesely wrote: >>>> Technically, "during the SMTP transaction" means that the transaction >>>> has to be started, which is after the last HELO/EHLO command. Can we >>>> say "before accepting the SMTP transaction" instead? >>> >>> Not quite. Sessions begin with HELO/EHLO; transactions begin with MAIL. >> >> So what? If rejection comes before a transaction starts, then there >> is no transaction. Rejection was still before the transaction end. >> Like turning off the alarm before it rings... no? > > I'm challenging your definition of "transaction" in the context of > SMTP, not with respect to SPF. We are both following the same definition, the one given by RFC 5321. I'm not sure I'm following you... > In both cases there's no completed transaction (which is all SPF > cares about), but you can't say "during a transaction" if the only > thing that's happened so far is HELO. That's why I proposed to s/during/before/ From vesely@tana.it Thu Aug 23 01:51: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 2971D21F85AF for ; Thu, 23 Aug 2012 01:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wA5SHL4fc6k for ; Thu, 23 Aug 2012 01:51:57 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CA99D21F85B1 for ; Thu, 23 Aug 2012 01:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345711915; bh=tz4IowXFh05gKzXWUpJF+N47Rm+IdqNUPuZDsruxQV8=; l=3643; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TaAilDPw2h+0Ify6C2FeZRpcRaIKGvYH3tSUSaHj3bSGrjJdyuwd6KK/NMsFu4SDN 8LuOtP3aQNXJBqaJOL4SDUn8pNi+/8YW0iIbzDd27fKEb8PwrzEtiJFHJZ0/mO0n3P kMlTNmr80ncp1UeEqWfeYoiusJsA4gRSxWQhWVbg= Received: from [109.113.54.135] ([109.113.54.135]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 10:51:54 +0200 id 00000000005DC039.000000005035EF2A.0000032A Message-ID: <5035EF1F.1040009@tana.it> Date: Thu, 23 Aug 2012 10:51:43 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> In-Reply-To: <4042906.FYNB9DcbUd@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:51:59 -0000 On Wed 22/Aug/2012 00:39:42 +0200 Scott Kitterman wrote: > On Tuesday, August 21, 2012 11:08:46 AM Murray S. Kucherawy wrote: >> In this particular case, the question is around interoperability >> between the SMTP client and server. The question we need to ask is: >> If someone doesn't do this, what's the impact? >> >> I think we can be certain that using 5yz codes is the right thing to >> do. Is there any harm in picking the wrong 5yz code? What do we need >> to say that RFC5321 doesn't, that's specific to SPF? >> >> Same question for enhanced status codes: 5.y.z is obviously correct, >> but beyond that, why is there a need to be more precise? The difference between 5yz an 5.y.z is that while SMTP mandates a single specific code, RFC 3463 allows a choice. No existing codes unambiguously identify SPF. We seem to agree on that being a feature, not a defect. Hence, the above question makes more sense in this case: What sort of confusion can be generated if one chooses a different enhanced status code? >> Perhaps more generally: What problem are we trying to solve? Is it >> simply a question of trying to avoid sending implementers off to read >> those other documents? > > Particularly the problem I'm trying to solve is having change for unimportant > reasons. While some have argued the codes don't need to be in 4408bis, I > don't think anyone has suggested it's a problem. Given that these codes are > (with one exception that was a mistake) in 4408, I think there needs to some > positive benefit associated with removing them. Being error-prone is a problem by itself. In addition, making the wording more clear-cut can provoke revision of existing policies and configuration of existing software. Finally, it may ease future development (see below.) > I do think there's value in uniformity on this. Not so much for hard core > interoperability between computers but to aid in human understanding of what > the various systems are doing. If different implementations use different > codes, then there is some potential for confusion. See question above. > Finally, I think it's better in this case to simply give the preferred answer > in 4408bis than to send implementers off to read two references, particularly > since one of which does not give a clear answer about how to proceed. The example provides a useful shortcut to those who don't read the references, without confusing those who do. > If we're going to remove things, I think there needs to be more to it than "I > feel like that's not the best way to have done it." Sure. It identifies "insertion points" for further development. Some further development is needed. SPF originally emphasized the negative results, assuming that senders would have changed their forwarding methods. Some still uphold and/or deploy such silver bullet view. However, it is not fully compatible with SMTP, and RFC 5598, Section 5.1 documents that changing the MailFrom implies a number of problems that a mail admin may not be willing to tackle. Current SPF deployments emphasize positive results. The protocol evolved, albeit not on the paper. However, domain reputation is not an exact science yet, especially for smaller ADMDs having a somewhat limited view of the global scenario. For that reason, and because they have a better knowledge of their users, small ADMDs tend to deploy the silver-bullet aspect of SPF more than others. Hence, we need to recover that aspect, and adapt it to the current trend. To precisely locate where on the paper that lies is a prerequisite for such work. From vesely@tana.it Thu Aug 23 02:27: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 3CC3C21F85C6 for ; Thu, 23 Aug 2012 02:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE6H8rz6sl5h for ; Thu, 23 Aug 2012 02:27:05 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 131BC21F858F for ; Thu, 23 Aug 2012 02:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345714023; bh=OPyNPRRVQZwKPBvdsZKeGNdrGDAbDPKz77K1SAeRNAA=; l=1811; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=KqcnUnMNBJcd2eF2hgXgDPj+gV2r8SRCCN1/3nD7dTGeo+jRX5FKI6X5b3ZPrB2ev 7t9LCMmRej+isEz1Xe9DxNebjc8h01fXKoNqs3pwq5RVPFWFwlvtn0PdflwPTfr7ek 0BwGwa5e+6XqSOr3wQYEJV1ois3iFrOVovc035JQ= Received: from [109.113.54.135] ([109.113.54.135]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 11:27:02 +0200 id 00000000005DC039.000000005035F766.00000BEC Message-ID: <5035F75F.2070406@tana.it> Date: Thu, 23 Aug 2012 11:26:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> In-Reply-To: <503584DA.8070403@gathman.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 09:27:06 -0000 On Thu 23/Aug/2012 03:18:18 +0200 Stuart Gathman wrote: > On 08/22/2012 03:16 PM, S Moonesamy wrote: >> >> Issue #12 has been open for some time. Please review the message at >> http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html >> and Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on >> this issue. > Using <> to forward emails is a bad idea. Empty mail from is reserved > for error/status returns. It is DSNs which are bound to have an empty mfrom, not the other way around. > In fact, many MTAs use a VERP like scheme to reject <> for emails > they did not send. They should be listed, according to http://www.rfc-ignorant.org/policy-dsn.php > -1 for using <> as a solution to the mis-configured user of forwarding > services problem Hm... it's not much the user who is responsible of the misconfiguration, as the forwarder itself. The point you make below is correct, but still far from providing an effective solution for forwarders who don't want to rewrite the MailFrom (see last paragraph of http://tools.ietf.org/html/rfc5598#section-5.1 ). > BTW, section 9.2.2 part 2 does not mention one effective scheme: the > forwarder simply rejects the email with 552 status (redirect IIRC) and > the target email. And for that matter, if the target email simply > rejects an email that fails SPF due to a forwarder, the sender has the > target email in the bounce. Using that info is not as easy to > automate as with 552, but a somewhat savy end-user could do so manually. For a similar point, in part 1, bullet #1 we could exemplify "v=spf1 mx ?exists:%{ir}.list.dnswl.org -all" instead of or in addition to the spamhaus example. IME that's quite effective as it solved all the practical cases I knew of, and still allows -all. From vesely@tana.it Thu Aug 23 02: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 0581921F85F3 for ; Thu, 23 Aug 2012 02:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn1Lt-yLXJwJ for ; Thu, 23 Aug 2012 02:56:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 39FBF21F85C6 for ; Thu, 23 Aug 2012 02:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345715771; bh=QECz7VhMI8z9pbE6e+YrZnSDyEz9dedZHsgbnBf7ikU=; l=1194; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=l4vPdrXe1Ue0YfpAwFf2NB2n5l2xAwSjuXeAaFc+2tYxeF2rmOW+3Q+ZX1xaXneHh J5tvxZgGhIPTWLSUEOShMjACjJubZBeqm6t9f6Fm3l32/68vos+Z0PbpGJsHebltiv AjFqeVsqFlLrjPE+XUBJ2Q7TUIemdpgQgGXRrZzc= Received: from [109.113.54.135] ([109.113.54.135]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 11:56:09 +0200 id 00000000005DC039.000000005035FE3A.000012AD Message-ID: <5035FE33.1060809@tana.it> Date: Thu, 23 Aug 2012 11:56:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <4948346.vhSgBJIQcB@scott-latitude-e6320> <50322723.8010702@tana.it> <19226324.vgg9iN3rkJ@scott-latitude-e6320> In-Reply-To: <19226324.vgg9iN3rkJ@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Publishing domains, was 4408bis update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 09:56:14 -0000 On Thu 23/Aug/2012 06:23:27 +0200 Scott Kitterman wrote: > On Monday, August 20, 2012 02:01:39 PM Alessandro Vesely wrote: >> On Sat 18/Aug/2012 19:02:39 +0200 Scott Kitterman wrote: >>> On Saturday, August 18, 2012 04:31:25 PM Alessandro Vesely wrote: >> >> Please note that the "MUST" in the first paragraph bears a slightly >> different meaning after the change. An ADMD could get away with some >> compliant domains only, according to the previous wording. Now, it >> has to define a record for each relevant host. Should we relax that >> "MUST" to a "SHOULD"? Or maybe keep it at "MUST" for mfrom and relax >> to "SHOULD" for helo identities only? > > Patch applied. For 2.3, I changed "domain MUST publish" to "domain MUST have" > so that it makes it about the DNS domain and not an ADMD, which is consistent > with what we have now. Thank you. However, that way there is still a "domain" vs "ADMD" ambiguity, especially because of the plural ("records"). Are there more opinions on this? Let me recall that we RECOMMEND to test the helo identity, but formalize about neither publishing it nor interpreting its result if different from that of the other identity. From sm@elandsys.com Thu Aug 23 03:02: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 CC11521F85F7 for ; Thu, 23 Aug 2012 03:02:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56+SMAIXlZC9 for ; Thu, 23 Aug 2012 03:02: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 4972E21F8618 for ; Thu, 23 Aug 2012 03:02:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NA1whc017049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2012 03:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345716129; bh=YAN96xALjytjkyRiDTxbXaccNKr41j2SkPqvngjjLdo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hvTnm4zgFTfHfSXwXQ/P2bdBI+lVz2x2G6JH7wePDVptkpnVNiTailnjO4UVXhVlM YUogTp+8sTLxmzCYiTN7IA0+0o3d5L0hwAxO9NjVcQXo1PPGrzifYbqmfmpTu3hUNM n+tGu4eB6je1qgUfXk1Hhw52g8WdhECv76Kg2oLs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345716129; i=@elandsys.com; bh=YAN96xALjytjkyRiDTxbXaccNKr41j2SkPqvngjjLdo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rUBfeTz2lz4JndHcqUTFa3CJ6KHoOeKnFxavmSkgKbBdFabUKZ8ktfCj23DJqB7hq L5QRD9EKtxje+FJ2oqOlLIdWVYya+7nc4DG1X2NCe1/YluwP0+hOdXHET1TLNMOvkW PKBKVFU2DIc6P9VWjvk7rXvw1GKxR5KdMuJJN8x0= Message-Id: <6.2.5.6.2.20120823025024.0a2f22e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 03:00:45 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <5035F75F.2070406@tana.it> References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 10:02:11 -0000 Hi Alessandro, At 02:26 23-08-2012, Alessandro Vesely wrote: >They should be listed, according to [URL removed] I don't think it would be a good idea to have a discussion about the above on the SPFBIS mailing list. Regards, S. Moonesamy From superuser@gmail.com Thu Aug 23 06:46: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 7967821F8594 for ; Thu, 23 Aug 2012 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajOFBxZhwIjC for ; Thu, 23 Aug 2012 06:46:55 -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 ED40421F85F4 for ; Thu, 23 Aug 2012 06:46:54 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1862190obb.31 for ; Thu, 23 Aug 2012 06:46:54 -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=f8Jdl1IjjvcEraVPnSc9PBL4FKT2bYEgxQQd6wJiR+o=; b=x5Gm7xlYY/Nzm2n/pGA6576I2dOAHcypeOKfZld/twJN3Aj4CeZ8N4AQOqtjodb1cL +Gv3Y8FqwunUIjaSmhGXj8w4Pp/yHtxo8nWTHXqMK8HMNuijHYUvATJjTwhCYyUSGgHC 1HcTTfxAGmMijU3C7jhXpX/dwNSf+BUBfNs3AIK3NJaj0gHCAoolt8mRPwpQwK+QsRXx /wwFWorTD9gyYimuTeyP3tmvIA/vEjX1I4Aa+qTeQqyO0eYCPycAPbSw5lqkT3gDRnRq 1yd9zwte+IIAmwYVj0kr5n6emyw1MKog5orifWheHpHG7IqVvWBB0LJ40x7GypJb2xJF B6Fw== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr1106194oeg.37.1345729614509; Thu, 23 Aug 2012 06:46:54 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 23 Aug 2012 06:46:54 -0700 (PDT) In-Reply-To: <2050339.9cOfrxQYRQ@scott-latitude-e6320> References: <50350126.2010506@isdg.net> <22809811.9sJZkmpsv2@scott-latitude-e6320> <2050339.9cOfrxQYRQ@scott-latitude-e6320> Date: Thu, 23 Aug 2012 06:46:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 13:46:55 -0000 On Wed, Aug 22, 2012 at 8:50 PM, Scott Kitterman wrote: >> I guess I hadn't read 9.3.2 in a while. The first sentence of this >> paragraph seems to be mangled. > > It seems OK to me. > > SPF fail results can also be used as one input into a larger set of > evaluations which might, based on the overall evaluation result in the > email being marked negatively in some way (this might be via delivery > to a special spam folder, modifying subject lines, or other locally > determined means). > > What did you have in mind? Reading it again, I think can also is probably > better put as can alternately, but I don't think that qualifies as mangled. The "might" near the front seems to be dangling. Might what? Maybe this is what's meant: SPF fail results can also be used as one input into a larger set of evaluations which might, based on the overall evaluation result of the message, be marked negatively in some way (...). If so, "might ... being" is the mangling I'm detecting, coupled with the need for commas. Also, "the overall evaluation result" might be better expressed as "a combination of other evaluation techniques". -MSK From superuser@gmail.com Thu Aug 23 06:54: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 41F9321F85A8 for ; Thu, 23 Aug 2012 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1pA0vhHaQ6u for ; Thu, 23 Aug 2012 06:54: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 2AD4E21F858A for ; Thu, 23 Aug 2012 06:54:08 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1884242obb.31 for ; Thu, 23 Aug 2012 06:54: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=HlziLo4h7odNE22YGHY1tAPU4ooipbhu64VjHyWNsNM=; b=sDLTJUlMfAPYxNNUhdsJu9xqa0Tg6jZfVwkt8OiNcT9DAWKa6H2HGtn388jTmmxzUH NthSvaXFmL2LwUUl5LHexgJyQeWifZ2xTILIdB7jYyLkYuQIwBjz+k1eBdBmdogHjS0+ JA0t6ReLJcsgCO0j94ljD8yPifVl8kDGR9k6T0qVdyTwebLEEY0bqNfm8AH1y0xWh48i 7Y4GGSrJma1nKVkTmLiB/cIFaU6fpTJPA802hsWfyZJ5sDHCJi4rEBrZTRLFzsy4FyUC oQvw+RKeVBh55x1HBaXa7PD+AOswW0HmMs3KwODWDszdHSv7RtPtbwmBv+02PXoO9JLu qIeg== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr1124379oeg.37.1345730047625; Thu, 23 Aug 2012 06:54:07 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 23 Aug 2012 06:54:07 -0700 (PDT) In-Reply-To: <5035EF1F.1040009@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> Date: Thu, 23 Aug 2012 06:54:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 13:54:09 -0000 On Thu, Aug 23, 2012 at 1:51 AM, Alessandro Vesely wrote: > The difference between 5yz an 5.y.z is that while SMTP mandates a > single specific code, RFC 3463 allows a choice. No existing codes > unambiguously identify SPF. Why is that something that's become a necessity? > We seem to agree on that being a feature, > not a defect. Hence, the above question makes more sense in this > case: What sort of confusion can be generated if one chooses a > different enhanced status code? This feels like change for the sake of change. How about: What sort of benefit is generated by adding this additional detail? As I've said, I'm fine with examples using specific SMTP and enhanced status codes, but normative language there steps on the documents that define them, and I'd rather we omit it. It doesn't seem necessary. -MSK From dhc@dcrocker.net Thu Aug 23 07:04: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 8914E21F8522 for ; Thu, 23 Aug 2012 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHrPzMhowpqy for ; Thu, 23 Aug 2012 07:04:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A93D021F8508 for ; Thu, 23 Aug 2012 07:04:47 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7NE4jtt019894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Aug 2012 07:04:46 -0700 Message-ID: <50363878.8000909@dcrocker.net> Date: Thu, 23 Aug 2012 07:04:40 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 23 Aug 2012 07:04:46 -0700 (PDT) Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 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: Thu, 23 Aug 2012 14:04:48 -0000 On 8/23/2012 6:54 AM, Murray S. Kucherawy wrote: > This feels like change for the sake of change. How about: What sort > of benefit is generated by adding this additional detail? As asked, that's a theoretical question. Benefits can be appealing as ideas but turn out to satisfy no actual market need. So in addition to asking about the benefit, I'll ask for the basis for believing that the market of SPF users (publishers and/or queriers) have demonstrated a desire or need for this change. > As I've said, I'm fine with examples using specific SMTP and enhanced > status codes, but normative language there steps on the documents that > define them, and I'd rather we omit it. It doesn't seem necessary. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Aug 23 07:35: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 7CB7021F84F3 for ; Thu, 23 Aug 2012 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUtV8ncorjwW for ; Thu, 23 Aug 2012 07:35:38 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8D18921F84F2 for ; Thu, 23 Aug 2012 07:35:38 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BAEC3D0408D; Thu, 23 Aug 2012 09:35:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345732537; bh=bNGtTwnPPLbPwfxMK1hcDP+OJv51Lsd5d8UNlJzqpN4=; h=References:In-Reply-To:Subject:From:Date:To:From; b=oG6bkSjm+GItFEAtL/d7g8RcdVuDf3sjnmUNFzZMTqE2boXqZRqGukFbuSfIubSKm JVGOq68CQgyOAEXOlpdjRNS7t8O/t+Vx6Kd5ekrN/TBo6NaQPTkVto0cXpk49rbwrq LMpgvaS81xBaS+J9yJmeaH7el0m02+eJ74kQHfb4= Received: from [IPV6:2600:1002:b023:b940:69f4:db7b:5750:9439] (unknown [IPv6:2600:1002:b023:b940:69f4:db7b:5750:9439]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 78164D04051; Thu, 23 Aug 2012 09:35:34 -0500 (CDT) References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <2503352.tTzaICpeS8@scott-latitude-e6320> <6.2.5.6.2.20120822153007.0a670d18@resistor.net> <1476027.UdxMWrdmeL@scott-latitude-e6320> <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 23 Aug 2012 10:34:44 -0400 To: spfbis@ietf.org Message-ID: <511d0c8b-b3fa-4ee3-bc55-aacc3098754b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 14:35:53 -0000 S Moonesamy wrote: >Hi Scott, >At 21:34 22-08-2012, Scott Kitterman wrote: >>This is a good point. Upon reflection, perhaps it would be better put >like >>this: >> >> Properly formed domains are fully qualified email domains as >> described in [RFC5321] Section 2.3.5. For implementations >that >> support Internationalized domain names, such domains MUST be >> encoded as A-labels, as described in Section 2.3 of >[RFC5890]. >> >>I think that might be more appropriate. I don't think 4408bis is the >right >>document to be mandating IDN support in MTAs. > >I have not discussed about this with Andrew. There are different >ways to tackle the issue. In my humble opinion the text suggested >above may be flagged during external review or it may generate a >DISCUSS. I suggest leaving the text as it is for now unless the >working group agrees on the text suggested above or any other text. > OK. I'll put it back. Scott K From spf2@kitterman.com Thu Aug 23 07:49: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 2F66E21F85AF for ; Thu, 23 Aug 2012 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, MANGLED_HRDCOR=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJpfJfi7OLT8 for ; Thu, 23 Aug 2012 07:49:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6470821F84F3 for ; Thu, 23 Aug 2012 07:49:45 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C89EDD0408D; Thu, 23 Aug 2012 09:49:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345733383; bh=/L2/K05QQYOtii81+EX+PCy2beym1fJyH0tW183+u2w=; h=References:In-Reply-To:Subject:From:Date:To:From; b=lEQXGwdHGSEDObl8ljj9UC1VxxEt/9HCnWHFM4aMhYNyVs+a9gGS9eWV/R9slxC4P ye7oVSHJN1K6XSL7BVpJnfNFh+sEA1shxXVo7HhwexDWj4sOBIVFBa0zCZaMtVG9+t le6sfCmufrcJn39oYSq0JVIVkFwYvHYdjtqkPJ0A= Received: from [IPV6:2600:1002:b023:b940:69f4:db7b:5750:9439] (unknown [IPv6:2600:1002:b023:b940:69f4:db7b:5750:9439]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2C8FCD04051; Thu, 23 Aug 2012 09:49:29 -0500 (CDT) References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <5035EF1F.1040009@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 23 Aug 2012 10:42:58 -0400 To: spfbis@ietf.org Message-ID: <3c305b1e-ccf3-4567-a929-b8fe28d04982@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:49:46 -0000 Alessandro Vesely wrote: >On Wed 22/Aug/2012 00:39:42 +0200 Scott Kitterman wrote: >> On Tuesday, August 21, 2012 11:08:46 AM Murray S. Kucherawy wrote: >>> In this particular case, the question is around interoperability >>> between the SMTP client and server. The question we need to ask is: >>> If someone doesn't do this, what's the impact? >>> >>> I think we can be certain that using 5yz codes is the right thing to >>> do. Is there any harm in picking the wrong 5yz code? What do we >need >>> to say that RFC5321 doesn't, that's specific to SPF? >>> >>> Same question for enhanced status codes: 5.y.z is obviously correct, >>> but beyond that, why is there a need to be more precise? > >The difference between 5yz an 5.y.z is that while SMTP mandates a >single specific code, RFC 3463 allows a choice. No existing codes >unambiguously identify SPF. We seem to agree on that being a feature, >not a defect. Hence, the above question makes more sense in this >case: What sort of confusion can be generated if one chooses a >different enhanced status code? > >>> Perhaps more generally: What problem are we trying to solve? Is it >>> simply a question of trying to avoid sending implementers off to >read >>> those other documents? >> >> Particularly the problem I'm trying to solve is having change for >unimportant >> reasons. While some have argued the codes don't need to be in >4408bis, I >> don't think anyone has suggested it's a problem. Given that these >codes are >> (with one exception that was a mistake) in 4408, I think there needs >to some >> positive benefit associated with removing them. > >Being error-prone is a problem by itself. > >In addition, making the wording more clear-cut can provoke revision of >existing policies and configuration of existing software. > >Finally, it may ease future development (see below.) > >> I do think there's value in uniformity on this. Not so much for hard >core >> interoperability between computers but to aid in human understanding >of what >> the various systems are doing. If different implementations use >different >> codes, then there is some potential for confusion. > >See question above. > >> Finally, I think it's better in this case to simply give the >preferred answer >> in 4408bis than to send implementers off to read two references, >particularly >> since one of which does not give a clear answer about how to proceed. > >The example provides a useful shortcut to those who don't read the >references, without confusing those who do. > >> If we're going to remove things, I think there needs to be more to it >than "I >> feel like that's not the best way to have done it." > >Sure. It identifies "insertion points" for further development. > >Some further development is needed. SPF originally emphasized the >negative results, assuming that senders would have changed their >forwarding methods. Some still uphold and/or deploy such silver >bullet view. However, it is not fully compatible with SMTP, and RFC >5598, Section 5.1 documents that changing the MailFrom implies a >number of problems that a mail admin may not be willing to tackle. > >Current SPF deployments emphasize positive results. The protocol >evolved, albeit not on the paper. However, domain reputation is not >an exact science yet, especially for smaller ADMDs having a somewhat >limited view of the global scenario. For that reason, and because >they have a better knowledge of their users, small ADMDs tend to >deploy the silver-bullet aspect of SPF more than others. Hence, we >need to recover that aspect, and adapt it to the current trend. To >precisely locate where on the paper that lies is a prerequisite for >such work. Perhaps I'm dense, but I don't see how any of that answers the question about then benefit of removing the status codes. And no, I don't think ambiguity is a feature. Scott K From spf2@kitterman.com Thu Aug 23 07:59: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 A6E4621F854A for ; Thu, 23 Aug 2012 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0-cgKvx97EU for ; Thu, 23 Aug 2012 07:59:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2BF21F8549 for ; Thu, 23 Aug 2012 07:59:15 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 68EFBD0408D; Thu, 23 Aug 2012 09:59:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345733954; bh=LMzx5oAGH8YvtXon0hDtkNG+tjGG8Vw4dGN+ZU+B5wM=; h=References:In-Reply-To:Subject:From:Date:To:From; b=GtKlFvCx4s9OVb6Lthc70bHWV2RJavDZ2Nand6xBD+mQ01lAaEk5i2VLKte8uOgkm hQtW84G5ykYU+sre/P6JxuNIAnic/9hU7ga7wC3Ao/vLXa/UosX9RsI06ektSj4jV4 Fvfo97gUIWjd+UNu3B0Kv/v4tjTT0ahSdChFHMUI= Received: from [IPV6:2600:1002:b023:b940:69f4:db7b:5750:9439] (unknown [IPv6:2600:1002:b023:b940:69f4:db7b:5750:9439]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9311CD04051; Thu, 23 Aug 2012 09:59:10 -0500 (CDT) References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 23 Aug 2012 10:57:28 -0400 To: spfbis@ietf.org Message-ID: <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:59:15 -0000 "Murray S. Kucherawy" wrote: >On Thu, Aug 23, 2012 at 1:51 AM, Alessandro Vesely >wrote: >> The difference between 5yz an 5.y.z is that while SMTP mandates a >> single specific code, RFC 3463 allows a choice. No existing codes >> unambiguously identify SPF. > >Why is that something that's become a necessity? > >> We seem to agree on that being a feature, >> not a defect. Hence, the above question makes more sense in this >> case: What sort of confusion can be generated if one chooses a >> different enhanced status code? > >This feels like change for the sake of change. How about: What sort >of benefit is generated by adding this additional detail? > >As I've said, I'm fine with examples using specific SMTP and enhanced >status codes, but normative language there steps on the documents that >define them, and I'd rather we omit it. It doesn't seem necessary. Having this language is not a change, except for one case where it was inadvertently omitted it's all there in 4408. I think removing what's there is what's change for change sake, not adding the missing information for one result to make the document internally consistent (it's one of the errata for 4408). Scott K From vesely@tana.it Thu Aug 23 08:56: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 32B9221F858F for ; Thu, 23 Aug 2012 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2kpmAA7V18M for ; Thu, 23 Aug 2012 08:56:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6804E21F855D for ; Thu, 23 Aug 2012 08:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345737416; bh=rLPDTDBtxN7cgbSDCqZUg1IkpnBZpX3+VKRZ3FKsRg4=; l=2131; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gm+CbQAKz3edp1OzBFinBOAXq38UYEhyvIzgRYlxcHCTmSyKNI/chBszkuOk46o2l RnE/HQ3S4WEpJ78pu7eQV6/bofWb2avy2aE6Oek9vajOS/HKvuzsqgztJNXP/1gxXE b6sMNUaTFdfvQ/3nhcHiV0WmGUZZmimF5Katv76A= Received: from [2.44.78.179] ([2.44.78.179]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 17:56:55 +0200 id 00000000005DC035.00000000503652C7.0000640F Message-ID: <503652BD.7020304@tana.it> Date: Thu, 23 Aug 2012 17:56:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <3c305b1e-ccf3-4567-a929-b8fe28d04982@email.android.com> In-Reply-To: <3c305b1e-ccf3-4567-a929-b8fe28d04982@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:56:59 -0000 On Thu 23/Aug/2012 16:42:58 +0200 Scott Kitterman wrote: > Alessandro Vesely wrote: > >> The difference between 5yz an 5.y.z is that while SMTP mandates a >> single specific code, RFC 3463 allows a choice. No existing codes >> unambiguously identify SPF. We seem to agree on that being a feature, >> not a defect. Hence, the above question makes more sense in this >> case: What sort of confusion can be generated if one chooses a >> different enhanced status code? >> >> [...] >> >> Some further development is needed. SPF originally emphasized the >> negative results, assuming that senders would have changed their >> forwarding methods. Some still uphold and/or deploy such silver >> bullet view. However, it is not fully compatible with SMTP, and RFC >> 5598, Section 5.1 documents that changing the MailFrom implies a >> number of problems that a mail admin may not be willing to tackle. >> >> Current SPF deployments emphasize positive results. The protocol >> evolved, albeit not on the paper. However, domain reputation is not >> an exact science yet, especially for smaller ADMDs having a somewhat >> limited view of the global scenario. For that reason, and because >> they have a better knowledge of their users, small ADMDs tend to >> deploy the silver-bullet aspect of SPF more than others. Hence, we >> need to recover that aspect, and adapt it to the current trend. To >> precisely locate where on the paper that lies is a prerequisite for >> such work. > > Perhaps I'm dense, More probably, my English is as if it was written by a foreigner ;-) > I don't see how any of that answers the question about then benefit > of removing the status codes. It might allow playing a different mantra, where the stress is more on what the receiver does and less on how it does it. According to the current text, reject and discard have the same conformance. > And no, I don't think ambiguity is a feature. Well you said the omission of an SPF-specific enhanced status code was not out of inattention. I inferred that if it's not a bug it must be a feature... From sm@elandsys.com Thu Aug 23 09:00:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF42E21F858F for ; Thu, 23 Aug 2012 09:00:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBPnw4BKySng for ; Thu, 23 Aug 2012 09:00: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 24EF121F855D for ; Thu, 23 Aug 2012 09:00:04 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NFxmbF010245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2012 08:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345737601; bh=T4k7Ncv5fNUlsWkYpVvkeHxlCh44EaqpuLtv4OqfTdo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ilqgDosMTihPILGcdJhB2IKqNefW3v3CCDxgHOXkMTau+sX3hOnETS9vhlgzIPnbk hP9AarxhHFZW+ePbPrnAxNnTBc9SPYmTd1Un3ryeepmZWkUDLHqMU7wM5tOOu1rBPN RTdn5YDHMYBrXlwlfLg2R6RY1rRbIbbwB3BVGR+w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345737601; i=@elandsys.com; bh=T4k7Ncv5fNUlsWkYpVvkeHxlCh44EaqpuLtv4OqfTdo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yODFYpGSU7iYS1MxEGC96G7X8h/OEaQSuHy/kiJCXqB1mRxMKXuTkj5eKihCossuz Kax7YF/p2Le3yOBVmcXk92z/EZQYFEjfHENkzHytGN/vvFPY3N+Nv1vahugQiBocV9 PUC16+e/F84waiZxkJXKDgsePvPQWRuqj+Bh1L9Y= Message-Id: <6.2.5.6.2.20120823065110.094b1138@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 07:40:41 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <5035BD24.7020304@isdg.net> References: <5035BD24.7020304@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Douglas Otis Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 16:00:05 -0000 At 22:18 22-08-2012, Hector Santos wrote: >Anyway, I think this and related sections should convey this as >migration feature because I don't think it will cater to all >existing systems that already have bots (theirs or 3rd party) that >rely on Receiver-SPF. I suspect most will add both since they may >not be able to technically afford breaking existing operations with >just Auth-Res version for SPF. I am quoting the above for context. I copied this message to Douglas Otis to notify him that this issue is being discussed. The Responsible Area Director once asked what was the problem with keeping the Received-SPF: header. The argument was about long-term simplification. John Levine mentioned that if you were allowed to generate both headers, they could disagree. Douglas Otis provided arguments in favor of retaining the Received-SPF: header ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ). Murray Kucherawy suggested an alternative in a message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02175.html Could the working group please work out something from there? Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Thu Aug 23 09:00: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 DE0E221F85AA for ; Thu, 23 Aug 2012 09:00:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsG65JMAmjIy for ; Thu, 23 Aug 2012 09:00: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 51C8C21F85FC for ; Thu, 23 Aug 2012 09:00:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NFxmbH010245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2012 09:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345737606; bh=yfDCbtzRJFtRNLrJGC4QokBKz2WLXyFPIQ1Ixk7k+Ac=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Eor9nVDCCAGOcuNKcJa0WGNQJYDjK+2ulfrXetHXiDVPfZKi+eEQJzzuAifmXnVEa bzjtUddep5N3tBl47fwFD/ogWEPBsF+2zrjmrKMrbr2l4lBoa7MdxPVgM8HW7cinfu bFlcHPNjgB333yK0+fecwb+0lOS/g/iyNxP8dKX4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345737606; i=@elandsys.com; bh=yfDCbtzRJFtRNLrJGC4QokBKz2WLXyFPIQ1Ixk7k+Ac=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pI5MWCzYcT3qms/CubOWEnhB2myeLlI6pvRFjAZO38vmX9h6RsoFTR3xVkqHHvZJJ k6FoIkmO8PrLcCAkMV2KWhZpJDy9NmnWnPbk/cma47HmSD+PW+SJSGYqUQMWDvcTkx lhdrMIigBhg5HtoiC6Fmm+esn4UIPJvuYJBnrtA8= Message-Id: <6.2.5.6.2.20120823074355.094b13c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 08:56:38 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <5035F75F.2070406@tana.it> References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 16:00:09 -0000 Hi Alessandro, At 02:26 23-08-2012, Alessandro Vesely wrote: >For a similar point, in part 1, bullet #1 we could exemplify > > "v=spf1 mx ?exists:%{ir}.list.dnswl.org -all" > >instead of or in addition to the spamhaus example. IME that's quite >effective as it solved all the practical cases I knew of, and still >allows -all. I believe that it is better if the SPFBIS WG is vendor-neutral. If we exemplify the above text it won't be flagged by ID-nits. I will notice it during my review. I will have to choose whether to look the other way. Other reviewers will also face the same choice. There has been ample discussion about Issue #12 on this mailing list. I'll leave it to you (or any other WG participant) to propose an alternative. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Thu Aug 23 09: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 0560821F857E for ; Thu, 23 Aug 2012 09:08:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5VtsozR8-fj for ; Thu, 23 Aug 2012 09:08:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561C21F8577 for ; Thu, 23 Aug 2012 09:08:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NG8VII008335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 09:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345738122; bh=muaUkMF0acwNE0h5lGXsXNYJs5ZlzSE1cDm7yCtwgII=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2Ipa95spN+elDaJaRNRTuusggdRY1zSyYlHwMdLxzN+YjdyP4tIswGk8PguxnvQfJ WvfiX5k9IFr7mhDffORoSlzUb9Op8gWjcdj2njL3NpEIKG9ySyngS855i/f2Cc7Mwe T8/AJ+S+wkfDU/odqmLNt03/BxYeQgF3SlUrvErE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345738122; i=@elandsys.com; bh=muaUkMF0acwNE0h5lGXsXNYJs5ZlzSE1cDm7yCtwgII=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=3lIDAYiVPCDyDo4NHUCAg1ew9GA516AbCJtWAvZcPG1i12MhL8L5udwuMklCgMwUf JcX+CK6FOusiitrW3EkpmBvYZLGutqhj2+/bO+XBfV5HvcGeigE5/5+Ui011dRwdyd TDw7Qp0MlcjejuFI4CIVwLXCJI/SOdCfhAhe1QZQ= Message-Id: <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 09:06:18 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 16:08:44 -0000 At 08:21 21-02-2012, spfbis issue tracker wrote: >#22: RFC 4408: Section 2.5.7 PermError on invalid domains after >macro expansion > > The Permerror definition ends with: > > 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. > > A after macro expansion of can be invalid, > i.e. a string not suited for DNS queries like foo..example (adjacent > dots), a with overlong labels, or similar issues not > permitted in the DNS > syntax. > > Suggested fix (variant 1): > > The last sentence in the Permerror definition is misleading. A > syntactically malformed can be also handled as no match. The > specification should say: > > 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. > > Please note that an unexpected can be also handled as no > match, ideally implementations document how they handle such issues. The > outcome for an unexpected without macros might differ from > the outcome for an unexpected after macro expansion. > > Suggested fix (Variant 2): > > The last sentence in the Permerror definition is misleading. A > syntactically malformed can be also handled as no match. The > specification should say: > > Be aware that it is also possible that this result is generated by > certain SPF clients due to the input arguments having an unexpected > format; see Section 4.8. > > At the end of Section 4.8 add: > > Note: Historically, this document has made no provisions for how to > handle s, or macro-expansions thereof, that are syntactically > invalid per [RFC1035], such as names with empty labels (e.g., > "foo..example.com") or overlong labels (more than 63 characters). Some > implementations choose to treat as a no-match mechanisms, and ignore > modifiers, with such names, whereas others throw a "PermError" exception. > The outcome for an unexpected without macros might even > differ from that for an unexpected after macro expansion. > > Rationale: > > Reporting a TempError in such cases is no option, the syntax problem won't > go away for a given sender policy, HELO identity, envelope sender address, > and sending IP combination with a try again later TempError approach. If > anything else is as expected the sender policy might need to be fixed > manually, supporting PermError. > > If the DNS syntax problem is caused by random net abuse, or intentionally > by an attacker, a no match approach, eventually reaching a FAIL for -all > or whatever the sender policy offers, is better. In common practice this > problem is handled as no match OR PermError, like similar problems > explicitly addressed in the specification. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html Can WG participants please review draft-ietf-spfbis-4408bis-06 and comment on Issue #22? Regards, S. Moonesamy From sm@elandsys.com Thu Aug 23 09:36: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 30D4F21F85AF for ; Thu, 23 Aug 2012 09:36:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lud-6shefJox for ; Thu, 23 Aug 2012 09:36: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 961D921F855A for ; Thu, 23 Aug 2012 09:36:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NGaNqY029643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 09:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345739799; bh=/lYgk1S9UR1GOlYwERk/dIT8mJXODay/0DxumISIkPU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=bsNKxIj57hZVRuDL/5UDzvmbYbb7PSxvsJ+DP1U0L8hY+CtDPyGXfnmt6LgZUJR8v hA+qeKNyxOu+ZCtZvWNlYbytE74WprfZQvCsn6wfKNk2tH6bQRKDs+GS4DIEZf3tPp O2qJoPwdkgqCWhSlG/zkVzv2Wrd6mVFR84VQUlKM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345739799; i=@elandsys.com; bh=/lYgk1S9UR1GOlYwERk/dIT8mJXODay/0DxumISIkPU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ExqDzRMwuSV4ZmRBVxe8FDYMDgDkBAMh/pfODJnkMfYkQwzIPWqvsIpW1OUFqrqKy vLpadgC/lgDsneRWE6Veph5opY3lQimPHaz6Gmbwb6Rys7rCaFCPgymY+nPDzmi/nW vyuoUFSCK6VixOwir+r6p6JQL7FiAOphehtrJP2Y= Message-Id: <6.2.5.6.2.20120823092947.0a140ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 09:36:20 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <511d0c8b-b3fa-4ee3-bc55-aacc3098754b@email.android.com> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <2503352.tTzaICpeS8@scott-latitude-e6320> <6.2.5.6.2.20120822153007.0a670d18@resistor.net> <1476027.UdxMWrdmeL@scott-latitude-e6320> <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> <511d0c8b-b3fa-4ee3-bc55-aacc3098754b@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 16:36:43 -0000 Hello, I am closing the ticket for Issue #28. As a reminder, open tickets are listed at http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Regards, S. Moonesamy From vesely@tana.it Thu Aug 23 09:59: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 75ADE21F854D for ; Thu, 23 Aug 2012 09:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AITtivLemFy for ; Thu, 23 Aug 2012 09:59:15 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8729A21F853D for ; Thu, 23 Aug 2012 09:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345741154; bh=iqzPbVQWJXAGkgprt+iHfBddNVUPgpFp6qvClsuj5p4=; l=1521; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=j0vENIZE+bUQ04Z4YixUBm6pQ/Ci7Jj3l0yrrj8JXFncW8OQeu1Sk2mV4BySj8z6S ixWa+LR5u/9+t84+YNk7YfIwIjK+9hU8LbhvN9s1BMmXtHM+1qirxKtcJrrCtJrFzD zj6+HQ9Tv63QJqlTrBTOoEMwcywaMx3l3xIgflXs= Received: from [2.44.78.179] ([2.44.78.179]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 18:59:12 +0200 id 00000000005DC035.0000000050366161.000071A1 Message-ID: <50366154.5010100@tana.it> Date: Thu, 23 Aug 2012 18:59:00 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> <6.2.5.6.2.20120823074355.094b13c8@resistor.net> In-Reply-To: <6.2.5.6.2.20120823074355.094b13c8@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 16:59:16 -0000 On Thu 23/Aug/2012 17:56:38 +0200 S Moonesamy wrote: > At 02:26 23-08-2012, Alessandro Vesely wrote: >> For a similar point, in part 1, bullet #1 we could exemplify >> >> "v=spf1 mx ?exists:%{ir}.list.dnswl.org -all" >> >> instead of or in addition to the spamhaus example. IME that's quite >> effective as it solved all the practical cases I knew of, and still >> allows -all. > > I believe that it is better if the SPFBIS WG is vendor-neutral. If we > exemplify the above text it won't be flagged by ID-nits. I will > notice it during my review. I will have to choose whether to look the > other way. Other reviewers will also face the same choice. I agree completely with your vendor-neutral feeling. However, the effectiveness of mentioning an actual whitelist cannot be achieved with circumlocutions. It is already unlikely to convince (i) ADMDs to put that term before -all, and (ii) non-rewriting alias expanders to subscribe to the whitelist appearing in the SPF record of the site that rejects their mail, even if we mention which list we're talking about... Dnswl.org is not commercial, much like the currently exemplified spamhaus.org. Subscriptions and small-volume querying are free. Ietf.org is itself subscribed: http://www.dnswl.org/s?s=ietf.org > There has been ample discussion about Issue #12 on this mailing list. > I'll leave it to you (or any other WG participant) to propose an > alternative. An alternative is http://www.spamhauswhitelist.com/. Is that better? From vesely@tana.it Thu Aug 23 10:23: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 ABA2121F84EA for ; Thu, 23 Aug 2012 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N10BQFbLzHD8 for ; Thu, 23 Aug 2012 10:23:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F19B121F84CD for ; Thu, 23 Aug 2012 10:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345742580; bh=fbRkxbWtdRPj/LXpd7Y1Kd/8Wgu5E/RLhxvMjDuGv9s=; l=1044; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lfz2SsKrb2268RNoZMou/QjTqIoCZvMS/1OhikBl8pFcY7+kuNGk8RUMG4RusakDT g7tgGLPLY7nN06oGMaDkhHVAdwuWLQIM9AC6YMSLMf2Tr94A2k1gngDdckAlh+rDux oab0Bnd7EsJuYW82YBEEJ6Muv0SKoIHsG4SxqzkA= Received: from [2.44.78.179] ([2.44.78.179]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 19:22:58 +0200 id 00000000005DC035.00000000503666F3.000076F4 Message-ID: <503666E7.2030803@tana.it> Date: Thu, 23 Aug 2012 19:22:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4563708.iYIAOlqAVf@scott-latitude-e6320> In-Reply-To: <4563708.iYIAOlqAVf@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 17:23:01 -0000 On Thu 23/Aug/2012 00:31:40 +0200 Scott Kitterman wrote: > On Wednesday, August 22, 2012 12:13:49 PM Murray S. Kucherawy wrote: >> We have Section 1.3.5 that defines what it means for an SPF feature to >> be deprecated in the context of this document. I think it would be a >> good idea in terms of setting reader expectations to list the things >> that are deprecated in a bullet list in this section. That way, when >> readers run into them, they understand the material is something >> that's likely to go away soon/later/whenever/something and can plan >> accordingly. It also provides a good early summary for those already >> familiar with RFC4408. > > I think this makes sense. Once it seems like we have a final list of what will > be marked deprecated I'll be glad to add it. Feel free to remind me if I > forget. +1, IMHO it should be a subsection of Appendix C (Change History), when we'll clean it up and rename it Changes since RFC 4408... Is it worth adding a ticket for this in the datatracker, as a reminder? From superuser@gmail.com Thu Aug 23 11:05:29 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 9D43E21F8629 for ; Thu, 23 Aug 2012 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjSePwZ1La0g for ; Thu, 23 Aug 2012 11:05:29 -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 EB38921F863F for ; Thu, 23 Aug 2012 11:05:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2731852obb.31 for ; Thu, 23 Aug 2012 11:05:28 -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=ta5b+FgrJ/1QZcvtYYAEpuYwQzlj6gISGx/h+q9gtrA=; b=Sk3eR2jb2AD5/zQVdewDDsk/iHb/eCdnqGSP1qlC7k1+AdR9Pi/IZwsVpHgMQ/x36b MQ2NV4hN1z5mtX2dSe/YXQ915rejblmyC3j7sGWLCafxBbqYxc/ueTi9Lc62ASWMo46M XGEZhm+1/tKx9EcLngEMZ8CaBwtwRDFtwEnhvIXgev2MKBjauGb8uoKu9/uMTESN9kzd zmNMfrPYfrFy4eeX0Y3VKJJkC0rT3oGVDfPBUYBDMM1CBR8lbFHIVmwvj48RABniUNoU j9UyJe3euiGzsqamQEeR/qs7eSOSoSHRju/yuEET9TpgmHyGJHHgKC8vaU4k1N9ZwBO8 8qRg== MIME-Version: 1.0 Received: by 10.60.6.6 with SMTP id w6mr1813352oew.129.1345745128616; Thu, 23 Aug 2012 11:05:28 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 23 Aug 2012 11:05:28 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120823074355.094b13c8@resistor.net> References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> <6.2.5.6.2.20120823074355.094b13c8@resistor.net> Date: Thu, 23 Aug 2012 11:05:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 18:05:29 -0000 On Thu, Aug 23, 2012 at 8:56 AM, S Moonesamy wrote: > I believe that it is better if the SPFBIS WG is vendor-neutral. If we > exemplify the above text it won't be flagged by ID-nits. I will notice it > during my review. I will have to choose whether to look the other way. > Other reviewers will also face the same choice. > > There has been ample discussion about Issue #12 on this mailing list. I'll > leave it to you (or any other WG participant) to propose an alternative. I agree. I'm also concerned with a tendency to include an example of every possible use of SPF to solve some problem. It feels like it's getting mighty cluttered. -MSK From superuser@gmail.com Thu Aug 23 11:06: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 E7EA821F860E for ; Thu, 23 Aug 2012 11:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeyL8xMj9VFg for ; Thu, 23 Aug 2012 11:06:19 -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 DCD9221F8605 for ; Thu, 23 Aug 2012 11:06:17 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2734431obb.31 for ; Thu, 23 Aug 2012 11:06:17 -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=mvUJCfhC866Q0sURAo142YE2hRqNaWQNfyxoUtAqGMA=; b=pOywBPkElIkI7GlPJGbYmW+IagdkJU/jd0I7M//yJWk0tm5XYxqvP5YmoEsTVMWZBJ CzqLaaHAY16ApeAQeQEgoYDyqMwDblQSX8Krl/k534QRBGKo4aGFniMrqEo+7efV7aHd vQ5YXUs3SLkHf+7zw7uJM0LjLY+VwdOIo2Kboyh+3vbKJUcBbDbqmHuNAZh6f+797pdH EK5e+x3OB48QpHOe7ns8ZpJtB26+Gw/Eq7k6IkAX2Noe33PGFmfM6tDTd2StfVwsvIu+ R6l6+h5/O+yprMeL6jddYbZYmPhBoPK9O8bFPjB2KeVPFkj3ufTbHQ91JK86UQow3Rgs YFRA== MIME-Version: 1.0 Received: by 10.182.72.9 with SMTP id z9mr1825352obu.5.1345745177471; Thu, 23 Aug 2012 11:06:17 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 23 Aug 2012 11:06:17 -0700 (PDT) In-Reply-To: <503666E7.2030803@tana.it> References: <4563708.iYIAOlqAVf@scott-latitude-e6320> <503666E7.2030803@tana.it> Date: Thu, 23 Aug 2012 11:06:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] On deprecated things X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 18:06:26 -0000 On Thu, Aug 23, 2012 at 10:22 AM, Alessandro Vesely wrote: > +1, IMHO it should be a subsection of Appendix C (Change History), > when we'll clean it up and rename it Changes since RFC 4408... Is it > worth adding a ticket for this in the datatracker, as a reminder? That would defeat the stated purpose of putting a summary early in the document. -MSK From vesely@tana.it Thu Aug 23 11:07:37 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 545F521F860E for ; Thu, 23 Aug 2012 11:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ch7KqZkk5Vi for ; Thu, 23 Aug 2012 11:07:36 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AA0CF21F8605 for ; Thu, 23 Aug 2012 11:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345745254; bh=a7zwR8dBVyt1P6FD0F/KtQRXOAaQSC6bqSMiE3zGAc0=; l=1439; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B4KlP1oqhjKKyEfvFaIuPJcZQnbf+h+leBUyfsOPM0NC5gDj1Gf6NMoUuAeQrD+3p L9srVU4+oO9Glk0P6XEJ9mu8A/kV5z4xbLsnB4kjrc9YFmKip9QULuDye5U5gBauaG A3mZna7Mqb2BO8BNJ8bKjHQMnuMqKEdAzi+cvCvY= Received: from [2.44.78.179] ([2.44.78.179]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 20:07:33 +0200 id 00000000005DC035.0000000050367165.0000021B Message-ID: <50367158.6090800@tana.it> Date: Thu, 23 Aug 2012 20:07:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@scott-latitude-e6320> <1449082.EbgXUPjcEi@scott-latitude-e6320> In-Reply-To: <1449082.EbgXUPjcEi@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 18:07:37 -0000 On Thu 23/Aug/2012 06:03:08 +0200 Scott Kitterman wrote: > On Wednesday, August 22, 2012 04:53:48 PM Murray S. Kucherawy wrote: >> On Wed, Aug 22, 2012 at 3:16 PM, Scott Kitterman wrote: >>> For this issue, I think it requires a two step answer: >>> >>> 10.7 Unauthorized Message Insertion >>> >>> Section 7.1 of [RFC5321] describes security considerations associated >>> with the SMTP protocol and spoofing. SPF is an attempt to address this >>> issue. When receivers deliver mail that has failed SPF checks then the >>> affect SPF has on this issue is reduced. In order to mitigate this >>> concern it is important that the results of SPF check be recorded (See >>> [Section 7]) to make it possible for MUAs to display message status to >>> end users. >> >> I generally like it, but the language here doesn't acknowledge SPF's >> failure modes (e.g., forwarding). Perhaps: >> >> s/the affect SPF has on this issue/any protection SPF offers (modulo >> Section 9.2 and Section 9.3)/ >> >> ...or something along those lines? > > I think it's the other way around. Those failure modes are reasons why > someone might choose not to reject at SMTP time, but they aren't part of this > issue, I don't think. I'd s/MUAs/downstream message processors, such as MUAs,/. It goes without saying that they have to be prepared to receive a stream of messages not so clean as it could be, doesn't it? From superuser@gmail.com Thu Aug 23 11:14: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 367C221F853B for ; Thu, 23 Aug 2012 11:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmLHRvwJ0t+H for ; Thu, 23 Aug 2012 11:14:37 -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 89AF321F8504 for ; Thu, 23 Aug 2012 11:14:37 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2761238obb.31 for ; Thu, 23 Aug 2012 11:14:37 -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:content-transfer-encoding; bh=5mS9tVw0hgos+qW8a5vC08L9wSzdPOf9gVGOOm0CTaI=; b=VFm32OThQfOtlW+9UKC9t3YIrEwuDt61k2pM8lsR+SGwDg6SL6ihNXbEOb1+ly2kFl 8C835NzzM/Vn6pRD2a0BWr6l0Xnqmj7X3XJDFMEoRY4z0uBqk6Go0Hp+KJzifX1hRudV eI+UP89/Dq2w+PYZyP/nFRE3G+duTXdwYeJn6NWArm3qOMPcTxn3XaifLhKmrQEtw2Vy mWF28k9AqOha6PG7JbrQs7EmjIFM64nNoISOOsLd1zKErKFjAsUAusWMyDRNyLtpU4mj 5mCLg4sgBz6mK/k9gFFgWi/duWOIfSoZuD6eMF7qDAIrufule6ZJnkM4tbtHRrdBFW28 K0PA== MIME-Version: 1.0 Received: by 10.182.44.68 with SMTP id c4mr1848259obm.27.1345745677007; Thu, 23 Aug 2012 11:14:37 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 23 Aug 2012 11:14:36 -0700 (PDT) In-Reply-To: <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> Date: Thu, 23 Aug 2012 11:14:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:14:38 -0000 On Thu, Aug 23, 2012 at 7:57 AM, Scott Kitterman wrote= : >>As I've said, I'm fine with examples using specific SMTP and enhanced >>status codes, but normative language there steps on the documents that >>define them, and I'd rather we omit it. It doesn't seem necessary. > > Having this language is not a change, except for one case where it was in= advertently omitted it's all there in 4408. I think removing what's there = is what's change for change sake, not adding the missing information for on= e result to make the document internally consistent (it's one of the errata= for 4408). My point is not change for the sake of change, but that it was a mistake to include them in the first place. Since cleaning up errors is within charter, I think it's a valid thing to consider. What special behaviour are we hoping to provoke in MTAs by providing normative guidance for use of specific codes when a rejection occurs due to SPF failures? Unless there is some, then there's no new data to encode, and thus providing normative guidance of specific codes is not valuable. -MSK From sm@elandsys.com Thu Aug 23 11:26: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 B479B21F851E for ; Thu, 23 Aug 2012 11:26:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46N2fXoiR+9t for ; Thu, 23 Aug 2012 11:26: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 D4E7E21F851B for ; Thu, 23 Aug 2012 11:26:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NIQ1b1006931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 11:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345746372; bh=IKxOGR9papKmc3OqtpO/2l0W3LRpL0BLBSTxuSgml94=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=BhFKWgmajbidAZNlIpYS9AZhvLjorUG2s8QVBhE9q7y18W2fNZI5V7pNor+iG8kYJ oQgCQl5Px0srqDRd5uQApYMEEKWJo7crRhjJKjVBx4vZIR3PzZlctZPTNPFzQP+0is kZ5AQ0C4zMGs+G80nx7EUGlSKF3APm4BDnsNd+Zo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345746372; i=@elandsys.com; bh=IKxOGR9papKmc3OqtpO/2l0W3LRpL0BLBSTxuSgml94=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ZU4RoYEXD0LltbcRVywicCyFxRJmFVNTLv0BplXTLu1sb8YUxzKiHkGHQsveMe9Yd mE/bznVvyVAwQL5rpl0PbMN8IccI7vyxMlatm3DF9N65LeQOf4Awyf0ITBUgwiR0QC TfRrWFAvRrvfiM9xg8Gew4d+a0qjS1NYl6sHpvxE= Message-Id: <6.2.5.6.2.20120823101355.090fe9b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 11:24:29 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50366154.5010100@tana.it> References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> <6.2.5.6.2.20120823074355.094b13c8@resistor.net> <50366154.5010100@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Vendor neutral (was: #12: RFC 4408 Section 9 - Forwarding and helo identities) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 18:26:20 -0000 At 09:59 23-08-2012, Alessandro Vesely wrote: >Dnswl.org is not commercial, much like the currently exemplified >spamhaus.org. Subscriptions and small-volume querying are free. >Ietf.org is itself subscribed: http://www.dnswl.org/s?s=ietf.org It would be inappropriate of me to favor X over Y. Whether X is free is immaterial. >An alternative is http://www.spamhauswhitelist.com/. Is that better? No. Regards, S. Moonesamy From vesely@tana.it Thu Aug 23 11:38: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 0C94921F84F5 for ; Thu, 23 Aug 2012 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1vE9VV7B4-m for ; Thu, 23 Aug 2012 11:38:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD421F84C4 for ; Thu, 23 Aug 2012 11:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345747135; bh=OOPDyF8P9GxYUTetOJjWYq/U7cTas+VfyOn4NVZB2Lk=; l=413; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ER48LxgmKW8qNW/pcthGr7drb7OyzE3b3wIynWkqdpHo85fad6lHgvH4VG8VO44hV X8y7RbD3BOpIgmF5UkZjFrdK8h+dr6bIo2INlbgDddgAjj90XPVaMZJ5IN4h3+1F6P +18mC7WGx9+1K+PAI/QU0tbY0AGeQeeu9O0Q/XIs= Received: from [2.44.78.179] ([2.44.78.179]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 23 Aug 2012 20:38:53 +0200 id 00000000005DC035.00000000503678BE.000008D4 Message-ID: <503678B1.40306@tana.it> Date: Thu, 23 Aug 2012 20:38:41 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:38:57 -0000 On Thu 23/Aug/2012 20:14:36 +0200 Murray S. Kucherawy wrote: > > What special behaviour are we hoping to provoke in MTAs by providing > normative guidance for use of specific codes when a rejection occurs > due to SPF failures? Unless there is some, then there's no new data > to encode, and thus providing normative guidance of specific codes is > not valuable. +1 for removing 2119-language for codes From sm@elandsys.com Thu Aug 23 12:45: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 A5ED621F86BA for ; Thu, 23 Aug 2012 12:45:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3-ObYfpqqXQ for ; Thu, 23 Aug 2012 12:45: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 97D0B21F86A2 for ; Thu, 23 Aug 2012 12:45:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7NJjYrS000703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 12:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345751145; bh=v8T8fjKIfcK64sbfHVjM02o4qfZjb4YEdCOv67aqSs0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=vIKALd+6T3SMeh/Ndr61417GaPjOoKLaro007WZJiTqdDQY8k/BTga5rcgqnJBlTT zih+7/3R11HyBRmRGu0uJ70LPIsHLaHx3zVvML9u5hY1k19gkxUb1TodbVd9Ajdeis Iw0+YtABfc4IEqR36mtO4MYrOjrMxFCKZ5QErTS0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345751145; i=@elandsys.com; bh=v8T8fjKIfcK64sbfHVjM02o4qfZjb4YEdCOv67aqSs0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=lp+yQVl2MkV74CpqAdnFmtSUFyUyeaAAblZU69l9lUuaBXFx+QFrK3n2Ap6pvcdpq I9APgWaWGutFH76BMtO7J6xf4EFus/zGo5fRpac79fW+p1lzcGujEtV7F9fT+G8RfW cz6mFHQWxet0FLutun9YuolgSHgM5sgyYshB7myU= Message-Id: <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 12:45:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <503678B1.40306@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> <503678B1.40306@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:45:48 -0000 Hello, I have read the messages on this thread. I will flag the following text in Section 2.5.4 as an issue for AD review: "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." Barry Leiba, as Area Director, provided some very useful information which may be relevant to the discussion about the above text ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02240.html ). I would be picky about the "checking software". :-) Regards, S. Moonesamy From hsantos@isdg.net Thu Aug 23 13:27: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 8ABEF21F844F for ; Thu, 23 Aug 2012 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUGozu-BGHcf for ; Thu, 23 Aug 2012 13:27:41 -0700 (PDT) Received: from winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D76B21F844C for ; Thu, 23 Aug 2012 13:27:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2721; t=1345753652; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BjYAnGLPMQkBtemzk/+Oab0lIJ4=; b=PpxtbOkHI152ZWCx7vy0 sv3hHTOXHx4/wl+fgtwUmqf/f3C2+1cDTjrGzTtJT+WaL6Ta72yaGu8MZQOWElRn 8AUXSsptq4fQjX5tGBktteLv3+Ov66vqkOwME3pLty3iUhpnuS5uCXNb9/bOmlG7 hj7meD6UokXkda+3UOEtXvQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 16:27:32 -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 1775448839.1305.4152; Thu, 23 Aug 2012 16:27:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2721; t=1345753461; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=W3uZeov RL5lJlgLs7ndgvpaXWOMsE/TrDqkWYwleoW0=; b=hXsep9OyEX77mJb4ioDeVWd xYe8J0pD1uWG4EZO6PB+YbC10qlrUIeIiVCHa6nmgrd77+paEfgBYTGaoGKS0q0T YPJbqbHL51Oq7NhhkYiY9BMhi3wYjI2AUB0eV4xso1dBSF0rjPBp19CDDe5AXynW WcUw8OFi6SL9gxQmy4ZI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 16:24:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2374259755.9.8124; Thu, 23 Aug 2012 16:24:20 -0400 Message-ID: <5036924D.6020500@isdg.net> Date: Thu, 23 Aug 2012 16:27:57 -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: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> <503678B1.40306@tana.it> <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> In-Reply-To: <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:27:42 -0000 S Moonesamy wrote: > Hello, > > I have read the messages on this thread. I will flag the following text > in Section 2.5.4 as an issue for AD review: > > "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." > > Barry Leiba, as Area Director, provided some very useful information > which may be relevant to the discussion about the above text ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02240.html ). > > I would be picky about the "checking software". :-) Yes, you have argued for 550 when you saw software using 551, like with quite a number of GLS (GreyListing Servers) and there are client software that might be triggering logic off the 551 since the 550 is very generic, hence why it (551) was used to cover non-extended reply code server support. My view. I don't see a problem with having specific examples. Perhaps if anything, they are just poor examples for reply text and also the exact paragraph can be improved too. IMO, if we want to remove the codes and link other docs, then we need to change the paragraph to state specifically the subject type of reply codes. Something along the line: If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use policy-based reply codes with the appropriate policy-based reply reason text. See policy examples in RFC5321, RFC3463. But to me, even for the best programmer in the world, he will be tickled pink if he had specific examples to work with. Otherwise, while he might have open windows on his desktop for RFC5321 and perhaps RFC3463 or even perhaps already printed out if his software is going to support extended reply codes, in the end, he might look else where for real illustrative transaction examples in the market place for the sort of the text that is being used. Spare him the need to search for servers that have working operational examples of rejects. No harm to anyone except maybe to a RFC/IETF purist. We need to remember, our "customers" of these docs are the real readers, NOT people like us (in this WG). They are certainly not IETF Technocrats who are privy to every known RFC document on earth and can put it all together. This is one reason I believed and also believed many also believed, RFC1123 was the like the "Holy Bible" for internet hosting! While it filled in many gaps missing at the time, it did one great thing - a single doc to work with with a sweet summary for a requirements table. -- HLS From hsantos@isdg.net Thu Aug 23 14:43: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 49DD921F849B for ; Thu, 23 Aug 2012 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baTlG2yhjIcX for ; Thu, 23 Aug 2012 14:43:07 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC9D21F849A for ; Thu, 23 Aug 2012 14:43:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2550; t=1345758182; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mL5gS1U6xv7+YMoh6OOB20yV6T0=; b=HgAbJ6eOoMiRiED80ZgP o/fpEtRfAGDH9orV/bP7FWPWn3NDbrLUmro4a9eCjF/G7GGYsdAwWzuuDuO1NDQF PUCRXc57PDnrWzUSvmFANhA5Jqao+99kyLinpMRR2pyQzabUAtFRlJcy5xminiPw m57FOxQALPl1gZ+lYPx+iOg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 17:43:02 -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 1779979061.1305.3732; Thu, 23 Aug 2012 17:43:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2550; t=1345757988; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3stdSFK r3H2BHc9cku/HHneCKV1HXyTqKE3JwASnu4Q=; b=uPh5U0I6VWTzmHLMypS48MD 2q5k/mABgXdvGhMnis4BLyMdi59vjWYuxjcSeKDVy7eIie3gB1UB4insOoowB9is oS3N6cVoj5lLIG7y8ZhOaZNYZlNeq//4pQfHC5/PCy/sUBGFAwoyjN489k2fl9sz bZCM+vo6B02UFjF/8nZs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 17:39: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 2378787192.9.1868; Thu, 23 Aug 2012 17:39:48 -0400 Message-ID: <5036A3D5.8070003@isdg.net> Date: Thu, 23 Aug 2012 17:42:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <4F912ADF.1070201@tana.it> <20120420124423.21010.qmail@joyce.lan> <6.2.5.6.2.20120822120806.0a11c1d8@resistor.net> <503584DA.8070403@gathman.org> <5035F75F.2070406@tana.it> <6.2.5.6.2.20120823074355.094b13c8@resistor.net> <50366154.5010100@tana.it> In-Reply-To: <50366154.5010100@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 23 Aug 2012 21:43:10 -0000 You looking to open for a major can of worms? :) This sort of thing has long been a major taboo, even for technology that is donated by a market/technology leader to the public domain. It is actually a "black art" to be able to design/write functional and technical specification that is general and fair to all involved. Takes lots of engineering time to do be able to do this. For the IETF, many have long, especially those like myself who put engineering trust in their peers, looked at the IETF as the gatekeeper and to watch for these sort of things. That said, we do look at market leaders to lead the way - but with fair and open new directions that doesn't add a strategic barrier and dependency to your own growth (this is where anti-trust seeds are laid). Alessandro Vesely wrote: > On Thu 23/Aug/2012 17:56:38 +0200 S Moonesamy wrote: >> At 02:26 23-08-2012, Alessandro Vesely wrote: >>> For a similar point, in part 1, bullet #1 we could exemplify >>> >>> "v=spf1 mx ?exists:%{ir}.list.dnswl.org -all" >>> >>> instead of or in addition to the spamhaus example. IME that's quite >>> effective as it solved all the practical cases I knew of, and still >>> allows -all. >> I believe that it is better if the SPFBIS WG is vendor-neutral. If we >> exemplify the above text it won't be flagged by ID-nits. I will >> notice it during my review. I will have to choose whether to look the >> other way. Other reviewers will also face the same choice. > > I agree completely with your vendor-neutral feeling. However, the > effectiveness of mentioning an actual whitelist cannot be achieved > with circumlocutions. It is already unlikely to convince (i) ADMDs to > put that term before -all, and (ii) non-rewriting alias expanders to > subscribe to the whitelist appearing in the SPF record of the site > that rejects their mail, even if we mention which list we're talking > about... > > Dnswl.org is not commercial, much like the currently exemplified > spamhaus.org. Subscriptions and small-volume querying are free. > Ietf.org is itself subscribed: http://www.dnswl.org/s?s=ietf.org > >> There has been ample discussion about Issue #12 on this mailing list. >> I'll leave it to you (or any other WG participant) to propose an >> alternative. > > An alternative is http://www.spamhauswhitelist.com/. Is that better? > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Thu Aug 23 18:54: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 5B53B21F855E for ; Thu, 23 Aug 2012 18:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.637 X-Spam-Level: X-Spam-Status: No, score=-3.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuR-3vLYVUQ8 for ; Thu, 23 Aug 2012 18:54:08 -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 9AE8B21F854B for ; Thu, 23 Aug 2012 18:54:07 -0700 (PDT) Received: by lbky2 with SMTP id y2so54420lbk.31 for ; Thu, 23 Aug 2012 18:54:06 -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=sA455udJIqNTs0LOzFYhuHWOi6yndk+RP7a6Q/eEAX4=; b=qxOMDJhQfPTlK5Hjx4r6OTo/SOO09m9t1xywbSKaHutdvXgInC80h2rqiwpCX7VIEr GgSNGK8GvVyZEf+/Xu2hAtjYWfADhmynSUxUZV+6B1YZiTzPHfGJsmwSyoHsGI2QkLvG sdW8hvnOShkGrEdXZYaNl6I2xedVLtpsPeFeYVbikLftnnV5guzUCu0Vvly/UdNDfzaN +JTQGJ8pEb1T/GybIi4k+25SFezmi+KyBuGhdx+FySFSkECeidMuhk0YlSA7xC5C9CKF 4HENGxPb1b2dMEvA5yl3gBxULDc9YmwXMGzLTV2pF9dJKMI7EWouoVZwItuem9Jer8/P sQKw== MIME-Version: 1.0 Received: by 10.152.112.234 with SMTP id it10mr3851906lab.36.1345773246406; Thu, 23 Aug 2012 18:54:06 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 23 Aug 2012 18:54:06 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> <503678B1.40306@tana.it> <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> Date: Thu, 23 Aug 2012 18:54:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:54:08 -0000 On Thu, Aug 23, 2012 at 12:45 PM, S Moonesamy wrote: > I have read the messages on this thread. I will flag the following text in > Section 2.5.4 as an issue for AD review: > > "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." > > Barry Leiba, as Area Director, provided some very useful information which > may be relevant to the discussion about the above text ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02240.html ). I'd be happy to argue with the ADs in support of dumping the normative text and leaving useful examples. -MSK From hsantos@isdg.net Thu Aug 23 21:01: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 B5D5921E8044 for ; Thu, 23 Aug 2012 21:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6ZRcY6e5Opz for ; Thu, 23 Aug 2012 21:01:02 -0700 (PDT) Received: from groups.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7134D21E8042 for ; Thu, 23 Aug 2012 21:01:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5058; t=1345780853; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zekv69qKcBbMjfZ6ECNNOuHreTo=; b=ou9JAHcB7k1SmvGdp7du jHvZoUDerveaB9oy9DLKw9ci5gLYVV4zbEfj0n3HUOl1hLi7zhNBO8QpIhCmUDwg 5pHTI0VPFA8BguUEmUKSbRXlKMwgl+eB+ymSjKgv0K0+xIdbdtpgUm6OTlHdvR47 YgvJ7zDLztvVdIykT9XDtEY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 00:00:53 -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 1802649423.1305.5216; Fri, 24 Aug 2012 00:00:52 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5058; t=1345780661; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zYTN0P1 n6jHEoY/2sITdFp3JTkRhZSoUlchQAlevTIg=; b=wuQmoNPIgrCZliHUM1xJzyB UFkMyivA8N3XOBzLMbZO5Lat/4X0pWHaUz8kugrxZxWCTZ6KqNBEBmgR1rz4CSTd lyAZtB+grvIOZ//kPBn5iUOqTot1gHfT6TkGzRzr5ZmXuRhuSdPBjcBioIHq+2/7 ITtDDRjCmo7fifcf2tws= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 23 Aug 2012 23:57:41 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2401459161.9.7148; Thu, 23 Aug 2012 23:57:40 -0400 Message-ID: <5036FC84.8090008@isdg.net> Date: Fri, 24 Aug 2012 00:01:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> In-Reply-To: <16215316.XYRRSdKXvA@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 04:01:03 -0000 Scott, Trying to figure out where out points differ, I think perhaps there is a presumption that all backends support user level policies or methods with automatic spam folder sorting/separation. If so, I don't think that can be automatically assumed, it needs to be highlighted that it is important. In this case, then the only security issue could be isolated to the RFC-based OFFLINE MUAs (Outlook, Live, TBird, Eudora, Opera, etc). But I think it is safe to suggest that we normally can not place a high dependency on offline store and forward based MUAs to have the special protection required passed off to users via ACCEPT+MARK. For the sake of an example, we would not be able to support Accept+Mark until separation is made available. We could only support SPF hard failures with a reject. We can not support Accept+Mark because our stock product does not separate mail in this way. We have in total six different ways mail can be access (MUA) for our total mail framework product line. 1) Telnet: telnet bbs.winserver.com MUA with Console/ANSI/VT100/102 Terminal Support 2) Frontend Native GUI MUA, http://www.winserver.com/public/wcnavigator.wct 3) Web-based MUA http://www.winserver.com 4) Sysop Editor with powerful mail management features (Stock) 4.1) Several 3rd party editors using our API 5) MAPI API hook for Outlook (Uses Exchange technology, obsolete) 6) Support for RFC based Offline/Online MUA NNTP (news://news.winserver.com) 7) Support for RFC based Offline MUA POP3 mail pickup Overall, unless the logic is built in to separate, we will be exposing users to potentially harmful mail with any of these online and offline MUA methods. So I guess, if you believe it is a presumed all MDA will separate mail, then maybe your text is sufficient. But that would be a rather large presumption of backend behavior. I am saying we can't automatically assume this design is natural for all backends and for this specific (accept+mark) mode, SPF -ALL protection is lost is separation is not part of the backend mail operations. I really don't know how else I can state it. We can't support ACCEPT+MARK simply because our mail software is not ready for it out of the box. For SPF, a reject mode is the only filter and only for -ALL. If we add a new option for example: SPF-HardFail-Action Reject|AcceptMark # default Reject We will now be force to redesign the software to add different mail bins for users. This is currently being done (sorting) by 3rd party mail bots but we can't depend on them to do this themselves for Received-SPF: fail results. We need to make sure that out of the box, there are no surprises for any of the mail access methods for SPF accept+mark failed messages. It would not be made available and only Reject would be possible until the separation management logic is available. Hope that better explains this. Scott Kitterman wrote: > On Wednesday, August 22, 2012 09:40:25 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-06.txt >> Pages : 66 >> Date : 2012-08-22 >> >> Abstract: >> Email on the Internet can be forged in a number of ways. In >> particular, existing protocols place no restriction on what a sending >> host can use as the "MAIL FROM" of a message or the domain given on >> the SMTP HELO/EHLO commands. This document describes version 1 of >> the Sender Policy Framework (SPF) protocol, whereby an ADMD can >> explicitly authorize the hosts that are allowed to use its domain >> names, and a receiving host can check such authorization. >> >> This document obsoletes RFC4408. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > There is nothing radical in this update, but it seemed like there was enough > change to make it better to publish the latest. This includes many changes > discussed on the list, but not yet the new security consideration that Hector > proposed (Issue #33), since we don't seem to have converged on anything yet. > > I believe that I've addressed all the other recent suggestions for changes. > If I've missed something, please let me know. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Thu Aug 23 21:57: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 A52C621F84E4 for ; Thu, 23 Aug 2012 21:57:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRo1alMgowWq for ; Thu, 23 Aug 2012 21:57: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 AA4F321F84FB for ; Thu, 23 Aug 2012 21:57:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.150]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7O4v3Qq022940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2012 21:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345784234; bh=/28OVNB6P1ivVPI2K5UiV8Bd3thcxf5mgkZW/wzb3Zg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=1DQCHQT+iAbXVIqWd3iAEmSbz0kzfc5LWYpuLVRdaGePLExmhcPisqJSL5pL4q9oM UG5LUZxyPA0KENw54boes+dVK/RMglVL7zwNfM++Sa3ioUOduzo95bjyXzlBG9Yh7r J+dIDSHDoROzk9ufKSgCP8e/5Lfn4hzYqy6YB+2A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345784234; i=@elandsys.com; bh=/28OVNB6P1ivVPI2K5UiV8Bd3thcxf5mgkZW/wzb3Zg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=hIP5Ju0xQ4NhHwI1PdKTYumnUKCe8RL5V35dcx1Ns5UIM3ia01VJ5Mq5jDJ0+YsOb 6RZNNxsBPfJP5SwiwPaoYD65HDHr45RiQZfoCAR8+mmRzZ5z9/m9a2gkvY/wo91YWT AyNv8Ax/4k6cE/azAU8IMH/PdJEQmAgEybZU0jzE= Message-Id: <6.2.5.6.2.20120823214532.095f5458@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Aug 2012 21:56:37 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20086782.TyIbvIWLSl@scott-latitude-e6320> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 04:57:17 -0000 At 15:16 22-08-2012, Scott Kitterman wrote: >For this issue, I think it requires a two step answer: > >1. Is the issue a security issue that should be mentioned in security >considerations Could working group participants please review the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html for information about Issue #33 and comment on the above question? Regards, S. Moonesamy From johnl@iecc.com Thu Aug 23 22:26: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 7054A11E8091 for ; Thu, 23 Aug 2012 22:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.219 X-Spam-Level: X-Spam-Status: No, score=-110.219 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVUxgg3n-WcM for ; Thu, 23 Aug 2012 22:26:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 981C711E809B for ; Thu, 23 Aug 2012 22:26:02 -0700 (PDT) Received: (qmail 55925 invoked from network); 24 Aug 2012 05:26:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 05:26:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50371068.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=oxZZ6eN/ElLx3KAASnoOtKgeRZJDx2n3evX9ujfsof4=; b=hPElxTvwoClUQDeqZi18jejNr5D970dyHxANMnAgl7DczvhdkEjILfhtsonWYFleljdVSlHUErmC+HglrP+qPWDvUODNZ+pBVpN/kf6SOTWdUQND4HVybT5DKi4xUZGkRJFfR/hKJwRkLgfZz2ZVmbR+b8kUaIgxtMI9maSHVNk= 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=50371068.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=oxZZ6eN/ElLx3KAASnoOtKgeRZJDx2n3evX9ujfsof4=; b=k+gWpNVBMDwCmS4HwIZIZOpEEjdpFVhWdBlfVj176YPMf30vFGeGQ2sDlT/2n3OEIIpjl0gvmHRSkgqUjXFyy1AGN8/CXHgSplDbanDekWjxMLNZiJeIJzmb/Yi0UFrkxxY36O7ZzaZYX+5M2dNdCWSe2nli+Rc7Pwr4WaUmj7k= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 05:25:38 -0000 Message-ID: <20120824052538.33851.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120823214532.095f5458@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 05:26:03 -0000 Close it. This proposal is totally ill-advised. R's, John From superuser@gmail.com Thu Aug 23 22:39: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 3E0C821F847A for ; Thu, 23 Aug 2012 22:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcdneI5lZjPw for ; Thu, 23 Aug 2012 22:39:21 -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 7240521F8476 for ; Thu, 23 Aug 2012 22:39:21 -0700 (PDT) Received: by lahm15 with SMTP id m15so939617lah.31 for ; Thu, 23 Aug 2012 22:39:20 -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=9XuoLbWk4UeAz9hT8D/sQyU5zabm7B7KXIrc7BN6xTY=; b=R1/73OYuwl2E+M2wWdmJUco325IQKK4XONdipGdHhlLG2PK82ayT6Awh1HM7LRyUIf 4W9VPFNfXXup8XUzLgsfcuhvYHvHbPFOvCfa8yrNGuO9u0Bngbu8999Sh387Yn3Ny215 Ze/CeVOvhXZFiTUnq0GjBYtllZYAZ+2T+vci3Cmqx0KuNSYTepy3VUTn74eX5rSyPHH8 i0N+2XPYmr5P1RMDFMfQ9pOBEMiuKd/42vAyPjbo1H/FtmRJ1e2+VscUNahSwP+UXxgU iKRfU3lXIy+j/TqgLLZeszyktEaCygRFTwMTRMbFZQKpkGOMfEX+nE5lNJNMW+o7FWUs FL3Q== MIME-Version: 1.0 Received: by 10.152.146.169 with SMTP id td9mr4304602lab.42.1345786760285; Thu, 23 Aug 2012 22:39:20 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 23 Aug 2012 22:39:20 -0700 (PDT) In-Reply-To: <20120824052538.33851.qmail@joyce.lan> References: <6.2.5.6.2.20120823214532.095f5458@resistor.net> <20120824052538.33851.qmail@joyce.lan> Date: Thu, 23 Aug 2012 22:39:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, sm+ietf@elandsys.com Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 05:39:22 -0000 On Thu, Aug 23, 2012 at 10:25 PM, John Levine wrote: > Close it. This proposal is totally ill-advised. I would agree, except Scott's discovery of recommendations for security considerations makes me think the IESG could reasonably expect something like this. In that case, I prefer his one-paragraph response. -MSK From hsantos@isdg.net Thu Aug 23 23:13: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 3C73821F8476 for ; Thu, 23 Aug 2012 23:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIlyzUIES5s3 for ; Thu, 23 Aug 2012 23:13:14 -0700 (PDT) Received: from mail.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6037421F84B9 for ; Thu, 23 Aug 2012 23:13:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1504; t=1345788789; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Qo+WHopf4uBMwUYD0hVFkRqQz/I=; b=A2LYCVUJ1puJZMkt9KRI QlHjIAP0qeTm8WQI1hadmdCqD20+JPtoFkpS5PWYi6V6tEkRfibF8CI2nTXGwmfL zgUbQwGqDokjOhH3BcAavYFuwRUgEUU75zzeIUVZ9E1m7DDz306q7SCFqVwFHKiZ xxSb+eknh35IbiDYSel/8R0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 02:13: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1810584835.2162.5012; Fri, 24 Aug 2012 02:13:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1504; t=1345788595; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bjEQ9h+ Sn88zWodcHMGiqDaZMGKGCy/ftNBEz2o+tfA=; b=l7ahuAi9ZvXtIgfZP285iGD ulHVyxK2BfVxCzFV2RvBD6fW7BusQ2EAcJxVDD+cg3fm/mIlqOdbxMAg0ZoQOtS3 saR5CrQ7277hPGyXeVe4HIc/lJdC65nFoWiUZyhqkSlxBKMmpu1w7nx4qgp8vLNb ProUg/mVQU3e8uWbCE/Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 02:09:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2409393411.9.4888; Fri, 24 Aug 2012 02:09:54 -0400 Message-ID: <50371B86.3070005@isdg.net> Date: Fri, 24 Aug 2012 02:13:26 -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: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> In-Reply-To: <6.2.5.6.2.20120823214532.095f5458@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 06:13:15 -0000 S Moonesamy wrote: > At 15:16 22-08-2012, Scott Kitterman wrote: >> For this issue, I think it requires a two step answer: >> >> 1. Is the issue a security issue that should be mentioned in security >> considerations > > Could working group participants please review the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html for > information about Issue #33 and comment on the above question? > > Regards, > S. Moonesamy 4408/BIS offers a mode of operation for -ALL that is not a rejection, but accept+marking the message. This negates the intent of the domain to negatively treating the message with an RFC2119 MUST requirement of using -ALL. If the SPF receiver backend does not separate this accept+marked message, a) the user is now at risk of receiving harmful mail deemed unauthorized by the domain owner, b) the domain reputation is potentially harmed, c) the receiver abuse is increased. If section 2.5.4 does not provide the semantically equivalent rejection form of accept+marking the message, then we have a security loophole and issue and it needs to be mentioned in the security consideration section. In addition, to not consider it a security issue, the accept+marking mode for SPF failed results presumes a backend mail design where mail separation already exist. Either way, the concept of separation for failed messages need to be described in 4408BIS to make implementators aware of the situation. -- HLS From WebMaster@Commerco.Net Thu Aug 23 23:21: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 808D021F8577 for ; Thu, 23 Aug 2012 23:21:33 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90ob6zBnPPaQ for ; Thu, 23 Aug 2012 23:21:32 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id ABF1011E80A5 for ; Thu, 23 Aug 2012 23:21:32 -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=XiJ/9unmNGdp/PKS/jexKwvgbIA9Y8z7/O4oU0+08j4zO/C8fjq42W6hx8dTwe0yIo/dXxiwXjpMT8xeZ8Ahg7h349OfGATJ5eeSGwpBwI3cBsC4JhNV9/223Trut41ByhXrZBJ3GgswIjZKCYr9fNR78BuXJ9c7m30NV9BdHVc= 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, 24 Aug 2012 06:21:30 +0000 Message-ID: <50371D64.4040400@Commerco.Net> Date: Fri, 24 Aug 2012 00:21:24 -0600 From: Commerco WebMaster 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@ietf.org References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> In-Reply-To: <6.2.5.6.2.20120823214532.095f5458@resistor.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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 06:21:33 -0000 On 8/23/2012 10:56 PM, S Moonesamy wrote: > At 15:16 22-08-2012, Scott Kitterman wrote: >> For this issue, I think it requires a two step answer: >> >> 1. Is the issue a security issue that should be mentioned in security >> considerations > > Could working group participants please review the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html for > information about Issue #33 and comment on the above question? > > Regards, > S. Moonesamy > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > The spirit and intent of the text seems correct. Remembering that a primary goal for SPF is to protect a domain holder's domain reputation when a third party uses the domain name without the domain holder's permission, perhaps an easier way to express that spirit and intent might look like this: ---- When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record and the result of a receiver MTA's SPF processing is an SPF FAIL, the receiving MTA (or any downline MTAs to which it or its successive forwarders must forward messages by reason of the receiver's local policy [e.g., downstream antispam analysis machines, DMARC implementers, etc.]) MUST NOT allow the message to ever reach the MUA(s) of the final RCPT TO address(es) in the message under any circumstance (i.e., the final mail recipients MUST NOT ever receive messages which fail SPF -ALL processing), nor should such -ALL SPF FAIL messages ever be used to impugn the reputation of the domain publisher. ---- I think that the above leaves very little to the imagination as to what the publisher intended in implementing SPF, while simultaneously allowing a receiver a huge amount of latitude as to what they can do with the messages (pretty much anything) as long as they don't deliver the failed SPF -ALL message to the end point receiver(s) or cause reputation harm to come to the SPF publisher's domain reputation from a failed SPF -ALL message event. Alan M From superuser@gmail.com Thu Aug 23 23:50:29 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 A0D7721F850B for ; Thu, 23 Aug 2012 23:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJiR5K8JVRsf for ; Thu, 23 Aug 2012 23:50:24 -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 65F0721F8508 for ; Thu, 23 Aug 2012 23:50:24 -0700 (PDT) Received: by lbky2 with SMTP id y2so161764lbk.31 for ; Thu, 23 Aug 2012 23:50: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 :cc:content-type; bh=+TlOzZrs9ZTpd1RPvzNLXKGDnhU6NWunnFha1Ux1XEI=; b=diZsAtrJ+TQ1HNTrnNq8gEDjOiYI/ag6l9dgSTqDnt3AfcTPYIKSdjPW8YeMLRS3ry 38QhQ03GfRjnm6az19PS1nZLwKSksQsbBSXpgPICukEYxxSM0v/Vyab3OTQ3ZzIMK/3j QwFhFmL1KPipEvxd9yNpngKNKRrLKy+zkkGR62EvuIIUZheYz1sb4U8gqdS3rrnhYWSd wOfJhYY3ILHxBCZ4dZNtc86s+/wO7ZvnGqpHHvFW1rHuyfByqR4k47e6BWXUqubeD+ev 4xqTdIWHzkDQRcxLW+bBui2fUWLSw3ggi3vJmqtmV9onsVq7joQ4UK+6Z6FyLXJhqIwY p5Yg== MIME-Version: 1.0 Received: by 10.152.130.3 with SMTP id oa3mr4534301lab.27.1345791023150; Thu, 23 Aug 2012 23:50:23 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 23 Aug 2012 23:50:23 -0700 (PDT) In-Reply-To: <50371D64.4040400@Commerco.Net> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> Date: Thu, 23 Aug 2012 23:50:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 06:50:30 -0000 Alan, On Thu, Aug 23, 2012 at 11:21 PM, Commerco WebMaster wrote: > When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record and > the result of a receiver MTA's SPF processing is an SPF FAIL, the receiving > MTA (or any downline MTAs to which it or its successive forwarders must > forward messages by reason of the receiver's local policy [e.g., downstream > antispam analysis machines, DMARC implementers, etc.]) MUST NOT allow the > message to ever reach the MUA(s) of the final RCPT TO address(es) in the > message under any circumstance (i.e., the final mail recipients MUST NOT > ever receive messages which fail SPF -ALL processing), nor should such -ALL > SPF FAIL messages ever be used to impugn the reputation of the domain > publisher. This flies in the face of all of the discussion about SPF being input to a larger message evaluation system and basically says that SPF "fail" wins over everything. Even RFC4408 didn't go that far. It gives no consideration to false negatives, which is the main reason lots of operators don't treat a fail with "-all" as gospel already. It doesn't even permit delivery to spam folders in that instance. -1 from me. -MSK From hsantos@isdg.net Fri Aug 24 00:24: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 199B021F86A4 for ; Fri, 24 Aug 2012 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPRz1GgQh8iB for ; Fri, 24 Aug 2012 00:24:11 -0700 (PDT) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CC21F8494 for ; Fri, 24 Aug 2012 00:24:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=901; t=1345793044; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/n7Sxxa9JE4QRp9ECQSZz+UaDLM=; b=g9X9DbW5/rQZFPWWeaS2 Api6zcitaRty5UKphZ7CACyS1EcmZtl3E4mKmu/F+6E6vhL0q+xRnMzXcUkM0IPd c/TVlbEeuPXrzoRC2Dm40vIDMZdimjSuPvvELgSyCvZAWmngkiWCOk30e4GrFzYw TiXOXgCvmHts9A0FQgN2TLU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 03:24:04 -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 1814840168.2162.2340; Fri, 24 Aug 2012 03:24:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=901; t=1345792849; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VXzy+Ic e/qEpHg7PVKwrwe06YK9lY+yESLOUXrITldo=; b=1bc7qoH/Qu9qZAloHhbBpp3 OjgN8t6do+CvAgRgvnsa7MQrPS7kWMZgt9gBi4DfL47z0VIxzHrlBriaOQowCptk 68W9muOVuQNGYtNSViRiQ8V3jzB0cWDNjEW6GfgdD6kZ13wbdD/vrQceduPJTzyQ 6ztrpWOXE1qXnmZAtxHk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 03:20:49 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2413647145.9.5408; Fri, 24 Aug 2012 03:20:48 -0400 Message-ID: <50372C24.1000709@isdg.net> Date: Fri, 24 Aug 2012 03:24:20 -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: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 07:24:12 -0000 > This flies in the face of all of the discussion about SPF being input > to a larger message evaluation system and basically says that SPF > "fail" wins over everything. Even RFC4408 didn't go that far. RFC4408 section 2.5.4: A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright. No other factors or additional add-on message eval system technology required. Reject the mail outright is the easiest solution. Accepting and marking the mail is a much more complex implementation concept which may begin to support advanced msg eval systems you speak of, however, in lieu of it, we have a security issue implementations need to have design insights for. What is the harm in this security consideration? -- HLS From WebMaster@Commerco.Net Fri Aug 24 01:00: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 0C60D21F86C4 for ; Fri, 24 Aug 2012 01:00:00 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfWzKuBobbLF for ; Fri, 24 Aug 2012 00:59:59 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4469E21F86C3 for ; Fri, 24 Aug 2012 00:59:59 -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=AMZwdUaPnpyOjWN1yBAb/sFS3vcLnVRcG3iaiW2F23GZ/Fqc99xPfsxmplTNgpY7gujeTW0tYpWx1sS6sRhNUo6b3EJK99CGib4kkOPL8RZVLwL/F7C+AbPFW2FMzVnUlXSzM2+jg4ZJdixr65Wh8Puq4htpy/klkL/bppyu4D8= 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]); Fri, 24 Aug 2012 07:59:52 +0000 Message-ID: <50373472.1000705@Commerco.Net> Date: Fri, 24 Aug 2012 01:59:46 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 08:00:00 -0000 Murray, On 8/24/2012 12:50 AM, Murray S. Kucherawy wrote: > Alan, > > On Thu, Aug 23, 2012 at 11:21 PM, Commerco WebMaster > wrote: >> When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record and >> the result of a receiver MTA's SPF processing is an SPF FAIL, the receiving >> MTA (or any downline MTAs to which it or its successive forwarders must >> forward messages by reason of the receiver's local policy [e.g., downstream >> antispam analysis machines, DMARC implementers, etc.]) MUST NOT allow the >> message to ever reach the MUA(s) of the final RCPT TO address(es) in the >> message under any circumstance (i.e., the final mail recipients MUST NOT >> ever receive messages which fail SPF -ALL processing), nor should such -ALL >> SPF FAIL messages ever be used to impugn the reputation of the domain >> publisher. > > This flies in the face of all of the discussion about SPF being input > to a larger message evaluation system and basically says that SPF > "fail" wins over everything. Even RFC4408 didn't go that far. It > gives no consideration to false negatives, which is the main reason > lots of operators don't treat a fail with "-all" as gospel already. > It doesn't even permit delivery to spam folders in that instance. > > -1 from me. > > -MSK I think that I can understand why you might feel that way, however, SPF does allow other options for publishers who wish to use it in a less publisher centric absolute manner (e.g., ~ALL). Obviously some folks do and will get their configurations wrong, but is it really the role of a standards group working on a standards draft to account for every misconfiguration (unintended or otherwise) in a standard? In other words, the punishment for publisher misconfiguration perhaps should be that things won't tend to work very well for the publisher with incorrectly configured SPF TXT records. Generally, that sort of thing is almost always adequate to get folks to fix their published records. I suppose my view comes from the publishers standpoint, in that I became a proponent of SPF all those years back specifically because it featured a real method to absolutely confirm that a published domain can absolutely be scored as, "if you received a message from our domain, it was not authorized and you should know it did not come from here" - in other words: "v=spf1 -all" A receiving MTA should toss anything coming in that way from a domain publishing the above. If the publisher wants to get feedback, I believe that our editor, Scott Kitterman, has a nice RFC out there to handle that. Or, if I specify that only certain machine IPs are allowed to send mail for a given domain through publishing an SPF TXT record for the domain and the receiving MTA finds that the sending MTA is not in that IP set, I can depend upon the mail to not get through. That is part of the overall appeal for SPF publishers, at least this one, as it protects the reputation of a domain, by respecting the intent of the domain holder who publishes a -ALL style SPF TXT record for the domain under their control. Put simply, in publishing with -ALL, I would rather not have some interpretive algorithm attempting to understand my intent as a SPF publisher. Instead, I'd prefer a receiver to just simply respect the -ALL and go from there. If a receiving MTA Fails in a -ALL, it should return something to the sender about their not being allowed (e.g. a 5xx error of some kind as I recall). If there is an SPF publisher misconfiguration, then logically, the sender should see it as a function of their MTA being told "no" by the receiver. I am completely okay with ~ALL implementations being subjected to whatever receiver "interpretation of intent" receivers may choose to do, however I think that -ALL really should be an absolute expression of a domain holder SPF publisher's will, where it comes to an -ALL SPF "fail" and receivers should respect that publisher's will. Alan M From vesely@tana.it Fri Aug 24 01:21: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 0EED321F86E5 for ; Fri, 24 Aug 2012 01:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgjRQCTPktkd for ; Fri, 24 Aug 2012 01:21:26 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 31D5021F86D7 for ; Fri, 24 Aug 2012 01:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345796484; bh=Ap4yz+XrcXYsoXFan02hj6MRRh72O8FJBPTyu4O2a4I=; l=553; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kcEAOQh58LZKXS38nf2a9XdgynRCWkCDTgJ517CEJoBXtaTZ6MHFI79bCP1dUKUW5 gMzRqzOsVeE8OCSHUET/IyTrmDeN5UffaCmPpPUDeIkHhzz6gjvscJhCBjIc0bV7bB fjevnTnJ9jmDqSZXVDEHBOLOQAWprXAiJEgICAiU= Received: from [109.115.207.169] ([109.115.207.169]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 24 Aug 2012 10:21:22 +0200 id 00000000005DC039.0000000050373983.00003E6D Message-ID: <50373979.9080502@tana.it> Date: Fri, 24 Aug 2012 10:21:13 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120821094204.0a268cd8@resistor.net> <4042906.FYNB9DcbUd@scott-latitude-e6320> <5035EF1F.1040009@tana.it> <55f88fb0-30a7-47d1-b5e6-173891071742@email.android.com> <503678B1.40306@tana.it> <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> In-Reply-To: <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 08:21:27 -0000 On Thu 23/Aug/2012 21:45:06 +0200 S Moonesamy wrote: > > "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." > [...] > > I would be picky about the "checking software". :-) If that means to s/checking software/server/, I agree. And there is a lowercase "should" further down, right before the example, that should be capitalized. From vesely@tana.it Fri Aug 24 02:18: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 A05AE21F860E for ; Fri, 24 Aug 2012 02:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYwq-UwOLz0z for ; Fri, 24 Aug 2012 02:18:50 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4221F8688 for ; Fri, 24 Aug 2012 02:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345799929; bh=3hOrFpZs9dO9Ps992Tc2cbcd4QBSrE3D9NCgJndCKfI=; l=496; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DOG5HX7LcwNZ/JxJshGTs5r2BJDBlzBno+Az9YMxJwrTIhLpDRyWxiYqlewo0fQjv C5M7MBJOuMSgaMPZPl4RbY5VEGzXh4GlX9Pz0sW8On97HxNzfInab4LuwppCSwFDZ8 q3/bW2DV5NEqPJfhMA+DQ906IPT/zZ9Glz5mH33Y= Received: from [109.115.207.169] ([109.115.207.169]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 24 Aug 2012 11:18:47 +0200 id 00000000005DC035.00000000503746F8.00004B4F Message-ID: <503746ED.1040607@tana.it> Date: Fri, 24 Aug 2012 11:18:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120823214532.095f5458@resistor.net> <20120824052538.33851.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 09:18:50 -0000 On Fri 24/Aug/2012 07:39:20 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 23, 2012 at 10:25 PM, John Levine wrote: >> Close it. This proposal is totally ill-advised. > > I would agree, except Scott's discovery of recommendations for > security considerations makes me think the IESG could reasonably > expect something like this. In that case, I prefer his one-paragraph > response. +1, however ill-advised the assumption that a downstream agent might know better. From sm@elandsys.com Fri Aug 24 02:26: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 0D46A21F86AD for ; Fri, 24 Aug 2012 02:26:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N5Sjia1yTAo for ; Fri, 24 Aug 2012 02:26: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 5E1D721F86AB for ; Fri, 24 Aug 2012 02:26:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.150]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7O9Q8tO000440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 02:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345800382; bh=95/jnro7YHv0zNzJLwmNZQYloJa4auYQUD3FEQHA9/c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cs0j8dn8QVXXq9c/7b4JDPkL7Ta+cCVVT7J3A0gusrx8wbYu8RUr3f+SZSU9dbcMc p+4eVYyc6s1xNYS2opijSb7AUY4UlmvpZe98RBK9+u2DXLVzuNAZRSu+QcGzr/EG+J q9NtRQ5nrRYKrnkNblUMTYs+xhe3VdO5hPf0ulu4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345800382; i=@elandsys.com; bh=95/jnro7YHv0zNzJLwmNZQYloJa4auYQUD3FEQHA9/c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W2vKYzD/2l/ZTCiRkYb4TmV5URPicT3PxLEielPLNW5tKnXS8z2fHTV6gXEuTZ1M7 BTMPjx0/vcl/X68O/LeJruSRin0Geq0Z1/wXcYjI0ZkRG8wUf0tVURBCHE7NPsw2U2 /DZ6x/M6PkHYuSPLI1uatHnA0dUSX0wZAnKk+1Dc= Message-Id: <6.2.5.6.2.20120824013510.08fb4170@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 02:25:15 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120222162826.GA36084@crankycanuck.ca> References: <4F4503B1.6000202@isdg.net> <1421922.FmWU0zJib9@scott-latitude-e6320> <4F450EB2.4040305@isdg.net> <20120222162826.GA36084@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] WG comportment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 09:26:25 -0000 Dear SPFBIS WG, At 09:28 22-02-2012, Andrew Sullivan wrote: >For this WG to be productive, we must all >discipline ourselves to ensure that our emotions do not get the better >of us, and your chairs will step in at the first sign that the >conversation is crossing that line. Remember, too, that email does >not come with all of the additional clues that in-person communication >does; please write accordingly. If you are inclined to send a >message, consider it twice before sending: sometimes an argument can >be made at once more neutral and technically stronger. Finally, we >very strongly oppose direct personalization of the discussion; please >don't do it. I would like to remind you of the above advice. Inappropriate behavior will not be tolerated. Regards, S. Moonesamy SPFBIS WG co-chair From vesely@tana.it Fri Aug 24 03:29: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 4B56921F8581 for ; Fri, 24 Aug 2012 03:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNd8uGEP49Z4 for ; Fri, 24 Aug 2012 03:29:18 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72D21F8609 for ; Fri, 24 Aug 2012 03:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345804156; bh=eXU7hsq/Jk5TKObgImClRkSXnckVfyOM5e2D6yxZTjs=; l=1466; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GfTr/Z1hJt3qOky2GonSVL9AbhJaZl3dtkXklpgfpR0xtZW2B9vrGbMbd8vw5ErcO PlPYIeMKfejd371Ef+q5PpnCyCh45yG7P58DhakShWABUlrsHvcKYWzbogGS5O8Eud bS5jnke2FrBasIp1lEf3MJRFJA2EKLZWfwseF6TQ= Received: from [109.115.207.169] ([109.115.207.169]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 24 Aug 2012 12:29:13 +0200 id 00000000005DC039.000000005037577A.00005AFD Message-ID: <50375769.5000308@tana.it> Date: Fri, 24 Aug 2012 12:28:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@Commerco.Net> In-Reply-To: <50373472.1000705@Commerco.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 10:29:19 -0000 On Fri 24/Aug/2012 09:59:46 +0200 Commerco WebMaster wrote: > > Put simply, in publishing with -ALL, I would rather not have some > interpretive algorithm attempting to understand my intent as a SPF > publisher. Instead, I'd prefer a receiver to just simply respect the > -ALL and go from there. The protocol delivers a result for a given input. A result of "fail" is "fail", irrespectively of which mechanism yielded that result. Bullet 1, part 1, Section 9.2.2 of the current I-D gives an example where one can get a "fail" with ?all: "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" I don't think that a failure originating from there should be treated any differently than one resulting from a -ALL. That said, SPF aims at domain name abuse, and allows legitimate forwarding. It considers a forwarding to be legitimate when it occurs either on the sender's or on the receiver's side. It doesn't take into account "spontaneous" forwarding, from a mailbox to another one without advice. That's illegal in many countries, but privacy laws provided no protocol to ease abiding by them. Nevertheless, we have to cope with that. While respecting the intent of the domain holder, a receiver can recognize that a sender is (temporarily) part of its network, inasmuch as it is relaying a good message --thereby promoting the use of receiver's services in preference of its own ones. That's what receiver policies are all about. From johnl@iecc.com Fri Aug 24 10:10: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 E1C4421F867D for ; Fri, 24 Aug 2012 10:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.139 X-Spam-Level: X-Spam-Status: No, score=-111.139 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8tTTdZOYkgG for ; Fri, 24 Aug 2012 10:10:14 -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 CAB6321F861D for ; Fri, 24 Aug 2012 10:10:13 -0700 (PDT) Received: (qmail 80904 invoked from network); 24 Aug 2012 17:10:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 17:10:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5037b573.xn--hew.k1208; i=johnl@user.iecc.com; bh=rQiFjJTjgfwegIygUpawg4OjR+BZ6E0uKdkhn6CXsXY=; b=ifJXE2uWLgv+IbYAWh55GxMxVKrZVVeD74GK+4xcLt7A28d3ROq9EVvofBWpgjoIcECiuSuYuChVGuPjO1g/fdvZW76kqwNEBM8Krq53IWi4K5SD1Lx4OJd6Okr8OWBLyLyFc10bUnMmi7fLBZazDFnUbe24rBG0V6uEBeFOrN8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5037b573.xn--hew.k1208; olt=johnl@user.iecc.com; bh=rQiFjJTjgfwegIygUpawg4OjR+BZ6E0uKdkhn6CXsXY=; b=S5MEmFsr6PqSP7Jqf8MFkPmz2pF/Ulfpeej9LNHl+KRYFL4s7eVZFpY/OS1/t11moIPpOY/W6uhJrnNaLbz9gLljwI1v0kYpNFpc+/ptldkvNRg5IjlDcUTOaEiE8lRYdp4yWclKMirnpYMJDuRHEf9OzvzbnQKdatD/3pK3mwc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 17:09:48 -0000 Message-ID: <20120824170948.6799.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1476027.UdxMWrdmeL@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:10:15 -0000 > Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5. For implementations that > support Internationalized domain names, such domains MUST be > encoded as A-labels, as described in Section 2.3 of [RFC5890]. In case it's not obvious, you don't need to support EAI to use A-label domains. It's reasonable advice to everyone to note that non-ASCII domains must be encoded as A-labels in DNS queries. On the other hand, since EAI is now on the standards track, I'm a little confused about why we wouldn't want to add the two sentences needed to say how to support it. (Domains are turned into A-labels whenever used for DNS lookups. Local parts are what they are and can cause surprises, same as now.) R's, John From johnl@iecc.com Fri Aug 24 10:38:54 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 524BF21F872A for ; Fri, 24 Aug 2012 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.14 X-Spam-Level: X-Spam-Status: No, score=-111.14 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19BXVebUKufl for ; Fri, 24 Aug 2012 10:38:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 467C621F8613 for ; Fri, 24 Aug 2012 10:38:53 -0700 (PDT) Received: (qmail 86373 invoked from network); 24 Aug 2012 17:38:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 17:38:51 -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=5037bc2b.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=JX1Tx4n5VGUE9g5CuIfjm4Oz2WnIgR6n3atwNFmstGc=; b=u8KBVerPTlZJMWK/rtAn7nZJq8pI5HcqFeFbjITmgl7YeMarr31tiBQqa82nD7zK/kOvn0UrSzMwNSTsWS7RQKTv3bvWV09bu4XsulIvQHuHT8n6gvRAhlOzVwts5dCa6zHg8d5bwYu5o8f9PylMSVTQMIKLrtTOplLQiUWgzgM= 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=5037bc2b.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=JX1Tx4n5VGUE9g5CuIfjm4Oz2WnIgR6n3atwNFmstGc=; b=SkI5wIY/QZvgFtPeIjrJUeL6gQpNS90k6HWcvpukxe0G29trjIP++DNYstt6C/YnJFWjH/bOBCNTJ95sks4/CsskvBywrxsuczYRQDrW76HS0UpSGc9k37WQDc+XnDY6jyYz9wF7Ill5TEGW4QZDFD6d/1uU3z/iHVm9qxAkn+Y= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 17:38:29 -0000 Message-ID: <20120824173829.13742.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <50371D64.4040400@Commerco.Net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:38:54 -0000 >When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record >and the result of a receiver MTA's SPF processing is an SPF FAIL, the >receiving MTA (or any downline MTAs to which it or its successive >forwarders must forward messages by reason of the receiver's local >policy [e.g., downstream antispam analysis machines, DMARC implementers, >etc.]) MUST NOT allow the message to ever reach the MUA(s) of the final >RCPT TO address(es) in the message under any circumstance (i.e., the >final mail recipients MUST NOT ever receive messages which fail SPF -ALL >processing), nor should such -ALL SPF FAIL messages ever be used to >impugn the reputation of the domain publisher. No. This proposal is equally ill-advised. SPF is about defining a way for mail-sending domains to publish policies about sending hosts, and for recipient systems to find out what a domain's policy is about a particular host. It is most definitely not about MUA design, or what a recipient system does with the policy information it has available. R's, John From johnl@iecc.com Fri Aug 24 10:40: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 809B421F8613 for ; Fri, 24 Aug 2012 10:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.14 X-Spam-Level: X-Spam-Status: No, score=-111.14 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwSHGcnOc5yk for ; Fri, 24 Aug 2012 10:40:22 -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 9C29321F8611 for ; Fri, 24 Aug 2012 10:40:21 -0700 (PDT) Received: (qmail 86528 invoked from network); 24 Aug 2012 17:40:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 17:40:19 -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=5037bc83.xn--9vv.k1208; i=johnl@user.iecc.com; bh=a6yZl1qclen9t0NZLSMHXM+0oZIrFCMTB9Y0qrrOdn0=; b=DpAQHy9tcdyJzEANaRu7vyLdgfKwdR1JoovBWf+KNdb2MmJWO5/sY7AF4Ur/Dwyh1k5QcwLXBSYnOGHzpvf+ulNZWWmnJrEM72/qNWm3YnuDCJ5aysKPxZYXMHSHLm52/FWXMfpAlvQBmhwfiS6u5dXw/Lr1kl1a0uu+egx7Lms= 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=5037bc83.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=a6yZl1qclen9t0NZLSMHXM+0oZIrFCMTB9Y0qrrOdn0=; b=zdPk9bPuVlpJvprmufAydMNN5CAh/dFRuv/3EmOeHn2KsH35HVvv6qu3DOy0bAvPeZFV4CPf2ldb/4YoNIXlrRVUb2vv2ctez8o5JGIb7nwwOoPPT02z0AZxTVuAGjmGQgbmPqwh+CnHabGibNraoOoOXF+GDCEetzHCHfQJH2I= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 17:39:57 -0000 Message-ID: <20120824173957.14118.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <50373472.1000705@Commerco.Net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:40:22 -0000 >A receiving MTA should toss anything coming in that way from a domain >publishing the above. ... No. This specific proposal has been rejected innumerable times in the past. I cannot imagine why anyone would bring it up yet again. R's, John From superuser@gmail.com Fri Aug 24 10:41: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 69FEA21F871E for ; Fri, 24 Aug 2012 10:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkAmpJuz+Pjt for ; Fri, 24 Aug 2012 10:41:45 -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 493BE21F86BE for ; Fri, 24 Aug 2012 10:41:45 -0700 (PDT) Received: by lahm15 with SMTP id m15so1356235lah.31 for ; Fri, 24 Aug 2012 10:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K50qqUDxDCl1pQF9tdDjG2PWoKdCZV2TvrkdX+5vpJE=; b=D/m0vut+RmqglND//bL6pBHnuVNZG7+a07QIFeyuauZm4tRkrGwAJjHUOzwnm+Vza9 Tu2sL1gKZF/Fg6TFv/boTr9uHyb9jfbSboPJXI6/uvMbzam1DCrnPs6Eab/WGq5VtOYH iLxSbMlDZAC6vwRD54807Vcz0KopO136F+RwwmYqoZEdjRm+hjV0JvLHlkqYDWO2ij2j yfdyISRQuNP9miqaNzev8cXLBYHI8u9gI5oFNURJ8IeLKO1CSV5yi0KnACndwjdX9Hv8 63X/c31ZbpT4+0951XIjYMPjPuVgrhLlSdJbQwZQEkTHZWTvAs1rrhcmRNkySLsiEfRM MFdw== MIME-Version: 1.0 Received: by 10.112.37.102 with SMTP id x6mr2978050lbj.66.1345830104178; Fri, 24 Aug 2012 10:41:44 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 24 Aug 2012 10:41:43 -0700 (PDT) In-Reply-To: <50373472.1000705@Commerco.Net> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@Commerco.Net> Date: Fri, 24 Aug 2012 10:41:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:41:46 -0000 On Fri, Aug 24, 2012 at 12:59 AM, Commerco WebMaster wrote: > I think that I can understand why you might feel that way, however, SPF does > allow other options for publishers who wish to use it in a less publisher > centric absolute manner (e.g., ~ALL). > > Obviously some folks do and will get their configurations wrong, but is it > really the role of a standards group working on a standards draft to account > for every misconfiguration (unintended or otherwise) in a standard? Of course not, but it is also not the place of a standard to disregard obvious failure modes, especially when those involve third parties not involved in the protocol. Some examples come to mind: User A sends to user B, who has forwarding arranged to address C. Said forwarding leaves the envelope sender unmodified. Upon receipt at C, SPF evaluation is performed. Of course, the MTA at B is not authorized to send mail for A, so SPF fails and the message bounces. Under your vision for SPF, in essence, A must ensure that it will never send mail to anyone that might set up mail forwarding. I suggest that's an unreasonable burden. User A sends to list B, which relays to C (among others, as C is subscribed) without changing the envelope. (Historically, some MLMs acted that way.) B observes the bounce, and ultimately unsubscribes C as a bad address. C, whose only crime is to participate in SPF and subscribe to list B, is now kicked off the list through no fault of its own. (This scenario is admittedly much more visible under ADSP.) The only way to avoid this is to ensure that nobody at A ever subscribes to a list. I suggest that's also unreasonable. There are many companies that solve this by having one domain for users and a different domain for critical transactional stuff, but most of them dislike having to do that. User A sends to B which forwards to C. C rejects due to SPF failure. B is doing the forwarding inline, so it also rejects. A now thinks B is a bogus address when in fact it is not. This is a variant of the first case, which means A can't ever send mail to anyone that forwards. The notion of demanding that fail + -all = reject also contradicts some well established principles that local policy is local policy and cannot be legislated by any standards action; it belongs solely to the ADMD. Moreover, given two receivers, one of whom does strict "-all" rejection and one that is softer and has a wider evaluation policy, people will vote with their feet when one of these failure modes hits on legitimate mail and move to the more comprehensive policy provider. (The more strict site will be perceived as "broken".) It then becomes a business decision not to be strict regardless of what's in the protocol. (Admittedly, this is also why there's very weak enforcement of mail format standards, but that's for another discussion.) The protocol has to accept such realities. -MSK From johnl@iecc.com Fri Aug 24 10: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 4E6BA21F8720 for ; Fri, 24 Aug 2012 10:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.141 X-Spam-Level: X-Spam-Status: No, score=-111.141 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0oncX+q+WZR for ; Fri, 24 Aug 2012 10:41:59 -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 0B5DE21F8691 for ; Fri, 24 Aug 2012 10:41:58 -0700 (PDT) Received: (qmail 86804 invoked from network); 24 Aug 2012 17:41:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 17:41:58 -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=5037bce6.xn--hew.k1208; i=johnl@user.iecc.com; bh=FcXiX87D4OoL+jvdBeoOtm7JZN7Ad70LEfJuEfYr7mI=; b=sjr8eabFuDUPQXBBOE7P2Lo+j+rWOV61eZw6jGfLB1T9hKX+FSKyk5U3zOAPYP+9ctjWJ4NlKOaZt5STjNSKwN1nEO1ZhK8QioCM1KFU3Nhn6IisW4D5ZXeH8IwBKA/3ofdjGJweXfXLh0k3Zb3Fx9o1m6u8DgY/mB3JJawV440= 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=5037bce6.xn--hew.k1208; olt=johnl@user.iecc.com; bh=FcXiX87D4OoL+jvdBeoOtm7JZN7Ad70LEfJuEfYr7mI=; b=tqUXcGFvYtjO4Be1LHjZXf8kq3lHh0bmOL9A9E978c4zyOeWmscSewW4C0jh+lBf93bHAaDyh3J/unmibT5571j2y2lxsG+nQYYuyam6Lst4WkKAwcmvw2V8nkEZhMcvGPc19WvDUrxpeCanLc9CKcbds8Z1l6pEOZSOyaexhVg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 17:41:36 -0000 Message-ID: <20120824174136.14534.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <50366154.5010100@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:42:00 -0000 >An alternative is http://www.spamhauswhitelist.com/. Is that better? Hi. I run the Spamhaus Whitelist and I would strongly object if this document mentioned it or any other specific DNSWL or DNSBL. R's, John From ajs@anvilwalrusden.com Fri Aug 24 10:54: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 B64F321F855E for ; Fri, 24 Aug 2012 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3DwexIdHWF2 for ; Fri, 24 Aug 2012 10:54:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 315B921F8613 for ; Fri, 24 Aug 2012 10:54:22 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 149448A031 for ; Fri, 24 Aug 2012 17:54:21 +0000 (UTC) Date: Fri, 24 Aug 2012 13:54:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120824175418.GH60243@mx1.yitter.info> References: <1476027.UdxMWrdmeL@scott-latitude-e6320> <20120824170948.6799.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120824170948.6799.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 17:54:22 -0000 On Fri, Aug 24, 2012 at 05:09:48PM -0000, John Levine wrote: > In case it's not obvious, you don't need to support EAI to use A-label > domains. It's reasonable advice to everyone to note that non-ASCII > domains must be encoded as A-labels in DNS queries. No hat: It's flat-out false that non-ASCII domains must be encoded as A-labels in DNS queries, so I don't see why we ought to start advising that. What _is_ true is that the specification for SPF says the "character content of the record is encoded as US-ASCII". If what you want to say is that SPF is defined only for DNS names conforming to the preferred syntax of section 2.3.1 of RFC 1035 or section 3.5 of RFC 1034 (or both), say that. In general, I think we should restrict ourselves narrowly to the protocol itself (i.e. the publication and interpretation of SPF records) and leave alone other things, such how to publish or look stuff up in the DNS, what to do with a mail when you've done SPF processing, and so on. > On the other hand, since EAI is now on the standards track, I'm a > little confused about why we wouldn't want to add the two sentences > needed to say how to support it. Speaking as chair, we wouldn't want to do that because it doesn't fall under any of the restrictions in our charter: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. also Specifically out-of-scope for this working group: […] * Extensions to the SPF protocols. If there are enhancements to be developed, we should put them on a TODO list so that they can be considered in case the WG wants to recharter to take them on. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Fri Aug 24 10:57: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 588C521F86D4 for ; Fri, 24 Aug 2012 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CIGGTSibmZM for ; Fri, 24 Aug 2012 10:57:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E17D421F868A for ; Fri, 24 Aug 2012 10:57:23 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7OHvNZ5026469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Aug 2012 10:57:23 -0700 Message-ID: <5037C07B.2010005@dcrocker.net> Date: Fri, 24 Aug 2012 10:57:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Kitterman References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@scott-latitude-e6320> <5035A047.1030604@isdg.net> <2267574.6GQXnqNoLg@scott-latitude-e6320> In-Reply-To: <2267574.6GQXnqNoLg@scott-latitude-e6320> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 24 Aug 2012 10:57:23 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure 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, 24 Aug 2012 17:57:25 -0000 On 8/22/2012 8:31 PM, Scott Kitterman wrote: > SPF is an MTA to MTA protocol. I don't think it's appropriate to include an > MUA design missive in the security considerations. I think it's enough to > document the consideration and let MUA designers deal with it appropriately. +1. Very nicely stated. In fact, I think that putting the sentence "SPF is an MTA to MTA protocol." into the document -- probably Intro -- would be useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Aug 24 11:03: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 A1A1121F8549 for ; Fri, 24 Aug 2012 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGUwHBq6ZyGD for ; Fri, 24 Aug 2012 11:03:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0F21F85FF for ; Fri, 24 Aug 2012 11:03:16 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7OI33Be026595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Aug 2012 11:03:03 -0700 Message-ID: <5037C1CF.40006@dcrocker.net> Date: Fri, 24 Aug 2012 11:02:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120823214532.095f5458@resistor.net> <20120824052538.33851.qmail@joyce.lan> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 24 Aug 2012 11:03:03 -0700 (PDT) Cc: spfbis@ietf.org, John Levine , sm+ietf@elandsys.com Subject: Re: [spfbis] #33: Marked Failed Mail Exposure 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, 24 Aug 2012 18:03:17 -0000 On 8/23/2012 10:39 PM, Murray S. Kucherawy wrote: > On Thu, Aug 23, 2012 at 10:25 PM, John Levine wrote: >> Close it. This proposal is totally ill-advised. > > I would agree, except Scott's discovery of recommendations for > security considerations makes me think the IESG could reasonably > expect something like this. In that case, I prefer his one-paragraph > response. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Fri Aug 24 11:06:29 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 42B9A21F859B for ; Fri, 24 Aug 2012 11:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QtTPFKEMg0t for ; Fri, 24 Aug 2012 11:06:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1388D21F8577 for ; Fri, 24 Aug 2012 11:06:21 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 10056D0408D; Fri, 24 Aug 2012 13:06:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345831580; bh=M5XCH/63HLFyTe+/Oi6nE1qIQibZ4Lpjc+AXjb1WvvE=; h=References:In-Reply-To:Subject:From:Date:To:CC:From; b=F2BQP20pimuBi9kWnhD3D89kHJc2SXMo86GOLsv6B8KTDJ/+sc+upngci6/I/sVLM wRsiFfe5C1O403ZyTZ4UkNSRxvrUBhzQqohSOyhPRcrKREvLwte7ue/cjfvvRpqKO4 8ZLgKpD0w+GoyMdYhgVJKtdIqvelToWiNBANTSoU= Received: from [IPV6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452] (unknown [IPv6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E0B88D04051; Fri, 24 Aug 2012 13:06:18 -0500 (CDT) References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <5036FC84.8090008@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Aug 2012 14:05:49 -0400 To: Hector Santos Message-ID: X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 18:06:30 -0000 I don't expect anything of MDAs or MUAs. I think highlighting the concern is where the demarcation between the Internet protocol and MDA/MUA is best drawn. It's not a question of what they should or shouldn't do, but defining boundaries for the system under consideration. Step one in any system engineering effort is to draw the boundary of your scope. I don't think the current language in 4408bis requires you to implement any new receiver policy. The fact that there is non-normative text that describes one approach for SPF receiver side doesn't obligate you to support it. Scott K Hector Santos wrote: >Scott, > >Trying to figure out where out points differ, I think perhaps there is >a presumption that all backends support user level policies or methods >with automatic spam folder sorting/separation. If so, I don't think >that can be automatically assumed, it needs to be highlighted that it >is important. In this case, then the only security issue could be >isolated to the RFC-based OFFLINE MUAs (Outlook, Live, TBird, Eudora, >Opera, etc). But I think it is safe to suggest that we normally can >not place a high dependency on offline store and forward based MUAs to >have the special protection required passed off to users via >ACCEPT+MARK. > >For the sake of an example, we would not be able to support >Accept+Mark until separation is made available. We could only support >SPF hard failures with a reject. We can not support Accept+Mark >because our stock product does not separate mail in this way. We have >in total six different ways mail can be access (MUA) for our total >mail framework product line. > >1) Telnet: telnet bbs.winserver.com > MUA with Console/ANSI/VT100/102 Terminal Support > >2) Frontend Native GUI MUA, > http://www.winserver.com/public/wcnavigator.wct > >3) Web-based MUA > http://www.winserver.com > >4) Sysop Editor with powerful mail management features (Stock) >4.1) Several 3rd party editors using our API > >5) MAPI API hook for Outlook (Uses Exchange technology, obsolete) > >6) Support for RFC based Offline/Online MUA NNTP >(news://news.winserver.com) > >7) Support for RFC based Offline MUA POP3 mail pickup > >Overall, unless the logic is built in to separate, we will be exposing >users to potentially harmful mail with any of these online and offline >MUA methods. > >So I guess, if you believe it is a presumed all MDA will separate >mail, then maybe your text is sufficient. But that would be a rather >large presumption of backend behavior. I am saying we can't >automatically assume this design is natural for all backends and for >this specific (accept+mark) mode, SPF -ALL protection is lost is >separation is not part of the backend mail operations. > >I really don't know how else I can state it. We can't support >ACCEPT+MARK simply because our mail software is not ready for it out >of the box. For SPF, a reject mode is the only filter and only for >-ALL. > >If we add a new option for example: > > SPF-HardFail-Action Reject|AcceptMark # default Reject > >We will now be force to redesign the software to add different mail >bins for users. This is currently being done (sorting) by 3rd party >mail bots but we can't depend on them to do this themselves for >Received-SPF: fail results. We need to make sure that out of the >box, there are no surprises for any of the mail access methods for SPF >accept+mark failed messages. It would not be made available and only >Reject would be possible until the separation management logic is >available. > >Hope that better explains this. > > >Scott Kitterman wrote: >> On Wednesday, August 22, 2012 09:40:25 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-06.txt >>> Pages : 66 >>> Date : 2012-08-22 >>> >>> Abstract: >>> Email on the Internet can be forged in a number of ways. In >>> particular, existing protocols place no restriction on what a >sending >>> host can use as the "MAIL FROM" of a message or the domain given >on >>> the SMTP HELO/EHLO commands. This document describes version 1 >of >>> the Sender Policy Framework (SPF) protocol, whereby an ADMD can >>> explicitly authorize the hosts that are allowed to use its domain >>> names, and a receiving host can check such authorization. >>> >>> This document obsoletes RFC4408. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> >> There is nothing radical in this update, but it seemed like there was >enough >> change to make it better to publish the latest. This includes many >changes >> discussed on the list, but not yet the new security consideration >that Hector >> proposed (Issue #33), since we don't seem to have converged on >anything yet. >> >> I believe that I've addressed all the other recent suggestions for >changes. >> If I've missed something, please let me know. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> >> > >-- >HLS From hsantos@isdg.net Fri Aug 24 11:08: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 5A54021F8503 for ; Fri, 24 Aug 2012 11:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4lFYttu4bBT for ; Fri, 24 Aug 2012 11:08:03 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2021F8491 for ; Fri, 24 Aug 2012 11:08:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=702; t=1345831680; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Ei70evkScHcvKnoqrp09AunA0k4=; b=SePeIXubICDOvAtxMmr5 ktsjDan+ikyNYVJWStnm4tWFVyHWfrUfjFS3CgPXL6MQL9iLhFacXvG/NQumR1Wm zASSh3aYvDWPN+/KQvLwx4mfgToYxsOMtNmH9ik6DoifTf3abs4rAPTJTu16670v DmJRmJGpC2Bp7roGa7KYC+g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:08:00 -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 1853475531.2162.5000; Fri, 24 Aug 2012 14:07:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=702; t=1345831485; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YZoLw8Y O51/nhQi6UQN55NP+DEEfaGnYYoNwRzt2R8Q=; b=Q/pHz2uiR07sFAHZr54C70+ dUWkDeR7MTRtu+hrxpE2AbW9ZlctXxUH/1z4E8mnfd4NDJykAaxqsI1jn9Av1Eh2 R7j2OOjPhjWL8rHq3Keaps1ZxgJC4S9eUrgWXA6wArw0t+2gk41BF8M1dPA6w0KO WIsL1/H7HncbJJtiNa5g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:04:45 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2452283927.9.7852; Fri, 24 Aug 2012 14:04:45 -0400 Message-ID: <5037C301.5090701@isdg.net> Date: Fri, 24 Aug 2012 14:08:01 -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: <20120824173957.14118.qmail@joyce.lan> In-Reply-To: <20120824173957.14118.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 18:08:04 -0000 It was repeated numerous times that the BACKEND needs to do the separation and how the MUA does would need to be VERY ADVANCED to deal with the situation and we could not depend on the MUA to solve this issue. Please read the proposal better. Thanks. John Levine wrote: >> A receiving MTA should toss anything coming in that way from a domain >> publishing the above. ... > > No. This specific proposal has been rejected innumerable times in the > past. I cannot imagine why anyone would bring it up yet again. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From hsantos@isdg.net Fri Aug 24 11:22: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 D365821F85F4 for ; Fri, 24 Aug 2012 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTOkUdm2IaB for ; Fri, 24 Aug 2012 11:22:26 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8929021F85F3 for ; Fri, 24 Aug 2012 11:22:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7730; t=1345832540; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Gnt1fByQ9D0dDlMquA69/InZWLA=; b=f8TzBfkomLrpXhrBuhwk PulgYVnyE4al9iwS7EajDBd7jpoY/wz+X4ZFerv8W6A2NXwhiUvSAhXFHnJ31b5C y98yumSgEX8NjVRorNzRNNkQ4K5ovTuk2thvZGERZ3QUrw8YHnca/fxb+3/gp6I6 3s45jN6X4d3ux/d4ACjSsas= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:22:20 -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 1854335861.2162.2472; Fri, 24 Aug 2012 14:22:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7730; t=1345832343; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=O6i95Cx peIc39wjwD9boB7KDkjm60q6Ih07mWDa5VsU=; b=h++bijTh6lIXWUF1EFk9Bgi KKOgY8Q0af3kUPou5FVwveTkrO2rfaCuc62Ix7S6vRAMzUAWBDQYoNVNWFc9CFjf tySeEmQwKCHP5e1S4DXvcLr/Oj8PHI7ZkLRXwInSUPowcJp+w9AyDaJTZlnKRiUI TL1ED9uSt8gplraS3x4M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:19:03 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2453141911.9.3976; Fri, 24 Aug 2012 14:19:03 -0400 Message-ID: <5037C660.9090406@isdg.net> Date: Fri, 24 Aug 2012 14:22:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 18:22:27 -0000 Scott I see your objection now and Levine's confusion now. Please read the proposal again and my follow up. The resolution of this security issue with accept-failures-mark operations can not depend on the MUA to resolve. The BACKEND would need to resolve it. I hope I did not convey the idea that an MUA can resolve this. Of course, in theory it CAN but as stated in the proposal, it would require to be an ADVANCED MUA. This needs to be resolved at the BACKEND so that regardless of the connectivity, the mode of user mail access, the user is not exposed to the accept+failed+marked mail without some special form of backend display rendering. I provided examples of this with Hotmail in the April/May message. I repeated yesterday with the gmail example, and I illustrated how the 6-7 multiple Mail Access methods AKA (MUA methods) we have all need to have the backend to resolve it. The proposal states in the final paragraph: Backends needs to take precautions of marking messages resulting from SPF -ALL failed transactions but were not rejected as prescribed in section 2.5.4. I don't see that saying anything regarding MUAs dependencies, nor backend mandate to resolve it, but a security precaution and insight to be aware. Ideally, I would like that to be stronger, like "The backend MUST separate the accept+failed+marked messages" but I don't think that would be acceptable. But then again, who knows, that may depend on who states it. -- HLS Scott Kitterman wrote: > I don't expect anything of MDAs or MUAs. I think highlighting the concern is where the demarcation between the Internet protocol and MDA/MUA is best drawn. It's not a question of what they should or shouldn't do, but defining boundaries for the system under consideration. Step one in any system engineering effort is to draw the boundary of your scope. > > I don't think the current language in 4408bis requires you to implement any new receiver policy. The fact that there is non-normative text that describes one approach for SPF receiver side doesn't obligate you to support it. > > Scott K > > Hector Santos wrote: > >> Scott, >> >> Trying to figure out where out points differ, I think perhaps there is >> a presumption that all backends support user level policies or methods >> with automatic spam folder sorting/separation. If so, I don't think >> that can be automatically assumed, it needs to be highlighted that it >> is important. In this case, then the only security issue could be >> isolated to the RFC-based OFFLINE MUAs (Outlook, Live, TBird, Eudora, >> Opera, etc). But I think it is safe to suggest that we normally can >> not place a high dependency on offline store and forward based MUAs to >> have the special protection required passed off to users via >> ACCEPT+MARK. >> >> For the sake of an example, we would not be able to support >> Accept+Mark until separation is made available. We could only support >> SPF hard failures with a reject. We can not support Accept+Mark >> because our stock product does not separate mail in this way. We have >> in total six different ways mail can be access (MUA) for our total >> mail framework product line. >> >> 1) Telnet: telnet bbs.winserver.com >> MUA with Console/ANSI/VT100/102 Terminal Support >> >> 2) Frontend Native GUI MUA, >> http://www.winserver.com/public/wcnavigator.wct >> >> 3) Web-based MUA >> http://www.winserver.com >> >> 4) Sysop Editor with powerful mail management features (Stock) >> 4.1) Several 3rd party editors using our API >> >> 5) MAPI API hook for Outlook (Uses Exchange technology, obsolete) >> >> 6) Support for RFC based Offline/Online MUA NNTP >> (news://news.winserver.com) >> >> 7) Support for RFC based Offline MUA POP3 mail pickup >> >> Overall, unless the logic is built in to separate, we will be exposing >> users to potentially harmful mail with any of these online and offline >> MUA methods. >> >> So I guess, if you believe it is a presumed all MDA will separate >> mail, then maybe your text is sufficient. But that would be a rather >> large presumption of backend behavior. I am saying we can't >> automatically assume this design is natural for all backends and for >> this specific (accept+mark) mode, SPF -ALL protection is lost is >> separation is not part of the backend mail operations. >> >> I really don't know how else I can state it. We can't support >> ACCEPT+MARK simply because our mail software is not ready for it out >> of the box. For SPF, a reject mode is the only filter and only for >> -ALL. >> >> If we add a new option for example: >> >> SPF-HardFail-Action Reject|AcceptMark # default Reject >> >> We will now be force to redesign the software to add different mail >> bins for users. This is currently being done (sorting) by 3rd party >> mail bots but we can't depend on them to do this themselves for >> Received-SPF: fail results. We need to make sure that out of the >> box, there are no surprises for any of the mail access methods for SPF >> accept+mark failed messages. It would not be made available and only >> Reject would be possible until the separation management logic is >> available. >> >> Hope that better explains this. >> >> >> Scott Kitterman wrote: >>> On Wednesday, August 22, 2012 09:40:25 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-06.txt >>>> Pages : 66 >>>> Date : 2012-08-22 >>>> >>>> Abstract: >>>> Email on the Internet can be forged in a number of ways. In >>>> particular, existing protocols place no restriction on what a >> sending >>>> host can use as the "MAIL FROM" of a message or the domain given >> on >>>> the SMTP HELO/EHLO commands. This document describes version 1 >> of >>>> the Sender Policy Framework (SPF) protocol, whereby an ADMD can >>>> explicitly authorize the hosts that are allowed to use its domain >>>> names, and a receiving host can check such authorization. >>>> >>>> This document obsoletes RFC4408. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>> There is nothing radical in this update, but it seemed like there was >> enough >>> change to make it better to publish the latest. This includes many >> changes >>> discussed on the list, but not yet the new security consideration >> that Hector >>> proposed (Issue #33), since we don't seem to have converged on >> anything yet. >>> I believe that I've addressed all the other recent suggestions for >> changes. >>> If I've missed something, please let me know. >>> >>> Scott K >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >>> >>> >> -- >> HLS > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From hsantos@isdg.net Fri Aug 24 11: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 DCE7321F8720 for ; Fri, 24 Aug 2012 11:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IaVOTk1IH0V for ; Fri, 24 Aug 2012 11:46:22 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D644F21F871C for ; Fri, 24 Aug 2012 11:46:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4731; t=1345833970; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=mVJTXqRBHZYbOS8lKqntCn9zuJE=; b=mPb0srWEJHf+plHl99dJ jKva9MiVz5W88NWhfwV3cy4UM0wnZeGzP8fN2KocPu/zW1u88GyeV7p2VPN3fvVL svz1wn9v/XdRkXFQalrKCovEOVKKMOItBkpkJb86m4R4cyUch8nsaQyD6l8sAdNF mhX/6Bq1qUehSlvmGxIfIaw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:46:10 -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 1855766094.2162.3024; Fri, 24 Aug 2012 14:46:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4731; t=1345833775; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=OaXaTmn z0+NTYrUvRGfbmT2Y2Pul3o8owRvJSsVOBt4=; b=OnBOEM56DHdRPRRFzmv0nxg H7K8WTurd/zzif5mcsTYuz2X2KNW6iiS98Uc5nyP/urZwzAzdTLxR1qu1ZVO75bT n7QkLZ0l+0RkBKRGepJgEBfOXmm9kb7lqIARKjHPDtVcWOk+zWB/pKuEC0oRffH0 V0p7NNRl8bR22nvQxcDo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:42:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2454572614.9.2780; Fri, 24 Aug 2012 14:42:53 -0400 Message-ID: <5037CBF6.1000800@isdg.net> Date: Fri, 24 Aug 2012 14:46:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@Commerco.Net> In-Reply-To: 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 Cc: spfbis@ietf.org, Commerco WebMaster Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 18:46:23 -0000 These are similar to old arguments since MARID that has failed to gain traction and were rejected as reasons to not explore the fast entry SPF protocol. As Alan now and many has stated since 2005 if a domain is unsure of its outbound mail senders and its "associates", then it needs have a more relaxed domain SPF policy. It is not a candidate to use a strong -ALL hard fail policy, nor should it expect that a receiver would be using one of those kludged methods like SRS to resolve any false positive issues with forwarding. This is why SPF offers the more relaxed policies of SoftFail (~ALL) and Neutral (?ALL) which does require additional factors to make any conclusions about the the transaction. The thing is over time, domains has learned. Many that did begin with a relaxed policy have found continued spoofing problems and have switched to the hard fail (-ALL). The point is -ALL has a special meaning described in 2.3. There is a certain intent and expectation. 2.5.4 offers a REJECT and a ACCEPT+MARK mode of handling. This issue/topic is how ACCEPT+MARK can be harmful when its not semantically equivalent to the REJECT mode of operation. The BACKEND is the only possible part of the framework that can deal with this. The MUA can not deal with this. It can, in theory, but it needs to be advanced and much trust is required by the user. The backend is the only practical method of dealing with this issue. Murray S. Kucherawy wrote: > On Fri, Aug 24, 2012 at 12:59 AM, Commerco WebMaster > wrote: >> I think that I can understand why you might feel that way, however, SPF does >> allow other options for publishers who wish to use it in a less publisher >> centric absolute manner (e.g., ~ALL). >> >> Obviously some folks do and will get their configurations wrong, but is it >> really the role of a standards group working on a standards draft to account >> for every misconfiguration (unintended or otherwise) in a standard? > > Of course not, but it is also not the place of a standard to disregard > obvious failure modes, especially when those involve third parties not > involved in the protocol. Some examples come to mind: > > User A sends to user B, who has forwarding arranged to address C. > Said forwarding leaves the envelope sender unmodified. Upon receipt at > C, SPF evaluation is performed. Of course, the MTA at B is not > authorized to send mail for A, so SPF fails and the message bounces. > Under your vision for SPF, in essence, A must ensure that it will > never send mail to anyone that might set up mail forwarding. I > suggest that's an unreasonable burden. > > User A sends to list B, which relays to C (among others, as C is > subscribed) without changing the envelope. (Historically, some MLMs > acted that way.) B observes the bounce, and ultimately unsubscribes C > as a bad address. C, whose only crime is to participate in SPF and > subscribe to list B, is now kicked off the list through no fault of > its own. (This scenario is admittedly much more visible under ADSP.) > The only way to avoid this is to ensure that nobody at A ever > subscribes to a list. I suggest that's also unreasonable. There are > many companies that solve this by having one domain for users and a > different domain for critical transactional stuff, but most of them > dislike having to do that. > > User A sends to B which forwards to C. C rejects due to SPF failure. > B is doing the forwarding inline, so it also rejects. A now thinks B > is a bogus address when in fact it is not. This is a variant of the > first case, which means A can't ever send mail to anyone that > forwards. > > The notion of demanding that fail + -all = reject also contradicts > some well established principles that local policy is local policy and > cannot be legislated by any standards action; it belongs solely to the > ADMD. > > Moreover, given two receivers, one of whom does strict "-all" > rejection and one that is softer and has a wider evaluation policy, > people will vote with their feet when one of these failure modes hits > on legitimate mail and move to the more comprehensive policy provider. > (The more strict site will be perceived as "broken".) It then > becomes a business decision not to be strict regardless of what's in > the protocol. (Admittedly, this is also why there's very weak > enforcement of mail format standards, but that's for another > discussion.) > > The protocol has to accept such realities. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From ajs@anvilwalrusden.com Fri Aug 24 11:49: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 F3F3021F8686 for ; Fri, 24 Aug 2012 11:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYyxzKBksUtb for ; Fri, 24 Aug 2012 11:49:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7D92221F8685 for ; Fri, 24 Aug 2012 11:49:08 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9100C8A031 for ; Fri, 24 Aug 2012 18:49:05 +0000 (UTC) Date: Fri, 24 Aug 2012 14:49:03 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120824184903.GJ60243@crankycanuck.ca> References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5037C660.9090406@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 18:49:09 -0000 Hector, On Fri, Aug 24, 2012 at 02:22:24PM -0400, Hector Santos wrote: > Please read the proposal again and my follow up. The resolution of > this security issue with accept-failures-mark operations can not > depend on the MUA to resolve. The BACKEND would need to resolve it. If I understand your suggestion, it sounds very much like a modification of what RFC 4408 says. Am I correct about that? If not, how? If I understand the discussion, it sounds like this modofication is not an enhancement "that ha[s] already gained widespread support" as required by our charter, since several people seem opposed to your suggestion. If I am incorrect about this, please provide an argument as to why. If I am correct in my understanding, then I do not believe we are chartered to make the change you request. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Aug 24 11:55: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 602C421F8686 for ; Fri, 24 Aug 2012 11:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laPGewVI2gHx for ; Fri, 24 Aug 2012 11:55:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 43B0621F85EA for ; Fri, 24 Aug 2012 11:55:33 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8EF8BD0408D; Fri, 24 Aug 2012 13:55:32 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345834532; bh=5mviLY3p7SJRweoQY2Xahzn9ztZflsbQcrCdVmViB+E=; h=References:In-Reply-To:Subject:From:Date:To:From; b=WF1LgkT1txEfQKBbkEf06aPuzUBvyYIqA+tA/1W9yQ8SFqpC0xbuLq6LYabrtzItT KUdYk+bhsDPDqQA+9Dlwq29V3132wWHActAFXIvXZNZJfZW+YToNKLFy1RdPAM45p0 9EymSVCru786bU/1PoRy8PB6diVUf9wSzpGleALc= Received: from [IPV6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452] (unknown [IPv6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E57C7D04051; Fri, 24 Aug 2012 13:55:31 -0500 (CDT) References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <5037C660.9090406@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Aug 2012 14:55:28 -0400 To: spfbis@ietf.org Message-ID: <32e34eaf-7d1d-4053-ab9c-90d76112539a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 18:55:34 -0000 I disagree. In most cases when SPF is used as one input out of many, some of the inputs will require inspection of message content and that's not properly the business of an MTA. This is an MDA/MUA issue. Scott K Hector Santos wrote: >Scott > >I see your objection now and Levine's confusion now. > >Please read the proposal again and my follow up. The resolution of >this security issue with accept-failures-mark operations can not >depend on the MUA to resolve. The BACKEND would need to resolve it. > >I hope I did not convey the idea that an MUA can resolve this. Of >course, in theory it CAN but as stated in the proposal, it would >require to be an ADVANCED MUA. > >This needs to be resolved at the BACKEND so that regardless of the >connectivity, the mode of user mail access, the user is not exposed to >the accept+failed+marked mail without some special form of backend >display rendering. > >I provided examples of this with Hotmail in the April/May message. I >repeated yesterday with the gmail example, and I illustrated how the >6-7 multiple Mail Access methods AKA (MUA methods) we have all need to >have the backend to resolve it. > >The proposal states in the final paragraph: > > Backends needs to take precautions of marking messages resulting > from SPF -ALL failed transactions but were not rejected as > prescribed in section 2.5.4. > >I don't see that saying anything regarding MUAs dependencies, nor >backend mandate to resolve it, but a security precaution and insight >to be aware. Ideally, I would like that to be stronger, like > > "The backend MUST separate the accept+failed+marked messages" > >but I don't think that would be acceptable. But then again, who >knows, that may depend on who states it. > >-- >HLS > > >Scott Kitterman wrote: >> I don't expect anything of MDAs or MUAs. I think highlighting the >concern is where the demarcation between the Internet protocol and >MDA/MUA is best drawn. It's not a question of what they should or >shouldn't do, but defining boundaries for the system under >consideration. Step one in any system engineering effort is to draw >the boundary of your scope. >> >> I don't think the current language in 4408bis requires you to >implement any new receiver policy. The fact that there is >non-normative text that describes one approach for SPF receiver side >doesn't obligate you to support it. >> >> Scott K >> >> Hector Santos wrote: >> >>> Scott, >>> >>> Trying to figure out where out points differ, I think perhaps there >is >>> a presumption that all backends support user level policies or >methods >>> with automatic spam folder sorting/separation. If so, I don't think > >>> that can be automatically assumed, it needs to be highlighted that >it >>> is important. In this case, then the only security issue could be >>> isolated to the RFC-based OFFLINE MUAs (Outlook, Live, TBird, >Eudora, >>> Opera, etc). But I think it is safe to suggest that we normally can > >>> not place a high dependency on offline store and forward based MUAs >to >>> have the special protection required passed off to users via >>> ACCEPT+MARK. >>> >>> For the sake of an example, we would not be able to support >>> Accept+Mark until separation is made available. We could only >support >>> SPF hard failures with a reject. We can not support Accept+Mark >>> because our stock product does not separate mail in this way. We >have >>> in total six different ways mail can be access (MUA) for our total >>> mail framework product line. >>> >>> 1) Telnet: telnet bbs.winserver.com >>> MUA with Console/ANSI/VT100/102 Terminal Support >>> >>> 2) Frontend Native GUI MUA, >>> http://www.winserver.com/public/wcnavigator.wct >>> >>> 3) Web-based MUA >>> http://www.winserver.com >>> >>> 4) Sysop Editor with powerful mail management features (Stock) >>> 4.1) Several 3rd party editors using our API >>> >>> 5) MAPI API hook for Outlook (Uses Exchange technology, obsolete) >>> >>> 6) Support for RFC based Offline/Online MUA NNTP >>> (news://news.winserver.com) >>> >>> 7) Support for RFC based Offline MUA POP3 mail pickup >>> >>> Overall, unless the logic is built in to separate, we will be >exposing >>> users to potentially harmful mail with any of these online and >offline >>> MUA methods. >>> >>> So I guess, if you believe it is a presumed all MDA will separate >>> mail, then maybe your text is sufficient. But that would be a rather > >>> large presumption of backend behavior. I am saying we can't >>> automatically assume this design is natural for all backends and for > >>> this specific (accept+mark) mode, SPF -ALL protection is lost is >>> separation is not part of the backend mail operations. >>> >>> I really don't know how else I can state it. We can't support >>> ACCEPT+MARK simply because our mail software is not ready for it out > >>> of the box. For SPF, a reject mode is the only filter and only for >>> -ALL. >>> >>> If we add a new option for example: >>> >>> SPF-HardFail-Action Reject|AcceptMark # default Reject >>> >>> We will now be force to redesign the software to add different mail >>> bins for users. This is currently being done (sorting) by 3rd party > >>> mail bots but we can't depend on them to do this themselves for >>> Received-SPF: fail results. We need to make sure that out of the >>> box, there are no surprises for any of the mail access methods for >SPF >>> accept+mark failed messages. It would not be made available and only > >>> Reject would be possible until the separation management logic is >>> available. >>> >>> Hope that better explains this. >>> >>> >>> Scott Kitterman wrote: >>>> On Wednesday, August 22, 2012 09:40:25 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-06.txt >>>>> Pages : 66 >>>>> Date : 2012-08-22 >>>>> >>>>> Abstract: >>>>> Email on the Internet can be forged in a number of ways. In >>>>> particular, existing protocols place no restriction on what a >>> sending >>>>> host can use as the "MAIL FROM" of a message or the domain >given >>> on >>>>> the SMTP HELO/EHLO commands. This document describes version 1 >>> of >>>>> the Sender Policy Framework (SPF) protocol, whereby an ADMD can >>>>> explicitly authorize the hosts that are allowed to use its >domain >>>>> names, and a receiving host can check such authorization. >>>>> >>>>> This document obsoletes RFC4408. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>> There is nothing radical in this update, but it seemed like there >was >>> enough >>>> change to make it better to publish the latest. This includes many >>> changes >>>> discussed on the list, but not yet the new security consideration >>> that Hector >>>> proposed (Issue #33), since we don't seem to have converged on >>> anything yet. >>>> I believe that I've addressed all the other recent suggestions for >>> changes. >>>> If I've missed something, please let me know. >>>> >>>> Scott K >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>>> >>>> >>> -- >>> HLS >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> >> From superuser@gmail.com Fri Aug 24 11:57: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 7AB3021F868A for ; Fri, 24 Aug 2012 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87fdpOiUCTuN for ; Fri, 24 Aug 2012 11:57:32 -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 AA17321F85EA for ; Fri, 24 Aug 2012 11:57:31 -0700 (PDT) Received: by lbky2 with SMTP id y2so588643lbk.31 for ; Fri, 24 Aug 2012 11:57:30 -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=wSJ5B0VuGp8WGUyWh9GuExEpxHN8+QGRaPWBYxCrBzA=; b=gWkb5TxcCowoXhWTCu2DWJGIbZP+koJtoEP88A8IoTYkj5n3KZxenRPsA4zoax/PhQ SpR7xND5fF3Z2SjEdFQy7jUyYY7Z6uRYqqrF64UnJiDZNMcliQP159sPC1IzfspsLAfO Tk9WnCIy1kXKujXh21qthMrCaNI7B8uCIy8Z/GHNLhmzGKbtDp0rVXqzkDh/+k4Ri7T7 3oehFo3H0oBabQHA5P98uVN0XvSGn2tCGhr9Fq3KdH1xZ5oHGg80qkMj5E2vG+KjoCwW Y3trnhta0QJi4LJOYdFoOaZb5Aa2mrCLeKTB5Sd2JL5VRGPbez/ZEDcJHMAYqeyEpTKQ +Ivw== MIME-Version: 1.0 Received: by 10.112.83.200 with SMTP id s8mr3161255lby.13.1345834650582; Fri, 24 Aug 2012 11:57:30 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 24 Aug 2012 11:57:30 -0700 (PDT) In-Reply-To: <32e34eaf-7d1d-4053-ab9c-90d76112539a@email.android.com> References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <32e34eaf-7d1d-4053-ab9c-90d76112539a@email.android.com> Date: Fri, 24 Aug 2012 11:57:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 18:57:32 -0000 On Fri, Aug 24, 2012 at 11:55 AM, Scott Kitterman wrote: > I disagree. In most cases when SPF is used as one input out of many, some of the inputs will require inspection of message content and that's not properly the business of an MTA. This is an MDA/MUA issue. Does that mean MTAs shouldn't be doing inline spam filtering or DKIM evaluation? Many do. -MSK From sm@resistor.net Fri Aug 24 12:01: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 5921321F876A for ; Fri, 24 Aug 2012 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHf7MgOGWcFP for ; Fri, 24 Aug 2012 12:01: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 B64C621F877B for ; Fri, 24 Aug 2012 12:01:18 -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 q7OJ1D9l003832 for ; Fri, 24 Aug 2012 12:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345834877; bh=erXvnh1t/fjGb1kt/ck0BIAMTry1RW4qyVFwfbP8n0w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=0WD7qD8dENEobFy/GtZ8z7yDx2/uBozeOm8NeneukGt4/nX9Amtl08xBAf9oJT6hX 4b1J4AISDBp9PCz4FXCyfb7iMDVoRkyfU68282SPrlRvbXpCW540Al2CCIk79rxdHQ hstladmm+uIvUU+z8iyAY7nclIakgkKmkmQZxVhU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345834877; i=@resistor.net; bh=erXvnh1t/fjGb1kt/ck0BIAMTry1RW4qyVFwfbP8n0w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SVdMkwdO9dvgkUlcaZwjouFiyfXz+72Uzhd2yenWRgQzSCbG1cqBtz7PqI4bXTBn/ 9g2xEiRqBhAigMosVyX0GM9CyR+QAWVGfm4N78IHcauZvD25FHbQies99he1wzLU5s /ReXHzT6HJQPRb+TEK/OQ4SrCXm+rlA1Sfo+0ZzU= Message-Id: <6.2.5.6.2.20120824085429.0a908050@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 12:01:08 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <50375769.5000308@tana.it> References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@Commerco.Net> <50375769.5000308@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 19:01:21 -0000 At 03:28 24-08-2012, Alessandro Vesely wrote: >The protocol delivers a result for a given input. A result of "fail" >is "fail", irrespectively of which mechanism yielded that result. I would like to proceed with the above as a starting point. The questions to the working group are: (a) Is there an issue where malicious content can be delivered to the recipient when there is a SPF "Fail" [1]? (b) Is there an issue where malicious content can be delivered to the recipient when there is a SPF "Pass" [2]? Regards, S. Moonesamy SPFBIS WG -co-chair 1. A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. 2. A "Pass" result means that the client is authorized to inject mail with the given identity. From hsantos@isdg.net Fri Aug 24 12:02: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 F1CE321F8758 for ; Fri, 24 Aug 2012 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwYNBRuMwCqW for ; Fri, 24 Aug 2012 12:02:15 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1036E21F8752 for ; Fri, 24 Aug 2012 12:02:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1330; t=1345834931; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=e0tgtRJVyadUVLA2bVKDlHLgQ3A=; b=mQ/VsSKkLf2A/cWgSdap TtoSKrzooHot/sFGXjZUkee3T3WHkS9cZMZPXYdTLXNUk2fSDFSqrTDZ9Kf+2HJo IT/+lSBwu1EbWSCKFnrTnuZjkP6lw7zjPq8O2JeCfFJdhPkQBrkHEufO2rx06pQc VtU39XdkePiZIWVTz9Kq6YI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 15:02:11 -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 1856726296.2162.4748; Fri, 24 Aug 2012 15:02:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1330; t=1345834737; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=R6U8bru k8ecpMnTeVu0zfqWm+tIctuDjLspZa1Oxt1U=; b=Sq5Ouwd+wgO0hUxtbHUMl84 S3r/KMbZkQQuxHy93qCHtEOYPi7PdWB+Xvyx4F63D80attCqo5h21IVgun9Nnvof o2+syOBCvYSUInEs9FP1Yel7v7iDQMBuhhANC5cfyzveW9c0wUW5EPRsZktBeDaG 28drttxnwLszUkjsYb9Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 14:58:57 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2455535239.9.7840; Fri, 24 Aug 2012 14:58:56 -0400 Message-ID: <5037CFB9.5050101@isdg.net> Date: Fri, 24 Aug 2012 15:02:17 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <20086782.TyIbvIWLSl@scott-latitude-e6320> <5035A047.1030604@isdg.net> <2267574.6GQXnqNoLg@scott-latitude-e6320> <5037C07B.2010005@dcrocker.net> In-Reply-To: <5037C07B.2010005@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 19:02:16 -0000 Dave Crocker wrote: > > On 8/22/2012 8:31 PM, Scott Kitterman wrote: >> SPF is an MTA to MTA protocol. I don't think it's appropriate to include an >> MUA design missive in the security considerations. I think it's enough to >> document the consideration and let MUA designers deal with it appropriately. > > > +1. Very nicely stated. For the record, the proposal IS NOT asking that MUA resolves the security issued with accepted marked failed messages. It clearly states the backends need to take precaution to address this without getting into any specific methods or mandate. > In fact, I think that putting the sentence "SPF is an MTA to MTA > protocol." into the document -- probably Intro -- would be useful. I am not to sure about that. SPF is more of a MTA to MDA protocol. We already have technology to deal with MTA to MTA transports to address open relay problems. We use ESMTP AUTH, IP Relay Authorizations, POP3 BEFORE SMTP and maybe others prearranged MTA to MTA transports. But at the MDA, there is no more further relay expected. No authentication is required for the final local mail recipients (unless we are using the SUBMIT protocol - port 587). This is where the spoofing begins with the bounce problems and SPF comes into play to help mitigate the problem. -- HLS From spf2@kitterman.com Fri Aug 24 12:07: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 3C54321F84A0 for ; Fri, 24 Aug 2012 12:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taZck1+x2TsL for ; Fri, 24 Aug 2012 12:07:07 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE721F843A for ; Fri, 24 Aug 2012 12:07:07 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 7792BD0408D; Fri, 24 Aug 2012 14:07:06 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345835226; bh=DXQxbnS/jjxQw20dbmFDzmjANGyPLMioY0TOiWfLWwk=; h=References:In-Reply-To:Subject:From:Date:To:From; b=mbibslbD43cu70arCv3aV17/KXb6/4z0V0bWyyyRQ6m9gDFqpHZscAaoxnz1hUb8U W1FuXbrFfwKGZwB+Vk7aoj5XPDKRIPXXnyyxiEAmze2h6HcTMGzwbb4SUV5LnaSQnY olSBKyZS/qTBkcnqFMVa2d6bvQoYUqMutywbeURU= Received: from [IPV6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452] (unknown [IPv6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CE5CED04051; Fri, 24 Aug 2012 14:07:05 -0500 (CDT) References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <32e34eaf-7d1d-4053-ab9c-90d76112539a@email.android.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Aug 2012 15:07:00 -0400 To: spfbis@ietf.org Message-ID: <226e895a-de33-435a-8868-d88529e896d0@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 19:07:08 -0000 "Murray S. Kucherawy" wrote: >On Fri, Aug 24, 2012 at 11:55 AM, Scott Kitterman >wrote: >> I disagree. In most cases when SPF is used as one input out of many, >some of the inputs will require inspection of message content and >that's not properly the business of an MTA. This is an MDA/MUA issue. > >Does that mean MTAs shouldn't be doing inline spam filtering or DKIM >evaluation? Many do. DKIM doesn't care what the content is (only that the body hash matches), so I think that's fine. Personally, I see spam/virus filtering as an MDA function. I would be surprised if everyone agreed. Scott K From hsantos@isdg.net Fri Aug 24 12:51:54 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 E140621F8609 for ; Fri, 24 Aug 2012 12:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu6-MEwVKvZS for ; Fri, 24 Aug 2012 12:51:54 -0700 (PDT) Received: from winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 49CEF21F8605 for ; Fri, 24 Aug 2012 12:51:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3463; t=1345837911; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VWXlI4l3s2FBLcoC7QcfQR33pSo=; b=aU9aaj2VHCViYPgzk5W/ GzZ2Pc2q9UrBtiRG6Q8r6mp1LY/cmf4S83Ctzyg233iOURjN6HhbOGd8d8/9fH3s jlmFfZGqxdNc/D0837592BTXTBEpbuYu4ULxbnarwJc7wwSNd+pBom5a7M0nKlL5 uWWnKPZZ7/NOSXqxK/6jncM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 15:51:51 -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 1859706585.2162.4504; Fri, 24 Aug 2012 15:51:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3463; t=1345837715; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5X6rO2f QtbnQqDWesdfN0iVTLhUzOo7t8osTeXih2Bk=; b=PXgJ92HJW9N9OE6yAe4wbQo qhM/6Ro58eflN+oSKMRr2XCwea3jBs3cu9aKkSww/AKis6cEkC2cBzi4zH78/oRw yU9ma4WTGhxuSFPkIN+lM09BEVt3PeSmmqwaf7sZ+XdHPPj01xgEWvOOtBdFTLMh 40RLbtIzJOGgxIrY3X48= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 15:48:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2458513520.9.4952; Fri, 24 Aug 2012 15:48:34 -0400 Message-ID: <5037DB5B.8030004@isdg.net> Date: Fri, 24 Aug 2012 15:51:55 -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: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <20120824184903.GJ60243@crankycanuck.ca> In-Reply-To: <20120824184903.GJ60243@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 19:51:55 -0000 Andrew Sullivan wrote: > Hector, > > On Fri, Aug 24, 2012 at 02:22:24PM -0400, Hector Santos wrote: > >> Please read the proposal again and my follow up. The resolution of >> this security issue with accept-failures-mark operations can not >> depend on the MUA to resolve. The BACKEND would need to resolve it. > > If I understand your suggestion, it sounds very much like a > modification of what RFC 4408 says. Am I correct about that? I don't believe so. > If not, how? Many ways to review this and explain it. Obviously I have not been successful in clearly stating it and its quite frustrating to understand why that is the case. I tried to explain it many different ways, from many angles. There is no mandate or change being advocating outside the fact that 4408BIS is gaining a new focus for ACCEPT+MARK methods of operations (based on the input here). Despite on how real that is, the protocol, IMV, MUST provide insight on the security impact of using one of two alternatives where one is 100% secured and the other is not unless the additional methods in the protocol defines it so. I honestly do not know how else to state this. I even used my own system where it would not be feasible to switch to a ACCEPT+MARK for the very reason cited by the security note. We would need to begin to separate the mail in the stock software otherwise a loophole is opened up by accepting plus marking the failed mail. According to our latest August 2012 stats, http://www.winserver.com/public/spamstats.wct SPF yields 16% among the total 82% rejection rate of the transactions. By switching to accept+mark, we would be exposing these currently SPF -ALL rejects to end users. Having this security note will help implementators under the same situations. Consider the alternative, by not having the security note, in effect, 4408 is mandating a certain design all mail systems must have to help protect the accept+mark mail recipients and the domains that are using -ALL. I am not going that far. My security note helps in avoid this implicit consideration for a specific user level policy mail design where SPAM FOLDERS are par for the course. > If I understand the discussion, it sounds like this modofication is > not an enhancement "that ha[s] already gained widespread support" as > required by our charter, since several people seem opposed to your > suggestion. If I am incorrect about this, please provide an argument > as to why. There seems to be an misunderstanding of an old and often discussed view that MUA can be part of the solution for SPF and even DKIM. That is not what the proposal is asking for the same reasons consensus always had - the backend is better equip to do the mail filtering to help/assist the layman user and also one where we can not practically mandate how various offline RFC-BASED Mail Reader/Writers will behave and/or when they will be updated. In other words, unless the backend can control the access and rendering, the backend can not put trust on 3rd party MUAs. > If I am correct in my understanding, then I do not believe we are > chartered to make the change you request. There is no request for a change. This is a security loophole with the accept+marked protocol option for -ALL policies where 2.3 has MUST level language for what a DOMAIN needs to do in order to get a negative filter consideration by the receiver. -- HLS From sm@elandsys.com Fri Aug 24 12:54: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 B2F5521F8620 for ; Fri, 24 Aug 2012 12:54:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+WTaDcFluhq for ; Fri, 24 Aug 2012 12:54:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F19A21F849D for ; Fri, 24 Aug 2012 12:54:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.150]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7OJsjhg007388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 12:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345838097; bh=WeNw9ptOLg8rSN7pPSi1WnPO/O5a1Ld+F81GFkO2fZM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X7P9G2BHQTBi8fPvbVwI1qUnjbtsIoL/LwrFr/DycBzDx5EFLkKLCv3VH3R8bQ+69 DA0shAyn+XyNv1PpuUtSDCn0xCj1zJ3KUzseCoD3lJ+cyQ6W/Az5ErIOYY+kycaJOp 0PyoOLyTT4yD/HkA02NhofB5s+zSVb2JIcZ1hHIE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345838097; i=@elandsys.com; bh=WeNw9ptOLg8rSN7pPSi1WnPO/O5a1Ld+F81GFkO2fZM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AnHhDlrPF+9h/Mq9KwxH/raoSTOSjVM7JWOvl6kZWVP4rPOtdmI6myDHIkmX1PmMG bbzI8AUCx3KFRDaRbQEEcOtacA8tY6FJUKIbky6tixxsaK3Ph9pMLlCjhgNnnW3fxa v/mO1QOA5meIvvTGKOSG5Upiimc4ZbfQV5wXiiUk= Message-Id: <6.2.5.6.2.20120824120706.06280a00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 12:54:21 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120824174136.14534.qmail@joyce.lan> References: <50366154.5010100@tana.it> <20120824174136.14534.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 19:54:58 -0000 Hello, I would like to thank Alessandro Vesely for suggesting alternatives to address Issue #12. There has been significant discussion about this issue. Murray Kucherawy commented [1] on the tendency to include an example of every possible use of SPF to solve some problem. Stuart Gathman mentioned [2] that using <> to forward emails is a bad idea. John Levine objected [3] to the draft mentioning specific DNSWL or DNSBL. I read the messages which have been posted since Issue #12 was opened for discussion. It is my understanding that some of the discussion [4] is about an effective solution for forwarders who don't want to rewrite the MailFrom. The WG Chair previously stated that the issue is deployment advice. I don't see any convergence of views on what advice to provide. I will close the ticket for Issue #12. Regards, S. Moonesamy SPFBIS WG co-chair 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02281.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02245.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02265.html From ajs@anvilwalrusden.com Fri Aug 24 13:11: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 1688721F8469 for ; Fri, 24 Aug 2012 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCwGT4UWZ7GX for ; Fri, 24 Aug 2012 13:11:00 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 987CE21F8463 for ; Fri, 24 Aug 2012 13:11:00 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8204F8A031 for ; Fri, 24 Aug 2012 20:10:59 +0000 (UTC) Date: Fri, 24 Aug 2012 16:10:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120824201056.GL60243@mx1.yitter.info> References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <20120824184903.GJ60243@crankycanuck.ca> <5037DB5B.8030004@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5037DB5B.8030004@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 24 Aug 2012 20:11:01 -0000 On Fri, Aug 24, 2012 at 03:51:55PM -0400, Hector Santos wrote: > SPF yields 16% among the total 82% rejection rate of the > transactions. By switching to accept+mark, we would be exposing > these currently SPF -ALL rejects to end users. Having this security > note will help implementators under the same situations. > > Consider the alternative, by not having the security note, in > effect, 4408 is mandating a certain design all mail systems must > have to help protect the accept+mark mail recipients and the domains > that are using -ALL. I think you may be conflating "implementation" and "deployment" here. I think you have observed, correctly, that under some deployment scenarios the MTA that receives mail that does not pass a check probably does need to reject the mail, because that MTA's clients may not have the capability to evaluate the mail in question. That is not the same thing, however, as saying that this or that action on the part of the MTA are required as part of the protocol, for interoperability reasons strictly construed. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From WebMaster@Commerco.Net Fri Aug 24 13:12: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 5B44C21F8634 for ; Fri, 24 Aug 2012 13:12:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UBW8p9PCfEQ for ; Fri, 24 Aug 2012 13:12:35 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id A496A21F8469 for ; Fri, 24 Aug 2012 13:12:35 -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=mBOQVn7dFNFqXjv2eVbdkVCvOyLLWtTAC2iP3hP5jgitJXCdSDiRLUTUYaGRVMXpAPlGbRr8uHD8d74fhlU2WLryToVm4E32q7bYfK8s70pQWf/CgLYWtFi/yjKGLUvMwezMhQZbzSjs0dqzZZeh00Qb+jJ1B4csTegpzmBaz1s= 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]); Fri, 24 Aug 2012 20:12:31 +0000 Message-ID: <5037E028.7090007@Commerco.Net> Date: Fri, 24 Aug 2012 14:12:24 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Levine References: <20120824173829.13742.qmail@joyce.lan> In-Reply-To: <20120824173829.13742.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:12:36 -0000 John, On 8/24/2012 11:38 AM, John Levine wrote: >> When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record >> and the result of a receiver MTA's SPF processing is an SPF FAIL, the >> receiving MTA (or any downline MTAs to which it or its successive >> forwarders must forward messages by reason of the receiver's local >> policy [e.g., downstream antispam analysis machines, DMARC implementers, >> etc.]) MUST NOT allow the message to ever reach the MUA(s) of the final >> RCPT TO address(es) in the message under any circumstance (i.e., the >> final mail recipients MUST NOT ever receive messages which fail SPF -ALL >> processing), nor should such -ALL SPF FAIL messages ever be used to >> impugn the reputation of the domain publisher. > > No. This proposal is equally ill-advised. > > SPF is about defining a way for mail-sending domains to publish > policies about sending hosts, and for recipient systems to find out > what a domain's policy is about a particular host. Absolutely correct. What I am trying to suggest in the above is that the recipient systems should respect the published policies of the sending hosts when there is 100% certainty about the interpretation of the published SPF DNS TXT record for a domain. Certainly in basic situations like "v=spf1 -all", the intent is always that "the domain you asked about does not send email". Changing that to be anything other than what that it really is seems wrong. > > It is most definitely not about MUA design, or what a recipient > system does with the policy information it has available. > Again, absolutely agree. My wording was deliberate to allow for the possibility of a pass through for an SPF -ALL "Fail" as long as the MTAs always do two things. 1 The MTAs receiving a forwarded "Fail" message must never allow a MUA to get hold of such a message. 2 The MTAs which receive the message never use a "Fail" message to create a problem for a domain's reputation. I suggest that if in the "v=spf1 -all" example, failing to do either of the above if the original receiver passes along an SPF "Fail" seems rather unfair to an SPF publisher and sort of defeats the point or at least diminishes the value in a domain holder publishing an SPF record using the -ALL syntax. > R's, > John Best, Alan M From johnl@iecc.com Fri Aug 24 13:13: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 324E421F8525 for ; Fri, 24 Aug 2012 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.142 X-Spam-Level: X-Spam-Status: No, score=-111.142 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt+2Lv+GSTru for ; Fri, 24 Aug 2012 13:13:11 -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 30C1821F8503 for ; Fri, 24 Aug 2012 13:13:10 -0700 (PDT) Received: (qmail 15719 invoked from network); 24 Aug 2012 20:13:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 20:13:09 -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=5037e055.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=XdeY1gGJ58UpNVUPFKn8pPvcNyE/w8Ohi/Kl3J7dPSo=; b=aI0YPO58XjXnaUppkE7a8hkr5TU2FMN4AH5LgMhJ43f8s9RfEp8aWwv6SiJ48H3oEecXBxRIEMFbRhMqPuAbPWrvrhmSdagicraPLw8WfEgUZfr9N6gGCghrXKnGiBhqrjNc3turutlNcLbo8eQb+VyMx5Nxiwv7cmDBXx2uxGs= 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=5037e055.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=XdeY1gGJ58UpNVUPFKn8pPvcNyE/w8Ohi/Kl3J7dPSo=; b=vYfBblO9UeDXh4Ufipw/8DOwQD1QxEmt/Gd3fsbAheZQ9/Nwqi42NS0QsQNaD7h+8HBoy9+1p6DZzFnzPVOQpIAhzICKoR1fvO0pMFbhXt/bxGwo4wcP73RGKyNi723ZpzpXtAhGxJwhUjKOA3sv28Zf8kr2fJALpyEhlOlqvI0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 20:12:47 -0000 Message-ID: <20120824201247.51644.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120824175418.GH60243@mx1.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] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:13:12 -0000 >> In case it's not obvious, you don't need to support EAI to use A-label >> domains. It's reasonable advice to everyone to note that non-ASCII >> domains must be encoded as A-labels in DNS queries. > >No hat: > >It's flat-out false that non-ASCII domains must be encoded as A-labels >in DNS queries, so I don't see why we ought to start advising that. Aw, come on. While it is certainly true that the wire-level DNS protocol allows names to contain arbitrary octets, I am reasonably sure that every TLD requires non-ASCII 2LDs to be encoded as A-labels, and application software such as web browsers that handle non-ASCII domains turns it all into A-labels before looking them up. Right now I exchange some mail with people whose addresses are in the form ascii@xn--stuff. (Not a whole lot, but more than none.) Anyone who tried to handle non-ASCII domains any other way would be doomed to eternal incompatibility pain. R's, John From johnl@iecc.com Fri Aug 24 13:14: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 9B17221F8574 for ; Fri, 24 Aug 2012 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.142 X-Spam-Level: X-Spam-Status: No, score=-111.142 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pnlwiiT9c38 for ; Fri, 24 Aug 2012 13:14:49 -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 DF3EE21F8525 for ; Fri, 24 Aug 2012 13:14:48 -0700 (PDT) Received: (qmail 16138 invoked from network); 24 Aug 2012 20:14:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Aug 2012 20:14:46 -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=5037e0b6.xn--hew.k1208; i=johnl@user.iecc.com; bh=q7BM88kU9155KjLMGFXQbHr4W+rjBJsVQMYprxm1ATY=; b=F/+P5YOd9e/TQv6pHpA1uv2Q/5WF6N/YXiWTKEzHHLInfo0KfFdZXmXC3uh7Hi01ztCawCC2aGoyvqpPrllxS6i+RMWY8Ykqc3rLDp24VS/9hDuwguhrQt9E6sOHs5lHW7forMpOgVpXBgbD4ek467EQoCsBkWFwF7fMAckl8YA= 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=5037e0b6.xn--hew.k1208; olt=johnl@user.iecc.com; bh=q7BM88kU9155KjLMGFXQbHr4W+rjBJsVQMYprxm1ATY=; b=o1KS9F9vf5MM5pkpkhtViXsfTcnUs2qVW/4PvjkD94Z0NmjdpCISX0unromJq2ye1eFLX5f1INGZ3PgrAant+i++ahIKyjnm1BkPNi+mTvy6Omevj07oiMwzfBdaED02xigAuXeyB9IB9ZUZA+x6LU21nF1j92qzYOXdIYjAVCE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 24 Aug 2012 20:14:24 -0000 Message-ID: <20120824201424.52054.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <5037E028.7090007@Commerco.Net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:14:49 -0000 >Absolutely correct. What I am trying to suggest in the above is that >the recipient systems should respect the published policies of the >sending hosts when there is 100% certainty about the interpretation of >the published SPF DNS TXT record for a domain. We've already said no to this proposal about a hundred times over the history of this WG and its predecessors. Do we really have to say no a hundred times more? R's, John From ajs@anvilwalrusden.com Fri Aug 24 13:21: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 EB5CF21F85AF for ; Fri, 24 Aug 2012 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j19nQSyD7SeU for ; Fri, 24 Aug 2012 13:21:18 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 743FE21F8517 for ; Fri, 24 Aug 2012 13:21:18 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8A0868A031 for ; Fri, 24 Aug 2012 20:21:17 +0000 (UTC) Date: Fri, 24 Aug 2012 16:21:15 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120824202115.GN60243@mx1.yitter.info> References: <20120824173829.13742.qmail@joyce.lan> <5037E028.7090007@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5037E028.7090007@Commerco.Net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:21:19 -0000 On Fri, Aug 24, 2012 at 02:12:24PM -0600, Commerco WebMaster wrote: > the sending hosts when there is 100% certainty about the > interpretation of the published SPF DNS TXT record for a domain. This condition can never be met. Since it's a TXT record, you can't be sure that it's intended for use with SPF, so 100% certainty is impossible. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Aug 24 13: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 DB69F21F85FC for ; Fri, 24 Aug 2012 13:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f74aA5R7lcu1 for ; Fri, 24 Aug 2012 13:28:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6489321F85C3 for ; Fri, 24 Aug 2012 13:28:53 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3849F8A031 for ; Fri, 24 Aug 2012 20:28:52 +0000 (UTC) Date: Fri, 24 Aug 2012 16:28:50 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120824202850.GO60243@mx1.yitter.info> References: <20120824175418.GH60243@mx1.yitter.info> <20120824201247.51644.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120824201247.51644.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:28:54 -0000 No hat. On Fri, Aug 24, 2012 at 08:12:47PM -0000, John Levine wrote: > Aw, come on. While it is certainly true that the wire-level DNS > protocol allows names to contain arbitrary octets, I am reasonably > sure that every TLD requires non-ASCII 2LDs to be encoded as A-labels, That's irrelevant. Every TLD I know of prevents underscore labels, but we use them all the time further down the tree, just as a handy example. > and application software such as web browsers that handle non-ASCII > domains turns it all into A-labels before looking them up. No, actually. At least one web browser that is still in (fortunately declining) use dumps UTF-8 -- or sometimes, I've been led to believe, UCS-2 with BOM -- on the wire. And browsers that automatically try to turn everything in to A-labels are going to fail completely with mDNS, which explicitly says that it uses UTF-8. I've been attempting to make this very point over in homenet. So some client software will for sure have unpredictable behaviour with respect to labels that might be domain name labels. > Right now I exchange some mail with people whose addresses are in the > form ascii@xn--stuff. (Not a whole lot, but more than none.) Anyone > who tried to handle non-ASCII domains any other way would be doomed to > eternal incompatibility pain. Yes. But this WG is not chartered to tell you how to run your domain, or your mail server, in a sane manner. If we start adding advice to the document about all the ways things probably won't work if you do stuff wrong, we'll never finish. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From WebMaster@Commerco.Net Fri Aug 24 13:54: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 1B0BF21F855E for ; Fri, 24 Aug 2012 13:54:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91GzOkt56teR for ; Fri, 24 Aug 2012 13:54:05 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B421F855D for ; Fri, 24 Aug 2012 13:54:05 -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=uqbyL0nrXWfaAv9zToM8QZ1rSG3nWFqKdtcTCLcJAfoBnX1G0q3AabGtdqAqslwIk2YIKQ/xYCowlKqQ2OEMI+YCZdqsWVWnVdFpqbJh6LEnQNFvIvSjdfmYpRqaxrQ/cNK0kVhrutvonT55mzNEwvL35wVzePahJiReHkbamAY= 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]); Fri, 24 Aug 2012 20:54:01 +0000 Message-ID: <5037E9E2.8080706@Commerco.Net> Date: Fri, 24 Aug 2012 14:53:54 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 20:54:06 -0000 Murray, On 8/24/2012 11:41 AM, Murray S. Kucherawy wrote: > On Fri, Aug 24, 2012 at 12:59 AM, Commerco WebMaster > wrote: >> I think that I can understand why you might feel that way, however, SPF does >> allow other options for publishers who wish to use it in a less publisher >> centric absolute manner (e.g., ~ALL). >> >> Obviously some folks do and will get their configurations wrong, but is it >> really the role of a standards group working on a standards draft to account >> for every misconfiguration (unintended or otherwise) in a standard? > > Of course not, but it is also not the place of a standard to disregard > obvious failure modes, especially when those involve third parties not > involved in the protocol. Some examples come to mind: > > User A sends to user B, who has forwarding arranged to address C. > Said forwarding leaves the envelope sender unmodified. Upon receipt at > C, SPF evaluation is performed. Of course, the MTA at B is not > authorized to send mail for A, so SPF fails and the message bounces. > Under your vision for SPF, in essence, A must ensure that it will > never send mail to anyone that might set up mail forwarding. I > suggest that's an unreasonable burden. Agreed. There has also been discussion over the years for how using SPF, in some limited forwarding situations, has some arguably show stopping issues for some publishers under the -ALL syntax. That said, SPF is not and has never presented itself as a final solution for all email scenarios. SPF does work well for "well behaved" MLMs and direct MTA to MTA mail transfers. It also seems to work well from around 7 years of experience in general use. If a publisher plans to have forwarding in their environment by user demand or as a market driven decision, perhaps the ~ALL syntax is better for them. Alternatively, perhaps this discussion should be taking place for a future SPF3 spec, where we could look at such things as an additional parameter for relaxed forwarding, such that a publisher can indicate they would prefer such an arrangement to allow for what you present in the hypothetical example above within the -ALL syntax. Or perhaps allow for a new way to indicate an absolute statement of publisher's will and intent, as I suspect many publishers believed was the case with -ALL when they first came to SPF. > > User A sends to list B, which relays to C (among others, as C is > subscribed) without changing the envelope. (Historically, some MLMs > acted that way.) B observes the bounce, and ultimately unsubscribes C > as a bad address. C, whose only crime is to participate in SPF and > subscribe to list B, is now kicked off the list through no fault of > its own. (This scenario is admittedly much more visible under ADSP.) > The only way to avoid this is to ensure that nobody at A ever > subscribes to a list. I suggest that's also unreasonable. There are > many companies that solve this by having one domain for users and a > different domain for critical transactional stuff, but most of them > dislike having to do that. > Again, agreed this is a valid example, but as before, SPF cannot stop folks from representing themselves as something they are not and then go back and say, well, maybe they are okay after all. As you point out, the idea of a mailing list doing such things did (and probably still does happen), but then they really should not be misrepresenting themselves as something they are not or again, the publisher might be forced to use the ~ALL syntax if the list owner refuses to repair their MLM software's behavior. > User A sends to B which forwards to C. C rejects due to SPF failure. > B is doing the forwarding inline, so it also rejects. A now thinks B > is a bogus address when in fact it is not. This is a variant of the > first case, which means A can't ever send mail to anyone that > forwards. Well, perhaps. If B has checked SPF and found A as valid, it should never conclude that the address from A was bogus by virtue of a bounce from C. Of course such things do happen in the wild. But, I think that the entire idea behind SPF white lists was to avoid or at least negate that sort of scenario. > > The notion of demanding that fail + -all = reject also contradicts > some well established principles that local policy is local policy and > cannot be legislated by any standards action; it belongs solely to the > ADMD. Indeed, local policy is local policy and SPF was designed to successfully be interoperable with MTAs which never understood or used SPF. The argument you make is real, but it also goes back to why SPF was so widely adopted by publishers. That is, domain holders finally saw a workable way to be able to combat folks misusing their domain names in spam email messages by publishing their domains as being tied to specific authorized sending MTAs. I think that publishers saw -ALL as being a way to make an absolute declaration of will as regards the treatment of their domain names in email messages. Granted, in the real world there are certainly some issues with forwarding and, to a lesser extent mailing lists, but having lived with SPF since 2005, there have been very few issues we could not address with SPF TXT records. In fact, we found ways to address all the issues we have encountered with SPF here in one way or another. > > Moreover, given two receivers, one of whom does strict "-all" > rejection and one that is softer and has a wider evaluation policy, > people will vote with their feet when one of these failure modes hits > on legitimate mail and move to the more comprehensive policy provider. > (The more strict site will be perceived as "broken".) It then > becomes a business decision not to be strict regardless of what's in > the protocol. (Admittedly, this is also why there's very weak > enforcement of mail format standards, but that's for another > discussion.) > I agree and understand. Again, perhaps this is a discussion for a future SPF3 spec where a syntax might be developed to allow smaller MTAs to differentiate themselves from the needs of larger commercial enterprises, where there are certainly wider scopes for implementations that the smaller enterprises do not face. > The protocol has to accept such realities. Agreed, although it should also be able to be scalable and responsive to the needs of all implementers from the smallest to the largest. > > -MSK > Best, Alan M From sm@elandsys.com Fri Aug 24 14:19: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 E766921F8617 for ; Fri, 24 Aug 2012 14:19:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDNTw1+VamG5 for ; Fri, 24 Aug 2012 14:19: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 5908721F85FF for ; Fri, 24 Aug 2012 14:19:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7OLJc5B013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 14:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345843193; bh=GQdRSpuWPux9+ZrwebxSwVCvT+cLaNk/z8LljSwdgWU=; h=Date:To:From:Subject:Cc; b=k64rOIr/a+DTTFRJpE/jwiI+KJf4XNhjGGJbDuv37VjZ/C8lKVKGvtr6fFBgKADVj JRNv0x8ISxv9vTV1yKIRz2Y49YSbQPTdASDQ6t84syWB9EwZFL8ZOeNaKpNP01bGgV +LyePPRymUtQDq2imLJ4r5gECqGLLrKnHNoFXOOs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345843193; i=@elandsys.com; bh=GQdRSpuWPux9+ZrwebxSwVCvT+cLaNk/z8LljSwdgWU=; h=Date:To:From:Subject:Cc; b=Xse4oGP3/TXBPRVuUu778WIM8xzMsUWODMWTkCXHt5XUSxamldKKbGfZO32LTUrtd KyQOoDAfsA+9wQbh2CASECfW3KZ3j8d3SD5EOIpIcWTNWBC6lR8swLcFhAO+KSqePz ZhZ0CdQYZf8MCjTwh/m9f5qr+hsmy82uLaP/4g9Q= Message-Id: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 14:13:24 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 21:19:56 -0000 Hello, There has been a lot of discussion about rejecting mail on SPF Fail. I read RFC 4408. Quoting from Section 2.5.4: "The checking software can choose to mark the mail based on this or to reject the mail outright." It is my understanding that the choice is left to the software in the above text. "If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see [RFC3464]), in addition to an appropriate reply text." The normative text quoted above states what the software should do if it chooses to reject the mail. I could not find any normative text that states that mail SHOULD or MUST be rejected on SPF Fail. I strongly suggest not to pursue further discussion about rejecting mail on SPF Fail as a requirement. Please post a message to the SPFBIS mailing list if you have any objection to the above. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Aug 24 14:22: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 E760A21F84FD for ; Fri, 24 Aug 2012 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZZcUDXY0GdV for ; Fri, 24 Aug 2012 14:22:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8D21F8499 for ; Fri, 24 Aug 2012 14:22:49 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 09387D0408D; Fri, 24 Aug 2012 16:22:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345843369; bh=WbKNVkMikIqwkESzLb6b7amBVOuH/VzECvU0SOWeRIY=; h=References:In-Reply-To:Subject:From:Date:To:From; b=EQIsOhwDsqBhfLXX1xvYgdA/07xbLV74g/uwbea1E8BGY2OIxWriSLtaUP+UrSpeX NetSlcLuBR9apf9cxeNUu2k0DamkAgm0KF/gwypUBfDoS8YYPkhu7gIyEKaiBlovaz iQH/8iKrXjd26Hp3D6OA1TPR+C1zJ7imwACl38q4= Received: from [IPV6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452] (unknown [IPv6:2600:1002:b008:e3a4:fa8c:18d7:a94a:1452]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4168ED0408A; Fri, 24 Aug 2012 16:22:47 -0500 (CDT) References: <20120824173829.13742.qmail@joyce.lan> <5037E028.7090007@Commerco.Net> User-Agent: K-9 Mail for Android In-Reply-To: <5037E028.7090007@Commerco.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 24 Aug 2012 17:22:30 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 24 Aug 2012 21:22:51 -0000 Commerco WebMaster wrote: >John, >On 8/24/2012 11:38 AM, John Levine wrote: >>> When an SPF publisher employs the -ALL syntax in a DNS SPF TXT >record >>> and the result of a receiver MTA's SPF processing is an SPF FAIL, >the >>> receiving MTA (or any downline MTAs to which it or its successive >>> forwarders must forward messages by reason of the receiver's local >>> policy [e.g., downstream antispam analysis machines, DMARC >implementers, >>> etc.]) MUST NOT allow the message to ever reach the MUA(s) of the >final >>> RCPT TO address(es) in the message under any circumstance (i.e., the >>> final mail recipients MUST NOT ever receive messages which fail SPF >-ALL >>> processing), nor should such -ALL SPF FAIL messages ever be used to >>> impugn the reputation of the domain publisher. >> >> No. This proposal is equally ill-advised. >> >> SPF is about defining a way for mail-sending domains to publish >> policies about sending hosts, and for recipient systems to find out >> what a domain's policy is about a particular host. > >Absolutely correct. What I am trying to suggest in the above is that >the recipient systems should respect the published policies of the >sending hosts when there is 100% certainty about the interpretation of >the published SPF DNS TXT record for a domain. > >Certainly in basic situations like "v=spf1 -all", the intent is always >that "the domain you asked about does not send email". Changing that >to >be anything other than what that it really is seems wrong. > >> >> It is most definitely not about MUA design, or what a recipient >> system does with the policy information it has available. >> > >Again, absolutely agree. My wording was deliberate to allow for the >possibility of a pass through for an SPF -ALL "Fail" as long as the >MTAs >always do two things. > >1 The MTAs receiving a forwarded "Fail" message must never allow a MUA >to get hold of such a message. > >2 The MTAs which receive the message never use a "Fail" message to >create a problem for a domain's reputation. > >I suggest that if in the "v=spf1 -all" example, failing to do either of > >the above if the original receiver passes along an SPF "Fail" seems >rather unfair to an SPF publisher and sort of defeats the point or at >least diminishes the value in a domain holder publishing an SPF record >using the -ALL syntax. Yes, but the "S" in SPF stands for sender, not receiver. Trying to specify what actions receivers should take would be completely novel in 4408bis. The goal of this bis exercise is to get through it with a minimum of novelty. Rehashing the (intentional) lack of specified receiver policies in 4408, and thus also 4408bis isn't helping. Scott K From hsantos@isdg.net Fri Aug 24 17:10: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 7ED3821F85A0 for ; Fri, 24 Aug 2012 17:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGI8cS1XzzG2 for ; Fri, 24 Aug 2012 17:10:19 -0700 (PDT) Received: from listserv.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5C72221F8598 for ; Fri, 24 Aug 2012 17:10:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2378; t=1345853416; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QPlwWw0fNikzWo4hOAtprsi9cpg=; b=oGySrQ2WGl3jyHTodyFO SrfIDGkchpx3JGOSC1vdm6DK/PAASWwWVxCRHe8zSjh7NQJR46+Z14dxZ8VoZp9c jMvkCLO5FwfsyEjO6/mAGkeMHVzgBdDvG+VovE1p1BRuOL4HCOzlMhr1wOjwdgVR b0/N39UjWBdmoyCfoAt8mlc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:10:16 -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 1875211962.2162.2628; Fri, 24 Aug 2012 20:10:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2378; t=1345853221; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3/D/0s2 /T9BzWI680QE+V518CyOjN4Iphfu+5y0VUMA=; b=LUSHrWUyq7d8wQqUuTPN3DX G96MjaHEkAIMmutgP9okB4fpDGptPkrbNX79+l5qjmMjfO2l/DSdGxHXpK9rM2Lf +9jm/fYc4LQSSa8I7/Pqkm1rtV3VWVaZFsoIMm6qE7CRjujji3kqAXh75kOsa/45 n0Zfx0ux+SVNe3zQB3GE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:07:01 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2474018739.9.5360; Fri, 24 Aug 2012 20:06:59 -0400 Message-ID: <503817F2.6080308@isdg.net> Date: Fri, 24 Aug 2012 20:10:26 -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: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> In-Reply-To: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 00:10:20 -0000 S Moonesamy wrote: > I strongly suggest not to pursue further discussion about rejecting mail > on SPF Fail as a requirement. Please post a message to the SPFBIS > mailing list if you have any objection to the above. No one has ever stated that Rejecting Mail on Fail was a requirement. However, it is part of the protocol for implementation to design software for to satisfy section 2.5.4 and section 2.3: See RFC4408 section 2.3 2.3. Publishing Authorization An SPF-compliant domain MUST publish a valid SPF record as described in Section 3. This record authorizes the use of the domain name in the "HELO" and "MAIL FROM" identities by the MTAs it specifies. If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made. This is important and can be read many ways! Now, lets look at the pertinent rev 06 changes: 2.3. Publishing Authorization ... SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Some can reasonable state this makes the argument stronger for the PROTOCOL for rejection or classifying mail in a negative way IFF when the DOMAIN publish a strong policy using -ALL. But no one has ever stated that REJECTING was a requirement. Section 2.5.4, as you point out, clearly makes that point. There are two "can" options: - REJECT - ACCEPT WITH MARKING (Receiver-SPF, see section 7) However, in fact, by RFC4408 section 7, a 3rd option is available: - ACCEPT WITH NO MARKING Since adding a Receiver-SPF is an recommendation but not a MUST. Yet, the advocates who have decided to reinforce the idea of ACCEPT+MARKING in the name of reporting and feeding unknown advanced message eval systems, a valid concept, need to also be aware there are repercussions with an ACCEPT+MARKING that are not negatively handled as RFC4408 section 2.3 states and in rev-06 makes it more clear. -- HLS From hsantos@isdg.net Fri Aug 24 17:13: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 70F7421F85A7 for ; Fri, 24 Aug 2012 17:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0cVdCtY+E4d for ; Fri, 24 Aug 2012 17:13:29 -0700 (PDT) Received: from listserv.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 644E921F85A4 for ; Fri, 24 Aug 2012 17:13:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3216; t=1345853607; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yw1YqbnSoiEyIHloVBxOsyR9JGk=; b=uby1QlaxAlLADs4XiJMS TPKfks/zJ8xC5qAeSlC4Yer9xZ18aYjkvNBae81k9UztJFZJrP1UOmpY3UxTKy+A CCun2yco3c2AHtivqaHIwlhBgN5x/lvzbdAGYbMHW4VwSWBtfZfm7ZbpFYr5/ozF 7auhTVl5FR2iXzg+QjIDES4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:13:27 -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 1875402267.2162.5104; Fri, 24 Aug 2012 20:13:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3216; t=1345853411; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4nf992p UAiJ3lE6RHYPgrELkoMD76VBcYTj+SGoJZRY=; b=MhSODHsqtfcbEJxlzg+i2Oy 3nCsZfYZAIiWlWjJGe1bx422sg+cSncLRfhev5V/7tZAtq5Kxkn567nJESEUf11v qXT5eC020I/pcUNEj49yrTm6x22s3RYpcge0WhzrAKEidnivq3uFAiEc/4vvU92c 1MitQKeq4z0W+Mg5IXdY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:10:11 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2474209630.9.6856; Fri, 24 Aug 2012 20:10:10 -0400 Message-ID: <503818B2.4020102@isdg.net> Date: Fri, 24 Aug 2012 20:13:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120824173829.13742.qmail@joyce.lan> <5037E028.7090007@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 00:13:30 -0000 Scott Kitterman wrote: > > Commerco WebMaster wrote: > >> John, >> On 8/24/2012 11:38 AM, John Levine wrote: >>>> When an SPF publisher employs the -ALL syntax in a DNS SPF TXT >> record >>>> and the result of a receiver MTA's SPF processing is an SPF FAIL, >> the >>>> receiving MTA (or any downline MTAs to which it or its successive >>>> forwarders must forward messages by reason of the receiver's local >>>> policy [e.g., downstream antispam analysis machines, DMARC >> implementers, >>>> etc.]) MUST NOT allow the message to ever reach the MUA(s) of the >> final >>>> RCPT TO address(es) in the message under any circumstance (i.e., the >>>> final mail recipients MUST NOT ever receive messages which fail SPF >> -ALL >>>> processing), nor should such -ALL SPF FAIL messages ever be used to >>>> impugn the reputation of the domain publisher. >>> No. This proposal is equally ill-advised. >>> >>> SPF is about defining a way for mail-sending domains to publish >>> policies about sending hosts, and for recipient systems to find out >>> what a domain's policy is about a particular host. >> Absolutely correct. What I am trying to suggest in the above is that >> the recipient systems should respect the published policies of the >> sending hosts when there is 100% certainty about the interpretation of >> the published SPF DNS TXT record for a domain. >> >> Certainly in basic situations like "v=spf1 -all", the intent is always >> that "the domain you asked about does not send email". Changing that >> to >> be anything other than what that it really is seems wrong. >> >>> It is most definitely not about MUA design, or what a recipient >>> system does with the policy information it has available. >>> >> Again, absolutely agree. My wording was deliberate to allow for the >> possibility of a pass through for an SPF -ALL "Fail" as long as the >> MTAs >> always do two things. >> >> 1 The MTAs receiving a forwarded "Fail" message must never allow a MUA >> to get hold of such a message. >> >> 2 The MTAs which receive the message never use a "Fail" message to >> create a problem for a domain's reputation. >> >> I suggest that if in the "v=spf1 -all" example, failing to do either of >> >> the above if the original receiver passes along an SPF "Fail" seems >> rather unfair to an SPF publisher and sort of defeats the point or at >> least diminishes the value in a domain holder publishing an SPF record >> using the -ALL syntax. > > Yes, but the "S" in SPF stands for sender, not receiver. Trying to specify what actions receivers should take would be completely novel in 4408bis. The goal of this bis exercise is to get through it with a minimum of novelty. > > Rehashing the (intentional) lack of specified receiver policies in 4408, and thus also 4408bis isn't helping. I don't see it as rehashing. Just serving reminder of its original purpose and intent with the new reinforcing that ACCEPT+MARK is actually more popular that one may otherwise believe. It takes two to tango in client/server protocol. The S in SPF may be "Sender" (client) but it means nothing without a Receiver (server). -- HLS From hsantos@isdg.net Fri Aug 24 17:24: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 0695821F85F9 for ; Fri, 24 Aug 2012 17:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.741 X-Spam-Level: X-Spam-Status: No, score=-101.741 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7khtqt7vxoc for ; Fri, 24 Aug 2012 17:24:51 -0700 (PDT) Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4921F8456 for ; Fri, 24 Aug 2012 17:24:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2169; t=1345854282; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=El+YEfOkg9KEs4P4ikv086AhZkU=; b=Yfeu10dmDlEhnxJB3NSA eXFhhHJSU3OdHHh1kwpnUre9ITfy0S6wfzVuX9AiRaN88hEHOdO06uoF2o6JEFtU ZNV6bodLEY9pesZRPNzjUPYqZJUpZDIJPZKFrC/Jk19Cvz1xF0efX6Y2OB89cTda Md5DDZ3SHm/YrdpC7vQqaE0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:24: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1876077393.2162.1064; Fri, 24 Aug 2012 20:24:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2169; t=1345854086; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=K/5r2zp 8jgXxFIaTPr4ri6JDVEPNjiNPXvzjPEjApB4=; b=vSKgn07mBJAMqsnbmxlwwU8 oYFnIYbjs1gF1fNP/ILv93fnDEKXcwFkRQBXAZF36UWxLpuwYUyftQ7u89I0gUT7 qoMrd53G2gdjqQnOaWaL6x/SroqPzytahbhX/6c4D1S3QGyYrTqvLntImcxwILRr fAktrkSXYZsRVnw8JoNQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:21:26 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2474883770.9.2020; Fri, 24 Aug 2012 20:21:25 -0400 Message-ID: <50381B53.7040905@isdg.net> Date: Fri, 24 Aug 2012 20:24:51 -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: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <20120824184903.GJ60243@crankycanuck.ca> <5037DB5B.8030004@isdg.net> <20120824201056.GL60243@mx1.yitter.info> In-Reply-To: <20120824201056.GL60243@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 25 Aug 2012 00:24:52 -0000 Andrew Sullivan wrote: > > On Fri, Aug 24, 2012 at 03:51:55PM -0400, Hector Santos wrote: >> SPF yields 16% among the total 82% rejection rate of the >> transactions. By switching to accept+mark, we would be exposing >> these currently SPF -ALL rejects to end users. Having this security >> note will help implementators under the same situations. >> >> Consider the alternative, by not having the security note, in >> effect, 4408 is mandating a certain design all mail systems must >> have to help protect the accept+mark mail recipients and the domains >> that are using -ALL. > > I think you may be conflating "implementation" and "deployment" here. Perhaps, since we are software vendors with an implementation that need to service various deployment options, methods and flexibility. We also have our own support site and I champions and users of the products we design, develop and market. My responsibility is to lead my customers with the best options for them, out of the box, by default and hopefully it matches (I think so), practical and industry methods. > I think you have observed, correctly, that under some deployment > scenarios the MTA that receives mail that does not pass a check > probably does need to reject the mail, because that MTA's clients may > not have the capability to evaluate the mail in question. That is not > the same thing, however, as saying that this or that action on the > part of the MTA are required as part of the protocol, for > interoperability reasons strictly construed. I think the topic has been pretty simple. The protocol has semantics for a functional specification. The technical specification reveals an security issue that in my engineering experience, MUST be noted, otherwise it can fall thru the cracks. It has nothing to do with local policies, mandates, receiver vs sender policies, This is a client/server protocol. The "S" in SPF does say "Sender" (client) but it means nothing with the Receiver (server). Whatever the functional specs says is possible, is also important to make sure all views, including mail security related, are make available. -- HLS From hsantos@isdg.net Fri Aug 24 17:28: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 4FBCE21F8554 for ; Fri, 24 Aug 2012 17:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZq6Uhes3i+y for ; Fri, 24 Aug 2012 17:28:21 -0700 (PDT) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C75021F853E for ; Fri, 24 Aug 2012 17:28:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=673; t=1345854497; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=P4ppj/LU+kCApqyz0eKk+LhaWJw=; b=tk0+KtA4C13ht1JMXqNu k2cC7Ud6dxCvOIGhpUAptweXjiTmTcktYX5g+yxcyq3OVTuSeRDri0IVUgCVtjwv FJG3r5ZK+BruTuTq6BJVllYrU/rdMO0FGRr57iKtdfMlbTOsV1e1OEhlnmpqKeyv WwWw+YHwfEdHKFyFZD5bfFk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:28:17 -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 1876292659.2162.4156; Fri, 24 Aug 2012 20:28:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=673; t=1345854302; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=KA7ZMpf wvRGXm5p4ajvHDvKM4dbMYaRpmMIhuuKI/XE=; b=YblIPQ/ASWZJDvIXBsXMGit o7j0qmTp7SOdnPQGbyT2kMizlQs010d5cOgcYEAQl50s5ZnViE2jd4w1iHOy9VJI 8zKa/tyRxgKSyZROVuzT88xZEnLSwZFnTnTlYwvg3iwXvgkrASQnSjN7Vhaw2gGB B8bRXPA+pplH5ZZ1dj+k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:25: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 2475100770.9.2512; Fri, 24 Aug 2012 20:25:02 -0400 Message-ID: <50381C2D.7040505@isdg.net> Date: Fri, 24 Aug 2012 20:28:29 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20120823044025.11984.71550.idtracker@ietfa.amsl.com> <16215316.XYRRSdKXvA@scott-latitude-e6320> <5036FC84.8090008@isdg.net> <5037C660.9090406@isdg.net> <20120824184903.GJ60243@crankycanuck.ca> <5037DB5B.8030004@isdg.net> <20120824201056.GL60243@mx1.yitter.info> <50381B53.7040905@isdg.net> In-Reply-To: <50381B53.7040905@isdg.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 Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.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, 25 Aug 2012 00:28:22 -0000 correction: Hector Santos wrote: > > I think the topic has been pretty simple. The protocol has semantics > for a functional specification. The technical specification reveals a > security issue that in my engineering experience MUST be noted, > otherwise it can fall thru the cracks. It has nothing to do with local > policies, mandates, receiver vs sender policies, This is a > client/server protocol. The "S" in SPF does say "Sender" (client) but it > means nothing without the Receiver (server). Whatever the functional specs > says is possible is also important to make sure all views, including > mail security related, are made available. -- HLS From sm@elandsys.com Fri Aug 24 17:37: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 CF64221F85FC for ; Fri, 24 Aug 2012 17:37:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNX6PigLub33 for ; Fri, 24 Aug 2012 17:37:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 752C421F8581 for ; Fri, 24 Aug 2012 17:37:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7P0bEkn020524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 17:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345855052; bh=Kn5NMB+DdAJyfho7Cf56WNslLs7zsWChYDQTGokAdGc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YRJlwIv2k6808XNR3m3DJsOik3Xt+24bIZgnQW4/JAxn0A308QhrCNpC6498/D0oz LsvaUxZgQsC4B9GKXJsNoaSvefa7D8O5Za6DU2nPTEYy8xTug/7Ki6TKvrbwvGclTN HmYzh/0f11MnLDDi8/f1e20syUJSwD+T/gbb8sZQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345855052; i=@elandsys.com; bh=Kn5NMB+DdAJyfho7Cf56WNslLs7zsWChYDQTGokAdGc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JRsVcxOCTqzjNb4PEK9LD7Vi7G5l579VM6ckJniWQ4+y8WmY3NsWAqedBBzgP7wIH iwCGeBhQoAnrptlH1+5g7weZb8MxyiBRH5YI5hH+7klZyTzzQ2ZWJv2WQoyX0pQ4iN qqvBDxZzcoFqTwsiWsjoSiBNfXtLVFnL1FB7sy4Y= Message-Id: <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 17:33:32 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <503817F2.6080308@isdg.net> References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 00:37:35 -0000 Hi Hector, At 17:10 24-08-2012, Hector Santos wrote: >No one has ever stated that Rejecting Mail on Fail was a >requirement. However, it is part of the protocol for implementation >to design software for to satisfy section 2.5.4 and section 2.3: > >See RFC4408 section 2.3 > > 2.3. Publishing Authorization > > An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3. This record authorizes the use of the domain name in > the "HELO" and "MAIL FROM" identities by the MTAs it specifies. > > If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made. I could not find any normative text that states that mail SHOULD or MUST be rejected on SPF Fail in the text quoted above. Is this an objection to message posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html ? > - ACCEPT WITH MARKING (Receiver-SPF, see section 7) > >However, in fact, by RFC4408 section 7, a 3rd option is available: > > - ACCEPT WITH NO MARKING > >Since adding a Receiver-SPF is an recommendation but not a MUST. > >Yet, the advocates who have decided to reinforce the idea of >ACCEPT+MARKING in the name of reporting and feeding unknown advanced >message eval systems, a valid concept, need to also be aware there >are repercussions with an ACCEPT+MARKING that are not negatively >handled as RFC4408 section 2.3 states and in rev-06 makes it more clear. With all due respect, the message I posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was about rejecting mail on SPF Fail as a requirement. It is not related to "accept with marking" or accept with no marking". Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Fri Aug 24 17:45: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 6558A21F85A3 for ; Fri, 24 Aug 2012 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHkFOE+tFtgM for ; Fri, 24 Aug 2012 17:45:43 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 859CD21F8595 for ; Fri, 24 Aug 2012 17:45:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1453; t=1345855542; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ufsKaXbE0Cu/Gqddie7xsQIqQog=; b=me13IQ87yiva0p43FCbA petEW6bM4t+tcyVucCQMF4wLCEkB+beywBXeMV+GRm10IeTWqt3k3MqWQeeQwg+B juFGHpS0F3tyH9YTlWC21BB2Jcg8ZknXv1zUzGLk6TZvyKIwz5i5LsYY6h3a+iQW /ozV3wbuc4ixjxL2WCsKRaE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:45: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1877337850.2162.5460; Fri, 24 Aug 2012 20:45:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1453; t=1345855349; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vVtlGvq THKuKy2b/Cdt9DatCc/i6fOom4uAs1iUmces=; b=Ub5jCYHvnsV4g2YLxHb4y77 3BW1Wl3/n4gn4MvqK9Dz3WitmZtyTa3ucXEDxBrcuWbCzOsdiJ59kQVe6ch6mfwF ZTTiVnSL5C3tk7dj4blNt1wUQiAMI4fvt0DWhWOdwtpJi4M5Ka9e0PkXK34sVCp5 z7/7PxMKBsN0IUaG3Glk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 20:42:29 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2476147474.9.5740; Fri, 24 Aug 2012 20:42:28 -0400 Message-ID: <50382043.9090206@isdg.net> Date: Fri, 24 Aug 2012 20:45:55 -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: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 00:45:44 -0000 S Moonesamy wrote: >> Yet, the advocates who have decided to reinforce the idea of >> ACCEPT+MARKING in the name of reporting and feeding unknown advanced >> message eval systems, a valid concept, need to also be aware there are >> repercussions with an ACCEPT+MARKING that are not negatively handled >> as RFC4408 section 2.3 states and in rev-06 makes it more clear. > > With all due respect, the message I posted at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was > about rejecting mail on SPF Fail as a requirement. It is not related to > "accept with marking" or accept with no marking". What other options does an implementator have to offer deployments? Based on my reading on RFC 4408 (and still with rev-6), there are three option in the technical programming extracted from functional specification: Per Section 2.5.4 - Reject - Accept, Add Receiver-SPF (and/or Auth-Res with rev-6) Per Section 7 - Accept, do not add Receiver-SPF or Auth-Res The point is that there was never a requirement for Rejecting on SPF Fail. It was just one of the options for handling a -ALL. The semantics are provided in Section 2.5.4 and in 2.3. The domain is providing a "HINT" to the receiver on how to handle the mail and in the case of -ALL policies, it is shooting for a negative classification. That could be rejection or accept+marking per section 2.5.4 What I am missing here? -- HLS From sm@elandsys.com Fri Aug 24 18:01: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 AFD7821F85D5 for ; Fri, 24 Aug 2012 18:01:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEOPgbFe6AXj for ; Fri, 24 Aug 2012 18:01: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 18F8721F8464 for ; Fri, 24 Aug 2012 18:01:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7P10wxs001456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 18:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345856470; bh=tV99qEiQjELPd2tlCyHJ4tqmRKsieRysdupavsn2UC0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fzc6vH8ImTdL+rLBK0sV0fQlh+dBrX/Hpx96rE3wVTixCa+Se8K8ToDtUywRRh4AH Es5TmyDP9SpPfMejemLFOv1Y7Sxsy1rzbX/g5FdiNKilEn/35ja9aqSibB/R2FEtI+ 7Bek4/oe1sSYzeuV3iRkzDjwd+zUmS8hPp2nfeEs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345856470; i=@elandsys.com; bh=tV99qEiQjELPd2tlCyHJ4tqmRKsieRysdupavsn2UC0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tu3ENapaU6nqhxbVOa0bHaq/90QOUn1ZRRdz1Df5UOn8LsRfFNPMy/K3GdyEsXqFJ sVK20vfYpYUaKOyDqEuhTvl7i2FJ/n9FvxJ48BMJPnrKqhVTw9YDXcryFEDAkblzZx m4ZOp5ebcZn5jXWx7ljM1aI18ZneVJkkbJeE3OcM= Message-Id: <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 18:00:10 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <50382043.9090206@isdg.net> References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> <50382043.9090206@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, Hector Santos Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 01:01:12 -0000 At 17:45 24-08-2012, Hector Santos wrote: >What other options does an implementator have to offer deployments? The message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was not about discussing options. Rejecting mail on SPF Fail as a requirement is outside the scope of the SPFBIS WG Charter ( https://datatracker.ietf.org/wg/spfbis/charter/ ). Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Fri Aug 24 18:16: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 3D6F121F8525 for ; Fri, 24 Aug 2012 18:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrM4DUZPJZo2 for ; Fri, 24 Aug 2012 18:16:37 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C5F2E21F853C for ; Fri, 24 Aug 2012 18:16:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1309; t=1345857387; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KGLNWW960rEFsE+B+1Yv7BWMU9M=; b=Rb1Eoup667Lo8zT7F7KL STO7vJ1bH967/MEeyeeywvkFkzLgUOtAMEE6EivrjH5lNNsh3WItmpm3MbdKCrto +UuAS73yWdshPFjsOvASBIBSTFisEPbQay06s0araKmTTvq/WxQjYDe6Dv8Nm3X5 bQkO584rvFDyfsxeTR7p20M= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 21:16:27 -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 1879183014.2162.1540; Fri, 24 Aug 2012 21:16:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1309; t=1345857194; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/GD6N3Q LsqfFmCHBATHXmXYiiJTF5APKxtQpWx2eJdk=; b=Gg933XvnJ7K4PJZ9/fCVOMP vENAu9hOuOVVd7ftCrKhm5I/SYL8gWSVimdHuR9fhXuducEeinZOlmOKyzN7MxG9 4AZFv+lSgOc1hoSPjqyILmpi3gACHdKp7z4lIt5OpW8MLz/P8BAQblWLljtMR7K1 5cfcYrR9wrIkoMG5lJ8I= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 24 Aug 2012 21:13:14 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2477992411.9.4740; Fri, 24 Aug 2012 21:13:13 -0400 Message-ID: <50382777.1020006@isdg.net> Date: Fri, 24 Aug 2012 21:16:39 -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: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> <50382043.9090206@isdg.net> <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 01:16:39 -0000 S Moonesamy wrote: > At 17:45 24-08-2012, Hector Santos wrote: >> What other options does an implementator have to offer deployments? > > The message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was > not about discussing options. Rejecting mail on SPF Fail as a > requirement is outside the scope of the SPFBIS WG Charter ( > https://datatracker.ietf.org/wg/spfbis/charter/ ). SM, There was a note for any objection to be posted: Please post a message to the SPFBIS mailing list if you have any objection to the above. I was not objecting. I was basically pointing out it is a moot point, never was an exclusive requirement and I don't know where it started or anyone getting the idea that is was the only exclusive requirement. I might have stated that for a specific implementation, Rejecting on SPF fail may be their only feasible, practical and most protocol secured method of operation that will both follow and spirit and intent of an -ALL policy. The DOMAIN will not complain for a reject and it will not be in violation of the protocol specification by no means. But as an exclusive mode of operation? Of course not, so I am not sure why we are going there with this. Just trying to understand why the hammer is coming down. -- HLS From sm@elandsys.com Fri Aug 24 18:55: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 9A01C21F8576 for ; Fri, 24 Aug 2012 18:55:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fyxI9X7tFtN for ; Fri, 24 Aug 2012 18:55:36 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9A21F8554 for ; Fri, 24 Aug 2012 18:55:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7P1tL00023319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 18:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345859735; bh=edTB6VMXoWIBfSieZ9y1Zxw5rnswQpti9g0qUodTJro=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4n8x8Sm7LZ33TChSdd7gMdB4vhJNt9UvN7tuJ7yV3nUgqdaGge7o87lKBduL4vyyJ yCdiEvcEjC0HSR+PiWLahoTpbhfFBWw3DK+w1/6IFMt+EhVotaK/GUgR7gzVrtmQUW LZXErqfssWxBtHnvMi8lu+1G9/uN6RWApfKWt3vo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345859735; i=@elandsys.com; bh=edTB6VMXoWIBfSieZ9y1Zxw5rnswQpti9g0qUodTJro=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ld3ukaIKDr2Z3GwNAvepQttjRQm8tV79T0qb3FdxRBXFwgL48WFOvp7AiKnGFbIyA 3B1nUGK1ezh0K41HBVh+sh47rpQHEnwW8NvPVTePLs+AYjwjqN9ILMWZpdt4vqOpWR 32TOloje4PMmIwIyJLI8b8MosBvRkTujMBRNwqiE= Message-Id: <6.2.5.6.2.20120824182542.0628c510@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Aug 2012 18:54:11 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <50382777.1020006@isdg.net> References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> <50382043.9090206@isdg.net> <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> <50382777.1020006@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 01:55:36 -0000 Hi Hector, At 18:16 24-08-2012, Hector Santos wrote: >There was a note for any objection to be posted: > > Please post a message to the SPFBIS mailing list if you > have any objection to the above. > >I was not objecting. I was basically pointing out it is a moot >point, never was an exclusive requirement and I don't know where it >started or anyone getting the idea that is was the only exclusive requirement. I'll quote the entire paragraph: "I strongly suggest not to pursue further discussion about rejecting mail on SPF Fail as a requirement. Please post a message to the" SPFBIS mailing list if you have any objection to the above." I don't see any reason to pursue the discussion as there isn't any objection. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Sat Aug 25 01:14:37 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 9372821F8508 for ; Sat, 25 Aug 2012 01:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXlbvSZ7w77F for ; Sat, 25 Aug 2012 01:14:35 -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 1C72721F850C for ; Sat, 25 Aug 2012 01:14:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7P8EDpG009849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Aug 2012 01:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345882466; bh=zRl6rp0Wq0J56ZPj0vdhJE9/GvAzSobbkDlJCu7AgUo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=IBoVm3M3emUOtf1cxHY2ouWjDFewTq8unsSzFFORMLh+N+RIKHOlODuhqwExk2sQX p0GII0+toQO1PmdOxZ8JyZfHtdSIRF0oz9/mX5FA8uw+jYAueK+QWv7C3GS7HQH/xI GdaKQQEsr3zxzqxu2TpGwi/xPVjNkXwkJjzo8B88= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345882466; i=@elandsys.com; bh=zRl6rp0Wq0J56ZPj0vdhJE9/GvAzSobbkDlJCu7AgUo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=AC8BPhkaAs3lm2BqFzt/qOFw9AHaSA+h/6WNmqpYsbB3wHs6Z+NLi0mlM0IhIrEs0 PwmciOVj/naw/Xg6rnu2ZNft6vdmvNXGnDwsrZU+HG46HgIx8N/3qkz/sGDM/ZgCQX mZN9Y5l6r0/AW2nH9WZ/gqnziD/wdptBAtExyTyk= Message-Id: <6.2.5.6.2.20120824235717.0626ec78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Aug 2012 01:13:59 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120823065110.094b1138@resistor.net> References: <5035BD24.7020304@isdg.net> <6.2.5.6.2.20120823065110.094b1138@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 08:14:37 -0000 Dear SPFBIS WG, The text below is from Section 7 of RFC 4408: "It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. If an SMTP receiver chooses to do so, it SHOULD use the "Received-SPF" header field defined here for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.)" The following text is from Section 2.5.4 of draft-ietf-spfbis-4408bis-06: "If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 7) to communicate this result to downstream message processors. While this is true for all SPF results, it is of particular importance for "fail" results since the message is explicitly not authorized by the domain owner." I consider the above as a significant change to Section 2.5.4. And from Section 7 of draft-ietf-spfbis-4408bis-06: 'It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. There are two methods for doing this: the Received-SPF header field defined here and the more generic Authentication-Results header field defined in [RFC5451]. Because these fields are generally used within a receiving ADMD, it is a local policy choice which to include. In general, the more broadly applicable Authentication-Results header field ought to be used, but it SHOULD be used in such a way that it conveys the same information that the verifier would have provided in a Received-SPF header field if that had been used. If an SMTP receiver chooses to do so, it SHOULD use one of these header fields for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.)' I consider the above as a significant change to Section 7. I'll skip Section 7.1 for now. From Section 7.2: 'As mentioned in Section 7, the Authentication-Results header field is designed to communicate lists of tests a border MTA did and their results. The specified elements of the field provide less information than the SPF-Received field: Authentication-Results: myhost.example.org; spf=pass smtp.mailfrom=example.net Received-SPF: pass (myhost.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from="myname@example.com"; helo=foo.example.com; It is, however, possible to add CFWS in the "reason" part of an Authentication-Results header field and provide the equivalent information. Receivers SHOULD include the same information they would have provided if they had used the Received-SPF field. The reason SHOULD include a key-value-list with keys provinding information normally included in a Received-SPF header field that is not already part of the Authentication-Results header field. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". Authentication-Results header fields can contain results for more than one authentication, so one field can provide results for both an "MAIL FROM" check and an "HELO" check. reasonspec = A suitably enhanced Authentication-Results header field might look like (for a "MAIL FROM" check in this example): Authentication-Results: myhost.example.org; spf=pass reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" smtp.mailfrom=user@example.net' I consider the above as a significant change. I am concerned that it may lead to the document updating RFC 5451. That would be outside the scope of what this working group is chartered to do. In a message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02275.html WG participants were given some leeway to work things out. Please note that even though I have not seen any more arguments from Douglas Otis I will take the arguments which he submitted on April 25, 2012 into consideration ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ). I will have a discussion next week with Andrew Sullivan to determine what to do if the different views cannot be reconciled. My default will be no change. Regards, S. Moonesamy SPFBIS WG co-chair From vesely@tana.it Sat Aug 25 03:16: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 D2AC921F8523 for ; Sat, 25 Aug 2012 03:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcSATgbDcf4y for ; Sat, 25 Aug 2012 03:16:57 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC7721F8466 for ; Sat, 25 Aug 2012 03:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345889814; bh=970yX96LpvcZX8cjLXKbQsyKOLktrBb/cfwekXwzSmY=; l=2216; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eAxwhqhBmkatg72+26T/kZ9LSIBZSt9KDCGwBt/+Iezf1SvHOaHM3Ad6iXneBleuh 7v6XV2GaxXX+ZNtbWJWfHQHAMkbec4/Iigk6PVlH1ivpu0WljQzsy5GFOiGOXwKun3 aOf+LlkNbHXxUIVSN/1e3D06kbdncV3hBRXmo45Q= Received: from [109.115.54.124] ([109.115.54.124]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 25 Aug 2012 12:16:53 +0200 id 00000000005DC033.000000005038A615.00001562 Message-ID: <5038A603.7040700@tana.it> Date: Sat, 25 Aug 2012 12:16:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.8fc523097c72015c9070758bb9755960@tools.ietf.org> <6.2.5.6.2.20120822141618.09972010@elandnews.com> <20086782.TyIbvIWLSl@scott-latitude-e6320> <6.2.5.6.2.20120823214532.095f5458@resistor.net> <50371D64.4040400@Commerco.Net> <50373472.1000705@Commerco.Net> <5037E9E2.8080706@Commerco.Net> In-Reply-To: <5037E9E2.8080706@Commerco.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [spfbis] Check-before-forwards, was Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 10:16:57 -0000 On Fri 24/Aug/2012 22:53:54 +0200 Commerco WebMaster wrote: > On 8/24/2012 11:41 AM, Murray S. Kucherawy wrote: >> >> User A sends to user B, who has forwarding arranged to address C. >> Said forwarding leaves the envelope sender unmodified. [...] > > If a publisher plans to have forwarding in their environment by user > demand or as a market driven decision, perhaps the ~ALL syntax is > better for them. B forwards on its own, without telling to A, let alone following its plans. >> User A sends to B which forwards to C. C rejects due to SPF failure. >> B is doing the forwarding inline, so it also rejects. A now thinks B >> is a bogus address when in fact it is not. This is a variant of the >> first case, which means A can't ever send mail to anyone that >> forwards. > > Well, perhaps. If B has checked SPF and found A as valid, it should > never conclude that the address from A was bogus by virtue of a bounce > from C. The problem is with the original poster A, not B. A newly added paragraph introduces check-before-forward semantics: (part 2, bullet 3, of Section 9.2.2 http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06#section-9.2.2 BTW, how about having sub-subsections for those parts?) User A sends to B. B has a forwarding "recipe" to C, but it checks SPF as if it were C before doing so. That way, B finds that, if it forwards the message, C will compute a "fail" for it. Then, rather than replying 251 to the RCPT command, it replies 551 to reject it. The author gets a bounce notifying the change of address at B. If B and C have no special relationship with A, the SPF check from C's POV that B carried out is similar to the SPF check from D's POV that C would carry out in a more involved case A -> B -> C -> D where B accepted the message. In the latter case, C can reject with 551, and B can send a bounce because it had an SPF "pass" from A. I propose to grant full citizenship to this technique by introducing it somewhere in Section 2. It requires an extra check_host() evaluation, with different input. Although it can be considered a change, it is fully backward compatible, so I think it's feasible if the WG agrees on it. From vesely@tana.it Sat Aug 25 04:10:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5793021F84EC for ; Sat, 25 Aug 2012 04:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wo0kdnUhigk for ; Sat, 25 Aug 2012 04:10:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE921F84EA for ; Sat, 25 Aug 2012 04:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345893003; bh=ZoQMEfVJ/4WuFfEDr5kP58n3azQL/tLZbJUE4zrT/v4=; l=1038; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=bapzpB282wJqUGxZrdpFc8ajInyFJStehec6gM65qOFFGmZ/MN7a2jek9/NdNDY8U AsjIb14UZntyLTaFQhp2ZI4lcqMVwSSY2/flSbjQYed3ADdL+31Mz6GEnV2HvomNAD vPwhislW744nM9sPJ3x/oxvFYw/ERMalAxxG0FFU= Received: from [109.113.201.70] ([109.113.201.70]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 25 Aug 2012 13:09:59 +0200 id 00000000005DC03F.000000005038B288.0000221F Message-ID: <5038B27D.6070001@tana.it> Date: Sat, 25 Aug 2012 13:09:49 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> In-Reply-To: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 11:10:05 -0000 Hi SM, WG, chairs, On Fri 24/Aug/2012 23:13:24 +0200 S Moonesamy wrote: > > I strongly suggest not to pursue further discussion about rejecting > mail on SPF Fail as a requirement. Please post a message to the > SPFBIS mailing list if you have any objection to the above. It is obviously ridiculous to state that SPF is not concerned with the possibility to reject mail. IMHO, it is an hysterical second best to consider receiver policies as casually related to SPF, rather than an integral part of it. The acrobatics that the RFC 4408 exhibits, albeit valuable, seem to be a consequence of the MARID climate. Have we cooled down? Then let's put a MAY or whatever, for the sake of a clearer spec. OTOH, if we're still unable to discuss this subject constructively, I accept SM's suggestion as quoted above. In the latter case, however, I'd appreciate if the reasons to ban such discussions are explained in more depth: Such analysis may also be useful whenever further work on SPF will be taken into consideration. From spf2@kitterman.com Sat Aug 25 07:01: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 22A3B21F84DD for ; Sat, 25 Aug 2012 07:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAaPqGhNTCno for ; Sat, 25 Aug 2012 07:01:36 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8CD21F8484 for ; Sat, 25 Aug 2012 07:01:36 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E7CE4D0408D; Sat, 25 Aug 2012 09:01:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345903295; bh=4yXWQDxjdBDgj1U+rkDz5wKJRSN/Vi1CE9rPJdL3sko=; h=Subject:From:Date:To:From; b=cFz7OKtv1WCeKjVgp48pRibF0oZfSlJt7T0U+corz7zRxzi2778+cHV+G4JD6FerC fRuWEg4iCWHapQdAIUjrgZ+Mimq4c/wAwpcsavbdnhaTUzpBoftmprsCq/Cg0oua/j IFRHST7UbTWZCrr+bB797NMgXk7seLba/2V1uRJI= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A94BBD0408A; Sat, 25 Aug 2012 09:01:35 -0500 (CDT) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 25 Aug 2012 10:01:33 -0400 To: spfbis@ietf.org Message-ID: <10899e88-9896-40a4-8627-c2e1bf7117c4@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 14:01:55 -0000 Alessandro Vesely wrote: >Hi SM, WG, chairs, > >On Fri 24/Aug/2012 23:13:24 +0200 S Moonesamy wrote: >> >> I strongly suggest not to pursue further discussion about rejecting >> mail on SPF Fail as a requirement. Please post a message to the >> SPFBIS mailing list if you have any objection to the above. > >It is obviously ridiculous to state that SPF is not concerned with the >possibility to reject mail. IMHO, it is an hysterical second best to >consider receiver policies as casually related to SPF, rather than an >integral part of it. The acrobatics that the RFC 4408 exhibits, >albeit valuable, seem to be a consequence of the MARID climate. > >Have we cooled down? Then let's put a MAY or whatever, for the sake >of a clearer spec. OTOH, if we're still unable to discuss this >subject constructively, I accept SM's suggestion as quoted above. In >the latter case, however, I'd appreciate if the reasons to ban such >discussions are explained in more depth: Such analysis may also be >useful whenever further work on SPF will be taken into consideration. This has nothing to do with MARID. REC 4408 was written by people who were involved in SPF before MARID and who weren't much influenced by it. The lack of receiver policy requirements is not accidental. MAY is not a requirement. Scott K From sm@elandsys.com Sat Aug 25 09:39: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 9134621F84A6 for ; Sat, 25 Aug 2012 09:39:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSq60-8TXvdf for ; Sat, 25 Aug 2012 09:39: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 DC51121F84A1 for ; Sat, 25 Aug 2012 09:39:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7PGdW2S011230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2012 09:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345912784; bh=+v9Jj/cMaBEKYcJzaYhrZd6gMfda8jIK+iaS0XqpJMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AT5gxIISfO5rukKmjOrD6C0EX3+5Qmzc5/qONYqyN4TsgZvIyMcPhf8+ttlkmVga2 ZSKPwLK/3N8md04tVO6lyC1SGP0rePURLV37VYsUtGuFqelUzDExAokKmKGgoUmb+4 xlB6MwS9G1ZSuKxtiFbNmUrjPKiL16is+RWyDJaA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345912784; i=@elandsys.com; bh=+v9Jj/cMaBEKYcJzaYhrZd6gMfda8jIK+iaS0XqpJMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=otrA4lISxxPfqkeVYbIzFoIhRpqujfx3eWBojc93wnG5AKoBG6ZURFe5xx4Y3SlSb w4dIn4V2mUhnDrDIjHJbW5HHVwxC2FFANuokbI7hINLKUYANzmJOIsILO5mZeLfvTK DI7CutkqUTNOuFA7MNCjWqe6pJhcLW3cw+8hD4ig= Message-Id: <6.2.5.6.2.20120825074644.0999d658@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Aug 2012 09:37:08 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <5038B27D.6070001@tana.it> References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <5038B27D.6070001@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 16:39:47 -0000 Hi Alessandro, At 04:09 25-08-2012, Alessandro Vesely wrote: >It is obviously ridiculous to state that SPF is not concerned with the >possibility to reject mail. IMHO, it is an hysterical second best to >consider receiver policies as casually related to SPF, rather than an >integral part of it. The acrobatics that the RFC 4408 exhibits, >albeit valuable, seem to be a consequence of the MARID climate. I gather that the above is an objection to the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html I mentioned in that message that I could not find any normative text that states that mail SHOULD or MUST be rejected on SPF Fail. I do not see any arguments in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02344.html about normative text that states that mail SHOULD or MUST be rejected on SPF Fail. I do not have any opinion about whether RFC 4408 exhibits any acrobatics or what might have caused that. I read both RFC 4408 and draft-ietf-spfbis-4408bis. If I notice a change, I find out whether it is according to what is in the SPFBIS Charter ( https://datatracker.ietf.org/wg/spfbis/charter/ ). Whether I like the change or not is immaterial. My task is to see that the WG deliverable is completed according to the guidance I received. >Have we cooled down? Then let's put a MAY or whatever, for the sake >of a clearer spec. OTOH, if we're still unable to discuss this >subject constructively, I accept SM's suggestion as quoted above. In >the latter case, however, I'd appreciate if the reasons to ban such >discussions are explained in more depth: Such analysis may also be >useful whenever further work on SPF will be taken into consideration. I consider any addition of a MAY, SHOULD or MUST as a substantive change as such a change can have an impact on existing implementations. The "for the sake of a clearer spec" is not one of the better arguments in my opinion. In a moderator note dated April 20, 2012, Andrew Sullivan mentioned that the topic of "reject on fail" was closed ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01340.html ). A quick glance through the archives will show that the topic resurfaced. A thorough read of the archives will show that there hasn't been any new arguments. Regards, S. Moonesamy SPFBIS WG co-chair From sklist@kitterman.com Sat Aug 25 10:00: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 7F33321F84F8 for ; Sat, 25 Aug 2012 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIbVkbE14PRl for ; Sat, 25 Aug 2012 10:00:56 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E83AD21F84F1 for ; Sat, 25 Aug 2012 10:00:55 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 20A23D0408D; Sat, 25 Aug 2012 12:00:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345914055; bh=78aZh1hXiK8p4MC9qJC95JPWKpcrMNLmNjS6GFSP8IQ=; h=Subject:From:Date:To:From; b=jV2MoSbRvmjsYTn2KX/SpXJlbncRoOBgIixhmXPMe1QzAfSfvioI1gsXSqZLvlqZG ahPTVoaND4D/jdLMG+jdBGjec4e/zg87Y9Ci+iN0vwciFRq4RxViqNu6otmwzOhVKj xfJ0v18flnaue/IqIGsbYVj0U0iHhHG+TedXXyws= Received: from [IPV6:2600:1003:b014:5834:e9b2:8ff:90df:e143] (unknown [IPv6:2600:1003:b014:5834:e9b2:8ff:90df:e143]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A3D3BD04051; Sat, 25 Aug 2012 12:00:54 -0500 (CDT) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 25 Aug 2012 13:00:52 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 25 Aug 2012 12:49:33 -0700 Subject: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 17:00:56 -0000 Upon reflection, I think a lot if the recent dialog on this list is based on a misunderstanding about what a 'sender policy' is in SPF terms. A sender policy is not about a sender telling a receiver what to do. A sender policy is a statement that mail was either sent in accordance with the sender's policy (pass), it wasn't (fail), or one of several varieties of uncertainty. That's all. Scott K From dhc@dcrocker.net Sat Aug 25 14:04: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 76DD321F850D for ; Sat, 25 Aug 2012 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELwlVkKVZ4XP for ; Sat, 25 Aug 2012 14:04:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D9DF621F8508 for ; Sat, 25 Aug 2012 14:04:10 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7PL48kl024568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Aug 2012 14:04:09 -0700 Message-ID: <50393DBE.3000704@dcrocker.net> Date: Sat, 25 Aug 2012 14:03:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Kitterman References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 25 Aug 2012 14:04:10 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? 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: Sat, 25 Aug 2012 21:04:11 -0000 On 8/25/2012 10:00 AM, Scott Kitterman wrote: > Upon reflection, I think a lot if the recent dialog on this list is > based on a misunderstanding about what a 'sender policy' is in SPF > terms. A sender policy is not about a sender telling a receiver what > to do. A sender policy is a statement that mail was either sent in > accordance with the sender's policy (pass), it wasn't (fail), or one > of several varieties of uncertainty. 1. Clarity about the role of this specification is essential. 2. For SPF and other, recent email "policy" work, there is a persistent confusion about the meaning of the specification and the extent to which a sender can or should attempt to "dictate" behaviors by receivers. 3. I am not finding language in the current draft that attempts the kind of clarity Scott's above text has. So I think we should add language of the sort that in the last two sentences, above. Clarify what it is. Clarify what it is not. Scott's language looks like a good start and maybe a good finish. The text I'd suggested adding to his two sentences is: A receiver is provided these sender statements as guidance, to use as they wish in the handling of a message. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Sat Aug 25 14:21: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 9120621F84FC for ; Sat, 25 Aug 2012 14:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNxz+aO1YDQS for ; Sat, 25 Aug 2012 14:21:24 -0700 (PDT) Received: from catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8324921F84A1 for ; Sat, 25 Aug 2012 14:21:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1992; t=1345929675; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0athgFCrneobxl0+vj+8VLbH9ck=; b=rx6rcMmy2B1QkkDGTDwS cOO1HomGGRGQ0AVaTUv5JDat8tDb9tt08n85CPqFJZ7yIEev4jDSjUqM+hkBEkky hw3tMbJGe1YYIBksDtopuV1ysKOgrmcRvJ3IEJobwgr9gyTnaTTTQpjsMQhuW2Q4 641YB0lAhLDRHJ2ixf4PVpk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 25 Aug 2012 17:21:15 -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 1951469322.3420.5416; Sat, 25 Aug 2012 17:21:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1992; t=1345929479; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4NNOJbn PPe1TJ518Ryz06ssbrLQ1i5PJUVjub/pdYWo=; b=cA0te4a5wBtI5S+oEv+2M/X 0WJBpR4YgrXHDV6DmIAmfr9kZtI7Kg3o7fMqgXBOTIpe5BdKgQCH5xWoCVWRCSpd vNjPNU+ZtjfzGXArQeRMSYJe8qDc3domrl4Ua9HJW6FqI6Zg1BlFatGQlqOiwA8Y toC7r0X5ZluiQR6Th/Ds= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 25 Aug 2012 17:17: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 2550276677.9.5484; Sat, 25 Aug 2012 17:17:57 -0400 Message-ID: <503941BF.3000404@isdg.net> Date: Sat, 25 Aug 2012 17:21:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 21:21:25 -0000 At the risk of being excommunicated in this WG, I disagree with this assessment and this placement of misunderstanding. Its the same old argument from the past and a waste of processing time, cost of development, support, overall "time" to debate what is essence of a client/server protocol, any one; the problem and the solution it offers to address the problem (read abstract), the payoff, its purpose in life. -ALL has always had a special meaning, despite how a receiver wishes to honor or deviate from the protocol functionality specification. It has always been very clear, 2.3 doubled it and to my surprise reinforced it in rev6. Yet, there were those opposed to this level of strength in the same way SSP has issues with it strong exclusive policies. It is not an accident that that new confusion and chaos are seeded by the same advocates of both protocols. Mind you, they are valid concerns too. But like anything else, we needed SPF to solve a real problem no other protocol was available to address. SPOOFS are real and what IMV what needs to appreciated is that there are those who strongly believed in deterministic solutions as as there were those that believed in heuristic (belated processing/learning) solutions, a.k.a Reporting like protocols. No one should be trumping the other and that IMV has been the conflict. I wish we can finally get over it. Scott Kitterman wrote: > Upon reflection, I think a lot if the recent dialog on this list is based on a misunderstanding about what a 'sender policy' is in SPF terms. A sender policy is not about a sender telling a receiver what to do. A sender policy is a statement that mail was either sent in accordance with the sender's policy (pass), it wasn't (fail), or one of several varieties of uncertainty. > > That's all. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Sat Aug 25 15:35: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 0E82421F848F for ; Sat, 25 Aug 2012 15:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIqQxEhqbQtF for ; Sat, 25 Aug 2012 15:35:33 -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 245CE21F8466 for ; Sat, 25 Aug 2012 15:35:32 -0700 (PDT) Received: by lahm15 with SMTP id m15so1906627lah.31 for ; Sat, 25 Aug 2012 15:35:32 -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=ix2M5pcrn2ZvERiJfTInmeQM+xzeKDgb+G/G4ad4p1U=; b=BulSbQ3cwpzB/kuXVFXDUCFrz9EVZenfy2O8J+QmgTxxrHIJh5EbjyVGFTtQXGU0xp 2fPGpegWZCmhT94n9e23dd4p5uElKl1g86Tmvm24VJpfep/xPHzwEhoneBU2MewrtNzB nvM/Nr/jcIl8+XS/ZcxdRZWDbsYZe7uJqpOXxTZedYD8N2TBNlylXUXiQeL+iafathke rnOXVJ8quVN2K63hdCceU4clu1+XULwEb1sx5hnJ4T2YeVc8SaVw8nWOgQd00wxv7cCY VUDRjec5PfcjwE8A11AKOD8it/k+2zDc7vuglb3DMyUaCH832lBVLfogFdGLyzmLthdP Cg1g== MIME-Version: 1.0 Received: by 10.112.28.4 with SMTP id x4mr4425403lbg.105.1345934131968; Sat, 25 Aug 2012 15:35:31 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 25 Aug 2012 15:35:31 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120824235717.0626ec78@resistor.net> References: <5035BD24.7020304@isdg.net> <6.2.5.6.2.20120823065110.094b1138@resistor.net> <6.2.5.6.2.20120824235717.0626ec78@resistor.net> Date: Sat, 25 Aug 2012 15:35:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 22:35:34 -0000 On Sat, Aug 25, 2012 at 1:13 AM, S Moonesamy wrote: > In a message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02275.html WG > participants were given some leeway to work things out. Please note that > even though I have not seen any more arguments from Douglas Otis I will take > the arguments which he submitted on April 25, 2012 into consideration ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ). I will > have a discussion next week with Andrew Sullivan to determine what to do if > the different views cannot be reconciled. My default will be no change. I agree that there are substantive changes in this area since RFC4408, and I'm aware at how increasingly allergic to change we are. However, our charter does explicitly permit us to accommodate the "addition of any enhancements that have already gained widespread support". I don't believe anyone disputes the claim that RFC5451 is in substantial use, including for SPF, so I submit that this is an appropriate topic. I also think that what the -06 draft currently says goes beyond what's necessary, at least in terms of its normative language if not in general. It should be sufficient to point out the two available options for post-MTA communication, explain why we're documenting two of them, and leave it there. In the message you cited, you referenced a proposal I made that I think needs more discussion. -MSK From spf2@kitterman.com Sat Aug 25 15:37: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 5CECE21F8469 for ; Sat, 25 Aug 2012 15:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+bDCcfcSW4z for ; Sat, 25 Aug 2012 15:37:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE521F8466 for ; Sat, 25 Aug 2012 15:37:13 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 68EE0D0408D; Sat, 25 Aug 2012 17:37:12 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345934232; bh=7AC7RrrQUfSU6h9I0lOntmCEzMixPzGp1IWIhOooctI=; h=References:In-Reply-To:Subject:From:Date:To:CC:From; b=MkuN3RcvBzTQiocdlS+MpUUMLLtjardAYHaUccPHOVKoDeXR5a+rDBNjk8VDFx21E SjLMVX3KxbIYjwwFmw/eXgbiFgxwx83W004prrt8NftlLY3Q1rhXAF9JDilKlFfGPu odZZYjNqB6Z2hawtb+0A7pgmv68rAcZWI7dinZnY= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id F0B54D04051; Sat, 25 Aug 2012 17:37:11 -0500 (CDT) References: <503941BF.3000404@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <503941BF.3000404@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 25 Aug 2012 18:37:09 -0400 To: Hector Santos Message-ID: <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 22:37:14 -0000 It's not new this misunderstanding. This 'special meaning' is documented nowhere. Scott K Hector Santos wrote: >At the risk of being excommunicated in this WG, I disagree with this >assessment and this placement of misunderstanding. Its the same old >argument from the past and a waste of processing time, cost of >development, support, overall "time" to debate what is essence of a >client/server protocol, any one; the problem and the solution it >offers to address the problem (read abstract), the payoff, its purpose >in life. > >-ALL has always had a special meaning, despite how a receiver wishes >to honor or deviate from the protocol functionality specification. It >has always been very clear, 2.3 doubled it and to my surprise >reinforced it in rev6. Yet, there were those opposed to this level of >strength in the same way SSP has issues with it strong exclusive >policies. It is not an accident that that new confusion and chaos are >seeded by the same advocates of both protocols. Mind you, they are >valid concerns too. But like anything else, we needed SPF to solve a >real problem no other protocol was available to address. SPOOFS are >real and what IMV what needs to appreciated is that there are those >who strongly believed in deterministic solutions as as there were >those that believed in heuristic (belated processing/learning) >solutions, a.k.a Reporting like protocols. No one should be trumping >the other and that IMV has been the conflict. I wish we can finally >get over it. > > >Scott Kitterman wrote: >> Upon reflection, I think a lot if the recent dialog on this list is >based on a misunderstanding about what a 'sender policy' is in SPF >terms. A sender policy is not about a sender telling a receiver what >to do. A sender policy is a statement that mail was either sent in >accordance with the sender's policy (pass), it wasn't (fail), or one of >several varieties of uncertainty. >> >> That's all. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> >> > >-- >HLS From superuser@gmail.com Sat Aug 25 15:43: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 B936A21F84A6 for ; Sat, 25 Aug 2012 15:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1TnkJPHFuz5 for ; Sat, 25 Aug 2012 15:43: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 EA02B21F84A5 for ; Sat, 25 Aug 2012 15:43:19 -0700 (PDT) Received: by lbky2 with SMTP id y2so1100896lbk.31 for ; Sat, 25 Aug 2012 15:43: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:content-transfer-encoding; bh=UAFfpp8waC7nFCRcpWaMZZ53l4zCJVRuvkEAj9ZkNl4=; b=CbbWUO8clOUnz1hq0aQ1AcMBRhunoDK8LhKP8N0dhrPRz70noDGR7pkN3NW/osE4Kh /cAeYEsjIsb10iGEadZI0+MhxCseNNGFQKCo/xn81+P2ESJ1W6sX3UD7GWaQ2MGgg6Am SNdvUGn6sGjpCLiNOi2Fntrv+MCnWs8MxQX500ciUpyKr1kq0dV+VcTS5KIIorFjkFpT 1URkDQTWuL5ECja8hrWfTbmWJ/7MUnqCxKFtKsx+Gq1up/reUMD6t9sXyDU32o2jAXEO q8JXQn3Is8p9Sdlqsw4tfaXpMw73srKvGJuks1OJdcEAg9fcGnVHFF6TxVR7uUCAdIy/ n8KQ== MIME-Version: 1.0 Received: by 10.152.130.3 with SMTP id oa3mr9864166lab.27.1345934598925; Sat, 25 Aug 2012 15:43:18 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sat, 25 Aug 2012 15:43:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Aug 2012 15:43:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 22:43:20 -0000 On Sat, Aug 25, 2012 at 10:00 AM, Scott Kitterman wr= ote: > Upon reflection, I think a lot if the recent dialog on this list is based= on a misunderstanding about what a 'sender policy' is in SPF terms. A sen= der policy is not about a sender telling a receiver what to do. A sender po= licy is a statement that mail was either sent in accordance with the sender= 's policy (pass), it wasn't (fail), or one of several varieties of uncertai= nty. +1. Also, I think Dave made an important point that went largely ignored: We know a lot more about a message that passes SPF or DKIM than one that fails, because failures can happen for so many valid reasons. -MSK From hsantos@isdg.net Sat Aug 25 16:14: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 B6FE621F84E1 for ; Sat, 25 Aug 2012 16:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okEvNpBq2CCV for ; Sat, 25 Aug 2012 16:14:01 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8121F84A1 for ; Sat, 25 Aug 2012 16:14:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3946; t=1345936425; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lfkg5kYHnjy5o5jOGbr0l1+BiKk=; b=QXXtY16rM8H1IpslnIiL Hr3dz1lcvBF26bwJgtBppRjc/DcKkvZgdcoYPEGuK5UnMZqpowPuCOIVgFZbResT 3v+DACxj/MZuEMFknPiv4GpCczY3fMb8IcCQMwIfbhU4j4r/QnMyRrjSubqd6v47 TOPqUFZvlNCvq52HR8ZOSKc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 25 Aug 2012 19:13:45 -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 1958219610.3420.4088; Sat, 25 Aug 2012 19:13:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3946; t=1345936230; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=P/vsWIW Z8i324Vcs4CK0ivbsJDTKEFphDAjc+nv8VeI=; b=sIrYEpjEOwn/h9Z6IPcVDdr yeohe/geLavh72RvACcDY3gyVMBy9+HjZz7c3h2U33xm/yGCFZObN2d/mUwziCxE ModReCql0WgH1ITaWP+K8eD71/8Ylj/EpwCTpCFzt30gob4eO3KeW2BcgT7K9ubM xU8Zn/QJSd9boyecZ+y0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 25 Aug 2012 19:10:30 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2557028130.9.6524; Sat, 25 Aug 2012 19:10:29 -0400 Message-ID: <50395C1F.9010600@isdg.net> Date: Sat, 25 Aug 2012 19:13:35 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> In-Reply-To: <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Aug 2012 23:14:01 -0000 Scott Kitterman wrote: > It's not new this misunderstanding. This 'special meaning' is documented nowhere. By "Special Meaning," I hope we can agree that -ALL has an unique semantic over others policies in RFC4408. As 2.3 has it, ... so that a definitive determination of authorization can be made. or as rev6 has it: ... otherwise, no definitive determination of authorization can be made. or as 2.5.4 says to mark or reject exclusively only for a -ALL fail result. Are we now saying this was never the intent for receivers to behave this way specifically and exclusively only possible with -ALL? I would call that a "special meaning" over the other possible policies in SPF. I agree there has been always the dispute on how strong one believes a receiver should honor the SPF, even SSP even ADSP similar "special meaning" policies of super strong authorization. Your proposal I don't believe will change this either way. I guess what I am at lost with this current topic and similar concerns is what exactly we are are trying to convey to receivers about what domain publishes? What exactly are they responsible for as an SPF "receiver" processor, the #1 essential component of the SPF client/server protocol? My concern is what is the end result, more ACCEPT+MARK actions? Ok, I don't see a problem with this new focus and emphasis because it doesn't remove the alternative, but it does highlights security concern - issue #33. If you think you need to add something, perhaps you can borrow text as it was done with RFC5016 in section 5.3, item 10 for the very same concerns of having "special meanings" with strong policies. Paraphrasing it for SPF: INFORMATIVE NOTE: the main thrust of -ALL is that this practice should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. -- HLS > Scott K > > Hector Santos wrote: > >> At the risk of being excommunicated in this WG, I disagree with this >> assessment and this placement of misunderstanding. Its the same old >> argument from the past and a waste of processing time, cost of >> development, support, overall "time" to debate what is essence of a >> client/server protocol, any one; the problem and the solution it >> offers to address the problem (read abstract), the payoff, its purpose >> in life. >> >> -ALL has always had a special meaning, despite how a receiver wishes >> to honor or deviate from the protocol functionality specification. It >> has always been very clear, 2.3 doubled it and to my surprise >> reinforced it in rev6. Yet, there were those opposed to this level of >> strength in the same way SSP has issues with it strong exclusive >> policies. It is not an accident that that new confusion and chaos are >> seeded by the same advocates of both protocols. Mind you, they are >> valid concerns too. But like anything else, we needed SPF to solve a >> real problem no other protocol was available to address. SPOOFS are >> real and what IMV what needs to appreciated is that there are those >> who strongly believed in deterministic solutions as as there were >> those that believed in heuristic (belated processing/learning) >> solutions, a.k.a Reporting like protocols. No one should be trumping >> the other and that IMV has been the conflict. I wish we can finally >> get over it. >> >> >> Scott Kitterman wrote: >>> Upon reflection, I think a lot if the recent dialog on this list is >> based on a misunderstanding about what a 'sender policy' is in SPF >> terms. A sender policy is not about a sender telling a receiver what >> to do. A sender policy is a statement that mail was either sent in >> accordance with the sender's policy (pass), it wasn't (fail), or one of >> several varieties of uncertainty. >>> That's all. >>> >>> Scott K -- HLS From srs0=bcclp=g2=gathman.org=stuart@fairfax.gathman.org Sat Aug 25 18:16: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 3A29E21F84A5 for ; Sat, 25 Aug 2012 18:16: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB+A40i7kMsU for ; Sat, 25 Aug 2012 18:16:29 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 833EE21F849D for ; Sat, 25 Aug 2012 18:16:29 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q7Q1GMpc015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Aug 2012 21:16:23 -0400 Received: from silver.gathman.org ([192.168.10.211]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id q7Q1GMVd019963 for ; Sat, 25 Aug 2012 21:16:22 -0400 Message-ID: <503978E6.9080201@gathman.org> Date: Sat, 25 Aug 2012 21:16:22 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <503817F2.6080308@isdg.net> <6.2.5.6.2.20120824171638.07a517c0@elandnews.com> <50382043.9090206@isdg.net> <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120824174636.078ceae8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 01:16:50 -0000 On 08/24/2012 09:00 PM, S Moonesamy wrote: > At 17:45 24-08-2012, Hector Santos wrote: >> What other options does an implementator have to offer deployments? > > The message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was > not about discussing options. Rejecting mail on SPF Fail as a > requirement is outside the scope of the SPFBIS WG Charter ( > https://datatracker.ietf.org/wg/spfbis/charter/ ). I don't think we really care whether mail with SPF Fail is rejected or not. I think what we are looking for is something along the lines of, "Don't blame (alleged) sender". I.e. whatever the recipient does with the email, any reputation should not accrue to the MAIL FROM, and no emails should be sent to abuse@mailfromdomain. No DSNs or other bounces should be sent to the alleged MAIL FROM. The no bounces part is actually the original motivation for SPF. The rejecting, not so much. From spf2@kitterman.com Sat Aug 25 19:06: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 3CC3721F84F1 for ; Sat, 25 Aug 2012 19:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh3mI+MacAyo for ; Sat, 25 Aug 2012 19:06:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5321F845D for ; Sat, 25 Aug 2012 19:06:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2233220E410A; Sat, 25 Aug 2012 22:06:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345946765; bh=02+iifCmWuwNqaLux3gYpyuRS9dHcC4tmx7MOotbc5s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jcP45VSvReOKC2Mco7k+cABMUnodKenRFtJnpQwGKMcBrUC5UK6T0xbrgJhF3w3TC G4Dsk/WWWXg58z4GdIivd/8JU+72twhv1wvf4+kJwd3sreUOHV9nss1j0n5o1+g89s /57NsVNOeLU9nYhWb4gSvkPswzpbwrHdRJ2MQi80= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E563D20E40B2; Sat, 25 Aug 2012 22:06:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 25 Aug 2012 22:06:04 -0400 Message-ID: <2002019.BGudIUEfKV@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50395C1F.9010600@isdg.net> References: <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@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] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 02:06:07 -0000 On Saturday, August 25, 2012 07:13:35 PM Hector Santos wrote: > Scott Kitterman wrote: > > It's not new this misunderstanding. This 'special meaning' is documented > > nowhere. > By "Special Meaning," I hope we can agree that -ALL has an unique > semantic over others policies in RFC4408. As 2.3 has it, > > ... so that a definitive determination of authorization can be made. > > or as rev6 has it: > > ... otherwise, no definitive determination of authorization can be > made. > > or as 2.5.4 says to mark or reject exclusively only for a -ALL fail > result. > > Are we now saying this was never the intent for receivers to behave > this way specifically and exclusively only possible with -ALL? > > I would call that a "special meaning" over the other possible policies > in SPF. Pre-MARID drafts say: Fail (-): the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] section 7.1.) So reject has never been more than a MAY. Clearly that has is still the case. I think that "message does not meet a domain's definition of legitimacy" is very close to my statement today that the message is not from an authorized source. I believe that what I'm saying is very consistent and unchanged and if you think it's not, you need to revisit your assumptions. Don't forget that SPF was originally Sender Permitted From. Nothing changed when the acronym changed. That's a more accurate name for SPF. Scott K From ajs@anvilwalrusden.com Sat Aug 25 19:11: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 E24F021F8493 for ; Sat, 25 Aug 2012 19:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH8S2cbg1z8L for ; Sat, 25 Aug 2012 19:11:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 401A121F846F for ; Sat, 25 Aug 2012 19:11:39 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EBBB38A031 for ; Sun, 26 Aug 2012 02:11:37 +0000 (UTC) Date: Sat, 25 Aug 2012 22:11:39 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120826021139.GB83954@mx1.yitter.info> References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50395C1F.9010600@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 02:11:40 -0000 Hat in hand. On Sat, Aug 25, 2012 at 07:13:35PM -0400, Hector Santos wrote: > By "Special Meaning," I hope we can agree that -ALL has an unique > semantic over others policies in RFC4408. As 2.3 has it, > > ... so that a definitive determination of authorization can be made. > > or as rev6 has it: > > ... otherwise, no definitive determination of authorization can be > made. It is plainly true that -ALL has different semantics compared to other things. One should hope that to be true, or else there'd be no reason to have it in the protocol. But there is nothing about it or anything else in SPF that has any binding on a receiver. By definition it _cannot_ be binding on a receiver, because there are lots of receivers who just don't process SPF. > Are we now saying this was never the intent for receivers to behave > this way specifically and exclusively only possible with -ALL? That is a false alternative. -ALL tells you something about what a sender claims is the case at its site. What you do with that information is entirely up to you. This is the force of Scott's emphasis of it being a _sender_ policy. If someone wishes to spin up a WG that is the Receiver Policy Framework, which dictates what implementing receivers MUST, MUST NOT, MAY do (and so on), I encourage such people to write those drafts. But in my opinion, what receivers do is just none of our (SPFBIS's) business. If people wish to pursue continued discussion about telling receivers of SPF-covered mail how to behave, I'm going to want to see a pretty good argument -- much better than I've seen so far -- why we ought to do that or why it is even remotely on charter. "Remotely on charter" means that you need to show how the text in 4408 is obscure, how current practice has settled matters, and how that links up with the specific tasks in our charter. Further discussion without meeting these necessary conditions is just off-topic for the WG. Please, I am asking, stop. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Sat Aug 25 22:13: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 C7BD521F84F1 for ; Sat, 25 Aug 2012 22:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.143 X-Spam-Level: X-Spam-Status: No, score=-111.143 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OEIuAcks3Yc for ; Sat, 25 Aug 2012 22:13:38 -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 EB24221F8460 for ; Sat, 25 Aug 2012 22:13:37 -0700 (PDT) Received: (qmail 27154 invoked from network); 26 Aug 2012 05:13:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2012 05:13:34 -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=5039b07e.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=x27jChZDMDBYiXc1mEQ/VxxATELB5F1JCkmgkjjgy9U=; b=RbNtyQgYwxAi9jZvCJ3YurhRVzDtRSvBcUcxHC6kORcIv+St1sJurNBftWMZ6nSdy9eCM27OUXV+h2+WtNj0acl2ZBvymhlFtnl/7zLQsIaLAoCc2t+zbN/STCg5WuLOYRUE0hADoA1I2Jn8K2GZaf9jeyMDewV9DMo3wPlRdjY= 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=5039b07e.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=x27jChZDMDBYiXc1mEQ/VxxATELB5F1JCkmgkjjgy9U=; b=EIMlTL7+PVDU2FUiJq2lFyNWWyZjaSf6O6w5mN2dJfQ+eaBq8VokVi47epW+4IKw69MB5o2T1L/SznpQT5rOk5bhjiK9R7YimsJrRf6ng2cHE41tacZHqiDnc660qXKV/E0ikq4vk5H+pGYNeh8SK/9t5bMjYYW0eR//AY4+Dto= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Aug 2012 05:13:12 -0000 Message-ID: <20120826051312.34721.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] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:13:39 -0000 >I also think that what the -06 draft currently says goes beyond what's >necessary, at least in terms of its normative language if not in >general. It should be sufficient to point out the two available >options for post-MTA communication, explain why we're documenting two >of them, and leave it there. Agreed. The stuff about how to hide extra information in A-R comments really doesn't belong in a standards track document. If someone thinks that it would be a good idea if A-R headers included more details about SPF results, do a separate draft to update RFC 5451. R's, John From spf2@kitterman.com Sat Aug 25 22: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 5D35A21F84F1 for ; Sat, 25 Aug 2012 22:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIZm35-IutgZ for ; Sat, 25 Aug 2012 22:20:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93421F847B for ; Sat, 25 Aug 2012 22:20:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EE59020E410F; Sun, 26 Aug 2012 01:20:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345958404; bh=mqiFbJaFufiFHyU6aZeXgI4RhXutMbHj4XCfr2MOS8U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VkVx7HBrQeqTLc5gJOGTXbf95+GJsiftsJ7dVCArtgF8sewMr0TDkooNquYzCP2oX GmoftUca+ADTP9C+eTHGocMWz4RpXKHGGi1sXSPoopNeuBnLR+vasSmhsfk691emaO UCArovWiJm7ZJ55Inr/aVVacemo/cTrdR7wiD1do= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C1DEB20E410A; Sun, 26 Aug 2012 01:20:03 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:20:02 -0400 Message-ID: <2038344.xmME5XhsPg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <5035BD24.7020304@isdg.net> <6.2.5.6.2.20120824235717.0626ec78@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] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:20:07 -0000 On Saturday, August 25, 2012 03:35:31 PM Murray S. Kucherawy wrote: > On Sat, Aug 25, 2012 at 1:13 AM, S Moonesamy wrote: > > In a message at > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02275.html WG > > participants were given some leeway to work things out. Please note that > > even though I have not seen any more arguments from Douglas Otis I will > > take the arguments which he submitted on April 25, 2012 into > > consideration ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ). I > > will have a discussion next week with Andrew Sullivan to determine what > > to do if the different views cannot be reconciled. My default will be no > > change. > I agree that there are substantive changes in this area since RFC4408, > and I'm aware at how increasingly allergic to change we are. However, > our charter does explicitly permit us to accommodate the "addition of > any enhancements that have already gained widespread support". I > don't believe anyone disputes the claim that RFC5451 is in substantial > use, including for SPF, so I submit that this is an appropriate topic. > > I also think that what the -06 draft currently says goes beyond what's > necessary, at least in terms of its normative language if not in > general. It should be sufficient to point out the two available > options for post-MTA communication, explain why we're documenting two > of them, and leave it there. > > In the message you cited, you referenced a proposal I made that I > think needs more discussion. Suggestions on changes please. I considered addition of A-R to 4408bis appropriate under the terms of the widespread support aspect of the charter. The question is how best to characterize it. Received-SPF is a trace header that carries, in addition to SPF results additional information to assist readers in understanding what it's trying to communicate and reconstruct decision logic after the fact for diagnostic purposes. A-R as is widely used today communicates less information as it is, by design, focused on communicating the results of multiple types of authentication without emphasis on additional detail or forensics. In the current draft I tried to make a recommendation about how to provide the same information typically provided in Received-SPF in an A-R header field so that it would be suitable as a replacement because it seemed to me that the discussion had been about aiming towards transition and an eventual replacement. Perhaps that was in error and it would be better to position A-R as 'no frills' results only used and Received-SPF as a more verbose vehicle in cases where it's desired. This isn't really right either though since it's quite possible to add all the same information to A-R. Thoughts? Scott K From spf2@kitterman.com Sat Aug 25 22:30:02 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 2E2C121F8513 for ; Sat, 25 Aug 2012 22:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-x6uj58cwOo for ; Sat, 25 Aug 2012 22:30:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A72821F84D9 for ; Sat, 25 Aug 2012 22:30:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1D58920E410A; Sun, 26 Aug 2012 01:30:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345959001; bh=iMEIwRYy/Q+lmGg0kvbBSjzXVBc0aeTST21boUbcCtI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FA8uA1ft9dLWS749urkuikXX82CfJ2Lf2WH/xeMuDqI0Ab58AYCJ69Q1FYQCdLrB4 z0W3dsLSL9KVgyK3ElhEz7pTohvZze9nc+ToP+HD4PKqDZaPM5JGVHbg+xT4kmmFyZ zC2JrDLN6er0uw10XhUaGzEZz+PBBgP6EDZe5ApA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E456E20E40B2; Sun, 26 Aug 2012 01:30:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:30 -0400 Message-ID: <3669562.evm5Ozz3o2@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <1476027.UdxMWrdmeL@scott-latitude-e6320> <6.2.5.6.2.20120822215213.0a04dec8@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] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:30:02 -0000 On Wednesday, August 22, 2012 10:23:33 PM S Moonesamy wrote: > Hi Scott, > > At 21:34 22-08-2012, Scott Kitterman wrote: > >This is a good point. Upon reflection, perhaps it would be better put like > > > >this: > > Properly formed domains are fully qualified email domains as > > described in [RFC5321] Section 2.3.5. For implementations that > > support Internationalized domain names, such domains MUST be > > encoded as A-labels, as described in Section 2.3 of [RFC5890]. > > > >I think that might be more appropriate. I don't think 4408bis is the right > >document to be mandating IDN support in MTAs. > > I have not discussed about this with Andrew. There are different > ways to tackle the issue. In my humble opinion the text suggested > above may be flagged during external review or it may generate a > DISCUSS. I suggest leaving the text as it is for now unless the > working group agrees on the text suggested above or any other text. Reverts as you said to do, but I think that the now current text: Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of .on 2.3 of . is outside the scope of our charter since this is a new requirement and it's not related to a widely deployed extension of SPF, so we need to address it. It may simply be a matter of acknowledging that since SPF records are ASCII, this is the only way to do it. Suggestions? Scott K From spf2@kitterman.com Sat Aug 25 22:38: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 2623511E8097 for ; Sat, 25 Aug 2012 22:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxXdI48OXRLM for ; Sat, 25 Aug 2012 22:38:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E53A521F8443 for ; Sat, 25 Aug 2012 22:38:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 669AF20E410A; Sun, 26 Aug 2012 01:38:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345959488; bh=g8Z0gT2bTTUlIxA9G8U28VzDADEgGKaL686ww3dOHdQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=f4AZvubwaxpIVWh9P/rtsIRY1Q2xo4I5acVFu/N2mmOTIZygylSIOj88ke4ydW5bN HUH0xTv4nyD99Le4XV0YvtuZGO2F/NowvQIqW/wCPt7okAmAeYTLgrF3qnshWqqAaL GezrUMo46jqEt+brDAMxhgaosgiEhAHVaGARNpxo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 365D420E40B2; Sun, 26 Aug 2012 01:38:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:38:07 -0400 Message-ID: <1897816.Ls82plnNjt@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <50350126.2010506@isdg.net> <2050339.9cOfrxQYRQ@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] Formal Request to Reopen ISSUE 29 to close security loophole X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:38:10 -0000 On Thursday, August 23, 2012 06:46:54 AM Murray S. Kucherawy wrote: > On Wed, Aug 22, 2012 at 8:50 PM, Scott Kitterman wrote: > >> I guess I hadn't read 9.3.2 in a while. The first sentence of this > >> paragraph seems to be mangled. > > > > It seems OK to me. > > > > SPF fail results can also be used as one input into a larger set of > > evaluations which might, based on the overall evaluation result in > > the > > email being marked negatively in some way (this might be via > > delivery > > to a special spam folder, modifying subject lines, or other locally > > determined means). > > > > What did you have in mind? Reading it again, I think can also is probably > > better put as can alternately, but I don't think that qualifies as > > mangled. > > The "might" near the front seems to be dangling. Might what? Maybe > this is what's meant: > > SPF fail results can also be used as one input into a larger set of > evaluations which might, based on the overall evaluation result of the > message, be marked negatively in some way (...). > > If so, "might ... being" is the mangling I'm detecting, coupled with > the need for commas. I think adding a comma in the right place was enough. Please take a look at 07 when it comes out and let me know if you think it needs more. > Also, "the overall evaluation result" might be better expressed as "a > combination of other evaluation techniques". Did that too. Scott K From spf2@kitterman.com Sat Aug 25 22:41: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 13EA711E8099 for ; Sat, 25 Aug 2012 22:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qqCvciA2pY7 for ; Sat, 25 Aug 2012 22:41:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF811E8097 for ; Sat, 25 Aug 2012 22:41:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E967520E410A; Sun, 26 Aug 2012 01:41:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345959683; bh=mIXXW8rWYgrsg2EgkGyd9vuyl4RnKTffB4bsR16UHyw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=l8+XCRjAP5DbVCZQjjmcGhZf6pgpydaaT7O09gx5+mRB/mGq9dtar9+OIpIoCv07V s96Hg3Xxr2mh9Roh5kEPOm26vVGRZ0Kfcntl8DfjmWbENoQwSd8FnKPdh0dFyqGVq7 xEqkphr6NgK00TGa4qUx9Tk+raKvSB2vCewngwTQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C3A0D20E40B2; Sun, 26 Aug 2012 01:41:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:41:23 -0400 Message-ID: <8061737.FV0QE38ozW@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <4F912ADF.1070201@tana.it> <6.2.5.6.2.20120823074355.094b13c8@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:41:25 -0000 On Thursday, August 23, 2012 11:05:28 AM Murray S. Kucherawy wrote: > On Thu, Aug 23, 2012 at 8:56 AM, S Moonesamy wrote: > > I believe that it is better if the SPFBIS WG is vendor-neutral. If we > > exemplify the above text it won't be flagged by ID-nits. I will notice it > > during my review. I will have to choose whether to look the other way. > > Other reviewers will also face the same choice. > > > > There has been ample discussion about Issue #12 on this mailing list. > > I'll > > leave it to you (or any other WG participant) to propose an alternative. > > I agree. I'm also concerned with a tendency to include an example of > every possible use of SPF to solve some problem. It feels like it's > getting mighty cluttered. My recollection is that we're collecting things in section 9 and will later decide if it should all stay in 4408bis are be in another document. My intent is to add a vendor neutral variant of this to section 9 and then we can revisit what, if anything, should come out later. Scott K From spf2@kitterman.com Sat Aug 25 22:51: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 EDF7221F845F for ; Sat, 25 Aug 2012 22:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlb7D+zao0Pz for ; Sat, 25 Aug 2012 22:51:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D121F845E for ; Sat, 25 Aug 2012 22:51:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7159620E410A; Sun, 26 Aug 2012 01:51:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345960312; bh=ArQagvlrnfPTUwg87e6mbHOsq22vS0HIpNRei5Qsg+s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IOjcMnC/ZyZ0Q0gf6vR2t49PGaVb+Qw9FvCT38uelhNsZVFBdVhD59ZCrZUfQYbtt AUYec83AT098G5CIKamLegsWS0NyJps1X04NFIvkoAa9apT1PFKQ6pZ/BJrtZCact2 mcopnFdjC3vxTl5odDOGW+pIPUn72VjpguxFoybs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4B47F20E40B2; Sun, 26 Aug 2012 01:51:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:51:51 -0400 Message-ID: <1420392.ivxmA5xrKm@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <8061737.FV0QE38ozW@scott-latitude-e6320> References: <4F912ADF.1070201@tana.it> <8061737.FV0QE38ozW@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] #12: RFC 4408 Section 9 - Forwarding and helo identities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:51:54 -0000 On Sunday, August 26, 2012 01:41:23 AM Scott Kitterman wrote: > On Thursday, August 23, 2012 11:05:28 AM Murray S. Kucherawy wrote: > > On Thu, Aug 23, 2012 at 8:56 AM, S Moonesamy wrote: > > > I believe that it is better if the SPFBIS WG is vendor-neutral. If we > > > exemplify the above text it won't be flagged by ID-nits. I will notice > > > it > > > during my review. I will have to choose whether to look the other way. > > > Other reviewers will also face the same choice. > > > > > > There has been ample discussion about Issue #12 on this mailing list. > > > I'll > > > leave it to you (or any other WG participant) to propose an alternative. > > > > I agree. I'm also concerned with a tendency to include an example of > > every possible use of SPF to solve some problem. It feels like it's > > getting mighty cluttered. > > My recollection is that we're collecting things in section 9 and will later > decide if it should all stay in 4408bis are be in another document. My > intent is to add a vendor neutral variant of this to section 9 and then we > can revisit what, if anything, should come out later. When I looked over section 9, this is very similar, but a much better example than the existing first item for the originating ADMD in 9.2.2, so I updated that to reflect this approach. It ended up shorter. Scott K From spf2@kitterman.com Sat Aug 25 22:53: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 AC4A021F846C for ; Sat, 25 Aug 2012 22:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rYuhn3L8NE4 for ; Sat, 25 Aug 2012 22:53:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 35F0821F846B for ; Sat, 25 Aug 2012 22:53:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AAFA420E410A; Sun, 26 Aug 2012 01:53:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345960431; bh=tjZ4QmbCWXN7prI0CrhpqCfRR28EwKsP2myj1tJ+VzM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=i2Jk233vT63LnxjcbToLQvu6ah+xy3bRHPh6WCFN4pOa4OpXDaBGm/L7FS6F47qqF UPMx5rbBrQY2bV/2d0U0UYdT4o+FVBqAzKLzRdbyuxDmyKk8UYuNbdyN5SZw8ie0y6 FVw2WEt0RhZGtPy0hmMMShiw9T3MyvHhW6xmnHY4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 83B8120E40B2; Sun, 26 Aug 2012 01:53:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:53:50 -0400 Message-ID: <2480847.VqIOrM1vYF@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120826051312.34721.qmail@joyce.lan> References: <20120826051312.34721.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] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 05:53:52 -0000 On Sunday, August 26, 2012 05:13:12 AM John Levine wrote: > >I also think that what the -06 draft currently says goes beyond what's > >necessary, at least in terms of its normative language if not in > >general. It should be sufficient to point out the two available > >options for post-MTA communication, explain why we're documenting two > >of them, and leave it there. > > Agreed. The stuff about how to hide extra information in A-R comments > really doesn't belong in a standards track document. > > If someone thinks that it would be a good idea if A-R headers included > more details about SPF results, do a separate draft to update RFC 5451. If you want A-R to be a replacement for SPF-Received than it need the extra information. If extending 5451 is the right way to handle it, then I think we should just remove it from 4408bis and wait for 5451 bis. Scott K From spf2@kitterman.com Sat Aug 25 22:57: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 971EB21F8448 for ; Sat, 25 Aug 2012 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChSlfX+Q6VGw for ; Sat, 25 Aug 2012 22:57:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F12DB21F8447 for ; Sat, 25 Aug 2012 22:57:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7159C20E410A; Sun, 26 Aug 2012 01:57:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345960668; bh=NO8t8TS6UQ08PqgOCkkhJv7QaLpt4x1CYejG0LGDKIQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DE3HiGrZQlUbJ9uaDvbZaRYYgzksccSGXNS34yRXLAwgGsJiP4yfp9n+Xp4QqPGMF mcfP93eE6/fvH4Ls+wW2Kd4KF4Uu5d22rNjFawtbi1ZmaZ9J8skSViv5QDwoc00qmt t5THUii5ECf9ADAOBWV/4IuIN3ILP6h5HXlLexeg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 426F020E40B2; Sun, 26 Aug 2012 01:57:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 26 Aug 2012 01:57:47 -0400 Message-ID: <1871488.UybePiPivm@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50373979.9080502@tana.it> References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <6.2.5.6.2.20120823122737.0a7c8630@resistor.net> <50373979.9080502@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] Picky on RFC 2119 key words already in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 05:57:49 -0000 On Friday, August 24, 2012 10:21:13 AM Alessandro Vesely wrote: > On Thu 23/Aug/2012 21:45:06 +0200 S Moonesamy wrote: > > "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." > > > > [...] > > > > I would be picky about the "checking software". :-) > > If that means to s/checking software/server/, I agree. > > And there is a lowercase "should" further down, right before the > example, that should be capitalized. Fixed. Found some others too. Scott K From hsantos@isdg.net Sun Aug 26 00:01: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 7AEB521F845C for ; Sun, 26 Aug 2012 00:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdXVBUPGLoNj for ; Sun, 26 Aug 2012 00:01:00 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72321F8459 for ; Sun, 26 Aug 2012 00:01:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=907; t=1345964450; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ScxKxUdozdNzEHUNbTV3Bvnn0k8=; b=W1gnk1heFhJA0FoDP7c9 XiE0Fqqylk2X/nKrXIgk/8uoLleWX3b1qbVM0buZ8uh9gDJ5SLWWEwtw/f7cN5T0 avMFyq+iFggPtyK2WIRFp63o9Wt/fqcaV7R6C+MZe/Mx2gGVZkABxf+vVnRlhqQ2 R6uU+CValLdkNB2JIBzz5qU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 26 Aug 2012 03:00:50 -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 1986244971.4163.6032; Sun, 26 Aug 2012 03:00:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=907; t=1345964255; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+9Bnv74 1i7NtaPjwZ8Go05ibPs8G3b/eklCxoYwQpGg=; b=O8aKt1sgBX3mJg6NSVIvC85 c+RY72uuI7Fn/blir3TwWD1hn5jMvTotLDbZgRiziIaa6PVaH+ux+Tdw9JdVoxsU 5M4JPHhhjsOiYZCOi9fWniep6fMev87sABl95SbngpCQUZnX4jqP2Hxu0b/TJ5yQ g3DBRDM0VlC9aQA2GClU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 26 Aug 2012 02:57:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2585052958.9.7132; Sun, 26 Aug 2012 02:57:34 -0400 Message-ID: <5039C9A1.4070600@isdg.net> Date: Sun, 26 Aug 2012 03:00:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120826051312.34721.qmail@joyce.lan> <2480847.VqIOrM1vYF@scott-latitude-e6320> In-Reply-To: <2480847.VqIOrM1vYF@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 07:01:01 -0000 Scott Kitterman wrote: >> >> If someone thinks that it would be a good idea if A-R headers included >> more details about SPF results, do a separate draft to update RFC 5451. > > If you want A-R to be a replacement for SPF-Received than it need the extra > information. If extending 5451 is the right way to handle it, then I think we > should just remove it from 4408bis and wait for 5451 bis. I should note as the OP of this thread, that regardless if was correct, flexible or not, my concern was 4408bis should present it as a migration, not just as an exclusive replacement since this is going to break existing 3rd party mail bots keying in on Received-SPF and is ignorant of A-R. Unless its specifically designed for a specific local system only or vendor solution, I sincerely doubt any mail-bot developers is going to eliminate support for Received-SPF anything soon. -- HLS From sm@elandsys.com Sun Aug 26 00:14: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 C334B21F847B for ; Sun, 26 Aug 2012 00:14:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP5R5Wni5cqQ for ; Sun, 26 Aug 2012 00:14: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 2A3BF21F847A for ; Sun, 26 Aug 2012 00:14:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7Q7E9ch023870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Aug 2012 00:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345965260; bh=QpZnmo7bsn6K8/JkcQmnxMK3Hjn2POJO613a5yVtRFg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=hzbJ3dOkDCEErCeT0hCtkdQ0l6MZnxM2il+Mbe6fCEJ92mv0lFUiYv0xeF3ALHsrB LMSX55A1+jFZvulGLpD7BE6a6Mr5i70AeN/vzUZ7cr9g5DFIPyaK0ivrgJ3sRlP/Yi 4LZWdf8rwTNgwyeY8zJh5jocwIiUJhfn7GmFVpSo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345965260; i=@elandsys.com; bh=QpZnmo7bsn6K8/JkcQmnxMK3Hjn2POJO613a5yVtRFg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fFZGB1RM4a8eTFJJJM8SYIFae3RYOIQcHMdyQ8lcwoFGvScygtydP7dOsO3Z6jU6j 8Woer5WNRkX+GWdd1RJztzqr6jVBBVHkhV2odN/dqDgfxoUVA4eO/UMC6QMYUCh4Dm UNNymDITdQBfPOLmaChNZYE2QEqRTdUYZ9tRoLgg= Message-Id: <6.2.5.6.2.20120826000436.0975dbc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Aug 2012 00:13:27 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <3669562.evm5Ozz3o2@scott-latitude-e6320> References: <064.ae6edf87f273cd393d23cb7076fcb28e@tools.ietf.org> <1476027.UdxMWrdmeL@scott-latitude-e6320> <6.2.5.6.2.20120822215213.0a04dec8@resistor.net> <3669562.evm5Ozz3o2@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #28: i18n for EAI compatibility X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 07:14:23 -0000 At 22:30 25-08-2012, Scott Kitterman wrote: >Reverts as you said to do, but I think that the now current text: > > Internationalized domain names MUST be encoded as A-labels, as > described in Section 2.3 of .on 2.3 > of . > >is outside the scope of our charter since this is a new requirement and it's >not related to a widely deployed extension of SPF, so we need to address it. Yes. >It may simply be a matter of acknowledging that since SPF records are ASCII, >this is the only way to do it. Suggestions? Suggestions from WG participants are welcome. Regards, S. Moonesamy From sm@elandsys.com Sun Aug 26 01:20:54 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 AE78521F8497 for ; Sun, 26 Aug 2012 01:20:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gts8O58KOecS for ; Sun, 26 Aug 2012 01:20:54 -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 0B71521F8491 for ; Sun, 26 Aug 2012 01:20:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7Q8Kejf002918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Aug 2012 01:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345969252; bh=CD43DyVbyxgUL8eKObvpVee3r+Hek027Jygu3++S4z8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qBgORiz1yEQlK+ChVowZPD4osrlW8xQNpHLNeewayFz0laV1gPMetrKAsbbO98L/D 1pNgOsATQuSuazrHuQZY1JC9tx3htcgU8d6j+kXhItHIpOwiNrXMe992IHaJ3HMJe2 Sd/7UXSo8eOeFA/qc482nWhSEVPTX2oq2oofjVtg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345969252; i=@elandsys.com; bh=CD43DyVbyxgUL8eKObvpVee3r+Hek027Jygu3++S4z8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2ZaI2JjYeY3KohTgofEUcPupZcTH88rRnaLQkvQesYu9/tIZxOyhQ8/AXaL/FezDa ok/yLOpwX1T1JLNmN4zm6eGcKJ1QpbS6O+D3iRq5RR4t7V4OAWcqUYmkaipe2VnxC5 MJJWEax5id7Ists6so7JSQF/cJ5TWtz38cFemX2k= Message-Id: <6.2.5.6.2.20120826001529.09a81970@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Aug 2012 01:20:07 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <2480847.VqIOrM1vYF@scott-latitude-e6320> References: <20120826051312.34721.qmail@joyce.lan> <2480847.VqIOrM1vYF@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 08:20:54 -0000 Hello, This is a very rough summary of the Authentication-Results and Received-SPF: headers discussion. Hector Santos mentioned presenting this as a migration, not just as an exclusive replacement [1]. John Levine suggested having more (Authentication-Results:) details about SPF results in a separate draft [2]. One of the arguments mentioned by Douglas Otis is that it would never be in a users interest to adopt result formats aimed at disabling third-party competitors by omitting essential information [3]. Murray Kucherawy commented that it should be sufficient to point out the two available options for post-MTA communication, explain why we're documenting two of them, and leave it there [4]. As an individual comment, this working group had to determine a resolution to two experiment. That happened because consensus did not clearly support one over the other. The working group will be conducting a similar experiment if it is WG consensus to support both options. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02365.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02357.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02350.html From vesely@tana.it Sun Aug 26 04:44: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 F332B21F84AF for ; Sun, 26 Aug 2012 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tnHRFeyK61Q for ; Sun, 26 Aug 2012 04:44:49 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2132121F845A for ; Sun, 26 Aug 2012 04:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1345981487; bh=PM2ATBOtTKdp55XnZC8CxuUDkcufKWXQskiPsvGudxQ=; l=2116; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GMibxDwtG4uyuUlQ/gaKbrFGLzC18Zop9yc8rwdHWk3Vh5F0YdHGYC2MDeNgc8F4R SRGucW1VAWngOum6TdtBXfmDSbm+tnEIkCe/4VJF+4OEJxRVSA4wizXW2J+CEaZScF +uHUhMJK0wuf85iroJYSM9t8w6lztkRH7IwSUsfE= Received: from [109.113.245.28] ([109.113.245.28]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 26 Aug 2012 13:44:45 +0200 id 00000000005DC035.00000000503A0C2D.00006040 Message-ID: <503A0C23.2090600@tana.it> Date: Sun, 26 Aug 2012 13:44:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> <20120826021139.GB83954@mx1.yitter.info> In-Reply-To: <20120826021139.GB83954@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 11:44:50 -0000 On Sun 26/Aug/2012 04:11:39 +0200 Andrew Sullivan wrote: > > If people wish to pursue continued discussion about telling receivers > of SPF-covered mail how to behave, I'm going to want to see a pretty > good argument -- much better than I've seen so far -- why we ought to > do that or why it is even remotely on charter. "Remotely on charter" > means that you need to show how the text in 4408 is obscure, how > current practice has settled matters, and how that links up with the > specific tasks in our charter. Further discussion without meeting > these necessary conditions is just off-topic for the WG. Please, I am > asking, stop. We don't need to show how the I-D is obscure: It's obvious. One can count dozens of occurrences of the term "reject" or inflections thereof. Yet, as Scott says, nowhere it documents recipient policy. It half-says, hints, surmises, alludes. I think everyone can see the dangers of standardizing such obscure stuff. In principle, cleanup can occur in two ways. After banning further discussion on receiver behavior, there is one way only: take off all of Section 9, and remove any allusion to receiver behavior from the rest of the document --except one-- so as to really make the I-D conform to the sentences upthread: A sender policy is not about a sender telling a receiver what to do. A sender policy is a statement that mail was either sent in accordance with the sender's policy (pass), it wasn't (fail), or one of several varieties of uncertainty. A receiver is provided these sender statements as guidance, to use as they wish in the handling of a message. The single allusion that has to be tolerated is a sentence to mandate header fields on acceptance only, e.g.: Receivers who accept a message after having carried out SPF authentication SHOULD add a trace header field to convey the result. I think it may be much easier and fast to proceed this way. Perhaps, we will even recharter and complete the receiver policy afterwards. In any case, we'd better avoid to submit something which is neither fish nor fowl. From john@jlc.net Sun Aug 26 04:46: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 D494621F84AF for ; Sun, 26 Aug 2012 04:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.79 X-Spam-Level: X-Spam-Status: No, score=-105.79 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRKA08M2OlU2 for ; Sun, 26 Aug 2012 04:46:57 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 608A721F845A for ; Sun, 26 Aug 2012 04:46:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CFE0233C20; Sun, 26 Aug 2012 07:46:56 -0400 (EDT) Date: Sun, 26 Aug 2012 07:46:56 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120826114656.GB72831@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 11:46:57 -0000 Scott Kitterman wrote: > > Upon reflection, I think a lot if the recent dialog on this list is > based on a misunderstanding about what a 'sender policy' is in SPF terms. Very likely true! > A sender policy is not about a sender telling a receiver what to do. > A sender policy is a statement that mail was either sent in accordance > with the sender's policy (pass), it wasn't (fail), or one of several > varieties of uncertainty. You prove your point. :^( A sender saying +a states clearly that mail originating from that address is consistent with policy. But what does -all mean? I guess most senders mean they never send from any other address. That clearly does _not_ mean that mail received via some other MTA is _not_ sent according to policy. Indeed, it simply isn't clear whether an SPF fail states _anything_ about whether the mail was sent according to policy. :^( :^( :^( -- John Leslie From sm@elandsys.com Sun Aug 26 08:56: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 AA26721F8516 for ; Sun, 26 Aug 2012 08:56:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO25LVU5jxTK for ; Sun, 26 Aug 2012 08:56:25 -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 247FB21F84FA for ; Sun, 26 Aug 2012 08:56:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7QFu97r012035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2012 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345996583; bh=0Sm916P5flYaWyx0crn7ggrPO4uBsta3NgBXHNMIUQk=; h=Date:To:From:Subject:Cc; b=lm6HruRKY1Ss7nU09d+Ct6M9t7sRKTITDTXuuedCgCBhmCDySLKDP8HpQCCxaFAPn rXIoGnur002oVjbj+I0T0kj3lUpHt/tO0Ijntr9nDGvK3KbLUVjafPG/UJcJRsolaE Qpm+eVGaQ5VXL5QqbnPIU1Ks8U6evhVYe5Ukg5lY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345996583; i=@elandsys.com; bh=0Sm916P5flYaWyx0crn7ggrPO4uBsta3NgBXHNMIUQk=; h=Date:To:From:Subject:Cc; b=BAuoV0MzzK9tpbfPww8fLSDMa8VaQ7ImjLkqjBZukMnC92jyhrnQ/k4D4z+qQl3Nj DnqEKNAZYrDd1FC+If0+z8fua2jEg+3fNcUG44WIPQHTHCfFUIbbZTnsbD6JpiAqTO 0fy8UFdBss6H/rHlgiphQWmDkfi6wn7H4mRTYv1I= Message-Id: <6.2.5.6.2.20120826070938.08f985e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Aug 2012 08:34:52 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Marking mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 15:56:25 -0000 Hello, There has been a lot of discussion about marking mail on SPF Fail. I read RFC 4408. Quoting from Section 2.5.4: "The checking software can choose to mark the mail based on this or to reject the mail outright." It is my understanding that the choice is left to the software in the above text. From Section 7: "It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header." There is a normative recommendation in the above text to record the result of the SPF processing. I could not find any normative requirement to mark mail on SPF Fail. The topic of marking mail on SPF Fail as a requirement is closed. You can send an objection to the mailing list if you believe that there is a normative requirement in RFC 4408. Any other discussion is off-topic. Regards, S. Moonesamy SPFBIS WG co-chair From agthisell@yahoo.com Sun Aug 26 10:04: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 3384D21F8530 for ; Sun, 26 Aug 2012 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_BACKHAIR_32=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bb1b+Y3JVmp for ; Sun, 26 Aug 2012 10:04:21 -0700 (PDT) Received: from nm12-vm3.bullet.mail.ne1.yahoo.com (nm12-vm3.bullet.mail.ne1.yahoo.com [98.138.91.142]) by ietfa.amsl.com (Postfix) with SMTP id 2296021F853E for ; Sun, 26 Aug 2012 10:04:21 -0700 (PDT) Received: from [98.138.90.49] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:04:15 -0000 Received: from [98.138.87.5] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:04:15 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:04:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 144062.96989.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 8067 invoked by uid 60001); 26 Aug 2012 17:04:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346000655; bh=jBsSvudLfNPYfZ7oRcQFwlIIkbZdz8v0dJiB24lyRvc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=NSya75futa32f5bUi4kPGnLnuxES3Q7kSDUwtPQCnp8s4kk/Cn0HrvhdvEcK77YOwBGAizsvWUwgle/OR7aSk+n5D9n7rhd8Y6JgaDhdHUwBFyUpAkAUxz8y6vioSnr4Z1RtZTHVFbKOEtyLTFE8E87aEbGQVmIYu87K/kNeLno= 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=fIrTxVdpFxMRBlRF/akJKwPv6Zxxud6vBAeby4nd1reBCzHRpZ9+4vsuPFSindqPnSS77agx6gOOKoBot4KbTnbt7jifH5mGosz3uEiRw4mXRcYvadusSWhSAo+VFJplmT60iU+rM/+JrkJd0kJ8kFAtyV47BJ4Rtr51AtA+7Yk=; X-YMail-OSG: urCykXoVM1nX3YQvzjoqEy9_3iJ8cFp1bKA_36TRmHHdvuy mLJLMzKghugXVp2Di8WiYsuM0.piZxzhkZkP_fVa57QQjz5K.vfuwKmteUDL pSH0YTKO4ja8Jlbb5a2nJgpiMgU6TViCWUFeddpLeoiOFHnij0Nv6XR.c.vj DWyxIsUq7VUUCnp.lu0663C8AJSzU6PCJPJ7cTL5Go5maUrTgGpSPWZ54DCP ATOOOuXptiHidvjE7cixQge1Bqwkl1xDL9ltRT.JJ8VM_byzLKwQpJ_mUdkv REV7HaTJJvRiurKI7y_PUlMTDRfEI1QdxxEqw.V8c0_L2i.u54Ub0W9BDlkb M9XOtN5X9A5TK_yv5crLLIsTBqxxUuTxFv.S_EjF.NhXF0cCoBXlZ7blMrd6 jutKOp7uxqlSJ5yDgRicFYyTflhnMR9q55aNFAOQ70jmZn2tBZlCo093AI76 rE2d4Bbjm20WERvj1zqRKTpjAucrmjJ2pSAD2k8cA0WsJGTR_QsAkfU_rq88 HjmCOz8n3Eextdf5e3hACEEZvDk2YGzcBUzm73d8O4OlB9HBcqH1hGX1OGfN 0fPxq.0YlImln16VrVnzM4ThHTFf.9xUPv2bbawJYTVqp8Doy0QhFUQ-- Received: from [71.61.133.134] by web125406.mail.ne1.yahoo.com via HTTP; Sun, 26 Aug 2012 10:04:14 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.com> Date: Sun, 26 Aug 2012 10:04:14 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 17:04:22 -0000 First, the list has been too busy for me to keep up. I'm afraid I have only skimmed many messages, so I'm sorry if some of this is already covered. Next, it appears my comments on -05 were neither rejected nor accepted, I suspect Scott missed them: http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html OK, last time I compared rfc 4408 with bis-05, this time I'm going through bis-06 as a whole... * Overall, when RFC 4408 was drafted, care was taken to capitalize RFC 2119 keywords, and use the lower case words as regular English meaning. While most of the lower case words have been changed to synonyms, a few have been changed into RFC 2119 keywords. I think most (but sadly, not all) of these capitalizations are wrong. * in the abstract, the abbreviation ADMD is used, but isn't defined until late. I would just spell the abbreviation out in the abstract, and leave the introduction of ADMD to the introduction. * I would get rid of the mention of "spf classic". Enough time has transpired that I suspect this causes more confusion than helping to clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID SPF". * After further pondering, I would get rid of the Deprecated definition (section 1.3.5.). The only thing that is deprecated is ptr:/%{p}, which were only "discouraged" in RFC 4408. I can not ever see version 1 of SPF having such an incompatible change as getting rid of ptr:/%{p}. SPF has a version number for a reason. If, in a new WG, we want to change such things, we should go to version 3. We can adopt SPF version 2's magic number format of spf3.0 instead of v=spf3. We can keep spf 2's notation for different identities and its positional modifiers. We can get rid of ptr:/%{p}. We can either get rid of macros that have a local part, or greatly simplify/eliminate macros all together. We can switch to using only type 99 SPF records. We can do lots of things that can't be done to version 1 of SPF. Declaring something as deprecated in this I-D seems contrary to the WG charter and contrary to version 1 of SPF. * In the last paragraph of section 2.4, it talks about dangers of bang paths and such. That might be a good place to mention potential problems with SMTPUTF8, IDN, etc. * In section 2.5.6 on temperror, new language seems to imply that temporary errors are only caused by DNS errors, but timeouts could be caused by local problems unrelated to the DNS. * In section 2.5.7 on permerror, there is a warning about macros causing problems. This might be a good place to add a warning about using local part macros, particularly with SMTPUTF8. * RFC 4408 used lower case 2119 in a normal English usage fashion. In section 3.5 on wildcard records, the "not recommended" has been capitalized. I think this changed the intent of RFC 4408, and instead it should be changed to "discouraged" or some similar language. Actually, the first sentence of that paragraph is kind of redundant with the second sentence. * In section 4.4, multiple DNS errors over a 24 hour period now can be called a permerror. I'm pretty sure there are a couple of SPF implementations that do this, but if not, this would probably violate the WG charter. * in section 4.6 Record Evaluation, the first sentence starts with "After one SPF record has been selected,". I think this is left over from when there was a record selection procedure for TXT/SPF records. I think saying "The check_host() function parses and interprets the SPF record to..." would be better. * in section 4.6.4, there is a new requirement that there must not be more than 10 records for mx: or ptr:. This completely wrong for ptr: because a spammer could choose to send spam from a host with more than 10 PTR records, thus forcing a domain's SPF record to return permerror, instead of fail. If anything, more than 10 PTR records should cause the ptr: mechanism to automatically not-match. It should also be made clear that the %{p} macro is valid no matter how many PTR records are returned. To be honest, I think this new text should be removed from 4.6.5 and moved/reworded in the appropriate sections of 5.*. * in section 5.2, there is a weird line break in "both domains wasmx:example.com" * in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the new requirement that there must not be more than 10 records that was added to section 4.6.4 * in section 5.5 (PTR), step 1 and step 2 are really the same step. In RFC 4408, this was in paragraph form, where these were two sentences describing a rDNS lookup. * in section 5.7 (EXISTS), there news language saying "The query will either return NXDOMAIN (no match), any valid answer (match), or an error." What happenss on an error? I think this sentence is redundant and better fixed by rewording text above it. Suggested text: bis-06: The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup. If any A record is returned, this mechanism matches. The lookup type is A even when the connection type is IPv6. new: The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup (even when the connection type is IPv6). If any A record is returned, this mechanism matches, otherwise the mechanism doesn't match. or new: The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup (even when the connection type is IPv6). If any A record is returned, this mechanism matches. In all other cases (no A records, DNS error, etc.), the mechanism doesn't match. * in section 7. (recording the result), there is a lot of new text, here and I've seen a lot of discussion on the mailing list about it. I'm not sure what the current consensus is, but here is my two cents. First, I think the text should be made clearer that it is ok (maybe even RECOMMENDED?) to add both R-SPF and A-R fields. Second, the beginning of the second paragraph says "if the SMTP receiver chooses to do so, ...". I think it is unclear what "to do so" is referencing. In RFC 4408, it was clear this meant "choose to add a R-SPF header". * in section 8.1 (macro defs), there is a "Note: Care MUST be taken so that ...". I think it should be clearer that it is the ADMD, not the SPF verifier that needs to take care. That is, it should say "Note: The ADMD needs to take care so that..." This wording also fixes what I think was an incorrect changing of an english language meaning of "must" to a RFC 2119 keyword. * in section 8.1 (macro defs), there is a note that says "Note: Domains SHOULD avoid using ...". Again, if RFC 4408 the "should" was lower case and I don't think it was meant to be an RFC 2119 keyword. Maybe "Note: ADMDs are discouraged from using ..."? * in section 9.1.2, first paragraph: s/over "a" or "a" or "mx"/over "a" or "mx"/ * in section 9.2.2, a blank line was removed before the paragraph beginning "Note that due to the 63-character limit..." * In section 9.3.2, I think the following sentence is too long: SPF fail results can alternately be used as one input into a larger set of evaluations which might, based on the overall evaluation result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). Simply breaking out the parenthetical phrase into its own sentence would help. * In section 10.2: s/authorizationsto/authorization to/ * In appendix A, the sentence "Hence, "mx" matches "mx", "MX", "mX", and "Mx"." should probably be moved/copied to section 4.6.1 (term evaluation). This was a problem with RFC 4408 also. * In appendix A, I was too lazy to check to see if this collected ABNF matches wat is in the rest of the document. I hope someone will at least once before publication... again, sorry for not replying to appropriate threads at appropriate times. I hope this list will be helpful anyway. From dhc@dcrocker.net Sun Aug 26 10:20:37 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 6F3CA21F854B for ; Sun, 26 Aug 2012 10:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXv9+iLlhWxy for ; Sun, 26 Aug 2012 10:20:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9421021F853E for ; Sun, 26 Aug 2012 10:20:36 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7QHKZMx001341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Aug 2012 10:20:35 -0700 Message-ID: <503A5AE3.7000403@dcrocker.net> Date: Sun, 26 Aug 2012 10:20:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Thisell References: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.com> In-Reply-To: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 26 Aug 2012 10:20:35 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 17:20:37 -0000 Arthur, Well, aren't you /diligent/? Very nice. My own tidbits to add to your notes: On 8/26/2012 10:04 AM, Arthur Thisell wrote: > * in the abstract, the abbreviation ADMD is used, but isn't defined > until late. I would just spell the abbreviation out in the abstract, > and leave the introduction of ADMD to the introduction. I think I am seeing people rather naturally use "administrative domain" as the terse, prose version of the term, absent formal discussion. For something like an abstract, I think it's intuitive meaning is sufficient to justify leaving out the "management'. > * I would get rid of the mention of "spf classic". Enough time has > transpired that I suspect this causes more confusion than helping to > clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID > SPF". +1. > * After further pondering, I would get rid of the Deprecated > definition (section 1.3.5.). The only thing that is deprecated is > ptr:/%{p}, which were only "discouraged" in RFC 4408. Well, we are starting to discuss some other uses of it... > I can not ever see version 1 of SPF having such an incompatible > change as getting rid of ptr:/%{p}. SPF has a version number for a > reason. Version numbers are never really as useful as people expect them to be. That's because a new version is either incompatible or is upward compatible. Incompatible creates massive interoperability problems, absent a different port number of some other equally massive separation; version numbers don't get seen soon enough. Upward compatibility doesn't need the version number: all the older stuff still works and the mere presence of the newer stuff declares that the record supports features of a later version. This self-declaration also avoids the problem of having to define what to do when there are more than two versions. There was an interesting exploration of this reality for MIME, long ago, which realized that it would never change the version number. > Declaring something as deprecated in this I-D seems contrary to the > WG charter and contrary to version 1 of SPF. Not really, since it doesn't remove anything. Rather, it's a marker for the future. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Aug 26 11:56: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 75DB821F84F1 for ; Sun, 26 Aug 2012 11:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.843 X-Spam-Level: X-Spam-Status: No, score=-110.843 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_34=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMTNx5pVGJum for ; Sun, 26 Aug 2012 11:56:22 -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 98B8021F84EA for ; Sun, 26 Aug 2012 11:56:22 -0700 (PDT) Received: (qmail 67012 invoked from network); 26 Aug 2012 18:56:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2012 18:56:20 -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=503a7154.xn--9vv.k1208; i=johnl@user.iecc.com; bh=AWpXfOUlHmM6pDlkZfPPVV5EbejDiLu+JVZQ62h7MW4=; b=ci8uPbbJ50jraYyW1m6H/z6MxEN9U5O8GWpJReIZ483kEJUjQQ2fAEJFmlEYTbZ+o5IYgutej2A4R/xV1+KTArPJPx5NIHii65L36p1ylDyZiEJiYTupHc9NbFBL0pKZro5j5TpZFEUfZDD/DNeTqKX77uTPqd+t5vfx2DdJBrY= 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=503a7154.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=AWpXfOUlHmM6pDlkZfPPVV5EbejDiLu+JVZQ62h7MW4=; b=vw11ogHo7vQQ1mBCVdLhnqgW+Sg8Laf8aNAmoKOA88PV0vZZtuwD0+jL1+dU+8t5GbY5f0EiQhA3rV5uQuRJk5zk/K3RscqrLdAFxaHy+dWcG9NivY0WDkzVflyHcAsz7Ge5fpvDDsJDtJkknpcNpXN2GRNRjYBSfxt40KRBCYU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Aug 2012 18:55:57 -0000 Message-ID: <20120826185557.36239.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2038344.xmME5XhsPg@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] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 18:56:23 -0000 Remember that the point of a standard is to tell people how to write their software so that it interoperates. The suggestion to hide stuff in the A-R header doesn't do that, since we're not updating 5451, and as far as 5451 is concerned, these headers are equivalent: Authentication-Results: myhost.example.org; spf=pass reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" smtp.mailfrom=user@example.net Authentication-Results: myhost.example.org; spf=pass reason="your mail is boring" smtp.mailfrom=user@example.net I'd suggest chopping everything about A-R out of 7 and 7.2 other than saying that you can use it, with a reference to 5451 and an example that doesn't go beyond what 5451 defines. Also keep in mind that whether A-R is an adequate substitute for Received-SPF is a local policy issue. If I don't happen to use the info that A-R doesn't record, A-R is fine. Once again, I'm not opposed to updating 5451 to record more mechanically parsable info about SPF results, but there's a way to do that, and this isn't it. R's, John From superuser@gmail.com Sun Aug 26 13:16: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 4AFBA21F8530 for ; Sun, 26 Aug 2012 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYD-Wp-+qLDj for ; Sun, 26 Aug 2012 13:16:35 -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 7F25321F8513 for ; Sun, 26 Aug 2012 13:16:35 -0700 (PDT) Received: by lahm15 with SMTP id m15so2236186lah.31 for ; Sun, 26 Aug 2012 13:16: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=80Rdn3//R6Nimz4xR1O9x9nrglH/7yVwWzN4b+sLFUk=; b=uHfIxypUXXTVHnvszGLYmlOmI3Evu+/MvnHic00zMuvrmx3xGBiAJzhsDV3mWzavKP 5q3Ke3M1lsS/NYw+LSFcelzTYJMq4pxRb7TrGs9GNR0kQuGdqQJa0TOav1/2ur4iIWG6 YAJgLzhCaWjqLb0+dGZbmmEzWk9GgtVHN2yL4Tibx7vQrlOmkEhbk7lNrNbTP2AJLmO+ pfPK9yB3E4EGudC+Hc8U5hAQwck1eU/eu90D9U9xzsCERh684LQWpM27UgVQZE5mwwA1 sG3VKt0Z2K+yjVvUOk6kqjGwR+csDqcJzWZUB+gMkiBQXbRzXdtMnvQc0rRblUjJmtvW 0+IA== MIME-Version: 1.0 Received: by 10.112.104.3 with SMTP id ga3mr5495159lbb.77.1346012194209; Sun, 26 Aug 2012 13:16:34 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 26 Aug 2012 13:16:34 -0700 (PDT) In-Reply-To: <20120826185557.36239.qmail@joyce.lan> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> Date: Sun, 26 Aug 2012 13:16:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 20:16:36 -0000 On Sun, Aug 26, 2012 at 11:55 AM, John Levine wrote: > Remember that the point of a standard is to tell people how to write > their software so that it interoperates. The suggestion to hide stuff > in the A-R header doesn't do that, since we're not updating 5451, and > as far as 5451 is concerned, these headers are equivalent: > [...] +1 to this entire message. Received-SPF needs a full definition because this will become its official definition, so we're good there. (Which reminds me: IANA Considerations needs to update the permanent header field registry to say this document is the new formal definition of that field if it doesn't already.) A-R is defined elsewhere, and we only need to reference it and explain that it's the "new" way to do things, and leave it to the receiver to decide which one is appropriate for its own use. If you'd like specific replacement text as a proposal, I'm happy to help. -MSK From agthisell@yahoo.com Sun Aug 26 15:39: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 F211821F857A for ; Sun, 26 Aug 2012 15:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwhSxgkI3-+M for ; Sun, 26 Aug 2012 15:39:29 -0700 (PDT) Received: from nm34-vm7.bullet.mail.ne1.yahoo.com (nm34-vm7.bullet.mail.ne1.yahoo.com [98.138.229.87]) by ietfa.amsl.com (Postfix) with SMTP id 5C4DD21F8574 for ; Sun, 26 Aug 2012 15:39:29 -0700 (PDT) Received: from [98.138.90.53] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 22:39:25 -0000 Received: from [98.138.86.157] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 22:39:25 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 22:39:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 226679.31446.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 11853 invoked by uid 60001); 26 Aug 2012 22:39:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346020765; bh=AQLeYTRpTsuByi635C2QNhtA5BPLq4JUGMgYanKMY1A=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=280SbFVeqpZs77AEyvRHSJ+3rQFqB9KtQ7N3UjmzXF/bD5vZTiKxqopFdv1rKg5B6rfdFaDIgRdLZY5R/dZZmHP9w1wqj2DHev5MzcYMTC3SKe3DLjnIhMp+QeJZcfsurTmRgGDi9eZvuVScjqpMRA65Qw7cGapQ5Z2ikz/yDFk= 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=oo2NL+Se7FUDP/AaxgXFx8txr0XKCSWzJVO8oq14X7i6J3iIi6t4tGUznr5PB/802D9piiaaoFhpl0dh+8LnFQFqrZztUF51Yexcp9v3umt9mlIELNxCVr6CYP0goxPNSI/FTa1OOZWZAuOoqOaK5IYh/dXswzd0kAtMk3Y57DU=; X-YMail-OSG: jiG0sycVM1lXdwavU.j.4EMoBz0mXnl2w8HPD.kUFIgaRaU BB34jO28ccq9JYkW4QKLUR.FSLc7rZyWuOr6R4FbBVRND8QvPQxEA8jp7EYX psVSroVIPQLk25eLqIa.LLmdcCaY.2uCPxl8PTSKPiLhQuH59VFRt3UFCin2 Xz86UF9D5sAyFqB2KVBRg6XqdWS5igP2STwm3szRhPP6YgPewsMKoF2pUf05 pn0vpOAQwhifbOTebVDQCWzR3.BUZ6Rw_S8GrOjJIGPsm8eWLcy5Rkp7JMea GDeSkCvxwBG1A4wMn5KFKCwZAZppwPGeBUv7IkTensoijoWhRaNvKhaX3reN WOuPwepbDVbQDtWjlFImSq3_50N10ArY2nM8rrshSYKtRVclX2txzBZ0NM3u 7mPIXEphhTOE4ItOJvWDivF7Zv5YtGP7PNI_YdYxtIaiyoa84QS7GOmcmNaA AMJ8OvTt_BtMDIDqRndE- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Sun, 26 Aug 2012 15:39:25 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346020765.98529.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Sun, 26 Aug 2012 15:39:25 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Aug 2012 22:39:30 -0000 >> I can not ever see version 1 of SPF having such an incompatible >> change as getting rid of ptr:/%{p}. > > Incompatible creates massive interoperability problems, Agreed, which is why removing features in version 1 of SPF is so bad. > absent a different port number of some other equally massive separation; > version numbers don't get seen soon enough. Which is why one of my suggestions was to go to exclusively type 99 SPF records for SPF3.0 (Oh, and Meng was very amused by IETF people forcing the sub version number, since no one could explain how it could ever be used. Incompatible changes would be a major version, compatible stuff doesn't need a new version.) >> Declaring something as deprecated in this I-D seems contrary to the >> WG charter and contrary to version 1 of SPF. > > Not really, since it doesn't remove anything. Rather, it's a marker for > the future. That's not true. We have half-removed ptr:/%{p}. Publishers SHOULD NOT use them. OK, sure, publishers can make up an excuse to use them anyway and receivers still have to support it, so maybe say that it is 40% removed. Given enough revisions that "do not remove any features", we can remove 99.999% of that feature! I hate ptr:/%{p} for many of the reasons listed in 4408, but it isn't broken. From dhc@dcrocker.net Sun Aug 26 15:49: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 9D80921F858E for ; Sun, 26 Aug 2012 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF8x-LCeCrkH for ; Sun, 26 Aug 2012 15:49:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 197CF21F8574 for ; Sun, 26 Aug 2012 15:49:26 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7QMnPRB005910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Aug 2012 15:49:25 -0700 Message-ID: <503AA7F4.2080209@dcrocker.net> Date: Sun, 26 Aug 2012 15:49:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Thisell References: <1346020765.98529.YahooMailClassic@web125405.mail.ne1.yahoo.com> In-Reply-To: <1346020765.98529.YahooMailClassic@web125405.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 26 Aug 2012 15:49:25 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 22:49:26 -0000 On 8/26/2012 3:39 PM, Arthur Thisell wrote: > Which is why one of my suggestions was to go to exclusively type 99 > SPF records for SPF3.0 Wow. Why should we go exclusively with something that has received such poor adoption and for which there are still adoption barriers. (New DNS RRs remain a challenge, for end-to-end interoperability. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sun Aug 26 18:42: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 3B06021F84D4 for ; Sun, 26 Aug 2012 18:42:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU4W9XT1237C for ; Sun, 26 Aug 2012 18:42:35 -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 7380521F84CF for ; Sun, 26 Aug 2012 18:42:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7R1gKql006311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2012 18:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346031753; bh=qiWbCcx4vFrlQ/dJFsco3matS7Gs87bLCNP5InyvKS0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IZ41RbafQ2N3Z+a1b4+a8hQpg8Eqm8vUHYYJYHNidW0IeRIlU7BAM98AqKhJFdFlC 35Px4hc2aMa/pxQQycyDDqJpfCKcFjmPuyRzjkgw3zNpnOanKasoPhsUgBXqC9HbER /F661U7EKOIDYQVZ8Jgnw21WjOOXaTYM3ukg4eVE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346031753; i=@elandsys.com; bh=qiWbCcx4vFrlQ/dJFsco3matS7Gs87bLCNP5InyvKS0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xa2/83Jbk+gfPdbiQfppzMwXw3asnKipl2p1fsUts1IpSL/i6xa++emgmBDJUupek 2Lq/3YLTXXO1xEkaQpWEdmabi0eojinwwTe3HOgUIv0OXZAeOl7LpGzSGlpK/ZpcJg XRhMSgDakfYryZ1N2JsQ9CqaFK1Cj+PgniFHWKk4= Message-Id: <6.2.5.6.2.20120826183106.09387b98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Aug 2012 18:42:00 -0700 To: Arthur Thisell From: S Moonesamy In-Reply-To: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo. com> References: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 01:42:36 -0000 Hi Arthur, At 10:04 26-08-2012, Arthur Thisell wrote: >First, the list has been too busy for me to keep up. I'm afraid I >have only skimmed many messages, so I'm sorry if some of this is >already covered. > >Next, it appears my comments on -05 were neither rejected nor >accepted, I suspect Scott missed >them: http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html Thanks for the review. I made a note of the comments. >OK, last time I compared rfc 4408 with bis-05, this time I'm going >through bis-06 as a whole... There is Issue #34 to Issue #48 in the tracker. I'll follow up on the issues that were not added to the tracker. Thanks, S. Moonesamy From sm@elandsys.com Sun Aug 26 22:18: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 E5A9D21F85A4 for ; Sun, 26 Aug 2012 22:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urwhx9gQSXXl for ; Sun, 26 Aug 2012 22:18:47 -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 95EA121F852E for ; Sun, 26 Aug 2012 22:18:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7R5IOAD017025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Aug 2012 22:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346044716; bh=WlLtTyVxMrP3OKU5RPmTjS6wMH+QRR+L3mtjV8Ml5PQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=OQBMpYBur9y0VWKFZC5f4mfO5GC/IvMzZDbjDhEKWT5+2eDU9u2vNWN85PrXclzw8 DqS9l5gkXnEob1H9A4QcR7Rzj0S2mUad5YBZxg+A81cqLvmccSy6x0XZRsHfvly+ze GpmAkQMElCMikrtIMYl859j0eHSzdd4qRA9G7zKw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346044716; i=@elandsys.com; bh=WlLtTyVxMrP3OKU5RPmTjS6wMH+QRR+L3mtjV8Ml5PQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=uYC44zyu+U+I714JLoK5s5ZQQpHSM9U5ouDwFfcK1isMZ8buaY48k1+yDHEGmali3 gDqxKw6PIkoUqSnS/hkw3KVFCdOBZqByHhof7mh4f/gYH8zJCMf/9eonT9nSoUi+BY 6lo/XyUDeDXYpwrC9Z5XKCcUAZ4LvAuuJRIa3A+s= Message-Id: <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 26 Aug 2012 22:15:28 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <503818B2.4020102@isdg.net> References: <20120824173829.13742.qmail@joyce.lan> <5037E028.7090007@Commerco.Net> <503818B2.4020102@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 05:18:49 -0000 Hello, This is a rough summary of Issue #33. Scott Kitterman mentioned [1] that SPF is an MTA to MTA protocol. (He doesn't) think it's appropriate to include an MUA design missive in the security considerations. Alessandro Vesely commented [2] that it goes without saying that they have to be prepared to receive a stream of messages not so clean as it could be, doesn't it? Murray Kucherawy mentioned that he supported the text suggested by Scott Kitterman [10] as the IESG could reasonably expect something like this [3]. Hector Santos commented that 4408/BIS offers a mode of operation for -ALL that is not a rejection, but accept+marking the message [4]. He also mentioned that if the SPF receiver backend does not separate this accept+marked message, the user is now at risk of receiving harmful mail deemed unauthorized by the domain owner. Commerco WebMaster mentioned that a primary goal for SPF is to protect a domain holder's domain reputation when a third party uses the domain name without the domain holder's permission [5]. Hector Santos asked what is the harm in this security consideration? [6] Alessandro Vesely commented that the protocol delivers a result for a given input. A result of "fail" is "fail", irrespectively of which mechanism yielded that result [7]. John Levine pointed out that (SPF) is most definitely not about MUA design [8]. Hector Santos mentioned that SPF is more of a MTA to MDA protocol [9]. As an individual comment, I will err on the side of caution and assume that there is a security issue. I read the test case provided in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html The result of the SPF processing was: Received-SPF: fail (google.com: domain of testuser at facebookmail.com does not designate 208.247.131.8 as permitted sender) client-ip=208.247.131.8; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of testuser at facebookmail.com does not designate 208.247.131.8 as permitted sender) smtp.mail=testuser at facebookmail.com And the comments from the WG participant were: "Now checking my sant9442 at gmail.com account.... It was placed in a SPAM BOX with this notification at the top of the basic header display: Why is this message in Spam? It's similar to messages that were detected by our spam filters." And: "This is exact behavior we want for a accept/mark mode of operation." The Security Considerations section of a document is to discuss the following: - which attacks are out of scope (and why!) - which attacks are in-scope * and the protocol is susceptible to * and the protocol protects against I would be concerned if a security consideration is used to promote a particular behavior instead of addressing an attack. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02247.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02283.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02294.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02295.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02296.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02298.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02303.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02305.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02320.html 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02230.html From superuser@gmail.com Sun Aug 26 23:10: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 6BD6321F8532 for ; Sun, 26 Aug 2012 23:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM-HBYD7CZAV for ; Sun, 26 Aug 2012 23:10:23 -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 A7FD221F852E for ; Sun, 26 Aug 2012 23:10:22 -0700 (PDT) Received: by lbky2 with SMTP id y2so1616562lbk.31 for ; Sun, 26 Aug 2012 23:10:21 -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=7kcTVe1fc2ma/Yh/6mFgVklDqms18LwspVS4iupi21c=; b=UWB2OKieq9CONcKOsOSQ54ESArlgP/MGsKhl945t784zMxXcxX/v3/tvb5x/P2cRMC iZtzmhNu8/Y2wgjr8pTrAtHll/+TKlqavc4FJqo2YBRN1RhnkGqbXYFTp9Ha3Gpu0kIF Nd2pQNsz2i/nnITOednjS2gAenX3JaeeD1AxC7QaeOXqIQsL5GBkRO81bk6wzoi5DZMO nCQa7hFR8kkkcXdJG1pV7FNXmN0p6Z9/Ea9sJ9rZ70tTdsHYQVQgmNWzfaNkWHxCO4Xl hSQFOx7lcmDxWw/5q7akGxp9YwbFUK6jbJAny8ZgFG/yCJNTZWaMmNT6fVUMp9kEro8i YTxA== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr13543746lab.43.1346047821668; Sun, 26 Aug 2012 23:10:21 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 26 Aug 2012 23:10:21 -0700 (PDT) In-Reply-To: <20120826114656.GB72831@verdi> References: <20120826114656.GB72831@verdi> Date: Sun, 26 Aug 2012 23:10:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 06:10:23 -0000 On Sun, Aug 26, 2012 at 4:46 AM, John Leslie wrote: > A sender saying +a states clearly that mail originating from that > address is consistent with policy. > > But what does -all mean? > > I guess most senders mean they never send from any other address. Right. > That clearly does _not_ mean that mail received via some other MTA > is _not_ sent according to policy. At best it can say "Anything else (that doesn't match the listed mechanisms) was not originated according to policy." The difficulty is that neither the message nor the envelope contain enough data to allow arbitrary agents in the handling path to reconstruct accurately the environment where such an evaluation would be meaningful. That is, after a message goes from A to B to C, C can't be certain it has all of the right information to answer the question "What did B see?" which is what would really make SPF results actionable. -MSK From superuser@gmail.com Sun Aug 26 23:21: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 3A1CF21F856D for ; Sun, 26 Aug 2012 23:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+Ew0beeSFd9 for ; Sun, 26 Aug 2012 23:21:42 -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 4F91621F855F for ; Sun, 26 Aug 2012 23:21:42 -0700 (PDT) Received: by lahm15 with SMTP id m15so2431433lah.31 for ; Sun, 26 Aug 2012 23:21:41 -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=AHTqze+mXHTJiq9EZRUOGoWuulk1RKs4OE2cdxA/0xM=; b=njnqmG7BNMDo86lxNaGykp144tIPL/xSaGyUf7OgBcNteYl4YX7Tr7EdBC6HzAT4AC m29uTBnYN86+GmioPN/JuodoYs8CEJ2KWCp5wtiRW87gVkTmHIVU1lk2ix1c/PGidiuR 0TvcWAC00Do2nihm6BhlSnidXWr79nN8UMPdAgCoePoF4YV5CaZyvtqkf7sbK0jEzcBw 1Y6M497xOytcTYH+yj6zVQGZ1UO6edxKDaqh+dLoYGYJ3hpNkKXxVEwQiH5dSomcq0gh vQr7XLhxZ0vj7e60bb7AsKv931iMjp5kwP0Ik0r5Kpelrif2Q7pMvDhfzVhnZJqKNnrp H4Qw== MIME-Version: 1.0 Received: by 10.152.130.3 with SMTP id oa3mr13539447lab.27.1346048501167; Sun, 26 Aug 2012 23:21:41 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Sun, 26 Aug 2012 23:21:41 -0700 (PDT) In-Reply-To: <503A0C23.2090600@tana.it> References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> <20120826021139.GB83954@mx1.yitter.info> <503A0C23.2090600@tana.it> Date: Sun, 26 Aug 2012 23:21:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 06:21:43 -0000 On Sun, Aug 26, 2012 at 4:44 AM, Alessandro Vesely wrote: > We don't need to show how the I-D is obscure: It's obvious. One can > count dozens of occurrences of the term "reject" or inflections > thereof. Yet, as Scott says, nowhere it documents recipient policy. > It half-says, hints, surmises, alludes. I think everyone can see the > dangers of standardizing such obscure stuff. I'm confused as to the objection. Absent normative language about what a participant has to do, nothing is actually being standardized. Is it somehow a problem to allude to the current best practices, i.e., either reject or mark, as per the receiver's needs, without actually specifying one? > In principle, cleanup can occur in two ways. After banning further > discussion on receiver behavior, there is one way only: take off all > of Section 9, and remove any allusion to receiver behavior from the > rest of the document --except one-- so as to really make the I-D > conform to the sentences upthread: I don't agree with striking Sections 9.1 and 9.2 on this basis as they are not related to receivers. 9.3 delivers nothing normative so I think it's fine too. And as we're chartered to document things that have gained widespread support, the two handling options presented are permitted (even though, really, nothing's changed). > A sender policy is not about a sender telling a receiver what to > do. A sender policy is a statement that mail was either sent in > accordance with the sender's policy (pass), it wasn't (fail), or > one of several varieties of uncertainty. A receiver is provided > these sender statements as guidance, to use as they wish in the > handling of a message. This, or something like it (perhaps coupled with Scott's statement that SPF is an MTA-to-MTA protocol), would be a good thing to add somewhere in Section 1. > The single allusion that has to be tolerated is a sentence to mandate > header fields on acceptance only, e.g.: > > Receivers who accept a message after having carried out SPF > authentication SHOULD add a trace header field to convey the result. That's basically what Section 7 should (and does) say. John Levine and I mentioned elsewhere that 7.2 should probably be heavily chopped, however. -MSK From vesely@tana.it Mon Aug 27 02:53: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 5DA0C21F8624 for ; Mon, 27 Aug 2012 02:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkNU8wp+x4Ml for ; Mon, 27 Aug 2012 02:53:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A452421F8625 for ; Mon, 27 Aug 2012 02:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346061204; bh=9lJNSR/BAGcjkYdy15ZxGn45/5SogEAMDweCkdHA5Zc=; l=1349; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ICdknRamccyH0H+N5SH43Bk2SUuggyYveSG2p4HEhLkVmnKqjnH8kEe07O4EgdVgJ 190hBvjXbtveXwPc/AoFaxBomA6sKQf4cSyYWuQ3ihhhfQDZPLsScjth1GwBGA800/ 0Q9ENdY0BTo66WVoS1e7SGa1R1f9CDjuTkVG0kH0= Received: from [109.113.167.230] ([109.113.167.230]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Aug 2012 11:53:23 +0200 id 00000000005DC039.00000000503B4393.000005B4 Message-ID: <503B438A.8080203@tana.it> Date: Mon, 27 Aug 2012 11:53:14 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 09:53:27 -0000 On Sun 26/Aug/2012 22:16:34 +0200 Murray S. Kucherawy wrote: > > A-R is defined elsewhere, and we only need to reference it and explain > that it's the "new" way to do things, and leave it to the receiver to > decide which one is appropriate for its own use. RFC 5451 is rather succinct in its explanation of the layout of SPF results. Comparing A-R to Received-SPF might not be obvious. Is that worth additional text, possibly in its own subsection? Here's my try: 7.3 Relationship between Received-SPF and Authentication-Results Per identity results are conveyed using one or two stanzas (resinfo) in one or two Authentication-Results header fields. There is no identity tag in those stanzas, as its value can be inferred by the presence of the smtp.mailfrom or smtp.helo tags, which imply the corresponding identities. If the result is the same for both identities, one stanza is enough to convey both tags. In case both kinds of trace header fields are added at the same hop, they MUST be compatible, in the sense that the result for any given identity, and the value of helo/smtp.helo MUST NOT differ, and the value of envelope-from/smtp.mailfrom MUST either be equal or have an equal domain if the value of smtp.mailfrom consists of the domain portion only. Fields can complement one another, though. From vesely@tana.it Mon Aug 27 03:33: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 8B52A21F845F for ; Mon, 27 Aug 2012 03:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCdvCvSlDisO for ; Mon, 27 Aug 2012 03:33:05 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8930B21F845D for ; Mon, 27 Aug 2012 03:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346063584; bh=yrXYB4CqLxxUu3H95vRYrVKSLIIidLkVt/lztYNULbA=; l=3530; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=XcCQAGIrjHiSgJ8rv9/VaQRe6W1TnU8qkJZ7FTXHzl2j5ltWFD6ffZ0i4uLrQ3Cnm ivoO6dnBbT1jNCKf8DAz7hPMsukM0AiQypG5vBQ8k5gW8aNikPdOUIUnybsKE2pvER SwdXUDuBbQvI3NvOQSmuFkvOO+K5TAogkDudYGa4= Received: from [109.113.167.230] ([109.113.167.230]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Aug 2012 12:33:02 +0200 id 00000000005DC039.00000000503B4CDF.00000F36 Message-ID: <503B4CD4.3080104@tana.it> Date: Mon, 27 Aug 2012 12:32:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <5038B27D.6070001@tana.it> <6.2.5.6.2.20120825074644.0999d658@elandnews.com> In-Reply-To: <6.2.5.6.2.20120825074644.0999d658@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 10:33:06 -0000 On Sat 25/Aug/2012 18:37:08 +0200 S Moonesamy wrote: > At 04:09 25-08-2012, Alessandro Vesely wrote: >> It is obviously ridiculous to state that SPF is not concerned with the >> possibility to reject mail. IMHO, it is an hysterical second best to >> consider receiver policies as casually related to SPF, rather than an >> integral part of it. The acrobatics that the RFC 4408 exhibits, >> albeit valuable, seem to be a consequence of the MARID climate. > > I gather that the above is an objection to the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html I > mentioned in that message that I could not find any normative text > that states that mail SHOULD or MUST be rejected on SPF Fail. I do > not see any arguments in the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02344.html > about normative text that states that mail SHOULD or MUST be rejected > on SPF Fail. > > I do not have any opinion about whether RFC 4408 exhibits any > acrobatics or what might have caused that. I read both RFC 4408 and > draft-ietf-spfbis-4408bis. If I notice a change, I find out whether > it is according to what is in the SPFBIS Charter ( > https://datatracker.ietf.org/wg/spfbis/charter/ ). Whether I like the > change or not is immaterial. My task is to see that the WG > deliverable is completed according to the guidance I received. Hi SM, I appreciate the work that you're doing for the IETF in general, and I thank you for co-chairing this WG in particular. However, I object to the excess of aseptic formalism that at times you seem to entrench yourself within. How come you have no opinion? Why wouldn't it matter whether you like something or not? I'm happy of your openness and respect, but would prefer you making use of your personal taste and skills, rather than abstain. After all, this is a WG, not a High Court... >> Have we cooled down? Then let's put a MAY or whatever, for the sake >> of a clearer spec. OTOH, if we're still unable to discuss this >> subject constructively, I accept SM's suggestion as quoted above. In >> the latter case, however, I'd appreciate if the reasons to ban such >> discussions are explained in more depth: Such analysis may also be >> useful whenever further work on SPF will be taken into consideration. > > I consider any addition of a MAY, SHOULD or MUST as a substantive > change as such a change can have an impact on existing > implementations. The "for the sake of a clearer spec" is not one of > the better arguments in my opinion. About changes in the I-D, IMHO the "clarifying language" that the charter mentions includes such things as adding or removing any 2119 terms as we see fit, as long as doing so doesn't invalidate existing implementations and deployments. In that respect, the only change up to date is to remove the SPF RR type, and I don't think there will be more. > In a moderator note dated April 20, 2012, Andrew Sullivan mentioned > that the topic of "reject on fail" was closed ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01340.html ). > A quick glance through the archives will show that the topic > resurfaced. A thorough read of the archives will show that there > hasn't been any new arguments. I now realize I should have kept most of that discussion off-list and only post conclusions. Anyway, that discussion shows that current practices are well different from what is (not) documented in either the I-D or RFC 4408. From vesely@tana.it Mon Aug 27 03:44: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 6496621F858A for ; Mon, 27 Aug 2012 03:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quBJswH7xe4R for ; Mon, 27 Aug 2012 03:43:59 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7763821F8581 for ; Mon, 27 Aug 2012 03:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346064238; bh=XQwuUJiU0/JFZFKwnMDNGXfsr3KOVUipFfjSTk+xaj8=; l=3544; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EOmKPCC2Q/UtSKmEoZVh8gxhBGtU8/TK2M/MJI3xiz7Z4UsJOlG3lvI0An48VfhV7 dt6wuIVoIvqU5KTyQYUTb2mBAOEvaUMT3QXLUKN/zdBhjtHcTv80wdE6aP2E/KYR/3 hiOc4FyF+IiWzL+Gf0mXiNG6dtMLTh4wDtvy5vGI= Received: from [109.113.167.230] ([109.113.167.230]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Aug 2012 12:43:56 +0200 id 00000000005DC039.00000000503B4F6D.000011D4 Message-ID: <503B4F63.1050702@tana.it> Date: Mon, 27 Aug 2012 12:43:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> <20120826021139.GB83954@mx1.yitter.info> <503A0C23.2090600@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 10:44:00 -0000 On Mon 27/Aug/2012 08:21:41 +0200 Murray S. Kucherawy wrote: > On Sun, Aug 26, 2012 at 4:44 AM, Alessandro Vesely wrote: >> We don't need to show how the I-D is obscure: It's obvious. One can >> count dozens of occurrences of the term "reject" or inflections >> thereof. Yet, as Scott says, nowhere it documents recipient policy. >> It half-says, hints, surmises, alludes. I think everyone can see the >> dangers of standardizing such obscure stuff. > > I'm confused as to the objection. Absent normative language about > what a participant has to do, nothing is actually being standardized. > Is it somehow a problem to allude to the current best practices, i.e., > either reject or mark, as per the receiver's needs, without actually > specifying one? I think it /is/ a problem, for various reasons. First, the "several varieties of uncertainty" miss an actual meaning unless they are paired with an intended behavior. Second, that kind of descriptions, given as if patting the reader with the elbow or winking, such as those currently used to pair results to intended behaviors, are a poor standardization technique, and lower the average quality of IETF standards. Third, since they are not spelled out clearly, it is overly difficult to improve them. Finally, participants are not officially supported, so that their behavior can be considered abusive by anyone acting as a protocol cop. >> In principle, cleanup can occur in two ways. After banning further >> discussion on receiver behavior, there is one way only: take off all >> of Section 9, and remove any allusion to receiver behavior from the >> rest of the document --except one-- so as to really make the I-D >> conform to the sentences upthread: > > I don't agree with striking Sections 9.1 and 9.2 on this basis as they > are not related to receivers. 9.3 delivers nothing normative so I > think it's fine too. I've been gross. There are several little parts to remove (including one on which the two of us recently agreed upon, e.g.). > And as we're chartered to document things that have gained > widespread support, the two handling options presented are > permitted (even though, really, nothing's changed). Yes. >> A sender policy is not about a sender telling a receiver what to >> do. A sender policy is a statement that mail was either sent in >> accordance with the sender's policy (pass), it wasn't (fail), or >> one of several varieties of uncertainty. A receiver is provided >> these sender statements as guidance, to use as they wish in the >> handling of a message. > > This, or something like it (perhaps coupled with Scott's statement > that SPF is an MTA-to-MTA protocol), would be a good thing to add > somewhere in Section 1. Yup, usual disclaimers, such as saying what is beyond the document, would also be appropriate. Then, the SPF-deployment document will be able to say "here we cover what we left unspecified there". The split of DKIM vs ADSP is a good example of how to do that. >> The single allusion that has to be tolerated is a sentence to mandate >> header fields on acceptance only, e.g.: >> >> Receivers who accept a message after having carried out SPF >> authentication SHOULD add a trace header field to convey the result. > > That's basically what Section 7 should (and does) say. John Levine > and I mentioned elsewhere that 7.2 should probably be heavily chopped, > however. I agree on that, but then OTOH I also proposed additional text. From hsantos@isdg.net Mon Aug 27 06:15: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 AD1F521F861E for ; Mon, 27 Aug 2012 06:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5NcwJZMerTj for ; Mon, 27 Aug 2012 06:15:21 -0700 (PDT) Received: from ntbbs.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 96A3D21F8450 for ; Mon, 27 Aug 2012 06:15:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=727; t=1346073313; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=U5T9AhlVDX0L8hr3kNRZmljE5KQ=; b=Pl1I+tLoWx7x+V1FmWlB AFCB8/QTrUnxEkw1OrQiZwYOnrT+on8fTvLbboOEhL7cumNoKPuR6NiyvwDQYKI2 Un2JLzhnbR6KH9UAQ65IltHT3TNE24Z8NEfo+ENALUcStiwqSzBW52Bd2ZLzuDF7 x2cV61C9xBlc3zcISJ8ko5Q= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 09:15:13 -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 2095106041.5114.3784; Mon, 27 Aug 2012 09:15:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=727; t=1346073115; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=O0V0hwZ TZ9w1XXukSodyjiHutzzLdVm+UXCo0CWFyP8=; b=UhS0gACYtcWO7WgYBo58ECF Go5V0donda5rYqfaYIEyfjhDm4QB6Y4cTucuc7gcRxekDHCEotgcbwSlJzqlWkAq d7bZ59mvLjLD1HRmhjkmBJZCoD5BgBk9TlqSFX9kZivP2XD/RdGe2I0QVB+8C/sa EuE0EzPtgOSJYmob96sw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 09:11:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2693913708.9.4872; Mon, 27 Aug 2012 09:11:54 -0400 Message-ID: <503B7306.2090907@isdg.net> Date: Mon, 27 Aug 2012 09:15:50 -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: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> <20120826021139.GB83954@mx1.yitter.info> <503A0C23.2090600@tana.it> <503B4F63.1050702@tana.it> In-Reply-To: <503B4F63.1050702@tana.it> 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] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 13:15:21 -0000 Alessandro Vesely wrote: >> This, or something like it (perhaps coupled with Scott's statement >> that SPF is an MTA-to-MTA protocol), would be a good thing to add >> somewhere in Section 1. > > Yup, usual disclaimers, such as saying what is beyond the document, > would also be appropriate. Then, the SPF-deployment document will be > able to say "here we cover what we left unspecified there". -1, I don't think MTA to MTA is proper here. It will inherently BREAK as a MTA to MTA "Chain of Trust" hop to hop protocol. I think this idea of adding MTA to MTA is born out of an erroneous notion people had a misunderstanding of SPF. It is unnecessary and my view, would not be technically correct. -- HLS From john@jlc.net Mon Aug 27 06:29: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 8D1BA21F865B for ; Mon, 27 Aug 2012 06:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.806 X-Spam-Level: X-Spam-Status: No, score=-105.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ+FP8FYD2nN for ; Mon, 27 Aug 2012 06:29:47 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E4BFF21F8652 for ; Mon, 27 Aug 2012 06:29:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 81D6833C26; Mon, 27 Aug 2012 09:29:45 -0400 (EDT) Date: Mon, 27 Aug 2012 09:29:45 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120827132945.GD72831@verdi> References: <20120826114656.GB72831@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 13:29:47 -0000 Murray S. Kucherawy wrote: > On Sun, Aug 26, 2012 at 4:46 AM, John Leslie wrote: > >> A sender saying +a states clearly that mail originating from that >> address is consistent with policy. >> >> But what does -all mean? >> >> I guess most senders mean they never send from any other address. > > Right. Of course, _some_ senders might mean "Please reject anything you receive from a different MTA". That's a point of obscurity in the spec. Some receivers _do_ interpret it that way. >> That clearly does _not_ mean that mail received via some other MTA >> is _not_ sent according to policy. > > At best it can say "Anything else (that doesn't match the listed > mechanisms) was not originated according to policy." I think Murray is saying the same thing, but he leaves out the "originated" in "that doesn't match..." > The difficulty is that neither the message nor the envelope contain > enough data to allow arbitrary agents in the handling path to > reconstruct accurately the environment where such an evaluation > would be meaningful. _If_ the headers in the message were 100% accurate and 100% trustworthy, an MTA could reconstruct the originating IP address from the message headers and perform check_host() on it. But even were that true, it would fall outside RFC 4408. > That is, after a message goes from A to B to C, C can't be certain > it has all of the right information to answer the question "What > did B see?" which is what would really make SPF results actionable. That's a more precise statement. IMHO, we need to lay to rest reject-on-fail by a better understanding rather than by a WGC calling consensus. Even if some senders intend reject-on-fail, and some receivers practice it, it lacks _any_ justification in the model of 4408 -- because the relationship between sender policy and receiver action is illusory: there's nothing in the envelope to tell the receiver whether the sending MTA is an originator or an intermediary. I suggest that reject-on-fail _be_ mentioned; but described as being based on a faulty assumption that the sending MTA is an originator. -- John Leslie From superuser@gmail.com Mon Aug 27 06:42: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 5B91221F8678 for ; Mon, 27 Aug 2012 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wl2w910uO3A for ; Mon, 27 Aug 2012 06:42:22 -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 A812C21F866D for ; Mon, 27 Aug 2012 06:42:11 -0700 (PDT) Received: by lbky2 with SMTP id y2so1886020lbk.31 for ; Mon, 27 Aug 2012 06:42: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=1VPnLSaYBwjEH11Qyr4WS91nj8AbAgHa8W3tK9+ozU4=; b=UGQjKCtpVCLtdF4rJMaUbJtrOzp1cfeBBXTqDaA19maWp+OdcBmwebupItvY3p8yq5 BtyQa+ooTw0X0MqfsksTYwKzH0O4r1RwMOxmhOutyHs7UrAxgTi8Le1juWgEWkfzuvO5 u6z7Ag75SphWzXO41V6Vsp822OKNSDHyFx8FjJ5DZwXa0dj32YX6QPxjGlV03PaZXvV5 DFEsfaWQoBWkkHsuSH7/oUav1m0s+KS/I7wgmvidbWui5X5tHVWIeOaIZbMa0ttnj/Tr i4TeIeMX1qeE/0a29I1q7c6y8Iw3V0l/Y+vkrEGHWIDuQji7kr03Jbp4Fb8QR1Stqlzp 87QQ== MIME-Version: 1.0 Received: by 10.152.130.3 with SMTP id oa3mr14901150lab.27.1346074930503; Mon, 27 Aug 2012 06:42:10 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 27 Aug 2012 06:42:10 -0700 (PDT) In-Reply-To: <503B438A.8080203@tana.it> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> Date: Mon, 27 Aug 2012 06:42:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 13:42:22 -0000 On Mon, Aug 27, 2012 at 2:53 AM, Alessandro Vesely wrote: > 7.3 Relationship between Received-SPF and Authentication-Results > > Per identity results are conveyed using one or two stanzas > (resinfo) in one or two Authentication-Results header fields. > There is no identity tag in those stanzas, as its value can be > inferred by the presence of the smtp.mailfrom or smtp.helo tags, > which imply the corresponding identities. If the result is the > same for both identities, one stanza is enough to convey both tags. > > In case both kinds of trace header fields are added at the same > hop, they MUST be compatible, in the sense that the result for any > given identity, and the value of helo/smtp.helo MUST NOT differ, > and the value of envelope-from/smtp.mailfrom MUST either be equal > or have an equal domain if the value of smtp.mailfrom consists of > the domain portion only. Fields can complement one another, though. Is the normative stuff necessary, or does that discussion belong in Security Considerations? What interoperability breaks if the MUSTard you have there is removed? Presumably consumers of this information aren't looking for both fields. Another important distinction is that RFC4408 contained no protections against spoofed Received-SPF attacks, while RFC5451 did. -MSK From superuser@gmail.com Mon Aug 27 06:55: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 8A12721F866A for ; Mon, 27 Aug 2012 06:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x51h334XPcup for ; Mon, 27 Aug 2012 06:55:42 -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 B6F8E21F865B for ; Mon, 27 Aug 2012 06:55:41 -0700 (PDT) Received: by lbky2 with SMTP id y2so1896673lbk.31 for ; Mon, 27 Aug 2012 06:55: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=wEl/7EYd0JcEB0Zx6hnt1SuUEC/fwBQOtT0EJpiNVy0=; b=WPhh3JsvtysdAUtQ4/ozrtHRD/eP+m5MbhmN8pXiQBeXDj7kPLIEdIEc2C8uNgildh /S3Qc+9RECc40ev2T4OFvoSpFi0SkFvfitPMFr1tTYMlzMsGCobCgla0AiAtFmuKHzgZ BGKlIWqvfc4TfdTnDyFMGyHZrUj2PfvuFttE2lol7ErgqzRpbEAOeCHY2JDrNXvKz1Nu QL197CgiwMeAiyJLtyhMyoS4g8zE9ebTe3Z11EnxasjJeRFyy0DOMl3RPLCSHII7xMIx nVkSG1mGaGYH+WqrSqaues7U7YNdRgBBBPmQ7GVFTHDsuRNTHrYhiDah/QbrSIXWZXw8 mwLg== MIME-Version: 1.0 Received: by 10.152.110.70 with SMTP id hy6mr14914731lab.44.1346075740611; Mon, 27 Aug 2012 06:55:40 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 27 Aug 2012 06:55:40 -0700 (PDT) In-Reply-To: <503B4F63.1050702@tana.it> References: <503941BF.3000404@isdg.net> <9d09ccb9-c98e-4441-839e-898827b4c82e@email.android.com> <50395C1F.9010600@isdg.net> <20120826021139.GB83954@mx1.yitter.info> <503A0C23.2090600@tana.it> <503B4F63.1050702@tana.it> Date: Mon, 27 Aug 2012 06:55:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 13:55:42 -0000 On Mon, Aug 27, 2012 at 3:43 AM, Alessandro Vesely wrote: >> I'm confused as to the objection. Absent normative language about >> what a participant has to do, nothing is actually being standardized. >> Is it somehow a problem to allude to the current best practices, i.e., >> either reject or mark, as per the receiver's needs, without actually >> specifying one? > > I think it /is/ a problem, for various reasons. First, the "several > varieties of uncertainty" miss an actual meaning unless they are > paired with an intended behavior. Second, that kind of descriptions, > given as if patting the reader with the elbow or winking, such as > those currently used to pair results to intended behaviors, are a poor > standardization technique, and lower the average quality of IETF > standards. Third, since they are not spelled out clearly, it is > overly difficult to improve them. Finally, participants are not > officially supported, so that their behavior can be considered abusive > by anyone acting as a protocol cop. Taking each of these in turn: Given that what you're calling "intended behaviour" is local policy, and I think we're trending toward agreement that local policy cannot be an edict of this document, I don't see how this can be resolved. Rather, the intended behaviour is that the receiver's SPF code returns a result based on the inputs to check_host(). What happens with that information is essentially out of scope, but this document presents some options when outright filtering is not a choice available to the operator. DKIM did the same thing; did you disagree with it then? Why is the proposed Section 7 text (you just contributed to it in another thread) poor? They are spelled out clearly; Section 7.1 describes Received-SPF quite well, and we have RFC5451 for the other alternative. I don't understand your fourth point. -MSK From spf2@kitterman.com Mon Aug 27 06:59: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 2833321F85A5 for ; Mon, 27 Aug 2012 06:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrKduTns2P5j for ; Mon, 27 Aug 2012 06:59:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7784A21F8534 for ; Mon, 27 Aug 2012 06:59:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6D6DC20E410A; Mon, 27 Aug 2012 09:59:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346075985; bh=O9n8J+jpx5N76T8uWLXR0FAi5NaVCc+7cESLxJtS9cc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g/UKpZiKFnZcCkPlx92fE4r6zoKDsz3h7LBzOWl3InT0PCVPBGj1HLH9yb1/ixcvG h0ANXwB0zTgDfD4oxX/wTkkScfjgBwaxb9kuc5EGl67a+0+OrsBUAoLEFxyg0e0LR9 cCxKu675V5vZDYE1RbF7jqljjT/BvnM6NRPvm558= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3FF7C20E40E8; Mon, 27 Aug 2012 09:59:44 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Aug 2012 09:59:44 -0400 Message-ID: <2994078.WIrANmooq5@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.com> References: <1346000654.2710.YahooMailClassic@web125406.mail.ne1.yahoo.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] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 13:59:47 -0000 On Sunday, August 26, 2012 10:04:14 AM Arthur Thisell wrote: > Next, it appears my comments on -05 were neither rejected nor accepted, I > suspect Scott missed > them: http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html I missed them. Scott K From vesely@tana.it Mon Aug 27 07:55: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 D917221F86C8 for ; Mon, 27 Aug 2012 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skwWLsXWlSWp for ; Mon, 27 Aug 2012 07:55:24 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD1521F866B for ; Mon, 27 Aug 2012 07:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346079321; bh=olAX2+V2Ot/RZeD/hGVN9Sjuf7TNMyy/dtscP6iO/RY=; l=1597; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IsIjx2jyoJVet8N2wkE/5POiMGxKa32GTfhKshNz9FrAqdvqpDcoBYzf7LUvvw83f MitS5UO117sMfGVQFERrpLUG1R8oSqxK3nWxEeO3b0z9odPEdDCNhXEUVAPjFZTj14 famUimhOVJNVmlv4peq96FQyXMINV8HsqbTdO5sw= Received: from [109.113.156.137] ([109.113.156.137]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Aug 2012 16:55:19 +0200 id 00000000005DC033.00000000503B8A57.00005665 Message-ID: <503B8A4C.9030701@tana.it> Date: Mon, 27 Aug 2012 16:55:08 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> In-Reply-To: <20120827132945.GD72831@verdi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 14:55:25 -0000 On Mon 27/Aug/2012 15:29:45 +0200 John Leslie wrote: > Murray S. Kucherawy wrote: > >> That is, after a message goes from A to B to C, C can't be certain >> it has all of the right information to answer the question "What >> did B see?" which is what would really make SPF results actionable. > > That's a more precise statement. It is possible for B to add an Authentication-Results field with SPF results, and sign it using DKIM. If C trusts B, it can then wholeheartedly accept the message. That scenario was considered while discussing DKIM for mailing lists. It turns out that if C trusts B, then it can accept the message anyway. That technique might still be useful, e.g. for forensics purposes. > IMHO, we need to lay to rest reject-on-fail by a better understanding > rather than by a WGC calling consensus. > > Even if some senders intend reject-on-fail, and some receivers > practice it, it lacks _any_ justification in the model of 4408 -- > because the relationship between sender policy and receiver action > is illusory: there's nothing in the envelope to tell the receiver > whether the sending MTA is an originator or an intermediary. > > I suggest that reject-on-fail _be_ mentioned; but described as > being based on a faulty assumption that the sending MTA is an > originator. It would be enough to consider the helo identity to ascertain that point. A rather scarce information if one misses a reputation system, but let's recall the declared purpose of SPF was just to force spammers to use their own domain names. From hsantos@isdg.net Mon Aug 27 07:57: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 3373321F86C8 for ; Mon, 27 Aug 2012 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.732 X-Spam-Level: X-Spam-Status: No, score=-101.732 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD-O43pVHIRn for ; Mon, 27 Aug 2012 07:57:00 -0700 (PDT) Received: from listserv.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4550121F866B for ; Mon, 27 Aug 2012 07:56:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3428; t=1346079408; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=91RuUULqOn3ybMgE5GceQCMaN+8=; b=fpTPZ0xj5Ov+Hjsqdjks QwV60vkTrx9RgcsWPq0ZkA6oQRz1eG1UxWg7T5KYjOaafXVBmp3h/Z6/1tIsxWNl 91lRYnSCF8q0dQein8idF2PyBGwY2qZH0WE/aXNfP/M7jZotRZmocZKvG8r+sNTW uM7UEuDwqpZ3Ilta9m0OAy8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 10:56:48 -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 2101201203.5114.1964; Mon, 27 Aug 2012 10:56:47 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3428; t=1346079208; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9VHXEKE kzlEMLo0t658eEyXCxrXR3pqc9WDbsgxtqK8=; b=JIghp83dbOMMyvFbAvfuwMl 1Bi+o8oaixSgVU9y0LSbhL7mAkPhphyIFXlaOGfMYJpOqZ5igIEGGxOl1m4GMKI2 SmCbbGhNJzb7ldrKBo35man6pNQ6PhGMJeOYeWCH/sXKFyShRSrknxHPYWk11unK c3PBb+EhITeUueROlumY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 10:53:28 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2700006255.9.1300; Mon, 27 Aug 2012 10:53:27 -0400 Message-ID: <503B8AD3.1050006@isdg.net> Date: Mon, 27 Aug 2012 10:57:23 -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: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> In-Reply-To: <20120827132945.GD72831@verdi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 14:57:01 -0000 John Leslie wrote: >> That is, after a message goes from A to B to C, C can't be certain >> it has all of the right information to answer the question "What >> did B see?" which is what would really make SPF results actionable. > > That's a more precise statement. > > IMHO, we need to lay to rest reject-on-fail by a better understanding > rather than by a WGC calling consensus. > > Even if some senders intend reject-on-fail, and some receivers > practice it, it lacks _any_ justification in the model of 4408 -- hmmmmm, if I follow you, I don't agree with that. I think its very very clear, since day one. > because the relationship between sender policy and receiver action > is illusory: there's nothing in the envelope to tell the receiver > whether the sending MTA is an originator or an intermediary. Serious -1 John. Just two things here, 1) you can count the hops and 2) SPF is not as payload (RFC5322) protocol, > I suggest that reject-on-fail _be_ mentioned; but described as > being based on a faulty assumption that the sending MTA is an > originator. IMO, what we should not be doing is reinvent SPF; its theory, the problem set and the solution it offered over and beyond anything else as one of the fastest entry, fastest adopted SMTP add-on in well, SMTP history. Today, I will surmise it as follow: ?ALL is a waste on the system across the board. +ALL is also a big waste, but could be used with add-ons. ~ALL is less of a waste but explorers are looking at augmented with other methods. At this point, it seems to be heuristics, but some at looking it with DKIM w/o ADSP in some fashion. I believe Microsoft stated they were experimenting with: SPF.softfail + DKIM/ADSP.discard -ALL was designed to be independent of anything else and is 100% deterministic. To me, finding a FAULT has a higher payoff then anything in this era of high volume abuse. The faster to filter the junk, the more you can apply augmented "Heuristic" reputation stuff. But then again, we been there before with this debate? No rights/wrongs, to me, SPEED of achieving yields and results is what to shoot for in order to avoid the "too late to fix" abuse issues due to "learning." This has nothing to say when it does fail with transition points (multiple hops, open relays, etc). We all knew this. Poor Domain understanding of their outbound mail network, Hosting use cases, etc, is a source of this. Kludges like SRS were proposed, I think the BATV too, but I never supported it so I don't know but it sounded like an SRS thing. Then we have the PATH solutions (DKEYS, DKIMS) were offered but there too, it failed to address the "middle ware" hop problem and 3rd party controls. Nonetheless, with SPF, by far and without a doubt, the industry accepted this SPF bad part with the overwhelming good SPF offered with clear and concise policy definition capability. DNS management software now offer SPF support in greater numbers, if not all. Not much support for other technologies, like DKIM. SPF was and is still simple. It really isn't that hard. We are making it hard. It took nearly 9 years to finally see a good payoff with a LMAP software with SPF prevailing. At my site, I see a 16% protection of spoofed domains. Of course, it will vary across the board. But this is good and as SPF promises for -ALL, it works. -- HLS From vesely@tana.it Mon Aug 27 07:57: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 943DE21F86B8 for ; Mon, 27 Aug 2012 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.064 X-Spam-Level: X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwpAgfvCLl4Q for ; Mon, 27 Aug 2012 07:57:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CE72721F866B for ; Mon, 27 Aug 2012 07:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346079443; bh=qLqrbNIrwq2HPL7rLTlln0FFtSY4S7kAnrd+YEiFVBg=; l=1794; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=NNhqEpQXm9KgmF1ums2PSZaNhq7NBhgV3AMrNZn/QNjmFwP/d9jwuhg4vED1J5hdA z7UOU093mzaxlt73kLSi4xLWR8SitjmVX2IDAsyAX5bS7m3+l0iCC2kscwaaDKw7oi uoXyP/wcd6qP/5eQf0pTGNYl7rSsO94eiQVCTb2Y= Received: from [109.113.156.137] ([109.113.156.137]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 27 Aug 2012 16:57:20 +0200 id 00000000005DC033.00000000503B8AD1.0000570C Message-ID: <503B8AC8.8080009@tana.it> Date: Mon, 27 Aug 2012 16:57:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 14:57:25 -0000 On Mon 27/Aug/2012 15:42:10 +0200 Murray S. Kucherawy wrote: > On Mon, Aug 27, 2012 at 2:53 AM, Alessandro Vesely wrote: >> 7.3 Relationship between Received-SPF and Authentication-Results >> >> Per identity results are conveyed using one or two stanzas >> (resinfo) in one or two Authentication-Results header fields. >> There is no identity tag in those stanzas, as its value can be >> inferred by the presence of the smtp.mailfrom or smtp.helo tags, >> which imply the corresponding identities. If the result is the >> same for both identities, one stanza is enough to convey both tags. >> >> In case both kinds of trace header fields are added at the same >> hop, they MUST be compatible, in the sense that the result for any >> given identity, and the value of helo/smtp.helo MUST NOT differ, >> and the value of envelope-from/smtp.mailfrom MUST either be equal >> or have an equal domain if the value of smtp.mailfrom consists of >> the domain portion only. Fields can complement one another, though. > > Is the normative stuff necessary, or does that discussion belong in > Security Considerations? What interoperability breaks if the MUSTard > you have there is removed? Presumably consumers of this information > aren't looking for both fields. The MUSTard serves just to convince consumers that they can look for the field they prefer, no need to compare them. Perhaps, without it, someone can think that uncertain cases like, say, temperror vs neutral, could be rendered by setting different results in those fields, possibly assuming that each field correspond to some class of consumers. > Another important distinction is that RFC4408 contained no protections > against spoofed Received-SPF attacks, while RFC5451 did. Right. From john@jlc.net Mon Aug 27 08:57: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 9307021F858A for ; Mon, 27 Aug 2012 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.822 X-Spam-Level: X-Spam-Status: No, score=-105.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nXRrydxNLzV for ; Mon, 27 Aug 2012 08:57:23 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6A21F8593 for ; Mon, 27 Aug 2012 08:57:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0BE3233C30; Mon, 27 Aug 2012 11:57:22 -0400 (EDT) Date: Mon, 27 Aug 2012 11:57:22 -0400 From: John Leslie To: Alessandro Vesely Message-ID: <20120827155722.GE72831@verdi> References: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> <503B8A4C.9030701@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503B8A4C.9030701@tana.it> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 15:57:23 -0000 Alessandro Vesely wrote: > On Mon 27/Aug/2012 15:29:45 +0200 John Leslie wrote: >> >> Even if some senders intend reject-on-fail, and some receivers >> practice it, it lacks _any_ justification in the model of 4408 -- >> because the relationship between sender policy and receiver action >> is illusory: there's nothing in the envelope to tell the receiver >> whether the sending MTA is an originator or an intermediary. >> >> I suggest that reject-on-fail _be_ mentioned; but described as >> being based on a faulty assumption that the sending MTA is an >> originator. > > It would be enough to consider the helo identity to ascertain that > point. A rather scarce information if one misses a reputation system, > but let's recall the declared purpose of SPF was just to force > spammers to use their own domain names. I would love to discuss using the HELO identity; but I fear it exceeds our charter. Nonetheless, if Alessandro replies quickly enough, perhaps he could explain what he was suggesting before the WGCs can stop this thread. ;>) -- John Leslie From ajs@anvilwalrusden.com Mon Aug 27 09:00: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 1315F21F8610 for ; Mon, 27 Aug 2012 09:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[AWL=-2.352, BAYES_05=-1.11, FRT_POSSIBLE=2.697, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwjC774HPBxp for ; Mon, 27 Aug 2012 09:00:19 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3923221F854E for ; Mon, 27 Aug 2012 09:00:19 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3BBBE8A031 for ; Mon, 27 Aug 2012 16:00:17 +0000 (UTC) Date: Mon, 27 Aug 2012 12:00:16 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120827160015.GC84552@mx1.yitter.info> References: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> <503B8AD3.1050006@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503B8AD3.1050006@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:00:20 -0000 Colleagues, Think of this as an attempt at scope-limiting advice from the chair. My natural tendency is always to try to allow people to work out their disagreements by argument, but we are rapidly (re-)approaching the point where people appear to be dug in on positions. I'd like to avoid making decisions about who is in the rough if I can. On Mon, Aug 27, 2012 at 10:57:23AM -0400, Hector Santos wrote: > -ALL was designed to be independent of anything else and is 100% > deterministic. To me, finding a FAULT has a higher payoff then > anything in this era of high volume abuse. The faster to filter > the junk, the more you can apply augmented "Heuristic" reputation > stuff. But then again, we been there before with this debate? What does _any_ of that have to do with the sender's publication? This is not attending to the distinctions among protocol, implementation, and deployment. The above is about what you can do with a system, once it is deployed. It is useful to think about these things. It is _not_ part of the protocol as such. Alessandro Vesely's suggestion is on target here: this stuff doesn't belong in the protocol document, and if someone wants to pursue it they should write a draft that includes all these deployment matters. I strongy encourage those who have opinions about these issues to start writing that draft. It becomes a possibile article for adoption if the WG decides to recharter; otherwise, it can be pursued by other publication means. But we need something stronger than, "This is my opinion," to continue talking about what are really operational metters in the protocol document. It doesn't belong there. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Mon Aug 27 09:18: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 7A18421F8539 for ; Mon, 27 Aug 2012 09:18:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR2n1r44v8Lg for ; Mon, 27 Aug 2012 09:18:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AA221F8525 for ; Mon, 27 Aug 2012 09:18:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7RGIM8X014013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 09:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346084315; bh=4VparzqAmXeaU4Jljr/LNuVlnE8gvkcFY69/fvXdeKw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qhiR+AHQhix9iC5jSlab0xvgDK7uWIfG+KFcAMVGDFhk9dmN6HaWmremURPPB/g28 5xI4eEQavDOAm6/mbvJewMGil/uiTOpCH149rCWpLLxoDSUmddrdSClpmQLLv3tXBI 3ozg7G4F4XhJYzo0ekAkaRX4RJgFQx8tMWMMkBmk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346084315; i=@elandsys.com; bh=4VparzqAmXeaU4Jljr/LNuVlnE8gvkcFY69/fvXdeKw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dJvA3Nbo4UM6n6R0t5zEFbFJD8EzR1ugRR0hkrou+/rBhHWigynaNGV0fPOAJzDb/ H/+NkipADoHHGSr4nDd04uuK2kUzTSWojN95M1bCdjuUjYBxtwe877kD9/M92lnmyN 2FSnXn8q16hAmiQcN09X7zUFlisa3P+BlbGe1k74= Message-Id: <6.2.5.6.2.20120827055802.0a161668@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Aug 2012 08:56:11 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <503B4CD4.3080104@tana.it> References: <6.2.5.6.2.20120824135405.0a6d9708@elandnews.com> <5038B27D.6070001@tana.it> <6.2.5.6.2.20120825074644.0999d658@elandnews.com> <503B4CD4.3080104@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Rejecting mail on SPF Fail as a requirement (off-topic) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:18:38 -0000 Hi Alessandro, At 03:32 27-08-2012, Alessandro Vesely wrote: >thank you for co-chairing this WG in particular. However, I object to >the excess of aseptic formalism that at times you seem to entrench That's an unusual objection. :-) >yourself within. How come you have no opinion? Why wouldn't it >matter whether you like something or not? I'm happy of your openness I would have to review the document to form an opinion. I am lazy to do that. Likes or dislikes do not matter; it's the arguments that matter. Regards, S. Moonesamy From hsantos@isdg.net Mon Aug 27 09:22: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 594E421F8539 for ; Mon, 27 Aug 2012 09:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.649 X-Spam-Level: X-Spam-Status: No, score=-100.649 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMkqSlIIg0kI for ; Mon, 27 Aug 2012 09:22:00 -0700 (PDT) Received: from catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6585921F8495 for ; Mon, 27 Aug 2012 09:22:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3984; t=1346084513; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=H+/8SxiWZ93JbyCt/Hg0Xp45nJw=; b=tcUICaaaW5IqPDozL7uG bBNWI0waXhXyO5u40cPDC1dM1OwWrDmMR3mORxPhXdMsSGw2nUj/uvJUH/rPQrZL O1cFlecteSgpXo1edhppqK/22k0ncMjYJ4Q8iNLsWQ2Dm84w8gPA78ggu29o+f+I 8rbh8vCbbEN5ZEeMZwCDmeg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 12:21:53 -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 2106306492.5114.1644; Mon, 27 Aug 2012 12:21:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3984; t=1346084315; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xuO3Cnr McY7fWDGvUrIOEC/cgl2+bGKeTs8ybS4+Epw=; b=1VpvToDkVRjksQS7XXJn2dW hnOz3NQqCE2wGVxkpPcuccYdtjDPn+MQTcwhCiJXrW2f6vF25kQTMmFQkN/kUXTn EwZp1MHO6HwMAuSl60w3w0Eok04zvAjs+ljHI6dnpGY1HYQNsy6+ad9L8ryy1A7r aJG5SEnHker7yvfgmTc4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 12:18:35 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2705112942.9.1824; Mon, 27 Aug 2012 12:18:34 -0400 Message-ID: <503B9ED6.3040903@isdg.net> Date: Mon, 27 Aug 2012 12:22:46 -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: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> <503B8AD3.1050006@isdg.net> <20120827160015.GC84552@mx1.yitter.info> In-Reply-To: <20120827160015.GC84552@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:22:01 -0000 I believe you have a very unfair view of my input. I am not implying anything you seem to be suggesting. Andrew Sullivan wrote: > Colleagues, > > Think of this as an attempt at scope-limiting advice from the chair. > My natural tendency is always to try to allow people to work out their > disagreements by argument, but we are rapidly (re-)approaching the > point where people appear to be dug in on positions. I'd like to > avoid making decisions about who is in the rough if I can. > > On Mon, Aug 27, 2012 at 10:57:23AM -0400, Hector Santos wrote: > >> -ALL was designed to be independent of anything else and is 100% >> deterministic. To me, finding a FAULT has a higher payoff then >> anything in this era of high volume abuse. The faster to filter >> the junk, the more you can apply augmented "Heuristic" reputation >> stuff. But then again, we been there before with this debate? > > What does _any_ of that have to do with the sender's publication? The Domain defined it, it is "what is the sender policy?" > This is not attending to the distinctions among protocol, > implementation, and deployment. I believe it is. But its your opinion that trumps here. I don't think I am saying anything wrong. Note, I am not making a mountain here. > The above is about what you can do with a system, once it is > deployed. It is useful to think about these things. It is _not_ part > of the protocol as such. I believe it is what is described in RFC4408, perhaps in different semantics and terms, such as defining what is authorizized or not, that has very powerful deterministic value and this is again described in RFC4408. is it not? > Alessandro Vesely's suggestion is on target here: this stuff doesn't > belong in the protocol document, and if someone wants to pursue it > they should write a draft that includes all these deployment matters. Now, in my opinion, the suggestion is changing the scope of the scope. I believe it does belong, which I would not be surprise what if people are gaining a greater sense of confusion by removing and attempting to define what SPF is or its no. I say its this. You say its that. Who's right and how do we determine it? Again, I don't see a problem. I am trying to advocate a position that is not what you believe RFC 4408 is. I have SPF implemented as a vendor for thousands of customers and also deployed as as support site as one of the original adopters. I believe my input is legitimate and I'm seeing a very dangerous trend with a redefinition of what SPF is not. > I strongy encourage those who have opinions about these issues to > start writing that draft. It becomes a possibile article for adoption > if the WG decides to recharter; otherwise, it can be pursued by other > publication means. But we need something stronger than, "This is my > opinion," to continue talking about what are really operational > metters in the protocol document. It doesn't belong there. It should without saying these are my opinions and what others are saying are opinions too. There is no need for a draft or I-D. Everything I stated is already written in RFC4408 in some way or another. I didn't mandate anything. But input from all sides needs to be stated otherwise changes are made that are not quite, in my technical and engineering SPF experience, valid. Some items I see as poor and do not wish to see it happen. To me, this are changes to the SPF specifications. I don't think I have made any kind of suggestion or statement that even comes close to mandating a change or requirement. If you can show it, please do. If you are going to excommunicate me for being concern of the trend I am seeing here, then I there is something serious flawed about this WG and how it is being run. Its not good if you need to continue to target me for your moderation when I simply provided a valid argument that counters another I view as incorrect. -- HLS From superuser@gmail.com Mon Aug 27 09:22: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 E44B321F854F for ; Mon, 27 Aug 2012 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq8EK1HPOoHx for ; Mon, 27 Aug 2012 09:22:28 -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 2A89821F8495 for ; Mon, 27 Aug 2012 09:22:27 -0700 (PDT) Received: by lahm15 with SMTP id m15so2816964lah.31 for ; Mon, 27 Aug 2012 09:22:27 -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=6ak/G9+TVtuxVm/bxXLDTrYtOCEKAhPBMcdazwY/a6c=; b=DYxIMa8RvPuwf/Ue1fxI8c8KlKmF4e+TIwQu48HYbCiN1zz5EYAnAmgFm9xgTNfacb 7UhtXRJtgbo26LSMt6Yg0v3zR8biR+eK5UT2Dj0/EhciOi35BzK1ZiLDpAtGaBD1v38r zfIALalN3qxHffeylZllrV9kQPLXCvLBsRRXp3kZgcp6xpXtnkg4KxBJ+20lfNXJt86m 9B+YARZf0t225woeSC8KTImvDp2Ewh9WGaooqnt4/3Dr/fA2ZTBPpPmcBqx7wu8qNYAH mhdJX57CNWoeUDuhmvNRHcyG/0HwPvtt3OE258CfsMWeuyXFaGXzP4zDqfKcGu99erBs +VjA== MIME-Version: 1.0 Received: by 10.112.82.170 with SMTP id j10mr3420682lby.8.1346084546948; Mon, 27 Aug 2012 09:22:26 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Mon, 27 Aug 2012 09:22:26 -0700 (PDT) In-Reply-To: <503B8AC8.8080009@tana.it> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> Date: Mon, 27 Aug 2012 09:22:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:22:29 -0000 On Mon, Aug 27, 2012 at 7:57 AM, Alessandro Vesely wrote: >> Is the normative stuff necessary, or does that discussion belong in >> Security Considerations? What interoperability breaks if the MUSTard >> you have there is removed? Presumably consumers of this information >> aren't looking for both fields. > > The MUSTard serves just to convince consumers that they can look for > the field they prefer, no need to compare them. Is that an interoperability concern? > Perhaps, without it, > someone can think that uncertain cases like, say, temperror vs > neutral, could be rendered by setting different results in those > fields, possibly assuming that each field correspond to some class of > consumers. The only case where I can imagine an ADMD using both of them would be knowledge that there are agents inside that use one and agents inside that use the other. I can't imagine a single agent that uses both and would be confounded by the existence of both fields with differing information. I think that renders the MUSTard unnecessary. Instead, if you have different agents, some of which want Received-SPF and some want Authentication-Results, then you essentially have two disjoint communication channels from the verifying agent to those internal agents. What's the benefit of demanding that they include the same message? -MSK From hsantos@isdg.net Mon Aug 27 09:41: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 46DBB21F8557 for ; Mon, 27 Aug 2012 09:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.633 X-Spam-Level: X-Spam-Status: No, score=-100.633 tagged_above=-999 required=5 tests=[AWL=-1.653, BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCDhLevSFoF2 for ; Mon, 27 Aug 2012 09:41:19 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7521F853F for ; Mon, 27 Aug 2012 09:41:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1519; t=1346085669; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=jMEkeLuJZcz1l80j0bYLUTW1FNQ=; b=O5CqOqALSiBJox0qloJ6 MZRP+fNoXd1W/kph0KcoeL9OmvD3r5aO7o5b8aQAKssU1IqVfPh37qaoqyPGqpe3 31xg1OAu1D99jgShQSlan58IyrSgdN3Bn/zapIx+b4fjxbrcHQkAudtz1BZQKZe1 PqKR8PaPiLU6P80l1VTSeDg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 12:41: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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2107461742.5114.2780; Mon, 27 Aug 2012 12:41:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1519; t=1346085467; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=j/2HMvd dOXAx19KdfoXFMsBHDlivL9mLiSV/witWaDY=; b=sNGkxQf+xjSr/bpkXr3u/gx SCGIzydZxHcgOONmoTsz9SQmihSyaJ51ruH9KocBQLA4b2F7OA8KhDvAwlDawv2B krcDV3LgnXG0VWNuvImSc3UTbwra1I0eQ28pmQUH/16+RSVS6u3v5BFPJ5QtpyEk dbjbmaEnhrPM+wbTcyA4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 12:37:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2706265661.9.1552; Mon, 27 Aug 2012 12:37:46 -0400 Message-ID: <503BA318.2090302@isdg.net> Date: Mon, 27 Aug 2012 12:40:56 -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: <20120826114656.GB72831@verdi> <20120827132945.GD72831@verdi> <503B8AD3.1050006@isdg.net> <20120827160015.GC84552@mx1.yitter.info> <503B9ED6.3040903@isdg.net> In-Reply-To: <503B9ED6.3040903@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:41:20 -0000 Correction: > Andrew Sullivan wrote: >> I strongy encourage those who have opinions about these issues to >> start writing that draft. It becomes a possibile article for adoption >> if the WG decides to recharter; otherwise, it can be pursued by other >> publication means. But we need something stronger than, "This is my >> opinion," to continue talking about what are really operational >> metters in the protocol document. It doesn't belong there. > > It should without saying these are my opinions and what others are > saying are opinions too. There is no need for a draft or I-D. I believe I was the first, and as an email to Barry early in the WG suggesting that another WG document, Deployment Guide, may be needed. But that was to help accommodate support for new integrated ideas, such as DKIM which was obvious in the minds of some folks. The different is that we got what seems a dispute about the "Theory of SPF" something already described as a dime a dozen RFC protocol, nothing special about it than another other mixed functional/technical RFC document. I don't understand what you want Andrew quite honestly. I end this in the words of another well respected WG participant: http://www.ietf.org/mail-archive/web/spfbis/current/msg02373.html "Remember that the point of a standard is to tell people how to write their software so that it interoperates. I think RFC4408 does that quite well as an IETF experiment and a World Wide pseudo-standard. -- HLS From johnl@iecc.com Mon Aug 27 09:41: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 2C13921F8557 for ; Mon, 27 Aug 2012 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.934 X-Spam-Level: X-Spam-Status: No, score=-109.934 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wirrvlQ8twDZ for ; Mon, 27 Aug 2012 09:41:37 -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 04BEF21F855D for ; Mon, 27 Aug 2012 09:41:36 -0700 (PDT) Received: (qmail 83268 invoked from network); 27 Aug 2012 16:41:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Aug 2012 16:41:30 -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=503ba33a.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=xZXwwlyazDIvQrf3TkEmFN93Oeamfkj0EwIs+1S9Gzs=; b=OmcvtnRj+fLjiz44n7q1UUp/HlMSbaZoDGNDJ2VdipBy/R5NoB/CGc/W8+JmUyR9WgSzmxiPU+Kea3kHUoTxTi+sMXVkF+qG77ABTVb4xUAY/OVnvW7RFYDyyLYJIxIx2fT+IBvTxOmcnio1LDXskoi2kwN5TXLbQI3oIwVwDEg= 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=503ba33a.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=xZXwwlyazDIvQrf3TkEmFN93Oeamfkj0EwIs+1S9Gzs=; b=YsjARSMmsFGEkxr4tZoWViO/ZY2REt0no7sKVc6UzlKCG9sAUHGAlMhnzPp4ONOECFXzVaESg6lVtQnQEnr+98GT7o3ig/9uatpmPIDFB/ah+HZbcwPeY+m8VWtrNPoO7zJqfMMW2ztubSbCRxCXUojnIjtSJRHerbXfoGsg78w= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Aug 2012 16:41:08 -0000 Message-ID: <20120827164108.60439.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <503B8A4C.9030701@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] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 16:41:38 -0000 >It is possible for B to add an Authentication-Results field with SPF >results, and sign it using DKIM. If C trusts B, it can then >wholeheartedly accept the message. If C trusts B, he should just deliver the message rather than wasting time second guessing B's filtering. Do we really have to go through this tired argument yet again? R's, John From sm@elandsys.com Mon Aug 27 11:22: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 9DF2521F8505 for ; Mon, 27 Aug 2012 11:22:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnEHpatndr0J for ; Mon, 27 Aug 2012 11:22: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 6373D21F84F8 for ; Mon, 27 Aug 2012 11:22:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7RIM27r025515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Aug 2012 11:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346091734; bh=pEXgPVczIdjy9+nVUlWp1ZhH34nx82QNH0zZMuiMNu4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=dRco23NrVD4OY84icB2EuD+K0ie40pdadAKJ4q11KVIADomdBKpaG9ECkqJ3AXWyv 9BfrejeoGwqHsSr4fOKmkb5SHZj2lpLn1oI6Mdl5PbIEqDYtmxQpS8mmIwXewmzW/v HQYgTjpqM+RV7Lk6rQwlxbATqNHQqyXzCqjj3f5g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346091734; i=@elandsys.com; bh=pEXgPVczIdjy9+nVUlWp1ZhH34nx82QNH0zZMuiMNu4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=GZSRsg92f/XIeBp3f/dxTTMEbqR6/nA/cdYwm8yeReggp663f9wJjSBGYpZOLXosK CoTWwuZ8ZGHPf2brAcvL0iSL48e6v5MaiGEDLgvdg5Ji7mf/s1x3KvtSl72aPzCVBV ZnNPc2+0fvKrGiXywT9zN71iQH1TvN/7I+La6oD8= Message-Id: <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Aug 2012 11:19:05 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120827164108.60439.qmail@joyce.lan> References: <503B8A4C.9030701@tana.it> <20120827164108.60439.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 18:22:17 -0000 Hello, Here's a quick summary. Scott Kitterman said that a sender policy is not about a sender telling a receiver what to do [1]. A sender policy is a statement that mail was either sent in accordance with the sender's policy (pass), it wasn't (fail), or one of several varieties of uncertainty. Hector Santos disagreed that there was a misunderstanding [2]. Dave Crocker mentioned that clarity about the role of this specification is essential [3] and that (he could not find) language in the current draft that attempts the kind of clarity Scott's above text has. Scott Kitterman mentioned that the misunderstanding is not new [4] and said that SPF was originally Sender Permitted From [5]. Alessandro Vesely mentioned that perhaps the WG will even recharter and complete the receiver policy afterwards [6]. Hector Santos mentioned the following: "Now, in my opinion, the suggestion is changing the scope of the scope. I believe it does belong, which I would not be surprise what if people are gaining a greater sense of confusion by removing and attempting to define what SPF is or its no. I say its this. You say its that. Who's right and how do we determine it? Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02347.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02349.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02348.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02351.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02355.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02368.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02392.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02395.html From hsantos@isdg.net Mon Aug 27 11:41: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 5967021F855D for ; Mon, 27 Aug 2012 11:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoGjZZDp5QdP for ; Mon, 27 Aug 2012 11:41:32 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3421F843F for ; Mon, 27 Aug 2012 11:41:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3041; t=1346092889; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=z7mXt+BlBwHND0KUaCkPsEliIXE=; b=IxX66vFT9CSC7+4hY4Aw GvI1YX7pwYsqMzGyY6fo9GRjPRJ0/pS0y6Zt756OEtQW7KIL2/zWhHXvKrJXtjwO TSwj8s2lkvTetQJcnlB98tqTxSNT99+7ew/l8m4BQ7OaLwf93dri6ENQv4nzCOQL 3ajfd2jfZlhm3kl/fKz8mBw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 14:41:29 -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 2114682061.5114.5716; Mon, 27 Aug 2012 14:41:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3041; t=1346092690; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fVeWQ3T CucnF2o0g5Ky6pNSbiMS+JKny8J/znozBEg4=; b=Q3gwWqOKQxa9XUkxUVIKbeB sYgN4EU0fhJ9yvYaXM1+fvVYhpJXc+RWw9v/N7dRRqsp5BfxoSEIA4kfcibyoRwZ +t297Jl7zR2R4Wi+h0xfwzTeHj2mQmgRS8fu1Z/gXFarBOz7BLOan83WWHajbTnc ny01eqxFvQs+KPNZrk5w= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 14:38:10 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2713488474.9.4400; Mon, 27 Aug 2012 14:38:09 -0400 Message-ID: <503BBF53.3040800@isdg.net> Date: Mon, 27 Aug 2012 14:41:23 -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: <503B8A4C.9030701@tana.it> <20120827164108.60439.qmail@joyce.lan> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> In-Reply-To: <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 18:41:33 -0000 SM, You are attributing me to a comment only applicable to a statement made by Mr. Sullivan suggesting Alessandro's input was on target with an idea of removing all deployment discussions in RFC4408: "Alessandro Vesely's suggestion is on target here: this stuff doesn't belong in the protocol document, and if someone wants to pursue it they should write a draft that includes all these deployment matters." My comment basically disagrees with this idea. I believe it (deployment matters) does belong in RFC4408 and should not be removed and I believe will begin a major scope change creating confusion. We don't need a deployment Guide within the limited scope we already have in SPF. However, I did note I suggested Deployment Guide to Barry Leiba for for the WG (and even volunteered to write it) but only related to integrated ideas with DKIM and also SPF2.0 (SenderID, Submitter), etc, not to remove the basic SPF client/server protocol description for RFC4408bis. Thanks S Moonesamy wrote: > Hello, > > Here's a quick summary. > > Scott Kitterman said that a sender policy is not about a sender telling > a receiver what to do [1]. A sender policy is a statement that mail was > either sent in accordance with the sender's policy (pass), it wasn't > (fail), or one of several varieties of uncertainty. Hector Santos > disagreed that there was a misunderstanding [2]. Dave Crocker mentioned > that clarity about the role of this specification is essential [3] and > that (he could not find) language in the current draft that attempts the > kind of clarity Scott's above text has. Scott Kitterman mentioned that > the misunderstanding is not new [4] and said that SPF was originally > Sender Permitted From [5]. Alessandro Vesely mentioned that perhaps the > WG will even recharter and complete the receiver policy afterwards [6]. > > Hector Santos mentioned the following: > > "Now, in my opinion, the suggestion is changing the scope of the scope. I > believe it does belong, which I would not be surprise what if people are > gaining a greater sense of confusion by removing and attempting to > define > what SPF is or its no. I say its this. You say its that. Who's > right and > how do we determine it? > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02347.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02349.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02348.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02351.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02355.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02368.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02392.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02395.html > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Mon Aug 27 11:48: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 7AD8421F852A for ; Mon, 27 Aug 2012 11:48:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E6FkpqYAgP3 for ; Mon, 27 Aug 2012 11:48: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 CA6C421F851A for ; Mon, 27 Aug 2012 11:48:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7RImfPK026643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 11:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346093333; bh=LVqYnKZWMT1aXqx3OHF9q7tm0klp82CdZBKTiS6g+JA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=F6fkfuT6aloF6nbUOCyJCSw3KAxB8fHJbeH27GQbLr/rEgHbwNB/kVIvYvOUFuXwq GmIextiZ2pLR4P04JCp5D5ImtqDgRm8GRDIh7Yo8Wb5ylXsPUolm7+gGbhI+G5lw3/ AksetnhRi5qXnph5uWcDONRAdwgWMZK9GOvLitts= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346093333; i=@elandsys.com; bh=LVqYnKZWMT1aXqx3OHF9q7tm0klp82CdZBKTiS6g+JA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p+00JOlnxVD3HDkTswT1VMJIqoQfZhzWfIAyjbjT8sjn54op562g1/r7bzQ7O97QZ IklK/1Hd+OnHB77/2ompqECbbRL0esIP5D9pMGkBZlPVYJrWQSomdbfQx0HWbPK3Tv AKORxSUbcfYHELdmTBCgSBzViQbQ1kTZi4V6I6KQ= Message-Id: <6.2.5.6.2.20120827114401.0958f518@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Aug 2012 11:48:09 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <503BBF53.3040800@isdg.net> References: <503B8A4C.9030701@tana.it> <20120827164108.60439.qmail@joyce.lan> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <503BBF53.3040800@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 18:48:56 -0000 Hi Hector, At 11:41 27-08-2012, Hector Santos wrote: >You are attributing me to a comment only applicable to a statement >made by Mr. Sullivan suggesting Alessandro's input was on target >with an idea of removing all deployment discussions in RFC4408: I apologize for that. Regards, S. Moonesamy From john@jlc.net Mon Aug 27 12: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 F105A21F8517 for ; Mon, 27 Aug 2012 12:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.837 X-Spam-Level: X-Spam-Status: No, score=-105.837 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhlDUchs-UQU for ; Mon, 27 Aug 2012 12:27:16 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7745221F8510 for ; Mon, 27 Aug 2012 12:27:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1AAA633C24; Mon, 27 Aug 2012 15:27:15 -0400 (EDT) Date: Mon, 27 Aug 2012 15:27:15 -0400 From: John Leslie To: S Moonesamy Message-ID: <20120827192715.GF72831@verdi> References: <503B8A4C.9030701@tana.it> <20120827164108.60439.qmail@joyce.lan> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 19:27:17 -0000 S Moonesamy wrote: > > Here's a quick summary. > > Scott Kitterman said that a sender policy is not about a sender > telling a receiver what to do [1]. A sender policy is a statement > that mail was either sent in accordance with the sender's policy > (pass), it wasn't (fail), or one of several varieties of > uncertainty. You seem to have missed several of my posts disagreeing that "a sender policy is a statement that mail... wasn't" sent "in accordance with the sender's policy" if check_host() returns "fail"; and stating this is a point of obscurity in the (current) spec. This issue deserves to be considered. While Scott's statement attempts to at least partly define what a sender policy is, it really doesn't help to define sender policy in terms of the output of a receiver action. It's possible, I suppose, that there may not _be_ any definition of sender policy we can agree on; but if that's the case, we owe it to our future readers to say so. -- John Leslie From sm@elandsys.com Mon Aug 27 13:31: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 4E57F21F8512 for ; Mon, 27 Aug 2012 13:31:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCCpMu0Dslb9 for ; Mon, 27 Aug 2012 13:31:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D20321F84EA for ; Mon, 27 Aug 2012 13:31:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.20]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7RKVEnc007954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 13:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346099486; bh=PpE9q9O4AMcnd+h6K3usVSoz9mDhZUi+Wp4zAJMRdBA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y1gHzb9C+UA5oZExcNBxOwnWfzdE2sJz3OALfpngq5fL38hYuleCgcGS/4vlzPm88 gdz02H1dqaczEFMlGsvLHGYnONH/msnlGB/gvTD4FVyFKbUglshv0Z2OvZk62/TrPK 2Ko8uxXjrzk9GdcfD9Bn+PgpE260wYpHiYUYkrI0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346099486; i=@elandsys.com; bh=PpE9q9O4AMcnd+h6K3usVSoz9mDhZUi+Wp4zAJMRdBA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UfB+I6e4NGnzuXjijPb123JA65slxsqB0elGs1hPY5x43d8Kw648CJegZTyh2J9JQ 9u676u4p9iU/JvGLCTCym3TdJKDMeHHPvooNFctU4daixNdNBGgzGXK5L/s+e0vNnd DnR2FKpLcy1BX6cjWm8XwGTQhMXpKk/Pnug6hmAM= Message-Id: <6.2.5.6.2.20120827124133.0aaead10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Aug 2012 13:30:24 -0700 To: John Leslie From: S Moonesamy In-Reply-To: <20120827192715.GF72831@verdi> References: <503B8A4C.9030701@tana.it> <20120827164108.60439.qmail@joyce.lan> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 20:31:35 -0000 Hi John, At 12:27 27-08-2012, John Leslie wrote: > You seem to have missed several of my posts disagreeing that "a >sender policy is a statement that mail... wasn't" sent "in accordance >with the sender's policy" if check_host() returns "fail"; and stating >this is a point of obscurity in the (current) spec. I apologize for the omission. I didn't include all the messages I read as it was meant as a quick summary. > This issue deserves to be considered. While Scott's statement The issue is being discussed on this thread. Regards, S. Moonesamy From spf2@kitterman.com Mon Aug 27 13:41: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 97B7821F8508 for ; Mon, 27 Aug 2012 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giyuPUbSlNaY for ; Mon, 27 Aug 2012 13:41:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 69CAE21F8505 for ; Mon, 27 Aug 2012 13:41:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CC1CE20E410A; Mon, 27 Aug 2012 16:41:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346100091; bh=Hbldkm0vyFMo57UXzZAyIFI+cJiiz0npwcAOy7syr5o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Hf7ttU6+VzlEQhlsW0EHpJvuQfX5MHKSWZlvsm9hZvNVMUPl9WvXUBQuEcR2XAl1O fPqt2YBxhm282yXz7gZnRrM7mL+rJ1SRpWStZOGpe3W0znp749Yu7k/NKw8wgc1xjV dWbM6Fp42V8oxT/VcefiifnbLocfSnoSnRirW2Z8= Received: from scott-latitude-e6320.localnet (unknown [207.87.40.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A3E6220E40E8; Mon, 27 Aug 2012 16:41:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Aug 2012 16:41:30 -0400 Message-ID: <7967888.2HlpJJ7FlH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120827192715.GF72831@verdi> References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 20:41:33 -0000 On Monday, August 27, 2012 03:27:15 PM John Leslie wrote: > S Moonesamy wrote: > > Here's a quick summary. > > > > Scott Kitterman said that a sender policy is not about a sender > > telling a receiver what to do [1]. A sender policy is a statement > > that mail was either sent in accordance with the sender's policy > > (pass), it wasn't (fail), or one of several varieties of > > uncertainty. > > You seem to have missed several of my posts disagreeing that "a > sender policy is a statement that mail... wasn't" sent "in accordance > with the sender's policy" if check_host() returns "fail"; and stating > this is a point of obscurity in the (current) spec. > > This issue deserves to be considered. While Scott's statement > attempts to at least partly define what a sender policy is, it really > doesn't help to define sender policy in terms of the output of a > receiver action. > > It's possible, I suppose, that there may not _be_ any definition > of sender policy we can agree on; but if that's the case, we owe it > to our future readers to say so. I'm about a day behind on this list, so this may have been discussed already ... My precise point is that sender policy is not defined " in terms of the output of a receiver action." I receiver action is a function of the receiver's policy. Personally, I think it's great when receivers reject mail that fails SPF checks (earlier this month I had such a rejection that led me to discover I'd misconfigured IPv6 address binding on a server), but I'm not at all confused that 4408bis can or should tell them to do such a thing. So I don't understand your comment. It seems to me like you are violently agreeing with me, but I'm not at all sure. Scott K From spf2@kitterman.com Mon Aug 27 14:13: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 3EB7921F844D for ; Mon, 27 Aug 2012 14:13: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbnHXlpEYXIN for ; Mon, 27 Aug 2012 14:13:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A135921F844C for ; Mon, 27 Aug 2012 14:13:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2144820E410A; Mon, 27 Aug 2012 17:13:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346101989; bh=+eApdUEGodyfNSjUvkgmebZQ8nlDfa6dbLuZyZGmfmI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ac07SuTUFtwnFDHkfQFo8ZG44RYC4Edu0YIBwDfUt/zoOTQKKKs6D9Z7f/cIJSnWP zI6SU+zNIBAiIqt1d/qsnJfW8mH9No6MtNG4Tc1f6AFPhlrlm1FK2ddlowcaKGmh4E m7tyy8UGdTPZVIAngy5AdhGgNw+zO5hlnWxqBNpM= Received: from scott-latitude-e6320.localnet (unknown [207.87.40.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E643720E40E8; Mon, 27 Aug 2012 17:13:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Aug 2012 17:13:07 -0400 Message-ID: <4317228.ax3BjIdquB@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503AA7F4.2080209@dcrocker.net> References: <1346020765.98529.YahooMailClassic@web125405.mail.ne1.yahoo.com> <503AA7F4.2080209@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] review of 4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 21:13:10 -0000 On Sunday, August 26, 2012 03:49:24 PM Dave Crocker wrote: > On 8/26/2012 3:39 PM, Arthur Thisell wrote: > > Which is why one of my suggestions was to go to exclusively type 99 > > SPF records for SPF3.0 > > Wow. > > Why should we go exclusively with something that has received such poor > adoption and for which there are still adoption barriers. (New DNS RRs > remain a challenge, for end-to-end interoperability. That's true, but any SPF 3.0 proposal is a long ways off. Since it will break from the current installed base, doing it in the new RR type is probably the way to go. Scott K From john@jlc.net Mon Aug 27 16:59:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5993321E8034 for ; Mon, 27 Aug 2012 16:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.851 X-Spam-Level: X-Spam-Status: No, score=-105.851 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaS9OoCfGuZ3 for ; Mon, 27 Aug 2012 16:59:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0311E8097 for ; Mon, 27 Aug 2012 16:59:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 209C433C26; Mon, 27 Aug 2012 19:59:04 -0400 (EDT) Date: Mon, 27 Aug 2012 19:59:04 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120827235904.GI72831@verdi> References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> <7967888.2HlpJJ7FlH@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7967888.2HlpJJ7FlH@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Aug 2012 23:59:05 -0000 Scott Kitterman wrote: > On Monday, August 27, 2012 03:27:15 PM John Leslie wrote: > >> This issue deserves to be considered. While Scott's statement >> attempts to at least partly define what a sender policy is, it really >> doesn't help to define sender policy in terms of the output of a >> receiver action. > > My precise point is that sender policy is not defined "in terms of > the output of a receiver action." Alas, that's not what your words said. Going back to your original post: ] ] A sender policy is a statement that mail was either sent in accordance ] with the sender's policy (pass), it wasn't (fail), or one of several ] varieties of uncertainty. (pass) and (fail) seem to refer to the output of check_host(), which _is_ a receiver action. Perhaps there is a better way to phrase my statement; but I think it very unwise to define "sender policy" in terms of the return-value of check_host(). > A receiver action is a function of the receiver's policy. Calling check_host() can be considered a receiver policy, I suppose, but I guess you meant "any action taken based on check_host()". > Personally, I think it's great when receivers reject mail that fails > SPF checks (earlier this month I had such a rejection that led me > to discover I'd misconfigured IPv6 address binding on a server), > but I'm not at all confused that 4408bis can or should tell them to > do such a thing. It may be that -all was intended to be a sender policy of "please reject all mail that comes to you through an intermediary"; but that was not documented in RFC 4408. We seem to have several folks who believe that was the intent, and your definition of "sender policy" would support them. IMHO, "sender policy" should reflect what the sender _does_ -- not what the sender hopes some other MTA will do. -- John Leslie From hsantos@isdg.net Mon Aug 27 18:20: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 8A80E21F84B2 for ; Mon, 27 Aug 2012 18:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjRKXfwQ5bpG for ; Mon, 27 Aug 2012 18:20:30 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DFEAE21F8489 for ; Mon, 27 Aug 2012 18:20:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2067; t=1346116820; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IyZTYYh/S17bolGoBUQiXmcfpcI=; b=KQ1EJUVTCV4ag5sXrdyz vmfsIBu1KdjuuPKfu2tllaX6TUWtTBQqXzLR7esL1X8L4xR9pVFpJalPHwYWlUYK 7tlDgATtxX3LbZ4/qX3qo48QUxLAQawUUjyu2BqD8eJEmyknbT1H09AD4p8z/U4D Xg29e8SoSV17SODgqmPJCYM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 21:20:20 -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 2138612287.5114.3432; Mon, 27 Aug 2012 21:20:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2067; t=1346116622; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NwzyRQc MOE8h0GRV+1w+sIUYZntQEXUabTCos3zpPik=; b=qrnDCWH9CHCAn9/9iKhkQ4y JvGHu8Q7gfNe+FsRHnU76aUxULhhTyHber4J1/Eg3G/02rbfPQb+F5Cra0r0iDxY ggijIT2IuI0CGKtJRJq5K+WUOSyyoKX41OF66TUe+PUaz8ePtmvme9cmxhBtCnEk r5CTT8JE+QrtnXzPolos= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 21:17: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 2737419442.9.3104; Mon, 27 Aug 2012 21:17:00 -0400 Message-ID: <503C1CF0.3080400@isdg.net> Date: Mon, 27 Aug 2012 21:20:48 -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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] New issue section 6.2 - clarify what kind of SMTP response X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 01:20:31 -0000 There has been much discussion related to the intent of domains publishing -ALL records for receiver interpretation. It is been my experience and understanding this has long been understood. Unfortunately, RFC4408 could of done a better job of making it even more clear to avoid what what we seeing today. But maybe it did? In section 6.2, it has clear illustrative examples of the type of explanation reason strings for -ALL policies: "Mail from example.com should only be sent by its own servers." -- a simple, constant message "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more information, including the IP address that failed the check "See http://%{d}/why.html?s=%{S}&i=%{I}" -- a complicated example that constructs a URL with the arguments to check_host() so that a web page can be generated with detailed, custom instructions The last one is not as clear at the first two. Further, in the section 4th paragraph. it provide what is the intent of the string: Since the explanation string is intended for an SMTP response ..... I believe this provides the ample evidence what SPF was intending to provide domains for receivers to follow. Two points about this: 1) In section 2.5.4, it refers to section 6.2 and usage of the exp directive, however, we should clarify in the above sentence whether the SMTP response is for a permanent or acceptance. Although it wouldn't make sense it if was a positive response to have such negative explanations. I can see if it possible for an accept+mark situation: MAIL FROM: 250-Mail from example.com should only be sent by its own servers. 250 Mail will be accepted but held in user's spam folder So I think we need a clarification here which pretty much means to add semantics so that the SMTP response can be for both rejection or acceptance transactions. 2) We should also note how this experience is carried over to the Received-SPF (and A-R if it remains as part of SPFBIS). -- HLS From hsantos@isdg.net Mon Aug 27 18:32: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 E899021F84EC for ; Mon, 27 Aug 2012 18:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.663 X-Spam-Level: X-Spam-Status: No, score=-101.663 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQv0LoE5j-5O for ; Mon, 27 Aug 2012 18:32:31 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F3ABD21F84EA for ; Mon, 27 Aug 2012 18:32:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3726; t=1346117540; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zfBdUCleQ2XeIvvwrxkrhtFRCn8=; b=tgUur2Ibg+xCSq3BBRNe c++H++JSfw4kPKva+7JeFGJkEplLUOS4DZtAqYKJxsgHyac201r8D9OVweRS/tHs pVZR3+rDtRpkBO0ZWsRXSTvigAjA7vXyhXUkgJGaazyY+h+JOHO5lV1U3ieEyH+k hrp3sjlzKdOC5WeeeaHHgyI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 21:32:20 -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 2139332574.5114.2100; Mon, 27 Aug 2012 21:32:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3726; t=1346117341; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sh0SqB5 sLYlaSL1cHzIgxpQm1yScmscfq5FPtv/L7E8=; b=SmKt+u36z+n3Obdwa74n4Df jIYWhHmggWlR7h5j6E58bpO0+6gRXYAGvo2A/2/bki+A/fWLccUmba35itv+pC/M ryMnHfkR8Agqy0jDPDfKixzpGIePs/wEdATyOuhbvRkCS0NMeGsmn3mqzZew0/Jf iZadt2fFoOSWU+PAS2GA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 27 Aug 2012 21:29:00 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2738138849.9.5224; Mon, 27 Aug 2012 21:29:00 -0400 Message-ID: <503C1FC3.8000309@isdg.net> Date: Mon, 27 Aug 2012 21:32:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Leslie References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> In-Reply-To: <20120827235904.GI72831@verdi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 01:32:32 -0000 I don't quite follow the goal of the thread. It seems it attempts to provide some reminder for a new purpose for what SPF does with ALL policies which IME is already pretty well defined, described for receivers to follow for many years. So is there something broken or is there something new we want to market or promote? I believe the main focus should be to help the REPORTING market (Murray's work) by helping to emphasize Accept+Mark as well as the rejection, and this is why I issued the security note to help close any loophole with increase accept+mark activities, especially with those who currently do rejection and may wish to consider an accept+mark mode of operation in order to being leverage future/current reporting work. As I indicated from vendor perspective in another post, our current stock software can not prepare accept+mark for deployment until we added separation logic. In the mean time, its reject only. My point here is I believe we can probably move forward if all parties accept the idea that SPF does provide non-normative protocol instructions to the receiver for handling -ALL and accept+mark should be a new focus especially since we are also contemplating adding A-R and in addition, I believe there is an errata for RFC5451 to change the registry keyword from "hardfail" to "fail" to match SPF "received-spf: fail" headers. This illustrates the goal of better supporting accept+mark mode of operations, and I hope we can welcome this and also rejects that already operate in this mode. -- HLS John Leslie wrote: > Scott Kitterman wrote: >> On Monday, August 27, 2012 03:27:15 PM John Leslie wrote: >> >>> This issue deserves to be considered. While Scott's statement >>> attempts to at least partly define what a sender policy is, it really >>> doesn't help to define sender policy in terms of the output of a >>> receiver action. >> My precise point is that sender policy is not defined "in terms of >> the output of a receiver action." > > Alas, that's not what your words said. > > Going back to your original post: > ] > ] A sender policy is a statement that mail was either sent in accordance > ] with the sender's policy (pass), it wasn't (fail), or one of several > ] varieties of uncertainty. > > (pass) and (fail) seem to refer to the output of check_host(), which > _is_ a receiver action. > > Perhaps there is a better way to phrase my statement; but I think > it very unwise to define "sender policy" in terms of the return-value > of check_host(). > >> A receiver action is a function of the receiver's policy. > > Calling check_host() can be considered a receiver policy, I suppose, > but I guess you meant "any action taken based on check_host()". > >> Personally, I think it's great when receivers reject mail that fails >> SPF checks (earlier this month I had such a rejection that led me >> to discover I'd misconfigured IPv6 address binding on a server), >> but I'm not at all confused that 4408bis can or should tell them to >> do such a thing. > > It may be that -all was intended to be a sender policy of "please > reject all mail that comes to you through an intermediary"; but that > was not documented in RFC 4408. > > We seem to have several folks who believe that was the intent, > and your definition of "sender policy" would support them. > > IMHO, "sender policy" should reflect what the sender _does_ -- > not what the sender hopes some other MTA will do. > > -- > John Leslie > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Mon Aug 27 20:55: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 B930921F8476 for ; Mon, 27 Aug 2012 20:55: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtWis-R7MOcG for ; Mon, 27 Aug 2012 20:55:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DB61A21F8473 for ; Mon, 27 Aug 2012 20:55:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 09CE920E410A; Mon, 27 Aug 2012 23:55:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346126118; bh=v+dr2VWbo1hdp8GCL5biHpzVmDqCazUvXYLhrzgiuSs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iV1Y4Ot79a6JHwBdY0RrGZwxT8ola8xhOcc1xPfFZm9tj84UAXM9FrtYrXTLSvY90 EFjRWEaLlw0cKecQkY9k3pT4SRotImlBw4XMGP3u04Rezf6y7O2yFa9hMZcMQSqMj4 K1N7zpfsdHAo8ABjrjFgz7KxeCNRmUxyRKYwEuSA= Received: from scott-latitude-e6320.localnet (ip-64-134-181-86.public.wayport.net [64.134.181.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A081B20E40E8; Mon, 27 Aug 2012 23:55:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 27 Aug 2012 23:55:15 -0400 Message-ID: <1372205.frOhBsbhem@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120827235904.GI72831@verdi> References: <503B8A4C.9030701@tana.it> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 03:55:19 -0000 On Monday, August 27, 2012 07:59:04 PM John Leslie wrote: > Scott Kitterman wrote: > > On Monday, August 27, 2012 03:27:15 PM John Leslie wrote: > >> This issue deserves to be considered. While Scott's statement > >> attempts to at least partly define what a sender policy is, it really > >> doesn't help to define sender policy in terms of the output of a > >> receiver action. > > > > My precise point is that sender policy is not defined "in terms of > > the output of a receiver action." > > Alas, that's not what your words said. > > Going back to your original post: > ] > ] A sender policy is a statement that mail was either sent in accordance > ] with the sender's policy (pass), it wasn't (fail), or one of several > ] varieties of uncertainty. > > (pass) and (fail) seem to refer to the output of check_host(), which > _is_ a receiver action. Upon reflection, I could have put this more clearly. The sender policy is the list of authorized sources published in the SPF record. The output of check_host() is an assessment of a message relative to that policy. Is it policy conformant, policy non-conformant, or unknown (of some variety). That assessment is not an action. It's an input into receiver policy. The receiver policy is entirely a local matter of how to dispose of the message. There are a number of things that can be done with it. > Perhaps there is a better way to phrase my statement; but I think > it very unwise to define "sender policy" in terms of the return-value > of check_host(). Then what is it? Would you agree it's the result of an assessment of a message relative to the sender policy? > > A receiver action is a function of the receiver's policy. > > Calling check_host() can be considered a receiver policy, I suppose, > but I guess you meant "any action taken based on check_host()". Yes almost. > > Personally, I think it's great when receivers reject mail that fails > > SPF checks (earlier this month I had such a rejection that led me > > to discover I'd misconfigured IPv6 address binding on a server), > > but I'm not at all confused that 4408bis can or should tell them to > > do such a thing. > > It may be that -all was intended to be a sender policy of "please > reject all mail that comes to you through an intermediary"; but that > was not documented in RFC 4408. I agree. It was not by accident that this is the case. > We seem to have several folks who believe that was the intent, > and your definition of "sender policy" would support them. SMTP time rejection was definitely a major consideration during SPF's development. It's what we'd have like to have recommended, but there were enough edge cases to make that imprudent. No matter how much some people like the idea, there are plenty others that don't. > IMHO, "sender policy" should reflect what the sender _does_ -- > not what the sender hopes some other MTA will do. I agree with this. That's what I was trying to communicate. Scott K From spf2@kitterman.com Mon Aug 27 21:03: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 159AA21F8449 for ; Mon, 27 Aug 2012 21:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ftVIXCb4KOD for ; Mon, 27 Aug 2012 21:03:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CE21F843F for ; Mon, 27 Aug 2012 21:03:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 07E7D20E410A; Tue, 28 Aug 2012 00:03:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346126628; bh=ayhI1/43XJHDq+ZpiSez6bx3WEAuoHAX9JltgSRHFiU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dBquNty6nvXcIQiUEQAq2nhWSvuoH/J/IWAe4mHi0Jlfl5H8APE1z7NWcu/XI2UE3 /t32JYOSA++aCAW+0Rfkb/G28yor1BRReJvPBzbcAqkDqprJKwCScT9pkJ3ERqw8Bu Nmbwf/KhqwqYLmPnfV4DMKk2nXHpMXZ5a4d6gQuE= Received: from scott-latitude-e6320.localnet (ip-64-134-181-86.public.wayport.net [64.134.181.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B2FB020E40E8; Tue, 28 Aug 2012 00:03:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 28 Aug 2012 00:03:44 -0400 Message-ID: <5240645.iuKD9yGGu1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503C1CF0.3080400@isdg.net> References: <503C1CF0.3080400@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue section 6.2 - clarify what kind of SMTP response X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 04:03:50 -0000 On Monday, August 27, 2012 09:20:48 PM Hector Santos wrote: > There has been much discussion related to the intent of domains > publishing -ALL records for receiver interpretation. It is been my > experience and understanding this has long been understood. > Unfortunately, RFC4408 could of done a better job of making it even > more clear to avoid what what we seeing today. > > But maybe it did? > > In section 6.2, it has clear illustrative examples of the type of > explanation reason strings for -ALL policies: > > "Mail from example.com should only be sent by its own servers." > -- a simple, constant message > > "%{i} is not one of %{d}'s designated mail servers." > -- a message with a little more information, including the IP > address that failed the check > > "See http://%{d}/why.html?s=%{S}&i=%{I}" > -- a complicated example that constructs a URL with the > arguments to check_host() so that a web page can be > generated with detailed, custom instructions > > The last one is not as clear at the first two. Further, in the > section 4th paragraph. it provide what is the intent of the string: > > Since the explanation string is intended for an SMTP response ..... > > I believe this provides the ample evidence what SPF was intending to > provide domains for receivers to follow. > > Two points about this: > > 1) In section 2.5.4, it refers to section 6.2 and usage of the exp > directive, however, we should clarify in the above sentence whether > the SMTP response is for a permanent or acceptance. Although it > wouldn't make sense it if was a positive response to have such > negative explanations. I can see if it possible for an accept+mark > situation: > > MAIL FROM: > 250-Mail from example.com should only be sent by its own servers. > 250 Mail will be accepted but held in user's spam folder > > So I think we need a clarification here which pretty much means to add > semantics so that the SMTP response can be for both rejection or > acceptance transactions. > > 2) We should also note how this experience is carried over to the > Received-SPF (and A-R if it remains as part of SPFBIS). All these are exemplary text. I don't think anyone is arguing that SMTP time rejection was not considered as an option. Of course it was, so I'm really confused about what point you are trying to make. Section 6.2 covers the "exp" modifier. It does not attempt to standardize the full SMTP session text and I don't think it should. Here's an example of the default fail text from my implementation: 550 Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=scott@fail.kitterman.org;ip=72.81.252.19;r=bogus@kitterman.org If you think writing different text in 4408bis is going to cause me to change this, you are mistaken. Scott K From hsantos@isdg.net Mon Aug 27 21:40: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 1A49A21E803A for ; Mon, 27 Aug 2012 21:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS7qEvySb1Ow for ; Mon, 27 Aug 2012 21:40:29 -0700 (PDT) Received: from news.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F00311E808E for ; Mon, 27 Aug 2012 21:40:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3438; t=1346128825; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZUETTN8iqpO+2KnGOrB7BeTKKLw=; b=nGuHkJeQAF61oRlItA1C BckxBAEJNN+nXzZFzLrSpbDbRli+sT16DO2SYAkk+5YBNPtxfa2rtGc1yXqpGIci EG493PwH/kDBBmHmvakc2/1uk3EYZNnzmy3HPMKVRdIRUrRdi8tjBAcbmnK9XbE0 /Kyh0jdMeMyIBtzfzMnkbUs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 00:40:25 -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 2150617921.5114.3804; Tue, 28 Aug 2012 00:40:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3438; t=1346128623; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tWcs8n/ w6hURRgOEF1SQ0CEGPaMoyfyEfrOFFyumxDA=; b=WbYR5gqDz7/NibMVCzsceHb caYg2PEMQvKw8BPVqpeNIVtKGCk69EwVPyb76Z6sy2BLldJCzKgN4XQ8oC0zN/P7 WKw2w+sAxS29xvNd/RP2i+nJZlPPYB/zU4N2H1aV+iB05nx4LAvUNMAd3MoV4SgQ x29xceq1R0oMTHp0CEGE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 00:37:03 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2749421239.9.3252; Tue, 28 Aug 2012 00:37:02 -0400 Message-ID: <503C4BB4.4060302@isdg.net> Date: Tue, 28 Aug 2012 00:40:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <503C1CF0.3080400@isdg.net> <5240645.iuKD9yGGu1@scott-latitude-e6320> In-Reply-To: <5240645.iuKD9yGGu1@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue section 6.2 - clarify what kind of SMTP response X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 04:40:31 -0000 Scott Kitterman wrote: > On Monday, August 27, 2012 09:20:48 PM Hector Santos wrote: >> There has been much discussion related to the intent of domains >> publishing -ALL records for receiver interpretation. It is been my >> experience and understanding this has long been understood. >> Unfortunately, RFC4408 could of done a better job of making it even >> more clear to avoid what what we seeing today. >> >> But maybe it did? >> >> In section 6.2, it has clear illustrative examples of the type of >> explanation reason strings for -ALL policies: >> >> "Mail from example.com should only be sent by its own servers." >> -- a simple, constant message >> >> "%{i} is not one of %{d}'s designated mail servers." >> -- a message with a little more information, including the IP >> address that failed the check >> >> "See http://%{d}/why.html?s=%{S}&i=%{I}" >> -- a complicated example that constructs a URL with the >> arguments to check_host() so that a web page can be >> generated with detailed, custom instructions >> >> The last one is not as clear at the first two. Further, in the >> section 4th paragraph. it provide what is the intent of the string: >> >> Since the explanation string is intended for an SMTP response ..... >> >> I believe this provides the ample evidence what SPF was intending to >> provide domains for receivers to follow. >> >> Two points about this: >> >> 1) In section 2.5.4, it refers to section 6.2 and usage of the exp >> directive, however, we should clarify in the above sentence whether >> the SMTP response is for a permanent or acceptance. Although it >> wouldn't make sense it if was a positive response to have such >> negative explanations. I can see if it possible for an accept+mark >> situation: >> >> MAIL FROM: >> 250-Mail from example.com should only be sent by its own servers. >> 250 Mail will be accepted but held in user's spam folder >> >> So I think we need a clarification here which pretty much means to add >> semantics so that the SMTP response can be for both rejection or >> acceptance transactions. >> >> 2) We should also note how this experience is carried over to the >> Received-SPF (and A-R if it remains as part of SPFBIS). > > All these are exemplary text. I don't think anyone is arguing that SMTP time > rejection was not considered as an option. Of course it was, so I'm really > confused about what point you are trying to make. I'll try better below. > Section 6.2 covers the "exp" modifier. It does not attempt to standardize the > full SMTP session text and I don't think it should. Never mention that, stated or implied it. > Here's an example of the > default fail text from my implementation: > > 550 Message rejected due to: SPF fail - not authorized. Please see > http://www.openspf.net/Why?s=mfrom;id=scott@fail.kitterman.org;ip=72.81.252.19;r=bogus@kitterman.org > > If you think writing different text in 4408bis is going to cause me to change > this, you are mistaken. Huh? Dude, calm down. I made a point in #1 that the reason was intended as a SMTP response and I am suggesting it should be expanded to clarify a rejection or acceptance response in order to be consistent with the rest of the changes in the rev. I made a point in #2 on whether the reason should/can/may be part of the marking, i.e. not just the SMTP response. -- HLS From spf2@kitterman.com Mon Aug 27 22:38: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 2086021F84D2 for ; Mon, 27 Aug 2012 22:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn-ncy1P8FUg for ; Mon, 27 Aug 2012 22:38:31 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3921F84D3 for ; Mon, 27 Aug 2012 22:38:31 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 229EAD0408A; Tue, 28 Aug 2012 00:38:30 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346132310; bh=VvvJQg2Zb78DjVT7TQm3i5xbqKBN/vXyjkNzza4F2bk=; h=References:In-Reply-To:Subject:From:Date:To:From; b=WkIeC28SWraxefxjAcReZ3XBVpPzEXrqKKMKXZX3hvd9gkNOc/pclvlNSBDfDFIS9 1ErjTB2kZCu4JB9BxKMSHYmw5rfEzzh2vDz5Wa3m3aJqpXifXIW4SwEw1JRphTPQ8M 4iZdZnMWJeI3blndZe8Rf0f1bZY7Zp4C4mbKQsXk= Received: from [IPV6:2600:1005:b123:938e:81c4:13bc:3997:6e7] (unknown [IPv6:2600:1005:b123:938e:81c4:13bc:3997:6e7]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6FB69D0407E; Tue, 28 Aug 2012 00:38:29 -0500 (CDT) References: <503C1CF0.3080400@isdg.net> <5240645.iuKD9yGGu1@scott-latitude-e6320> <503C4BB4.4060302@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <503C4BB4.4060302@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 28 Aug 2012 00:38:25 -0500 To: spfbis@ietf.org Message-ID: <1baec3bd-1ce3-43ad-8c9e-257431b5e204@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?New_issue_section_6=2E2_-_clarify_what_kind_of?= =?utf-8?q?=09SMTP=09response?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 05:38:32 -0000 Hector Santos wrote: >Scott Kitterman wrote: >> On Monday, August 27, 2012 09:20:48 PM Hector Santos wrote: >>> There has been much discussion related to the intent of domains >>> publishing -ALL records for receiver interpretation. It is been my >>> experience and understanding this has long been understood. >>> Unfortunately, RFC4408 could of done a better job of making it even >>> more clear to avoid what what we seeing today. >>> >>> But maybe it did? >>> >>> In section 6.2, it has clear illustrative examples of the type of >>> explanation reason strings for -ALL policies: >>> >>> "Mail from example.com should only be sent by its own >servers." >>> -- a simple, constant message >>> >>> "%{i} is not one of %{d}'s designated mail servers." >>> -- a message with a little more information, including the >IP >>> address that failed the check >>> >>> "See http://%{d}/why.html?s=%{S}&i=%{I}" >>> -- a complicated example that constructs a URL with the >>> arguments to check_host() so that a web page can be >>> generated with detailed, custom instructions >>> >>> The last one is not as clear at the first two. Further, in the >>> section 4th paragraph. it provide what is the intent of the string: >>> >>> Since the explanation string is intended for an SMTP response >..... >>> >>> I believe this provides the ample evidence what SPF was intending to >>> provide domains for receivers to follow. >>> >>> Two points about this: >>> >>> 1) In section 2.5.4, it refers to section 6.2 and usage of the exp >>> directive, however, we should clarify in the above sentence whether >>> the SMTP response is for a permanent or acceptance. Although it >>> wouldn't make sense it if was a positive response to have such >>> negative explanations. I can see if it possible for an accept+mark >>> situation: >>> >>> MAIL FROM: >>> 250-Mail from example.com should only be sent by its own >servers. >>> 250 Mail will be accepted but held in user's spam folder >>> >>> So I think we need a clarification here which pretty much means to >add >>> semantics so that the SMTP response can be for both rejection or >>> acceptance transactions. >>> >>> 2) We should also note how this experience is carried over to the >>> Received-SPF (and A-R if it remains as part of SPFBIS). >> >> All these are exemplary text. I don't think anyone is arguing that >SMTP time >> rejection was not considered as an option. Of course it was, so I'm >really >> confused about what point you are trying to make. > >I'll try better below. > >> Section 6.2 covers the "exp" modifier. It does not attempt to >standardize the >> full SMTP session text and I don't think it should. > >Never mention that, stated or implied it. > >> Here's an example of the >> default fail text from my implementation: >> >> 550 Message rejected due to: SPF fail - not authorized. Please see >> >http://www.openspf.net/Why?s=mfrom;id=scott@fail.kitterman.org;ip=72.81.252.19;r=bogus@kitterman.org >> >> If you think writing different text in 4408bis is going to cause me >to change >> this, you are mistaken. > >Huh? Dude, calm down. > >I made a point in #1 that the reason was intended as a SMTP response >and I am suggesting it should be expanded to clarify a rejection or >acceptance response in order to be consistent with the rest of the >changes in the rev. > >I made a point in #2 on whether the reason should/can/may be part of >the marking, i.e. not just the SMTP response. It's in Received-SPF, so yes it can. Scott K From vesely@tana.it Tue Aug 28 01:51: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 1260C21F8525 for ; Tue, 28 Aug 2012 01:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT7o-gfcEGyM for ; Tue, 28 Aug 2012 01:51:44 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6F21F8523 for ; Tue, 28 Aug 2012 01:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346143902; bh=NpgNXwee3BuaVd9zQTWmxhrH7APTROtpz/1miSP0u8Y=; l=2289; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jh1XeMZC3L2RLNjb3+GohPv/USvLGf/4e6zOGqlyTV5gC27LXejEHPjESZlOmedPd QyCK2uglKPMaRvYeyNTkSMsDL9aJt9knAGNPciaPBFMBJdUSgfnI/xdjSKM+QYA4EV PYBw5P+beT/tKSqq9Ar1B/nQZfqfpLiDV+aWt+qw= Received: from [109.115.139.30] ([109.115.139.30]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 28 Aug 2012 10:51:41 +0200 id 00000000005DC039.00000000503C869E.000055F4 Message-ID: <503C8690.1030004@tana.it> Date: Tue, 28 Aug 2012 10:51:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 08:51:45 -0000 On Mon 27/Aug/2012 18:22:26 +0200 Murray S. Kucherawy wrote: > On Mon, Aug 27, 2012 at 7:57 AM, Alessandro Vesely wrote: > >>> Is the normative stuff necessary, or does that discussion belong in >>> Security Considerations? What interoperability breaks if the MUSTard >>> you have there is removed? Presumably consumers of this information >>> aren't looking for both fields. >> >> The MUSTard serves just to convince consumers that they can look for >> the field they prefer, no need to compare them. > > Is that an interoperability concern? If it is, it's about the communication to downstream message processors. Is that the sense that Hector means when he says MTA-to-MDA protocol? >> Perhaps, without it, someone can think that uncertain cases like, >> say, temperror vs neutral, could be rendered by setting different >> results in those fields, possibly assuming that each field >> correspond to some class of consumers. > > The only case where I can imagine an ADMD using both of them would be > knowledge that there are agents inside that use one and agents inside > that use the other. Yes. > I can't imagine a single agent that uses both and would be > confounded by the existence of both fields with differing > information. I don't want to imagine that. However, if it becomes customary that in certain cases those fields differ, agents that examine both in order to detect such cases seem plausible. > I think that renders the MUSTard unnecessary. Hm... > Instead, if you have different agents, some of which want Received-SPF > and some want Authentication-Results, then you essentially have two > disjoint communication channels from the verifying agent to those > internal agents. What's the benefit of demanding that they include > the same message? Cleanliness of mind. If you have an undertone that you wish your agent captures, you should extend the relevant field appropriately and fill the new value when you find it. If that's a clever idea, it may get standardized, eventually. Differentiating agent's behavior by target field will cause confusion to agents beyond control, such as an IMAP client add-on. Home brewed code based on such kludges will be difficult to share and evolve. From vesely@tana.it Tue Aug 28 02:35: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 A447B21F84D2 for ; Tue, 28 Aug 2012 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHA-1fYQcC+v for ; Tue, 28 Aug 2012 02:35:25 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C053621F84D3 for ; Tue, 28 Aug 2012 02:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346146523; bh=88k15lBzKMy4uZvj5HN1AjkrqOrc30Vh1GgZqvGdNsY=; l=1760; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=a34dwjZNDXauhikiK6M4WV68Oyp7fz6Co+Y6P/mOyFvsdTwn6QwDQ2T6MPuETwo9x ltj57M4BVLoTl9s2eDC1XHgfHTtBJ9f6/zEpQcPqbdNU9qcQx9G1KUWjMKZPwoNcbj G2MDPd4qXoAkb80EGOz//58kYltDiWkssHVbSnq0= Received: from [109.115.139.30] ([109.115.139.30]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 28 Aug 2012 11:35:22 +0200 id 00000000005DC039.00000000503C90DB.00006103 Message-ID: <503C90D6.6070509@tana.it> Date: Tue, 28 Aug 2012 11:35:18 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <503C1FC3.8000309@isdg.net> In-Reply-To: <503C1FC3.8000309@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 09:35:25 -0000 On Tue 28/Aug/2012 03:32:51 +0200 Hector Santos wrote: > > I don't quite follow the goal of the thread. It seems it attempts to > provide some reminder for a new purpose for what SPF does with ALL > policies which IME is already pretty well defined, described for > receivers to follow for many years. I agree it's already defined, but certainly not "pretty well". > So is there something broken or is there something new we want to > market or promote? > > I believe the main focus should be to help the REPORTING market > (Murray's work) by helping to emphasize Accept+Mark Yes, that's relatively new, but SPF specification certainly predates it. For that use, "pass" is the most interesting result. The DMARC initiative allows a domain to state that messages not passing SPF or DKIM be quarantined or rejected. In addition, RFC 6650 provides for reporting spam to an authenticated domain's abuse-mailbox. Specifying Accept+Mark possibilities is definitely out of scope for SPF in general, and for our current charter in particular. However, in view of that new tendency (or "market", if you prefer) it does make sense to produce a cleaned-up specification of SPF, getting rid of all the badly defined receiver behavior. As soon as I get back to my office (next week, that is) I'll post a couple of drafts, as suggested by Andrew, to fully illustrate the concept: The cleaned-up SPF spec, and the receiver policy. Scott will use the parts of the first one as he likes. The second one will only be useful upon rechartering. However, don't think that standardizing an SPF protocol that does not at all consider rejection will have any visible impact on behavior. Normatively, it changes nothing about receiver behavior. From hsantos@isdg.net Tue Aug 28 04:12: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 49C5E21F842F for ; Tue, 28 Aug 2012 04:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.685 X-Spam-Level: X-Spam-Status: No, score=-101.685 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aJKwpZ7qkvv for ; Tue, 28 Aug 2012 04:12:56 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0AE21F842E for ; Tue, 28 Aug 2012 04:12:55 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1469; t=1346152366; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=13wykeitHSwXH2HqRU9n70SoZP4=; b=Ru1/JWIaGz8rX81NG8C9 TTWAc3adN1GpAqKexm88FUJKiSL1+cArTAJGfYwwPYRBrKeE9uvZ3lVEHvv74jXx BW0LjOaYh+BgDeUqZNYvDCiYThVM3uBpl9iaUymYW7NqZBogpnb6Md4bqMQdVRKE w8tFtr/EjTqbNK4jDxEiPbo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 07:12:46 -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 2174158347.6189.1476; Tue, 28 Aug 2012 07:12:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1469; t=1346152163; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=u63vYGw qe4SRTiYxn3Jh/Gmu+CYjPO7JZdsu8iKYobk=; b=0RGIKKrwkyjqsTDFfnv8HtT Hghb/wRUj+7NKNQpM6vrx/VCRcOjZJwpsohWNZ6PSOErm2j7dAZ8jSbxErlySX5v q9mieS0bZxeTlBVuToGGQksNbcO+rftlYAcNd2P1P9oJx2lLyQZRyeGXtl5+78TQ loheFeNS5Y/rUXILfxac= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 07:09:23 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2772961989.9.640; Tue, 28 Aug 2012 07:09:23 -0400 Message-ID: <503CA7AB.8000500@isdg.net> Date: Tue, 28 Aug 2012 07:12:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <503C1FC3.8000309@isdg.net> <503C90D6.6070509@tana.it> In-Reply-To: <503C90D6.6070509@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 11:12:57 -0000 Alessandro Vesely wrote: > On Tue 28/Aug/2012 03:32:51 +0200 Hector Santos wrote: >> I don't quite follow the goal of the thread. It seems it attempts to >> provide some reminder for a new purpose for what SPF does with ALL >> policies which IME is already pretty well defined, described for >> receivers to follow for many years. > > I agree it's already defined, but certainly not "pretty well". ok, but what is broken about it, perhaps is what I am seeking? What problem are we seeing? What are trying to fix? > Specifying Accept+Mark possibilities is definitely out of scope for > SPF in general, and for our current charter in particular. However, > in view of that new tendency (or "market", if you prefer) it does make > sense to produce a cleaned-up specification of SPF, getting rid of all > the badly defined receiver behavior. Yes, but that's what I scratching my head about. What badly defined receiver behavior? What specifically are we talking about and what is bad about it? What issues is it causing that we need so much time with it here? Are we just talking about uppercasing some keywords? I am just wondering if there anything wrong other than what we might want to focus more on, like accept+mark. The spec is peppered with receiver protocol instructions and except for issues already outlines and worked on to fix here and there, I don't see anything particular wrong with SPF as far as receiver behavior. -- HLS From superuser@gmail.com Tue Aug 28 06:52:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8615A21F84F9 for ; Tue, 28 Aug 2012 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fsCRLPvQvkV for ; Tue, 28 Aug 2012 06:52:04 -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 A8D5C21F84F8 for ; Tue, 28 Aug 2012 06:52:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so3498073lah.31 for ; Tue, 28 Aug 2012 06:52:02 -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=pbrysSVWKrAXQS3cfgXd5v1ojVj1ERjSuDbWrUKYlqo=; b=iui/1CdKs+PIbVJ5Ex0nfSL76slDqKyMuvKZr1anCEJhixUIq1LsHuq31dps5BKmjT Qqq5hTrCgY7SFIvjTVJ94BysdEo1mWmMxr7ESTEuK7Y4Gb/IDHo6U3BfElaNWZznRhxY PADfhE46mRYx2L3WGnqWBh7UneA0sV3jqps8XkgQYoNmbx1k+zo4PIcecbTuY5sqmzTd bUVieb6f78K49az4k8GF5W+lUI7ip2vUDWczh+MTKMRaGlaCrlkB5vaabxMN6W31uJIf UIBtYYlmEepCCFGH2GoTeBuMNMzB1rOvVbF1SCepV9zhfX8QqMNADaO/IEkxmqwgwhkm wPdQ== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr728787lbi.116.1346161922534; Tue, 28 Aug 2012 06:52:02 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Tue, 28 Aug 2012 06:52:02 -0700 (PDT) In-Reply-To: <503C8690.1030004@tana.it> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> Date: Tue, 28 Aug 2012 06:52:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 13:52:04 -0000 On Tue, Aug 28, 2012 at 1:51 AM, Alessandro Vesely wrote: >>> The MUSTard serves just to convince consumers that they can look for >>> the field they prefer, no need to compare them. >> >> Is that an interoperability concern? > > If it is, it's about the communication to downstream message > processors. Is that the sense that Hector means when he says > MTA-to-MDA protocol? I'm going by RFC5598 definitions. I believe he means originator to receiver, as different from relay-to-relay. MDA is a delivery agent, i.e., the thing that actually writes to inboxes. I think it's false to claim that the MDA is doing anything SPF-related at all, so if he means that then I disagree. SPF is therefore an out-of-band message between the originating MTA and the receiving MTA, which is what I mean when I say it's MTA-to-MTA. What that means to me is that we should spend very little energy talking about the communication between the receiver's MTA and agents internal to the ADMD such as the MDA or MUA. That's what Section 7 is about. >> I can't imagine a single agent that uses both and would be >> confounded by the existence of both fields with differing >> information. > > I don't want to imagine that. However, if it becomes customary that > in certain cases those fields differ, agents that examine both in > order to detect such cases seem plausible. That presumes the consumers of these fields will notice that they could get "better" information by looking at the other field and adapt. I don't think that's likely. >> Instead, if you have different agents, some of which want Received-SPF >> and some want Authentication-Results, then you essentially have two >> disjoint communication channels from the verifying agent to those >> internal agents. What's the benefit of demanding that they include >> the same message? > > Cleanliness of mind. If you have an undertone that you wish your > agent captures, you should extend the relevant field appropriately and > fill the new value when you find it. If that's a clever idea, it may > get standardized, eventually. That path seems highly unlikely to me. > Differentiating agent's behavior by target field will cause confusion > to agents beyond control, such as an IMAP client add-on. Home brewed > code based on such kludges will be difficult to share and evolve. I'm happy to discourage home brewed code based on kludges. -MSK From john@jlc.net Tue Aug 28 07:35: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 B375121F84F6 for ; Tue, 28 Aug 2012 07:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.865 X-Spam-Level: X-Spam-Status: No, score=-105.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgDYy042WYta for ; Tue, 28 Aug 2012 07:35:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43921F8494 for ; Tue, 28 Aug 2012 07:35:19 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B681D33C27; Tue, 28 Aug 2012 10:35:18 -0400 (EDT) Date: Tue, 28 Aug 2012 10:35:18 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120828143518.GJ72831@verdi> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 14:35:19 -0000 Murray S. Kucherawy wrote: >... > SPF is therefore an out-of-band message between the originating MTA > and the receiving MTA, Yes. (Can we say that clearly, please?) > which is what I mean when I say it's MTA-to-MTA. Unfortunately, that's not what the average reader takes MTA-to-MTA to mean. > What that means to me is that we should spend very little energy > talking about the communication between the receiver's MTA and agents > internal to the ADMD such as the MDA or MUA. That's what Section 7 is > about. Until we clearly define SPF to belong at the receiving MTA, reading policy of the sender, it's hard to rule it out of scope... -- John Leslie From vesely@tana.it Tue Aug 28 10:41: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 B7CB721F8598 for ; Tue, 28 Aug 2012 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8NJcXXvxSP5 for ; Tue, 28 Aug 2012 10:41:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA321F8596 for ; Tue, 28 Aug 2012 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346175692; bh=OqFPyrFey6GJBeqCig15v3CuquO3bLxmuy91/0ARhBk=; l=1989; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OYIiRyHRn0q+A/ejENsEjLVfpFBKN5TzyF/HzEKMx1KFK+udeh+/1rEsxIraLAoIY 2QqkJO8iSQ2zVf846A7r8s6W0W+Q6riKhVZ7xHkMOWt3VQMhtD6wZK/3sMShW5Pruv 0Fq4VTh1djgQRJoTU+uzOQMozEpaRs60kfjG8t2o= Received: from [37.183.75.143] ([37.183.75.143]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 28 Aug 2012 19:41:31 +0200 id 00000000005DC039.00000000503D02CB.00005754 Message-ID: <503D02C8.5050600@tana.it> Date: Tue, 28 Aug 2012 19:41:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <503B8A4C.9030701@tana.it> <6.2.5.6.2.20120827102724.0a795ee8@resistor.net> <20120827192715.GF72831@verdi> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <503C1FC3.8000309@isdg.net> <503C90D6.6070509@tana.it> <503CA7AB.8000500@isdg.net> In-Reply-To: <503CA7AB.8000500@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 17:41:34 -0000 On Tue 28/Aug/2012 13:12:43 +0200 Hector Santos wrote: > Alessandro Vesely wrote: >> On Tue 28/Aug/2012 03:32:51 +0200 Hector Santos wrote: > >>> what SPF does with ALL policies [...] IME is already pretty >>> well defined, described for receivers to follow for many >>> years. >> >> I agree it's already defined, but certainly not "pretty well". > > ok, but what is broken about it, perhaps is what I am seeking? Maybe what you are seeking cannot be defined within SPF, but hinges on the (missing) definition of a receiver policy. > What problem are we seeing? What are trying to fix? If one refers to SPF receiver behavior, people can righteously point out that no such thing is defined. >> Specifying Accept+Mark possibilities is definitely out of scope for >> SPF in general, and for our current charter in particular. However, >> in view of that new tendency (or "market", if you prefer) it does make >> sense to produce a cleaned-up specification of SPF, getting rid of all >> the badly defined receiver behavior. > > Yes, but that's what I scratching my head about. What badly defined > receiver behavior? What specifically are we talking about and what is > bad about it? What issues is it causing that we need so much time > with it here? Are we just talking about uppercasing some keywords? That is because of the way our mind works. At times, one may be unable to solve a simple equation without using paper and pencil. At times, one may be unable to get a protocol on focus if the keywords are not used correctly. > I am just wondering if there anything wrong other than what we might > want to focus more on, like accept+mark. The spec is peppered with > receiver protocol instructions and except for issues already outlines > and worked on to fix here and there, I don't see anything particular > wrong with SPF as far as receiver behavior. SPF doesn't specify any receiver behavior, yet. Focusing ghost specs is difficult. From vesely@tana.it Tue Aug 28 10:41:54 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 4556121F8596 for ; Tue, 28 Aug 2012 10:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSWXfAn9TX3W for ; Tue, 28 Aug 2012 10:41:51 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BBECA21F8594 for ; Tue, 28 Aug 2012 10:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346175705; bh=/C4gnznFadco9LD7w5yWQ12orCCcZRstegjSU15j8kQ=; l=1319; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bv0hgU+uGGfB0D2+HfbgcnjypJySCCocJsJtTmtW/W47f4CLSZCUCRmxIEROmlxBE Q4zlf0LLM/46q/hV5K+6WZia7VdnDgGK/tJfZSHyOtYRDbkJdJ4GIC7NbFTz0mg7z7 oJIE9P83j41QzObQrvE4njN8vTCEl+LTo9/Ykslg= Received: from [37.183.75.143] ([37.183.75.143]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 28 Aug 2012 19:41:43 +0200 id 00000000005DC039.00000000503D02D8.00005770 Message-ID: <503D02D3.1000504@tana.it> Date: Tue, 28 Aug 2012 19:41:39 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 17:41:54 -0000 On Tue 28/Aug/2012 15:52:02 +0200 Murray S. Kucherawy wrote: > On Tue, Aug 28, 2012 at 1:51 AM, Alessandro Vesely wrote: > >>> [I]f you have different agents, some of which want >>> Received-SPF and some want Authentication-Results, then you >>> essentially have two disjoint communication channels from the >>> verifying agent to those internal agents. What's the benefit >>> of demanding that they include the same message? >> >> Cleanliness of mind. If you have an undertone that you wish >> your agent captures, you should extend the relevant field >> appropriately and fill the new value when you find it. If that's >> a clever idea, it may get standardized, eventually. > > That path seems highly unlikely to me. Both Received-SPF and the spf's resinfo of Authentication-Results are extensible. However unlikely may be the need for additional info, that's the right track for conveying it. >> Differentiating agent's behavior by target field will cause confusion >> to agents beyond control, such as an IMAP client add-on. Home brewed >> code based on such kludges will be difficult to share and evolve. > > I'm happy to discourage home brewed code based on kludges. If you know of a sauce better than MUSTard to keep that on the right track, I'd be happy with it. From hsantos@isdg.net Tue Aug 28 10:46: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 197F221F85F3 for ; Tue, 28 Aug 2012 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7gh-AqIcPhr for ; Tue, 28 Aug 2012 10:46:12 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD08A21F85AC for ; Tue, 28 Aug 2012 10:46:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5251; t=1346175968; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=giciwq2hRNYANYpixpKFo8mZMII=; b=BPZa5Yw4HkOskovmMv8v ZAbzmJTBalBl6arxJzdYtJu8x/gyWbsQc3Tdds0ELblw7U2se4DN6dLW8VXw4A1G rxncwx0mhuHPWZWfiCpt1H1DlnpMeIXFs5Q7C6HrPgLAmLH2DieaYV9VNxQlgWTx 2lWzCx0tuVkTsCMX3Sqz4/0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 13:46:08 -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 2197758927.6189.3952; Tue, 28 Aug 2012 13:46:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5251; t=1346175767; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=L+4Mxlt 3oYzvU5MeffzfJpL5U2ic5/Sujc+jRS/VaZc=; b=EmcJwkhiP7lyh/nT9ZzrwKJ NlsWDdhoVXhjrHoQkGTxnhwPr2pAvgPFcQ7G3jwUoeOGuJKf0qdevoPX7xYnVyo9 PbSLn0caADzJBqJTGsOr+kounj1AczBJXPNJorvDHR+GiT20B5tAKdOpovhwCt3O Bv7Em6VUIp/4wmV0lduM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 28 Aug 2012 13:42:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2796565677.9.3188; Tue, 28 Aug 2012 13:42:46 -0400 Message-ID: <503D03FE.5010507@isdg.net> Date: Tue, 28 Aug 2012 13:46:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Aug 2012 17:46:13 -0000 An SMTP code can have multiple roles, MTA, MDA and MSA and not to go overboard and for the sake of simplicity a good way to see it is: MTA - generic transporter, router, sender/receiver, client/server, etc. In general and traditionally, little to no overhead and all "intelligent processing" was done post acceptance - Store and forward. MDA - receiver with no authorization requirement (no open relay) and only for local user or locally hosted domains. MSA - receiver with authorization requirement. In older established systems, where the MTA did not have dynamic state machine processing, shims, hooks, i.e. ACLs, milters, WCX scripts for us, etc, the MDA was generally a gateway, mail importer/exporter, transformer, even uucp/slip processor, etc. This is where the email to user account existence check was done and this is where the bounce was also created (hence accept+bounce problems). But in modern systems, the MTA with user checking (delivery and user account checking), and state machine hook processing, it now behaves more like an MDA when there is no authentication for relaying. If there was authentication established, the user/sender account was checked etc, then its mode is behaving more like an MSA. Of course, there are still large scale systems that still keep these roles separated yet, increasingly to improve TCO, they are scaling up with lesser machines, more multi-cores machine and upgrading and updating the software so that a MTA can play more than one role. With RFC5598, the one noted objection I had with it during the development was its locked down on using SIEVE and at the time, and maybe still today, it only allowed for post SMTP processing. It could not be used as a inline SMTP state machine scripting tool to make dynamic decisions on the fly and this is where reality does include such modes with all the different SMTP software. It didn't support DNS lookups for example, to do the sort of SPF and/or other dynamic SMTP online checking. I believe RFC4408 has SPF as a SMTP level processor. If the target is a remote address, then we have a relay authentication requirement and SPF is not required. This would be the behavior of a MSA or MTA with relay authentication established. Hence, IMV, SPF is more of a MTA to MDA protocol because A) No authentication is required to deliver mail, b) No User Login is required, c) Only mail for local user or locally hosted domain is allowed. Thats the behavior of a MDA. -- HLS Murray S. Kucherawy wrote: > On Tue, Aug 28, 2012 at 1:51 AM, Alessandro Vesely wrote: >>>> The MUSTard serves just to convince consumers that they can look for >>>> the field they prefer, no need to compare them. >>> Is that an interoperability concern? >> If it is, it's about the communication to downstream message >> processors. Is that the sense that Hector means when he says >> MTA-to-MDA protocol? > > I'm going by RFC5598 definitions. I believe he means originator to > receiver, as different from relay-to-relay. MDA is a delivery agent, > i.e., the thing that actually writes to inboxes. I think it's false > to claim that the MDA is doing anything SPF-related at all, so if he > means that then I disagree. SPF is therefore an out-of-band message > between the originating MTA and the receiving MTA, which is what I > mean when I say it's MTA-to-MTA. > > What that means to me is that we should spend very little energy > talking about the communication between the receiver's MTA and agents > internal to the ADMD such as the MDA or MUA. That's what Section 7 is > about. > >>> I can't imagine a single agent that uses both and would be >>> confounded by the existence of both fields with differing >>> information. >> I don't want to imagine that. However, if it becomes customary that >> in certain cases those fields differ, agents that examine both in >> order to detect such cases seem plausible. > > That presumes the consumers of these fields will notice that they > could get "better" information by looking at the other field and > adapt. I don't think that's likely. > >>> Instead, if you have different agents, some of which want Received-SPF >>> and some want Authentication-Results, then you essentially have two >>> disjoint communication channels from the verifying agent to those >>> internal agents. What's the benefit of demanding that they include >>> the same message? >> Cleanliness of mind. If you have an undertone that you wish your >> agent captures, you should extend the relevant field appropriately and >> fill the new value when you find it. If that's a clever idea, it may >> get standardized, eventually. > > That path seems highly unlikely to me. > >> Differentiating agent's behavior by target field will cause confusion >> to agents beyond control, such as an IMAP client add-on. Home brewed >> code based on such kludges will be difficult to share and evolve. > > I'm happy to discourage home brewed code based on kludges. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Tue Aug 28 23:06:29 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 E5D1511E80D3 for ; Tue, 28 Aug 2012 23:06:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG6vxoS1V2P0 for ; Tue, 28 Aug 2012 23:06:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0811E80C5 for ; Tue, 28 Aug 2012 23:06:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEm002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220387; bh=znbL3BawVkqHKYQ4+O+8jKkNbojBBJkk+IBeXf/VAgM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=BXf04oLV3xYW5ws6cbQ54s3bCJnCaNtHnV5IE4xLYoF91Wyo8veOGBcVRml91q0ws UChnfgl+kXXvj1E1uAoLbTKUmRQtTTPYo7ceA7K/f3Y1oe6jDADS6a0lOVgdhwuGb/ 33G47qs9TH7oQox/HgH1gUZsS3EEErv+IGh429Xo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220387; i=@elandsys.com; bh=znbL3BawVkqHKYQ4+O+8jKkNbojBBJkk+IBeXf/VAgM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=3LC36AH196SrJrQScoRj3rqWXBTWKdCW+xkOpCq84udmm5KfyiIzf+VzTS7GYXndP Mn+It16zFs2tHekS8WHx7xa99JkjeY+roCiGOC60LbXqUgc3CCfyMcF6imPRLjOybn qybdNKOtAFr2v+gN4cjPNkzG/lkRiv2aOtBZ/ROM= Message-Id: <6.2.5.6.2.20120828214809.0a64d968@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 21:49:12 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.919053af35ecc7a81253ce96e81fe639@tools.ietf.org> References: <064.919053af35ecc7a81253ce96e81fe639@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #38: Deprecated X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 06:06:30 -0000 X-List-Received-Date: Wed, 29 Aug 2012 06:06:30 -0000 At 18:09 26-08-2012, spfbis issue tracker wrote: >#38: Deprecated > > Message from Arthur Thisell posted on 26 Aug 2012: > > * After further pondering, I would get rid of the Deprecated definition > (section 1.3.5.). The only thing that is deprecated is ptr:/%{p}, which > were only "discouraged" in RFC 4408. > > I can not ever see version 1 of SPF having such an incompatible change as > getting rid of ptr:/%{p}. SPF has a version number for a reason. If, > in a new WG, we want to change such things, we should go to version 3. > We can adopt SPF version 2's magic number format of spf3.0 instead of > v=spf3. We can keep spf 2's notation for different identities and its > positional modifiers. We can get rid of ptr:/%{p}. We can either get > rid of macros that have a local part, or greatly simplify/eliminate macros > all together. We can switch to using only type 99 SPF records. We can do > lots of things that can't be done to version 1 of SPF. > > Declaring something as deprecated in this I-D seems contrary to the WG > charter and contrary to version 1 of SPF. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html This issue is similar to Issue #27. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:06: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 0DA1011E8097 for ; Tue, 28 Aug 2012 23:06:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7wzOgoyapMA for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA8311E80DE for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEu002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220400; bh=CQZZewmKw36EO3dW4wJb5l9NeqAd1mvEIJq4sf+tO5g=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=hOQclUOfQa92or2ukSh1+k8SlpWc415FIZ3iOnBu97m/4Z8YLHh3R9FaqDA+2yYDu 3Z4LFVlrH/sVGJXC5nLqISRVB1gdWTl03wbeAYqbFIdj+ZLg6sjHa/kpk7P/+f/Os6 knh8NV29wTs4PRuoqkhxP8bCkLNnin+SMPrhe5aQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220400; i=@elandsys.com; bh=CQZZewmKw36EO3dW4wJb5l9NeqAd1mvEIJq4sf+tO5g=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=gwAWxF5JYazs38XOFIVY/eAk9n4lNuQ3m6axwoHBUjIDAnmVcv9uif9m9JYmk7EWr PYkm5L55Xmr+A0qcjJqyvSjvUyS6qs2mfB5+ZShcA/M1ifFOcPh38tTILhWBAkRc9v nWjGmy6KpOUoztQd+pHMWEh9S/TgSY4qU8VGkGdI= Message-Id: <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:37:58 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> References: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #45: Section 5.5 steps X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:06:44 -0000 At 18:24 26-08-2012, spfbis issue tracker wrote: >#45: Section 5.5 steps > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 5.5 (PTR), step 1 and step 2 are really the same step. In RFC > 4408, this was in paragraph form, where these were two sentences > describing a rDNS lookup. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Yes. As a quick comment, the "MUST NOT" does not seem to fit in Step 3. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:06: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 2B52811E80F1 for ; Tue, 28 Aug 2012 23:06:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqp3T46ILHc9 for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11411E80C5 for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEq002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220394; bh=fLFBf787VBjFQ8baAeH4uZ/H6V8TH06e2O0UDWlXdW4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=uW9ozc4b+NwOAE0iGcAK8WpdlzCOkETjYd9qa21a91KUuCH/198t1H4LuGyqLVDQF ehfb+U+mQ5pzq5nTKnkwGFO8LMwyJo5dk4XLMRS/9GgTzAJKNMNcNi2s1Z759kjXx0 NvbWYJFSAqrgweCaCS4qv62FWVVSvJsvh77J6BhA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220394; i=@elandsys.com; bh=fLFBf787VBjFQ8baAeH4uZ/H6V8TH06e2O0UDWlXdW4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Y5WZk+QJkQStJXkQ6R8+AQSeVHR6W9oOol9npkSbQsF8QHDvqFX75MYSE9NgRfifB CeSpmMlMBNYHEsVcAO7DjyU50MFJzagWirsKsmjw6yHEY9mJ/HidWbpNkBw6NxRwbG imJwk2NYuSlrzfui9vySXseXLmig/8eQpirMgoJk= Message-Id: <6.2.5.6.2.20120828220529.0a64d300@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:10:17 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.d2a8ebeffcd06a78e08bcdaf75b76d93@tools.ietf.org> References: <064.d2a8ebeffcd06a78e08bcdaf75b76d93@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #41: Multiple DNS errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:06:44 -0000 At 18:14 26-08-2012, spfbis issue tracker wrote: >#41: Multiple DNS errors > > Message posted by Arthur Thisell on 26 Aug 2012: > > In section 4.4, multiple DNS errors over a 24 hour period now can be > called a permerror. I'm pretty sure there are a couple of SPF > implementations that do this, but if not, this would probably violate the > WG charter. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html A RFC 2119 key word was added to Section 4.4. Andrew Sullivan commented about DNS error codes at http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:06: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 1DF7411E80EF for ; Tue, 28 Aug 2012 23:06:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjMLxygkMDeK for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8260711E80E6 for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEs002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220397; bh=9PDDT3sybfRtXj1BUrv4gwyxcTmIDvgfzznjixJCCqg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=i4SZRIezeZZ0nfn/0UGJ/vSooP9zZ6C8mAmhzrafGbrkcUo+aV4WTzETEHecL0kc1 /jE+8UDMIOceT92R5/qBl16Ah5OC/XC8nWA8jPbaI3BxawSDQKuLF0UrnoCdqIk/BO iJigBSNitPFWvntuisqSnP6Alom2TzwXuue1JWwU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220397; i=@elandsys.com; bh=9PDDT3sybfRtXj1BUrv4gwyxcTmIDvgfzznjixJCCqg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=beqMvmTwvjxPeExHip5HI7FnU13T2hO3+k6Hi3RVnP1cRJ8zSbV9b/znzucIRbemj yl8fJHf9sjVhsR6sY7XtqxSIfPklD3bI6Tv50e66AabpHqPtTR7oUV+6QqK8nshwkn /6/abpvuZnn69pb4HxJ/joupxmuUmdtVDsJiDUow= Message-Id: <6.2.5.6.2.20120828221039.0a64d448@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:15:32 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.5fc00ea993fbd4c485cd9fd7b0648ff1@tools.ietf.org> References: <064.5fc00ea993fbd4c485cd9fd7b0648ff1@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #42: Record Evaluation X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:06:44 -0000 At 18:15 26-08-2012, spfbis issue tracker wrote: >#42: Record Evaluation > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 4.6 Record Evaluation, the first sentence starts with "After > one SPF record has been selected,". I think this is left over from when > there was a record selection procedure for TXT/SPF records. I think > saying "The check_host() function parses and interprets the SPF record > to..." would be better. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html This is a side-effect of Issue #9. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:06: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 3C6C511E80C5 for ; Tue, 28 Aug 2012 23:06:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-LQAkkdeiGR for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17311E80D3 for ; Tue, 28 Aug 2012 23:06:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEo002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220391; bh=sr++Wfe49Y6sd54mIYnJEuBG6Tw/Npu5/unXvl9vAFo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=cmr/vfUiAVbvF7uaRVyXaEMoy6bjD9hY1IFk/bucDfncrceHf1VNzyWx5bvOBx1+o gLB0QF+AEElrwtynuDVanSYy001ACsr4/X/uMiQzRkcF4gcmKVpDVG7eU9H2LChS6i WjZ23RIC0IP0q88efDcCij5YV2gYBAIBpUk+2snI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220391; i=@elandsys.com; bh=sr++Wfe49Y6sd54mIYnJEuBG6Tw/Npu5/unXvl9vAFo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SpWw4o7xE+BOJ1aAP3+yUUtUbi6u3V7lntWwAJ3l45cXkBTHo98Mjh5Zue6/QWaq4 yGSKHq4ojQPMmb+8sjkzic6kCD+594BUZumPMX2qnY7GXQtGfNG1SnaqwBBM2lXnsH 2xFI7w7G6xqbNu9E3otn4YY5PhEfjsplZKdj6xxY= Message-Id: <6.2.5.6.2.20120828215517.0a64dab0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:02:12 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.4fbeccef7a423b1c90252c2a296770fb@tools.ietf.org> References: <064.4fbeccef7a423b1c90252c2a296770fb@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #40: Wildcard records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:06:44 -0000 At 18:13 26-08-2012, spfbis issue tracker wrote: >#40: Wildcard records > > Message from Arthur Thisell posted on 26 Aug 2012: > > In section 3.5 on wildcard records, the "not recommended" has been > capitalized. I think this changed the intent of RFC 4408, and instead it > should be changed to "discouraged" or some similar language. Actually, > the first sentence of that paragraph is kind of redundant with the second > sentence. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Three RFC 2119 key words were added to Section 3.5. Andrew Sullivan suggested an approach for DNS ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02309.html ). Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:30:02 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 CD49921F84D3 for ; Tue, 28 Aug 2012 23:30:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezDgUv3gQMQj for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35A21F84C4 for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FF0002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220406; bh=avdvZtBBXc6LIu9xRbDk+6oIp8aFjvV3s0r0QpwnNoY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=xbsPwx3HM5B+Vvspq94nnknIRbCrvVRXLqF0SFBOZD15VkM5ig+550SvSJYs5ab0/ 4EpA/+uyDHJbeWg4A3BOheafRIMA0+2SVps7FAOY1hvnh8ztF+8eDPeK7ED0oYQSz4 DGYnjfWAouKxMIspeil7n0CS5gY0WVebjKtNx2II= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220406; i=@elandsys.com; bh=avdvZtBBXc6LIu9xRbDk+6oIp8aFjvV3s0r0QpwnNoY=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=N7y9a/WCLi/7HBeymb5ButPEqmWPCCJRSu6GY6w8VbJwYGBx+ZvFMCrOr+48vQVEx sGovDEY0kXsGP99GDHi75n+smYwxpO0KAz2uiAYx/lzVl7KGCY0C/xOe9/VjO5w3m5 TdqPII9CbO+LvoT2E8PKYx/Z594qDRTxk1bSxI7s= Message-Id: <6.2.5.6.2.20120828224335.0a64cc98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:47:01 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.d45a5c69a133a41ee04010734a95efcc@tools.ietf.org> References: <064.d45a5c69a133a41ee04010734a95efcc@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 06:30:03 -0000 At 18:27 26-08-2012, spfbis issue tracker wrote: >#47: domain-spec > > Message posted by Arthur Thisell on 26 Aug 2012: > > Suggested text: > > bis-06: > The domain-spec is expanded as per Section 8. The resulting domain > name is used for a DNS A RR lookup. If any A record is returned, this > mechanism matches. The lookup type is A even when the connection type is > IPv6. > > new: > > The domain-spec is expanded as per Section 8. The resulting domain > name is used for a DNS A RR lookup (even when the connection type is > IPv6). If any A record is returned, this mechanism matches, otherwise the > mechanism doesn't match. > > or new: > > The domain-spec is expanded as per Section 8. The resulting domain > name is used for a DNS A RR lookup (even when the connection type is > IPv6). If any A record is returned, this mechanism matches. In all other > cases (no A records, DNS error, etc.), the mechanism doesn't match. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Please review the above text. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:30:02 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 DBFBD21F84D4 for ; Tue, 28 Aug 2012 23:30:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxNg4wWMzaGB for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EAF21F84CD for ; Tue, 28 Aug 2012 23:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FEw002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220403; bh=ArOXT67EV2LN8b4JS30aVwKuNX3Aa9nmqXjPHyan/X4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=iXcQQryTSu29hq4JwLczBJo+CXRQJIfoF96p5ZbP5ccP7Grf7C96k5inTtXbQ+ytV Q4vV3+kzmw2KJts3dDOxA79v3wmkHF15cfIyiHiwLGkOc2/wOMJRS80y2t7w1qi+Eh bvEgrDys00jxdpUrU+a4UY9+pqYyLnhi0isEFSSc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220403; i=@elandsys.com; bh=ArOXT67EV2LN8b4JS30aVwKuNX3Aa9nmqXjPHyan/X4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=0RFXR1+/wHSKNtpGoFLjppLuX4kC8gzvvsDTmMXGizY0RpEykvYAVTJ+GRxY0rGwe ZmMU0yo98QvzNtgaGOsm+VDmlvNMncFvi9pe3kAUhyikXcpnyS8ou57da8+mJMaxtK 9lwUhbBrQFzLaahboTSJMgir31hNM2CQycgmiBYU= Message-Id: <6.2.5.6.2.20120828223808.0a64cb50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:43:03 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.1a7db6a12f4ed104036231a688d9a12e@tools.ietf.org> References: <064.1a7db6a12f4ed104036231a688d9a12e@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #46: DNS reply in Section 5.7 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:30:03 -0000 At 18:25 26-08-2012, spfbis issue tracker wrote: >#46: DNS reply in Section 5.7 > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 5.7 (EXISTS), there news language saying "The query will either > return NXDOMAIN (no match), any valid answer (match), or an error." What > happenss on an error? I think this sentence is redundant and better > fixed by rewording text above it. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html I am adding a pointer to another DNS related discussion ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html ). Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:30:02 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 E7CFB21F84D7 for ; Tue, 28 Aug 2012 23:30:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6qfD-vy-IAi for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 658B821F84CF for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FF4002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220412; bh=nXsW/XxBaTD8Gf7QFJa+e9owCzuEqxwl5WdJSEYvJs4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ypF6+7HH2/5CC0+FdK/CqHC+fUdpYZXKCzSDjlOAvDuh2ivAj+t1hQx03UPuMH+xy krs/PuMAXvV8E7gnsmuTNe10ysY/O2y3q1hCk/DpPAjRyvwECxvcNhA+Fwwb4FjRTw 7wlRCoBQAJvGYAmhgEF8iAAggb5ZUWldF1AsgZ/E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220412; i=@elandsys.com; bh=nXsW/XxBaTD8Gf7QFJa+e9owCzuEqxwl5WdJSEYvJs4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=zShGTJ06T/6e0GnAU8ekO2Q+j1IH3a/DnKgOg3D5lkWuagMiZ4UZcQTQZfiCszMD2 LSGWD5CwLusDXSzkQMHAifx3KhpIGFTheyi0+G6Kfarr1DJGSTZNrT3TrijXM9eQ4/ VRHSSYiQZd0CuavVG+EQDz9gAVTgs6TuGb15jW/0= Message-Id: <6.2.5.6.2.20120828225739.09cf4508@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 23:00:45 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.92cae4f8f546fe214929d9bfc7eb9d5d@tools.ietf.org> References: <064.92cae4f8f546fe214929d9bfc7eb9d5d@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #37: spf classic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 06:30:03 -0000 At 18:07 26-08-2012, spfbis issue tracker wrote: >#37: spf classic > > Message from Arthur Thisell posted on 26 Aug 2012: > > * I would get rid of the mention of "spf classic". Enough time has > transpired that I suspect this causes more confusion than helping to > clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID SPF". > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Section 1.1 requires a clean-up. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:30: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 4018F21F84C4 for ; Tue, 28 Aug 2012 23:30:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-q4v4GjjSOW for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3621F84C8 for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FF2002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220409; bh=5y9F4BrNQMTilfvlevKFztf61Ov8lz1125UFo5mZCmU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jLu8dgW0v6S8Km5cjGuERFsd8O6w3SIysUQiwtlACldYRTxZn8FhAb4fvjqHlWwlI p/haGVg/dEZkvF0ChaO+KXLpcFDDbdploYLejHIh8FLpvpi3sdxzMSaxl8jK3oe22x 7LrksGpGDxSWypjwwK9k0H7Q3eM8ItUUtNYT7zQ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220409; i=@elandsys.com; bh=5y9F4BrNQMTilfvlevKFztf61Ov8lz1125UFo5mZCmU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=CCEhJ/ATvka4ok7/cQStQ6srBnPZsug8ptv7bxTC6cjmEq6eokktqneixFMVhSZqy Rgy/hXWEXiAUnyizgzrupax5GAEGhlAhBk4xNOp9geX7KWWM+tTMczz3lXvfTfsu6m OCeAeM1ZcrqCW39s7Q4qjv2L+UjlTGLH+XLShPoA= Message-Id: <6.2.5.6.2.20120828224800.0a64c778@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 22:49:48 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> References: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #48: Section 8.1 - macro defs X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 06:30:03 -0000 At 18:29 26-08-2012, spfbis issue tracker wrote: >#48: Section 8.1 - macro defs > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 8.1 (macro defs), there is a "Note: Care MUST be taken so that > ...". I think it should be clearer that it is the ADMD, not the SPF > verifier that needs to take care. That is, it should say "Note: The ADMD > needs to take care so that..." This wording also fixes what I think was > an incorrect changing of an english language meaning of "must" to a RFC > 2119 keyword. > > in section 8.1 (macro defs), there is a note that says "Note: Domains > SHOULD avoid using ...". Again, if RFC 4408 the "should" was lower case > and I don't think it was meant to be an RFC 2119 keyword. Maybe "Note: > ADMDs are discouraged from using ..."? > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Section 8.1 has not received adequate review. Regards, S. Moonesamy From sm@elandsys.com Tue Aug 28 23:30: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 5851821F84C8 for ; Tue, 28 Aug 2012 23:30:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDoDNWU+Xo1q for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 872C021F84D2 for ; Tue, 28 Aug 2012 23:30:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7T66FF6002873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 23:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346220415; bh=Nduon/Wum9m4sPy0aWhzGJAmKYmKMs+IFpeO6B/UEBk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wvPbZ/j03hCKH6rHEmw4q1+KmokXvXR8RtkUz2p1ljmUTABeBnFS88vVIfQbi9Ilb 9C6MiqwnIZrnaRoIWeW7Q3RWjT0/PArBYwpofcyj+Y1t1zAXgDNW8y7/ubxq0Uz4ps YfQ+u3yFYAyTmH1YeoMZ1ryckREasi8ksYyu0Llw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346220415; i=@elandsys.com; bh=Nduon/Wum9m4sPy0aWhzGJAmKYmKMs+IFpeO6B/UEBk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=MwpZrdxE49dZbts39AuZaweobBaGGc5lWI/WtznEVWJ3uHzl9bPNxmihAqZ8Qh0Kx 66uks0HeLVTdtvRfKGHv4v2iYBpRDnznPoe1hD+uaNzQj81nNly1SjmJ1HJ+ngp7OJ nTbkqdk6bDMe6VNR2JcNN2R1wU5tohztL1bM/4Ko= Message-Id: <6.2.5.6.2.20120828230229.09cf48e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Aug 2012 23:03:13 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.320b1674b2ffece17f1e2d29ef877d19@tools.ietf.org> References: <064.320b1674b2ffece17f1e2d29ef877d19@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #34: Throw a temperror - Section 5.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: Wed, 29 Aug 2012 06:30:03 -0000 At 17:59 26-08-2012, spfbis issue tracker wrote: >#34: Throw a temperror - Section 5.2 > > Message posted by Arthur Thisell on 22 Aug 2012: > > Second, in the table in section 5.2, it still says to "throw" a temperror. > I thought we were trying to get rid of that term. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html The term may be related to Perl exception handling. Regards, S. Moonesamy From vesely@tana.it Wed Aug 29 04:34:37 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 35AFD21F8653 for ; Wed, 29 Aug 2012 04:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvmVrZN7SIHg for ; Wed, 29 Aug 2012 04:34:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5C21F864A for ; Wed, 29 Aug 2012 04:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346240073; bh=CIdZ1PFTFnbZv8v0TdC0RW3Z8SfSXU2OeJEHDVoocsA=; l=837; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=d0vrTlC9pXI7Ze7pdmLgZiHRO0T/Rfqiz280yvl0jVcceNoXH+TmTJp1f9EzZx1Dy RhI1sxGC7XVvY7l44bQGINO+a1LsEck05mBEKQp20kXpgisa473MwaeF7lo2COpmUu gcRpZsoR0CS0iZLZgqoK0OP91wOz4oDNSXBhC4jk= Received: from [37.159.123.133] ([37.159.123.133]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 29 Aug 2012 13:34:31 +0200 id 00000000005DC039.00000000503DFE48.00004D83 Message-ID: <503DFE42.2060605@tana.it> Date: Wed, 29 Aug 2012 13:34:26 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.4fbeccef7a423b1c90252c2a296770fb@tools.ietf.org> <6.2.5.6.2.20120828215517.0a64dab0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120828215517.0a64dab0@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #40: Wildcard records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 11:34:37 -0000 On Wed 29/Aug/2012 07:02:12 +0200 S Moonesamy wrote: > At 18:13 26-08-2012, spfbis issue tracker wrote: >> #40: Wildcard records >> >> Message from Arthur Thisell posted on 26 Aug 2012: >> >> In section 3.5 on wildcard records, the "not recommended" has >> been capitalized. I think this changed the intent of RFC 4408, >> and instead it should be changed to "discouraged" or some similar >> language. Actually, the first sentence of that paragraph is kind >> of redundant with the second sentence. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > Three RFC 2119 key words were added to Section 3.5. Andrew Sullivan > suggested an approach for DNS ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02309.html ). The last reference, msg02309, is on #28: i18n for EAI compatibility. From vesely@tana.it Wed Aug 29 04:36: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 7E27721F865E for ; Wed, 29 Aug 2012 04:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfgVHGaNUQL2 for ; Wed, 29 Aug 2012 04:36:03 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1121F865D for ; Wed, 29 Aug 2012 04:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346240160; bh=Qd7Z43VEANkUS3cDQ31jiR7S6pYmaRArM6nOFuiqGT8=; l=1137; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=h/OzOYIT68GLzCA0SGPvrS34obfUt8kWfCLa66fqVUmTYuoH00Yj4nLiGbpWYloIh lTccTNKY620AEuyNUpgO0w8vexAlv5NlTtJuiRWrVZGRVRDH9lhQ4054PlP89VLqaI ZrgR3x3ulxfsJbw8bnqUpSnlNjjGH2/RTqMLW8YE= Received: from [37.159.123.133] ([37.159.123.133]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 29 Aug 2012 13:35:58 +0200 id 00000000005DC039.00000000503DFE9F.00004DF5 Message-ID: <503DFE98.9030003@tana.it> Date: Wed, 29 Aug 2012 13:35:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> In-Reply-To: <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #45: Section 5.5 steps X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 11:36:03 -0000 On Wed 29/Aug/2012 07:37:58 +0200 S Moonesamy wrote: > At 18:24 26-08-2012, spfbis issue tracker wrote: >> #45: Section 5.5 steps >> >> Message posted by Arthur Thisell on 26 Aug 2012: >> >> in section 5.5 (PTR), step 1 and step 2 are really the same step. >> In RFC 4408, this was in paragraph form, where these were two >> sentences describing a rDNS lookup. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > Yes. The pseudocode name could be mentioned in the step, e.g. as follows: 1. Perform a DNS reverse-mapping for by looking up PTR records either in "in-addr.arpa." if the address is an IPv4 one, or in "ip6.arpa." if it is an IPv6 address. (This results in the list of names code-named "sending-domain_names" below.) Or, comments in the pseudocode could refer to the step, e.g. like so: sending-domain_names := ptr_lookup(sending-host_IP); // step 1 > As a quick comment, the "MUST NOT" does not seem to fit in Step 3. Why not? Do you mean it is better to say "MUST truncate the list" in the previous step? For a nit, s/its IP address/its IP addresses/. From vesely@tana.it Wed Aug 29 04:46: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 BD4FB21F8672 for ; Wed, 29 Aug 2012 04:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TClIG0er2d-j for ; Wed, 29 Aug 2012 04:46:14 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5921F866E for ; Wed, 29 Aug 2012 04:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346240773; bh=pJhaeKqbu0hEsRh2nzl/v+VbMJWNZjOtmvcR87uiOEA=; l=1888; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=E23/iFLw9OSutPudoi0NLLEN1pBzOZXVPf7td03HSrvqpQmzjCqBmFghY5dVM2/Ef tK7fQlAcqysjBRRJgrrvnhHICHMD1xge7bUVQmTVXhbvMD5NfFSadsnX3nk84qHJPk TgzlbIDPOrZpV0xDkonEp378mwRZX46goec6VPLk= Received: from [37.159.123.133] ([37.159.123.133]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 29 Aug 2012 13:46:11 +0200 id 00000000005DC039.00000000503E0104.00005038 Message-ID: <503E00FE.6030004@tana.it> Date: Wed, 29 Aug 2012 13:46:06 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.d45a5c69a133a41ee04010734a95efcc@tools.ietf.org> <6.2.5.6.2.20120828224335.0a64cc98@elandnews.com> In-Reply-To: <6.2.5.6.2.20120828224335.0a64cc98@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 11:46:14 -0000 > At 18:27 26-08-2012, spfbis issue tracker wrote: >> #47: domain-spec >> >> Message posted by Arthur Thisell on 26 Aug 2012: >> >> Suggested text: >> >> bis-06: >> The domain-spec is expanded as per Section 8. The resulting domain >> name is used for a DNS A RR lookup. If any A record is returned, this >> mechanism matches. The lookup type is A even when the connection >> type is >> IPv6. >> >> new: >> >> The domain-spec is expanded as per Section 8. The resulting domain >> name is used for a DNS A RR lookup (even when the connection type is >> IPv6). If any A record is returned, this mechanism matches, >> otherwise the mechanism doesn't match. >> >> or new: >> >> The domain-spec is expanded as per Section 8. The resulting domain >> name is used for a DNS A RR lookup (even when the connection type is >> IPv6). If any A record is returned, this mechanism matches. In all >> other cases (no A records, DNS error, etc.), the mechanism doesn't match. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > Please review the above text. my take: Note that the queried type MUST be A: This mechanism doesn't work for sites returning TXT RRs, nor allows discrimination based on the returned value. Only the returned RCODE is meaningful for the result, NOERROR yields a match and NXDOMAIN a non-match. Other codes imply a DNS error and break the evaluation. BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html discusses SERVFAIL. Is that the only DNS case, besides timeout, that yields temperror? Should Section 2.5.6 mention it? The current I-D mentions SERVFAIL only in Appendix C, annotating the option to turn repeated SERVFAIL into permerror. Shouldn't such criterion be applicable to "exists" mechanisms as well? How about non-DNS errors, e.g. database unavailable and similar? From agthisell@yahoo.com Wed Aug 29 13:42: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 63C3311E80F5 for ; Wed, 29 Aug 2012 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAdvbuD8++QC for ; Wed, 29 Aug 2012 13:42:14 -0700 (PDT) Received: from nm17-vm1.bullet.mail.ne1.yahoo.com (nm17-vm1.bullet.mail.ne1.yahoo.com [98.138.91.34]) by ietfa.amsl.com (Postfix) with SMTP id 862B311E80F1 for ; Wed, 29 Aug 2012 13:42:14 -0700 (PDT) Received: from [98.138.90.51] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:42:09 -0000 Received: from [98.138.89.192] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:42:09 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 20:42:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 33689.19309.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 82389 invoked by uid 60001); 29 Aug 2012 20:42:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346272928; bh=paq1nwxzVOGgrtun7N5Yy+wYoMNYJ0nt78Dmw9G57vY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Qassq65adkpAb0Bf1dzKQEifWaDwRvTwtenari+rUk9iBkbx47OplmOlSpuu5cpHcTHV/zxrdX5g8aVpNNT7b3BqD5gwSVooxeeSxofqPx0ByRa0+9lTvYFdmOFKrIj81S+GY0OECE/cz5Silif3QjXh3cNZ6xv7SyAjGbCMDYo= 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=yyHxzbHSKdwQ57l0aUOR+XYnL9VKCcpqBEVLrS3aCgneE2gemFHErqz1HBxGnS6TPs+i0W4m4bflrQD7Jot70kUv6qSgf67j+I/59pcPGIfg8VO7CTB2/dPb+C3AKyC/bSUSCwQqeHt3i+KPazK9hmZy23DwvaJpjYGd7VyRF5s=; X-YMail-OSG: DM3BqkMVM1mTygnXTB647Lm9Rc2nGgDCKkpBJ1cNrSTmTaj ufrCKEK74V.nBJ8gruGGo3eL2F0YrhzVFM7ZSdBvgtOHVVjhIht1Ujph1p0w pjy0XZ42E.fFsneyPCvNkBL5BU9d3xTw3Cty5xkiGT8MfwN3jrj3luBxU95x Bn50L.opFYZT0PYc7zZUowLNWZOygePqxyUsrsSET.EwE9BhYqtuGix3NxXw CAMa9JczBvCjbDbhZS0B2FviTUiuuon5Qg_UAugyP35U0FNhZb5egYJ8uHuo xwmbAnLxAltK7Lcppn5F9D83O1.mOJ20edMTcZGYa2Phak9CaYnFnjHRsRNv p_DGft2RmATpJsE_ZEAkarQX2slVkPF5RzyGANw97N8rVRHtbSkp8BjCaATy jcvb8stPvMbkdUUzkbsEPghcQEFRwjQD.2s3.ChBSOJKlV.P_2WfapnbkEuU ePI7M9v.5.T16.T3.hHSnpEsmrCYwuTiqayYjsmvZkhIY6OMp6eQAGF6xOJE JRfeVd6iVKjLzF_PCTQeX5DvJHiVt4hAIoKbeQJXqIj3MwlleKFmHrC2uDq4 hqepUKacDWbJ9 Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Wed, 29 Aug 2012 13:42:08 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Wed, 29 Aug 2012 13:42:08 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:42:15 -0000 First off, when drafting RFC4408, we were scolded by the DNS folks not to use things like NXDOMAIN, SERVFAIL, etc. because those are labels for particular libraries/APIs, rather than from RFCs. Instead, we should use RCODE. I don't know if the opinion within the IETF has changed since then, I see IANA now has a registry with names for DNS RCODEs. I think we should be consistent, either use only RCODE numbers, or only use IANA names. >>> or new: >>> >>> The domain-spec is expanded as per Section 8. The resulting domain >>> name is used for a DNS A RR lookup (even when the connection type is >>> IPv6). If any A record is returned, this mechanism matches. In all >>> other cases (no A records, DNS error, etc.), the mechanism doesn't match. My mistake, DNS errors should be handled as per section 5's general description for DNS lookups. Saying "In all other cases" might imply overriding general description. The new text that was added to 4408bis is almost duplicate information, except where it is contradictory to previous text. This, of course, is one of the dangers of saying the same thing twice, you have to make sure both places say the same thing. >my take: > > Note that the queried type MUST be A: This mechanism doesn't work > for sites returning TXT RRs, nor allows discrimination based on the > returned value. Only the returned RCODE is meaningful for the > result, NOERROR yields a match and NXDOMAIN a non-match. Other > codes imply a DNS error and break the evaluation. This is wrong. >BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html >discusses SERVFAIL. Is that the only DNS case, besides timeout, that >yields temperror? Should Section 2.5.6 mention it? > >The current I-D mentions SERVFAIL only in Appendix C, annotating the >option to turn repeated SERVFAIL into permerror. Shouldn't such >criterion be applicable to "exists" mechanisms as well? > >How about non-DNS errors, e.g. database unavailable and similar? One of my there comments was section 2.5.6 (temperror) seemed to imply that only DNS errors could generate it. This is wrong, other local temporary errors can cause it also. Dababases being unavailable, out of memory, out of disk space, etc. can also use temperror. From sm@elandsys.com Wed Aug 29 13:53: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 0E12F21F85A7 for ; Wed, 29 Aug 2012 13:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.684 X-Spam-Level: X-Spam-Status: No, score=-101.684 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7OxoiytXwV3 for ; Wed, 29 Aug 2012 13:53: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 2D18821F85A2 for ; Wed, 29 Aug 2012 13:53:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7TKrRXd027587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 13:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346273618; bh=tmJoZ8KMePy/m5HTYF9bBo0oTR/KbGkVPUXagQAO0UI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=QH7e0dZoqJSqXZo8FAlEIA9sRDbBWB+coNliXp4tjIOgQxjh+Iora8WZQ5t0bi8tJ rw+kF7/4dCxwZYiEjEWU10+d3ianMLtvOUavs1Sa0061yMvjkoMQT6zyOFpmn0Jh8Z 4B+4oWk3sUYzvQ5vH9ENUF1s8ByijEHywl4trcVc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346273618; i=@elandsys.com; bh=tmJoZ8KMePy/m5HTYF9bBo0oTR/KbGkVPUXagQAO0UI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=nb+2cI31HJSkF9ycJr/xGsWj/tzJzeyuMTO+baWWmHzwO2rtrxIJvM5gBkAAFVJkv 4LSOkzPoooqKrnCuRVLvZpaK5mXTVGlG62T/ieWvABYlCTkbl94XZs9gfPduSP6yZJ B49bKT7vcjBHscXsjpjLPMTzfWiBEy0eHmvo09qM= Message-Id: <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 13:51:46 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <503D03FE.5010507@isdg.net> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> <503D03FE.5010507@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Aug 2012 20:53:41 -0000 Hello, Here are my individual comments. This is a RFC 2119 recommendation in Section 7 of RFC 4408 for SMTP receivers to record the result of SPF processing in the message header. There is a SHOULD in the second sentence of that paragraph. The two normative sentence could have been folded into one sentence to tighten the specification. The second paragraph mentions that the header field should be prepended but it must appear before all other Received-SPF fields in the message. The Security Considerations section (see 10.5) does not provided a thorough analysis of the security issues [1]. The comment and key-value-pair is optional in the ABNF. There is normative text which makes the comment a RFC 2119 recommendation. There is another RFC 2119 recommendation for SPF clients to give enough information so that the SPF results can be verified. I took a quick look to find out which header fields are generated: Google: Received-SPF: pass (example.net: domain of prvs=518e12a64=MAngelisi@example.com designates 165.155.105.213 as permitted sender) client-ip=165.155.105.213; Authentication-Results: example.net; spf=pass (google.com: domain of prvs=518e12a85=MAngelisi@example.com designates 165.155.105.213 as permitted sender) smtp.mail=prvs=518e12a64=MAngelisi@example.com Hotmail: Authentication-Results: example.net; sender-id=none (sender IP is 176.98.199.110) header.from=ddpevkjkjuwj@example.com; dkim=none header.d=example.com; x-hmca=none Yahoo: Received-SPF: none (domain of example.com does not designate permitted sender hosts) Authentication-Results:example.net from=example.com; domainkeys=fail (bad syntax); from=example.com; dkim=permerror (invalid domain) MDaemon: Authentication-Results: example.net spf=hardfail smtp.mail=customerservices_delivery@example.com; sender-id=hardfail header.from=customerservices_delivery@example.com; x-ip-ptr=pass dns.ptr=metamail.metapack.com (ip=193.129.71.18); x-ip-helo=pass smtp.helo=metamail.metapack.com (ip=193.129.71.18); x-ip-mail=hardfail smtp.mail=customerservices_delivery@sendingcompany.com (does not match 193.129.71.18) Received-SPF: fail (example.net: domain of customerservices_delivery@example.com does not designate 193.129.71.18 as permitted sender) spfmilter and Exim add Received-SPF headers. My reading of the above header fields is that they diverge from the specification. There is a message about Issue #10 at http://www.ietf.org/mail-archive/web/spfbis/current/msg00901.html I'll suggest a straw man proposal: (a) Add text to say that the result can be recorded in a Received-SPF: header field (b) Specify the Received-SPF: header field using the least common denominator (see examples above) (c) Add text as a security consideration pointing to RFC 5451 Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02386.html From hsantos@isdg.net Wed Aug 29 19:46: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 071CF11E8106 for ; Wed, 29 Aug 2012 19:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.901 X-Spam-Level: X-Spam-Status: No, score=-99.901 tagged_above=-999 required=5 tests=[AWL=-2.324, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8QXxczl9q-A for ; Wed, 29 Aug 2012 19:46:38 -0700 (PDT) Received: from ftp.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8711E8103 for ; Wed, 29 Aug 2012 19:46:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3989; t=1346294790; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PiXIhf9jfUMrTgD0sYOAhx/+JOU=; b=BX5WYhSgOAhQHavl6Qk+ /1INr+ZxV0gn8KAMmyPq+yO0dgmJR+bQsK498WCqg9H2fnIvmnqljsJcdnEaNQhX b8bOMPTJPYvnHYq2KJPwNmWXganG86l6/vcpB41+KQFV2t7IfuuvPuyKvbqDNkvD s3hmXLQUg6mZ9Ikz/S90kkg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 29 Aug 2012 22:46:30 -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 2316580130.7137.5532; Wed, 29 Aug 2012 22:46:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3989; t=1346294588; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UYA0un0 vRQqmxPpdIobl28eooAFzC3KQoEY7G5ag6iE=; b=uzcRnH7WZMSFYzi05TQN0Zs hhqgG/9bLQ2rx7nLO0ISwmgal8Qvr3BvLkWzgr4bhyKhFNqPgDhcoDiS4Ttx+jMq EAy/s33S9VhxNbq+ipBiD5rBehYHbe95U1avvhg+EJB1ofEx1gRqrS1Aj4i6xFr3 o+Uu9chRe6NJ90O9MWjw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 29 Aug 2012 22:43:08 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2915386786.9.2096; Wed, 29 Aug 2012 22:43:08 -0400 Message-ID: <503ED405.3000201@isdg.net> Date: Wed, 29 Aug 2012 22:46:29 -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: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> <503D03FE.5010507@isdg.net> <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> In-Reply-To: <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 02:46:40 -0000 1) 1st paragraph in section 7 should be consistent with 2.5.4 where there is a receiver rejection functionality describe in RFC2119 lingo and hence Recordings COULD NOT be possible as described in section 7. 2) The text in 2.5.4 and the 2nd paragraph 7.0 describe A-R as a exclusive replacement without any insight on compatibility issues. IMV, it should provide semantics for using Received-SPF first, A-R second as an migration feature. This of course will highly dependence on the implementation. It if uses in house canned software with no 3rd party support, then it has the luxury to use A-R only. But if the implementation can be used for systems with 3rd party support, it should continued to offer Received-SPF S Moonesamy wrote: > Hello, > > Here are my individual comments. > > This is a RFC 2119 recommendation in Section 7 of RFC 4408 for SMTP > receivers to record the result of SPF processing in the message header. > There is a SHOULD in the second sentence of that paragraph. The two > normative sentence could have been folded into one sentence to tighten > the specification. > The second paragraph mentions that the header field > should be prepended but it must appear before all other Received-SPF > fields in the message. The Security Considerations section (see 10.5) > does not provided a thorough analysis of the security issues [1]. > > The comment and key-value-pair is optional in the ABNF. There is > normative text which makes the comment a RFC 2119 recommendation. There > is another RFC 2119 recommendation for > SPF clients to give enough information so that the SPF results can be > verified. > > I took a quick look to find out which header fields are generated: > > Google: > > Received-SPF: pass (example.net: domain of > prvs=518e12a64=MAngelisi@example.com > designates 165.155.105.213 as permitted sender) > client-ip=165.155.105.213; > Authentication-Results: example.net; spf=pass (google.com: domain of > prvs=518e12a85=MAngelisi@example.com designates 165.155.105.213 as > permitted > sender) smtp.mail=prvs=518e12a64=MAngelisi@example.com > > Hotmail: > > Authentication-Results: example.net; sender-id=none (sender IP is > 176.98.199.110) header.from=ddpevkjkjuwj@example.com; dkim=none > header.d=example.com; x-hmca=none > > Yahoo: > > Received-SPF: none (domain of example.com does not designate permitted > sender > hosts) > Authentication-Results:example.net from=example.com; domainkeys=fail (bad > syntax); from=example.com; dkim=permerror (invalid domain) > > MDaemon: > > Authentication-Results: example.net spf=hardfail > smtp.mail=customerservices_delivery@example.com; sender-id=hardfail > header.from=customerservices_delivery@example.com; x-ip-ptr=pass > dns.ptr=metamail.metapack.com (ip=193.129.71.18); x-ip-helo=pass > smtp.helo=metamail.metapack.com (ip=193.129.71.18); x-ip-mail=hardfail > smtp.mail=customerservices_delivery@sendingcompany.com (does not match > 193.129.71.18) > Received-SPF: fail (example.net: domain of > customerservices_delivery@example.com > does not designate 193.129.71.18 as permitted sender) > > spfmilter and Exim add Received-SPF headers. > > My reading of the above header fields is that they diverge from the > specification. There is a message about Issue #10 at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00901.html I'll > suggest a straw man proposal: > > (a) Add text to say that the result can be recorded in a > Received-SPF: header field > > (b) Specify the Received-SPF: header field using the > least common denominator (see examples above) > > (c) Add text as a security consideration pointing to RFC 5451 > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02386.html > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Wed Aug 29 20:28: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 4A70821F8505 for ; Wed, 29 Aug 2012 20:28: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crVwTeFOwR5L for ; Wed, 29 Aug 2012 20:28:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A700321F84F8 for ; Wed, 29 Aug 2012 20:28:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2433220E414A; Wed, 29 Aug 2012 23:28:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346297298; bh=FCPhbio/kIAsqf0+t0bhrA4vMnk9XyUSwgaLVd7fTgQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TOA9FOQIt7XVV4Un243BJpy3PMdnLs0pIi3ChPm/l85jI86fMwGfQA9XTwna4zEYL 9RrcfmjYY0X+JuPr1GQlNFO5gJX2zRpuNCvybELA9UOtwQ/DbP5ua35y1qzahZ/TLR vDsyX7FCeorH58KBPUoeaxAWZMQ3Jflke5tbI/EU= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DC1F020E4129; Wed, 29 Aug 2012 23:28:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:28:15 -0400 Message-ID: <2332033.MFyoen0AEp@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> References: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> <6.2.5.6.2.20120828222048.0a64cf28@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] #45: Section 5.5 steps X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 03:28:19 -0000 On Tuesday, August 28, 2012 10:37:58 PM S Moonesamy wrote: > At 18:24 26-08-2012, spfbis issue tracker wrote: > >#45: Section 5.5 steps > > > > Message posted by Arthur Thisell on 26 Aug 2012: > > > > in section 5.5 (PTR), step 1 and step 2 are really the same step. In RFC > > 4408, this was in paragraph form, where these were two sentences > > describing a rDNS lookup. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > Yes. I recombined them locally for the next revision. > As a quick comment, the "MUST NOT" does not seem to fit in Step 3. Why not? All the processing limits are hard requirements. This is is treated just like the others. Scott K From spf2@kitterman.com Wed Aug 29 20:31: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 14E7011E810A for ; Wed, 29 Aug 2012 20:31: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9s8tIUxUVlY for ; Wed, 29 Aug 2012 20:31:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4111E8091 for ; Wed, 29 Aug 2012 20:31:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBC3620E414A; Wed, 29 Aug 2012 23:31:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346297496; bh=NXNlCS4BjW8mkF7UgJOQ94BScBikXo/J7dg/VgXK5Kk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SjMjwfTm3BQPlPpzw7wse2AgPH6VB04jQjkaQ1eCNTHTwT87NfCN+QwATvx8p5XjS /VN9Uz2bWFqG1vz447ooM+bOjZIkc7GZ/42mqjFM734RL7JjWIhL0tUogf1JuWMt9/ OBFboy73oNDKAIb7XveaAt/5UOXXe2JM0whlCj/g= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6C19720E4129; Wed, 29 Aug 2012 23:31:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:31:34 -0400 Message-ID: <2284659.he7dtYKGJL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828223808.0a64cb50@elandnews.com> References: <064.1a7db6a12f4ed104036231a688d9a12e@tools.ietf.org> <6.2.5.6.2.20120828223808.0a64cb50@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] #46: DNS reply in Section 5.7 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 03:31:38 -0000 On Tuesday, August 28, 2012 10:43:03 PM S Moonesamy wrote: > At 18:25 26-08-2012, spfbis issue tracker wrote: > >#46: DNS reply in Section 5.7 > > > > Message posted by Arthur Thisell on 26 Aug 2012: > > > > in section 5.7 (EXISTS), there news language saying "The query will > > either > > return NXDOMAIN (no match), any valid answer (match), or an error." What > > happenss on an error? I think this sentence is redundant and better > > fixed by rewording text above it. Please recommend text. This was added because it turns out at least one person thought match meant fail because the language describing exists compared it to a DNSBL and in DNSBLs a match is "bad", so it ought to be clarified somehow. To answer the specific question is it depends on the error. It'd be temperror/permerror depending on why it happened. Scott K From spf2@kitterman.com Wed Aug 29 20:38: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 4489811E8103 for ; Wed, 29 Aug 2012 20:38: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya7GQ-qYyQRr for ; Wed, 29 Aug 2012 20:38:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8DC11E8091 for ; Wed, 29 Aug 2012 20:38:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DAD0A20E414A; Wed, 29 Aug 2012 23:38:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346297902; bh=mPQw+fbPRByq9cvfXRpEzbbq8WLtgpF96fJCxOSylFE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MjRqlSDuWhlHjJnsHXiCzHoaQghWTNLW5/D/y+IM/IbQM7TRsLb+RV6hwJRJrqCFm GVPXN7n2KgE9t0xnebFV9P8vGaVhoq7hjFLzEFfCQkTxVyzJo/OmZKgU6BfhlSFkFg pqO1MemVygkq1ZvLY8TmKiqc23IU+DCEEXtIv/CE= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 654E520E4129; Wed, 29 Aug 2012 23:38:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:38:20 -0400 Message-ID: <1364070.EyWtgMjLQx@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828224335.0a64cc98@elandnews.com> References: <064.d45a5c69a133a41ee04010734a95efcc@tools.ietf.org> <6.2.5.6.2.20120828224335.0a64cc98@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] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 03:38:32 -0000 On Tuesday, August 28, 2012 10:47:01 PM S Moonesamy wrote: > At 18:27 26-08-2012, spfbis issue tracker wrote: > >#47: domain-spec > > > > Message posted by Arthur Thisell on 26 Aug 2012: > > > > Suggested text: > > > > bis-06: > > The domain-spec is expanded as per Section 8. The resulting domain > > name is used for a DNS A RR lookup. If any A record is returned, this > > mechanism matches. The lookup type is A even when the connection type is > > IPv6. > > > > new: > > The domain-spec is expanded as per Section 8. The resulting domain > > name is used for a DNS A RR lookup (even when the connection type is > > IPv6). If any A record is returned, this mechanism matches, otherwise the > > mechanism doesn't match. > > > > or new: > > The domain-spec is expanded as per Section 8. The resulting domain > > name is used for a DNS A RR lookup (even when the connection type is > > IPv6). If any A record is returned, this mechanism matches. In all other > > cases (no A records, DNS error, etc.), the mechanism doesn't match. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html I think both these proposals change the meaning of the requirements in this paragraph. Here's RFC 4408: The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup. If any A record is returned, this mechanism matches. The lookup type is A even when the connection type is IPv6. My understanding of the RFC 4408 design is that an error (temporary at the very least) could result from this lookup. The propose text states that errors are ignored as no match. I don't think there's been any foundational discussion for such a change in requirements and without a substantiating rationale we shouldn't change it. Scott K From spf2@kitterman.com Wed Aug 29 20:40: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 2DC3A11E810A for ; Wed, 29 Aug 2012 20:40: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPyorKeFQakk for ; Wed, 29 Aug 2012 20:40:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A5DAA11E8106 for ; Wed, 29 Aug 2012 20:40:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 280A920E414A; Wed, 29 Aug 2012 23:40:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346298031; bh=QGL+RLoZNVRYh7yYI5f7Vo3f2O6ZzsQVvtxzbWft5T0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p6+pfqTo085tsxiUIFfh3bo7EAZH6imp8UuJKT3Kj9KyrlJP0MJbVOjG91IJVknsQ 2IFcnxlZcn2it9s9b0ln75AO2Kb/iWuWbd7mNOISbcYyWlR8gpntZhEkdeNr0DpqkX yEeP4BjC+whkK2ugUrqdavoOf9mbJpi+f/LMCeLI= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EF52420E4129; Wed, 29 Aug 2012 23:40:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:39:04 -0400 Message-ID: <1515493.7ykjo06LiV@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828215517.0a64dab0@elandnews.com> References: <064.4fbeccef7a423b1c90252c2a296770fb@tools.ietf.org> <6.2.5.6.2.20120828215517.0a64dab0@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] #40: Wildcard records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 03:40:32 -0000 On Tuesday, August 28, 2012 10:02:12 PM S Moonesamy wrote: > At 18:13 26-08-2012, spfbis issue tracker wrote: > >#40: Wildcard records > > > > Message from Arthur Thisell posted on 26 Aug 2012: > > > > In section 3.5 on wildcard records, the "not recommended" has been > > capitalized. I think this changed the intent of RFC 4408, and instead it > > should be changed to "discouraged" or some similar language. Actually, > > the first sentence of that paragraph is kind of redundant with the second > > sentence. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > Three RFC 2119 key words were added to Section 3.5. Andrew Sullivan > suggested an approach for DNS ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02309.html ). > > Regards, > S. Moonesamy I agree with changing it to discouraged. I've changed it locally and combined the two sentences. Scott K From spf2@kitterman.com Wed Aug 29 20:47: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 1843B11E8106 for ; Wed, 29 Aug 2012 20:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4tZyO1m1bfD for ; Wed, 29 Aug 2012 20:47:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD2F11E8091 for ; Wed, 29 Aug 2012 20:47:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 763B220E414A; Wed, 29 Aug 2012 23:46:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346298419; bh=xjzap0Uc71J5u9WuXPel6yHCTkWn/4fmHlqLsiAVUFY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NnrbwFbhkuWU1xJmW1dThqHrDS7fPkZIhI7SJbsu8NqQ7uA9rcGepYhE6gHNyKev1 gYxDekre0tzQLS0S44jhCkQBGtNEvXFNouSkyNbTfwrpoIJsVxG+T0iP2fowhckqfp do1Oj4Zd+G8nYsDocDiWnjk9zg254jIB1G/UW3OE= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3BC6820E4129; Wed, 29 Aug 2012 23:46:58 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:46:58 -0400 Message-ID: <1428962.6IPKQEtNWL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828224800.0a64c778@elandnews.com> References: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> <6.2.5.6.2.20120828224800.0a64c778@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] #48: Section 8.1 - macro defs X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 03:47:01 -0000 On Tuesday, August 28, 2012 10:49:48 PM S Moonesamy wrote: > At 18:29 26-08-2012, spfbis issue tracker wrote: > >#48: Section 8.1 - macro defs > > > > Message posted by Arthur Thisell on 26 Aug 2012: > > > > in section 8.1 (macro defs), there is a "Note: Care MUST be taken so that > > ...". I think it should be clearer that it is the ADMD, not the SPF > > verifier that needs to take care. That is, it should say "Note: The ADMD > > needs to take care so that..." This wording also fixes what I think was > > an incorrect changing of an english language meaning of "must" to a RFC > > 2119 keyword. > > > > in section 8.1 (macro defs), there is a note that says "Note: Domains > > SHOULD avoid using ...". Again, if RFC 4408 the "should" was lower case > > and I don't think it was meant to be an RFC 2119 keyword. Maybe "Note: > > ADMDs are discouraged from using ..."? > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html I need to do a general review of the capitalization changes as I agree I was too liberal with adding them. This may not end up being one of those cases. Depending on how issue #22 gets resolved, label too long could explicitly be a permerror limit (some implementations treat it that way already - #22 is about resolving an ambiguity in 4408) and in that case, this limit would be a hard limit for records/macro construct development and the MUST would be appropriate. Given that we have to at least give a nod to the fact that this causes permerrors with some implementations, I think the least this should end up being is a SHOULD, but once we get #22 sorted we should consider it. I'd proposed adding this to #22 and closing this issue. > Section 8.1 has not received adequate review. Since you've recently stated on the list that you haven't reviewed the document yet, perhaps you could provide that. Scott K From spf2@kitterman.com Wed Aug 29 20:52: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 70C4711E8106 for ; Wed, 29 Aug 2012 20:52: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knce7cvgGYEm for ; Wed, 29 Aug 2012 20:52:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2911E8091 for ; Wed, 29 Aug 2012 20:52:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4B3F320E414A; Wed, 29 Aug 2012 23:52:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346298737; bh=iDEjcQWdkxbsMIS07YBA/L4UYjbNO33sFss94o5jkoc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MNNAnycX4WKrOBZ6K7DAqahEUhiFppxFgUVBpyKa9a7cGWLgR4Ksd4T/tGZdGf1En 6VGCzySmmJGheJIDICnx2UfzjOSJRE1DgRCXU4qfCjSyQIaA+D6b7k+x0EHNIWAv5g 6bNDdQTC3P4u6PIWfnw4jwtQ7ynfPLafi11jtg10= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 14CF620E4129; Wed, 29 Aug 2012 23:52:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:52:16 -0400 Message-ID: <23214846.35DP7DaIiD@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828225739.09cf4508@elandnews.com> References: <064.92cae4f8f546fe214929d9bfc7eb9d5d@tools.ietf.org> <6.2.5.6.2.20120828225739.09cf4508@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] #37: spf classic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 03:52:18 -0000 On Tuesday, August 28, 2012 11:00:45 PM S Moonesamy wrote: > At 18:07 26-08-2012, spfbis issue tracker wrote: > >#37: spf classic > > > > Message from Arthur Thisell posted on 26 Aug 2012: > > > > * I would get rid of the mention of "spf classic". Enough time has > > transpired that I suspect this causes more confusion than helping to > > clarify "Pre-MARID SPF" vs "MARID SPF" vs "Sender-ID" vs "Post-MARID > > SPF". > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html I cleaned it up a bit. > Section 1.1 requires a clean-up. Please review the next draft when it's published and provide recommendations if you believe additional changes are needed. Scott K From spf2@kitterman.com Wed Aug 29 20:54: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 AE61A11E80AE for ; Wed, 29 Aug 2012 20:54: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4sV7bK7Y3gY for ; Wed, 29 Aug 2012 20:54:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3A64C11E8091 for ; Wed, 29 Aug 2012 20:54:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ADE4820E414A; Wed, 29 Aug 2012 23:54:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346298866; bh=x0HrnhX0Mt1EhZn9R7EKnfISXGgA5P8t9Se5hVBhn54=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FoIrTWeELnDtI9Vc3KsKRV+S1RJni1HmJEQ4C/7fvNt2zromZcpsaDGWV+dueGvee j7LIvh5H5VShdmgfxI6HH31e2J7iPN1OVNM9Ui9LDLnmpACASvy/isFgzbG4pJTaoV laSICmUoWYMNLA3WjiCsS5c0GAe/0gaHaXCvvRSE= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7289A20E4129; Wed, 29 Aug 2012 23:54:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:54:25 -0400 Message-ID: <1350445.VvHizKSGqm@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120828230229.09cf48e0@elandnews.com> References: <064.320b1674b2ffece17f1e2d29ef877d19@tools.ietf.org> <6.2.5.6.2.20120828230229.09cf48e0@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] #34: Throw a temperror - Section 5.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: Thu, 30 Aug 2012 03:54:27 -0000 On Tuesday, August 28, 2012 11:03:13 PM S Moonesamy wrote: > At 17:59 26-08-2012, spfbis issue tracker wrote: > >#34: Throw a temperror - Section 5.2 > > > > Message posted by Arthur Thisell on 22 Aug 2012: > > > > Second, in the table in section 5.2, it still says to "throw" a > > temperror. > > I thought we were trying to get rid of that term. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html Fixed locally. I did a word search and found a few more instances that I also took care of. Scott K From spf2@kitterman.com Wed Aug 29 20:56: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 2FDDF11E80AE for ; Wed, 29 Aug 2012 20:56: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dcph+RX6-8y for ; Wed, 29 Aug 2012 20:56:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77911E8091 for ; Wed, 29 Aug 2012 20:56:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D2D9020E414A; Wed, 29 Aug 2012 23:56:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346298992; bh=uxhIF4TJthfjYZjHBWfcKBOzKzlMo8HkS5qH4kbJOZs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cRanPuBA232OJuJ7B89Yqh9Z6BjYkPQowCrHjwGeQIywmzpCdtKsjL6IQb21/KaoE nG8OfLkHTyRNlbZFdmqu6GAXBUSdrSr7lfWYMZ5LbpX+05sJw4PMswKtkWmlcGDJIc 2ksSp8lcSq/Br484lRzT3M9Woe9cv1YCX35kXPB8= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9CB5720E4129; Wed, 29 Aug 2012 23:56:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 Aug 2012 23:56:32 -0400 Message-ID: <10773190.NdrXzhepVJ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503DFE98.9030003@tana.it> References: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> <503DFE98.9030003@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] #45: Section 5.5 steps X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 03:56:40 -0000 On Wednesday, August 29, 2012 01:35:52 PM Alessandro Vesely wrote: > On Wed 29/Aug/2012 07:37:58 +0200 S Moonesamy wrote: > > At 18:24 26-08-2012, spfbis issue tracker wrote: > >> #45: Section 5.5 steps > >> > >> Message posted by Arthur Thisell on 26 Aug 2012: > >> in section 5.5 (PTR), step 1 and step 2 are really the same step. > >> In RFC 4408, this was in paragraph form, where these were two > >> sentences describing a rDNS lookup. > >> > >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > > > Yes. > > The pseudocode name could be mentioned in the step, e.g. as follows: > > 1. Perform a DNS reverse-mapping for by looking up PTR records > either in "in-addr.arpa." if the address is an IPv4 one, or in > "ip6.arpa." if it is an IPv6 address. (This results in the list > of names code-named "sending-domain_names" below.) > > Or, comments in the pseudocode could refer to the step, e.g. like so: > > sending-domain_names := ptr_lookup(sending-host_IP); // step 1 > > > As a quick comment, the "MUST NOT" does not seem to fit in Step 3. > > Why not? Do you mean it is better to say "MUST truncate the list" in > the previous step? > > For a nit, s/its IP address/its IP addresses/. Fixed the nit locally. thanks. Scott K From spf2@kitterman.com Wed Aug 29 21:04: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 37D8A11E80AE for ; Wed, 29 Aug 2012 21:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkhaXhKRQPmV for ; Wed, 29 Aug 2012 21:04:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4568811E810A for ; Wed, 29 Aug 2012 21:04:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0017620E414A; Thu, 30 Aug 2012 00:04:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346299458; bh=IDK9esZCkvMrZIHsNqgrI/14HxPsV17Clc+fB9c4jms=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cF0N7m5Hc8OhM8yVK2RM8vP7pvPuzAkWIj0vbfxiZJSps3VgbiaANOxl4KLc830s3 G1wRhja+bFTGKnmp0db9UnENW6lTL3cjmkBq+Z1U8wvpJCZToUfkry+0htSZQFKeH7 Hl8GWP1t5QD19NXaYCY/JxSvzyiRXrQlDeQ2RGbY= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A85D120E4129; Thu, 30 Aug 2012 00:04:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 30 Aug 2012 00:04:16 -0400 Message-ID: <2658221.Z4qI3DNV2S@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503E00FE.6030004@tana.it> References: <064.d45a5c69a133a41ee04010734a95efcc@tools.ietf.org> <6.2.5.6.2.20120828224335.0a64cc98@elandnews.com> <503E00FE.6030004@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] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 04:04:26 -0000 On Wednesday, August 29, 2012 01:46:06 PM Alessandro Vesely wrote: > > At 18:27 26-08-2012, spfbis issue tracker wrote: > >> #47: domain-spec > >> > >> Message posted by Arthur Thisell on 26 Aug 2012: > >> > >> Suggested text: > >> > >> bis-06: > >> The domain-spec is expanded as per Section 8. The resulting domain > >> > >> name is used for a DNS A RR lookup. If any A record is returned, this > >> mechanism matches. The lookup type is A even when the connection > >> > >> type is > >> > >> IPv6. > >> > >> new: > >> The domain-spec is expanded as per Section 8. The resulting domain > >> > >> name is used for a DNS A RR lookup (even when the connection type is > >> IPv6). If any A record is returned, this mechanism matches, > >> > >> otherwise the mechanism doesn't match. > >> > >> or new: > >> The domain-spec is expanded as per Section 8. The resulting domain > >> > >> name is used for a DNS A RR lookup (even when the connection type is > >> IPv6). If any A record is returned, this mechanism matches. In all > >> other cases (no A records, DNS error, etc.), the mechanism doesn't match. > >> > >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > > > Please review the above text. > > my take: > > Note that the queried type MUST be A: This mechanism doesn't work > for sites returning TXT RRs, nor allows discrimination based on the > returned value. Only the returned RCODE is meaningful for the > result, NOERROR yields a match and NXDOMAIN a non-match. Other > codes imply a DNS error and break the evaluation. > > BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html > discusses SERVFAIL. Is that the only DNS case, besides timeout, that > yields temperror? Should Section 2.5.6 mention it? This is addressed in the Record Lookup section. I don't think we should repeat it. > The current I-D mentions SERVFAIL only in Appendix C, annotating the > option to turn repeated SERVFAIL into permerror. Shouldn't such > criterion be applicable to "exists" mechanisms as well? Appendix C is not meant to be part of final 4408bis. It's for our use to track what we've done. I agree that exists should be subject to DNS errors causing a temperror. > How about non-DNS errors, e.g. database unavailable and similar? I don't think we've defined any non-DNS causes for temperrors. If your system is unable to do SPF processing because it's broken in some manner, then it can't produce an SPF result. It may choose to defer mail until it's fixed, but that's not part of the SPF protocol and I don't propose we add it now. Scott K From spf2@kitterman.com Wed Aug 29 21:13: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 C268D21F845B for ; Wed, 29 Aug 2012 21:13: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Blvqkpqmqo3 for ; Wed, 29 Aug 2012 21:13:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D87BC11E80AE for ; Wed, 29 Aug 2012 21:13:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5316520E414A; Thu, 30 Aug 2012 00:13:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346299986; bh=09xWN6FrZ599ZIuHZL0xB+Yus7MVi07K1UozRghbX50=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mnWr+Pk9vN1m8vdKI830ogMWD2yTfeE9CpHF+At51XGzmjdv4rl/V85yHUbPJucoE R0EJuebnng0Id9fhJezphzbWy8jryzAkgXvp1B4ktOQ8hYhLUMNNT4FjDw5BTGbVRx y9LF6J1ZzzGg/jOyRsO4LV9L6eIcScrq2fLdSfD8= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4AF8820E4129; Thu, 30 Aug 2012 00:13:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 30 Aug 2012 00:13:03 -0400 Message-ID: <5345259.50xTJaGO9G@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.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] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 04:13:07 -0000 On Wednesday, August 29, 2012 01:42:08 PM Arthur Thisell wrote: > First off, when drafting RFC4408, we were scolded by the DNS folks not to > use things like NXDOMAIN, SERVFAIL, etc. because those are labels for > particular libraries/APIs, rather than from RFCs. Instead, we should use > RCODE. I don't know if the opinion within the IETF has changed since then, > I see IANA now has a registry with names for DNS RCODEs. I think we should > be consistent, either use only RCODE numbers, or only use IANA names. > >>> or new: > >>> The domain-spec is expanded as per Section 8. The resulting domain > >>> > >>> name is used for a DNS A RR lookup (even when the connection type is > >>> IPv6). If any A record is returned, this mechanism matches. In all > >>> other cases (no A records, DNS error, etc.), the mechanism doesn't > >>> match. > > My mistake, DNS errors should be handled as per section 5's general > description for DNS lookups. Saying "In all other cases" might imply > overriding general description. > > The new text that was added to 4408bis is almost duplicate information, > except where it is contradictory to previous text. This, of course, is > one of the dangers of saying the same thing twice, you have to make sure > both places say the same thing. i may have lost track of this issue. What is the new text you're referring to here? > >my take: > > Note that the queried type MUST be A: This mechanism doesn't work > > for sites returning TXT RRs, nor allows discrimination based on the > > returned value. Only the returned RCODE is meaningful for the > > result, NOERROR yields a match and NXDOMAIN a non-match. Other > > codes imply a DNS error and break the evaluation. > > This is wrong. > > >BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html > >discusses SERVFAIL. Is that the only DNS case, besides timeout, that > >yields temperror? Should Section 2.5.6 mention it? > > > >The current I-D mentions SERVFAIL only in Appendix C, annotating the > >option to turn repeated SERVFAIL into permerror. Shouldn't such > >criterion be applicable to "exists" mechanisms as well? > > > >How about non-DNS errors, e.g. database unavailable and similar? > > One of my there comments was section 2.5.6 (temperror) seemed to imply that > only DNS errors could generate it. This is wrong, other local temporary > errors can cause it also. Dababases being unavailable, out of memory, out > of disk space, etc. can also use temperror. Every single reference to TempError in RFC 4408 is DNS related. The addition of the parenthetical (DNS) was meant to clarify this. I don't think that having every "my system is broken" condition return an SPF result of temperror is consistent with general usage or a good idea. For example, if you screw up postfix policy configuration and get into a non-working condition, postfix will reply is 451 System Configuration Issue (or similar, I'm doing that from memory) until it's fixed. If broken system is an SPF temperror, I can see all kinds of unrelated failures tagged as SPF failures. This has no benefit I can see and could certainly cause confusion. Scott K From spf2@kitterman.com Wed Aug 29 21:16: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 AE9EE11E8106 for ; Wed, 29 Aug 2012 21:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9cI1Bq4PkaH for ; Wed, 29 Aug 2012 21:16:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA821F845E for ; Wed, 29 Aug 2012 21:16:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 416EC20E414A; Thu, 30 Aug 2012 00:16:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346300204; bh=hUqWDL2yRLucC/vGkzGRnoTAEirKKITRYCXVp1YP/pM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jHaGrJBJrG2TRqM4yNgy7TrJeVyRdmGq/Lb3tarSTEwQwAhGXKdvYPcfsdp9zzqR7 QURbEbv1PelIPE/NDSsn+O8IFxtUCtPIdPa4aNdDF+ecZ8NGM1kUgf7rEiLLjyzTtx zFccj9oIS3kq6gCy2GemN7gqJtDIUTCBaCxwe4tc= Received: from scott-latitude-e6320.localnet (unknown [209.60.139.226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1037920E4129; Thu, 30 Aug 2012 00:16:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 30 Aug 2012 00:16:42 -0400 Message-ID: <4145261.ebQcLzVxW3@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <503D03FE.5010507@isdg.net> <6.2.5.6.2.20120829005310.09eeeca0@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] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 04:16:45 -0000 On Wednesday, August 29, 2012 01:51:46 PM S Moonesamy wrote: > Hello, > > Here are my individual comments. > > This is a RFC 2119 recommendation in Section 7 of RFC 4408 for SMTP > receivers to record the result of SPF processing in the message > header. There is a SHOULD in the second sentence of that > paragraph. The two normative sentence could have been folded into > one sentence to tighten the specification. The second paragraph > mentions that the header field should be prepended but it must appear > before all other Received-SPF fields in the message. The Security > Considerations section (see 10.5) does not provided a thorough > analysis of the security issues [1]. > > The comment and key-value-pair is optional in the ABNF. There is > normative text which makes the comment a RFC 2119 > recommendation. There is another RFC 2119 recommendation for > SPF clients to give enough information so that the SPF results can be > verified. It's my recollection that msk had already volunteered to provide a proposed revision to this section, so I think further work on deciding it needs to be revised has limited utility. > I took a quick look to find out which header fields are generated: > > Google: > > Received-SPF: pass (example.net: domain of > prvs=518e12a64=MAngelisi@example.com designates 165.155.105.213 as > permitted sender) client-ip=165.155.105.213; Authentication-Results: > example.net; spf=pass (google.com: domain of > prvs=518e12a85=MAngelisi@example.com designates 165.155.105.213 as > permitted sender) smtp.mail=prvs=518e12a64=MAngelisi@example.com > > Hotmail: > > Authentication-Results: example.net; sender-id=none (sender IP is > 176.98.199.110) header.from=ddpevkjkjuwj@example.com; dkim=none > header.d=example.com; x-hmca=none > > Yahoo: > > Received-SPF: none (domain of example.com does not designate permitted > sender hosts) > Authentication-Results:example.net from=example.com; domainkeys=fail (bad > syntax); from=example.com; dkim=permerror (invalid domain) > > MDaemon: > > Authentication-Results: example.net spf=hardfail > smtp.mail=customerservices_delivery@example.com; sender-id=hardfail > header.from=customerservices_delivery@example.com; x-ip-ptr=pass > dns.ptr=metamail.metapack.com (ip=193.129.71.18); x-ip-helo=pass > smtp.helo=metamail.metapack.com (ip=193.129.71.18); x-ip-mail=hardfail > smtp.mail=customerservices_delivery@sendingcompany.com (does not match > 193.129.71.18) > Received-SPF: fail (example.net: domain of > customerservices_delivery@example.com > does not designate 193.129.71.18 as permitted sender) > > spfmilter and Exim add Received-SPF headers. This is great data. > My reading of the above header fields is that they diverge from the > specification. There is a message about Issue #10 at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00901.html > I'll suggest a straw man proposal: > > (a) Add text to say that the result can be recorded in a > Received-SPF: header field > > (b) Specify the Received-SPF: header field using the > least common denominator (see examples above) > > (c) Add text as a security consideration pointing to RFC 5451 The decision to use Received-SPF or RFC 5451 A-R header fields has nothing to do with security, so I find this recommendation difficult to understand. Please clarify. Scott K From ajs@anvilwalrusden.com Wed Aug 29 22:50:02 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 CFC1C11E810A for ; Wed, 29 Aug 2012 22:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0f09-yulp4f for ; Wed, 29 Aug 2012 22:50:02 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DA1E311E8105 for ; Wed, 29 Aug 2012 22:50:01 -0700 (PDT) Received: from mx1.yitter.info (unknown [205.201.170.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 354C18A031 for ; Thu, 30 Aug 2012 05:50:00 +0000 (UTC) Date: Thu, 30 Aug 2012 01:49:58 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120830054957.GB59367@mx1.yitter.info> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 05:50:02 -0000 No hat. On Wed, Aug 29, 2012 at 01:42:08PM -0700, Arthur Thisell wrote: > First off, when drafting RFC4408, we were scolded by the DNS folks not to use things like NXDOMAIN, SERVFAIL, etc. because those are labels for particular libraries/APIs, rather than from RFCs. Instead, we should use RCODE. I don't know if the opinion within the IETF has changed since then, I see IANA now has a registry with names for DNS RCODEs. I think we should be consistent, either use only RCODE numbers, or only use IANA names. > Error codes _always_ had names. My personal preference has always been to include the RCODE and, on first use, the symbolic name as well. I'm also happy if people use the symbolic name, with the RCODE on first use. But I think both need to be in the document at first use, no matter what. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Wed Aug 29 23:07: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 A2C7711E8106 for ; Wed, 29 Aug 2012 23:07:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv4y3OEGnnNV for ; Wed, 29 Aug 2012 23:07: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 D79C811E80AE for ; Wed, 29 Aug 2012 23:07:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U66sx0005732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 23:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346306830; bh=Qb3W001NQ5s4+lm7RC6vyJn19n3bdVW0SUCi66GhRjs=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jUg8/lRIVsuC8GybxZQC2ugEdS2uSRUKrLsiikg+iyAQZcQqMBYq/Y92oe9liL0bC lLMS71a3RYis2mjvNMJiFQV7M6lx0YaTCF0vZ9qe1a3LRXWQpkZF7vyXTN+TWD6D1E hdFwoXjJ2eV4ecwFuR0MGJe++LVIOyrA7DUaRFa8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346306830; i=@elandsys.com; bh=Qb3W001NQ5s4+lm7RC6vyJn19n3bdVW0SUCi66GhRjs=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=D9LAFEbwFI4Fr7vxBcDH7jXz4Q8Ga9WuaJtmTdrBB9C75gYOFVq2FDwlTCde76Ayq LDohPQd4/8ZSxwmipEiLnbsAsG3COYFK7St2aKgsyQpGYPuGAl7IlCxNHvr3/O/S9B plU6ynbaVYFa2M2IJGLxVPJePBEc6eWEkwgyT3+4= Message-Id: <6.2.5.6.2.20120829220559.0a841f50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 22:12:26 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <2332033.MFyoen0AEp@scott-latitude-e6320> References: <064.f76cc7e479a49e24beae3d1ad28b71ed@tools.ietf.org> <6.2.5.6.2.20120828222048.0a64cf28@elandnews.com> <2332033.MFyoen0AEp@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #45: Section 5.5 steps X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:07:11 -0000 Hi Scott, At 20:28 29-08-2012, Scott Kitterman wrote: >Why not? All the processing limits are hard requirements. This is >is treated >just like the others. I read the steps again and realized that my comment was incorrect. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:07: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 B881D11E80AE for ; Wed, 29 Aug 2012 23:07:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCJPdFjhEt0I for ; Wed, 29 Aug 2012 23:07: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 9357F11E808A for ; Wed, 29 Aug 2012 23:07:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U66sww005732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 23:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346306826; bh=3bB/67ITtUfeC63zqyzyO43lv4/v/6uytwXoqsU+JMk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=s0tFoi/SpdNnv55irrG1mZZgQitAm6pycGAVZm6pvHrripwHeh0h/E0ra1UdLH57I smZz9GzkBfDsu2QISvlO0LPeOL+Bl3MDtXUaI6a70PayPZYo15BxJe2PpGTjVDmZjV 1vLdUolQ0Krg6fyq62DaDWWRvPkBldiH3T7hx2GU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346306826; i=@elandsys.com; bh=3bB/67ITtUfeC63zqyzyO43lv4/v/6uytwXoqsU+JMk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=hlKTq84E/mIU83ZK9NtAU9ztMBKGngYBCVG9hn4rrTZLV2SFy+UlBfF50JQ98JgG8 GuHqVYpSuanPiCeoHM4bFO8Y1JZU8KS4QDu8HVYeFjZCCqssNgBWkNrO05YGmEeKNz KFCccJvO1SjNRjEYWIRgci74PpcUcLno8dADd6cU= Message-Id: <6.2.5.6.2.20120829215317.0a841b78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 22:03:36 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <1428962.6IPKQEtNWL@scott-latitude-e6320> References: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> <6.2.5.6.2.20120828224800.0a64c778@elandnews.com> <1428962.6IPKQEtNWL@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #48: Section 8.1 - macro defs X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:07:11 -0000 Hi Scott, At 20:46 29-08-2012, Scott Kitterman wrote: >I need to do a general review of the capitalization changes as I agree I was >too liberal with adding them. This may not end up being one of those cases. You could get back to it for Issue #36. >Depending on how issue #22 gets resolved, label too long could >explicitly be a >permerror limit (some implementations treat it that way already - >#22 is about >resolving an ambiguity in 4408) and in that case, this limit would be a hard >limit for records/macro construct development and the MUST would be >appropriate. Given that we have to at least give a nod to the fact that this >causes permerrors with some implementations, I think the least this >should end >up being is a SHOULD, but once we get #22 sorted we should consider it. I'd >proposed adding this to #22 and closing this issue. There hasn't been any comments about Issue #22. Could WG participants please review the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02277.html and comment on that thread? >Since you've recently stated on the list that you haven't reviewed the >document yet, perhaps you could provide that. I will have to review the draft after the WGLC. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:07: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 1B8AF11E80D7 for ; Wed, 29 Aug 2012 23:07:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v28r5PRBIeDx for ; Wed, 29 Aug 2012 23:07: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 6CF2711E808A for ; Wed, 29 Aug 2012 23:07:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U66sx2005732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 23:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346306833; bh=VD18aCZF4uzD0vbS3AP0/T+AOOk3Vzb+xGHXPVpZP+A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wciySP5OESPmuA3vpP6kGFQ1X1J1Uvd9p3UjOICiq3vIsw+tECYkxz6agM1JDSzBH WjJQcnvYvu3xW215NAdBUahz7Nyr8u1Ly1IuQ8dDHAKVOHM6T9JHVHFEqbL1tyGKYV NxvC7fUJ311iV3HiOlGRVYzfL3QaIsm6W9IoGs0U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346306833; i=@elandsys.com; bh=VD18aCZF4uzD0vbS3AP0/T+AOOk3Vzb+xGHXPVpZP+A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=piz2SN1tJ5UiZud/YwUeI9aaQj3sqXm3pStLtn945evZRH5OTLLSBwaIQA/L2dx0a g4wYma3UlsryHaOx2wqiZnGIuldQGc5SKekF/xQiFs4+gHi/Z9Et9k+3qB+jk4mh5P pkRVpl6ooRaGgc8tHz3kL2MKACdoPoOblSHIGt0A= Message-Id: <6.2.5.6.2.20120829221451.0a8421e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 22:45:29 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <4145261.ebQcLzVxW3@scott-latitude-e6320> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <503D03FE.5010507@isdg.net> <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> <4145261.ebQcLzVxW3@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:07:15 -0000 Hi Scott, At 21:16 29-08-2012, Scott Kitterman wrote: >The decision to use Received-SPF or RFC 5451 A-R header fields has nothing to >do with security, so I find this recommendation difficult to >understand. Please >clarify. There are security considerations no matter which header field is used. There are issues such as header positioning and forged header fields. Murray Kucherawy pointed out that RFC4408 contained no protections against spoofed Received-SPF attacks. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:30: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 4887211E80BA for ; Wed, 29 Aug 2012 23:30:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCtPlGPVUACv for ; Wed, 29 Aug 2012 23:30:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6211E80AD for ; Wed, 29 Aug 2012 23:30:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U6UOAo023264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 23:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346308236; bh=ClE8JoAVOWNfNttBPrRGzh46KzC5/WutRDniZwJ38rI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Yh0ZtTvhcfnhLknF8OlsvD1wbh8j4dAgEM3zyFuuXRek5VqqYaP3eIfq7oLQ7KjRr 6bOvTeVuHK6dAuB22EjIP8x+8Dqwxak74rLwAyPr8S0RvJqqvKWdeUgFIyq96U0+mc tU/TOGi7b7Mh4nGhlu8WVC/WrAKLajgXnPJjf8cg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346308236; i=@elandsys.com; bh=ClE8JoAVOWNfNttBPrRGzh46KzC5/WutRDniZwJ38rI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ABjga9yUoJDhh4rgK455XuJNOB/ZnHqGHq8eHhWGVzv4tirtpyka+h8LUFLpdIxHT cZoiMFpvz5HE2oLrLnZ02RtnD7sS+4fpKOD0hV+jD+QfvYuAw3nLIBV7g+0PvvtFAg vzQpLLpKaTypIVn0z8DQ11B4aoAaFiOP0mBFC4qU= Message-Id: <6.2.5.6.2.20120829230741.0a3c3fc8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 23:09:09 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.c1eb79ecf12b16bd719f06e344736199@tools.ietf.org> References: <064.c1eb79ecf12b16bd719f06e344736199@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #35: authorized_spf domain name - Section 9.1.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:30:38 -0000 At 18:01 26-08-2012, spfbis issue tracker wrote: >#35: authorized_spf domain name - Section 9.1.1 > > Message posted by Arthur Thisell on 22 Aug 2012: > > Last, in section 9.1.1, an A record domain name "authorized_spf" is used, > which isn't a valid host name. I'm not sure if that was intentional or > not, but most real SPF records would use a real host name. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html The "authorized_spf" is not a valid. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:30: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 ED74711E810D for ; Wed, 29 Aug 2012 23:30:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR3drOCM1aC5 for ; Wed, 29 Aug 2012 23:30:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A29311E80A3 for ; Wed, 29 Aug 2012 23:30:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U6UOAq023264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 23:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346308240; bh=o8L1PCTPOIlFU+dsTkcYBNvqC2mjGQJ9uxCQeuXpaeA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sv6L7fCc1UvmtggkU07dV3QPFT2cznobk8HQl0pdgWzjJ0uD07zcoBuiLTZoY7+HB YjREoDcjJ6XfmioxtUmo7hkoh69vHzarIdmQ+F9RwUwUnKysnPfbtlJ4grjNc78qXL q+oBnJz/fTQg8iWNhFXM6JwmbOyhta7HL7Kvo+Wk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346308240; i=@elandsys.com; bh=o8L1PCTPOIlFU+dsTkcYBNvqC2mjGQJ9uxCQeuXpaeA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=s8vnUBKrKMwLomcPZnu9Oly6DJlm8b38+Mo7feeMuWZ6ezjLLzTbtjTjHQbtnQNUh /xD3cAtF0C3I3jTwA0hDV2jySyduNqrotPxnbnE9tFwz0c+JPifCtCu1SlRFXWnUvv nZcFaZvEe3SB+aktnxhdKFD8TvVaL6Ovie5QWVQs= Message-Id: <6.2.5.6.2.20120829230931.0a3c43a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 23:13:20 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.7bacdd0d9c7b5553b356aadbc6fe448b@tools.ietf.org> References: <064.7bacdd0d9c7b5553b356aadbc6fe448b@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #39: Temporary errors implied as only caused by DNS errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:30:42 -0000 At 18:11 26-08-2012, spfbis issue tracker wrote: >#39: Temporary errors implied as only caused by DNS errors > > Message from Arthur Thisell posted on 26 Aug 2012: > > * In section 2.5.6 on temperror, new language seems to imply that > temporary errors are only caused by DNS errors, but timeouts could be > caused by local problems unrelated to the DNS. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html RFC 4408 mentions transient error without going into details. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:30: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 4EA8111E80FA for ; Wed, 29 Aug 2012 23:30:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rDrS-U-jX9i for ; Wed, 29 Aug 2012 23:30:47 -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 4376511E8117 for ; Wed, 29 Aug 2012 23:30:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U6UOAs023264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 23:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346308243; bh=OTYqeFaBe3J67nHpRdo2X94JfM8EdrImETFoZifn7bI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=FNxCmEHELwH68B1NKpuIRzZc4CP06JdgkutB8hrb5N5DcSO0CRvjgUSrFRMnEGfug rDGLhP7nkqcNPRz2Fx8e8/JcklGzNHix/lubYcIr1uBkjXVOyTPgWXa9tFKg86UrZz /ZqsNRBC1Gt9sYCl/X1MJLTTNst6a+LizIQcHJ+4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346308243; i=@elandsys.com; bh=OTYqeFaBe3J67nHpRdo2X94JfM8EdrImETFoZifn7bI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=h5jLAPvdV/M++0RIpXCCK1laeEui+dpInoEylRZvquMgnq6Xi90Kx+vpZzZVUOqF+ 6i0afUoSwjkxKLTyuZOu2FZx+zIscTD1027X5Heu6KzITR0v2lwlBAIDKbbNbxc0jN j3f7s9tUGbFVPjwaR2X+D4W5feMESNkCI0FmmTaE= Message-Id: <6.2.5.6.2.20120829231332.0a3c4258@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 23:19:50 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.d1bab9aeb936b01c76e6fcdd6a048370@tools.ietf.org> References: <064.d1bab9aeb936b01c76e6fcdd6a048370@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #43: New requirement for mx: or ptr records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:30:48 -0000 At 18:17 26-08-2012, spfbis issue tracker wrote: >#43: New requirement for mx: or ptr records > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 4.6.4, there is a new requirement that there must not be more > than 10 records for mx: or ptr:. This completely wrong for ptr: because > a spammer could choose to send spam from a host with more than 10 PTR > records, thus forcing a domain's SPF record to return permerror, instead > of fail. If anything, more than 10 PTR records should cause the ptr: > mechanism to automatically not-match. It should also be made clear that > the %{p} macro is valid no matter how many PTR records are returned. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html One of the RFC 2119 requirements appears in different sections of the draft. It's better not to restate normative text as it can lead to different interpretations in case of ambiguity. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:30: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 6377911E810A for ; Wed, 29 Aug 2012 23:30:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPHykXzPK7Lw for ; Wed, 29 Aug 2012 23:30:47 -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 CF57F11E80A3 for ; Wed, 29 Aug 2012 23:30:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U6UOAu023264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 23:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346308246; bh=2xazsjOq/irNhjR9OxYjJ1sW+jJeZf4v2isRoTpFlvc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=FEhhGPps9hLLng4d5/BqJlPoy1va/wkVnkecvObpbcG/qfQwUtkYSrAH4fmrjNc+K XD1APoGGOvXIVW9BCksgjr7D2bWEIlHfRcEav23N2LWH/YI9FVYjR0frwXiDEAwQjb QqprIoqddcdUA0F9MzHkWb7B55zSSbd71yIALBKc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346308246; i=@elandsys.com; bh=2xazsjOq/irNhjR9OxYjJ1sW+jJeZf4v2isRoTpFlvc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qpG0RcP2/HIegLBJp2H0FIB0QU32WBcAl10jNRJHFvEJwiApC+ujXNz9OSChiUO4D cLVgOKF903eWepFLeiG4Vvw2UAUW4Gf5hezW5hsCFuCObtJfup1zAvAcYP0ZBgc6TE yeAB9HEua1hGMA+Y8wbTI6BtyEdNVREYyjzYRB+U= Message-Id: <6.2.5.6.2.20120829232016.0a3c4778@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 23:22:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.0f4f3f81bd864018584c277c99de0e98@tools.ietf.org> References: <064.0f4f3f81bd864018584c277c99de0e98@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #44: Section 5.4 does not mention requirement in section 4.6.4 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 06:30:48 -0000 At 18:23 26-08-2012, spfbis issue tracker wrote: >#44: Section 5.4 does not mention requirement in section 4.6.4 > > Message posted by Arthur Thisell on 26 Aug 2012: > > in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the new > requirement that there must not be more than 10 records that was added to > section 4.6.4 > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html My reading of the requirement in Section 5.5 is that it has to do with the number of DNS queries and not the number of DNS records. Regards, S. Moonesamy From sm@elandsys.com Wed Aug 29 23:30: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 F220511E810D for ; Wed, 29 Aug 2012 23:30:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wVAhZztxUYE for ; Wed, 29 Aug 2012 23:30:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4BE11E80AD for ; Wed, 29 Aug 2012 23:30:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7U6UOAw023264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 23:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346308250; bh=dDC1wH+6fjrO4J4u6AiG0O0f4QqMzEaTI+75eGhyHTA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=nVm6X0VsKRzloP+gdQw78T2CflQzvMLtGixOENJBIghi+VCmRRwTn03OvYK20PB5j B684QKLPOUrVM2EXi9vrC/g8fmokATsRUbFWdPZlocKKeV3Ro47HK6Y61lrnVx3yrp XJZzbootP0T8/TIzvrfF1Ip5KPB/UYhQYzHLYT8g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346308250; i=@elandsys.com; bh=dDC1wH+6fjrO4J4u6AiG0O0f4QqMzEaTI+75eGhyHTA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=lDcmGImV0MsBmlfX4eZs35fLXnl4+6vsoxS1dngdq219t7nU+0UVKO7I3lx0adqNN 1qEB/DQ5RAHxslU1+gOi63xYomvS0I1KMr+A2l3r714SNGd+jhD9UUV2gnWI9ZPDq/ 907ulNPDHOaf6WNfm7HUIAkOUWTtYOgBI241tyoA= Message-Id: <6.2.5.6.2.20120829232341.0a3c4a08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Aug 2012 23:30:05 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.12c3e269c68edcf155d31b2e19fc660a@tools.ietf.org> References: <064.12c3e269c68edcf155d31b2e19fc660a@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #36: RFC 2119 key words X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:30:52 -0000 At 18:05 26-08-2012, spfbis issue tracker wrote: >#36: RFC 2119 key words > > Message posted by Arthur Thisell on 26 Aug 2012: > > * Overall, when RFC 4408 was drafted, care was taken to capitalize RFC > 2119 keywords, and use the lower case words as regular English meaning. > While most of the lower case words have been changed to synonyms, a few > have been changed into RFC 2119 keywords. I think most (but sadly, not > all) of these capitalizations are wrong. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html Scott Kitterman already commented on this. On an unrelated note, I started a thread for each of the issues in the tracker. Regards, S. Moonesamy From hsantos@isdg.net Thu Aug 30 00:50: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 B303B21F85A2 for ; Thu, 30 Aug 2012 00:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SYSS4PvkTLZ for ; Thu, 30 Aug 2012 00:50:35 -0700 (PDT) Received: from catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6521F859E for ; Thu, 30 Aug 2012 00:50:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=985; t=1346313020; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lyXMqE7ObbZ3Gv058MxzSAr+MYw=; b=n5WktIqVG5Y20i1S5ST3 R+c0Cfy1DT/Rfa71/ih7wvLLTXFbBfxAIjIpIKy/YF5Jju44COPuo2xY1+OY8deR CsAWBzaU7lKMZ4DzsRv65BnnaAgzLz1wJ06z2Z/PBsAhH0F7HB5WwQVyBNuyFmsQ sOiPhaHIcnFVARiYI+w55cI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 03:50:20 -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 2334810485.8048.5592; Thu, 30 Aug 2012 03:50:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=985; t=1346312818; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=r4sjmHD druMs4uk4bXbpL5JgWxLRnRQV8FY+O5a5lPU=; b=qs5Xg3keSLEXYszuGeEMPGw BqXdgwNOrwx0OOnEnNIlZ9JcU8h+ouASmy57xoreX+tfrGNyP2Lb1bk3Y+alTyIg KNItYweRdj5JK6Th8gbq5UWMSGnwnORK3bziibeK3gBGd7oa68NYhVAxYcCR5TS8 bdpLwQuSlg6lzyC2oRa0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 03:46:58 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2933616895.9.4924; Thu, 30 Aug 2012 03:46:58 -0400 Message-ID: <503F1B57.7090805@isdg.net> Date: Thu, 30 Aug 2012 03:50:47 -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: <2038344.xmME5XhsPg@scott-latitude-e6320> <503D03FE.5010507@isdg.net> <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> <4145261.ebQcLzVxW3@scott-latitude-e6320> <6.2.5.6.2.20120829221451.0a8421e0@resistor.net> In-Reply-To: <6.2.5.6.2.20120829221451.0a8421e0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 07:50:35 -0000 S Moonesamy wrote: > Hi Scott, > At 21:16 29-08-2012, Scott Kitterman wrote: >> The decision to use Received-SPF or RFC 5451 A-R header fields has >> nothing to >> do with security, so I find this recommendation difficult to >> understand. Please >> clarify. > > There are security considerations no matter which header field is used. > There are issues such as header positioning and forged header fields. > Murray Kucherawy pointed out that RFC4408 contained no protections > against spoofed Received-SPF attacks. Don't follow this claim security claim. The only threat entry point I can see is some insertion between the MDA and MUA outside the ADMD network and thats pretty much means at the 3rd party MUA - offline, not online. The Receiver-SPF header is for local network consumption where the trust is located. It is not for offline MUA trust. Its the same thing applies for A-R or another other similar header. DKIM-Signature as well. -- HLS From agthisell@yahoo.com Thu Aug 30 04:00: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 A884C21F854F for ; Thu, 30 Aug 2012 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoS9R45LhtIF for ; Thu, 30 Aug 2012 04:00:33 -0700 (PDT) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) by ietfa.amsl.com (Postfix) with SMTP id 82EB721F8610 for ; Thu, 30 Aug 2012 04:00:33 -0700 (PDT) Received: from [98.138.90.51] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 11:00:30 -0000 Received: from [98.138.89.166] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 11:00:30 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 11:00:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 373507.61136.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 24972 invoked by uid 60001); 30 Aug 2012 11:00:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346324430; bh=v1MzKx1MNdbb05PKxjB4A0Yg3k2WElEQGaTDAQbtOTA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=lnzO265/Gu19xRmDltfRY320PiLLykteb5MtpZgZiN6EYDJuVCFB8NhMnc6G8T4lS322CcAcFa5VcZiXlD6WD7YDC8gC1lKIqDybHALatnPnKR9VK8fYcXXzH+awwBzuDJ+lbPRJ1+NJ9bSo04VPJFQ4kIwXzEXqNQcGzgOwkZA= 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=d6yFdidqx80RmNscaqxqJtH3MLz06UFtieKjmE8wgYD5Fs99rsSi76kS/l1APf6EZ7x28+ES0gtkYu/J4qXx641DjDAztSapjm74uP8NN2fFtNGmtFhIqyKrRfA74Hb2QN3exS0+Xp0PyZtEYUqBGxRNl5dbNqImsG9jYwLfKug=; X-YMail-OSG: KtANWgUVM1kFbW9Kfptp6TSFAmea0ct2ZdizcjFNBZdV3St TSC.cyAyoFmtCKneveuJqD0Ybt.YOuxUYpGXEkuFIrQu1LoiSy0RSQidc_Pw jjCLUSDmPTsJt_Pe4YuuSv6j1v01rvFQEmLdtE8uM5BMW74qQeIMyjS32ABB z5_UPaYVc4VTk1USS3bC3vAR2QUef_7hU0sp1fUVbzB1BBoKyj0J8K_sIK6. wjX5jp9aFOe15Oc9HQi03mZ.Whd2JPlSa7zDBgxe.yrkiCvtu4hPD5SC34dM HwvaftJk.9EbrEtUrph6jxyQRQcdq2HxcPBvR.v1w58MVIfSPsXUUBHNAs6T FWV8LUCaiTAWQYkFQcHnvbELmG4Gpda65X_9cnOEEg3hwnXsImN0vqfeWFjt MSv9FSysQOJFchrG6ePhvGHIty2Hu1oksaqHRkryKRTUyRDKy9UXDlABU3Gj oL5Mlnlz1Gl5F5uc2ods- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 04:00:30 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346324430.24241.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 04:00:30 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 11:00:34 -0000 > Murray Kucherawy pointed out that RFC4408 contained no protections against spoofed Received-SPF attacks. RFC 4408 says: The Received-SPF header field is a trace field (see [RFC2822] Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. This text is still in 4408bis. RFC 5322 makes no mentioned about forged received headers, nor does it say anything in its security section. Why would RFC 4408 need to say anything more? From vesely@tana.it Thu Aug 30 04: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 5AD3321F8616 for ; Thu, 30 Aug 2012 04:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n25tdtM3Ygx for ; Thu, 30 Aug 2012 04:01:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF5621F860E for ; Thu, 30 Aug 2012 04:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346324471; bh=kSXuzMyoog2rRKFJb92pKlGWsag4J49/ymwFTOdwjdo=; l=990; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=K/WrFE9fcUBZVvypbsm/ybzUVbz41kqMJCcLPTeyQq3CRmBMyevlKmbVZwKVP/ppj Gpb4DhJvfLnxTKzTMiW2FrYwiE8Zk9eut42U2k8jSyoXxG95p4AAGyFQ9s0pb5RlUz ns5zzH+hSlWB9sLTbkcvGIBWmghbKaLnNh3Of8sE= Received: from [109.115.133.131] ([109.115.133.131]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 13:01:09 +0200 id 00000000005DC039.00000000503F47F6.00000C68 Message-ID: <503F47ED.8020109@tana.it> Date: Thu, 30 Aug 2012 13:01:01 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.c1eb79ecf12b16bd719f06e344736199@tools.ietf.org> <6.2.5.6.2.20120829230741.0a3c3fc8@elandnews.com> In-Reply-To: <6.2.5.6.2.20120829230741.0a3c3fc8@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #35: authorized_spf domain name - Section 9.1.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 11:01:14 -0000 On Thu 30/Aug/2012 08:09:09 +0200 S Moonesamy wrote: > At 18:01 26-08-2012, spfbis issue tracker wrote: >> #35: authorized_spf domain name - Section 9.1.1 >> >> Message posted by Arthur Thisell on 22 Aug 2012: >> >> Last, in section 9.1.1, an A record domain name "authorized_spf" >> is used, which isn't a valid host name. I'm not sure if that >> was intentional or not, but most real SPF records would use a >> real host name. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html > > The "authorized_spf" is not a valid. That's not an LDH name. In the example, that label is used to demonstrate an SPF trick, and breaking host names' preferred syntax is a way to hint that it is not a label that already existed for some other reason. In real life, zone file writers can use non-LDH labels to avoid cluttering their host name space. If the above sounds nasty, or requires too much discussion, conversion to LDH is straightforward and harmless. From vesely@tana.it Thu Aug 30 04:03: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 DC3C721F852C for ; Thu, 30 Aug 2012 04:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXUfunOEhzNr for ; Thu, 30 Aug 2012 04:03:21 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D422821F84D9 for ; Thu, 30 Aug 2012 04:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346324599; bh=cLVBbeWtqsbxWy066OiBHPd3aDgpt5XmRMQA4nwJdhQ=; l=1981; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JXdfWuQ2mPzyB4tMgBhM/edK6KL7l1WIKPHZ8q2Lw/0MIBztkL64sqP9q3g7vwmxK sozsCtx58S4bBNfSmQwjXNeb+2CV2EuV4O190fyD4alI+vu1jWWXxoCKh/JrYL/XgN FYT14edJncaBFCNsjqBCLg3qmhLhUaAn8MfywLfI= Received: from [109.115.133.131] ([109.115.133.131]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 13:03:17 +0200 id 00000000005DC039.00000000503F4876.00000CDB Message-ID: <503F486F.6060405@tana.it> Date: Thu, 30 Aug 2012 13:03:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5345259.50xTJaGO9G@scott-latitude-e6320> In-Reply-To: <5345259.50xTJaGO9G@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 11:03:26 -0000 On Thu 30/Aug/2012 06:13:03 +0200 Scott Kitterman wrote: > On Wednesday, August 29, 2012 01:42:08 PM Arthur Thisell wrote: >>> >>> How about non-DNS errors, e.g. database unavailable and similar? >> >> One of my there comments was section 2.5.6 (temperror) seemed to >> imply that only DNS errors could generate it. This is wrong, >> other local temporary errors can cause it also. Dababases being >> unavailable, out of memory, out of disk space, etc. can also use >> temperror. > > Every single reference to TempError in RFC 4408 is DNS related. > The addition of the parenthetical (DNS) was meant to clarify this. > I don't think that having every "my system is broken" condition > return an SPF result of temperror is consistent with general usage > or a good idea. For example, if you screw up postfix policy > configuration and get into a non-working condition, postfix will > reply is 451 System Configuration Issue (or similar, I'm doing that > from memory) until it's fixed. > > If broken system is an SPF temperror, I can see all kinds of > unrelated failures tagged as SPF failures. This has no benefit I > can see and could certainly cause confusion. I see your point. However, DNS timeout will always be dubious, as it can depend on an outage or misconfiguration at the verifier's, at the publisher's, or anywhere in between. I don't think an out-of-memory error can be caused by names longer than 63, but, in principle, I neither think we can limit local errors due to SPF to DNS timeouts exclusively. What is the reason to deny an SPF qualifier to a local error occurring during SPF verification? If the verifier replies 4xx, or crashes without replying, the SPF qualification doesn't matter. OTOH, if the server recovers from the error after the verification failed, it may be able and willing to accept the message at hand. I'd assume it writes its trace header field also in such cases. What SPF result should it report? From vesely@tana.it Thu Aug 30 04:03: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 B1B6F21F8611 for ; Thu, 30 Aug 2012 04:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.681 X-Spam-Level: X-Spam-Status: No, score=-4.681 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZFEzjdFYk6G for ; Thu, 30 Aug 2012 04:03:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CD44521F860E for ; Thu, 30 Aug 2012 04:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346324625; bh=dIUoAfITbHVTExvSAQAqt1qFMlynGmGnAo4In0P/6jY=; l=1205; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Kj06Q+lCOHcuZIMzuVAoPzanv7JCV94YhTfw9rMRC0zXtVju7tDveT+Qm5DTyQRil Les2KsV7yBW8JxSKDMp9RdhMrx1539CwKkVHnIWJhTXG8g/JgoSq1STr0KpbZyfBUp Wz0zntYj4zqlcVZn3D9DdIOHYzbSkHBNRdJHnK/I= Received: from [109.115.133.131] ([109.115.133.131]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 13:03:42 +0200 id 00000000005DC039.00000000503F488F.00000D0D Message-ID: <503F4887.4060207@tana.it> Date: Thu, 30 Aug 2012 13:03:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <20120830054957.GB59367@mx1.yitter.info> In-Reply-To: <20120830054957.GB59367@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 11:03:46 -0000 On Thu 30/Aug/2012 07:49:58 +0200 Andrew Sullivan wrote: No hat. > On Wed, Aug 29, 2012 at 01:42:08PM -0700, Arthur Thisell wrote: >> First off, when drafting RFC4408, we were scolded by the DNS >> folks not to use things like NXDOMAIN, SERVFAIL, etc. because >> those are labels for particular libraries/APIs, rather than from >> RFCs. Instead, we should use RCODE. I don't know if the opinion >> within the IETF has changed since then, I see IANA now has a >> registry with names for DNS RCODEs. I think we should be >> consistent, either use only RCODE numbers, or only use IANA >> names. > > Error codes _always_ had names. My personal preference has always > been to include the RCODE and, on first use, the symbolic name as > well. I'm also happy if people use the symbolic name, with the > RCODE on first use. But I think both need to be in the document at > first use, no matter what. Is there a better place than 1.3. *Terminology* ? In http://www.iana.org/assignments/dns-parameters I find, for example, that decimal 3, name "NXDomain" means Non-Existent Domain and its reference is [RFC1035]. However, RFC 1035 does not contain the symbolic name string. RFC 2136 does. From vesely@tana.it Thu Aug 30 04: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 62EA421F85F7 for ; Thu, 30 Aug 2012 04:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnTKmk9Cmrd0 for ; Thu, 30 Aug 2012 04:18:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5492E21F85F4 for ; Thu, 30 Aug 2012 04:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346325497; bh=QlNRGkHhExMfzTvuiUN/s87meaGYi5UgXcJk28GSfcg=; l=3573; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dQ/pyJ93gNtztz5pCXaU+5Ohz/rja8QIanZqbJUQ/ShJkH8SDxqCGrZNoR+qgcB7o QrTtiNzGrC3SRBX2dgoVOUH/t1f/X/l8GUYNPr+di2GhgXOFYSJxXxtCgzNoz3EWWd cTdrsvghjCDFUjbv/bAZGdezbJL2dlMR2VDCZnBg= Received: from [109.115.133.131] ([109.115.133.131]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 13:18:16 +0200 id 00000000005DC039.00000000503F4BF8.000010B6 Message-ID: <503F4BF2.6000001@tana.it> Date: Thu, 30 Aug 2012 13:18:10 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 11:18:20 -0000 On Thu 23/Aug/2012 18:06:18 +0200 S Moonesamy wrote: > At 08:21 21-02-2012, spfbis issue tracker wrote: >> #22: RFC 4408: Section 2.5.7 PermError on invalid domains after >> macro expansion >> >> The Permerror definition ends with: >> >> 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. >> >> A after macro expansion of can be invalid, >> i.e. a string not suited for DNS queries like foo..example (adjacent >> dots), a with overlong labels, or similar issues not >> permitted in the DNS >> syntax. >> >> Suggested fix (variant 1): >> >> The last sentence in the Permerror definition is misleading. A >> syntactically malformed can be also handled as no >> match. The specification should say: >> >> 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. >> >> Please note that an unexpected can be also handled >> as no match, ideally implementations document how they handle >> such issues. The outcome for an unexpected without >> macros might differ from the outcome for an unexpected >> after macro expansion. >> >> Suggested fix (Variant 2): >> >> The last sentence in the Permerror definition is misleading. A >> syntactically malformed can be also handled as no >> match. The specification should say: >> >> Be aware that it is also possible that this result is generated >> by certain SPF clients due to the input arguments having an >> unexpected format; see Section 4.8. >> >> At the end of Section 4.8 add: >> >> Note: Historically, this document has made no provisions for how >> to handle s, or macro-expansions thereof, that are >> syntactically invalid per [RFC1035], such as names with empty >> labels (e.g., "foo..example.com") or overlong labels (more than >> 63 characters). Some implementations choose to treat as a >> no-match mechanisms, and ignore modifiers, with such names, >> whereas others throw a "PermError" exception. The outcome for an >> unexpected without macros might even differ from >> that for an unexpected after macro expansion. >> >> Rationale: >> >> Reporting a TempError in such cases is no option, the syntax >> problem won't go away for a given sender policy, HELO identity, >> envelope sender address, and sending IP combination with a try >> again later TempError approach. If anything else is as expected >> the sender policy might need to be fixed manually, supporting >> PermError. >> >> If the DNS syntax problem is caused by random net abuse, or >> intentionally by an attacker, a no match approach, eventually >> reaching a FAIL for -all or whatever the sender policy offers, is >> better. In common practice this problem is handled as no match OR >> PermError, like similar problems explicitly addressed in the >> specification. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html > > Can WG participants please review draft-ietf-spfbis-4408bis-06 and > comment on Issue #22? It is not clear whether the above provides for derivative strategies, such as throwing an error depending on the qualifier of the "all" mechanism. I'd opt to allow implementation-dependent behavior as long as an evaluation that went through errors cannot result in a "pass". From hsantos@isdg.net Thu Aug 30 04:21: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 4CEAA21F861A for ; Thu, 30 Aug 2012 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV4-I7PHm9oH for ; Thu, 30 Aug 2012 04:21:45 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71921F8616 for ; Thu, 30 Aug 2012 04:21:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=646; t=1346325700; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=hAjFG7vutbazKDf3WA2aXn2pHkg=; b=Hl3Oz8z3UdZlKfJPX39P xCbHN0qXKRDR9ZknI8xQa3ie2aPmvK1GoSwvBpv2KDurYYfkUcP3HWeU6ftNIW4z UjmxQbLjhUmE1Ny3zXdPZHuFeUT5gjMWxPWZf3s7ETYOi9zBGz0CtAgBvkia4jcH 5YiNQzXyVB0bgN6tjSAuwUo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 07:21:40 -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 2347490855.8048.2608; Thu, 30 Aug 2012 07:21:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=646; t=1346325497; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KhO72HT BBj9nv2ncybacESj0AsTYfR0She+/n06jTsw=; b=fjGKCJKO+OLNRCPrCd7f11t 9abCVTlsvpY2uyXfkAWMKy6HnkIvfN6aLB8ekRdepAzKIZhz57BZmWdSeEhVXHWJ XWP4GPT82utgrZlYYucXjLMqHrkl5eKS7iQ2fFeWc1P3ZNWTqyHPqFMZk6lcM875 lTcgwDi0bFqp3AMlKI1c= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 07:18:17 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2946294911.9.7540; Thu, 30 Aug 2012 07:18:16 -0400 Message-ID: <503F4CBA.9060102@isdg.net> Date: Thu, 30 Aug 2012 07:21:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: SPFBIS WG References: <1346324430.24241.YahooMailClassic@web125403.mail.ne1.yahoo.com> In-Reply-To: <1346324430.24241.YahooMailClassic@web125403.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 11:21:46 -0000 +1 Arthur Thisell wrote: >> Murray Kucherawy pointed out that RFC4408 contained no protections against spoofed Received-SPF attacks. > > RFC 4408 says: > > The Received-SPF header field is a trace field (see [RFC2822] Section > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver. It MUST > appear above all other Received-SPF fields in the message. > > This text is still in 4408bis. > > RFC 5322 makes no mentioned about forged received headers, nor does it say anything in its security section. Why would RFC 4408 need to say anything more? > -- HLS From spf2@kitterman.com Thu Aug 30 04:31: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 E23FA21F855A for ; Thu, 30 Aug 2012 04:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWL28YMRFvMk for ; Thu, 30 Aug 2012 04:31:10 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57621F8559 for ; Thu, 30 Aug 2012 04:31:10 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 286CBD0408A; Thu, 30 Aug 2012 06:31:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346326269; bh=c+R9RU5NCnQXUowvExl+ABG31P9Nlu2XrfFlcy0dQt4=; h=References:In-Reply-To:Subject:From:Date:To:From; b=HjMjv4euFFkXp10WAhSTa/cdF38rMEU2X9Aktof4NoR4W6QELNhGZNER453HvPtjZ 6QuFBsQIUSPgw2AZAmrHo11cR4WdV+STrq+HedNeEFXIGjXgwnCA6TO541sU7bUpdb mNBG2XmWFRpIsB4pOFfym0CtqQ9fHkSFkaOSDRIc= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 64291D04087; Thu, 30 Aug 2012 06:31:08 -0500 (CDT) References: <064.7bacdd0d9c7b5553b356aadbc6fe448b@tools.ietf.org> <6.2.5.6.2.20120829230931.0a3c43a0@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829230931.0a3c43a0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 06:31:06 -0500 To: spfbis@ietf.org Message-ID: <24898e16-ed27-44b9-b9ff-4918a64a2b3a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #39: Temporary errors implied as only caused by DNS errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 11:31:11 -0000 S Moonesamy wrote: >At 18:11 26-08-2012, spfbis issue tracker wrote: >>#39: Temporary errors implied as only caused by DNS errors >> >> Message from Arthur Thisell posted on 26 Aug 2012: >> >> * In section 2.5.6 on temperror, new language seems to imply that >> temporary errors are only caused by DNS errors, but timeouts could >be >> caused by local problems unrelated to the DNS. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > >RFC 4408 mentions transient error without going into details. Every time 4408 specifies returning a TempError it is because of a DNS error. Scott K From agthisell@yahoo.com Thu Aug 30 05:07:02 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 C615121F8602 for ; Thu, 30 Aug 2012 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDH+KyTRQsRd for ; Thu, 30 Aug 2012 05:07:01 -0700 (PDT) Received: from nm30-vm3.bullet.mail.ne1.yahoo.com (nm30-vm3.bullet.mail.ne1.yahoo.com [98.138.91.160]) by ietfa.amsl.com (Postfix) with SMTP id 8BF0921F85F7 for ; Thu, 30 Aug 2012 05:07:01 -0700 (PDT) Received: from [98.138.90.57] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 12:06:56 -0000 Received: from [98.138.89.253] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 12:06:56 -0000 Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 12:06:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 102037.31762.bm@omp1045.mail.ne1.yahoo.com Received: (qmail 3286 invoked by uid 60001); 30 Aug 2012 12:06:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346328415; bh=S+RPfjdF10xsRbeub5B5dV8V6vapBhb9wwHW+iLcsoo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=iT7Z0zYZSAuql0XsZybPU1pEiSWnwIR5t+VDyr3TwPd62QznQyGwR7+FE8rCV7IvD+lJsv2vDRmRbg38JeeW6AipV+2vVx1FjIlnZPOSEAd2MAzYpZNk2P8fSj2Nsj2VmRtyks2isKL7eq5mBJB0lkzYIsSoDfMLCIwiONR32qk= 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=kw/oxZbzQGEhNIN3MsWVeIgmq1bf9XAUGRNxNlwnDFZcK7b+c51VjgQRDmoKntTBfQP39qvIub4UTZBZ3NxfZno77rB/OuEhzL7H2f4slbLq7nfhO5aKj5b943cV1Ud3e0orDmrOQOS/VlXqUCIPOLkqFXaf6GvTHpsA9obSEqg=; X-YMail-OSG: 43k5LXMVM1k_oFL7iJxBw9htrAPQrRCkD12MTD62qrvBiWk w6Y.yMxERPPEDKXaDQoCGQAgOeLJVeJaccWJrzus9PG5xykx_vzJHIW.lz8D IVNCE4ewFGhhQ35epK180DMrvJFXQxBv1qPVWKBOyckVUvrR1rfyvkWP_OqT 1LXtuNlaxz.otpdWW9TeBTms4nMah2CGS2wnMy3orxcNOw_xEm0gvVEGxyr1 z2E_vNC8WFb.YDoRgX7bajPOm.fwz98OxhgZ0gHpkNfkAik0kuTvH.70ZTdw GQd4XnHJlcO9skzRMs_zISMDufyYl1goWRCIoZkX2Lcu.d_JAw9JzgwrGEW1 LR84ZWCV.4BblvShcIHYTQLMirmLGyo0HLL65gVigY_SeK2j4JDXbU4ZO8Sw TEotstq4rDI9e0Y7J_bdlNbQouyLmrHemXUgSEZClbUUcfxxdIWmhTHM6B0s HSBFejakdAPV2GBpnMnyHaBT3.5QckQ-- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 05:06:55 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346328415.720.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 05:06:55 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #39: Temporary errors implied as only caused by DNS errors X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 12:07:02 -0000 >>> but timeouts could be >>> caused by local problems unrelated to the DNS. > Every time 4408 specifies returning a TempError it is because of a DNS error. Again, timeouts do not need to be caused by DNS errors. RFC 4408 was equally vague, saying only that temperror were transient errors while performing the SPF check. From spf2@kitterman.com Thu Aug 30 06:07: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 4463D21F8516 for ; Thu, 30 Aug 2012 06:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9Ms-zVZCW0Y for ; Thu, 30 Aug 2012 06:07:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8621F84FE for ; Thu, 30 Aug 2012 06:07:42 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 6FBBED0408A; Thu, 30 Aug 2012 08:07:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346332061; bh=CvAIlNtL0k7ETH2QOpZ2fdxNZXqOyuZ/ojqsLb3ABQk=; h=References:In-Reply-To:Subject:From:Date:To:From; b=oPip/KsYPpJrsY3y28njFratOZzWNjtJydL+BLglZkxx2qX7Q6Q/+5a6GMJr/v2rq va7qy8QeBU8AF0zcGN+tbCg/CDraXgV/At46zaLdY1p3SUIhdGtF1HC3MuQ3dmbJNw DKxrkgmRNqgKRUPGmaOVqEC08eZ69o37gITUt3BY= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EA2AFD0407E; Thu, 30 Aug 2012 08:07:40 -0500 (CDT) References: <1346328415.720.YahooMailClassic@web125401.mail.ne1.yahoo.com> User-Agent: K-9 Mail for Android In-Reply-To: <1346328415.720.YahooMailClassic@web125401.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 08:07:40 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?=2339=3A_Temporary_errors_implied_as_only_caus?= =?utf-8?q?ed_by_DNS=09errors?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:07:43 -0000 Arthur Thisell wrote: >>>> but timeouts could be >>>> caused by local problems unrelated to the DNS. > >> Every time 4408 specifies returning a TempError it is because of a >DNS error. > >Again, timeouts do not need to be caused by DNS errors. RFC 4408 was >equally vague, saying only that temperror were transient errors while >performing the SPF check. A timeout is a type of error that can occur with a DNS lookup. You''re certainly correct it can happen for a variety of reasons, but I think it's still a DNS error. Scott K From spf2@kitterman.com Thu Aug 30 06:13: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 C04AE21F85A7 for ; Thu, 30 Aug 2012 06:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uVExIkRwPDx for ; Thu, 30 Aug 2012 06:13:43 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B726221F8499 for ; Thu, 30 Aug 2012 06:13:43 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0B285D0408A; Thu, 30 Aug 2012 08:13:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346332423; bh=Y16sxHkA4183J738tV/n+cGas0WCWdbx6YN8u6fNqNk=; h=References:In-Reply-To:Subject:From:Date:To:From; b=hNuIkNVoaRnVwyEuUh5F8TU6FGEhFmULD2/4T4hFk6rstv/pBqCput5j1ZpsE2D/4 znVj7FRXAetp+ZO+mN6VrVtnOYACnVcFpT7sgBqubSnrV1gjt1voemJrbgGKpr49TM wsCPSDdLiFtnSY/sxBAon16nh8Xrw56kajx+uLlc= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8E8E6D0407E; Thu, 30 Aug 2012 08:13:42 -0500 (CDT) References: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> <6.2.5.6.2.20120828224800.0a64c778@elandnews.com> <1428962.6IPKQEtNWL@scott-latitude-e6320> <6.2.5.6.2.20120829215317.0a841b78@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829215317.0a841b78@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 08:13:38 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #48: Section 8.1 - macro defs X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:13:49 -0000 S Moonesamy wrote: >Hi Scott, >At 20:46 29-08-2012, Scott Kitterman wrote: ... >>Since you've recently stated on the list that you haven't reviewed the >>document yet, perhaps you could provide that. > >I will have to review the draft after the WGLC. So? If you defer review until after WGLC, then we may end up with a lot of new issues that need to be addressed late in the process. As efficient as that may be for you, it seems highly suboptimal for the goal of finishing the work of the group in a timely manner. Scott K From agthisell@yahoo.com Thu Aug 30 06:16: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 7EF8D21F8499 for ; Thu, 30 Aug 2012 06:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xexbkd4PaH-D for ; Thu, 30 Aug 2012 06:16:42 -0700 (PDT) Received: from nm14-vm0.bullet.mail.ne1.yahoo.com (nm14-vm0.bullet.mail.ne1.yahoo.com [98.138.91.52]) by ietfa.amsl.com (Postfix) with SMTP id A96F021F85EA for ; Thu, 30 Aug 2012 06:16:42 -0700 (PDT) Received: from [98.138.90.55] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:16:35 -0000 Received: from [98.138.89.194] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:16:35 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:16:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 930072.38069.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 47090 invoked by uid 60001); 30 Aug 2012 13:16:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346332595; bh=l+aOg3ivs8Zb7s0276cPUur1G6areoZ3lnlNkofUWEg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Q1etR3FK39ziduEJSjUMsnPNRyZBBdZUoD9obq5UdrFCL+pjOy6b6i9Csxq4JV0iwnIh4smmnKGo09tJEQIasq4waYv9bPo1sgSagqKXUdkzOiZVaNgD9yRUWks5wyyY2DjkMaQbgNhGnNtbv/dUb6BDrGvVU01Dtmz8Q4hTn7g= 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=I+ZEUASWnIS8Os88pRgNb5+nl4lJFyJdwDldL2YcOLQiZJZ19TH4iX3jvMSJtiQNSyfietZtLGqT/Q8ieGSRjkA2k0TwFEfJqp8h3qz2XTaCpIbtD7EzVuVFmNO3c/fFIariuJnPoj8U5Yxlrk6eVNYdp3HwuZwRO65FhT1qesY=; X-YMail-OSG: dA5kN_MVM1nBiQS3U7yRldG8S5uLGTuatxa7VwfwcDk1snz lnh9j1PakUNcvZMNHOyXHMzcyPUC0kNGt3BIzdXe0HsgH9kN7Rz3_xST3a2u B42LWPIuy0nyerOLSY36AHdnu3z31bjK1aNPit_OQEA4NUJWFlCVcICvgSKK yAgBSkWxYe7pCPG95iR1D7p7NtqgZeS8lLljUrMjIYIe6qHdSZo7Pwzyav16 Mrip61zgAxsRmqGnXzuqbKCwbQWs91ke5JqW99X4pwQOFfZjxsTRNFrWHRmq t6WcR5ojG4nLOePNxNAV7tVNA7QxLjJ2EzDblLqEmqT38TjdiV3_aQUJMcMY gY__e0I1u5blW.sFI6LiD3886yLCMcLKYbFFWBCWnBTBZpLuL3PPsxjp07YV K2iURq3blQn3D_guHJp3w7MvcJYTqdEBUg.RjdVcF0KBheNoRd400PfAJx4L rabuA4lXlP4.Sy1Vjkl0- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 06:16:35 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346332595.45626.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:16:35 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 13:16:43 -0000 >> First off, when drafting RFC4408, we were scolded by the DNS folks not to >> use things like NXDOMAIN, SERVFAIL, etc. because those are labels for >> particular libraries/APIs, rather than from RFCs. Instead, we should use >> RCODE. > > Error codes _always_ had names. I wasn't very clear in my post, the above explanation was more for why there the "I-D mentions SERVFAIL only in Appendix C", when really, it is mentioned several times via RCODE 2 or set negation ("not RCODE 0 or 3"). I am neither care deeply about this nor am I an expert in this area. When someone who has his name on several DNS related RFCs says that NXDOMAIN etc. are bind API names and that the SPF drafts should be changed to RCODEs, I'm not going to argue. When you say that error codes always had names, I'm not going to argue. As long as the IESG doesn't come back and tell us to change it, I'm happy. Changing the draft to your suggestion would require a bit of editing. From superuser@gmail.com Thu Aug 30 06:29: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 2B44121F8616 for ; Thu, 30 Aug 2012 06:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiyBwbFIqYge for ; Thu, 30 Aug 2012 06:29:12 -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 552E221F85F4 for ; Thu, 30 Aug 2012 06:29:12 -0700 (PDT) Received: by lbky2 with SMTP id y2so610079lbk.31 for ; Thu, 30 Aug 2012 06:29:11 -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=wqOVrLINQjShAnqtCYrHyqUF35SFDJ4AmD8R9l+L9to=; b=LeNdNfCs4VhTP8me/nql3FlwmF24fy4u6GGYP5dM44vz7Y6V4iPRumSTkLGJ2LvMBr nQ9hD+/J1xgVi/bbBSuqtHL0yy8qLedadWDggjARmw15MUN/jWgisYq2BXT+ANsHUmGa U9hqrfNafrQ0NleSnUMrlsstjmSt/Z9x9b3dV6hYVfXbl4LcTb0aUkutMCZxgfFn1Xrb FZR22jOAsegrdfT+wl8flb8v/ub+KWWu+ZXsr1n0xW3h3SPRWGdT/yzRAfeYFcFrJUjz xengtkWi4luZn6ZQ8SWZfT3AJSWgw4LrC7fZDv62l5k5XVzzxMlV5qSaz+MOmu62BJvv noJg== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr1373532lba.69.1346333351201; Thu, 30 Aug 2012 06:29:11 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:29:11 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120829231332.0a3c4258@elandnews.com> References: <064.d1bab9aeb936b01c76e6fcdd6a048370@tools.ietf.org> <6.2.5.6.2.20120829231332.0a3c4258@elandnews.com> Date: Thu, 30 Aug 2012 06:29:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #43: New requirement for mx: or ptr records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:29:13 -0000 On Wed, Aug 29, 2012 at 11:19 PM, S Moonesamy wrote: > One of the RFC 2119 requirements appears in different sections of the draft. > It's better not to restate normative text as it can lead to different > interpretations in case of ambiguity. This is something the RFC Editor will catch and send back as well. It's best to state the normative stuff once and then reference it elsewhere rather than repeating it. (Also of interest: The RFC Editor will not allow document Y to use normative language to summarize other normative language in document X (and rightly so). I discovered this during the final work on the experiment document.) -MSK From superuser@gmail.com Thu Aug 30 06: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 B246221F8622 for ; Thu, 30 Aug 2012 06:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ixdxsb8kXF1 for ; Thu, 30 Aug 2012 06:35:16 -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 DA8C221F8621 for ; Thu, 30 Aug 2012 06:35:15 -0700 (PDT) Received: by lbky2 with SMTP id y2so615280lbk.31 for ; Thu, 30 Aug 2012 06:35:14 -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=PplM5rYdZufGwXpwbiRCfQEeFM2r/z6jswkJqEuv8nE=; b=Jp9c35gibLanDsy88UA4NjKWAv9O/yYnjn6KjrwxiLBBKYPCMpPNhTgorqZO5CuQTo JmqH+0qKsn1+WtP0wS14b9lBSrgf/cNKF7TG9cftUquCsl52VUy2I+5FP4FtNym+eatw hmOlj7UnWDt0rYd4Z87+h7/I3/TH5FGsR2qNMeWWgnUxWeLoEnYLGjUl2KcBJNqKOHno 2sqNfbyuHuDhNUwuwvjNjkx1fvH1t2UoX4ia0yKz/GeIpVqTrFn+Krex63Erjtgnb+cr jcjRjLjG5wfoXBBFwqBKZ7zgix+fd7p986N+IVYExmfbvWkRXQ0YAMonEWENihqqSPen jB2w== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr1388469lbb.72.1346333714707; Thu, 30 Aug 2012 06:35:14 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:35:14 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120829221451.0a8421e0@resistor.net> References: <2038344.xmME5XhsPg@scott-latitude-e6320> <503D03FE.5010507@isdg.net> <6.2.5.6.2.20120829005310.09eeeca0@resistor.net> <4145261.ebQcLzVxW3@scott-latitude-e6320> <6.2.5.6.2.20120829221451.0a8421e0@resistor.net> Date: Thu, 30 Aug 2012 06:35:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Authentication-Result (Issue 10?)) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:35:16 -0000 On Wed, Aug 29, 2012 at 10:45 PM, S Moonesamy wrote: > There are issues such as header positioning and forged header fields. > Murray Kucherawy pointed out that RFC4408 contained no protections against > spoofed Received-SPF attacks. Right, the Security Considerations of RFC5451 pretty much all apply to Received-SPF as well. It would probably be wise to indicate this at least (i.e., refer to it and save ourselves repeating much of it). I would add to SM's summary that sid-milter (now abandonware) generated only Authentication-Results. I still owe a proposal for new text for Section 7, but I've been swamped with day job stuff. Will try again to take a run at it today. -MSK From agthisell@yahoo.com Thu Aug 30 06:38: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 AF04921F8551 for ; Thu, 30 Aug 2012 06:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+M5Ks8Tly5I for ; Thu, 30 Aug 2012 06:38:36 -0700 (PDT) Received: from nm2-vm3.bullet.mail.ne1.yahoo.com (nm2-vm3.bullet.mail.ne1.yahoo.com [98.138.91.132]) by ietfa.amsl.com (Postfix) with SMTP id 1D7B821F8535 for ; Thu, 30 Aug 2012 06:38:36 -0700 (PDT) Received: from [98.138.90.53] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:38:30 -0000 Received: from [98.138.89.166] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:38:30 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:38:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 711847.40461.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 60538 invoked by uid 60001); 30 Aug 2012 13:38:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346333910; bh=xD3y4M9y3FcAR0B2v/CfVSS6Suxh/83H0GkLcJ/IEE8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=NRSmnRNqWjLqwafCdrRv2gbWfS0cIib1uQtNH9Jj2hXkkD0i262zDPryLquYiu4IwAP/ptjOQfC/iRSvHJhj5O0VYfi1dQCwUqMS3U3pQQYMFnyZKoxP29+RlpCbMWlVQrxUmKUtr/nSLTkrzUogaYtvLMtrEideE+KbTKosn1s= 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=GXuhfGGQTsfbd8BNYcs1f87FgVVs4mmT6OoF9KYiGXL9ws/KsqpU0a5/L0T6bmfeNeuw8UBSQBOpf9wIAaZfVMJVqHNbdc1V1o3zPuh9jQj6tjj9/w9598YQ+/mQXwlxopurrTI+WuhyTCWn648ElttjBaHdAhsJhgB83DNTv5Y=; X-YMail-OSG: TxL4ALkVM1mvWUCOfMz1JPGmvlCuQlfGtxW0ErwHi2M6tV_ ixwh1pUhaLcVZXhIP52KxVLoOs.hsrlhYyup1RINRAnIhjyHUjDz2._t8K1K E1johvpvnohr5Sbbthk1tonAhIFQJwYtkpAI2qF35btwpAofO5hLwDecWQYS 64VFukj.cWj9C2Q3r4dlJoR2Ml_1ZDfjP9DQRQpdmAo1gwIOCpzdN6lnph9X jzTXELUG84lknaEmwHaTVsHcKiuVpoxEYvl4pfIU99VQuoK12YMY0Zdsgzvt Y6w0j8o3HAHVKPHhDROcmcQRcxgHosttI.Mz1zC8zlq15t1nJZXgkjDemoL0 xX48__dh16BPQpjmXghj_e6j_FoyxxpWONJnKPcBhY8kglhpu8pMQReEJzsd 9SpZMtdsB9ZncAfQFNNmD6IoDKAagXf3uQN6ChUgAUQ3mJysmFSnpcRLLKw2 HHX1PVQEiEwNQW13q9bg- Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 06:38:30 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346333910.47792.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:38:30 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:38:36 -0000 I don't see a problem with some malformed domain names being turned into permerrors, but we need to be careful not to stomp on Section 8 which says, in part: When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length of a domain name), the left side is truncated to fit, by removing successive domain labels (and their following dots) until the total length does not exceed 253 characters. Some malformed domain names are also covered in section 4.3: If the is malformed (e.g. label longer than 63 characters, zero-length label not at the end, etc.) or is not a fully qualified domain name, or if the DNS lookup returns "domain does not exist" (RCODE 3), check_host() immediately returns the result "none". So, I guess that means that null labels and labels longer than 63 octets should be permerrors? From superuser@gmail.com Thu Aug 30 06:39:37 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 0109121F860B for ; Thu, 30 Aug 2012 06:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kepOSfdSqzzc for ; Thu, 30 Aug 2012 06:39: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 2C30321F8551 for ; Thu, 30 Aug 2012 06:39:35 -0700 (PDT) Received: by lbky2 with SMTP id y2so618786lbk.31 for ; Thu, 30 Aug 2012 06:39:35 -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=newKQQo6HZINsnJs2yju4pMMo/BbdJ0XtwGMovKqwrs=; b=g3pb9zBNP6Vu5vxrd5t/fdwVhLeJmDyGFZ9IacStWlKvD7skUfJisR6O0gj72NwWDc 0s5mLf+petqvZ6bS6OeMTDfEd8VxissK6w7LdIM7UN5sZi3GxkFgeN4HFYFxd+b+pR7J 3EkJ3mPoYr4c6T3Z5wW06UdXTbNA4UaTB5wf2Gpr9kPz8xxuKB61R6UqDHfRHHt7L2JM tbbFGR4r1xCgQnroN8pfgeFA1INqt1ngogOZIJkG3LW8/CUZbZFipL6C6iyl9lzmZJjy U9XDZIzFn+F80v0OfcPXHXbjwwOudz5i7T6H9hi5tAPS+WjkVQTVTjSnP60ebFoFjgJ3 W7WQ== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr1384776lba.69.1346333974873; Thu, 30 Aug 2012 06:39:34 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:39:34 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> Date: Thu, 30 Aug 2012 06:39:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:39:37 -0000 On Thu, Aug 23, 2012 at 9:06 AM, S Moonesamy wrote: >> Suggested fix (Variant 2): >> >> The last sentence in the Permerror definition is misleading. A >> syntactically malformed can be also handled as no match. >> The >> specification should say: >> >> Be aware that it is also possible that this result is generated by >> certain SPF clients due to the input arguments having an unexpected >> format; see Section 4.8. >> >> At the end of Section 4.8 add: >> >> Note: Historically, this document has made no provisions for how to >> handle s, or macro-expansions thereof, that are >> syntactically >> invalid per [RFC1035], such as names with empty labels (e.g., >> "foo..example.com") or overlong labels (more than 63 characters). Some >> implementations choose to treat as a no-match mechanisms, and ignore >> modifiers, with such names, whereas others throw a "PermError" exception. >> The outcome for an unexpected without macros might even >> differ from that for an unexpected after macro expansion. I prefer this solution, with some corrections to the final paragraph (get rid of "throw" as has been done elsewhere, correct "to treat as a", and give an example of what the last sentence is talking about). -MSK From prvs=582bcc053=fmartin@linkedin.com Thu Aug 30 06:44:02 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 41EC721F852B for ; Thu, 30 Aug 2012 06:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snTXWnPXFFii for ; Thu, 30 Aug 2012 06:44:01 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4121F8526 for ; Thu, 30 Aug 2012 06:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1346334241; x=1377870241; h=from:to:subject:date:message-id:mime-version; bh=uWFVMXtwQFuz5Gb/UGR+NLsk4LUtzWn97FJTISDtMzw=; b=C5VPLf+R8SIhDPMWj1f+fu9jGKtreaDITVyBAvgbF9aKsrrx5Q1v9luA +9KQXd60MpNEt8OkA9DcKv3X8Yq/wQr8hNZgp1aIyzuE6CMVTVJ6ImXFm QpCQ8gbNk1R8MLFsTwzpn4SJKMwSocti/gcbrTLqXbnIDXM7uo8uzqRbs M=; X-IronPort-AV: E=Sophos;i="4.80,339,1344236400"; d="scan'208,217";a="23005811" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 30 Aug 2012 06:43:32 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Thu, 30 Aug 2012 06:43:32 -0700 From: Franck Martin To: "spfbis@ietf.org" Thread-Topic: DNS record _spf.example.com Thread-Index: AQHNhrVyELph88I5DkS5iDjH/5jAKw== Date: Thu, 30 Aug 2012 13:43:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: multipart/alternative; boundary="_000_CC64BC294F9E6fmartinlinkedincom_" MIME-Version: 1.0 Subject: [spfbis] DNS record _spf.example.com X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:44:02 -0000 --_000_CC64BC294F9E6fmartinlinkedincom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know if it has been discussed, but should we encourage the usage of _spf.example.com to store the SPF TXT record? Many other protocol use that notation. I know it is frown upon by the DNS p= eople, but the adoption of the SPF record type has proven very slow, and we= should avoid to overload the TXT result of the domain. --_000_CC64BC294F9E6fmartinlinkedincom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7E360AB5386F7C409596D711D41367B7@linkedin.com> Content-Transfer-Encoding: quoted-printable
I don't know if it has been discussed, but should we encourage the usa= ge of

_spf.example.com to store the SPF TXT record?

Many other protocol use that notation. I know it is frown upon by the = DNS people, but the adoption of the SPF record type has proven very slow, a= nd we should avoid to overload the TXT result of the domain.
--_000_CC64BC294F9E6fmartinlinkedincom_-- From agthisell@yahoo.com Thu Aug 30 06:49: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 1DAA921F85F4 for ; Thu, 30 Aug 2012 06:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxbyABwyMKNF for ; Thu, 30 Aug 2012 06:49:03 -0700 (PDT) Received: from nm34-vm7.bullet.mail.ne1.yahoo.com (nm34-vm7.bullet.mail.ne1.yahoo.com [98.138.229.87]) by ietfa.amsl.com (Postfix) with SMTP id 7247121F859A for ; Thu, 30 Aug 2012 06:49:03 -0700 (PDT) Received: from [98.138.90.50] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:48:57 -0000 Received: from [98.138.89.170] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:48:57 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:48:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 911590.79569.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 69339 invoked by uid 60001); 30 Aug 2012 13:48:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346334537; bh=HpEIa7H5NctV15bEsLO/Fv0P9QHrELNrEjuXocHKTu0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=HRdyJ8e+tsMSA5fH8Q+Qs29a7ntO2qum1e1hOBEVIbGdWXGln2QbOFqg6G3VMALlXFZ7MrXyZJoFgPIwsy6IsFqJfGEFuIxnyekzI0B/+v292fSx81ywn3Dj7jAVb74iQkFfRTQdtuUpqK1cut7BCXlj8/yO8Ux7BMLoqhPZoVI= 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=YEH9TyAo4PmvXCLd690MFrUs+ALY6PQILUxUTeKhCnTauFDHBTAF3TgEVz2zYkMYL0eg8NTtpp8h1coOnnrF8yGenXG0s1JJf2acjIjTSjTGAEILsZ4WUkRArUe+njEwKGz6rK7AKk+y6QTtE2HdyO72OwkuFHameom+P4lf5O4=; X-YMail-OSG: J7dO.0MVM1nSV6Dnot.9kc95kGx2QLaeeDCQwaQP5Soko68 BDbhdTSJ7vr64wR4OkG508bE6N1kxz5pOhOhvtq6LoXJCbcziLCg0M2NKtuk GuH.S9HNlqnH_UomYrzoO4E2UxV4EhrfdazMTlQCJ74ezvsZUoaBk8TNkJTf UtEr.TqVXDzaiExPzOzI2.OW7r.X2qwP11gVWXncDDUMKwpQxQ00f0MWYrZF vJBg.xC_hcZb48PaKuz78iS00m5fFBHI0l24qkoHFfQJGLqqp.qcAS5pqpFF AforE.wPNKBsEWre610A5NGqWqG8lGPm5jmrd1MyrN4dopoIntT2DKad_Cyb hF.8C9WTtNuQPMOeuDYrT87HdqgwtqGZ.6ux45Rsz5ePqsfY6oL0vPgwa7Fa fMZHqG.q1ZE8UcYvvFX6Rj25Lkg1GIFd0TrJKgoLaWmooXJBt5FDuizdIENN tcET.jL9vQMJghA5Wslg- Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 06:48:57 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346334537.69117.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:48:57 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #46: DNS reply in Section 5.7 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:49:04 -0000 > Please recommend text. This was added because it turns out at least one > person thought match meant fail because the language describing exists > compared it to a DNSBL and in DNSBLs a match is "bad", so it ought to be > clarified somehow. Sorry for the second response to this, I failed to drink my coffee. ;-) I think the current text is better than RFC 4408. You now mention both DNS white lists and black lists and give a pointer to the new(-ish) RFC on them. I think just cutting out the duplicate directions of how exists: works is fine. From superuser@gmail.com Thu Aug 30 06:52: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 F1A0021F8526 for ; Thu, 30 Aug 2012 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk3NX+1q7M4L for ; Thu, 30 Aug 2012 06:52:13 -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 1500521F8517 for ; Thu, 30 Aug 2012 06:52:12 -0700 (PDT) Received: by lbky2 with SMTP id y2so630216lbk.31 for ; Thu, 30 Aug 2012 06:52:11 -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=3s59laHL3GvFhCAnCaxAWuT/JASYIStf+GAXGdRiMdI=; b=r/KS2T10qi/Dkkqk6n3dhCWPVri6qGpTRA4du6o4vPv7EsTrzUUriv1q6RO1jA6ngu DlvBtcst43qYLQqLkgk6/4D7Uv6od+Jyp1ytL+lzS/dyraXXsc4et2oOEVnTqGxOptWB uzTFi3XNsnrOTt1mT7yP6fxeR3+S8bpmtFmZMEabv7EI72dd1NZObN2TCjepCjIeDTLD E1t/qn2wu5/4dSTSfiMkEkcZWxvbE4fBEDSKsya3EnxK3FyDRqqYz9VhBoVx4sblUqEL ZvHWMIXYxu4JvQUplT9myMLjczUqociI3pLpTDBUyM5CPBqJBT7Xsxh4I5sxac45xr0X NkTA== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr1405073lbg.55.1346334731661; Thu, 30 Aug 2012 06:52:11 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:52:11 -0700 (PDT) In-Reply-To: <1346324430.24241.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1346324430.24241.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:52:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:52:14 -0000 On Thu, Aug 30, 2012 at 4:00 AM, Arthur Thisell wrote: > The Received-SPF header field is a trace field (see [RFC2822] Section > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver. It MUST > appear above all other Received-SPF fields in the message. > > This text is still in 4408bis. > > RFC 5322 makes no mentioned about forged received headers, nor does it say anything in its security section. Why would RFC 4408 need to say anything more? Received fields are not explicitly carrying security information, merely trace data, so RFC5322 didn't need to point this out in Security Considerations. However, Received-SPF and Authentication-Results are very clearly carrying authentication information which, if falsified, can cause end users to be deceived. Depending on header field ordering to infer security details is historically problematic. One has to imagine crazy things could happen at each hop, such as the entire header being sorted alphabetically or even randomized. I tried the same approach as RFC4408 did with RFC5451 and it was deemed insufficient, which is why the authserv-id and cleaning rules were added. That stuff also enables external filters to communicate results inbound in a meaningful way. It's also possible that a contributing factor for the above is that many MTA implementations at the time lacked the capability to prepend header fields apart from Received, as it was the only trace field in use. -MSK From superuser@gmail.com Thu Aug 30 06:56: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 5C2E621F8559 for ; Thu, 30 Aug 2012 06:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RabCawMoLvVW for ; Thu, 30 Aug 2012 06:56: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 1265F21F84B3 for ; Thu, 30 Aug 2012 06:56:18 -0700 (PDT) Received: by lbky2 with SMTP id y2so633746lbk.31 for ; Thu, 30 Aug 2012 06:56:17 -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:content-transfer-encoding; bh=qfxGldaxSzpM2f0v13GFHao6ko6HCPSXS6+wxavjOig=; b=yG8mT4s9XmJvMqPklrUx7sSULuBlRC4czebict1U9ynWmfJFxGz5pen6B1VD/dcHr3 9PK6T3j8YYflSSBTWdtO0wR+INfJilvcTKCn5HPNgPpcaS2Ma8LfhFxPrvwXRUAyXMEY amXxVQSaevYlnx1v6g9bh8WdwJA8H9FitZ9Enekviwro4++87UckBAQttYa1t+LdVsOX mpuhMXHlbg5J37tJfzJH9ZuYw5pFxRLxAStBPxnXcIbGzlDwMgPoaoh1iR6yCQeK+PdC MYHZVkvFOxh7nXtaoNcDpItyDr/OpNlFQEKnm2lKHu64yM4kXQ4jdWEsR8ca3ZZFClXa vd1w== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr1409348lbg.55.1346334976927; Thu, 30 Aug 2012 06:56:16 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:56:16 -0700 (PDT) In-Reply-To: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:56:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 13:56:21 -0000 On Wed, Aug 29, 2012 at 1:42 PM, Arthur Thisell wrote= : > First off, when drafting RFC4408, we were scolded by the DNS folks not to= use things like NXDOMAIN, SERVFAIL, etc. because those are labels for part= icular libraries/APIs, rather than from RFCs. Instead, we should use RCODE= . I don't know if the opinion within the IETF has changed since then, I se= e IANA now has a registry with names for DNS RCODEs. I think we should be = consistent, either use only RCODE numbers, or only use IANA names. I've gotten away with stuff like "NXDOMAIN (DNS RCODE 3)" before, and then use NXDOMAIN in the rest of the document. > The new text that was added to 4408bis is almost duplicate information, e= xcept where it is contradictory to previous text. This, of course, is one= of the dangers of saying the same thing twice, you have to make sure both = places say the same thing. +1. -MSK From agthisell@yahoo.com Thu Aug 30 06:59: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 449E421F84EA for ; Thu, 30 Aug 2012 06:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFMq4+xsFpZj for ; Thu, 30 Aug 2012 06:59:09 -0700 (PDT) Received: from nm13-vm1.bullet.mail.ne1.yahoo.com (nm13-vm1.bullet.mail.ne1.yahoo.com [98.138.91.62]) by ietfa.amsl.com (Postfix) with SMTP id 9282921F84B9 for ; Thu, 30 Aug 2012 06:59:09 -0700 (PDT) Received: from [98.138.90.54] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:59:04 -0000 Received: from [98.138.89.194] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:59:04 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 13:59:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 114995.63643.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 15461 invoked by uid 60001); 30 Aug 2012 13:59:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346335144; bh=UzAP489M0oY1C+T3KhbSHrcscbkdTE0wANI9e68dsfw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=UU9Gp1RRY3aYsooepVb4ZR8o+mjGmSg8XY9Paz4DSjfg5gBE3Ytu9e3gpq+/ETWC1X2CEO5QEkyrTmZsR9wvHLg0G7/59hI2Z8FAldkTc2CKdEFVaz/9AHbKE4Bw92hv9ItYiZhr7kVxRuMD1CdUGztxF1I8oczbAiI94g4IYDY= 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=H42of+/qCDGuMi0VNBDlBHt3PCmBBOrkvODJNUT7X4+jkzwkC9cIwwlndpe3C4c+gZ153yHCn1JPAcjJ5OX9eTCG79CB7sSU7ydR2M1cT3alJAsLSTZk8eYDRY6YseAi05IJwDmmPi2yw1CDuHHdUz3FOwKxhh0c5e/WZlBgH34=; X-YMail-OSG: P7j0O30VM1l97PVFXOr4tMzbm79PagwLZ2lcUHIRDrug16r xq0H3O1plLfaX7a9x2t60ko6wSsQqgIFDT5.op8QWFN4lQJcqELs2TN7i.TJ ZZOmgK2pqe0dA_KHXWY9IDWN7jeWECa6Pbkfi0Kn5Ot96dBC0MNIL1Xk3Doz 0CKiIEHWV9On9alz16zfmOjemIIl7fvYSjAHo7ivCjdAj1MSLQMO036Wp9fE kcM3ZPV20DoZFxywjmfzis.q1gSpbov9_mJ_mFmtrCi7Xpc0xeWQAdNz_SET _ZlHD__wlbYpXUMJwP079Hd9iqD0HpYrAZ9jBi3_L25yQCgvwGxp23jqwJkU xLzjK3c.YP.84cXe9oz1cK29PakBqonMoK4AF0HFr2lXDsdAgGVn_lN6jWtO XGj6A9ENkzr2Z59poWspBvcBvweg43_n.EMeAtT0nQMxdvL8b4YMzlTv_kwr teh314oSMTjqUmrAAhVk- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 06:59:03 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346335143.11277.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 06:59:03 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #35: authorized_spf domain name - Section 9.1.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 13:59:10 -0000 >> The "authorized_spf" is not a valid. > > That's not an LDH name. In the example, that label is used to > demonstrate an SPF trick, and breaking host names' preferred syntax is > a way to hint that it is not a label that already existed for some > other reason. If we are going to give that trick as an example, I would prefer a domain name such as "_spf_authorized", or some name with a leading underscore. I think that makes it clearer that the label is not intended to be used as a host name. Or, maybe a comment on the zone file line explicitly saying the underscore is used to make it not a valid host name. I don't have strong opinions on this though. it could stay as it is. From superuser@gmail.com Thu Aug 30 07:09:29 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 85EE221F8611 for ; Thu, 30 Aug 2012 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZWiqS1m3SP4 for ; Thu, 30 Aug 2012 07:09:29 -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 A651D21F8621 for ; Thu, 30 Aug 2012 07:09:28 -0700 (PDT) Received: by lbky2 with SMTP id y2so645512lbk.31 for ; Thu, 30 Aug 2012 07:09:27 -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=btJPDmXplQL6dg8caaaI+QosdIZotvwO7+wP86t1KhE=; b=WVSzHE+iAQOEF9xolbpqgOE/8fMDz8ZS2WZKY/2K+8CLDcDXDF25tykMy8x5TmRkvh XRZ7jgdv8zTIK0/MjGBns9pQvGUXkxrYPEoHx/GJQkGB17arYyc2siyPy6UJYQp0Wnys QpFgnmyINU8bUcOoQ85Uf/RDwv2Y2mPCjIRe0rCOw1CC2iehYBm3JC5tfT+KWT+dA0GZ q2TvIHQ5zJBoJ8TvHFCBF9KgK5GY1mqVLo3tjJwtjrQb42mNosZfggfxayeuKC2WtRZ/ OOv7AJVzBXiIoJF4DflWk4Rm0LajSC97WnwrcslNEokTFI07E/gGXgZBdbpKjYTli67y d+wQ== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr1403344lbh.85.1346335131793; Thu, 30 Aug 2012 06:58:51 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 06:58:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Aug 2012 06:58:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] DNS record _spf.example.com X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:09:29 -0000 On Thu, Aug 30, 2012 at 6:43 AM, Franck Martin wrote: > I don't know if it has been discussed, but should we encourage the usage of > > _spf.example.com to store the SPF TXT record? > > Many other protocol use that notation. I know it is frown upon by the DNS > people, but the adoption of the SPF record type has proven very slow, and we > should avoid to overload the TXT result of the domain. The best we could do is say "If you don't find an SPF TXT record at the domain, check there" which would double the traffic for every message received that's not publishing a policy at the base domain. I believe such a change violates our charter, unless there's evidence that lots of people are doing this already. And I'm certain the DNS people would hate on it. -MSK From spf2@kitterman.com Thu Aug 30 07:38: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 3922C21F8616 for ; Thu, 30 Aug 2012 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJbv6U+Ofynd for ; Thu, 30 Aug 2012 07:38:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7009D21F8607 for ; Thu, 30 Aug 2012 07:38:45 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8C152D0408A; Thu, 30 Aug 2012 09:38:44 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346337524; bh=2dQumg1L7D5UtX/gy9mzjs3kuh/9jxkXdn7i6Ghwn70=; h=References:In-Reply-To:Subject:From:Date:To:From; b=dpFBj2dRtVlrX+RVmAZ1o3Hkjm5cL1lwqa9qIj2aMaqqPxbcfYBer1HYlibh5dzx2 0YIMbXfjn7uXcFGx0Ggr1njlrzDPp1D2b+6l7Zt7VMnap1ldth8szJtpfz/gHP47S6 h7C+5VadlrWxrDSqcP4q2LXQgi1ywXTEQYJxgDhw= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 147FAD0407E; Thu, 30 Aug 2012 09:38:43 -0500 (CDT) References: <064.d1bab9aeb936b01c76e6fcdd6a048370@tools.ietf.org> <6.2.5.6.2.20120829231332.0a3c4258@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829231332.0a3c4258@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 09:38:39 -0500 To: spfbis@ietf.org Message-ID: <706c6b81-3480-4a60-8ea7-578f2bdbfa37@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #43: New requirement for mx: or ptr records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:38:46 -0000 S Moonesamy wrote: >At 18:17 26-08-2012, spfbis issue tracker wrote: >>#43: New requirement for mx: or ptr records >> >> Message posted by Arthur Thisell on 26 Aug 2012: >> >> in section 4.6.4, there is a new requirement that there must not be >more >> than 10 records for mx: or ptr:. This completely wrong for ptr: >because >> a spammer could choose to send spam from a host with more than 10 >PTR >> records, thus forcing a domain's SPF record to return permerror, >instead >> of fail. If anything, more than 10 PTR records should cause the >ptr: >> mechanism to automatically not-match. It should also be made clear >that >> the %{p} macro is valid no matter how many PTR records are returned. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html In 4408 it's no match which means that it's random in the case where an authorized host has more than 10 if it gets a match or not. The current wording was intended to not leave that unreliability hidden, but to clearly make it deterministically an error. I see your point though. We ought to make these no match, but make it very clear ADMDs can't publish records that use PTR if the authorized hosts exceed the limit. I'm open to suggestions. >One of the RFC 2119 requirements appears in different sections of the >draft. It's better not to restate normative text as it can lead to >different interpretations in case of ambiguity. Where? Scott K From spf2@kitterman.com Thu Aug 30 07:42: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 8D32D21F8491 for ; Thu, 30 Aug 2012 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BDRB7jgP5m4 for ; Thu, 30 Aug 2012 07:42:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBBEE21F8438 for ; Thu, 30 Aug 2012 07:42:48 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 94DEBD0408A; Thu, 30 Aug 2012 09:42:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346337759; bh=yNFfdHLWeFjeHo+e5DQZW15yh3wrV7Aiyl9n2MqI1h4=; h=References:In-Reply-To:Subject:From:Date:To:From; b=Kj4IjfMzWyzGeuWRMmdJ6WZipkJw1gzpA6l15SzAwvwUVAmnBqiNuS4By/ipJ78MW tcGyqxwpZQqsRWPjDAAzyCyaKbg9upYLDDvIAEjq1w/qMAW47rZQfyLY6uEMzx9YKo yCAr4Z4oMWkseVmeeJhROCehZfbFYvVfneGbPRDQ= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 22BE0D0407E; Thu, 30 Aug 2012 09:42:38 -0500 (CDT) References: <064.c1eb79ecf12b16bd719f06e344736199@tools.ietf.org> <6.2.5.6.2.20120829230741.0a3c3fc8@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829230741.0a3c3fc8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 09:42:36 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #35: authorized_spf domain name - Section 9.1.1 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:42:49 -0000 S Moonesamy wrote: >At 18:01 26-08-2012, spfbis issue tracker wrote: >>#35: authorized_spf domain name - Section 9.1.1 >> >> Message posted by Arthur Thisell on 22 Aug 2012: >> >> Last, in section 9.1.1, an A record domain name "authorized_spf" is >used, >> which isn't a valid host name. I'm not sure if that was intentional >or >> not, but most real SPF records would use a real host name. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02199.html > >The "authorized_spf" is not a valid. I changed the underscore to a hyphen locally. Scott K From dhc@dcrocker.net Thu Aug 30 07:50: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 11FD921F8652 for ; Thu, 30 Aug 2012 07:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqfcga7TXoU9 for ; Thu, 30 Aug 2012 07:50:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6721F8622 for ; Thu, 30 Aug 2012 07:50:40 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7UEobND011154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Aug 2012 07:50:38 -0700 Message-ID: <503F7DB5.6060304@dcrocker.net> Date: Thu, 30 Aug 2012 07:50:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 30 Aug 2012 07:50:38 -0700 (PDT) Cc: "spfbis@ietf.org" , Franck Martin Subject: Re: [spfbis] DNS record _spf.example.com 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: Thu, 30 Aug 2012 14:50:44 -0000 On 8/30/2012 6:58 AM, Murray S. Kucherawy wrote: > The best we could do is say "If you don't find an SPF TXT record at > the domain, check there" which would double the traffic for every > message received that's not publishing a policy at the base domain. > > I believe such a change violates our charter, unless there's evidence > that lots of people are doing this already. And I'm certain the DNS > people would hate on it. The concerns for TXT RR collision would disappear, if a ._spf naming convention had been specified. But it wasn't. And by my reading of the charter, adding that convention is /very/ far outside our current charter. I also think that migrating the installed base would be extremely difficult, at this point. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From agthisell@yahoo.com Thu Aug 30 07:54: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 4A48C21F8587 for ; Thu, 30 Aug 2012 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01TDxwjaZ1od for ; Thu, 30 Aug 2012 07:53:59 -0700 (PDT) Received: from nm14.bullet.mail.ne1.yahoo.com (nm14.bullet.mail.ne1.yahoo.com [98.138.90.77]) by ietfa.amsl.com (Postfix) with SMTP id 1B04721F8597 for ; Thu, 30 Aug 2012 07:53:57 -0700 (PDT) Received: from [98.138.90.49] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:53:52 -0000 Received: from [98.138.226.162] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:53:52 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:53:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 607471.36259.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 4225 invoked by uid 60001); 30 Aug 2012 14:53:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346338432; bh=dXw0HyMygedRqXxk3F+QviCqG9mWA0UD8dS6BJUxbX0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=v7lYqs9Yz1tm7+RO1JiAyr5VB7c3yhgxDdv/iXhzB9U7dAtNILuv+cx0OwklWZtHB9HjNlx5mgjPagrH4Yhqyz6hvXbLhB8LNc6BbquhmA/aW1k/ILlCF1n/Kab9vAS+a11rooEuyGmQEDBmc0rtsX6g6UuJk1NyZ54h8f7Wqx4= 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=nmuU7ENgZs/rooa/eK1LeVza4Wk6L2lCe7dlYtlCUXl7iDqHEOUPYE1mG62sI4ICBSXorQJXT1H1KbfZftvh1NpFEhgcEgsJ6ULVWMAeiHPkkiAONixvfMgHpgfYXQWBc3U36+k0l8y3XE0xsVaNCpkYhFDu4Chyau543HyoJXE=; X-YMail-OSG: aKgA1J4VM1n0ti.yuvzTHf3l.q90mI60eg6456bFv_pGhI. B5Xm_sMdcSV7TSTqHSqZTeY0dNU5kTQbKs3Kw0KE3K8MgUuyw9RJKAFILe5k farrmk2RhOtX1mi2UNbMCcEf0c9.kCsLwXqKjtj5Rmoi5YU0jLnRZMaZSpZs q9__bjqLOZBXK2KqpSv3fgNKiZUH.CndL55ihzRGYczQqBTaa0pJYFmGKnPO ykbyrPeGodcphFRl8IPx0sPW6HjvL7B_kxi6Ppe4UbQj1PLga6lVXdq9tjVi LGRx_14qWhv2PvjHxm5zdJNARBQIIC4rIz5aJJrLU_wOm6KEzwTpUEyUhlhe yJIppUk.9n2Pag4S55itHukZ.WaFWqq6s9Hp1qSXsFBvCosXMXQt46ChW.SS M9pIQ8K8vcobxHUhCK7Hy9ybhs5d6A3l1Zd76bsgqjQ6s6DSyBv8hPFi.Epy TCXZMFOJdV8X1bq8Yszw- Received: from [71.61.133.134] by web125402.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 07:53:52 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346338432.84595.YahooMailClassic@web125402.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 07:53:52 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #43/#44: New requirement for mx: or ptr records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:54:00 -0000 >> in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the new >> requirement that there must not be more than 10 records that was added to >> section 4.6.4 > My reading of the requirement in Section 5.5 is that it has to do with the > number of DNS queries and not the number of DNS records. Things got a little garbled in the translation from my review of bis-06 into tickets, which is probably my fault. Ticket #44 does not contain a complete description of the problem, it is really part of #43. Ticket #43 doesn't contain everything either, it leaves out that I think that the new text should be moved from 4.6.4 to the appropriate sections of 5.X. RFC 4408's documentation on how the ptr: mechanism works does not depend on how many PTR records there are, so you are right, section 5.3 just talks about PTR lookups. However, the new text in 4.6.4 radically changes the way the ptr: mechanism works. I think it would be much clearer if all the description of out ptr: works is kept in one section. Right now, if an in-addr zone for an IP address has more than 10 PTR records, ptr: will give inconsistent results depending on what order the PTR records are returned. It might find a matching PTR record, or it might not match. With the new text, if there are more than 10 PTR records, it is supposed to raise a permerror, in cases were RFC 4408 would never raise an error. Indeed, RFC 4408 is designed so that ptr: never even raises a temperror, it just doesn't match in those cases. The %{p} macro is defined in RFC 4408 to always give a result, but the new text in 4.6.4 means it could give an error. The fact that RFC 4408 doesn't guarantee consistent results for ptr:/%{p} is one of the problems with ptr:/%{p}. The sender, however, has control over the sending IP address, so you don't want to let the sender to be able to force a permerror instead of a fail. So, maybe changing how ptr: works so that it always doesn't match if there are more than 10 PTR records would be an improvement. Changing how %{p} works, however, is probably not a good idea. Changing mx: to give a permerror if there are too many MX records is also probably an improvement. From spf2@kitterman.com Thu Aug 30 07:54: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 7DBE721F8597 for ; Thu, 30 Aug 2012 07:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DbTWPPsuVoU for ; Thu, 30 Aug 2012 07:54:56 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7B21F8587 for ; Thu, 30 Aug 2012 07:54:56 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ECC22D0408A; Thu, 30 Aug 2012 09:54:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346338496; bh=WBtVSZTtJZDI6VkdQCUpJp3BtOBPODYxQ1L/D94dGPk=; h=References:In-Reply-To:Subject:From:Date:To:From; b=Ue0t2PAhnv0u4tAz6fzzFjvHl3tOt8KTjT7pUwxSzyhiAJSt8ErKrCDgtz+uZM0HB IyqB8wBAuSGkKIX9ZFTsrp8s46327K6RxZ91EWqx9XCp+3FPRh1JyMpHa1ncHbUz4r yM+d1pcpepoW82cAzJG4WFnw2LTxlrUb/jiS7VIE= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7A1C0D0407E; Thu, 30 Aug 2012 09:54:55 -0500 (CDT) References: <064.0f4f3f81bd864018584c277c99de0e98@tools.ietf.org> <6.2.5.6.2.20120829232016.0a3c4778@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829232016.0a3c4778@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 09:54:53 -0500 To: spfbis@ietf.org Message-ID: <5678d3ee-c299-42cc-bc82-41cb9040f8af@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #44: Section 5.4 does not mention requirement in section 4.6.4 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:54:57 -0000 S Moonesamy wrote: >At 18:23 26-08-2012, spfbis issue tracker wrote: >>#44: Section 5.4 does not mention requirement in section 4.6.4 >> >> Message posted by Arthur Thisell on 26 Aug 2012: >> >> in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the >new >> requirement that there must not be more than 10 records that was >added to >> section 4.6.4 >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > >My reading of the requirement in Section 5.5 is that it has to do >with the number of DNS queries and not the number of DNS records. For 5.5, I think it's fine since we're going to change 4.6.4. For 5.4, it needs to point at 4.6.4 instead of section 10 it also needs to mention the permerror. Fixed locally. Scott K From sklist@kitterman.com Thu Aug 30 07:50: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 155D121F8610 for ; Thu, 30 Aug 2012 07:50: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q2yJbPoBA0F for ; Thu, 30 Aug 2012 07:50:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F221F8639 for ; Thu, 30 Aug 2012 07:50:41 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 52691D0408A; Thu, 30 Aug 2012 09:50:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346338240; bh=tDWKseAdPvNEjBZxOsJU9453gvw6/Kq/AaR/bOcPnT4=; h=References:In-Reply-To:Subject:From:Date:To:From; b=QENB6msl3lz11lB4yFQ3PRd0h8Zy+IkP/hb6hMMYaDZHBNMBllJNHypT88yIrhfyu Fo4bph+i4cDQf1qk/BHdDURhrJ56xGB5ACmAFPZ0a6auFVW+9A8xoUyT4SA27riJpH HnahBeaD7vBjQRQ0X8cHX09WhBJPtRS4dTNW4uOg= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DBD08D0407E; Thu, 30 Aug 2012 09:50:39 -0500 (CDT) References: <064.0f4f3f81bd864018584c277c99de0e98@tools.ietf.org> <6.2.5.6.2.20120829232016.0a3c4778@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120829232016.0a3c4778@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 09:50:34 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 30 Aug 2012 07:56:21 -0700 Subject: Re: [spfbis] #44: Section 5.4 does not mention requirement in section 4.6.4 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:50:44 -0000 S Moonesamy wrote: >At 18:23 26-08-2012, spfbis issue tracker wrote: >>#44: Section 5.4 does not mention requirement in section 4.6.4 >> >> Message posted by Arthur Thisell on 26 Aug 2012: >> >> in section 5.4 (MX) and section 5.5 (PTR), no mention is made of the >new >> requirement that there must not be more than 10 records that was >added to >> section 4.6.4 >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > >My reading of the requirement in Section 5.5 is that it has to do >with the number of DNS queries and not the number of DNS records. For 5.5, I think it's fine since we're going to change 4.6.4. For 5.4, it needs to point at 4.6.4 instead of section 10 it also needs to mention the permerror. Fixed locally. Scott K From spf2@kitterman.com Thu Aug 30 07:58: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 636FA21F8606 for ; Thu, 30 Aug 2012 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7LOHXcqOCd7 for ; Thu, 30 Aug 2012 07:58:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3F21F85B4 for ; Thu, 30 Aug 2012 07:58:45 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E7DE4D0408A; Thu, 30 Aug 2012 09:58:44 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346338725; bh=2Ki8/OIlf62s/LHLVXruN7z2LLHWHrAWBaf/lzXTe3s=; h=References:In-Reply-To:Subject:From:Date:To:From; b=SCJL06DtSl7uK10rVwbRZsLUZ3pnFH3W4RWVhA3+WQgmPNcYFA7JzIAXtcUz9erFW dI/pf2AxhxrP9TKpQAVGVhy4M7pYYVaC2diQQvjo5Yaxg3xr207jZGWRm2skSRUhA2 gaOy97XXogsEPETr5uzKnRFsmRSXcwrHgX1rYTmE= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6F1A2D0407E; Thu, 30 Aug 2012 09:58:44 -0500 (CDT) References: <1346333910.47792.YahooMailClassic@web125404.mail.ne1.yahoo.com> User-Agent: K-9 Mail for Android In-Reply-To: <1346333910.47792.YahooMailClassic@web125404.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 09:58:42 -0500 To: spfbis@ietf.org Message-ID: <5341fe2e-7551-4a76-a7d2-2f8723acb86b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?=2322=3A_RFC_4408=3A_Section_2=2E5=2E7_PermErr?= =?utf-8?q?or_on_invalid=09domains_after_macro_expansion?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:58:46 -0000 Arthur Thisell wrote: >I don't see a problem with some malformed domain names being turned >into permerrors, but we need to be careful not to stomp on Section 8 >which says, in part: > > When the result of macro expansion is used in a domain name query, if > the expanded domain name exceeds 253 characters (the maximum length > of a domain name), the left side is truncated to fit, by removing > successive domain labels (and their following dots) until the total > length does not exceed 253 characters. > >Some malformed domain names are also covered in section 4.3: > > If the is malformed (e.g. label longer than 63 characters, > zero-length label not at the end, etc.) or is not a fully qualified > domain name, or if the DNS lookup returns "domain does not exist" > (RCODE 3), check_host() immediately returns the result "none". > > >So, I guess that means that null labels and labels longer than 63 >octets should be permerrors? I think it makes sense. Scott K From vesely@tana.it Thu Aug 30 07:59: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 8485621F851A for ; Thu, 30 Aug 2012 07:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gNsvhNlFbo3 for ; Thu, 30 Aug 2012 07:58:59 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C021F8570 for ; Thu, 30 Aug 2012 07:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346338738; bh=YkyT1RuYvmXEVF7CRTFlNzdBXtUxZut13FRxaZXlqJ0=; l=618; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eTHYgy/uHbBheCCjDLkWQQnJhc/JCHk2StQeFx/UarHt2DvmRT2te4WSmzP1XSqvq eSliQMYR4X5HCW0pnOk7VQ0OWUVBZ1J4b8U77CTK5zM8WGdkmeciShpaE6LzGWwd+7 CBq0Cwt9lQ6t3laOFG2OjhhRyDrvFXEQ824dQMVU= Received: from [109.115.175.226] ([109.115.175.226]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 16:58:57 +0200 id 00000000005DC033.00000000503F7FB2.0000436E Message-ID: <503F7FAE.7080100@tana.it> Date: Thu, 30 Aug 2012 16:58:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] DNS record _spf.example.com X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:59:00 -0000 On Thu 30/Aug/2012 15:43:32 +0200 Franck Martin wrote: > > I don't know if it has been discussed, but should we encourage the > usage of > > _spf.example.com to store the SPF TXT record? > > Many other protocol use that notation. I know it is frown upon by the > DNS people, but the adoption of the SPF record type has proven very > slow, and we should avoid to overload the TXT result of the domain. +1, it is exemplified as the target for "redirect". I guess it is not shown for "include" because that example has two such mechanisms, and adding "_spf." (5 chars) twice wouldn't fit on a single line. From agthisell@yahoo.com Thu Aug 30 07:59: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 0FC1721F8610 for ; Thu, 30 Aug 2012 07:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odWcD75IoV+0 for ; Thu, 30 Aug 2012 07:59:12 -0700 (PDT) Received: from nm5.bullet.mail.ne1.yahoo.com (nm5.bullet.mail.ne1.yahoo.com [98.138.90.68]) by ietfa.amsl.com (Postfix) with SMTP id 7898A21F860B for ; Thu, 30 Aug 2012 07:59:12 -0700 (PDT) Received: from [98.138.90.55] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:59:07 -0000 Received: from [98.138.87.8] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:59:07 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 14:59:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 633628.65207.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 56899 invoked by uid 60001); 30 Aug 2012 14:59:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346338747; bh=Y1msf57gA4e4u994upoHhAP8YXMX+/jMINfn7fAmZc4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=5sa7POI+nDGosuWklqXs2G8K9HFRSiu2g860Sry8P7b01M+PfqD7POoE+zUOk2vO+FUl0jRN2Flt3LCbbfvu3gkyg1H2fV1jKKg1EcU9NruRXrE9rYhs+xyjg4I2MHYjYWUKHViLipF84Qr+1zCr7JMeHCmDq1uzBMZbiIXvJUk= 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=Nei8aoEtf3HQM68OspR+lj6Pyu3th+4d41geTFFwLN5RqdXq5KhHN/WXXVTXRJtT1Z0+A2R71P9ZnLMPAZ69fIgiUU9f7T0eGndhVyjPVTLaV/GX/j8ma2oSEalr0zEC5tV2eqL7TQ50J8FmeOQs3GMUr0znVfEaUU413iBqIuw=; X-YMail-OSG: L8TjPNgVM1mrjiYDHd5GBee5f5AL_RIU7wRwqt9_oludAE3 xvLsFcozyVs.79Op_YWiFy7aR5CCH591U3rKgeZ6fksF0QlgaSqwSfyjsi_D NJk8mrgxpPqioiZkXmeOcNiz9k_WZGcf7GvhMLBNtJ2eq6zj7__1ednZ6_Uo USCdwCqKES6hd84xb2wJJlCKeuyI0Jzh_kwUIHHfNfsqIu1BaGn4bZNxqRJB R.IP1.1jRFeOLqvZRzPXgi95yLJdjV1Qi8zptNmry1gSLJ0sEfPVgjy7JujT 3_sdCfMRbmSOByNF5lg.Ya7Z7JCjzhSYnl1NYyG9xhBj_vOSYdIZKf4RKWwG 4JCLXyNrqRhnWnz1UZTiC07tkYzC5EXEsZsh6HKTHM5aYDHx36aQ5W0bVz9H d8emTE4DWk1GX9Da29VDaZQVdC0oDKwaFfVBrIlu935G5XeZRuDHA1dJoW7. fR_PuF6aa4MbUaiNasPA- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 07:59:07 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 07:59:07 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 14:59:13 -0000 > Received fields are not explicitly carrying security information, > merely trace data, so RFC5322 didn't need to point this out in > Security Considerations. Uh, yes they did. Forging Received fields is a very common practice by spammers to mislead people (and poorly written anti-spam programs) into thinking that the email ok. Forged Received fields, and depending on the order of those fields, is almost exactly like Received-SPF fields. From sm@elandsys.com Thu Aug 30 08:02: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 6FE1521F85B4 for ; Thu, 30 Aug 2012 08:02:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx3GV15c31sj for ; Thu, 30 Aug 2012 08:02: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 B3E6C21F853F for ; Thu, 30 Aug 2012 08:02:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7UF1qJ0006531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 08:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346338923; bh=RckKQ4R4o7UvgyendHZXCxzizd2ecvdu54YfIBCxqbE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=CarMKiZESUY7EdrFpvAsyoSB7n1icuDoLR++5SAkmgo1gRuBxETxmpdZU7l55U+V8 HSt0GV4eoYP7uPK0VPxuP4j5r8bGC4M/pD4pg0WqyCznVW78FzlY7DVLUmxnvSNqfF V2esuqZe+CvLuL8TLFMJ12N129M5FJWeNHeIyrvo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346338923; i=@elandsys.com; bh=RckKQ4R4o7UvgyendHZXCxzizd2ecvdu54YfIBCxqbE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=u0/e52Gh4nsYTgPtsLebOeUiXYYSCeMoEt2DGXaR387VqcGI8YQCLDytPZbdSk9+O K/ghUdoEg+mXBSQ60V3r53m3xrDATnFf/zkSHU3dCvElU/+3nWm4Q+mjDMG9xW5Bry 82EAC6UHHPM4YzNqaipRkA0Wi+7HEoZ/YiCXtlyo= Message-Id: <6.2.5.6.2.20120830063540.0a479b38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Aug 2012 07:47:11 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <064.b929c2ab78ae209d849d0d537bbf8af0@tools.ietf.org> <6.2.5.6.2.20120828224800.0a64c778@elandnews.com> <1428962.6IPKQEtNWL@scott-latitude-e6320> <6.2.5.6.2.20120829215317.0a841b78@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] The bottom line (was: #48: Section 8.1 - macro defs) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 15:02:06 -0000 At 06:13 30-08-2012, Scott Kitterman wrote: >So? If you defer review until after WGLC, then we may end up with a >lot of new issues that need to be addressed late in the process. As >efficient as that may be for you, it seems highly suboptimal for >the goal of finishing the work of the group in a timely manner. The WG can end up with a lot of new issues after the WGLC. The goal is for the WG to complete the work in a timely manner. This entails getting timely reviews, identifying issues and addressing them. A lot of what I do is not efficient for me. I have commented on what could become an issue later in the process. The bottom line is that it is up to WG participants to do the work. This WG took on the task to write a Proposed Standard. It is expected that the WG has the expertise to do the work and it will act in a responsible manner. I understand that the work is not easy. I understand that there can be disagreements. That's part of the work whether I like it or not. Regards, S. Moonesamy From spf2@kitterman.com Thu Aug 30 08:04: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 94CAD21F8604 for ; Thu, 30 Aug 2012 08:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHW-idyHdnjX for ; Thu, 30 Aug 2012 08:04:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6936021F860B for ; Thu, 30 Aug 2012 08:04:48 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B8FF7D0408A; Thu, 30 Aug 2012 10:04:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346339087; bh=7H8wXn2rO4LG+Egnc3hy/WeYsnEbd9i7DU33zKI8Xws=; h=References:In-Reply-To:Subject:From:Date:To:From; b=muuZUr/g68RrHgFNBV5kk1dLeFWktd/wmymwEdjHuBcdRpEpznQXHfvbeHptAV1ZR 6VBfHExPC2sBkGxs/ZsaDJinwkai192xn4D1WAnn8HP73Scp8IwKAo4KcDl3kbiwqM kyoGh+BDLc0PdpbxaF73fopFSl/gOkp9ePhH3R0Y= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4655ED0407E; Thu, 30 Aug 2012 10:04:47 -0500 (CDT) References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5345259.50xTJaGO9G@scott-latitude-e6320> <503F486F.6060405@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <503F486F.6060405@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 10:04:40 -0500 To: spfbis@ietf.org Message-ID: <5848c7ce-5396-42d0-84cf-6ee81dc0466c@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:04:49 -0000 Alessandro Vesely wrote: >On Thu 30/Aug/2012 06:13:03 +0200 Scott Kitterman wrote: >> On Wednesday, August 29, 2012 01:42:08 PM Arthur Thisell wrote: >>>> >>>> How about non-DNS errors, e.g. database unavailable and similar? >>> >>> One of my there comments was section 2.5.6 (temperror) seemed to >>> imply that only DNS errors could generate it. This is wrong, >>> other local temporary errors can cause it also. Dababases being >>> unavailable, out of memory, out of disk space, etc. can also use >>> temperror. >> >> Every single reference to TempError in RFC 4408 is DNS related. >> The addition of the parenthetical (DNS) was meant to clarify this. >> I don't think that having every "my system is broken" condition >> return an SPF result of temperror is consistent with general usage >> or a good idea. For example, if you screw up postfix policy >> configuration and get into a non-working condition, postfix will >> reply is 451 System Configuration Issue (or similar, I'm doing that >> from memory) until it's fixed. >> >> If broken system is an SPF temperror, I can see all kinds of >> unrelated failures tagged as SPF failures. This has no benefit I >> can see and could certainly cause confusion. > >I see your point. However, DNS timeout will always be dubious, as it >can depend on an outage or misconfiguration at the verifier's, at the >publisher's, or anywhere in between. I don't think an out-of-memory >error can be caused by names longer than 63, but, in principle, I >neither think we can limit local errors due to SPF to DNS timeouts >exclusively. > >What is the reason to deny an SPF qualifier to a local error occurring >during SPF verification? > >If the verifier replies 4xx, or crashes without replying, the SPF >qualification doesn't matter. OTOH, if the server recovers from the >error after the verification failed, it may be able and willing to >accept the message at hand. I'd assume it writes its trace header >field also in such cases. What SPF result should it report? If it can't complete the evaluation, then there can't be an SPF result. Scott K From spf2@kitterman.com Thu Aug 30 08:08: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 9952321F84B2 for ; Thu, 30 Aug 2012 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb472+qRHA0N for ; Thu, 30 Aug 2012 08:08:10 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC90821F84AF for ; Thu, 30 Aug 2012 08:08:09 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 14EEAD0408A; Thu, 30 Aug 2012 10:08:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346339289; bh=BDWN5XLn0Tp/mgqSzJ3Xmx6X6Rt+Qn8CNu0GaQpek/k=; h=References:In-Reply-To:Subject:From:Date:To:From; b=gGFLOdDoQsKNgss0RRrPdeaMPcAYhgruWXWgxCyJe4BVo7r7oAmZkPATrO06L1HhP SG1Mb8XWuKPh9lBNHo3Wm/MQc80GweA85XuvaYaTXY7bXXLFknbmi0/FivMGi198Ok /0v4raeOZvYaIfds65qVoCg3gV73exNi2F0skUhg= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6FDB4D0407E; Thu, 30 Aug 2012 10:08:08 -0500 (CDT) References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <20120830054957.GB59367@mx1.yitter.info> <503F4887.4060207@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <503F4887.4060207@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 10:08:01 -0500 To: spfbis@ietf.org Message-ID: <6241c6ab-dd56-422e-b11a-51084392e4df@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:08:10 -0000 Alessandro Vesely wrote: >On Thu 30/Aug/2012 07:49:58 +0200 Andrew Sullivan wrote: No hat. >> On Wed, Aug 29, 2012 at 01:42:08PM -0700, Arthur Thisell wrote: >>> First off, when drafting RFC4408, we were scolded by the DNS >>> folks not to use things like NXDOMAIN, SERVFAIL, etc. because >>> those are labels for particular libraries/APIs, rather than from >>> RFCs. Instead, we should use RCODE. I don't know if the opinion >>> within the IETF has changed since then, I see IANA now has a >>> registry with names for DNS RCODEs. I think we should be >>> consistent, either use only RCODE numbers, or only use IANA >>> names. >> >> Error codes _always_ had names. My personal preference has always >> been to include the RCODE and, on first use, the symbolic name as >> well. I'm also happy if people use the symbolic name, with the >> RCODE on first use. But I think both need to be in the document at >> first use, no matter what. > >Is there a better place than 1.3. *Terminology* ? > >In http://www.iana.org/assignments/dns-parameters I find, for example, >that decimal 3, name "NXDomain" means Non-Existent Domain and its >reference is [RFC1035]. However, RFC 1035 does not contain the >symbolic name string. RFC 2136 does. We've survived half a decade with just the rcodes. The appendix won't get published as part of 4408bis. Can we just drop this? Scott K From spf2@kitterman.com Thu Aug 30 08:16: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 D1AB121F851A for ; Thu, 30 Aug 2012 08:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxxST60ctPS6 for ; Thu, 30 Aug 2012 08:16:23 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA92821F8514 for ; Thu, 30 Aug 2012 08:16:22 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0D153D0408A; Thu, 30 Aug 2012 10:16:22 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346339782; bh=5VpBYck0OE6mPvvboK9rNoUCcK7M+p7J7TUGDN0QA9g=; h=References:In-Reply-To:Subject:From:Date:To:From; b=Vkd04BQDMOmxveoFZScHuuZ3A0E8cOby/BsI/52HQD9EjyZzyPZY2vLQbhRrHdos+ 93XK0vdhK/BfCvndthNydzclcD1XeGrWEXfO9FHfJF/Um59f0mKtNstvD6t8aUTGzt LbmK/RRIKWeoQ06pSCOyo8OZFBlq3AnYl5b/lQ+w= Received: from [IPV6:2600:1004:b023:52a:611a:fbb2:a72c:63b6] (unknown [IPv6:2600:1004:b023:52a:611a:fbb2:a72c:63b6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 40BB9D04087; Thu, 30 Aug 2012 10:16:21 -0500 (CDT) References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 10:16:10 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 15:16:24 -0000 "Murray S. Kucherawy" wrote: >On Thu, Aug 23, 2012 at 9:06 AM, S Moonesamy >wrote: >>> Suggested fix (Variant 2): >>> >>> The last sentence in the Permerror definition is misleading. A >>> syntactically malformed can be also handled as no >match. >>> The >>> specification should say: >>> >>> Be aware that it is also possible that this result is generated >by >>> certain SPF clients due to the input arguments having an unexpected >>> format; see Section 4.8. >>> >>> At the end of Section 4.8 add: >>> >>> Note: Historically, this document has made no provisions for >how to >>> handle s, or macro-expansions thereof, that are >>> syntactically >>> invalid per [RFC1035], such as names with empty labels (e.g., >>> "foo..example.com") or overlong labels (more than 63 characters). >Some >>> implementations choose to treat as a no-match mechanisms, and >ignore >>> modifiers, with such names, whereas others throw a "PermError" >exception. >>> The outcome for an unexpected without macros might >even >>> differ from that for an unexpected after macro >expansion. > >I prefer this solution, with some corrections to the final paragraph >(get rid of "throw" as has been done elsewhere, correct "to treat as >a", and give an example of what the last sentence is talking about). If I understand this correctly, you're favoring documenting the current ambiguity, but not resolving it? Scott K From vesely@tana.it Thu Aug 30 08:56: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 2AD7D21F8567 for ; Thu, 30 Aug 2012 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.692 X-Spam-Level: X-Spam-Status: No, score=-4.692 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udafqMWkAKEa for ; Thu, 30 Aug 2012 08:56:58 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1131C21F8532 for ; Thu, 30 Aug 2012 08:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346342216; bh=/i6+i5mpX1xft16NXAhdh4wC2B13vfaRZO4QynHt3zI=; l=2920; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gQdwLbaCZhv23sdkYXJr0qc4odnaCE6687ekOSBT+g1mMVTJGaLMcQHHBBfPVVfbp ZqAeIu/bCQMbYHJTJO2AaTWUx4MJFtWaH8HMr5JJEm+UyzcQkNicROoHZN331OZtgv smhmTO8lpNDdkMx0jM8HqjQ4xCmHUeOa0RSP1tqE= Received: from [109.115.175.226] ([109.115.175.226]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 30 Aug 2012 17:56:55 +0200 id 00000000005DC039.00000000503F8D48.000050F4 Message-ID: <503F8D42.3020109@tana.it> Date: Thu, 30 Aug 2012 17:56:50 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5345259.50xTJaGO9G@scott-latitude-e6320> <503F486F.6060405@tana.it> <5848c7ce-5396-42d0-84cf-6ee81dc0466c@email.android.com> In-Reply-To: <5848c7ce-5396-42d0-84cf-6ee81dc0466c@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:56:59 -0000 On Thu 30/Aug/2012 17:04:40 +0200 Scott Kitterman wrote: > Alessandro Vesely wrote: >> On Thu 30/Aug/2012 06:13:03 +0200 Scott Kitterman wrote: >>> On Wednesday, August 29, 2012 01:42:08 PM Arthur Thisell wrote: >>>>> >>>>> How about non-DNS errors, e.g. database unavailable and similar? >>>> >>>> One of my there comments was section 2.5.6 (temperror) seemed to >>>> imply that only DNS errors could generate it. This is wrong, >>>> other local temporary errors can cause it also. Dababases being >>>> unavailable, out of memory, out of disk space, etc. can also use >>>> temperror. >>> >>> Every single reference to TempError in RFC 4408 is DNS related. >>> The addition of the parenthetical (DNS) was meant to clarify this. >>> I don't think that having every "my system is broken" condition >>> return an SPF result of temperror is consistent with general usage >>> or a good idea. For example, if you screw up postfix policy >>> configuration and get into a non-working condition, postfix will >>> reply is 451 System Configuration Issue (or similar, I'm doing that >>> from memory) until it's fixed. >>> >>> If broken system is an SPF temperror, I can see all kinds of >>> unrelated failures tagged as SPF failures. This has no benefit I >>> can see and could certainly cause confusion. >> >> I see your point. However, DNS timeout will always be dubious, as it >> can depend on an outage or misconfiguration at the verifier's, at the >> publisher's, or anywhere in between. I don't think an out-of-memory >> error can be caused by names longer than 63, but, in principle, I >> neither think we can limit local errors due to SPF to DNS timeouts >> exclusively. >> >> What is the reason to deny an SPF qualifier to a local error occurring >> during SPF verification? >> >> If the verifier replies 4xx, or crashes without replying, the SPF >> qualification doesn't matter. OTOH, if the server recovers from the >> error after the verification failed, it may be able and willing to >> accept the message at hand. I'd assume it writes its trace header >> field also in such cases. What SPF result should it report? > > If it can't complete the evaluation, then there can't be an SPF result. Hm... omitting the trace field entirely should mean that the sender was whitelisted from SPF checking (e.g. submission.) So, the server might want to write: Received-SPF: none (can't complete the evaluation) That conflicts slightly with Section 2.5.1. Then, one would expect no neat demarcation between the above and: Received-SPF: temperror (the DNS made a boo boo) For comparison, RFC 5451 doesn't say "a transient (DNS) error" but "some error that is likely transient in nature, such as a temporary inability to retrieve a policy record from DNS." IMHO, the latter includes local malfunction, albeit it indicates the DNS as a typical case. From sm@elandsys.com Thu Aug 30 11:20: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 BC0BE21F8594 for ; Thu, 30 Aug 2012 11:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpA4ZW5GqxdP for ; Thu, 30 Aug 2012 11:20:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD36721F8585 for ; Thu, 30 Aug 2012 11:20:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.178]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7UIKdHR014302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 11:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346350850; bh=eFOzTwFKRREbA0c45pj2OviMkojYh0vm0/k1jqRjT/Y=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=G+pQXt+O8//tFfrqqtgx42s3qc5CemAioxRIZukRrZt2MFOMx9rz6+8g9ShY27G0j bVghbU0jdfoyZYmODtPib++kamnNJsQ961InjHVDTz+8UZDblZF7ni/TjwFOkhCmOY t/zeSytvbA+YkbA77Uz/4qVW8aexoBEmw5RSVsKo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346350850; i=@elandsys.com; bh=eFOzTwFKRREbA0c45pj2OviMkojYh0vm0/k1jqRjT/Y=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=0gifw61RAV+uyjeGPP2WG9vKa5t6BM4dMTQNmT2qG42ZEk9cX8dXz6+LXLhULaKyr cgiYt9LG0rV/wl0Jei1eZ90RxPk1459uDRYBpg5T4gJ0cg8Djw1VgS1xFqjOBwP1/9 G8qOZq10Qdd9uyTngD91K+R/yqG2+w6+pCEANckk= Message-Id: <6.2.5.6.2.20120830100555.09761cd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Aug 2012 11:08:14 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E0039280F1346@exch-mbx901.corp.cl oudmark.com> References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@isdg.net> <10035218.VxSKd6zvrx@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280F1346@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Deployment guide X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 18:20:53 -0000 At 14:35 13-04-2012, Murray S. Kucherawy wrote: >Either way, this is not work we should actually plan on starting >until after RFC4408bis is basically done. But I think asking this >question now and collecting ideas will help decide (a) what goes >into RFC4408bis, and (b) whether or not we should seek to add this >as a deliverable when/if we re-charter. Several months ago there was a question about whether to have a deployment guide or to have some notes as part of an appendix. Dave Crocker suggested writing the text and then figuring out where it should go and the Chair agreed. I suggest moving the text from Section 9 into an appendix. The WG can discuss what to do about the appendix once all the issues have been addressed. Regards, S. Moonesamy From spf2@kitterman.com Thu Aug 30 11:30:29 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 2ECE021F85C3 for ; Thu, 30 Aug 2012 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sApK3KhX2-n7 for ; Thu, 30 Aug 2012 11:30:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id B506B21F85C6 for ; Thu, 30 Aug 2012 11:30:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D742BD0408A; Thu, 30 Aug 2012 13:30:17 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346351417; bh=XNVjMDXAdilPSB3ppOHlQIkEB9zEsuCGAIv2uQgZSIM=; h=References:In-Reply-To:Subject:From:Date:To:From; b=MXmcq883kLkbcLBu4XhNOslfX3PK4T/rxz6iYwfgabX3swwcNo9wIUw2aUnrKDsj7 WnuNzQU3nunY3xf4J19hmuKVLPH9b1mVGh03gG6+h9uCiTQb/laynPCOrQeIEPvbOG qlByL062oSz6isvZ0grkxAVOX1gnX/9RaUsXam+M= Received: from [10.226.137.99] (56.sub-174-252-97.myvzw.com [174.252.97.56]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 30078D04087; Thu, 30 Aug 2012 13:30:16 -0500 (CDT) References: <20120324090349.15462.qmail@joyce.lan> <2230111.fUdp390bGt@scott-latitude-e6320> <4F8884A7.6080404@isdg.net> <10035218.VxSKd6zvrx@scott-latitude-e6320> <9452079D1A51524AA5749AD23E0039280F1346@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120830100555.09761cd0@resistor.net> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120830100555.09761cd0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 14:30:14 -0400 To: spfbis@ietf.org Message-ID: <5a1418c7-e88a-4543-b155-bd26d680b334@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Deployment guide X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 18:30:29 -0000 S Moonesamy wrote: >At 14:35 13-04-2012, Murray S. Kucherawy wrote: >>Either way, this is not work we should actually plan on starting >>until after RFC4408bis is basically done. But I think asking this >>question now and collecting ideas will help decide (a) what goes >>into RFC4408bis, and (b) whether or not we should seek to add this >>as a deliverable when/if we re-charter. > >Several months ago there was a question about whether to have a >deployment guide or to have some notes as part of an appendix. Dave >Crocker suggested writing the text and then figuring out where it >should go and the Chair agreed. I suggest moving the text from >Section 9 into an appendix. The WG can discuss what to do about the >appendix once all the issues have been addressed. I don't think this is a good idea. Scott K From superuser@gmail.com Thu Aug 30 12:22: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 08FA021F84A7 for ; Thu, 30 Aug 2012 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97ORw99wwfMp for ; Thu, 30 Aug 2012 12:22:57 -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 6F3EF21F842B for ; Thu, 30 Aug 2012 12:22:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4554729obb.31 for ; Thu, 30 Aug 2012 12:22: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:content-transfer-encoding; bh=bm88ksFXZfvnXsKPTAzq9esNRxMO8V07eME2NMeO58Y=; b=ARDgaPoTYgm95rLiLW6wXzAgML/IEM8mIewPhG3LTlYNCDTiYR4S9HAbCI9OJ1IhmM t1r2fiSMUM3kGfn+qieNv98uawnd3yTtslpJhMEX8OscqNDaWWL9/PyNdaPHZ/wAfeR/ rYbIzi2sy/2w4paGdHseMUZseFOtlybOKRZvTDsx5Ley4IysE3tQJDWYOhJlG3bCmdoH mv6uBjPb58fETYc7rjQpQJLQ4c6kHU0K2YnF+mHoLtT1Zv883SVkRZuZinNAnh6pE01K OkD0p6kuHgSYlsFzZbPaylZnX1Xv0HWj6InTbABoYtLD4bRKm2O0XT1cQVYRdXOjga/w DYxA== MIME-Version: 1.0 Received: by 10.182.72.9 with SMTP id z9mr5826197obu.5.1346354577113; Thu, 30 Aug 2012 12:22:57 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 30 Aug 2012 12:22:56 -0700 (PDT) In-Reply-To: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 12:22:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 19:22:58 -0000 On Thu, Aug 30, 2012 at 7:59 AM, Arthur Thisell wrote= : >> Received fields are not explicitly carrying security information, >> merely trace data, so RFC5322 didn't need to point this out in >> Security Considerations. > > Uh, yes they did. Forging Received fields is a very common practice by s= pammers to mislead people (and poorly written anti-spam programs) into thin= king that the email ok. Forged Received fields, and depending on the orde= r of those fields, is almost exactly like Received-SPF fields. Uh, no they didn't. Which part of Section 5 of RFC5322 talks about Received field ordering? Section 3.6 even warns about this: It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. However, for the purposes of this specification, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information. That text seems to make reliance on header field ordering or positioning unreliable at best. DomainKeys also tried this and it was not something that was carried forward into DKIM. -MSK From superuser@gmail.com Thu Aug 30 12:25: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 3326121F860E for ; Thu, 30 Aug 2012 12:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR7qUBI9Dt8W for ; Thu, 30 Aug 2012 12:25:34 -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 A33BA21F8604 for ; Thu, 30 Aug 2012 12:25:34 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4560177obb.31 for ; Thu, 30 Aug 2012 12:25: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=cpcIzMjP7RjHFPGnDPxPnYu0zC+Kwo3pDJy0wL9XnKQ=; b=uxpgKoXu1+VwtLea5QUfgQNIFDKWreZq+usK0/+TQh0fVtyavFjrFHAUV/eceJSbLo mwJV6Kh9T/+anQsvMczSrh0UgPIHPlReJV2B6TXEG16BzmOnnCHpX9fhh/YuGSzTeV+N RCtPFgmtUOefz1YVL/p/UazcmyoFHBPAscDchcI1wCSXbMmY/Add6tuuMcdDCdXvPZKX gBfU3kAo9ZGXmmb58h2i/W9bPgcKrzNV5ro3Qz3nqwn147FL5x2/ZmtOnjTSsbU7p3eV iqTOe9JrIr7OkKc//PtBPaK98/DCt2Qv7gxj3xKomyFNbo2TSIMNTKPXT/fWKfgqKs+T P6JA== MIME-Version: 1.0 Received: by 10.182.0.13 with SMTP id 13mr5755412oba.55.1346354734274; Thu, 30 Aug 2012 12:25:34 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 30 Aug 2012 12:25:34 -0700 (PDT) In-Reply-To: References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> <6.2.5.6.2.20120823090217.095f31c0@elandnews.com> Date: Thu, 30 Aug 2012 12:25:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 19:25:35 -0000 On Thu, Aug 30, 2012 at 8:16 AM, Scott Kitterman wrote: > If I understand this correctly, you're favoring documenting the current ambiguity, but not resolving it? If that's the signal you're getting from my reply then maybe I'm not understanding the problem. However, Suggested Variant 1 (upthread a bit) also doesn't seem to do much other than document the ambiguity. Is there a proposal for something more firm that I missed? -MSK From superuser@gmail.com Thu Aug 30 12:27: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 866D421F84A1 for ; Thu, 30 Aug 2012 12:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEqMHS3j74Nc for ; Thu, 30 Aug 2012 12:27:47 -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 B5C9321F8495 for ; Thu, 30 Aug 2012 12:27:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4564949obb.31 for ; Thu, 30 Aug 2012 12:27: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=yK1ydPP1HYYrkyckPrTgUWGnLk0sENVLLmp8shFRwOQ=; b=wxECSv+3ofF841qKIM3pgoqlRSaTkKZSNx1QeF2X2FDQZzjRFrXvwQiC49cHKJ0XS4 0EAzWcANxExfmmcZF+a8HzUcLDDUfWIBRzcfp4Kgq+/YSfs+SahXzsePexrhC9BoY0R9 M9f5gYmdRsHxKccz6MyX+vWCHFmpwkNi0hR3rGEglgGkbXzrfQuLQgp4a0H4GTKMBMBW yeSqAozxxmDCAht+yLIZGJ8e8lFwT+y/9XRU7/8vjkxoCouQA19Fxc2Nb0C6JjWQWpt8 Y08AoQ0RtLm9y/2C9ofClIRrJBRZK2TBvcx4vgcO7ouBCB7Hnn91a+evt7R5BZVi2yiX bUmw== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr4961148oeb.18.1346354866345; Thu, 30 Aug 2012 12:27:46 -0700 (PDT) Received: by 10.182.8.130 with HTTP; Thu, 30 Aug 2012 12:27:46 -0700 (PDT) In-Reply-To: <503F8D42.3020109@tana.it> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5345259.50xTJaGO9G@scott-latitude-e6320> <503F486F.6060405@tana.it> <5848c7ce-5396-42d0-84cf-6ee81dc0466c@email.android.com> <503F8D42.3020109@tana.it> Date: Thu, 30 Aug 2012 12:27:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:27:47 -0000 On Thu, Aug 30, 2012 at 8:56 AM, Alessandro Vesely wrote: > For comparison, RFC 5451 doesn't say "a transient (DNS) error" but > "some error that is likely transient in nature, such as a temporary > inability to retrieve a policy record from DNS." IMHO, the latter > includes local malfunction, albeit it indicates the DNS as a typical case. Is the distinction important? The salient point is that the software has determined that, whatever the error was, it's possible it will self-resolve rather than being an error that requires operator intervention. -MSK From dhc@dcrocker.net Thu Aug 30 12:52: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 A157D21F861A for ; Thu, 30 Aug 2012 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmcAAy-FUe5i for ; Thu, 30 Aug 2012 12:52:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF5FE21F8621 for ; Thu, 30 Aug 2012 12:52:20 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7UJqIur015966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Aug 2012 12:52:19 -0700 Message-ID: <503FC46A.5000409@dcrocker.net> Date: Thu, 30 Aug 2012 12:52:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5345259.50xTJaGO9G@scott-latitude-e6320> <503F486F.6060405@tana.it> <5848c7ce-5396-42d0-84cf-6ee81dc0466c@email.android.com> <503F8D42.3020109@tana.it> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 30 Aug 2012 12:52:19 -0700 (PDT) Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] #47: domain-spec 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: Thu, 30 Aug 2012 19:52:21 -0000 On 8/30/2012 12:27 PM, Murray S. Kucherawy wrote: > On Thu, Aug 30, 2012 at 8:56 AM, Alessandro Vesely wrote: >> For comparison, RFC 5451 doesn't say "a transient (DNS) error" but >> "some error that is likely transient in nature, such as a temporary >> inability to retrieve a policy record from DNS." IMHO, the latter >> includes local malfunction, albeit it indicates the DNS as a typical case. > > Is the distinction important? The salient point is that the software > has determined that, whatever the error was, it's possible it will > self-resolve rather than being an error that requires operator > intervention. Certainly it's not significant at a protocol specification level. On the other hand, it probably has some pedagogic benefit to remind the reader that there is an end-to-end integration that has to work properly and when it doesn't, the problem could be anywhere in the sequence. So, perhaps: ...such as a temporary a network problem or a remote host's inability to retrieve a policy record from its portion of the DNS. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Aug 30 13:06: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 569CC21F854B for ; Thu, 30 Aug 2012 13:06: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkLaLir-WvhU for ; Thu, 30 Aug 2012 13:06:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A293621F853C for ; Thu, 30 Aug 2012 13:06:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9571120E414A; Thu, 30 Aug 2012 16:06:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346357189; bh=KMEIhla9s1m4MtoIxM3b4PyZLFqfgxyt6+X0/JjyV/I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=S4xl3HnbPHZyJHLYqnvmyZtgoK8lkciZgiCOcMVQWOZTUD/UAfi+EB06+Kb2jK3sM 4AwNfmYKYLqeDE9YkHOxQGAJVPisPIX8MThLDDq28O5vK4KoVTJtI2Bsx9jHjvbUQJ cumxkTazPHB0e/9oQOb6E5ihjJr2AM77l2qwCaDk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6E78820E4086; Thu, 30 Aug 2012 16:06:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 30 Aug 2012 16:06:28 -0400 Message-ID: <5731978.t7c17mbZLx@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <503FC46A.5000409@dcrocker.net> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <503FC46A.5000409@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:06:31 -0000 On Thursday, August 30, 2012 12:52:10 PM Dave Crocker wrote: > On 8/30/2012 12:27 PM, Murray S. Kucherawy wrote: > > On Thu, Aug 30, 2012 at 8:56 AM, Alessandro Vesely wrote: > >> For comparison, RFC 5451 doesn't say "a transient (DNS) error" but > >> "some error that is likely transient in nature, such as a temporary > >> inability to retrieve a policy record from DNS." IMHO, the latter > >> includes local malfunction, albeit it indicates the DNS as a typical > >> case. > > > > Is the distinction important? The salient point is that the software > > has determined that, whatever the error was, it's possible it will > > self-resolve rather than being an error that requires operator > > intervention. > > Certainly it's not significant at a protocol specification level. > > On the other hand, it probably has some pedagogic benefit to remind the > reader that there is an end-to-end integration that has to work properly > and when it doesn't, the problem could be anywhere in the sequence. > > So, perhaps: > > ...such as a temporary a network problem or a remote host's inability > to retrieve a policy record from its portion of the DNS. My plan is to change (DNS) to (generally DNS). Any objections? Scott K From spf2@kitterman.com Thu Aug 30 13:12: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 BE56E21F847D for ; Thu, 30 Aug 2012 13:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnNVmi9GAGwO for ; Thu, 30 Aug 2012 13:12:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 179E821F846E for ; Thu, 30 Aug 2012 13:12:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83E3820E414A; Thu, 30 Aug 2012 16:12:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346357575; bh=9bdUb9YuPyi329J+zCH3b8cs4Zi17KcY7ZCN2TiFGc0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cJoMx857kYVysesGlHHGmvFM/QAsmixN3zbq11Pb+zvN2VHIG9E2c0XTlA/8/X6CY zlGWRNsq0Yxr0L2CHCRk1On/a9vZ1qc8bWRDa/y0+AGyfb7zuHFc7nHW3zAWn+1Vyf hkI+WwWYlU2o0Wy+dF8avJ9n/nUF/s1mY2HJkCV4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 573DE20E4086; Thu, 30 Aug 2012 16:12:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 30 Aug 2012 16:12:54 -0400 Message-ID: <4082670.uUHbE4N9gQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <061.61d1aa393ab9e5caf37caccda22cd004@tools.ietf.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 20:12:56 -0000 On Thursday, August 30, 2012 12:25:34 PM Murray S. Kucherawy wrote: > On Thu, Aug 30, 2012 at 8:16 AM, Scott Kitterman wrote: > > If I understand this correctly, you're favoring documenting the current > > ambiguity, but not resolving it? > If that's the signal you're getting from my reply then maybe I'm not > understanding the problem. However, Suggested Variant 1 (upthread a > bit) also doesn't seem to do much other than document the ambiguity. > > Is there a proposal for something more firm that I missed? Leaving specific wording aside for a moment, I think there are three options: Invalid domains after macro expansion (empty label/label too long) produce domains that can never be matched, but there is no error returned. Invalid domains after macro expansion (empty label/label too long) are rrors and a permerror is returned. The current spec is ambiguous on which of these is correct and there are implementations that do both (thus the erratum). We could leave this ambiguity and specify it as OK and warn against relying on either behavior. Obviously documenting the discrepancy and moving on is the most backward compatible solution, but it does leave ambiguity. Personally, I'm inclined to make them errors, but I'm not sure that's right. Scott K From dhc@dcrocker.net Thu Aug 30 13:14: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 78BF421F8568 for ; Thu, 30 Aug 2012 13:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaVY7Szap2wG for ; Thu, 30 Aug 2012 13:14:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2A21F854B for ; Thu, 30 Aug 2012 13:14:50 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q7UKEiCe016264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Aug 2012 13:14:46 -0700 Message-ID: <503FC9AC.1060402@dcrocker.net> Date: Thu, 30 Aug 2012 13:14:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Kitterman References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <503FC46A.5000409@dcrocker.net> <5731978.t7c17mbZLx@scott-latitude-e6320> In-Reply-To: <5731978.t7c17mbZLx@scott-latitude-e6320> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 30 Aug 2012 13:14:48 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #47: domain-spec 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: Thu, 30 Aug 2012 20:14:51 -0000 On 8/30/2012 1:06 PM, Scott Kitterman wrote: > On Thursday, August 30, 2012 12:52:10 PM Dave Crocker wrote: >> So, perhaps: >> >> ...such as a temporary a network problem or a remote host's inability >> to retrieve a policy record from its portion of the DNS. > > My plan is to change (DNS) to (generally DNS). Any objections? It's a bit subtle for the pedagogical point I was noting, but it also isn't wrong. And of course, it's less wordy... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Thu Aug 30 14:48: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 7EC1321F853B for ; Thu, 30 Aug 2012 14:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79VfWUDGp0YJ for ; Thu, 30 Aug 2012 14:48: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 CC5A221F8530 for ; Thu, 30 Aug 2012 14:48:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7ULljKE029889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 14:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346363281; bh=MjERKKIbwHtqXgLYt+LDX7JbhevZFoisWMBcdf2MUrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZSjqc5pnOQFhZI8QrAjQzTo/SEw8R1zT42m9VnvIMO+An6Yf925hss3h65tAE5Oh/ s7RLQ0y+XgtDUu6MPJt2yWcEnkpoKMzj+UYhc6N2XXu3OesnK8mD4jdUohcKlsSCbd GSncdVRrcD2f/nEChWdZ9kdEm1kdU8wiGjH8AAw0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346363281; i=@elandsys.com; bh=MjERKKIbwHtqXgLYt+LDX7JbhevZFoisWMBcdf2MUrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qWvN9wTzT73Wcg/AB3L1VEc9x1OWp6Zw/PVJTQldhdIk36SZzeaXanZrxWGkDDBIR bBKuf2N1Da2Fc9yd4YuBZd8Y3uIQiDUTXKutrW4VJhoWJQzGfPTYE0PAhjKqo84urC PHcZ2OOtMYURZ/kPzbRNPFABapGQDBhSZZ+j7xO4= Message-Id: <6.2.5.6.2.20120830135423.0a482828@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Aug 2012 14:42:41 -0700 To: "Murray S. Kucherawy" , Arthur Thisell From: S Moonesamy In-Reply-To: References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Aug 2012 21:48:16 -0000 At 12:22 30-08-2012, Murray S. Kucherawy wrote: >Uh, no they didn't. Which part of Section 5 of RFC5322 talks about >Received field ordering? As I may have misunderstood the comment from Arthur Thisell, I won't comment about that. >That text seems to make reliance on header field ordering or >positioning unreliable at best. DomainKeys also tried this and it was >not something that was carried forward into DKIM. My understanding is that there is some (unrelated) discussion of the Received: header field in RFC 5321. Murray Kucherawy covered most of the issues in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02475.html The working group might end up having to reference DKIM if it decides to tackle header protection. I mentioned "leeway" as it is easier for me to get a view of what the WG wants and suggest a path from there. Regards, S. Moonesamy From hsantos@isdg.net Thu Aug 30 17:48: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 D88EF21F8459 for ; Thu, 30 Aug 2012 17:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJCy+f2FbSps for ; Thu, 30 Aug 2012 17:48:00 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 142E121F845B for ; Thu, 30 Aug 2012 17:47:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=676; t=1346374077; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=M8/XeXDxVDkCM5MQRaHUsOtZUss=; b=c2/a9afIeuchSdfoh08t 0cjv/oS66WRG9g3g6NDpVrGUjI2Q2kcZOr4QZxsCpfEzuPFrl0IK33e95GpMbZF7 rUCtX+XpnxiIKGU0LzoKuyAJHlpkQq7Ys7YjNWIL+0deRztOLQXL/ncL/zX5e01+ qGD30lP2AX3M788HaEZ01QY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 20:47:57 -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 2395866375.8048.736; Thu, 30 Aug 2012 20:47:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=676; t=1346373873; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WjZJrnV CnOuZHO6+5yYWOmL1lNpke9Arb/VAIVy2Eow=; b=TUUkRrLauEJ9//tbExmEHg+ kTBoSWFv9pXt/0dGhC5Xir7Hdqll6ExW+PvQydwGES4mdFjHTdx/W2mT6DTn7MYC I285+h2vqRkwPY4KL1jVdQXCDJFRDLCE0rZwHjCsNlGRMp2loGnF3iGPGctQuatz 32DLLZM7URs19JigHOCY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 30 Aug 2012 20: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 2994671802.9.2896; Thu, 30 Aug 2012 20:44:33 -0400 Message-ID: <504009E8.8070103@isdg.net> Date: Thu, 30 Aug 2012 20:48:40 -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: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> In-Reply-To: <6.2.5.6.2.20120830135423.0a482828@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 00:48:01 -0000 S Moonesamy wrote: > The > working group might end up having to reference DKIM if it decides to > tackle header protection. What you (speaking in general) are saying is that a RECEIVER will now have to sign local incoming mail. Then you need a SIGNER POLICY that says: This mail is expected to be signed by the receiver to protect ACCEPT+MARK deployments. Please don't. While I appreciate a new focus and emphasis in BIS to support accept+mark with a deemphasis in SMTP level 55x permanent responses mode of operations, I don't think its necessary to revamp the protocol for this accept+mark operation. Thank you for your WG consideration. -- HLS From agthisell@yahoo.com Thu Aug 30 18:24: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 2175811E80E4 for ; Thu, 30 Aug 2012 18:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tczzC2Ofoajg for ; Thu, 30 Aug 2012 18:24:46 -0700 (PDT) Received: from nm14-vm2.bullet.mail.ne1.yahoo.com (nm14-vm2.bullet.mail.ne1.yahoo.com [98.138.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 8E4A921F84B6 for ; Thu, 30 Aug 2012 18:24:46 -0700 (PDT) Received: from [98.138.90.53] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 01:24:39 -0000 Received: from [98.138.226.169] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 01:24:39 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 01:24:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 514759.94841.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 88754 invoked by uid 60001); 31 Aug 2012 01:24:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346376279; bh=jETJbcRuxfYmlGCKAPd1BLudovSA/K4hoXZREw20wis=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Ba1NcKHfKZB3GgMqMk2MOS6WEy01F2l+Ruq52O6bPKxCZgMRrNGZc522jaVeKePeu2QJrBGRCd4jMpzvdpOTn9l4rQt0z2/VbIDe9SwTGM7YkMWHgHz9ritdKG/hfO8fuV7Z1MC+t9h34yl02jKfkvGCuHoke0lYpUL7gBrJjdI= 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=vDhQtiMvbFAIHVfayfs8ueso+Cl/kcjMDgA4OwV3HqxAKu4X1EEW66PjwSstSozIwxOKlif/Wr7e3mOk8Pm+sHZZYhJBx1lhotV5XRsZdkBQWzItt53rt1QB/6kej72QJVVrFyBeKdL18tpXDkZUKBbZmmW9Jc27zl6UZ7G/C38=; X-YMail-OSG: kZ.cPeUVM1ke1ATqPfMlZIIyfoKixvixxY9hyUF.ouyjwcj TyfW.6l9j.qsmZpvL7J988Z6FWfxhDCkgcsD7ds_LA2VWhjWH9TnssRUZ8bL PMlbeyAZua0Y90Ea9Mu8S__Stq.Th9X.3Z4V8kssTGFAPiFiFu4ZW65_TS_k KqUt0ACf.oXQxQ3Oq8A18vLZuoPe4naNylzg4RhQ48r0JSbVa81I4F6vehj_ ycamhi5jLB7y40KSXVi6UI74AXI5P0.4KAmqs.n3zcIEKfEHz4wCkiQu473P AVfDT8GPGApjl5QysgCQ8Kv2BmQch.2c8JtyawP5wxrYq7zQmMX1rSUKDx9P _C1TjWaN3UC2aizZwQvzJpmmAOYjYCIFlS2B.voG5.q4DKPhXbuWQmXtCUif zmtbMcXYIgM94KkAxJb9iXPpI3WiJ9m7qce7AEtxim2pHJBlV2BZDSHy5pwN V9cfZVu.H1FcwP9e2vrI- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Thu, 30 Aug 2012 18:24:39 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Thu, 30 Aug 2012 18:24:39 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 01:24:47 -0000 I did some more digging around in old SPF drafts. My notes apparently say that there are many conflicts on this subject between the pre-marid drafts, marid drafts and the implementations. I had forgotten how much of a mess it is. No matter what we do, we will still have conflicts between drafts and conflicting implementations will be around for years. *sigh* Besides the three options you mentioned, the current text about in the RFC about chopping off labels until there are fewer than 253 octets could be expanded to chopping off labels until the domain is valid, but I don't much like that one. I'm kind of leaning toward making invalid domains not match. I guess no matter what we do, documenting this known brain damage is probably a good idea. From spf2@kitterman.com Thu Aug 30 19:14: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 7A48521F84F9 for ; Thu, 30 Aug 2012 19:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IoNzhCqDwn1 for ; Thu, 30 Aug 2012 19:14:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB67C21F8501 for ; Thu, 30 Aug 2012 19:14:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 30493D0408A; Thu, 30 Aug 2012 21:14:18 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346379258; bh=OoeJCUybhBbaZHR0RYHZRybErk+FX2jZa99rBbMzu0k=; h=References:In-Reply-To:Subject:From:Date:To:From; b=U6DmgSx0HlBy13WihT85B+Xsn2zViebVbNh7w4lefPlTbVRrEUZ4EZYE2gvyzA8ni 1Tuo6r+EOoml7mPNToZRXIhuORb89xkqZH6lduKRVNPl6CCyPLZ8j01p0M+mO1nR7X EAUxuTK2yXwyHxu0H5rPTVTf6YlNGN1qEpwAGo9o= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E1048D04087; Thu, 30 Aug 2012 21:14:17 -0500 (CDT) References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> User-Agent: K-9 Mail for Android In-Reply-To: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 Aug 2012 22:10:00 -0400 To: spfbis@ietf.org Message-ID: <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] =?utf-8?q?=2322=3A_RFC_4408=3A_Section_2=2E5=2E7_PermErr?= =?utf-8?q?or_on_invalid=09domains_after_macro_expansion?= X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 02:14:19 -0000 Arthur Thisell wrote: >I did some more digging around in old SPF drafts. My notes apparently >say that there are many conflicts on this subject between the pre-marid >drafts, marid drafts and the implementations. I had forgotten how much >of a mess it is. > >No matter what we do, we will still have conflicts between drafts and >conflicting implementations will be around for years. *sigh* > >Besides the three options you mentioned, the current text about in the >RFC about chopping off labels until there are fewer than 253 octets >could be expanded to chopping off labels until the domain is valid, but >I don't much like that one. > >I'm kind of leaning toward making invalid domains not match. > >I guess no matter what we do, documenting this known brain damage is >probably a good idea. I think we need to document the brain damage so people know not to rely on either behavior and pick either no match or permerror as correct. I have a slight preference for permerror, but I care more about picking an unambiguous 'right' way for the future than which one we pick. Scott K From superuser@gmail.com Thu Aug 30 20:29: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 9135911E80DE for ; Thu, 30 Aug 2012 20:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBVcU0XWx6dO for ; Thu, 30 Aug 2012 20:29:58 -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 B9D8011E80DC for ; Thu, 30 Aug 2012 20:29:57 -0700 (PDT) Received: by lbky2 with SMTP id y2so1116875lbk.31 for ; Thu, 30 Aug 2012 20:29: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=4UshbOH7ga9uPqIHYL6R4/wiSnIoRQjpD9wuk1zGZec=; b=jGT4KQb/96QiIWBrohktaWj9+i4zjFWbdjcBQn8KZ04y9nNUs8pXFF1jC2CZrV7H3w nstlZOKPC4pSj2cs73FoNcT9U335T9Lp9MwZTJWEdi2tRnO5fD7RjPnC2/dEJ3XPKg7W 3Sro7qYqZ9j8lpJPbJVsynvEjOV1o4yOaBYBJJieEeeYj7E8yx6BW1Me5VzfbHvKfCNI ng3SIo3aZ7NqDOrWjpuwxB43QVcXRU5SfigZ1W6Y9xZQOSG27Pf4PF26je865k7JpgXL iCOHi0iL2mkoLNOzjRcEAUKUB+KzEGD/b1ScE5cL+gk8wPtXGYbqodamCj7W9YuTkTDt puyA== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr5090905lab.37.1346383796602; Thu, 30 Aug 2012 20:29:56 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 20:29:56 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120830135423.0a482828@resistor.net> References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> Date: Thu, 30 Aug 2012 20:29:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Arthur Thisell Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 03:29:58 -0000 On Thu, Aug 30, 2012 at 2:42 PM, S Moonesamy wrote: > The > working group might end up having to reference DKIM if it decides to tackle > header protection. I don't think that's necessary. RFC5451 already talks about all of that. DKIM is one of several possible solutions for ADMDs where internal forgery is a concern. We don't need to copy all of that, just make informative references to the relevant bits. -MSK From superuser@gmail.com Thu Aug 30 20: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 C97FF11E80DE for ; Thu, 30 Aug 2012 20:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+1jCTAum4sb for ; Thu, 30 Aug 2012 20:32:08 -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 019B611E80DC for ; Thu, 30 Aug 2012 20:32:07 -0700 (PDT) Received: by lahm15 with SMTP id m15so2322198lah.31 for ; Thu, 30 Aug 2012 20: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=4L556sMe+2hLqWYtcM8nQ1YWhMriJ6xQLQsRfEq9pqw=; b=XGh4YtDHnboTwG0p4BJBY8KXSe5+HwLeqSo9hCVVL76J/mraH0OzJ++nMOCGVZMIPG 7BUdPBUGxgOxGok1mCC7quMQZzTY0kqELeIaxPQyAAUI2/ryBYbsLcElAh6u9H64wI7Q K596+PTVDXlAMoXgctqZUOv/xDNXig8shbqWAoNH/PvLoZd/5Zbzo/rZrGT9QuxRr/32 K+wNR21euKze/KGKDqYy1S1SjDPmnOQgKegHhl6rx0alsl9djQ3KQZf5O2rfGGLrXq5p NbUort+sbyCC7cOLsQ7XwGXOqAPtU68j1qNCPch8Kj51RAy+NckY4Ige4RU6JPxkdOoH pZ0Q== MIME-Version: 1.0 Received: by 10.152.148.1 with SMTP id to1mr5158816lab.34.1346383926819; Thu, 30 Aug 2012 20:32:06 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Thu, 30 Aug 2012 20:32:06 -0700 (PDT) In-Reply-To: <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> Date: Thu, 30 Aug 2012 20:32:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 03:32:08 -0000 On Thu, Aug 30, 2012 at 7:10 PM, Scott Kitterman wrote: > I think we need to document the brain damage so people know not to rely on either behavior and pick either no match or permerror as correct. +1. > I have a slight preference for permerror, but I care more about picking an unambiguous 'right' way for the future than which one we pick. Since we're talking about data that are plainly malformed, I'm inclined to agree with permerror. But my preference is also slight. -MSK From sm@elandsys.com Thu Aug 30 22:59: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 6865B21F852B for ; Thu, 30 Aug 2012 22:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jo686rTcYur for ; Thu, 30 Aug 2012 22:59: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 B1E7521F84D4 for ; Thu, 30 Aug 2012 22:59:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7V5xXEg025838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 22:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346392788; bh=thv9dRoCp3U4gX9VYdrSCYZb8uE8SbsTvwydxat6Sg0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LeXBQa/kJULDwNZaE5bwaKb0OxV4To3/am705+8wlw+5AaggGpNDAZzzSfQS+wEnR EgYT9nV3Tg+SezHXuZJ85GbNaqvXmYDOAEDdZQinhw4DCf8dRh5tfniWDV8tpE3qPf kaHX3Ipv8E172yRLx8EMhlE/PUc0MCD26UJ5e3DA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346392788; i=@elandsys.com; bh=thv9dRoCp3U4gX9VYdrSCYZb8uE8SbsTvwydxat6Sg0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4i6Y8ZdvCk5B41/D3zjEaPfkZR8hJ+wfdH6DKOrnEiEAYCbWXdegBH7dsHU99o4BM qA3/lozQW5UCVfwWhAxohxtNkC8oWmM8wWZY04MqXsRWxzNIqfXSFR2tlLYmDPH0y9 piDU67y2ophJT/vQvH95ORLC0PhdgHV/PF5w22DE= Message-Id: <6.2.5.6.2.20120830221228.098efd08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Aug 2012 22:57:27 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <504009E8.8070103@isdg.net> References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> <504009E8.8070103@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 05:59:56 -0000 Hi Hector, At 17:48 30-08-2012, Hector Santos wrote: >What you (speaking in general) are saying is that a RECEIVER will >now have to sign local incoming mail. Then you need a SIGNER POLICY that says: > > This mail is expected to be signed by the receiver to protect > ACCEPT+MARK deployments. No, it's not about setting requirements. It is up to the author (well, the WG) of the specification to analyze the threats and provide guidance about how to mitigate those threats. This is not about signer policy. It is about security. >Please don't. While I appreciate a new focus and emphasis in BIS to >support accept+mark with a deemphasis in SMTP level 55x permanent >responses mode of operations, I don't think its necessary to revamp >the protocol for this accept+mark operation. It is not about accept+mark. Even if I do a SMTP reject there would still be an issue as I will be adding a header field in other cases. Regards, S. Moonesamy From sm@elandsys.com Fri Aug 31 00:03: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 E452B21F8532 for ; Fri, 31 Aug 2012 00:03:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpM3xTs2KqMj for ; Fri, 31 Aug 2012 00:03: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 4D3D221F8525 for ; Fri, 31 Aug 2012 00:03:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7V73MLp012239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 00:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346396615; bh=3I1NYouBV/Buy2t8UKaZzyUWvxhJGHlSIxEb9RW3yEg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IvtStocskodDYLsixfAD8vlYHbA1l9qDbw+yle3wY5SK++Jb3VFw+8Oa8bmlb6piw U2CKSZ/MCQKB1YOmf9cQsa052lerGwuv9wcMcv1gUww6xb4HYfOtRDJjzMz/9Gn0U1 U+4daWtiBPCbv5rdc6OOixn+7aHaEU9yStRIUKjA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346396615; i=@elandsys.com; bh=3I1NYouBV/Buy2t8UKaZzyUWvxhJGHlSIxEb9RW3yEg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RffhLMwCQ4n6XssVJ6eLWfIznuKqLBJN1kHoGJBXosmZxlSK+jujL5uEJEHIqoVk2 YJ+cWhP7B5bYaHrkgHTKpYfCwIKHA5se5ZIZg1hS/A3pPDr6ydJsm/AhZtsYU5TPf5 b+TX4C7MQJlwOwpkfrJEHdGsQ1wDbRu1Hbrhyeeo= Message-Id: <6.2.5.6.2.20120830230313.0ad11708@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 30 Aug 2012 23:27:44 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Arthur Thisell Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 07:03:41 -0000 Hi Murray, At 20:29 30-08-2012, Murray S. Kucherawy wrote: >I don't think that's necessary. RFC5451 already talks about all of >that. DKIM is one of several possible solutions for ADMDs where >internal forgery is a concern. Yes. >We don't need to copy all of that, just make informative references to >the relevant bits. There are different ways to tackle this. You don't have to provide an elaborate explanation if you provide the necessary warnings and ways to mitigate the threats. Let's me know whether I should elaborate on this. Regards, S. Moonesamy From hsantos@isdg.net Fri Aug 31 01:11: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 5AED021F8526 for ; Fri, 31 Aug 2012 01:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOHwLTCm+te5 for ; Fri, 31 Aug 2012 01:11:51 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3444321F84FA for ; Fri, 31 Aug 2012 01:11:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1197; t=1346400702; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lHtQdwnbu+RkcDNO2CPDUPCXTP8=; b=szo6p/34WKWqLZnPb60J pCy+Tyoby1XJiI6yxesXGNCqu5mp8IW00+U+RCQ3ehb1OFnIiT4MbzDwFuE5+5HL J+NNKhK8ejvuv2qXhqHPiFMx4AZnP06f+Gvw+gWqKnPKBYviu7dbscBLyK5NUw+p zjgNpn6cfHvNL6aac3sbdJI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 04:11: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 2422491705.9047.5960; Fri, 31 Aug 2012 04:11:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1197; t=1346400495; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Y5BCDVQ n53+Uc8IQVN3gN6A05imx9HNK2p0tStCWMQo=; b=KhoIgAKrts3NBO1sI1LvRUG ZtBGLUG9n/qX1ZS0L5iiyk9uobdRJ6m7a0rxdWVIzqKeSsb2BQRViDs6bqyHbif5 9D6xSxCMo3/UVNeQhBIS77ObhOqfieXURFW2NH7NhztnefkoFdLULFJfujEEB7m6 n6rz5GOqC4jn2StcyDno= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 04:08:15 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3021292911.9.7400; Fri, 31 Aug 2012 04:08:14 -0400 Message-ID: <504071D1.3060605@isdg.net> Date: Fri, 31 Aug 2012 04:12:01 -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: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> <6.2.5.6.2.20120830230313.0ad11708@elandnews.com> In-Reply-To: <6.2.5.6.2.20120830230313.0ad11708@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 08:11:52 -0000 S Moonesamy wrote: > Hi Murray, > At 20:29 30-08-2012, Murray S. Kucherawy wrote: >> I don't think that's necessary. RFC5451 already talks about all of >> that. DKIM is one of several possible solutions for ADMDs where >> internal forgery is a concern. > > Yes. No. Please don't advocate this. >> We don't need to copy all of that, just make informative references to >> the relevant bits. > > There are different ways to tackle this. You don't have to provide an > elaborate explanation if you provide the necessary warnings and ways to > mitigate the threats. Let's me know whether I should elaborate on this. You are missing the point. If the system is already compromized internally, then the system is already hosed. Nothing can't protect it, Not even DKIM and in fact, all other security warnings are out the door. If the internal system has to begin adding DKIM or any other error correction/checking, CRC or otherwise to protect Receiver-SPF, then why not for Received, From, Return-Path and all other headers? It isn't about protecting Receiver-SPF but developing a new local system protocol to protect the entire message from local system itself. -- HLS From vesely@tana.it Fri Aug 31 01:15: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 6FFED21F850D for ; Fri, 31 Aug 2012 01:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTtU-ExmWRHx for ; Fri, 31 Aug 2012 01:15:42 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 403E721F850C for ; Fri, 31 Aug 2012 01:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346400939; bh=xzauoq4tmY4hcBX6iPnpLulKE029qu2+1U29VuewzIo=; l=144; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=FaWaEXbPVBVOVe750mr+Xd/jL9HOr6kB3xrpF+xHa13EEDl3hU39NAYBGTNXH8a/w /Q/a5IVUG+Wdb6y8FCw6oNxTA8l0TQuwHPJws1n5V8mntKI4cbSSfTmqNtSgfsVb8Z 8MQtqFVrLPz2lxX56aTCxfFfyo7XVNwSYh5jwmcg= Received: from [37.183.71.43] ([37.183.71.43]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 31 Aug 2012 10:15:38 +0200 id 00000000005DC042.00000000504072AA.00002DC8 Message-ID: <504072A6.3020407@tana.it> Date: Fri, 31 Aug 2012 10:15:34 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <503FC46A.5000409@dcrocker.net> <5731978.t7c17mbZLx@scott-latitude-e6320> In-Reply-To: <5731978.t7c17mbZLx@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 08:15:43 -0000 On Thu 30/Aug/2012 22:06:28 +0200 Scott Kitterman wrote: > > My plan is to change (DNS) to (generally DNS). Any objections? Works for me. From vesely@tana.it Fri Aug 31 01:17: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 3755E21F8471 for ; Fri, 31 Aug 2012 01:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzWyZ0lDxpHY for ; Fri, 31 Aug 2012 01:17:54 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A60A321F846B for ; Fri, 31 Aug 2012 01:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346401073; bh=KGt2gFf2WklOmHhUVDj46WbRlViQtb38r150tDTxuNI=; l=1043; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lU6gQxeYwftmZuXilsKCQD/bCBouqJHf7T9NFAHFdO9vtznaPmuzP7juAhOE8g4qJ zSRXMGY7PhD34MJrScHdQk5TCRvgJDymufXeDOUm2TAAoiinqtDGy2NbxO6n4E0Dpu ZSJEO3J5jTm4xNGZOBAKLe7nFv/8SQeUQD2ZOMK4= Received: from [37.183.71.43] ([37.183.71.43]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 31 Aug 2012 10:17:52 +0200 id 00000000005DC042.0000000050407330.00002E5C Message-ID: <5040732A.4080802@tana.it> Date: Fri, 31 Aug 2012 10:17:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 08:17:56 -0000 On Fri 31/Aug/2012 05:32:06 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 30, 2012 at 7:10 PM, Scott Kitterman wrote: > >> I have a slight preference for permerror, but I care more about >> picking an unambiguous 'right' way for the future than which one >> we pick. > > Since we're talking about data that are plainly malformed, I'm > inclined to agree with permerror. But my preference is also slight. Non-match makes sense in case the record is correct, but the parameter is malicious, e.g.: exists:{%l}.{%o}._spf.lengthy-subdomain.example That may match all allowed users, but can be made longer than 63 or empty-label. It is not an error in the record, and it would produce noise to consider it as such if error reports are requested. OTOH, exists:{%ir}.my..bad.example is a reportable error. I agree the 'right' way is permerror. However, leaving some leeway spares us a change in the spec while also allowing the verifying software to detect malicious macros and do better if it can. From hsantos@isdg.net Fri Aug 31 01:22: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 3C10021F8518 for ; Fri, 31 Aug 2012 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjBIxOF2zwXj for ; Fri, 31 Aug 2012 01:22:02 -0700 (PDT) Received: from listserv.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6272E21F850D for ; Fri, 31 Aug 2012 01:22:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1606; t=1346401317; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oavWFMaOeQmPxBJpJ33Zvm6WwCg=; b=QvqiVsQmiWgeF3r0nY5E F7G/5dv1rOdTR6hBIxpYoX7pQ6OtGt4k7nOUbbz37h7CaAazKyJmSbLjCq7Wo1W7 9A2xy4w0nJtqPaoFhkqE1J7DtPqXgoCyvz1nGk7YZSz6FboeH3dl5x003I3kc99+ 56Fe2chyQW5F82ziZ/W7T74= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 04:21:57 -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 2423106895.9047.2120; Fri, 31 Aug 2012 04:21:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1606; t=1346401111; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CoDzkqU ybuh2fiYG8o1Xkr5PIpUlZIIxMJnPD6NaToM=; b=MT2BZOyWTH+fHBOkG1rd+wV sDRofVpHWUMO3TAcYZn+6YkbEadLBg4twf5waB5O2GDMDmO3oPIYfrDv/YYi8a2i LHF9R/rchSDCZLgFwDsT2kI/GL3GZAHrwIZ20fVlmZzgBvjUl686azw3KJaGeVYi ygzS1Mbw1Mi6VTr8vUZI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 04:18:31 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3021909942.9.7424; Fri, 31 Aug 2012 04:18:31 -0400 Message-ID: <5040743A.6070001@isdg.net> Date: Fri, 31 Aug 2012 04:22:18 -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: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> <504009E8.8070103@isdg.net> <6.2.5.6.2.20120830221228.098efd08@elandnews.com> In-Reply-To: <6.2.5.6.2.20120830221228.098efd08@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 08:22:03 -0000 Yes, it is about security which is what SPF is by definition from the perspective of ALL parties; email domains, her senders and her receivers. Its all the above (or below) when we begin to advocate protecting headers that the SMTP is adding especially those recommended, suggested or even mandated the the protocol such as RFC5322, RFC5321, RFC4408. This is way out of scope and new level of protocol talk. S Moonesamy wrote: > Hi Hector, > At 17:48 30-08-2012, Hector Santos wrote: >> What you (speaking in general) are saying is that a RECEIVER will now >> have to sign local incoming mail. Then you need a SIGNER POLICY that >> says: >> >> This mail is expected to be signed by the receiver to protect >> ACCEPT+MARK deployments. > > No, it's not about setting requirements. It is up to the author (well, > the WG) of the specification to analyze the threats and provide guidance > about how to mitigate those threats. This is not about signer policy. > It is about security. > >> Please don't. While I appreciate a new focus and emphasis in BIS to >> support accept+mark with a deemphasis in SMTP level 55x permanent >> responses mode of operations, I don't think its necessary to revamp >> the protocol for this accept+mark operation. > > It is not about accept+mark. Even if I do a SMTP reject there would > still be an issue as I will be adding a header field in other cases. > > Regards, > S. Moonesamy > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Fri Aug 31 05:51: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 2CD3321F856F for ; Fri, 31 Aug 2012 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQlOfaRuZiwD for ; Fri, 31 Aug 2012 05:51:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6313F21F8570 for ; Fri, 31 Aug 2012 05:51:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DCC520E414A; Fri, 31 Aug 2012 08:51:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346417492; bh=Gk19Bm7O0U/fD/gcuwy3IiluGKf/HXqghuWN2mIZebg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IHZlhlPeHIPeiZEJAk2nTpxmM9oSxg9mMjQGCpoqNVJJYCz60sfPatwguV1J6JhdR 1XIiq4RGf84cXvKSsrxWP1bPzo9O4E5uUfKn295eR8R+XjI87gvM8ISOSwprl/umd4 hMVQViqDFfEX3Qmnl/PyMrW1xTeEL0DfptOrWt40= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 495EB20E4071; Fri, 31 Aug 2012 08:51:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 08:51:31 -0400 Message-ID: <4431128.WSyRKOKiki@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <504072A6.3020407@tana.it> References: <1346272928.76604.YahooMailClassic@web125404.mail.ne1.yahoo.com> <5731978.t7c17mbZLx@scott-latitude-e6320> <504072A6.3020407@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] #47: domain-spec X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:51:34 -0000 On Friday, August 31, 2012 10:15:34 AM Alessandro Vesely wrote: > On Thu 30/Aug/2012 22:06:28 +0200 Scott Kitterman wrote: > > My plan is to change (DNS) to (generally DNS). Any objections? > > Works for me. Done locally. Scott K From agthisell@yahoo.com Fri Aug 31 06:23: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 4613321F8471 for ; Fri, 31 Aug 2012 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQTi690KdUcO for ; Fri, 31 Aug 2012 06:23:07 -0700 (PDT) Received: from nm10-vm0.bullet.mail.ne1.yahoo.com (nm10-vm0.bullet.mail.ne1.yahoo.com [98.138.91.72]) by ietfa.amsl.com (Postfix) with SMTP id 9D22D21F846C for ; Fri, 31 Aug 2012 06:23:07 -0700 (PDT) Received: from [98.138.90.54] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 13:23:04 -0000 Received: from [98.138.89.173] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 13:23:04 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 13:23:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 241051.80139.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 84221 invoked by uid 60001); 31 Aug 2012 13:23:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346419384; bh=seCQmOPE79CXXa3jP6+OzrHJbv/70ucInhrLsefEMeQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=XmJig7mmtnX5D+HwwORZ6d8dceNfWhpW1OBhpUsQH2kBNokfkJ+KPS1ourU/Z43XKrr/wVsAp98f89b5vCJUTZOIEmoZR8NxMIb6ilkWZMyJK9WCTIU2inWvIXZI6bonTQGKDWL5X9yCnlxb01wq04X7BHfy3wbNYrf305Hnbfw= 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=xJa1GxaTWzxke+mTyukNJVOI7HPdKC3pSzsZCL2MM0r4RiiiWbjJKuj7hLdRgtS0B2I47ycTwK5V7qbhSZFQgKxjhF3bWisZ6uV6kQFXjkHrtQt/NZrPddyGZYcdzZahvivZlf9P2gNtXPJYyGcjmHIZpiLBE3BhzAvvgPeEl3A=; X-YMail-OSG: pyitvQoVM1ln8lcBDrgnXpatk9_E6ehgRp2N.u32BaNl9a8 wPaLLx3bMDEjnM5FnEtsojvdVplmUDtiC2XDKgckn_R04ZK05cqXZq7AsTnI arryNNBD16CZtgu7vgIcupvFOtLp2fFIPdcrLqSTS6zg_33jwTxbjaReomNm QEkDyCHBvkwx4QBieDGkKBGVBdQf9RQzzBAKZldxyIcD.9_onyWWsrTe4zfN rqVROAWfi09oO_wwGGlhM6YOwBFwP_FhfIiyRIv4.C9A7OA8MtryHxM8EXyT lznR02XuMszOr3iA..p.dk45Ze9ISYqZS9ZgFqxE_nnL8jemO4gMZTVwqC.D i3OzXiEZ1h.Ln8p0nqiW2kwtht2mzWZNbFLhJkHBx0IKUyLfl.7W0xqAighQ hi2iURl2Qg22FID1T2twZ6P0Z1uCUGINSWwXzFuJOqsK6196V48SxIkmE6Pq q_YH3PUQElhFoBEZEKKA- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Fri, 31 Aug 2012 06:23:04 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346419384.83601.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 06:23:04 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 13:23:08 -0000 > Which part of Section 5 of RFC5322 talks about Received field ordering? My mistake, I meant RFC 5321, not RFC 5322. RFC 5322 talks about the general data format of a message and is careful not to stomp on things defined by RFC 5321, so it treats the Received header field very lightly. Not surprisingly, since Section 5 of RFC 5322 is the security section, it doesn't talk about the Received header. about trace header fields. Trace header fields are defined by RFC 5321 section 4.4. It contains all sorts of MUSTs, in particular, it says: An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location. There is, needed a security section of RFC 5321 about Received headers, but that is only about information disclosure. The SPF RFC already talks about that. But, this does bring up a problem: Currently, both RFC 4408 and bis-06 give RFC 2822/5322 as references in the definition of the Received-SPF field. It should be changed to RFC 5321. From superuser@gmail.com Fri Aug 31 07:12: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 0FE4121F8458 for ; Fri, 31 Aug 2012 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46LgrJI18YQ3 for ; Fri, 31 Aug 2012 07:12:43 -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 2F17221F8456 for ; Fri, 31 Aug 2012 07:12:42 -0700 (PDT) Received: by lahm15 with SMTP id m15so2720894lah.31 for ; Fri, 31 Aug 2012 07:12:42 -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=cuCUIP/4owpns9s4rfrkbpDIAXLN+/wR/UhcrfhoTK4=; b=qnFNUQvlS+lVsspsg4wOGNiAN5mhfT3LpYOUsaibE7jUtmYQZdgsHYEDkaK4yIWy3d cX8j6mUQOHiM1vkdiKs8EQOCTOjONCJKxc9Ki2GB+TFIoLRS79Hg55H6iyFnm4dDvlFX bFLi/je0/DjVO85PpC7qfb7f0euyho+Q7eZ7chp8m+1SrCFoenWU+xynH85p4ZCv5/fN pGBUDMPEa4ShJLaSb4BCfkUuBdXvftHLPUZ+/iYhTyYs143KjFgycjG/lZ5snGje/fJX MqLbvlwkwcro1BsFi4XRdSit4uDkQTWUjsoigf5i5hilVucPgiXunIyfg03C3LZfurAe 8TTw== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr6680006lab.41.1346422362084; Fri, 31 Aug 2012 07:12:42 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 07:12:41 -0700 (PDT) In-Reply-To: <1346419384.83601.YahooMailClassic@web125401.mail.ne1.yahoo.com> References: <1346419384.83601.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 07:12:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 14:12:44 -0000 On Fri, Aug 31, 2012 at 6:23 AM, Arthur Thisell wrote: > Trace header fields are defined by RFC 5321 section 4.4. It contains all sorts of MUSTs, in particular, it says: > > An Internet mail program MUST NOT change or delete a Received: line > that was previously added to the message header section. SMTP > servers MUST prepend Received lines to messages; they MUST NOT change > the order of existing lines or insert Received lines in any other > location. And then the citation I provided from RFC5322 warns that despite this normative requirement, there exist programs that do such reordering, and one must not rely on order. That's what RFC5451 attempted to address, and we could make use of that here. -MSK From superuser@gmail.com Fri Aug 31 07:16: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 3C05A21F861F for ; Fri, 31 Aug 2012 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5WD46M+MHws for ; Fri, 31 Aug 2012 07:16:52 -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 50B5721F861E for ; Fri, 31 Aug 2012 07:16:52 -0700 (PDT) Received: by lbky2 with SMTP id y2so1521640lbk.31 for ; Fri, 31 Aug 2012 07:16: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=eVh2nSCKLjYyaXzvTqszjxGs5+3UnpUdn0INoNeiAz8=; b=GVFW3Fh973JxlqLbzFtLeILX5UUwj/KYSj7Efh/dzwj766Qt87DEdZOaVLqNAQe5Ae QpQhgq4oKRk/WizSY9fR0HoHdt4IVsTFMoY7w4YAdAuk4PFElS6O4la0fac2I13ZNuTG swOe0smG6o705dIDtgfH9nIjozrnGhwn7ZNNP2536Pei6Mc59WziXqgBRFOOaT5550V7 cuzbTwvpPxXNBp+82VKK+ja7tTsGeYjyWBdHzz3mRou8sfHkB2ruduGnWkUchdgv/wVt iiFqMRqK67ZjA//C8sutCa3MhxXYF7CWFk6GZq30x5vTsQUGjOLZCkXF+0F1CuG7nj42 R6yA== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr2676386lbb.72.1346422611068; Fri, 31 Aug 2012 07:16:51 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 07:16:50 -0700 (PDT) In-Reply-To: <504071D1.3060605@isdg.net> References: <1346338747.45868.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120830135423.0a482828@resistor.net> <6.2.5.6.2.20120830230313.0ad11708@elandnews.com> <504071D1.3060605@isdg.net> Date: Fri, 31 Aug 2012 07:16:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Authentication-Result (Issue 10?) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 14:16:53 -0000 On Fri, Aug 31, 2012 at 1:12 AM, Hector Santos wrote: > You are missing the point. If the system is already compromized internally, > then the system is already hosed. Nothing can't protect it, Not even DKIM > and in fact, all other security warnings are out the door. If the internal > system has to begin adding DKIM or any other error correction/checking, CRC > or otherwise to protect Receiver-SPF, then why not for Received, From, > Return-Path and all other headers? It isn't about protecting Receiver-SPF > but developing a new local system protocol to protect the entire message > from local system itself. That's all true, but that's not the point being made here. Received-SPF appears to claim safety behind the notion that it will never be reordered, while RFC5322 warns that that's not a good idea. The sponsoring AD, as the author of that RFC, will almost certainly notice that. RFC5451 has a way of dealing with that, and we would therefore only benefit from using it. -MSK From superuser@gmail.com Fri Aug 31 07:18: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 8C22F21F8570 for ; Fri, 31 Aug 2012 07:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gKxK4M5CPic for ; Fri, 31 Aug 2012 07:18:34 -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 C6EE821F856F for ; Fri, 31 Aug 2012 07:18:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so2725847lah.31 for ; Fri, 31 Aug 2012 07:18:32 -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=fmTKJaNTykfA8adhGnSvIfHMizwrCPKXhLc6x68X25Y=; b=rfAB9z18QTDm6VVfxY/zVbBdThrvGO8MAeme20wpWPmNn/1ZIcJdXeQDlZkRuADIjm huEw3zLg9OQnfFLxB1XNVXSrpjZjHjmO6vwlDcy3w2fXnbvlvXLcD9qziT5G8TnrRJN9 FYwrm12QHxT57iXxMBEj1DijhMqlUvBTR/81QFhOCE0ORKsNuk5bIDD1U88akt/oOX6Q GGizH7Ux2KMmrG91KaMh1RqXvQdFCIWRNHsrWr/XsX/zXiXVMjAeXVN9+7K+Hrdtp0dW NFlysKUmYYU0qWWxuWzQdGpNr+2WPVDEYUAFQj2lMGtM+WEbbP5m+ryuWQcko0Nk9OQ3 N4lA== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr2674859lbg.55.1346422712552; Fri, 31 Aug 2012 07:18:32 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 07:18:32 -0700 (PDT) In-Reply-To: <5040732A.4080802@tana.it> References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> <5040732A.4080802@tana.it> Date: Fri, 31 Aug 2012 07:18:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 14:18:34 -0000 On Fri, Aug 31, 2012 at 1:17 AM, Alessandro Vesely wrote: > Non-match makes sense in case the record is correct, but the parameter > is malicious, e.g.: Is there a deterministic way to identify abuse? "Do X if the input data is malicious" is not a recipe for normative guidance. We need to pick the one that's more generally applicable, and move forward with it. -MSK From agthisell@yahoo.com Fri Aug 31 07:39: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 529FB21F8639 for ; Fri, 31 Aug 2012 07:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9mBfJKu4uDK for ; Fri, 31 Aug 2012 07:39:44 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by ietfa.amsl.com (Postfix) with SMTP id BC15321F8634 for ; Fri, 31 Aug 2012 07:39:44 -0700 (PDT) Received: from [98.138.90.52] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 14:39:41 -0000 Received: from [98.138.89.160] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 14:39:41 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 14:39:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 361380.49891.bm@omp1016.mail.ne1.yahoo.com Received: (qmail 92791 invoked by uid 60001); 31 Aug 2012 14:39:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346423981; bh=p9yfTZPpYM133vX6uX6w5S2q9siopBIAIWndwkZZOdA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=xBEcmcFrajhf7aPXU4+RRTXPu+RCxic78p9DDgWiiRyRQN1M5QBC62DFvb0uPzFo83v75oywBt//4dXvaDyG0JayUsNWm09Ii/f2EYEALF9ju/ds37vVCCkYW7V70BV2NduTIjca91vVKHhOe5kFEbsFeylUCEOHeWZWK/5Wf9o= 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:To:MIME-Version:Content-Type; b=kZXJH0UHbgw7LofwkuQlB2lgDNIW9/44pF3WvpPClmh4pKxmLG8SjG6WKiUhcTXmITW0FcTJwzTVZGtsu5g2ZxYJwum2mdGhTrH8XNYykuNZXhFYqP6Hj5RPkAluIMThtPMtrqvwF7e3TTUqyCnvLfiLdRBM5DxwNfkN0blgMns=; X-YMail-OSG: m.kNKjMVM1kDiYNycccvJ1dmm5rpKRxtEM7Y8Ec13vhqB.W fvdR9kwrPe7k_rmvq4UszYBriF3LNASVC16On_f3RraPqc7EfpMn.h8t4VoM BR9JM30KM2J_Lg.T9_59eBEbsFu4a8A0RURFwaixibHgbAUaBujMRUGKadgj b7BD8ULQ_joO2OmarTYQ66.D5bFMOlLEj9Nh5p286NQmmDZTMp2RilwtaLhm tKbLUPKPioRR8F26J69k4SsEyV7w1EL2ljrfKCCGQo0Wk5EwYA9KEkPT03u3 uPfA.wMoY2HMB3SBdcfUFzW_12YO5qJHUU_VMMZ5_NI9Q64Xx66uCDb9CO.u 4.1JH0SzZdq_SVNFbLDW1PN1Q1i6rFMLtItb5ZGfyb9U94aG.4SnkEFOK.00 c6S5Zujz1ZxG60AwlxrYrGQONe7E1W9t0GpkoM6wLf3_VEjtg8b.7jcm3TLd Pbq0_eMAzwGY2mJUaYhg- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Fri, 31 Aug 2012 07:39:41 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346423981.92387.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 07:39:41 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] (no subject) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 14:39:45 -0000 > And then the citation I provided from RFC5322 warns that despite this > normative requirement, there exist programs that do such reordering, > and one must not rely on order. Even the text you quoted from RFC 5322 said that: More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. You are taking warnings about non-trace fields and applying it to trace fields. Lots of stuff breaks when programs violate MUSTs left and right. Yes, programs like PROFS would re-order other header fields, but PROFS was old and almost (does?) predates SMTP. A much more serious problem raised during MARID is that defining a new trace field, we may have to mark RFC 5321/22 as being updated. This was clearly out of bounds for the MARID WG. It is probably out of bounds here. Maybe we should try to get IANA to create a registry for trace fields? From spf2@kitterman.com Fri Aug 31 09:24: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 6763521F864A for ; Fri, 31 Aug 2012 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJNuICz7+xzx for ; Fri, 31 Aug 2012 09:24:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6240821F8648 for ; Fri, 31 Aug 2012 09:24:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8001F20E414A; Fri, 31 Aug 2012 12:24:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346430260; bh=IEDXZr6zgicyyNfbVw05ZF9pNpQhzcKfhoI15/WIIuc=; h=From:To:Subject:Date:From; b=XNI2kwDsvJGqVH+RBgS1ptwZMD19LbgYA+2sst16aYLExUF4hpEOS2KpPhwJ0ruFS qOnWZ66RS00QupbbxMVbsTycr6U4EiThsiDoWxJtYMxRgOLDcbcaHWYl6zg1+B2Nr7 nA7k9Gb1r4spg19wqrL5agtriH/SihrTsZeN2uwA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 53CA820E4071; Fri, 31 Aug 2012 12:24:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 12:24:19 -0400 Message-ID: <1378842.l9NQS7aiuB@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] SPF Modifier Registry X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 16:24:26 -0000 Due to RFC 6652, there is an IANA registry for SPF modifiers. See: http://www.iana.org/assignments/spf-parameters/spf-parameters.xml We don't currently mention this is 4408bis at all, which seems odd to me. I think it should be brought in somehow, but I'm not sure how. Suggestions? Scott K From agthisell@yahoo.com Fri Aug 31 09:48: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 462CF21F859A for ; Fri, 31 Aug 2012 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+e1vuDEtga2 for ; Fri, 31 Aug 2012 09:48:35 -0700 (PDT) Received: from nm31-vm1.bullet.mail.ne1.yahoo.com (nm31-vm1.bullet.mail.ne1.yahoo.com [98.138.229.41]) by ietfa.amsl.com (Postfix) with SMTP id A125921F8566 for ; Fri, 31 Aug 2012 09:48:35 -0700 (PDT) Received: from [98.138.90.50] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 16:48:28 -0000 Received: from [98.138.89.248] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 16:48:28 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 16:48:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 682247.28739.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 87734 invoked by uid 60001); 31 Aug 2012 16:48:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346431708; bh=6VjgTQobL0km+Ysvs+VHMzgdm+qpaYea5ygRwcGBFCI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=JwKxYqcBVQ15Rl+0NJ15xm/Vqx5ck9w1NlJaMiiSUDU347f9LPa7A3jTkjSGqEqGmH4jSmse7Bp606JNyOIgobCjEO51EJL+Lov6LF2q/s6RSlJM0PjQh2EfaBh0PsA62aJsG6dRVuUHc248xu+eiBWjWE3Cu8w4bW1PjW9V0es= 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=cNruijhhxiUJ70YBblJdlYJu9vyC5dMPItyH2FWEYvpMjP/PMYWSEEWgvqWwSMaWrD9TVHLmmM1i0125muOPOFM4/g2yOBtmIkLTXojaqn0DMz1/mIW7VtPGthXSJ/quhCZ8eISG5EnLqK8eCadlen53MFQawW+Loq1MB/NHKJI=; X-YMail-OSG: 8S4nl5gVM1lYu1MgYUIIfHJ3EkKGzIr0Rcoq6Mb7rwwBvWN WwuZ3J35HZJQsTKbgMHj.UJ.HAYijv2RiHKmrM9waFT5FIjl7oW6JRrxZ484 ziOkzGYL2IOcn5Ll9FwN6pWBUtQuE3FJ2ul0iFh..Zcsn9e.9zFXv3XyUmrx 2w6UGbvXRdnGpdsLxTPrELecn3LH3COXl16.EUOq28l3.yxjBTFqC4vYYsV3 QWHdZmjW_Vn.BZvnz04iJm8zlnzneYaV07Rv4kBRaQHg3xVKV1BNM5qfu7UQ xCsBvhHTZzVQVLItGbfAW9ABmQvEesSJ4awBBPG906dA1L9RGYFzJ3gbqpU6 ZjljV8gf6vIClSP8TngXCXM7H0vT2UXNKnin3bAiK2SftJZQPbRchFVAjVJ5 iJIQW5WTKrc5UvEoxjWDhum0A7T7AeEEPHGUw3me9KZIu2SLok_7USW6HssG 32_5w8ZYt7s8T8aKbHqF12DKg5EtPhQ-- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Fri, 31 Aug 2012 09:48:28 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346431708.82840.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 09:48:28 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Bloating the 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: Fri, 31 Aug 2012 16:48:36 -0000 OK, I've mentioned this once before, but the size of RFC4408bis is bothering me. draft-mengwong going into MARID: 36 pages, about 9 months of writing coming out of MARID: 46 pages, about 4 months of writing RFC4408: 46 pages, about 9 months of writing (IESG appeals delayed publication) RFC4408bis (excluding appendix C): 63 pages, about 3 months of writing We have bloated the spec by over 35% so far. What value have we gotten for all that? Every page is more stuff people have to wade through to find the important stuff. For comparison: RFC5322 has only 55 pages. RFC5321 has 94 pages, but it defines all of SMTP RFC6376 has 75 pages to define DKIM! RFC5451 has 43 pages to define a single header field! Ugh. If the quality of a standard was measured in pages, OSI would have crushed the IETF. I thought it was a bad sign that SPF needed 46 pages, just to add an extension to SMTP. Do we *really* need a long intruduction, with a protocol status and history subsections? The protocol status was important when SPF has been beaten around for years, but now it is on the standard track. Do we really need the section on wildcards? Yeah, RFC4408 was drafted around the time that the DNS folks were doing a lot of stuff with wildcard records and there was a lot of concern about them, but could we cut it down and and make a few mentions in other sections? Do we really need section 9 (implications) to be 9 pages long Do the macro examples (8.2) need 2 pages? I haven't put serious thought into eliminating those sections, so don't open tickets for them, but this WG seems to be all too willing to add stuff, and not willing to cut anything out. From superuser@gmail.com Fri Aug 31 09:53: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 B1B5F21F8618 for ; Fri, 31 Aug 2012 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgrm2FEH88-n for ; Fri, 31 Aug 2012 09:53:18 -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 8C68621F85DA for ; Fri, 31 Aug 2012 09:53:18 -0700 (PDT) Received: by lbky2 with SMTP id y2so1641313lbk.31 for ; Fri, 31 Aug 2012 09:53:17 -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=oSHml4sJol/8EK2enGfGe/xqw6JgV80gB/5ZIvOS3ck=; b=TZiTKlbHaijJHcg4gYtLCpYDMJCoF+5jcO+iTGCCX3HTPpVno6m8EdDCIUbOtyAI1B NIyfAVYNTmZXRnlxs2RFogzxfjWJ7aqiNMXJNPgQalrypdCzo5HQdJtR7RY9+KkwmbJN ACMnGEullP0XKMPL/PIWSQcwf0iiYtVWQ62JwqTGEfsamy96b7CjNPTmcFKb0gICkI7c PYH/f66iUQyy6i0Jj8gfroSwnUSrBRnW7bO9l3fLocyXIGfKL0vjpvDTaVxUvILrssQN c7cLFALSt9X3bR2x/j8AH64+h9uFA/swhjH7gCY2THA53nEghmeWly/vk00ejcDH5IPh EMzQ== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr7128824lab.35.1346431997383; Fri, 31 Aug 2012 09:53:17 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 09:53:17 -0700 (PDT) In-Reply-To: <1346423981.92387.YahooMailClassic@web125405.mail.ne1.yahoo.com> References: <1346423981.92387.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 09:53:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] (no subject) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 16:53:19 -0000 On Fri, Aug 31, 2012 at 7:39 AM, Arthur Thisell wrote: > Even the text you quoted from RFC 5322 said that: > > More importantly, the trace header fields and resent > header fields MUST NOT be reordered, and SHOULD be kept in blocks > prepended to the message. > > You are taking warnings about non-trace fields and applying it to trace fields. The citation included this: It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. That admonition is not specific to trace fields or to non-trace fields, but to all fields. Yes, of course, an agent that does reordering contrary to the normative assertions violates the specification, but that doesn't mean it doesn't happen. So do we presume compliance, or do we defend against extant non-compliance that can confound end user agents or internal filters? I seem to recall from the DKIM work that there's far more recent MTA software (compared to PROFS) that does undesirable reordering or reformatting of header fields, including trace data. > Maybe we should try to get IANA to create a registry for trace fields? That was proposed either on ietf-smtp or apps-discuss during the discussion of the received-state draft recently, but it didn't go anywhere. -MSK From superuser@gmail.com Fri Aug 31 10:08: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 79ECB21F852C for ; Fri, 31 Aug 2012 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-Y-Dpxp6j67 for ; Fri, 31 Aug 2012 10:08: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 A98BE21F84B5 for ; Fri, 31 Aug 2012 10:08:58 -0700 (PDT) Received: by lbky2 with SMTP id y2so1652829lbk.31 for ; Fri, 31 Aug 2012 10:08: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=jvLziHdTfeeYMGxL1Z5j9/gKJsfFG3zpaQT61Ru0hfo=; b=vBsaWQ+2Vdf75ijzTPpsYvRAMqVU7ZvBbAUtNnAucVg8NVTPH3Q2mLhx+0i6SXj0NY IxjI+8q5x+DfZgvPd1DkkjoKX/3zAojU3C/1xltJrPV5FM91zCCgxrdeF1wB8zAcJc0u wUpBJv/mR71djy2ulCdPPZf1Auaiwbrha+lvfWkWQP7EB/4MEHDSVptWJ2purpUOMDMk 4IRnD9Hd65HMw+doyY5mZ6Rd6H+XqoseZFIYZNv9D6O+vVQkOZnxiaKg5ryCx5zbr7Cp 5kZu1eXaMNhbMHfsQFrMzu0ilHpc4PB4rZtHWNx1z4dV62/TkCPxt5M0jPnGGV67W70e 5/LQ== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr7135908lab.41.1346432937583; Fri, 31 Aug 2012 10:08:57 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 10:08:57 -0700 (PDT) In-Reply-To: <1346431708.82840.YahooMailClassic@web125405.mail.ne1.yahoo.com> References: <1346431708.82840.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Fri, 31 Aug 2012 10:08:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Bloating the 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: Fri, 31 Aug 2012 17:08:59 -0000 On Fri, Aug 31, 2012 at 9:48 AM, Arthur Thisell wrote: > RFC6376 has 75 pages to define DKIM! > RFC5451 has 43 pages to define a single header field! I would love to know what you think might reasonably have been excluded from either of those, especially when reviewing their respective paths through the formal evaluation processes. There's a lot of context the transition from RFC4408 carries with it to this document. Also, this document will undergo actual IESG review where RFC4408 did not. > Ugh. If the quality of a standard was measured in pages, OSI would have crushed the IETF. I thought it was a bad sign that SPF needed 46 pages, just to add an extension to SMTP. I think 46 pages is pretty typical these days for what SPF tries to accomplish. So I'm not sure I agree that page count is a useful metric for document quality. Looking at the diff you cited earlier between RFC4408 and this draft, the bulk of the added text is in Section 9 and Appendix C. The remainder is largely rewording or an added sentence here or there. It doesn't really look like 17 pages were added. I wonder if a lot of this is just related to cumulative formatting changes since xml2rfc came along. But I don't feel that adding text that documents six years of experience (which includes describing some deep philosophical divides) and the advice based on same can be considered unwarranted bloat. Mail is a funny space, unlike most others; local policy and subjective interpretation of data often need to be discussed, something through which other protocol layers don't generally need to suffer. And security protocols often come with a lot of pedagogy. -MSK From superuser@gmail.com Fri Aug 31 10: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 E15EF21F8598 for ; Fri, 31 Aug 2012 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTO4TyLCEvPb for ; Fri, 31 Aug 2012 10:11:21 -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 21D2921F8530 for ; Fri, 31 Aug 2012 10:11:20 -0700 (PDT) Received: by lbky2 with SMTP id y2so1654441lbk.31 for ; Fri, 31 Aug 2012 10:11:20 -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=uPTiJiTAz5KMF4cjoLusoUNEUh6ryapMcam+HGPkA8M=; b=U3ZraOlkJYPRFkhGzXEF74JxLVnbHhj0BecxLSB9KSnwKdVX1kbcm7hJ6iOOiPb0Vi +3EQ9+2OrEtk1BBYEQxL8b4HMNvT2TXzF9Hve8H6EpCR2YBs+c+VCA5YXV+G9JIjh44o 469nWnrXtrOhwIWKTWuCJABaGzfMUzaQx3uSRAE2Fb178fSKIvqM1UhOQ1UZlIvZjkGE m7yWNYvKZurwVKVH/yGPfpOCZz9lvjep/2hawdR8sNPTKBAuUbWl/zJ+wdJEu0EJm1Gl 9R7wfWi2zJ+tETIou/GlYwIt4VVo4QZEdHWzRQlNtA644upWbDjXCnOt8djbEVmS+Xq1 ZtBw== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr2847272lbb.72.1346433079959; Fri, 31 Aug 2012 10:11:19 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 10:11:19 -0700 (PDT) In-Reply-To: <1378842.l9NQS7aiuB@scott-latitude-e6320> References: <1378842.l9NQS7aiuB@scott-latitude-e6320> Date: Fri, 31 Aug 2012 10:11:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF Modifier Registry X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 17:11:22 -0000 On Fri, Aug 31, 2012 at 9:24 AM, Scott Kitterman wrote: > Due to RFC 6652, there is an IANA registry for SPF modifiers. See: > > http://www.iana.org/assignments/spf-parameters/spf-parameters.xml > > We don't currently mention this is 4408bis at all, which seems odd to me. I > think it should be brought in somehow, but I'm not sure how. > > Suggestions? Good point. A new subsection (sorry, Arthur) of the IANA Considerations section of RFC4408bis needs to say that the SPF modifier registry is updated to indicate RFC4408bis is now the defining document for exp and redirect. -MSK From sm@elandsys.com Fri Aug 31 10:19: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 3997A21F85AD for ; Fri, 31 Aug 2012 10:19:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXPp0H73pG1r for ; Fri, 31 Aug 2012 10:19:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D06921F85A8 for ; Fri, 31 Aug 2012 10:19:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VHJRul004177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Aug 2012 10:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346433579; bh=TEgz3MRH/ORvbUZxEmnM9vCs2LO7QLNOHA4meV3JAd0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SJ4n5dtt8gNuz+y4F0GFWkTuGQ6UwOzr4lJOJCj6ng+tkH9mZNgpZIMMEdTru5k+P zsl43wzR5K7SG3oRuc0dtUSqdeFDX52hz8IB65x+7I6lmTJMGV/OvZXXlPXprtXobZ jvw3bkWY4Fb90ouvXz6/G11/JSkxkWjHHuLpl22A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346433579; i=@elandsys.com; bh=TEgz3MRH/ORvbUZxEmnM9vCs2LO7QLNOHA4meV3JAd0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=rhZGoeFu+eE2BXYB9HsXclx+AjzJ7SqLf6OUZKHYmmsZGfgnIgtK5uRWPYoczgz0c vJE14u4n98yZ5+RDrWtQZ4mc6OO5PDD6m5rFgJWglpzavrZ7RD+654dXbBheIC8mdK FL/qFDJAPbds8E8JHUgYWDAchYgnw4q+0/PmhGJc= Message-Id: <6.2.5.6.2.20120831090529.0a5d6b48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 10:18:55 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1346423981.92387.YahooMailClassic@web125405.mail.ne1.yahoo .com> References: <1346423981.92387.YahooMailClassic@web125405.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Trace fields X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 17:19:42 -0000 At 07:39 31-08-2012, Arthur Thisell wrote: >Even the text you quoted from RFC 5322 said that: > > More importantly, the trace header fields and resent > header fields MUST NOT be reordered, and SHOULD be kept in blocks > prepended to the message. > >You are taking warnings about non-trace fields and applying it to >trace fields. > >Lots of stuff breaks when programs violate MUSTs left and >right. Yes, programs like PROFS would re-order other header fields, >but PROFS was old and almost (does?) predates SMTP. > >A much more serious problem raised during MARID is that defining a >new trace field, we may have to mark RFC 5321/22 as being >updated. This was clearly out of bounds for the MARID WG. It is >probably out of bounds here. > >Maybe we should try to get IANA to create a registry for trace fields? There is an expired draft about such a registry. That's out of scope for this working group. As mentioned above an update RFC 5321 or RFC 5322 is out of bounds. I suggest that WG participants step back a little and look at the security angle instead of RFC 5321 or RFC 5322. I posted the following some time back: - which attacks are out of scope (and why!) - which attacks are in-scope * and the protocol is susceptible to * and the protocol protects against I would ask the above for the Received-SPF: header field. Here's an excerpt of a message about an unrelated draft (the quote level is unrelated to SPFBIS messages): >>The alternatives, as I see it, for the first sentence are: >> >>(a) Do you want people to go and write code so that the site administrator >> can enforce such a policy? > >I want server developers to take this into consideration and expose >any possible management knobs to administrators. > >>(b) Do you want people to "think" about this as a security consideration? > >Yes. > >> (c) Do you want to enjoy the summer weather instead of generating more >> mail traffic? > >Most certainly, yes :-). For context, the discussion was about finding an acceptable alternative without too much stress. The author explained clearly what he wanted. That made it easy to come up with a solution. I don't know how to explain this. I'll rely on the indulgence of WG participants. The WG is exploring tangents when there is already prior work discussing about such a problem. Regards, S. Moonesamy From superuser@gmail.com Fri Aug 31 10:39: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 076F821F8622 for ; Fri, 31 Aug 2012 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRUE9CDsQzPB for ; Fri, 31 Aug 2012 10:39:21 -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 BB5AB21F8646 for ; Fri, 31 Aug 2012 10:39:20 -0700 (PDT) Received: by lahm15 with SMTP id m15so2873345lah.31 for ; Fri, 31 Aug 2012 10:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=E9dASlxaHcsEkvM9I0YaKbDaRd2isPDJZgpWR/yE8q0=; b=tSFMt3UcSXChPkFzi8cE3yzmVtQQSS8ymmNwkvKW/30ov8TmbBFBcSa3U+RzEq8AKl 5ANWEjnq8IRcr+bQC1wvlk38XIiFGzqctzA8sHLTDBc/F3NXOTVcfCVFcsDeXbW2dh27 Kv2myAfmUQi7z+Z1kSXZPiTKWDvIWJqZHK0V56kJfep2M9N4vxJz+++UCo1HE/7fM9wd No+uhY8n7qiV4DYiXHlfNX+88+0zV3GZAxMzEvFHxRud8QInOyeYH3kuZXlSriLd8wJd wNN/oYrrVmwHfFHusCgOBlaU4hbc54LAsp4WhVaW9mIqSmBlnAUpIBQmexSmk/m457jc brzA== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr7225320lab.35.1346434759661; Fri, 31 Aug 2012 10:39:19 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 10:39:19 -0700 (PDT) Date: Fri, 31 Aug 2012 10:39:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 17:39:22 -0000 7. Recording The Result For operators that choose to record SPF results in the header of the message for processing by internal filters or MUAs, two methods are presented. Section 7.1 defines the Received-SPF field, which is the results field originally defined for SPF use. Section 7.2 discusses Authentication-Results [RFC5451] which was specified more recently and is designed for use by SPF and numerous other authentication protocols. Both are in common use, and hence both are included here. However, it is important to note that they serve slightly different purposes: Received-SPF is intended to include enough forensic information to enable reconstruction of the SPF evaluation of the message, while Authentication-Results is designed only to relay the result itself and related output details of likely use to end users (e.g., what property of the message was actually authenticated and what it contained), leaving forensic work to the purview of system logs and the Received field contents. Also, Received-SPF relies on compliance of agents within the receiving ADMD to adhere to the header field ordering rules of [RFC5321] and [RFC5322], while Authentication-Results includes some provisions to protect against non-compliant implementations. An operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure both fields are conveying the same details, or unexpected results can occur. 7.1. The Received-SPF Header Field 7.2. The Authentication-Results Header Field [RFC5451] defined the Authentication-Results header field and included provisions for reporting SPF results to downstream agents. As noted above, however, it lacks the capability to include certain forensic details. If an operator wishes to use this field, the missing forensic details could be included either in the "reasonspec" or in header field comments, which can then be extracted and used by downstream agents. For example: -MSK From spf2@kitterman.com Fri Aug 31 11:18: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 50FF321F84AF for ; Fri, 31 Aug 2012 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHgACZAUH2Gk for ; Fri, 31 Aug 2012 11:18:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0EB21F84A1 for ; Fri, 31 Aug 2012 11:18:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CB31420E414A; Fri, 31 Aug 2012 14:18:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346437112; bh=zTe1Vm2/UmjYOuKQoBLcugsymQ2IR0nGIuo5RVmUdu8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VzLqqSTCYt7ZOrO2LVLptccelWZ+as0s1OdqM0YVrDL6z6+BVnlrAOudm9/DyOCL1 M7QO/GKic7/E4oy4k/BbEFCGf774b34oqH83DvFFpBxAzr5yyA7ejkLwGS6kOtF2PF 8/X500CW0VL1Vp6Q4VClkc2OEIicH9I+DQo0hAoM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A00A320E4071; Fri, 31 Aug 2012 14:18:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 14:18:31 -0400 Message-ID: <1861843.9UWIgLTYo2@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:18:34 -0000 On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: I think, before discussing the specific text, we should resolve what to do about the fundamental idea of adding a header field. Your proposed text starts: > 7. Recording The Result > > For operators that choose to record SPF results ... RFC 4408 starts: > It is RECOMMENDED that SMTP receivers record the result of SPF > processing in the message header. Was this change intentional and if so, what was the rationale? I don't recall any discussion that adding a header field was a bad idea. Scott K From sm@elandsys.com Fri Aug 31 11:19: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 1337A21F84C2 for ; Fri, 31 Aug 2012 11:19:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0Wt03juuwbS for ; Fri, 31 Aug 2012 11:19: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 0EE6521F84AF for ; Fri, 31 Aug 2012 11:19:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VIJBns021960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 11:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346437163; bh=sFaBBT5hnzb5DtOAX3ygDs4MEEuABN7AU0ZRhgvtvxE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j4wTC92V6/pOM0oeR/CJ+V0ItACruAeDypFBd7qAOuHn/xrg4FrMVkgelKNE8TxYM 1t4vx3HIQhJ+pIh0cplsY5a8YvYTBVUmcD4JcIEMyC7QnfQSnRJVgfcbQwP0AKIlHW ID6jixfzXqE8kChlfbuEKnr+whcynP9ys4LTVaAk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346437163; i=@elandsys.com; bh=sFaBBT5hnzb5DtOAX3ygDs4MEEuABN7AU0ZRhgvtvxE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=D/IKTapZKdJxMwvptP9h7BD3Uyqi1J/mbGrAPOLbj2/OiQsSZaqoDz2c6WO3Mc+/C AmVr3j99X4v7VPeCQ2LRB+6dqptQGq+yHxuusKuqaFwZ+3OCrzA4W0bSvl5WKZIZjG yshnG4R9cbZh4OSJNjd7uOdsbBycjvHelA6KGics= Message-Id: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 11:19:08 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:19:27 -0000 Hi Murray, At 10:39 31-08-2012, Murray S. Kucherawy wrote: >7. Recording The Result > >For operators that choose to record SPF results in the header of the >message for processing by internal filters or MUAs, two methods are >presented. Section 7.1 defines the Received-SPF field, which is the >results field originally defined for SPF use. Section 7.2 discusses >Authentication-Results [RFC5451] which was specified more recently and >is designed for use by SPF and numerous other authentication >protocols. > >Both are in common use, and hence both are included here. However, it >is important to note that they serve slightly different purposes: >Received-SPF is intended to include enough forensic information to >enable reconstruction of the SPF evaluation of the message, while >Authentication-Results is designed only to relay the result itself and >related output details of likely use to end users (e.g., what property >of the message was actually authenticated and what it contained), >leaving forensic work to the purview of system logs and the Received >field contents. Also, Received-SPF relies on compliance of agents >within the receiving ADMD to adhere to the header field ordering rules >of [RFC5321] and [RFC5322], while Authentication-Results includes some >provisions to protect against non-compliant implementations. > >An operator could choose to use both to serve different downstream >agents. In such cases, care needs to be taken to ensure both fields >are conveying the same details, or unexpected results can occur. Thanks. The text is well-written. I don't think that the working group will get away with "relies on compliance within receiving ADMD" to address security considerations about the Received-SPF: header field. John Levine commented on possible issues if an operator chooses to use both headers. You covered that in the second sentence of the third paragraph. I am not comfortable with that as it looks like DISCUSS material. I'll advise the working group against that to be on the safe side. >7.1. The Received-SPF Header Field > > The following text can be used to argue about the forensic information: "The following key-value pairs are designed for later machine parsing. SPF verifiers SHOULD give enough information so that the SPF results can be verified." Parallels will be drawn between the two header fields. >7.2. The Authentication-Results Header Field > >[RFC5451] defined the Authentication-Results header field and included >provisions for reporting SPF results to downstream agents. As noted >above, however, it lacks the capability to include certain forensic >details. > >If an operator wishes to use this field, the missing forensic details >could be included either in the "reasonspec" or in header field >comments, which can then be extracted and used by downstream agents. >For example: > > I previously mentioned that Section 7.2 looks like an update to RFC 5451. if you feel strongly about the above, I'll suggest folding the text into Section 7. I would like to look at stable text (one that the WG can agree on) to have a better view of the implications. Otherwise, I will be looking at one alternative instead of considering all the alternatives. The text is a good starting point. Regards, S. Moonesamy From superuser@gmail.com Fri Aug 31 11:35: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 A5DA421F8539 for ; Fri, 31 Aug 2012 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPwaA+1KuJfW for ; Fri, 31 Aug 2012 11:35:38 -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 D7F2821F8534 for ; Fri, 31 Aug 2012 11:35:37 -0700 (PDT) Received: by lahm15 with SMTP id m15so2910583lah.31 for ; Fri, 31 Aug 2012 11:35: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=kCcA/gG9IPXZmteRjqvsiqnyblA7dGoAHQTDsqGyzcs=; b=lAMGKoJXG+E8AscPeO2dVSopoR16lOBSy0afHQ3iJmwaVUyPJOV3glmSBJ6qFnzxQC 1d+UcZGGWtzoGNVnH6CsDZOh3ykGPhKJf+trB+US9jk6Lb0Qz2rK1mca4Qkhl0qLi9aZ IiSaeeCBJ4oP27+H50i7p9l8iOdDOF25JB4jOokRGHLfDrFWASuVKBghZQAboZfAnf43 umkgaaQGqs3rAigArsxKlIngcyjgJMpsl4cDm7QW6jPrS6UHaLwIkg8+B+UxiwYgdvUV Lztc8mmLigUkb/dcI3GpmMQh5a9gE/pDPR4oU/EnfTMFT/5DeCurvkgMzMeziIiGR0yH Algw== MIME-Version: 1.0 Received: by 10.152.103.244 with SMTP id fz20mr7351136lab.54.1346438136836; Fri, 31 Aug 2012 11:35:36 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 11:35:36 -0700 (PDT) In-Reply-To: <1861843.9UWIgLTYo2@scott-latitude-e6320> References: <1861843.9UWIgLTYo2@scott-latitude-e6320> Date: Fri, 31 Aug 2012 11:35:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:35:38 -0000 On Fri, Aug 31, 2012 at 11:18 AM, Scott Kitterman wrote: > On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: > > I think, before discussing the specific text, we should resolve what to do > about the fundamental idea of adding a header field. Your proposed text > starts: > >> 7. Recording The Result >> >> For operators that choose to record SPF results ... > > RFC 4408 starts: > >> It is RECOMMENDED that SMTP receivers record the result of SPF >> processing in the message header. > > Was this change intentional and if so, what was the rationale? I don't recall > any discussion that adding a header field was a bad idea. I don't think it's a bad idea, but it is still an operator choice. On the basis that SPF is a protocol primarily between MTAs, not adding a field at all doesn't violate that interoperability so the RECOMMENDED isn't really meaningful. However, in the interests of staying consistent with RFC4408, I'd be fine restoring that sentence. -MSK From superuser@gmail.com Fri Aug 31 11:40: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 D0D4A21F8539 for ; Fri, 31 Aug 2012 11:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whmjtnCda8nM for ; Fri, 31 Aug 2012 11:40:51 -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 6AC3721F8523 for ; Fri, 31 Aug 2012 11:40:51 -0700 (PDT) Received: by lahm15 with SMTP id m15so2914020lah.31 for ; Fri, 31 Aug 2012 11:40:50 -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=rU19wCKKeSmiWq3JlMWLoNJ9kukdwzc3g3uRu32D+Tc=; b=LaU/QWZOmkoFjNBDBZdIXSmmYkpu2VaPLr0S/HCWRe0jMgjQOZYLi0Af7UdrQy4gl1 nN6PCc5lvrRUhEbI4ziL5v+UDLUz8JaVqSKRtQnDJMKCTVafuuA8wGDaGUhpI3Ack8Ib u82rarXhV30KctrxfXl69YkbnX0vyae3E0x8N+qV5zKbaRHtbd/Zex2aGmSIUfZRlbeF SndHPJf9YBBASCJr7eRlcMcTsC4Ysbv0F/JAOikwNtzzTSYBQ8SaplD7lnRci8ZvJD4e oX4Necr0dkkYfgidQ7vjeVJ9R3oewqZGElgNcHqAKPZuifkmwgfzojZOGwYeI1gmKk0b ywZw== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr7315224lab.41.1346438450291; Fri, 31 Aug 2012 11:40:50 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 11:40:50 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> References: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> Date: Fri, 31 Aug 2012 11:40:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:40:52 -0000 On Fri, Aug 31, 2012 at 11:19 AM, S Moonesamy wrote: > Thanks. The text is well-written. I don't think that the working group > will get away with "relies on compliance within receiving ADMD" to address > security considerations about the Received-SPF: header field. Why? > John Levine commented on possible issues if an operator chooses to use both > headers. You covered that in the second sentence of the third paragraph. I > am not comfortable with that as it looks like DISCUSS material. I'll advise > the working group against that to be on the safe side. In that we can't remove Received-SPF since it's in use, but A-R is increasing in use, it seems that we are in a position where providing both options is entirely appropriate. Since there's been pressure even at the IESG level to be forward-compatible, I think we're going to get less resistance than you're predicting. > I previously mentioned that Section 7.2 looks like an update to RFC 5451. > if you feel strongly about the above, I'll suggest folding the text into > Section 7. It's not an update in the normative sense. It suggests possible use. It doesn't rise to the level of an applicability statement. I think it's fine. -MSK From spf2@kitterman.com Fri Aug 31 11:40: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 E7F0E21F855E for ; Fri, 31 Aug 2012 11:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYJmrMDoqGf3 for ; Fri, 31 Aug 2012 11:40:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85021F8534 for ; Fri, 31 Aug 2012 11:40:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B4AF420E414A; Fri, 31 Aug 2012 14:40:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346438455; bh=OWiVoC7Ox3iBUMH43aaAYDXXccszNfUdZGGnkZ/CSAQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cGIxAcCYfNh0vrBlsilCwNVVjDv8Vz4+K9LIkk22hFzzA5pPcRl3tOrB2fQC9veIr 4OJHTeRFX2EbgFMhlW3+4N0P7wRwbTiyGsV1nwTm5Ctgx9H/iTOMENjjSbGEhA8Rsj 0Ea/IAzBHCS0o2ZLyL+B8hkHJFNJSDFvEHpaoAfg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9C81120E4071; Fri, 31 Aug 2012 14:40:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 14:40:55 -0400 Message-ID: <2987575.8EimHC5yT4@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1861843.9UWIgLTYo2@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] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:40:57 -0000 On Friday, August 31, 2012 11:35:36 AM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 11:18 AM, Scott Kitterman wrote: > > On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: > > > > I think, before discussing the specific text, we should resolve what to do > > about the fundamental idea of adding a header field. Your proposed text > > > > starts: > >> 7. Recording The Result > >> > >> For operators that choose to record SPF results ... > > > > RFC 4408 starts: > >> It is RECOMMENDED that SMTP receivers record the result of SPF > >> processing in the message header. > > > > Was this change intentional and if so, what was the rationale? I don't > > recall any discussion that adding a header field was a bad idea. > > I don't think it's a bad idea, but it is still an operator choice. On > the basis that SPF is a protocol primarily between MTAs, not adding a > field at all doesn't violate that interoperability so the RECOMMENDED > isn't really meaningful. > > However, in the interests of staying consistent with RFC4408, I'd be > fine restoring that sentence. Thanks. I think it's better to stay consistent without a strong reason to change. Scott K From spf2@kitterman.com Fri Aug 31 11:51: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 E1CF921F8570 for ; Fri, 31 Aug 2012 11:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLjz6+VGxmRc for ; Fri, 31 Aug 2012 11:51:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DC2FF21F856F for ; Fri, 31 Aug 2012 11:51:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DC6020E414A; Fri, 31 Aug 2012 14:51:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346439091; bh=/1SS+KQbF1sO/iJI4d9uK3wDobDfTgPt+BE1r8ozsk8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SDa+QTZkXnKDdN1xA0eFGRMTrzqZlSQghfDPRLgd2tD1TiHPkcvRwMzpvsSpor3CJ uJ0k34FlZK6Plm+CIaLMdGxRwrjCVQsYOkd+q8QRSqJSrYrHmN0d+HUaSOrbUA2DzC T8iBgzgm6Q8b9BY/T5DWObR1V/rLxF67cXumhapU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3BE5520E4071; Fri, 31 Aug 2012 14:51:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 14:51:30 -0400 Message-ID: <2385202.ToyOPapQOP@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:51:33 -0000 On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: > 7. Recording The Result > > For operators that choose to record SPF results in the header of the > message for processing by internal filters or MUAs, two methods are > presented. Section 7.1 defines the Received-SPF field, which is the > results field originally defined for SPF use. Section 7.2 discusses > Authentication-Results [RFC5451] which was specified more recently and > is designed for use by SPF and numerous other authentication > protocols. > > Both are in common use, and hence both are included here. However, it > is important to note that they serve slightly different purposes: > Received-SPF is intended to include enough forensic information to > enable reconstruction of the SPF evaluation of the message, while > Authentication-Results is designed only to relay the result itself and > related output details of likely use to end users (e.g., what property > of the message was actually authenticated and what it contained), > leaving forensic work to the purview of system logs and the Received > field contents. Also, Received-SPF relies on compliance of agents > within the receiving ADMD to adhere to the header field ordering rules > of [RFC5321] and [RFC5322], while Authentication-Results includes some > provisions to protect against non-compliant implementations. > > An operator could choose to use both to serve different downstream > agents. In such cases, care needs to be taken to ensure both fields > are conveying the same details, or unexpected results can occur. > > 7.1. The Received-SPF Header Field > > > > 7.2. The Authentication-Results Header Field > > [RFC5451] defined the Authentication-Results header field and included > provisions for reporting SPF results to downstream agents. As noted > above, however, it lacks the capability to include certain forensic > details. > > If an operator wishes to use this field, the missing forensic details > could be included either in the "reasonspec" or in header field > comments, which can then be extracted and used by downstream agents. > For example: > > I think (with the RECOMMENDED change already discussed upstream) this is pretty good. Can we squeeze the suggestion to use the SPF-Received key-value- list to add details to A-R into here? I don't think it needs to be more than 'here's a reasonable way to do it', but I'd like to at least suggest something if people want to go down this path (and it helps support the example, which does exactly that). Scott K From superuser@gmail.com Fri Aug 31 11:55: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 5D35B21F84CF for ; Fri, 31 Aug 2012 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFxlzZB6IvMG for ; Fri, 31 Aug 2012 11:55:47 -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 94D1921F84C4 for ; Fri, 31 Aug 2012 11:55:46 -0700 (PDT) Received: by lahm15 with SMTP id m15so2923988lah.31 for ; Fri, 31 Aug 2012 11:55: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=rbDaDgtJlajK5q3HkTF8rba/brd7yKIHrE9Ke85R4Ok=; b=Ao3fRzO5nyTXF44rRV79MZF+uqXI52wn+nbouxBPO5eaO9BnEKRUg87MgnjmJWe47T O2iVImxaF6PuuWhGI5S07UT7QDGTzNT6TptXNpG0J/s0GHfSPoIIadivkSwQL9OOi8hG s6xY5+07X9hb1mrpWYeU+tELWO92797Gwdc821na8iQPPtf+eKQpiEjeVernQeI3xvrJ gSlV535X1cd8sKBduiIX+4YLISVycifiTS9H7jAqZg5irnDUVnimHXbBoD1Wwk0Pq8wl 3oG3dhkL8hOQt2r+RBCWBeuCMd89YbSf6SBfvr9W+qvftwfh8rXDG9eDq7Hnh0eOBGTx rijw== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr7341906lab.41.1346439345585; Fri, 31 Aug 2012 11:55:45 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 11:55:45 -0700 (PDT) In-Reply-To: <2385202.ToyOPapQOP@scott-latitude-e6320> References: <2385202.ToyOPapQOP@scott-latitude-e6320> Date: Fri, 31 Aug 2012 11:55:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:55:47 -0000 On Fri, Aug 31, 2012 at 11:51 AM, Scott Kitterman wrote: > I think (with the RECOMMENDED change already discussed upstream) this is > pretty good. Can we squeeze the suggestion to use the SPF-Received key-value- > list to add details to A-R into here? I don't think it needs to be more than > 'here's a reasonable way to do it', but I'd like to at least suggest something > if people want to go down this path (and it helps support the example, which > does exactly that). You could do that in a sentence or two right before including your example. Just don't use any normative language to say you SHOULD or MUST do it this way and I think it's fine. -MSK From sm@elandsys.com Fri Aug 31 11:58: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 B4F3D21F848F for ; Fri, 31 Aug 2012 11:58:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEwDmRxu-Jx1 for ; Fri, 31 Aug 2012 11:58:39 -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 79F6B21F8475 for ; Fri, 31 Aug 2012 11:58:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VIwJJS020615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 11:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346439515; bh=UWBKHmV+QnlU35uZbeevNRV35S98oOCapBzZE1zrTYQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kURlPEVbArfTB9SX5LNJ6j4ZUpVFfH/sjwzZe+SOTO3H2TgwrN+02hcpE8LoUPWS6 PgGoTxUQo2Y9Dt2duZ9nroAV73O8fJh1cE6MXPtFY85eLe8LJh66wXrkOlSUEsOgcC U7kWUVMTKvTo3Csof3jSXPRuAgPZ3Gshj+xi8crM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346439515; i=@elandsys.com; bh=UWBKHmV+QnlU35uZbeevNRV35S98oOCapBzZE1zrTYQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LYIpZD5cTolPjmU5Db5sLwZ0zZnI6SLFWkX3RMqZWzEoinGq4oes86RwHcHZYDAkg E8evC6m4Lwl200BWCDz/7qNeSibnzMLI3gRITkeFgKnlIW1OMvHiUM7NPgPeBTWYMC +ViilT6Y4Tm5lzZ8EcZqEchQrCl58GLTLMvsu+sk= Message-Id: <6.2.5.6.2.20120831114210.099fe480@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 11:55:44 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 18:58:40 -0000 At 11:40 31-08-2012, Murray S. Kucherawy wrote: >Why? If the argument wasn't convincing for Authentication-Results:, it won't be convincing here. >In that we can't remove Received-SPF since it's in use, but A-R is >increasing in use, it seems that we are in a position where providing >both options is entirely appropriate. Since there's been pressure >even at the IESG level to be forward-compatible, I think we're going >to get less resistance than you're predicting. Maybe. From an IETF perspective, we have not explored all the possibilities. Let me try and list for constraints: (a) address security concerns (b) taking into account what's in use (c) the charter The Received-SPF: header field is about (a) while Authentication-Results: header field is about (c). I'll leave others to chime in on this to get a better idea. >It's not an update in the normative sense. It suggests possible use. >It doesn't rise to the level of an applicability statement. I think >it's fine. Ok. I mentioned it to avoid any surprises. Regards, S. Moonesamy From superuser@gmail.com Fri Aug 31 12:21: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 29E6D21F8598 for ; Fri, 31 Aug 2012 12:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGuXquNA1XKB for ; Fri, 31 Aug 2012 12:21:55 -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 54C9B21F8577 for ; Fri, 31 Aug 2012 12:21:55 -0700 (PDT) Received: by lahm15 with SMTP id m15so2940428lah.31 for ; Fri, 31 Aug 2012 12:21:54 -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=CGQPKV6KXm9UACA05K/U4Evx8QUGs9PaoF5If1aMm18=; b=lHo0bYxMP4vfo9qOa2P8pjzJi5aRCWv0D9R5HSZUcd8R5pHr85+jBhNEnaSCI7x88O hEMkm+r+t1ImvbkaJ83JqhUEm7g1HH6iFq3cO4gv04yXUAvExhkF7Iyl7okZa8YGN3MY XuWyu5A3k/snyckAETR4nU/N3NFBudW+mkqYgPdp0EzSGHEh7K/WQLQPFcw8hhR/SZ+k YirwAppxneR0GQm0G1NvZ/6GZikkHb+LZlMwjHRKZCKCdWtYphquFnqGNTzC7VabEDXS TxhZ+HUClGIRSYJ71Q6iGLqsyZgeYd+jJHLHuVAikwH07oDkBsOVpthkW7xiLCUc7CVI LfOg== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr7418294lab.35.1346440914050; Fri, 31 Aug 2012 12:21:54 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 12:21:53 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831114210.099fe480@elandnews.com> References: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> <6.2.5.6.2.20120831114210.099fe480@elandnews.com> Date: Fri, 31 Aug 2012 12:21:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 19:21:56 -0000 On Fri, Aug 31, 2012 at 11:55 AM, S Moonesamy wrote: > At 11:40 31-08-2012, Murray S. Kucherawy wrote: >> >> Why? > > If the argument wasn't convincing for Authentication-Results:, it won't be > convincing here. I think the fact that Received-SPF is already in use means we can't remove it. The best we can do is call out that it's at the mercy of the "no reordering" rule and implementations' adherence to it. > Maybe. > > From an IETF perspective, we have not explored all the possibilities. Let > me try and list for constraints: > > (a) address security concerns > > (b) taking into account what's in use > > (c) the charter > > The Received-SPF: header field is about (a) while Authentication-Results: > header field is about (c). I'll leave others to chime in on this to get a > better idea. I think the proposed text (intentionally) addresses all three of those concerns. -MSK From sm@elandsys.com Fri Aug 31 13:12: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 A577811E80BA for ; Fri, 31 Aug 2012 13:12:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id felbmwzEsP8l for ; Fri, 31 Aug 2012 13:12: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 4C3C721F8555 for ; Fri, 31 Aug 2012 13:12:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.239]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7VKBnol019664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 13:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346443920; bh=aSrJiuDps3JJpG7HOf6JRBBWEuRb0tjLKwHBloGgjzU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NhEUqilT+YcazuHq4LbX35BSkPkEP/oVJn78+lhDuamYaWGdSysyum2FVg/U4SAXY D+KH2Yf5YauRzwvIGxIoBEQElE2l6aYxn3mdwOYuJdDNCcbHhTzKHDCHcgDFTR4bwq MFIFHby+Wm51ZZoiXvV8LbjejLfMjc1I8VHwniHg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346443920; i=@elandsys.com; bh=aSrJiuDps3JJpG7HOf6JRBBWEuRb0tjLKwHBloGgjzU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k0yi32fVTTLarwQtCNCYIfvRiZkaJAbygN2Ppk9u/oKOMFVJYRXHDwpQbgAN1Cw0N 7HYo04p05bS7SA7jnIhnn7OzQ8afcSSjWfJEHM8j7BTvbnGBwFFKZZrE7lAvoC6m5s nD6Vos5n1E+GkjsdozeoYCEOyn9jlzWw1w9sthvA= Message-Id: <6.2.5.6.2.20120831122446.0965a7b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 12:32:52 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831105137.0ad02840@resistor.net> <6.2.5.6.2.20120831114210.099fe480@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 20:12:14 -0000 Hi Murray, At 12:21 31-08-2012, Murray S. Kucherawy wrote: >I think the fact that Received-SPF is already in use means we can't >remove it. The best we can do is call out that it's at the mercy of >the "no reordering" rule and implementations' adherence to it. We have one wish where we can beg the IESG for mercy. :-) My preference is not to use it for this issue. Regards, S. Moonesamy From spf2@kitterman.com Fri Aug 31 14:12: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 BC25511E80E6 for ; Fri, 31 Aug 2012 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qousJR0Oj3rq for ; Fri, 31 Aug 2012 14:12:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CC48711E80DC for ; Fri, 31 Aug 2012 14:12:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1E4FF20E414A; Fri, 31 Aug 2012 17:12:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346447533; bh=xBJBDVmq3aqE3Iko6cRq29i0zIXeXiVfbQwyLxtJta8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jRCvUmDnxFyp63tPjgtjgXs/6SWtaR7BTYObxc9p4CripAOoojD8TDC7oJkZOgVjK foJWeN6dTl0dhYmk6WCkIICGmtr3ZR6ZqiuN7FMvKVEb91GfG7+yjmpA5BchzwlO7s aVoERjYxR3HeXxGCx/6pcZfmuHWlpCLbxkD7cQwc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E6E4B20E4071; Fri, 31 Aug 2012 17:12:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 17:12:11 -0400 Message-ID: <2987595.sYjZB0k9Rb@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831114210.099fe480@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] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 21:12:15 -0000 On Friday, August 31, 2012 12:21:53 PM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 11:55 AM, S Moonesamy wrote: > > At 11:40 31-08-2012, Murray S. Kucherawy wrote: > >> Why? > > > > If the argument wasn't convincing for Authentication-Results:, it won't be > > convincing here. > > I think the fact that Received-SPF is already in use means we can't > remove it. The best we can do is call out that it's at the mercy of > the "no reordering" rule and implementations' adherence to it. Absolutely. Additionally, there's no evidence so far that removing it is even a good idea. > > Maybe. > > > > From an IETF perspective, we have not explored all the possibilities. Let > > > > me try and list for constraints: > > (a) address security concerns > > > > (b) taking into account what's in use > > > > (c) the charter > > > > The Received-SPF: header field is about (a) while Authentication-Results: > > header field is about (c). I'll leave others to chime in on this to get a > > better idea. > > I think the proposed text (intentionally) addresses all three of those > concerns. I agree. I think the current bidding on the text is something like this then: 7. Recording The Result It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header for processing by internal filters or MUAs. Two methods are presented. Section 7.1 defines the Received-SPF field, which is the results field originally defined for SPF use. Section 7.2 discusses Authentication- Results [RFC5451] which was specified more recently and is designed for use by SPF and numerous other authentication protocols. Both are in common use, and hence both are included here. However, it is important to note that they serve slightly different purposes: Received-SPF is intended to include enough forensic information to enable reconstruction of the SPF evaluation of the message, while Authentication-Results is designed only to relay the result itself and related output details of likely use to end users (e.g., what property of the message was actually authenticated and what it contained), leaving forensic work to the purview of system logs and the Received field contents. Also, Received-SPF relies on compliance of agents within the receiving ADMD to adhere to the header field ordering rules of [RFC5321] and [RFC5322], while Authentication-Results includes some provisions to protect against non-compliant implementations. An operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure both fields are conveying the same details, or unexpected results can occur. 7.1. The Received-SPF Header Field 7.2. The Authentication-Results Header Field [RFC5451] defined the Authentication-Results header field and included provisions for reporting SPF results to downstream agents. As noted above, however, it lacks the capability to include certain forensic details. If an operator wishes to use this field, the missing forensic details could be included either in the "reasonspec" or in header field comments, which can then be extracted and used by downstream agents. Using the SPF-Received key-value-list (see Section 7.1) would provide a structured method to convey this information. For example: How's that? The only changes from Murray's original text are to put the RECOMMENDED back at the beginning and make reference to the key-value-list in the A-R section. Scott K From superuser@gmail.com Fri Aug 31 15:07: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 EB73421F8523 for ; Fri, 31 Aug 2012 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI0+45ZX2Q2g for ; Fri, 31 Aug 2012 15:07:11 -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 2755C21F851E for ; Fri, 31 Aug 2012 15:07:10 -0700 (PDT) Received: by lahm15 with SMTP id m15so3030340lah.31 for ; Fri, 31 Aug 2012 15:07: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=0nehDp8EXK1cMAzgoBPGy/iSAtn4eMI2gc0yB4IrbKQ=; b=qlVR4lKVMM40x1tO0KryWUqQUinHxKt9XkrRYqa+qwwZ+2NGENt6H5Wwlfy9lJYzpz kPsnmybOkorIqBjzo83lLVzNdmtL7WQbGLeX8ZC5rIXPAzV6sCZZYOa+d85CuNO48m4m h2ZZbxK5SB6mWw1LQ48cvGkqdLwrkgddcP4bhlpDJLu3gJcdTTqV3k6RKR3o0iN0m5wj GkRDJ//ruyhwDVqgKg+lynMbuIMFdPyQ9GTMoFj1CH+FUtV5wcTkbm3uQyGQJEGa6wvn /YKBloW+mb8qfi7NCjTWw48KHuzWWr/vb4rpval6HrkrEH1nWtBHdJycYD1glpDyzE4L z7vg== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr7690441lab.19.1346450830141; Fri, 31 Aug 2012 15:07:10 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 15:07:10 -0700 (PDT) In-Reply-To: <2987595.sYjZB0k9Rb@scott-latitude-e6320> References: <6.2.5.6.2.20120831114210.099fe480@elandnews.com> <2987595.sYjZB0k9Rb@scott-latitude-e6320> Date: Fri, 31 Aug 2012 15:07:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 22:07:12 -0000 On Fri, Aug 31, 2012 at 2:12 PM, Scott Kitterman wrote: > How's that? The only changes from Murray's original text are to put the > RECOMMENDED back at the beginning and make reference to the key-value-list in > the A-R section. In retrospect, I think it would be good to explain (in no more than a sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) happy with the text I proposed. :-) -MSK From spf2@kitterman.com Fri Aug 31 15:31: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 70B2D11E80BA for ; Fri, 31 Aug 2012 15:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZOzpvahQBZY for ; Fri, 31 Aug 2012 15:31:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C726D11E808D for ; Fri, 31 Aug 2012 15:31:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 08D6320E414A; Fri, 31 Aug 2012 18:31:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346452278; bh=hMD1qPuEfxBSQesUc/PuDHHJmwUStpj4tiIIwk/NM1U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iXUdTBqmt33thPBQ/yF3DscPcGumgMMGM5gvHWvs2XtaraEkQ4RjL1WbFrv5xtNo+ GG4b9Jz0AqC0zLTU9QDoyNQw11o59icQ/GoIk9JYjRRPdaxyWmKwN0PXXwowG8tYpA xjmpIHdqK6yOJ72pBJ1mlc8pgEeUcwBY5HaUtUWE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BB60220E4071; Fri, 31 Aug 2012 18:31:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 31 Aug 2012 18:31:16 -0400 Message-ID: <1979293.yDzOpEWBxv@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <2987595.sYjZB0k9Rb@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] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 22:31:19 -0000 On Friday, August 31, 2012 03:07:10 PM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 2:12 PM, Scott Kitterman wrote: > > How's that? The only changes from Murray's original text are to put the > > RECOMMENDED back at the beginning and make reference to the key-value-list > > in the A-R section. > > In retrospect, I think it would be good to explain (in no more than a > sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) happy > with the text I proposed. :-) In order to avoid the uncertainty associated with internal MTA SPF assessments (see [MTA Relays]) in follow on processing and to assist in trouble shooting ... How's that? Scott K From superuser@gmail.com Fri Aug 31 15:52: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 76B1C21F84A5 for ; Fri, 31 Aug 2012 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DeguuhVWTqg for ; Fri, 31 Aug 2012 15:52:06 -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 973A721F84A0 for ; Fri, 31 Aug 2012 15:52:05 -0700 (PDT) Received: by lahm15 with SMTP id m15so3050660lah.31 for ; Fri, 31 Aug 2012 15:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kOFaHIUiONxOjZpHCRYRnINLS3znt02eoLXxIHiBxIs=; b=VYZ2lekV26E4k/C/OfA6Y/yOx+oGyTsE7rSyk76y3M5YNiBf7usHuGzarf3bYti/c2 Wg63IkN48fgwfKQUR/EHh+7fJfgb8Y7QeP9NZVUY24flnsLCv7nSZRrk2qdo8rflHnIw m/+1uYMoQVoqVuD+o4pUjLULzqBVObHxGweYyWKnTO9CYIh/31ZdDBT7G/zFy8yuYkHS aMxMHcKEAdfBCbo6sKfzlGQ+mMGIhf7MNBb+Iu3WcjhnOMWgOfOGznSMuQg0YnAwhbrN QCVRk20tcUyUYgd4PZ52EdmbyfZASt8kP5QslWewb5beqSOIkVgkD+nu9eE0C1ExTxXl e1oQ== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr7607452lab.37.1346453524605; Fri, 31 Aug 2012 15:52:04 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 15:52:04 -0700 (PDT) In-Reply-To: <1979293.yDzOpEWBxv@scott-latitude-e6320> References: <2987595.sYjZB0k9Rb@scott-latitude-e6320> <1979293.yDzOpEWBxv@scott-latitude-e6320> Date: Fri, 31 Aug 2012 15:52:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 22:52:06 -0000 On Fri, Aug 31, 2012 at 3:31 PM, Scott Kitterman wrote: >> In retrospect, I think it would be good to explain (in no more than a >> sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) happy >> with the text I proposed. :-) > > In order to avoid the uncertainty associated with internal MTA SPF assessments > (see [MTA Relays]) in follow on processing and to assist in trouble shooting > ... > > How's that? I'm thinking: To provide downstream agents, such as MUAs, with the information they may need in terms of evaluating or representing the apparent safety of the message content, it is RECOMMENDED... -MSK From spf2@kitterman.com Fri Aug 31 16:18:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05921F8460 for ; Fri, 31 Aug 2012 16:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFyjxuzv8FYc for ; Fri, 31 Aug 2012 16:18:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5F321F8450 for ; Fri, 31 Aug 2012 16:18:04 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 3432CD0408A; Fri, 31 Aug 2012 18:18:03 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346455083; bh=aNsqIBr/zQU1P21iNK1jCUApKsaFQ5l10CjmSTx/QHo=; h=References:In-Reply-To:Subject:From:Date:To:From; b=cp6eHsV2qxNU9Br8OOnyy8yEj48tsTeKTTlZghWb6asNn4CxmKcB3gpKG9yOPe7r3 omT62LPXEzSkSpODw0oo3NRHOF93vJiM3Ty8gbZGDjpA4lj7DHr5eXCnme4gRKq2U/ d59o3xT7MZdQD3BVbmLAlfZWGAmAQzaKoQ/hk07Y= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E62A0D04087; Fri, 31 Aug 2012 18:18:02 -0500 (CDT) References: <2987595.sYjZB0k9Rb@scott-latitude-e6320> <1979293.yDzOpEWBxv@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 31 Aug 2012 19:18:00 -0400 To: spfbis@ietf.org Message-ID: <82564fa8-5b3c-4d83-ac35-3d55f4b0fd84@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 31 Aug 2012 23:18:05 -0000 "Murray S. Kucherawy" wrote: >On Fri, Aug 31, 2012 at 3:31 PM, Scott Kitterman >wrote: >>> In retrospect, I think it would be good to explain (in no more than >a >>> sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) >happy >>> with the text I proposed. :-) >> >> In order to avoid the uncertainty associated with internal MTA SPF >assessments >> (see [MTA Relays]) in follow on processing and to assist in trouble >shooting >> ... >> >> How's that? > >I'm thinking: > >To provide downstream agents, such as MUAs, with the information they >may need in terms of evaluating or representing the apparent safety of >the message content, it is RECOMMENDED... > >-MSK Works for me. Scott K From sm@elandsys.com Fri Aug 31 17: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 33A2021F845F for ; Fri, 31 Aug 2012 17:07:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJuutATmntbp for ; Fri, 31 Aug 2012 17:07: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 18BED21F843C for ; Fri, 31 Aug 2012 17:07:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8107dlP009965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Aug 2012 17:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346458073; bh=AvwoCdpVf+GkH8l5W5GYp6ZoTmZSwwqMp6JFaZD2kMY=; h=Date:To:From:Subject:Cc; b=AtPWdd1M+VQZ1WQwQ9sqeayqDIDXwSaxXtJIPEz3Wmv2lTZKzrZZ4IwVEfVESrcrn KpfWnb6Dn3oH+iFMceMQMEg+oPq6YCd8WYSoIeVoRMWKsSYRI8bWv3blq27gSYCGDX vrJAfbMlt/roFL7XvHtqoQbU71XK7qKrfAgcCVSA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346458073; i=@elandsys.com; bh=AvwoCdpVf+GkH8l5W5GYp6ZoTmZSwwqMp6JFaZD2kMY=; h=Date:To:From:Subject:Cc; b=i8WXaMX6Vi2xifcRojkcDs2waEjp4DYfNxpPiENrUUVoErylKAR7cY0lAefhmII3D nNN/0ncS0q1EnhTzcob2sTCB2yOXsNv2T6cRBkDhWJ8HBOPURoV5eoUUtMFPEi4k3K RkETMdmHvVfZkI1pDtsdGBhIzBYX5DMcTGF88oE8= Message-Id: <6.2.5.6.2.20120831151809.06207550@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 17:06:07 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 00:07:57 -0000 Hello, I'll comment about Section 9 of draft-ietf-spfbis-4408bis-06. RFC 4408 mentions that: 'This section outlines the major implications that adoption of this document will have on various entities involved in Internet E-Mail. It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities should do in light of this document. This section is non-normative.' The text mentions what the section is about implications of adopting the specification. I read that as what will break in Internet E-Mail when SPF is used and how to mitigate that without getting turning the section into a how-to manual or a best practices document. draft-ietf-spfbis-4408bis-06 introduces policy into the section. That is a significant change from RFC 4408. Appendix C lists the following changes: Start to rework section 9 with some RFC5598 terms. Added mention of RFC 6552 feedback reports in section 9. Move advice to non-normative section 9. Added text and figures from Alessandro Vesely in section 9.1 to better explain DNS resource limits. Added new sections on Receiver policy for SPF pass, fail, and permerror. Added new section 9 discussion on treatment of bounces and the significance of HELO records. Section 9 of draft-ietf-spfbis-4408bis-06 looks like a catch-all for material which could not be fitted in the other sections of the draft. I could not find any significant discussion on the SPFBIS mailing list about introducing policy into the draft. The SPFBIS charter mentions "addition of clarifying language". I'll read that as what is unclear and requires clarification. From RFC 4408 Section 9.1: 'Domains that wish to be compliant with this specification will need to determine the list of hosts that they allow to use their domain name in the "HELO" and "MAIL FROM" identities. It is recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations.' and Section 9.1 of the draft: 'Originating ADMDs (ADministrative Management Domains - [RFC5598] Section 2.2.1 and Section 2.3) that wish to be compliant with this specification will need to determine the list of relays ([RFC5598] Section 2.2.2) that they allow to use their domain name in the "HELO" and "MAIL FROM" identities when relaying to other ADMDs. It is recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations.' IETF specifications do not generally mention compliance. It is usually about interoperability. There isn't any definition for "originating ADMDs" in Section 2.2.1 or Section 2.3 of RFC 5598. The heading for the subsection is "sending domains". If the goal is to use RFC 5598, I suggest using it throughout the draft. It will be a significant change as it is much more than "addition of clarifying language". Section 9.1.1 is about "DNS Resource Considerations". That section looks like a "how-to". It is against the stated goal. Section 9.1.2 is about "Administrator's Considerations". This is a new subsection too. Quoting from that subsection: "The record for a domain that sends no mail is: www.example.com. IN TXT "v=spf1 -all" Publishing SPF records for individual hosts is also best practice." It is stated at the beginning of the section that it is not a best practice document. The example quoted above stretches the notion "addition of clarifying language". My reading of the charter is that the scope was to avoid significant changes unless there is a problem to solve. The WG is over-diligent in solving the problems of Internet Mail. 'Validating correct deployment is difficult. [RFC6652] describes one mechanism for soliciting feedback on SPF failures. Another approach that can be helpful to publish records that include a "tracking exists:" mechanism.' This is deployment guidance. From Section 9.1.3 of the draft: 'As explained in Section 1.3.3, [RFC5321] allows the reverse-path to be null, which is typical of some Delivery Status Notification [RFC3464], commonly called email bounces. In this case the only entity available for performing an SPF check is the "HELO" identity defined in Section 1.3.4. SPF functionality is enhanced by administrators ensuring this identity is set correctly and has an appropriate SPF record. It is normal to have the HELO identity set to hostname instead of domain. Zone file generation for significant numbers of hosts can be consolidated using the redirect modifier and scripted for initial deployment. Specific deployment advice is given above in Section 9.1.2.' There is a normative reference to RFC 5321. There is an assumption that the reader will have read and understood RFC 5321 before reading this document. The first sentence sounds like what would fit in a tutorial about Internet Mail. The subsection mentions how to enhance SPF functionality. That is beyond of the scope of what the working group was chartered to do. From Section 9.2 of the draft: "Broadly speaking, there are two types of mediating ADMDs that can affect SPF deployment of other ADMDs: mailing lists (see [RFC5598] Section 5.3) and ReSenders ([RFC5598] Section 5.2)." The reader is supposed to have read and understood RFC 5598. This paragraph comes out as tutorial material. From Section 9.2.1 of the draft: "Mailing lists have to be aware of how they re-inject mail that is sent to the list. Mailing lists MUST comply with the requirements in [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that the reverse-path MUST be changed to be the mailbox of a person or other entity who administers the list." As a note, the above text is similar to what was in RFC 4408. Section 9 is supposed to be non-normative. There is a (RFC 2119) requirement in the above paragraph. It is not clear why there is even a requirement to RFC 1123. This subsection comes out as telling mailing list administrators what the RFCs say and that they are to blame if they do comply with the RFCs. Section 9.2.2 mentions that "Forwarding services take mail that is received at a mailbox and direct it to some external mailbox". This again sounds like tutorial material. 'At the time of this writing, the near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" rather than a "mail list".' The term used has always been "alias" and not "mail list". The draft then gets into techniques to "fix the problem". "This would cause a lookup on an anti-spam DNS blacklist (DNSBL) and cause a result of "fail" only for email coming from listed sources." I suggest avoiding anti-spam techniques as that's not the intent of the specification. "Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the local-part." This text was also in RFC 4408. Are there any widespread specialized DNS servers providing this type of service? 'Forwarding services can solve the problem by rewriting the "MAIL FROM" to be in their own domain.' It would be easier to avoid the "forwarding problem" than to attempt to solve it. "Forwarding servers could reject mail that would "fail" SPF if forwarded using an SMTP reply code of 551, User not local, (see [RFC5321] section 3.4) to communicate the correct target address to resend the mail to." The working group is taking liberties with RFC 5321 with such advice. There will be concerns about privacy of the advice is followed. This text was not in RFC 4408. 'Tests against other identities, such as the "HELO" identity, MAY be used to override a failed test against the "MAIL FROM" identity.' There is a RFC 2119 key word in the above. Section 9.3 is about receiver policy (new material compared to RFC 4408. Quoting RFC 4408: 'This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity.' The document moves from Sender Policy Framework to "Receiver Policy Framework". There is no mention of receiver policy in the SPFBIS charter. It is way outside the scope of the charter to discuss about that. The second milestone mentions a standards track document defining SPF. Section 9 would be highly unusual for a document on that track. My understanding of the charter is that the goal is to pursue development of the protocol and not deployment. Regards, S. Moonesamy From superuser@gmail.com Fri Aug 31 17:54: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 268AC21F8498 for ; Fri, 31 Aug 2012 17:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40mCSjKYBkUx for ; Fri, 31 Aug 2012 17:54: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 5292F21F8493 for ; Fri, 31 Aug 2012 17:54:05 -0700 (PDT) Received: by lbky2 with SMTP id y2so1897771lbk.31 for ; Fri, 31 Aug 2012 17:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zj1Ca07vFbpZ5kYGTttOB46scAgzNnBXGrlYPWQzn24=; b=hQAR9QqQTFxzuNRYtZN4L1vk4oc7SpQAwNCw/emH/2p4q8pfH8H7FNb5s0JjDOifsU iFM7cXnz5u8DMYI6HaCWRnFyf3O9VpVtuSSwRqAbMgKa+3mrLHJInEBNdDwddD1TO5LA Q337+dNhykf9zGrhnlvNzLXGpXkEZkT8uoQWlq+Zf8PQfh8ACjnrFsrhcOJX2OOPyt5E CY7PLspH+D1wXbF+jQ8PFa8G1guzDcsIygemEGDMaNU12yKRL7jvdoqAtAuU7uBlkLvC 4mCt/IDE/D7QvWX7qhVZ+F+6ZFRpE4Zh7fggSjn+DTcwU3cyBQWOZrzswH0oKcvqViRp Tz3A== MIME-Version: 1.0 Received: by 10.152.148.1 with SMTP id to1mr7887338lab.34.1346460844295; Fri, 31 Aug 2012 17:54:04 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 17:54:04 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831151809.06207550@elandnews.com> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> Date: Fri, 31 Aug 2012 17:54:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 00:54:06 -0000 On Fri, Aug 31, 2012 at 5:06 PM, S Moonesamy wrote: > The text mentions what the section is about implications of adopting the > specification. I read that as what will break in Internet E-Mail when SPF > is used and how to mitigate that without getting turning the section into a > how-to manual or a best practices document. > > draft-ietf-spfbis-4408bis-06 introduces policy into the section. That is a > significant change from RFC 4408. Appendix C lists the following changes: > [...] So in general, I think this kind of stuff has to go someplace. The experience we've gained in the six years since RFC4408 plus the period during which SPF was originally developed is useful to document someplace in an official capacity. We are not, however, chartered to do so, either in this document or in a separate one. That would require re-chartering. Perhaps the simplest thing to do is to start an individual submission to collect this stuff, and move it out of here. The trick, though, is that RFC4408bis itself should then refer to it, which will delay its publication until that document finds a new home or an AD sponsor and is also published. (And I can tell you that we're very unlikely to take it in APPSAWG.) What the co-chairs will have to decide along these lines is whether moving Section 9 out to its own document constitutes a change that fits within the charter. We can't really have it both ways; RFC4408's Section 9 is indeed deployment advice, so if it stays in the name of minimal change, it at least deserves an update pass. There are, however, parts of the current Section 9 that really need to stay. I'm mainly thinking about the section that describes implications for receivers. Put yourself in the position of an operator reading this: "OK, so I got an SPF {fail, pass, *error} on this message. Now what?" I believe this document is incomplete without an answer to that question. -MSK From hsantos@isdg.net Fri Aug 31 17:59: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 42E2121F84EA for ; Fri, 31 Aug 2012 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTSKLyw5E1BV for ; Fri, 31 Aug 2012 17:59:26 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 555E321F84A5 for ; Fri, 31 Aug 2012 17:59:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1377; t=1346461164; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=y9u8dQ96e8MvIlLsxzKsy/uG0GM=; b=pL1M1xv5gmFPiFKr/mUB bFDs75Mk8IdQibGrYwwssj/gzwx62LnVeEkxQJzv8o5a5QY4hFc/kRAlN7vMgUj0 ukGcTNOQGfvLMZ5QG0xWGyL4AQCZNcG2pfhKZkpOJG5Dex8IZUFx5kW4atez1tFA p2UBd+nDApKZRdZkqKA0ibM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 20:59:24 -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 2482952513.9047.4528; Fri, 31 Aug 2012 20:59:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1377; t=1346460959; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=un+NmDf sVT6gEe7c32vZnYU0yxwABx/37/V1yK4vpaI=; b=c2OBsUI+a6G/MVAI4Ndb8Qw F+ikL6rdMYnzSvhuLZxxa0ypSy0MCeosZeoptNEDsSWs41ZLWGZkhS+kAarcI1bf KA7Y0jg6Hb8rc5y12qsCP4xq8/hRDWbG2/lRNk39oaReoUi3uwpWBojSP8yS6xm1 7sscL5Q2FV/1DP6EMC1M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 20:55: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 3081757536.9.1192; Fri, 31 Aug 2012 20:55:58 -0400 Message-ID: <50415DF9.4050808@isdg.net> Date: Fri, 31 Aug 2012 20:59:37 -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: <2987595.sYjZB0k9Rb@scott-latitude-e6320> <1979293.yDzOpEWBxv@scott-latitude-e6320> <82564fa8-5b3c-4d83-ac35-3d55f4b0fd84@email.android.com> In-Reply-To: <82564fa8-5b3c-4d83-ac35-3d55f4b0fd84@email.android.com> 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] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 00:59:27 -0000 It would be wonderful to get more WG participant input, especially from current SPF vendors, implementators in this exchange. Too limited input IMV may does not adequately represent the SPF community which I hope the WGCs take serious. I personally have some "MUA" related issues with the text below, in addition to the some MUA inconsistencies in applicability here vs there. Scott Kitterman wrote: > > "Murray S. Kucherawy" wrote: > >> On Fri, Aug 31, 2012 at 3:31 PM, Scott Kitterman >> wrote: >>>> In retrospect, I think it would be good to explain (in no more than >> a >>>> sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) >> happy >>>> with the text I proposed. :-) >>> In order to avoid the uncertainty associated with internal MTA SPF >> assessments >>> (see [MTA Relays]) in follow on processing and to assist in trouble >> shooting >>> ... >>> >>> How's that? >> I'm thinking: >> >> To provide downstream agents, such as MUAs, with the information they >> may need in terms of evaluating or representing the apparent safety of >> the message content, it is RECOMMENDED... >> >> -MSK > > Works for me. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Fri Aug 31 18:05: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 09C2221F84F8 for ; Fri, 31 Aug 2012 18:05:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn-48dvsPEOO for ; Fri, 31 Aug 2012 18:05:25 -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 14EE821F84BF for ; Fri, 31 Aug 2012 18:05:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q811564m002640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Aug 2012 18:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346461524; bh=larY516Anm5+XeY9ba097Evq58O8MhnqiYffkbEIIlc=; h=Date:To:From:Subject:Cc; b=3sUYsMMRFshONyheIe0jSEaKUjeVwtaJM8RiW8JOYfUhoGHeCALGYkgjDrVguhlce BUiyxjEwHPjYT9OvRgXxx2WDRVdG5xcRTcXw6AMrahn6w6I2s5dXg0wO0/19t3uINT 4SuZSiveTB2fAyJTmVX5FH2xvMogdWzRGtQPnrbc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346461524; i=@elandsys.com; bh=larY516Anm5+XeY9ba097Evq58O8MhnqiYffkbEIIlc=; h=Date:To:From:Subject:Cc; b=mhgBccj63gDMaA9PdVe/P6mYAkOQcwpV/UmKIofQJ7cTEhP/31fXzvspQon6ahFNb GxyOcv7cGnaApQ7+JsZN71MPTGIo1JyieUZSqfOeInHjKVvCukgMMhhk5pMPzS3MXj Fn1BScA0HLAqph0iSsZB5LLCXNXYyKcxUIMPNunk= Message-Id: <6.2.5.6.2.20120831171639.098d0d60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 18:03:47 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Section 3 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 01:05:26 -0000 Hello, I am commenting on Section 3 of draft-ietf-spfbis-4408bis-06. Section 3 is about SPF records. 'An SPF record is a DNS TXT (type 16) Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities.' According to RFC 4408: 'This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity.' The protocol is described about hosts authorized to use the domain name instead of who is authorized and who isn't. Note that the text I am commenting about is similar to what is in RFC 4408. I suggest keeping the SPF record definition similar to what is used for the protocol instead of getting into who is authorized and who isn't. "Loosely, the record partitions all hosts into permitted and not-permitted sets (though some hosts might fall into neither category)." I suggest remove that to "tighten" the specification. 'The SPF record is a single string of text. An example record is the following: v=spf1 +mx a:colo.example.com/28 -all' There isn't any information about the record "format" in that subsection. "Each SPF record is placed in the DNS tree at the host name it pertains to, not a subdomain under it, such as is done with SRV records [RFC2782]." This is tutorial material. 'The example in Section 3 might be published via these lines in a domain zone file: example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. TXT "v=spf1 a -all"' As the "format" as not been defined the above comes out as tutorial material. "They might cause problems with size limits (see Section 3.4) and care MUST be taken to ensure only SPF records are used for SPF processing." There is a new RFC 2119 requirement compared to RFC 4408. 'ADMDs publishing SPF records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. ADMDs SHOULD also try to minimize the amount of other DNS information needed to evaluate a record.' Two new RFC 2119 recommendations have been added. In Section 3.1: "SPF records MUST be published as type TXT [RFC1035]" There is a previous definition for SPF records which already mentions that it is a DNS TXT (type 16) Resource Record (RR). It is not clear what the MUST is for. 'Use of alternate DNS RR types was supported in SPF's experimental phase, but has been discontinued.' I suggest mentioning the SPF RR is considered as deprecated. In Section 3.4: 'Note that when computing the sizes for queries of the TXT format, one MUST take into account any other TXT records published at the domain name.' This is a new RFC 2119 requirement. In Section 3.5: "Use of wildcard records for publishing is NOT RECOMMENDED." This is a new RFC 2119 recommendation. "SPF records MUST be listed twice for every name within the zone:" This is a new RFC 2119 requirement. There seems to be an assumption that DNS is secure. I suggest adding text about DNS Security in the Security Considerations section. Regards, S. Moonesamy From superuser@gmail.com Fri Aug 31 18:20: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 0271C11E8091 for ; Fri, 31 Aug 2012 18:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8JlbGm5N1fj for ; Fri, 31 Aug 2012 18:20: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 7DCD111E808D for ; Fri, 31 Aug 2012 18:20:02 -0700 (PDT) Received: by lbky2 with SMTP id y2so1908483lbk.31 for ; Fri, 31 Aug 2012 18:20: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=V7cJnze2V443a0lwvLHyfUMRpKcrWGQ27oS7itQR+Bk=; b=FnL6AWOx0obQIvngr4dLZ5QoQ/eJjP8b0/jhAkSdojRExFDAoa98mlnM+x1gdJO5KT YpvjYzCyQnvBm548gWoG3A5U4Kyr8sjkxvrdNQBaVfCqjzeyhuwHwo0HFmjLYUnMH6FA Pys+n4JqlR4VCcSH2pc1pvyvENID71raoGhtYuqMONQxoL2sHmrsEGs8m0hzZmLIQZO7 276GW7vbSrjp7fK3819QC/oBWEwMgg6qwPT1nxo3BkGWpYMs1oL5ggIWRfgHIPjYtwjE tk2l8iw+l/5adwV7LINepPimeKeVQS+T/aIj8xWtdO2P2Fo8RRMhmDfU8B8NV5BtZvgg Ly+A== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr3158634lbb.72.1346462401344; Fri, 31 Aug 2012 18:20:01 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 18:20:01 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831171639.098d0d60@elandnews.com> References: <6.2.5.6.2.20120831171639.098d0d60@elandnews.com> Date: Fri, 31 Aug 2012 18:20:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 3 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 01:20:06 -0000 On Fri, Aug 31, 2012 at 6:03 PM, S Moonesamy wrote: > "Loosely, the record partitions all hosts into permitted and > not-permitted sets (though some hosts might fall into > neither category)." > > I suggest remove that to "tighten" the specification. How is that an improvement? > 'The SPF record is a single string of text. An example record is the > following: > > v=spf1 +mx a:colo.example.com/28 -all' > > There isn't any information about the record "format" in that subsection. A forward reference to the formal specification would be adequate. > "Each SPF record is placed in the DNS tree at the host name it > pertains to, not a subdomain under it, such as is done with SRV > records [RFC2782]." > > This is tutorial material. I disagree. It's implementation. > 'The example in Section 3 might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all"' > > As the "format" as not been defined the above comes out as tutorial > material. Two things: 1) The forward reference I suggested above solves it. 2) "The example in Section 3" inside Section 3 is weird. How about "The example above?" > "They might cause problems with size limits (see Section 3.4) > and care MUST be taken to ensure only SPF records are used > for SPF processing." > > There is a new RFC 2119 requirement compared to RFC 4408. The issue is use of "must" vs. "MUST". I believe this is appropriate clarification (this, or replace MUST with some non-2119 word). > 'ADMDs publishing SPF records SHOULD try to keep the number of > "include" mechanisms and chained "redirect" modifiers to a minimum. > ADMDs SHOULD also try to minimize the amount of other DNS information > needed to evaluate a record.' > > Two new RFC 2119 recommendations have been added. Same argument. > In Section 3.1: > > "SPF records MUST be published as type TXT [RFC1035]" > > There is a previous definition for SPF records which already mentions that > it is a DNS TXT (type 16) Resource Record (RR). It is not clear what the > MUST is for. Same argument. Could change "MUST be" to "are" though. > 'Use of alternate DNS RR types was supported in SPF's experimental > phase, but has been discontinued.' > > I suggest mentioning the SPF RR is considered as deprecated. Agree, and refer to the experiment document for more detail. > In Section 3.4: > > 'Note that when computing the sizes for queries of the TXT format, > one MUST take into account any other TXT records published at > the domain name.' > > This is a new RFC 2119 requirement. Same issue, I believe. I'll skip further things along those lines. > There seems to be an assumption that DNS is secure. I suggest adding text > about DNS Security in the Security Considerations section. I'd suggest we get guidance from Andrew or our AD about that. Seems like we might need to do that for everything that uses the DNS in any way, which could get tedious, unless we can rely on the fact that RFC1034/5 are already marked as updated by the DNSSEC drafts. -MSK From hsantos@isdg.net Fri Aug 31 18:23: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 3A32C21F8440 for ; Fri, 31 Aug 2012 18:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9DzjFtMtQFP for ; Fri, 31 Aug 2012 18:23:49 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3651721F843E for ; Fri, 31 Aug 2012 18:23:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1866; t=1346462620; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=crCcRCrqBaXgN3wWLirkdyiHiKQ=; b=oeTH5P5Fodepm1QSh02O bJnMyTLMilobStodSAA2jC4EANUid1CNNuSG58Ut9AXcbj/wfgtIddD9Ezf2FlJ5 g8S6eo/VfvEote8abUDjeiCdIG4atpmx77xC7bY6wvHvRsZDp3M6ZRyENUJdHuMV F1DLkaEI5edqhIvdZTtTGYE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 21:23:40 -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 2484408034.3.3608; Fri, 31 Aug 2012 21:23:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1866; t=1346462087; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=lsW/BDO CdS4TVpT+KfverVkziTj+JjDqsFOc0wCGGHY=; b=EJoM1H4+iZkiXs39x8uuswb 2a6uboZn180ZvlTb4GIvuIE3IA08gNRIUxyS3cFiAGXMCCg+8/3mSiCZshkrMuKs gacCfQbgg/3mWkX0qC0CXtyv6Z4ZDTN1vxwMU0XtaAZm3beD3G339mVDEKyGd1+4 Z4tdHpk7kntDJRHhqx/E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 31 Aug 2012 21:14:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3082885833.9.6680; Fri, 31 Aug 2012 21:14:47 -0400 Message-ID: <50416261.1030602@isdg.net> Date: Fri, 31 Aug 2012 21:18:25 -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: <6.2.5.6.2.20120831151809.06207550@elandnews.com> In-Reply-To: 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] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 01:23:50 -0000 Murray S. Kucherawy wrote: > There are, however, parts of the current Section 9 that really need to > stay. I'm mainly thinking about the section that describes > implications for receivers. Put yourself in the position of an > operator reading this: "OK, so I got an SPF {fail, pass, *error} on > this message. Now what?" I believe this document is incomplete > without an answer to that question. This sort of revisiting of SPF theory is really out of place. We already know what SPF is, what it does, what it offers, its weak and strong points and where it fails. Honestly, we do and we did since day one and I guess I can say that because there are millions of domains using SPF. As a matter of fact, since day one, its #1 issue was the genesis for DKEYS, IIM and DKIM reason to exist (at least marketing wise). We are not inventing anything new. We know what SPF says for FAIL, PASS, SOFTFAIL, NONE and *ERROR and in all honesty, SPF is about a "RECEIVER protocol." Calling it "Receiver Policies" is a misnomer. SPF describes what a compliant SPF receiver is expected to do with a Domain SPF policy and if they don't follow it, it breaks down. Sure, it is unfortunately weak in throwing the book at anyone and thus one can start an argument "Well, it really doesn't say that - RFC2119 wise." but that isn't practical in real life. People do know whats going on and that is why SPF is pretty popular, widely adopted and widely supported. I believe people can provide experiences for some insight, but SPF is pretty clear and has been very clear since the beginning on what receiver can or can't do. Lets not reinvent the wheel, intentions - the SPF Theory. We are dangerously close of losing focus of what SPF is and IMO, we risk a lost of endorsement for what one may view as already over bloated BIS work. -- HLS From sm@elandsys.com Fri Aug 31 18:33:54 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 53FDA11E8091 for ; Fri, 31 Aug 2012 18:33:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0VYMKKfIgQc for ; Fri, 31 Aug 2012 18:33:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0A11E808D for ; Fri, 31 Aug 2012 18:33:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q811Xct8013383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 18:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346463230; bh=ZFPlxRDxFdZ0My+k/+Xv9Fq3RQoOarfizSvJrhyXrDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gz7zDM6qzfA9tYmVYi6TyZLu8uJhTwNIFUILV0YyEn+BLeQARITyyVmVWFDH0QNIW GDwpd85pF7g9AKn4L73w/pFQAlnkgTLwRylCpWlypFMAyAHkqOmI6mubDYiqxguy21 gvXVHBe9ZLsCy2pmMQXIRgBOyx232RYYn2NJ749E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346463230; i=@elandsys.com; bh=ZFPlxRDxFdZ0My+k/+Xv9Fq3RQoOarfizSvJrhyXrDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lX8H+MXn4Awxb+GRUVam1xyX4KppZnuBlKKXbSk55W7Xbw6p+s7NVRnIw3eapRO+g pah9vuhZy1AuP/mFff4aqzZjTsRDYfQ5PbvzS73KZI/m79Rsn4DmqdOhfbLSewSfaY oLi9N5scqoKMKFqx2wWSQXo7FwdPfCiHIuTcJtLc= Message-Id: <6.2.5.6.2.20120831180612.098d0090@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 18:23:49 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 01:33:54 -0000 Hi Murray, At 17:54 31-08-2012, Murray S. Kucherawy wrote: >someplace in an official capacity. We are not, however, chartered to >do so, either in this document or in a separate one. That would >require re-chartering. Yes. >Perhaps the simplest thing to do is to start an individual submission >to collect this stuff, and move it out of here. The trick, though, is >that RFC4408bis itself should then refer to it, which will delay its >publication until that document finds a new home or an AD sponsor and >is also published. (And I can tell you that we're very unlikely to >take it in APPSAWG.) I don't know what to suggest. I won't suggest APPSAWG. :-) >What the co-chairs will have to decide along these lines is whether >moving Section 9 out to its own document constitutes a change that >fits within the charter. We can't really have it both ways; RFC4408's >Section 9 is indeed deployment advice, so if it stays in the name of >minimal change, it at least deserves an update pass. Yes. I posted the review of this section to get some feedback from WG participants. >There are, however, parts of the current Section 9 that really need to >stay. I'm mainly thinking about the section that describes >implications for receivers. Put yourself in the position of an >operator reading this: "OK, so I got an SPF {fail, pass, *error} on >this message. Now what?" I believe this document is incomplete >without an answer to that question. That's a good point. Regards, S. Moonesamy From sm@elandsys.com Fri Aug 31 18:33: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 6577E11E809C for ; Fri, 31 Aug 2012 18:33:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib+0Ktd2rKCy for ; Fri, 31 Aug 2012 18:33:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E439711E80A2 for ; Fri, 31 Aug 2012 18:33:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q811XctA013383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 18:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346463234; bh=LqqFBs31oEnkeg9k++ZHfEWeoSXBVGky0o9hkFXLygM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TRW6latnADtG2+RDe34lFGrjVJlO5ZkZ+9Xe5UnPSpLE01MKrCrzKtmwm0R1cYCOA KOH1pDQ2Q0ft0/prHq5JzfiiyY1YpySTSs7jHWP/5Vl+t/dW0qxbbebMilYwGOuVCo x+uh0eoICX3dwhi2Wr7tdQ2MkPjBoFgqVg6bWXh0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346463234; i=@elandsys.com; bh=LqqFBs31oEnkeg9k++ZHfEWeoSXBVGky0o9hkFXLygM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=c8NTZ3GPf2Swiiq1tOV3zZrVA277m8MoVlBtY7tlNnoRlpJ37vI5ZRCLcy8ZFtf5z Wg3IHWaLFNGe5Xn7zr15Cod/k7uJ/8P3fh/kzCOQWBoG2uRuK++fF8NbqLG3Y7MSj0 asiofvz9xaWtCbPCLGG/eMNXnfpVRXO7hgYhp7Wc= Message-Id: <6.2.5.6.2.20120831182412.0a25f180@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 18:33:17 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831171639.098d0d60@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 3 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 01:33:58 -0000 At 18:20 31-08-2012, Murray S. Kucherawy wrote: >How is that an improvement? The WG Chairs might say that it is not a clarification. :-) >A forward reference to the formal specification would be adequate. Yes. >I disagree. It's implementation. Noted. >Two things: > >1) The forward reference I suggested above solves it. Ok. >2) "The example in Section 3" inside Section 3 is weird. How about >"The example above?" I'll leave it to WG participants to provide feedback. >The issue is use of "must" vs. "MUST". I believe this is appropriate >clarification (this, or replace MUST with some non-2119 word). One "MUST" could be used (re: your comment about the SPF RR). >I'd suggest we get guidance from Andrew or our AD about that. Seems >like we might need to do that for everything that uses the DNS in any That's the trend nowadays. >way, which could get tedious, unless we can rely on the fact that >RFC1034/5 are already marked as updated by the DNSSEC drafts. I don't think so ( http://www.rfc-editor.org/rfc/rfc1035.txt ). One or two lines about DNSSEC with the appropriate reference would be enough. I'll leave it to Andrew to suggest text. Regards, S. Moonesamy P.S. Thanks for the feedback on the two sections. From superuser@gmail.com Fri Aug 31 20:26:37 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 7DBB621F84AF for ; Fri, 31 Aug 2012 20:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOKVjyiNgLuS for ; Fri, 31 Aug 2012 20:26: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 B30CB21F84AE for ; Fri, 31 Aug 2012 20:26:36 -0700 (PDT) Received: by lbky2 with SMTP id y2so1953233lbk.31 for ; Fri, 31 Aug 2012 20:26:35 -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=xTGeRd1XbQxvJMZkRO0spW0gLrYBccI0nKfcWTwAaMc=; b=U7zXIbbx4QTT0dENWwNkUDq9XFlTjKdSNReq703+628heu3sPGwnIvK14LOiv9G6Lm 84ibbVEEnwJq1KonZq22Xo/qtPhXEcMDfCP+/54ezQodhj4iK17HxmSradT8lf9+D18x T42+8SpByMPmXlh+H62wocxGBYNKaJcH0PEaArhJX4BJDdmcTvpCrIktPkX7FD3662gW epZNJvMr/CdRp5D18+fMy9Rk2ayxxpvYg30BJYvXV1F6ZouVg0HFa1NlCuH4DLiyXM6+ ud+dQmT6JmUNsT7/AKLUaawiJfJ4F6i+RqjpBdJwT4oRb0u/ic7uhZTRWf46b4lVDT6A 08OA== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr3221645lbg.55.1346469995011; Fri, 31 Aug 2012 20:26:35 -0700 (PDT) Received: by 10.112.9.72 with HTTP; Fri, 31 Aug 2012 20:26:34 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831180612.098d0090@elandnews.com> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> Date: Fri, 31 Aug 2012 20:26:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 03:26:37 -0000 On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy wrote: >> Perhaps the simplest thing to do is to start an individual submission >> to collect this stuff, and move it out of here. The trick, though, is >> that RFC4408bis itself should then refer to it, which will delay its >> publication until that document finds a new home or an AD sponsor and >> is also published. (And I can tell you that we're very unlikely to >> take it in APPSAWG.) > > I don't know what to suggest. I won't suggest APPSAWG. :-) The APPSAWG co-chair thanks you. (Seriously, though, there are several procedural things blocking that path.) If we do split the work in this way, we technically still hit our deliverable even if it lands in the RFC Editor queue and stalls there until the second document finishes via whatever path is chosen for it. We just have to accept the unpredictable delay. The only work then is to decide what parts of the current Section 9 are required to make the document whole (those should stay) and which constitute non-critical implementation advice (those should move). It's possible that new content from other sections is also a candidate for such a migration, which would make Arthur happy. Oh, and you need to find an editor(s). ;-) -MSK From spf2@kitterman.com Fri Aug 31 21:48: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 4F99021F8484 for ; Fri, 31 Aug 2012 21:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t3ZUMppCB9R for ; Fri, 31 Aug 2012 21:48:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3C121F847F for ; Fri, 31 Aug 2012 21:48:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 04EFE20E414A; Sat, 1 Sep 2012 00:48:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346474931; bh=yRpFRxuFFnIxZUlzMkg6Ss3m1FBJA4Q/YfwHLlSdJYo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EYMU0MZBCRmff/Y8jLr+u7KsJIdXhde6n5+eQIz2UJUUNe29BwzNBrWr2T4A8iqxM Bf2wI5VuB2GgXvJQ8iGo9kaG7UCX3V+4sQ5d8pj4e5s0LJlKQxCI27RjW/JgyZyoq5 rka6PdcrbMx2pdqMmapNp9gfITIubDLfRkB8Lb3o= Received: from scott-latitude-e6320.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CA8A220E4071; Sat, 1 Sep 2012 00:48:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 01 Sep 2012 00:48:49 -0400 Message-ID: <1488299.LgTzxXEGtV@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@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] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 04:48:53 -0000 On Friday, August 31, 2012 08:26:34 PM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy wrote: > >> Perhaps the simplest thing to do is to start an individual submission > >> to collect this stuff, and move it out of here. The trick, though, is > >> that RFC4408bis itself should then refer to it, which will delay its > >> publication until that document finds a new home or an AD sponsor and > >> is also published. (And I can tell you that we're very unlikely to > >> take it in APPSAWG.) > > > > I don't know what to suggest. I won't suggest APPSAWG. :-) > > The APPSAWG co-chair thanks you. (Seriously, though, there are > several procedural things blocking that path.) > > If we do split the work in this way, we technically still hit our > deliverable even if it lands in the RFC Editor queue and stalls there > until the second document finishes via whatever path is chosen for it. > We just have to accept the unpredictable delay. The only work then > is to decide what parts of the current Section 9 are required to make > the document whole (those should stay) and which constitute > non-critical implementation advice (those should move). > > It's possible that new content from other sections is also a candidate > for such a migration, which would make Arthur happy. > > Oh, and you need to find an editor(s). ;-) I think that both removing section 9 and leaving section 9 unchanged are inconsistent with our charter. I think to do the work we're chartered to do an updated/corrected section 9 is required. I think that's substantially what we have now. That aside, I think splitting the document is a silly idea that would be editorially difficult to pull off without making things significantly more difficult for people trying to understand SPF based on the product of this working group. Scott K From spf2@kitterman.com Fri Aug 31 21:50: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 5FD9A11E809A for ; Fri, 31 Aug 2012 21:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AQLD+jGoI2w for ; Fri, 31 Aug 2012 21:50:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8721F847F for ; Fri, 31 Aug 2012 21:50:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6673D20E414A; Sat, 1 Sep 2012 00:50:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346475014; bh=wqdGHaVmTUp/K5pWfAjD24WBsEEA2mEFusy8idvaIAc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cVpZu4+CNkCXs+YUEwC/WR6/5PhI+9qkisiCMileaSg1pRhHYtnJ/NGoq4ieZwyKw QhRvEtmnWOs6hkbKw2whp2hxn43Di21H9kEP6KFDZ/Ns0qNHsBZRoKuru4+mqY1xvW bSz68UzH8xalGPk/d0vGB5zt+RJ9A4t66COEdseQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 54AE820E4071; Sat, 1 Sep 2012 00:50:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 01 Sep 2012 00:50:13 -0400 Message-ID: <1851677.9k5KAPja5f@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50415DF9.4050808@isdg.net> References: <82564fa8-5b3c-4d83-ac35-3d55f4b0fd84@email.android.com> <50415DF9.4050808@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] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 04:50:16 -0000 "I have some issues" isn't actionable. Please provide actionable comments, preferably with proposed text. Scott K On Friday, August 31, 2012 08:59:37 PM Hector Santos wrote: > It would be wonderful to get more WG participant input, especially > from current SPF vendors, implementators in this exchange. Too > limited input IMV may does not adequately represent the SPF community > which I hope the WGCs take serious. I personally have some "MUA" > related issues with the text below, in addition to the some MUA > inconsistencies in applicability here vs there. > > Scott Kitterman wrote: > > "Murray S. Kucherawy" wrote: > >> On Fri, Aug 31, 2012 at 3:31 PM, Scott Kitterman > >> > >> wrote: > >>>> In retrospect, I think it would be good to explain (in no more than > >> > >> a > >> > >>>> sentence or so) why it's RECOMMENDED. Otherwise I'm (obviously) > >> > >> happy > >> > >>>> with the text I proposed. :-) > >>> > >>> In order to avoid the uncertainty associated with internal MTA SPF > >> > >> assessments > >> > >>> (see [MTA Relays]) in follow on processing and to assist in trouble > >> > >> shooting > >> > >>> ... > >>> > >>> How's that? > >> > >> I'm thinking: > >> > >> To provide downstream agents, such as MUAs, with the information they > >> may need in terms of evaluating or representing the apparent safety of > >> the message content, it is RECOMMENDED... > >> > >> -MSK > > > > Works for me. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Fri Aug 31 22:17: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 4911C11E809C for ; Fri, 31 Aug 2012 22:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y027hkBsoFAu for ; Fri, 31 Aug 2012 22:17:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 379E921F8496 for ; Fri, 31 Aug 2012 22:17:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 688F220E414A; Sat, 1 Sep 2012 01:17:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346476653; bh=xJd8WS3sUYULqSzLdqTwE9dZIQod86kf9m0ARqtxgy0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TfaKoEht/mrwvdqXP/KV9eD1Yskpjg388BHIlKBLF6dx5KoJwCT2uhWzjCDD93Eds fwPoA3n9hpduuW4xB/8VUIiEOLtuqHgbvD5Qrvu2yLpDekENxHYE1Vq/XkHQfd7TqH LHkBrFR164a3xpVVK4XGMVe0cTwjAt2ljhGrMQKw= Received: from scott-latitude-e6320.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 29C3F20E4071; Sat, 1 Sep 2012 01:17:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 01 Sep 2012 01:17:32 -0400 Message-ID: <3262358.CfmtW3KmIJ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831171639.098d0d60@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] Section 3 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 05:17:35 -0000 On Friday, August 31, 2012 06:20:01 PM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 6:03 PM, S Moonesamy wrote: > > "Loosely, the record partitions all hosts into permitted and > > > > not-permitted sets (though some hosts might fall into > > neither category)." > > > > I suggest remove that to "tighten" the specification. > > How is that an improvement? Considering we specifically discussed this text and the working group seemed to feel it helped clarify things, I'm disinclined to remove it. > > 'The SPF record is a single string of text. An example record is the > > > > following: > > v=spf1 +mx a:colo.example.com/28 -all' > > > > There isn't any information about the record "format" in that subsection. > > A forward reference to the formal specification would be adequate. I don't think this is particularly needed, but added anyway. It's not like this is a single pass compiler where implicit forward references cause failures. > > "Each SPF record is placed in the DNS tree at the host name it > > pertains to, not a subdomain under it, such as is done with SRV > > records [RFC2782]." > > > > This is tutorial material. > > I disagree. It's implementation. Absolutely. There is no interoperation without knowing where records should be published/looked up. > > 'The example in Section 3 might be published via these lines in a > > > > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > smtp-out.example.com. TXT "v=spf1 a -all"' > > > > As the "format" as not been defined the above comes out as tutorial > > material. > > Two things: > > 1) The forward reference I suggested above solves it. > > 2) "The example in Section 3" inside Section 3 is weird. How about > "The example above?" Fixed. > > "They might cause problems with size limits (see Section 3.4) > > and care MUST be taken to ensure only SPF records are used > > for SPF processing." > > > > There is a new RFC 2119 requirement compared to RFC 4408. > > The issue is use of "must" vs. "MUST". I believe this is appropriate > clarification (this, or replace MUST with some non-2119 word). This was not an accidental change that I'll revert when I go through and double check 2119 changes. It was converted to a MUST based on expressed concern in the working group that non-2119 language was incorrect because this is an actual protocol requirement. > > 'ADMDs publishing SPF records SHOULD try to keep the number of > > > > "include" mechanisms and chained "redirect" modifiers to a minimum. > > ADMDs SHOULD also try to minimize the amount of other DNS information > > needed to evaluate a record.' > > > > Two new RFC 2119 recommendations have been added. > > Same argument. These are also not accidental. These changes are based on post-4408 deployment experience and are strongly recommended best practices (following them avoids interoperation problems). They are also meant to be part of the answer to Issue #24. > > In Section 3.1: > > "SPF records MUST be published as type TXT [RFC1035]" > > > > There is a previous definition for SPF records which already mentions that > > it is a DNS TXT (type 16) Resource Record (RR). It is not clear what the > > MUST is for. > > Same argument. Could change "MUST be" to "are" though. I changed the language to only mention the specific RR type in one place. This particular section has had a lot of changes, since this is where the no longer used Type SPF RR type was defined here. The operative part of RFC 4408 relative to this text was: > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least one > type. Since we only have one type saying a domain MUST have a record of that type is completely consistent with the 2119 requirements in 4408. In any case I don't understand what the objection is, since it's perfectly correct that if you don't publish an SPF record as a TXT record you aren't doing SPF. > > 'Use of alternate DNS RR types was supported in SPF's experimental > > > > phase, but has been discontinued.' > > > > I suggest mentioning the SPF RR is considered as deprecated. > > Agree, and refer to the experiment document for more detail. Except it's not. Please actually read our definition of deprecated. We didn't deprecate type SPF, we removed it. > > In Section 3.4: > > 'Note that when computing the sizes for queries of the TXT format, > > one MUST take into account any other TXT records published at > > the domain name.' > > > > This is a new RFC 2119 requirement. > > Same issue, I believe. I'll skip further things along those lines. You do have to do it or you'll publish records that are too big and get interoperation failures. This one seems appropriate to me as well. > > There seems to be an assumption that DNS is secure. I suggest adding text > > about DNS Security in the Security Considerations section. > > I'd suggest we get guidance from Andrew or our AD about that. Seems > like we might need to do that for everything that uses the DNS in any > way, which could get tedious, unless we can rely on the fact that > RFC1034/5 are already marked as updated by the DNSSEC drafts. Sigh. Did anyone look at the existing security considerations before commenting. Section 10.3 covers this exact issue. If it's inadequate, please provide text, but please check if your comments are already addressed before making new ones. Scott K From sm@elandsys.com Fri Aug 31 22:24: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 523BE21F84B8 for ; Fri, 31 Aug 2012 22:24:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZvK5JgVpp+s for ; Fri, 31 Aug 2012 22:24: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 6F44B21F849D for ; Fri, 31 Aug 2012 22:24:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q815NvCQ000649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 22:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346477049; bh=dDOzUB055fxNrczPmBFTX+luUR/Q1ff+fU6sJszKN5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mhRzIKdBYgm0HP/8kCoAyWxrn9AuEFrA98onGdfxdT9chALcKBj5ln/1+RxM4zEJl eOIwBq2ytHQ5Vaj9NeRc/GDKpvs/QJng+vXQHK4FyxoaoKb7dnb7g/1yj9YXyAD1zS b5vqGFD61ZjLBm35cghvEUDfLRW+msa8+vWwbA/I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346477049; i=@elandsys.com; bh=dDOzUB055fxNrczPmBFTX+luUR/Q1ff+fU6sJszKN5Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mJ2y/eesEXl6C8CNZnskFcQfREoyqixcm44FBHc76+gwOmcABBbWgdxGoFB6jPi3G zBFJsQTKW342l9YeeggcBan7nH3pVEW1OMX1JVjaKBEiABlQxZWo75J4mpJE6cWVmh BiGfPj6oybEFfFBQV9O/an2rdSwXphrTJspJgv6E= Message-Id: <6.2.5.6.2.20120831213948.09fb49a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 22:23:46 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, Scott Kitterman Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 05:24:12 -0000 Hello, My recommendation to the document editor of draft-ietf-spfbis-4408bis-06 is to move Section 9 of the draft to an appendix. draft-ietf-spfbis-4408bis is intended to be published as a Proposed Standard (RFC). I suggest that WG participants send arguments about which parts of the new appendix is necessary for the Proposed Standard. The guideline in determining what to do is the SPFBIS Charter. What has been done in other Proposed Standards may be used as input for additional guidance. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Aug 31 22:35: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 DB73511E80A3 for ; Fri, 31 Aug 2012 22:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp3N-DpgD8Z6 for ; Fri, 31 Aug 2012 22:35:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0541111E80A6 for ; Fri, 31 Aug 2012 22:35:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7A1BD20E414A; Sat, 1 Sep 2012 01:35:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346477713; bh=IdIt6hLOBf/ctq3SLeD33YhkP+o+L1i0xDvlprYXFh0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K45Ikq2INV6hx61zhRuls3RLW0xYdLJyTSA4xx8jIfeQkioHGn5fXafR7i8GT/My0 sgbNBbmyc+MNYQo2BRogMuD4j1y1LiGeHV3J6TosH51Vrn6+3cl6EGxGqEgkO5/R53 +lnwy2gG10vWmu5tm9m+BF3+gzKIN0zc4GosAN1E= Received: from scott-latitude-e6320.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5740820E4071; Sat, 1 Sep 2012 01:35:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 01 Sep 2012 01:35:12 -0400 Message-ID: <4094761.6jIeQ51N6G@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120831213948.09fb49a8@elandnews.com> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831213948.09fb49a8@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] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 05:35:15 -0000 On Friday, August 31, 2012 10:23:46 PM S Moonesamy wrote: > Hello, > > My recommendation to the document editor of > draft-ietf-spfbis-4408bis-06 is to move Section 9 of the draft to an > appendix. > > draft-ietf-spfbis-4408bis is intended to be published as a Proposed > Standard (RFC). I suggest that WG participants send arguments about > which parts of the new appendix is necessary for the Proposed > Standard. The guideline in determining what to do is the SPFBIS > Charter. What has been done in other Proposed Standards may be used > as input for additional guidance. The charter says: > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. Moving section 9 to an appendix is none of those things. Scott K From sm@elandsys.com Fri Aug 31 23:12: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 C07DF21F848F for ; Fri, 31 Aug 2012 23:12:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zy2ayky8Axq for ; Fri, 31 Aug 2012 23:12:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1210D21F842A for ; Fri, 31 Aug 2012 23:12:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q816CSbw026185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 23:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346479960; bh=MCQihVnl3huy3jwavCT/NDgB/eJbEaWoHa/WiOKOO2Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wBSM1wgameC8HtClKOyZfr0XcooV2k68jnZQjatJzkpBor4qCTQHIN9MMgho+kU/N OFYay8vtAlIV6NW4ojJHt9XotMCEuzFCn8GnLkNXN6LV4gUTnfBkM9Htcy2yN/V2Bg sUdNXtafhBzBLsB944RCVKtgba3XZoRyMCBGaPGE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346479960; i=@elandsys.com; bh=MCQihVnl3huy3jwavCT/NDgB/eJbEaWoHa/WiOKOO2Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Zs95moUkPbbOVk+R8NWAPnyZ1DtQkFmoc7V1zibv3mjefy3e8ruwPjetaGoBHVTw5 94yxzRI2YlBReKv7KEkjw0kHPS9gp1Wm/9aAmGVhDabexYsQKLsq/1PYuMNijM6DJe BNrwjYbfsUiNV2px8/o/XSW9nV9EnahZ9BwIHJRI= Message-Id: <6.2.5.6.2.20120831230912.0a0a7df0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 23:12:06 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4094761.6jIeQ51N6G@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831213948.09fb49a8@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 06:12:43 -0000 Hi Scott, At 22:35 31-08-2012, Scott Kitterman wrote: >Moving section 9 to an appendix is none of those things. Please move the section to an appendix. The working group can discuss about this issue after completing the work on the other sections of the draft. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Aug 31 23:33: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 9EC4F11E80AD for ; Fri, 31 Aug 2012 23:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+bfSGCLc3SY for ; Fri, 31 Aug 2012 23:33:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D0E9B11E80A3 for ; Fri, 31 Aug 2012 23:33:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2FE7B20E414A; Sat, 1 Sep 2012 02:33:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346481203; bh=7UcRqbUfpKb3erIQIt0StEa+cb81DnU4vI4jy1KfIJs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Eko7is20gAG5EEF+z4g4kK5OtSHkW+ZvDKyMZDyfFqL3b2ZkHjk9UK524quru8jHE IGOXpDC+/82dXfAAus4r1dAmpmlLe5V4L6fNDosJ9qwWnorX+kt2Pmc7VT/IDkdOc4 c65CCmFmEFvW/8kzVZeQVTjiMYUN8RsLZBAmy20A= Received: from scott-latitude-e6320.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F35E520E4071; Sat, 1 Sep 2012 02:33:22 -0400 (EDT) From: Scott Kitterman To: S Moonesamy , spfbis-chairs@tools.ietf.org Date: Sat, 01 Sep 2012 02:33:22 -0400 Message-ID: <5083185.69cuoQvzXM@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120831230912.0a0a7df0@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> <6.2.5.6.2.20120831230912.0a0a7df0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org, Pete Resnick Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Sep 2012 06:33:24 -0000 On Friday, August 31, 2012 11:12:06 PM S Moonesamy wrote: > Hi Scott, > > At 22:35 31-08-2012, Scott Kitterman wrote: > >Moving section 9 to an appendix is none of those things. > > Please move the section to an appendix. > > The working group can discuss about this issue after completing the > work on the other sections of the draft. You've already said you haven't reviewed the entire draft and won't until after WGLC. I don't think you are in a position to know if that's a good idea or not. I also think you are giving direction that is inconsistent with the WG charter. I've already said that and you've ignored it. I don't think that is appropriate either. What makes this suddenly essential that it can't wait until it's been discussed? I'm putting my work on the draft on hold until this is resolved. Scott K