From sm@elandsys.com Thu Jan 3 12:27:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F3921F8CE8 for ; Thu, 3 Jan 2013 12:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 slH9Hqr5TJtC for ; Thu, 3 Jan 2013 12:27:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38521F8CA1 for ; Thu, 3 Jan 2013 12:26:59 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.135.128]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r03KQk62009215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jan 2013 12:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357244818; bh=dhluW6y5/ajOqmRiJWcxsf06VB4kWFLKewi+9O6RiTM=; h=Date:To:From:Subject:In-Reply-To:References; b=pfGUrkNC8SDiT1SiU0hV4AU1cir4Fp1LXjbaIWrh6NQ+f8mo+17LH4vBmjN1kyDL6 QfDJE0rQ0VRccjeNgHrp8su452UI2JfhDeiZsNJ8aaLUKr/5QoOCL0Qk3BxMj+nZ8y 7ccxscGnyvV7VSRv6cSulYghJ/qzm5omZATOJ0mI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1357244818; i=@elandsys.com; bh=dhluW6y5/ajOqmRiJWcxsf06VB4kWFLKewi+9O6RiTM=; h=Date:To:From:Subject:In-Reply-To:References; b=Di4xuCxTVuvcMlBO0V7qrBLun2WG5ORDTE0BKRpn4L/BG1S2hlPJC1IYC5GBqNh1k 5WA3K10zdXP2GXjzw9Pr1DtkvV/8RdaHrXAlgbeYr01W9GT7WKkOlmzebuzSPAYHzJ ++t/rx6qCZOwsXKO0XO4pAaYxbRJtjY6/UEOV45s= Message-Id: <6.2.5.6.2.20130103122118.0c06db78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 Jan 2013 12:24:48 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4bba8e74-2c12-4c44-99db-891279958573@email.android.com> References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> <6.2.5.6.2.20121218071117.0aad1310@resistor.net> <4bba8e74-2c12-4c44-99db-891279958573@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:27:03 -0000 Hi Scott, At 07:25 18-12-2012, Scott Kitterman wrote: >I expect to have time next work to get it sorted. Would it be possible to provide a tentative date? Thanks, S. Moonesamy From sm@elandsys.com Wed Jan 9 14:58:46 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F821F892F for ; Wed, 9 Jan 2013 14:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Qm2J5cVwRKML for ; Wed, 9 Jan 2013 14:58:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10821F8505 for ; Wed, 9 Jan 2013 14:58:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.145.213]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r09MwOFC015871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jan 2013 14:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357772316; bh=zmcBu1UL8lYH7F+Jz0zjfDzDmB1JuD5U2xybS53+2js=; h=Date:To:From:Subject; b=oPi0/C0gj0BA6JR63dG8hQbdpahehrLzRFPkZUZxpvDvXuQ3ZzMAnLEBY8TEVQbNS FRHxagGJRN32vbTaQWaEPv1Lov0zePe38AapAg513vhtumgo+HJzEx3svnN3zPMSnY LYhb6UtneyjUbwknj76RuqA2Gdt2+4qVMPdWeGp0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1357772316; i=@elandsys.com; bh=zmcBu1UL8lYH7F+Jz0zjfDzDmB1JuD5U2xybS53+2js=; h=Date:To:From:Subject; b=yPK59knkOJkEiR2lcum12zWo36/oVrpfvNRg42K9CynLjLFmOpYagIXOYVSqLXpba oSu4ABk0opxbqduro4u3CaRn7JaQVW+T10WmnqDXSYGeWoE3LnpJwwjzkU9K2AU3i1 8ctsfuIBjeYLjd6HAsUekAO0VpOKZPZRcqMHxCiU= Message-Id: <6.2.5.6.2.20130109144211.0b1f23c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Jan 2013 14:56:25 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] IETF 86 slot for SPFBIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 09 Jan 2013 22:58:48 -0000 Hello, As part of IETF 86 planning working groups are asked if they need a slot on the agenda. There is a conflict list, i.e. other WG sessions which SPFBIS participants need to attend. Please post your preference. Note that this does not mean that there will be a SPFBIS session at IETF 86. Regards, S. Moonesamy From superuser@gmail.com Thu Jan 10 07:44:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2F21F881A for ; Thu, 10 Jan 2013 07:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-GKEK3C1JWy for ; Thu, 10 Jan 2013 07:44:13 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 85C3F21F885C for ; Thu, 10 Jan 2013 07:44:12 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id c1so592390lbg.18 for ; Thu, 10 Jan 2013 07:44:07 -0800 (PST) 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=gSpIiQKG24NNIrSNJKBlIgjy3LI8L82JbM5nR6I0uNE=; b=TjGP9IbrhUjJQk8h9+E3Mn5vWaf3e7ehPEfShVD7OBWYg1S5kw9zFPMu/h2R0ej5kG vJ5LYjHorgzQoOYaZvDS4HyGtaULSKHrfhvkAS8CA9KY4cZ9hAWqPhIvuwhyLsfl5Rsi 7tOMUHLv+n4bwQqU9y974Iq8pIFleln4hHzKa4S5A02/d/BvtGfG4Hlcw1JOFoV/191m rFOGSCbLeXXFu8y54pZ09A8bmAcpgXqMq93Ehp1ArtbmET+zwa8jqw/eUEuePKeYFf3W tKC/5HTpnHO7P8464kcMycSJ1ohSKKehiEWb/6klKxnU6BPYinJjSG49u9dD++DgvoKn ErLA== MIME-Version: 1.0 Received: by 10.152.144.130 with SMTP id sm2mr69560286lab.49.1357832647550; Thu, 10 Jan 2013 07:44:07 -0800 (PST) Received: by 10.112.61.67 with HTTP; Thu, 10 Jan 2013 07:44:07 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130109144211.0b1f23c0@elandnews.com> References: <6.2.5.6.2.20130109144211.0b1f23c0@elandnews.com> Date: Thu, 10 Jan 2013 07:44:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=e89a8f2348a99f25f404d2f10cd2 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] IETF 86 slot for SPFBIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 Jan 2013 15:44:13 -0000 --e89a8f2348a99f25f404d2f10cd2 Content-Type: text/plain; charset=ISO-8859-1 It's hard to say whether we'll need one at this point. It depends on how the merged draft work shakes out and how the WG responds to it. I suggest requesting a one-hour or 1.5-hour slot (since we have to do that by Monday), and canceling it if it's not needed, while we work out the above question. I'll be reviewing Scott's diff this weekend before he posts it. My own priority conflict list is: 1: appsawg, weirds (chairing those), repute 2: saag, httpauth, httpbis, websec, precis, dnsop, v6ops, geopriv, xmpp, dane, oauth, dnsext 3: All BoFs -MSK On Wed, Jan 9, 2013 at 2:56 PM, S Moonesamy wrote: > Hello, > > As part of IETF 86 planning working groups are asked if they need a slot > on the agenda. There is a conflict list, i.e. other WG sessions which > SPFBIS participants need to attend. Please post your preference. > > Note that this does not mean that there will be a SPFBIS session at IETF > 86. > > Regards, > S. Moonesamy > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --e89a8f2348a99f25f404d2f10cd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's hard to say whether we'll need one at th= is point.=A0 It depends on how the merged draft work shakes out and how the= WG responds to it.

I suggest requesting a one-hour or 1.5-hour slot= (since we have to do that by Monday), and canceling it if it's not nee= ded, while we work out the above question.=A0 I'll be reviewing Scott&#= 39;s diff this weekend before he posts it.

My own priority conflict list is:

1: appsawg, weirds (chairing t= hose), repute
2: saag, httpauth, httpbis, websec, precis, dnsop, v6ops, = geopriv, xmpp, dane, oauth, dnsext
3: All BoFs

-MSK


O= n Wed, Jan 9, 2013 at 2:56 PM, S Moonesamy <sm+ietf@elandsys.com>= ; wrote:
Hello,

As part of IETF 86 planning working groups are asked if they need a slot on= the agenda. =A0There is a conflict list, i.e. other WG sessions which SPFB= IS participants need to attend. =A0Please post your preference.

Note that this does not mean that there will be a SPFBIS session at IETF 86= .

Regards,
S. Moonesamy

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

--e89a8f2348a99f25f404d2f10cd2-- From sm@elandsys.com Thu Jan 10 12:13:51 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6121F882B for ; Thu, 10 Jan 2013 12:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_13=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 fAC0ywHsL8or for ; Thu, 10 Jan 2013 12:13:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22921F879D for ; Thu, 10 Jan 2013 12:13:50 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.142.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0AKDYD3001627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 12:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357848826; bh=i2MySxHrZ6KEHZG9P/S+J1D0AaTjyjqZ8GBUcm7iNlk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CNLGs1w4NFIYdwhm2cdOWErtq+5+R8PgW+7/pbbOvY843Ac40BfVSpFqS4w6k2qVP HEixrDmKz9lJ7lNqSiKrHOUyiBG5yAsg4NKtNBohEw8vwuPDRpqh6hqm6TAcKVpMny b5B1OZn4N3xWwgDc+wk+WWz+noBv4yFvr+mWd3sM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1357848826; i=@elandsys.com; bh=i2MySxHrZ6KEHZG9P/S+J1D0AaTjyjqZ8GBUcm7iNlk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rtlhFP9cKNm3yI7v0wM/lrFU2HmhbPXoFiJXHoVwAtzTatAurOnJqQarsSi7p0Rgl AKmCuLkgtHsVGTeqtFydgJpqX6u9mSAI0puqYgc/J0iKAqGtYg5j8PqG6Bz7CMCo5l FrLFYx4cPVJfcmargmPkAgJqXxSabWZaO6GHyf84= Message-Id: <6.2.5.6.2.20130110115334.0aca6088@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Jan 2013 12:13:16 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130109144211.0b1f23c0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] IETF 86 slot for SPFBIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 10 Jan 2013 20:13:51 -0000 Hi Murray, At 07:44 10-01-2013, Murray S. Kucherawy wrote: >It's hard to say whether we'll need one at this point. It depends >on how the merged draft work shakes out and how the WG responds to it. Yes. BTW, the working group has been using a meeting slot only when issues cannot be resolved through the mailing list. >I suggest requesting a one-hour or 1.5-hour slot (since we have to >do that by Monday), and canceling it if it's not needed, while we >work out the above question. I'll be reviewing Scott's diff this >weekend before he posts it. I'll suggest one hour to Andrew. >My own priority conflict list is: > >1: appsawg, weirds (chairing those), repute >2: saag, httpauth, httpbis, websec, precis, dnsop, v6ops, geopriv, >xmpp, dane, oauth, dnsext >3: All BoFs I have: 1. appsawg, weirds, repute, hybi, dnsext, dnsop, dane 2. saag, httpbis, websec, precis, v6ops, geopriv, xmpp, oauth, homenet I am not sure whether we can ask for all BoFs. :-) Regards, S. Moonesamy From internet-drafts@ietf.org Tue Jan 15 19:44:37 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2510311E80AD; Tue, 15 Jan 2013 19:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 6qjanlzgGvkl; Tue, 15 Jan 2013 19:44:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5321F8497; Tue, 15 Jan 2013 19:44:36 -0800 (PST) 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.37 Message-ID: <20130116034436.22576.36078.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 19:44:36 -0800 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:44:37 -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-09.txt Pages : 73 Date : 2013-01-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 "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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Tue Jan 15 19:51:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEDD11E80A2 for ; Tue, 15 Jan 2013 19:51:16 -0800 (PST) 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 0VaZrH14Ecid for ; Tue, 15 Jan 2013 19:51:15 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB6E11E809B for ; Tue, 15 Jan 2013 19:51:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D39420E4094; Tue, 15 Jan 2013 22:51:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358308274; bh=/f6/++JPqTiHvBk/VBwlLXCi2BjctA1H9Rse1E1DXm4=; h=From:To:Subject:Date:From; b=HUmX38/Tn9EaO07vvYzkRYdyoB9sWkKB2Vga1NSjmicHa2GT7IltyvFjk5QVRQyKv 6hhvj0gjAIRmDcwyHAdi9FgisFAtSANrWuuOVf5B/u6mNjWyHIQYcn1ShEHhH+Qvjp CrR2TCbAfpDzFc8u6lCC4wyUyAPMYBMeFEuYwIfA= 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 0E02720E407C; Tue, 15 Jan 2013 22:51:13 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 15 Jan 2013 22:51:13 -0500 Message-ID: <1440164.CoAgXWpN1C@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-21-generic; KDE/4.9.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] Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:51:16 -0000 This is the joint reorg draft that Murray and I were supposed to do based on the last meeting (as confirmed on the list). I stuck to his outline and kept the text changes to either editorial changes or the text needed to glue different parts together in the new organization. There are two things I didn't do from Murray's draft that I'd propose for -10 and will do unless anyone objects: Combine Appendix H and Appendix I. Add this security consideration: 11.7. Delivering Mail Producing a 'Fail' Result Operators that choose to deliver mail for which SPF produces a "fail" result need to understand that they are admitting content that is explicitly not authorized by the purported sender. While there are known failure modes that can be considered "false negatives", the distincg choice to admit those messages increases end-user exposure to likely harm. This is especially true for domains belonging to known good actors that are typically well-behaved; unauthorized mail from those sources might well be subjected to much higher skepticism and content analysis. SPF does not, however, include the capacity for identifying good actors from bad ones, nor does it handle the concept of known actors versus unknown ones. Those notions are out of scope for this specification. Then it's back to the regularly scheduled work on open issues: http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Scott K ---------- Forwarded Message ---------- Subject: New Version Notification for draft-ietf-spfbis-4408bis-09.txt Date: Tuesday, January 15, 2013, 07:44:36 PM From: internet-drafts@ietf.org A new version of I-D, draft-ietf-spfbis-4408bis-09.txt has been successfully submitted by Scott Kitterman and posted to the IETF repository. Filename: draft-ietf-spfbis-4408bis Revision: 09 Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Creation date: 2013-01-15 WG ID: spfbis Number of pages: 73 URL: http://www.ietf.org/internet-drafts/draft-ietf- spfbis-4408bis-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis Htmlized: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-09 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 Secretariat ----------------------------------------- From ajs@anvilwalrusden.com Tue Jan 15 20:11:32 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD56B21F841C for ; Tue, 15 Jan 2013 20:11:32 -0800 (PST) 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 Un1LPNkPlHxv for ; Tue, 15 Jan 2013 20:11:32 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8921F83EF for ; Tue, 15 Jan 2013 20:11:32 -0800 (PST) Received: from crankycanuck.ca (ip-64-134-66-93.public.wayport.net [64.134.66.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 73E708A037 for ; Wed, 16 Jan 2013 04:11:30 +0000 (UTC) Date: Tue, 15 Jan 2013 23:11:30 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130116041130.GB31040@crankycanuck.ca> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1440164.CoAgXWpN1C@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 04:11:32 -0000 Dear colleagues, On Tue, Jan 15, 2013 at 10:51:13PM -0500, Scott Kitterman wrote: > There are two things I didn't do from Murray's draft that I'd propose for -10 > and will do unless anyone objects: […] Please register any such objections in the next few days, so that we can proceed with the WG effort. It's hard to see what would be objectionable about those proposals, so we do not want to waste a lot of time on waiting. We'd like to resume the earlier pace that the WG achieved, and finish up the document in good time. Best regards, Andrew (as chair/goad) -- Andrew Sullivan ajs@anvilwalrusden.com From john@jlc.net Wed Jan 16 04:12:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BD821F86AA for ; Wed, 16 Jan 2013 04:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.106 X-Spam-Level: X-Spam-Status: No, score=-106.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 2AiPRxFQdXkj for ; Wed, 16 Jan 2013 04:12:10 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CF8E821F86BE for ; Wed, 16 Jan 2013 04:12:09 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6EFA933CC0; Wed, 16 Jan 2013 07:12:09 -0500 (EST) Date: Wed, 16 Jan 2013 07:12:09 -0500 From: John Leslie To: Scott Kitterman Message-ID: <20130116121209.GD41685@verdi> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440164.CoAgXWpN1C@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 12:12:18 -0000 Scott Kitterman wrote: > > Add this security consideration: > > 11.7. Delivering Mail Producing a 'Fail' Result > > Operators that choose to deliver mail for which SPF produces a "fail" > result need to understand that they are admitting content that is > explicitly not authorized by the purported sender. While there are > known failure modes that can be considered "false negatives", the > distincg choice to admit those messages increases end-user exposure > to likely harm. This is especially true for domains belonging to > known good actors that are typically well-behaved; unauthorized mail > from those sources might well be subjected to much higher skepticism > and content analysis. > > SPF does not, however, include the capacity for identifying good > actors from bad ones, nor does it handle the concept of known actors > versus unknown ones. Those notions are out of scope for this > specification. This seems to blame operators too much, IMHO, for a practice their customers demand. A possible re-working: " " Many operators have found that email for which SPF produces a "fail" " result is nonetheless email which end-users depend upon receiving, " and deliver it despite the "fail" result. This practice is permitted. " There are things the end-user can do which will distinguish SPF " "fail" email which they do want from SPF "fail" email they don't " want. " " Nonetheless, there are SPF publishers that really want an SPF "fail" " to prevent delivery. SPF does not and cannot promise that. However, " both operators and end-users should clearly understand that most " SPF "fail" emails deserve to be rejected, and a significant number " of them can cause harm. SPF "fail" emails from senders which are " typically well-behaved probably deserve much higher skepticism " and automated content-analysis. (I don't feel especially strongly about this. Use as you see fit.) -- John Leslie From superuser@gmail.com Wed Jan 16 15:06:08 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A59E11E80A6 for ; Wed, 16 Jan 2013 15:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ftXgY01Kdt4l for ; Wed, 16 Jan 2013 15:06:07 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7336B11E809A for ; Wed, 16 Jan 2013 15:06:06 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so186674lbo.14 for ; Wed, 16 Jan 2013 15:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IG9JGJb5wPpoBlX8qjvoCVeG1lfn1EDvORnKCB+uWFE=; b=rKI2NoUDZa6B7Xhmtz5tRfEkvhBD7usk2lTRoYOQ6EdMx7twGLIzyiO6iwj1Kj7Lzx 0TyoQ5Jx4JyvDltzwlZqmmd6DDpby8lJNlxYRmrp0plam771LRst5ykaBKWK+SxkghEY 5e9vmGPpAxYP8KNshOG2oxD06K/QwbjEvDBJi5ni4+pVwXCBi8tbK+0oR1KG3qd3Jw4o qdb7N9Va5MoIsg9/q4y2BQA0tdWLMyG9b5tHdtYVnqw5Xt21QfBAaGHLYMWyOwK1O/Tf QKgTcD63zVkJGUFv0KVHXTmpEyO/dqEaaUtnRG8gp/rakaYIAAO/GYloGyMmsQHbUNt/ Nu8A== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr2760505lab.49.1358377565746; Wed, 16 Jan 2013 15:06:05 -0800 (PST) Received: by 10.112.61.67 with HTTP; Wed, 16 Jan 2013 15:06:05 -0800 (PST) In-Reply-To: <20130116121209.GD41685@verdi> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> Date: Wed, 16 Jan 2013 15:06:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: multipart/alternative; boundary=e89a8f2348a946f4f904d36fecdb Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:06:08 -0000 --e89a8f2348a946f4f904d36fecdb Content-Type: text/plain; charset=ISO-8859-1 Operators are ultimately the ones that implement local policy, so I think it's reasonable to place the focus there. It's unlikely that end users will read this and/or try to understand it. That said, I don't have a problem with the alternative text proposed by John. I think the point in the last paragraph of the proposed 11.7 needs to remain, however. --e89a8f2348a946f4f904d36fecdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Operators are ultimately the ones that implement loca= l policy, so I think it's reasonable to place the focus there.=A0 It= 9;s unlikely that end users will read this and/or try to understand it.=A0 = That said, I don't have a problem with the alternative text proposed by= John.

I think the point in the last paragraph of the proposed 11.7= needs to remain, however.
--e89a8f2348a946f4f904d36fecdb-- From vesely@tana.it Thu Jan 17 02:35:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7F21F8890 for ; Thu, 17 Jan 2013 02:35:52 -0800 (PST) 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 KigLBn2S8j7I for ; Thu, 17 Jan 2013 02:35:51 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 867AA21F888E for ; Thu, 17 Jan 2013 02:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358418949; bh=1E1x54ofTkM6PKR/Bi4wVm7/R8yEKMbQHcH333G132k=; l=3364; h=Date:From:To:References:In-Reply-To; b=VFb/8EbRQa5mSWXELYmYERq/7fhGqtJ5Sg0XnoeAr6IR18wJfAj9yapPjIoZMvAYJ KdWxAbwJwM0Wk3c1q/gdZuXNp3yDqie8W0e+4M/XnKMKBZgzCU/J5M1BzNi6mbpFTw AVoPXmev3CfvZU0fbc131KasRxEVcjkonstnry70= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 17 Jan 2013 11:35:49 +0100 id 00000000005DC02B.0000000050F7D405.00000D8D Message-ID: <50F7D405.6030904@tana.it> Date: Thu, 17 Jan 2013 11:35:49 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> In-Reply-To: <20130116121209.GD41685@verdi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] security consideration, was Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 10:35:52 -0000 On Wed 16/Jan/2013 13:12:09 +0100 John Leslie wrote: > Scott Kitterman wrote: >> >> Add this security consideration: >> >> 11.7. Delivering Mail Producing a 'Fail' Result >> >> Operators that choose to deliver mail for which SPF produces a "fail" >> result need to understand that they are admitting content that is >> explicitly not authorized by the purported sender. Good. I'd s/purported sender/identified ADMD/. >> While there are >> known failure modes that can be considered "false negatives", the >> distincg choice to admit those messages increases end-user exposure >> to likely harm. Usually, a false positive is a false alarm, whereas a failure to notice a malicious attempt would be called a false negative. We may point out that for SPF that is reversed, since failed authorizations are marked with a negative sign... But can't we avoid such parlance and be specific? For example: While there are known transfer modes, such as forwarding, whereby legitimate mail can get a "fail" result, indiscriminately admitting non-authorized messages increases end-user exposure to likely harm. >> This is especially true for domains belonging to >> known good actors that are typically well-behaved; unauthorized mail >> from those sources might well be subjected to much higher skepticism >> and content analysis. Fluffy... >> SPF does not, however, include the capacity for identifying good >> actors from bad ones, nor does it handle the concept of known actors >> versus unknown ones. Those notions are out of scope for this >> specification. Right. But reversing that argument makes it constructive. Consider: In such cases, the ability to discern good actors from bad ones has to be found in tools different from SPF. > This seems to blame operators too much, IMHO, for a practice their > customers demand. A possible re-working: > " > " Many operators have found that email for which SPF produces a "fail" > " result is nonetheless email which end-users depend upon receiving, > " and deliver it despite the "fail" result. This practice is permitted. That sounds like "don't be fooled into rejecting messages just because they got a fail". I don't think such advice is necessary. The purpose of this security consideration is to warn operators that by delivering such messages they place themselves on the side of the actual sender, so they had better make sure it is a good actor before doing so. > " There are things the end-user can do which will distinguish SPF > " "fail" email which they do want from SPF "fail" email they don't > " want. > " > " Nonetheless, there are SPF publishers that really want an SPF "fail" > " to prevent delivery. SPF does not and cannot promise that. However, > " both operators and end-users should clearly understand that most > " SPF "fail" emails deserve to be rejected, and a significant number > " of them can cause harm. That seems correct, possibly except numerical considerations. But then end-users don't happen to notice SPF results... > " SPF "fail" emails from senders which are > " typically well-behaved probably deserve much higher skepticism > " and automated content-analysis. "Senders" is ambiguous in that context. You mean the identified ADMD, not the actual sender, don't you? From vesely@tana.it Fri Jan 18 03:14:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F2821F889A for ; Fri, 18 Jan 2013 03:14:49 -0800 (PST) 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 V9tKwmhCVw8x for ; Fri, 18 Jan 2013 03:14:48 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB1021F88A2 for ; Fri, 18 Jan 2013 03:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358507686; bh=kC/S3R9WnQ4KMSQ8Qip8b1bjw0onZX6lnRBC1Kag+xA=; l=4235; h=Date:From:To:References:In-Reply-To; b=OZ0qbqTfJlodyO54eXxZFWWVdAk0uz720RNwzbAgJtDVIr426Au3UteNrAC0TAjX7 XE5htrbLlMVlRqTs6gpooLvWY2wbWd9cuqBY8p5rAqMfReDDmJmTiuiUxy/XFWlHyM 7ORotD7eHn0TMx9p15T3m+v2RscX7hQxl0TWgzuo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 18 Jan 2013 12:14:46 +0100 id 00000000005DC035.0000000050F92EA6.00004256 Message-ID: <50F92EA6.4020700@tana.it> Date: Fri, 18 Jan 2013 12:14:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-16982-1358507686-0001-2" To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1643914.vUaBv9VAvs@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392807EC68@exch-mbx901.corp.cloudmark.com> <3679773.ridM3LemJv@scott-latitude-e6320> In-Reply-To: <3679773.ridM3LemJv@scott-latitude-e6320> 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: Fri, 18 Jan 2013 11:14:49 -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-16982-1358507686-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed 07/Mar/2012 22:55:28 +0100 Scott Kitterman wrote: > On Wednesday, March 07, 2012 09:36:11 PM Murray S. Kucherawy wrote: >> >> If for example I post a policy of "v=spf1 mx -all", and then I advertise "n" >> MXes, and each of those have "m" IP addresses, that gives me m x n IP >> addresses to compare to the client address. > > What RFC 4408 doesn't say (it's left to the reader to infer from paragraph > 10.1) is if you have more than 10 mx records, don't use an mx mechanism in > your SPF record. We could be explicit about that. There are ways around this > problem that don't require protocol changes. > [...] > Instead of using mx in an SPF record, publish records for another unique > hostname, e.g. mx.example.com, and a records from it pointing at all the > various mx* IP addresses: > > $ dig a mx.example.com +short > > mx.example.com 120 IN A 192.0.2.2 > mx.example.com 120 IN A 192.0.2.3 > mx.example.com 120 IN A 192.0.2.4 > mx.example.com 120 IN A 192.0.2.5 > mx.example.com 120 IN A 192.0.2.6 > mx.example.com 120 IN A 192.0.2.7 > mx.example.com 120 IN A 192.0.2.8 > ... > mx.example.com 120 IN A 192.0.2.22 With those 21 addresses, the DNS record seems to get near to the UDP packet size limit. On a TCP connection, one can return a gabillizion IPs from an A record lookup. Assuming each IPv4 address increases the record size by 16 bytes, +20% TCP overhead, at 100Mbps, I reckon a whole /8 could get through before the 20-sec time limit elapses. Is that worth an additional paragraph in Section 3.4 and 5.3? I attempt that in the attached patch. Please comment on it. --=_north-16982-1358507686-0001-2 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-spfbis-4408bis-09.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-09.patch.txt" LS0tIGRyYWZ0LWlldGYtc3BmYmlzLTQ0MDhiaXMtMDkub3JpZy54bWwJMjAxMy0wMS0xOCAx MjoxMzoxMi4wMDAwMDAwMDAgKzAxMDAKKysrIGRyYWZ0LWlldGYtc3BmYmlzLTQ0MDhiaXMt MDkueG1sCTIwMTMtMDEtMTggMTI6MTM6MTIuMDAwMDAwMDAwICswMTAwCkBAIC01MDksNiAr NTA5LDEzIEBACiAgICAgICAgICAgICB0aGVuIEROUyBhbnN3ZXJzIG91Z2h0IHRvIGZpdCBp biBVRFAgcGFja2V0cy4gIE5vdGUgdGhhdCB3aGVuCiAgICAgICAgICAgICBjb21wdXRpbmcg dGhlIHNpemVzIGZvciBxdWVyaWVzIG9mIHRoZSBUWFQgZm9ybWF0LCBvbmUgaGFzIHRvIHRh a2UKICAgICAgICAgICAgIGludG8gYWNjb3VudCBhbnkgb3RoZXIgVFhUIHJlY29yZHMgcHVi bGlzaGVkIGF0IHRoZSBkb21haW4gbmFtZS4KKyAgICAgICAgICA8L3Q+CisgICAgICAgICAg PHQ+CisgICAgICAgICAgICBETlMgcmVjb3JkcyBvZiBkaWZmZXJlbnQgdHlwZXMsIHdoZW4g dXNlZCBmb3IgU1BGIHB1cnBvc2VzLCB1bmRlcmdvCisgICAgICAgICAgICBhIHNpbWlsYXIg cmVzdHJpY3Rpb24uICBGb3IgZXhhbXBsZSwgdHlwZXMgQSBhbmQgQUFBQSBhcyB1c2VkIGlu CisgICAgICAgICAgICB0aGUgImEiIG1lY2hhbmlzbSAoc2VlIDx4cmVmIHRhcmdldD0ibWVj aC1hIi8+KS4KKyAgICAgICAgICA8L3Q+CisgICAgICAgICAgPHQ+CiAgICAgICAgICAgICBS ZWNvcmRzIHRoYXQgYXJlIHRvbyBsb25nIHRvIGZpdCBpbiBhIHNpbmdsZSBVRFAgcGFja2V0 IGNvdWxkIGJlCiAgICAgICAgICAgICBzaWxlbnRseSBpZ25vcmVkIGJ5IFNQRiB2ZXJpZmll cnMgZHVlIHRvIGZpcmV3YWxsIGFuZCBvdGhlciBpc3N1ZXMKICAgICAgICAgICAgIHRoYXQg Y2F1c2UgRE5TIG92ZXIgVENQIHRvIGJlIGxlc3MgcmVsaWFibGUgdGhhbiBETlMgb3ZlciBV RFAuCkBAIC0xMDU5LDYgKzEwNjYsMTIgQEAKICAgICAgICAgICAmbHQ7aXAmZ3Q7IGlzIGNv bXBhcmVkIHRvIHRoZSByZXR1cm5lZCBhZGRyZXNzKGVzKS4gSWYgYW55IGFkZHJlc3MKICAg ICAgICAgICBtYXRjaGVzLCB0aGUgbWVjaGFuaXNtIG1hdGNoZXMuIAogICAgICAgICA8L3Q+ CisgICAgICAgIDx0PgorICAgICAgICAgIEFuIFVEUCBETlMgcmVwbHkgbWlnaHQgaG9sZCAy MCB0eXBlIEEgcmVjb3Jkcywgb3IgMTAgdHlwZSBBQUFBIG9uZXMsCisgICAgICAgICAgYnV0 IGlzIGxpa2V5IHRvIGdldCB0cnVuY2F0ZWQgYXQgcXVhbnRpdGllcyBuZWFyIG9yIGFib3Zl IHRob3NlCisgICAgICAgICAgdmFsdWVzLCBhbmQgdGh1cyByZXF1aXJlIGZhbGxiYWNrIHRv IFRDUCBjb25uZWN0aW9ucy4gIFB1Ymxpc2hlcnMgYXJlCisgICAgICAgICAgZW5jb3VyYWdl ZCB0byBjYXJlZnVsbHkgdGVzdCB0aGVpciBTUEYgcmVjb3JkcyBpbiBzdWNoIGNhc2VzLgor ICAgICAgICA8L3Q+CiAgICAgICA8L3NlY3Rpb24+CiAgICAgICA8c2VjdGlvbiB0aXRsZT0i JnF1b3Q7bXgmcXVvdDsiIGFuY2hvcj0ibWVjaC1teCI+CiAgICAgICAgIDx0Pgo= --=_north-16982-1358507686-0001-2-- From spf2@kitterman.com Fri Jan 18 11:51:35 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A306221F87C8 for ; Fri, 18 Jan 2013 11:51:35 -0800 (PST) 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 rI+Msw7-c9mz for ; Fri, 18 Jan 2013 11:51:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5935921F87D4 for ; Fri, 18 Jan 2013 11:51:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 525E820E41D6; Fri, 18 Jan 2013 14:51:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358538693; bh=t03alf/pV5bFAvbWOl+uJYSTgMx8ioTQ4iXaUEFCg2k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QLwNGDVaFMmrMey1+nMgNuU9xAAee6le5N81SJnzP60uhD+Nxg1azBXsTrWSmoT5o GejE0gQTL1v/exxIpLqksMjg8NWiQbBbyRoevopks4kCScKQrAT4xwWSTM9F/4NM1o 1MxgBfxP9uFy+H7VBh4LM1+6izWDJL++rnESqFug= 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 39E5D20E4077; Fri, 18 Jan 2013 14:51:32 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 18 Jan 2013 14:51:29 -0500 Message-ID: <1420975.XPujRKHavV@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <50F92EA6.4020700@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3679773.ridM3LemJv@scott-latitude-e6320> <50F92EA6.4020700@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] #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: Fri, 18 Jan 2013 19:51:36 -0000 On Friday, January 18, 2013 12:14:46 PM Alessandro Vesely wrote: > On Wed 07/Mar/2012 22:55:28 +0100 Scott Kitterman wrote: > > On Wednesday, March 07, 2012 09:36:11 PM Murray S. Kucherawy wrote: > >> If for example I post a policy of "v=spf1 mx -all", and then I advertise > >> "n" MXes, and each of those have "m" IP addresses, that gives me m x n > >> IP addresses to compare to the client address. > > > > What RFC 4408 doesn't say (it's left to the reader to infer from paragraph > > 10.1) is if you have more than 10 mx records, don't use an mx mechanism in > > your SPF record. We could be explicit about that. There are ways around > > this problem that don't require protocol changes. > > [...] > > Instead of using mx in an SPF record, publish records for another unique > > hostname, e.g. mx.example.com, and a records from it pointing at all the > > various mx* IP addresses: > > > > $ dig a mx.example.com +short > > > > mx.example.com 120 IN A 192.0.2.2 > > mx.example.com 120 IN A 192.0.2.3 > > mx.example.com 120 IN A 192.0.2.4 > > mx.example.com 120 IN A 192.0.2.5 > > mx.example.com 120 IN A 192.0.2.6 > > mx.example.com 120 IN A 192.0.2.7 > > mx.example.com 120 IN A 192.0.2.8 > > ... > > mx.example.com 120 IN A 192.0.2.22 > > With those 21 addresses, the DNS record seems to get near to the UDP > packet size limit. On a TCP connection, one can return a gabillizion > IPs from an A record lookup. Assuming each IPv4 address increases the > record size by 16 bytes, +20% TCP overhead, at 100Mbps, I reckon a > whole /8 could get through before the 20-sec time limit elapses. > > Is that worth an additional paragraph in Section 3.4 and 5.3? I > attempt that in the attached patch. Please comment on it. What if we just changed the last sentence before the first hunk of your patch from: > Note that when computing the sizes for queries of the TXT format, one has to > take into account any other TXT records published at the domain name. to > Note that when computing the sizes for queries of the TXT format, one has to > take into account the size of all records returned with the query, including > any other TXT records published at the domain name. I think that accomplishes the clarification you are after without the tutorial on how DNS works. Scott K From vesely@tana.it Sat Jan 19 03:47:40 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180FC21F845F for ; Sat, 19 Jan 2013 03:47:40 -0800 (PST) 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 dYtiBH7HIJd0 for ; Sat, 19 Jan 2013 03:47:39 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0BD21F851E for ; Sat, 19 Jan 2013 03:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358596056; bh=ObcbCJveOXY8np/npQcpRA7yGjh9KTgqraQ8jtMesiI=; l=1579; h=Date:From:To:References:In-Reply-To; b=chL4LanILBV/96XpMFu1bgP34gyQfXplHRih1yxLzhK3qSu5MUIrg6/Ug7o+IJQLd eWv1qlu4xJrFB5zrXwpZxm9a+wxeIrijehAuspRydYmhuo3hhlNhDE6Ar1r8DzFEU2 jSNYPccQDpniYw0/VcYZ5mIZInJgbFUwN+9eE1j0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 19 Jan 2013 12:47:36 +0100 id 00000000005DC039.0000000050FA87D8.00004EF4 Message-ID: <50FA87D7.4080103@tana.it> Date: Sat, 19 Jan 2013 12:47:35 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3679773.ridM3LemJv@scott-latitude-e6320> <50F92EA6.4020700@tana.it> <1420975.XPujRKHavV@scott-latitude-e6320> In-Reply-To: <1420975.XPujRKHavV@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 19 Jan 2013 11:47:40 -0000 On Fri 18/Jan/2013 20:51:29 +0100 Scott Kitterman wrote: > On Friday, January 18, 2013 12:14:46 PM Alessandro Vesely wrote: >> On a TCP connection, one can return a gabillizion IPs from an A >> record lookup. >> >> Is that worth an additional paragraph in Section 3.4 and 5.3? > > What if we just changed the last sentence before the first hunk of your patch > from: > > Note that when computing the sizes for queries of the TXT format, one has to > take into account any other TXT records published at the domain name. > > to > > Note that when computing the sizes for queries of the TXT format, one has to > take into account the size of all records returned with the query, including > any other TXT records published at the domain name. > > I think that accomplishes the clarification you are after without the tutorial > on how DNS works. It doesn't, because they are actually two queries. For example, on that base I'd conclude that the record short-spf-record.tana.it is perfectly good. Indeed, http://www.kitterman.com/spf/validate.html tells me the "SPF record passed validation test with pySPF", with no complaints. http://dmarcian.com/spf-survey/short-spf-record.tana.it instead says: "WARNING: DNS: Truncated UDP Reply, SPF records should fit in a UDP packet, retrying TCP" -- BTW, I'm amazed at how sharply the flattening comes out in that case. Bravo! I think Tim's diagnosis is correct, but cannot find a statement in the spec that supports it, since all records returned by the TXT query (1 record, that is) fit UDP size... From spf2@kitterman.com Sat Jan 19 07:05:41 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD421F8678 for ; Sat, 19 Jan 2013 07:05:41 -0800 (PST) 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 R6hEr38DQCaE for ; Sat, 19 Jan 2013 07:05:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 33C0D21F8635 for ; Sat, 19 Jan 2013 07:05:39 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 37FE920E41E7; Sat, 19 Jan 2013 10:05:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358607939; bh=mWnkP+puvEyloEX8HoJgem6bhLauFOYISL6iGuFdJx4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kl8y6QjtA0yaJHZ0Sw3jftOKPGR0FsUJhMWS8xPv5GnLajg02vqOp+txmjXxtDJH5 XZiBjm+oMihegVOMryW8wY4RDsb/xkk12YZxS4m4NDs3WrcSnyXTJbh3SOrZoC71N3 3VsgAW3979L6lof2KVB6iOQA27Bx1wTBwLENtV54= 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 1F8B420E4081; Sat, 19 Jan 2013 10:05:38 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 19 Jan 2013 10:05:34 -0500 Message-ID: <3023970.Tl3Mi1YvPR@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <50FA87D7.4080103@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1420975.XPujRKHavV@scott-latitude-e6320> <50FA87D7.4080103@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] #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: Sat, 19 Jan 2013 15:05:41 -0000 On Saturday, January 19, 2013 12:47:35 PM Alessandro Vesely wrote: > On Fri 18/Jan/2013 20:51:29 +0100 Scott Kitterman wrote: > > On Friday, January 18, 2013 12:14:46 PM Alessandro Vesely wrote: > >> On a TCP connection, one can return a gabillizion IPs from an A > >> record lookup. > >> > >> Is that worth an additional paragraph in Section 3.4 and 5.3? > > > > What if we just changed the last sentence before the first hunk of your > > patch> > > from: > > Note that when computing the sizes for queries of the TXT format, one has > > to take into account any other TXT records published at the domain name.> > > to > > > > Note that when computing the sizes for queries of the TXT format, one has > > to take into account the size of all records returned with the query, > > including any other TXT records published at the domain name. > > > > I think that accomplishes the clarification you are after without the > > tutorial on how DNS works. > > It doesn't, because they are actually two queries. For example, on > that base I'd conclude that the record short-spf-record.tana.it is > perfectly good. Indeed, http://www.kitterman.com/spf/validate.html > tells me the "SPF record passed validation test with pySPF", with no > complaints. That's because (surprise to me) the server that hosts that now supports EDNS 0, it was able to do it all in UDP. I'll fix that. > http://dmarcian.com/spf-survey/short-spf-record.tana.it instead says: > "WARNING: DNS: Truncated UDP Reply, SPF records should fit in a UDP > packet, retrying TCP" -- BTW, I'm amazed at how sharply the > flattening comes out in that case. Bravo! > > I think Tim's diagnosis is correct, but cannot find a statement in the > spec that supports it, since all records returned by the TXT query (1 > record, that is) fit UDP size... OK. How about: > Note that when computing the sizes for queries of the TXT format, one has > to take into account the size of all records returned with the query, > including any other TXT records published at the domain name. It is more > reliable if all answers for all queries needed to process the SPF record can > be returned in a single UDP packet. Scott K From vesely@tana.it Sat Jan 19 12:17:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8221F8545 for ; Sat, 19 Jan 2013 12:17:34 -0800 (PST) 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 ccQIuh6aRY01 for ; Sat, 19 Jan 2013 12:17:32 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6736B21F854F for ; Sat, 19 Jan 2013 12:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358626650; bh=QzuEw5vmeHhtwvAY/P+F+/Qoox1OIkSZ0845+gIgZXs=; l=1492; h=Date:From:To:References:In-Reply-To; b=LJeNvv9RxKLE57S3OFnNc92dKnrTLpu3TdYSn5XLTWllUVfSxLaYwRh3X4e/3flU/ pfn6mrNmz8Mk4No1WOzkbIZkIieUwk1DCPyL9eSnOVJ2bK8LysBgHOFiNAKfcLRfpY at6bXASZLDflpvASurBNOP0Zkx3Lb7t5BNN1J/70= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 19 Jan 2013 21:17:30 +0100 id 00000000005DC042.0000000050FAFF5A.00007B14 Message-ID: <50FAFF5A.8030906@tana.it> Date: Sat, 19 Jan 2013 21:17:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1420975.XPujRKHavV@scott-latitude-e6320> <50FA87D7.4080103@tana.it> <3023970.Tl3Mi1YvPR@scott-latitude-e6320> In-Reply-To: <3023970.Tl3Mi1YvPR@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 19 Jan 2013 20:17:34 -0000 On Sat 19/Jan/2013 16:05:34 +0100 Scott Kitterman wrote: > On Saturday, January 19, 2013 12:47:35 PM Alessandro Vesely wrote: >> I think Tim's diagnosis is correct, but cannot find a statement in the >> spec that supports it, since all records returned by the TXT query (1 >> record, that is) fit UDP size... > > OK. How about: > > Note that when computing the sizes for queries of the TXT format, one has > to take into account the size of all records returned with the query, > including any other TXT records published at the domain name. It is more > reliable if all answers for all queries needed to process the SPF record can > be returned in a single UDP packet. Yeah, that's the idea, more or less... I think that the reliability gain obtained by UDP optimization is the same for TXT records as for any other type. In that case, I could try and reword the whole paragraph so as to avoid that dangling "more reliable", and s/a single UDP packet/UDP packets/. You didn't say anything about the paragraph proposed for Section 5.3, did you? That was: An UDP DNS reply might hold 20 type A records, or 10 type AAAA ones, but is likey to get truncated at quantities near or above those values, and thus require fallback to TCP connections. Publishers are encouraged to carefully test their SPF records in such cases. Besides repeating the same concept, the latter also gives rough estimates. The other types (mx and ptr) already have their own limits. From prvs=7244fd969=fmartin@linkedin.com Sat Jan 19 12:48:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B750B21F84C9 for ; Sat, 19 Jan 2013 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWINtBYYVIRL for ; Sat, 19 Jan 2013 12:48:43 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3893221F8439 for ; Sat, 19 Jan 2013 12:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1358628523; x=1390164523; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FnCS08OMCvIaWHNOnS2Jc3UX8ln7sXGniJCSaXWok/c=; b=Zyhkz6b6wHI1yW3EdZtAeL0EwmvN24byihDFY8sNxqszmkKvEVbtngw0 6Icm6tOlbscsPjd1OtjrkOZCwnFfs/XcEsjXwJYIEC8tJcWpVMyNl0rG6 kShm9PB8Hok4NptaM0yNBGP5NyeQvuhD6hSGo5Hd9qvnPMCCNSlMrbco0 k=; X-IronPort-AV: E=Sophos;i="4.84,499,1355126400"; d="scan'208";a="36825911" 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; Sat, 19 Jan 2013 12:48:19 -0800 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHN9W0FGn+8opfWQ0SliDov9l1m4JhQBayAgAELIYCAADdRAP//2bwA Date: Sat, 19 Jan 2013 20:48:18 +0000 Message-ID: In-Reply-To: <3023970.Tl3Mi1YvPR@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.250] Content-Type: text/plain; charset="utf-8" Content-ID: <37275CA89A6F034EB1326F36F28EF5CB@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Sat, 19 Jan 2013 20:48:44 -0000 DQoNCk9uIDEvMTkvMTMgNzowNSBBTSwgIlNjb3R0IEtpdHRlcm1hbiIgPHNwZjJAa2l0dGVybWFu LmNvbT4gd3JvdGU6DQoNCj5PbiBTYXR1cmRheSwgSmFudWFyeSAxOSwgMjAxMyAxMjo0NzozNSBQ TSBBbGVzc2FuZHJvIFZlc2VseSB3cm90ZToNCj4+IE9uIEZyaSAxOC9KYW4vMjAxMyAyMDo1MToy OSArMDEwMCBTY290dCBLaXR0ZXJtYW4gd3JvdGU6DQo+PiA+IE9uIEZyaWRheSwgSmFudWFyeSAx OCwgMjAxMyAxMjoxNDo0NiBQTSBBbGVzc2FuZHJvIFZlc2VseSB3cm90ZToNCj4+ID4+IE9uIGEg VENQIGNvbm5lY3Rpb24sIG9uZSBjYW4gcmV0dXJuIGEgZ2FiaWxsaXppb24gSVBzIGZyb20gYW4g QQ0KPj4gPj4gcmVjb3JkIGxvb2t1cC4NCj4+ID4+IA0KPj4gPj4gSXMgdGhhdCB3b3J0aCBhbiBh ZGRpdGlvbmFsIHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuNCBhbmQgNS4zPw0KPj4gPiANCj4+ID4g V2hhdCBpZiB3ZSBqdXN0IGNoYW5nZWQgdGhlIGxhc3Qgc2VudGVuY2UgYmVmb3JlIHRoZSBmaXJz dCBodW5rIG9mDQo+PnlvdXINCj4+ID4gcGF0Y2g+IA0KPj4gPiBmcm9tOg0KPj4gPiAgTm90ZSB0 aGF0IHdoZW4gY29tcHV0aW5nIHRoZSBzaXplcyBmb3IgcXVlcmllcyBvZiB0aGUgVFhUIGZvcm1h dCwNCj4+b25lIGhhcw0KPj4gPiAgdG8gdGFrZSBpbnRvIGFjY291bnQgYW55IG90aGVyIFRYVCBy ZWNvcmRzIHB1Ymxpc2hlZCBhdCB0aGUgZG9tYWluDQo+Pm5hbWUuPiANCj4+ID4gdG8NCj4+ID4g DQo+PiA+ICBOb3RlIHRoYXQgd2hlbiBjb21wdXRpbmcgdGhlIHNpemVzIGZvciBxdWVyaWVzIG9m IHRoZSBUWFQgZm9ybWF0LA0KPj5vbmUgaGFzDQo+PiA+ICB0byB0YWtlIGludG8gYWNjb3VudCB0 aGUgc2l6ZSBvZiBhbGwgcmVjb3JkcyByZXR1cm5lZCB3aXRoIHRoZSBxdWVyeSwNCj4+ID4gIGlu Y2x1ZGluZyBhbnkgb3RoZXIgVFhUIHJlY29yZHMgcHVibGlzaGVkIGF0IHRoZSBkb21haW4gbmFt ZS4NCj4+ID4gDQo+PiA+IEkgdGhpbmsgdGhhdCBhY2NvbXBsaXNoZXMgdGhlIGNsYXJpZmljYXRp b24geW91IGFyZSBhZnRlciB3aXRob3V0IHRoZQ0KPj4gPiB0dXRvcmlhbCBvbiBob3cgRE5TIHdv cmtzLg0KPj4gDQo+PiBJdCBkb2Vzbid0LCBiZWNhdXNlIHRoZXkgYXJlIGFjdHVhbGx5IHR3byBx dWVyaWVzLiAgRm9yIGV4YW1wbGUsIG9uDQo+PiB0aGF0IGJhc2UgSSdkIGNvbmNsdWRlIHRoYXQg dGhlIHJlY29yZCBzaG9ydC1zcGYtcmVjb3JkLnRhbmEuaXQgaXMNCj4+IHBlcmZlY3RseSBnb29k LiAgSW5kZWVkLCBodHRwOi8vd3d3LmtpdHRlcm1hbi5jb20vc3BmL3ZhbGlkYXRlLmh0bWwNCj4+ IHRlbGxzIG1lIHRoZSAiU1BGIHJlY29yZCBwYXNzZWQgdmFsaWRhdGlvbiB0ZXN0IHdpdGggcHlT UEYiLCB3aXRoIG5vDQo+PiBjb21wbGFpbnRzLg0KPg0KPlRoYXQncyBiZWNhdXNlIChzdXJwcmlz ZSB0byBtZSkgdGhlIHNlcnZlciB0aGF0IGhvc3RzIHRoYXQgbm93IHN1cHBvcnRzDQo+RUROUyAN Cj4wLCBpdCB3YXMgYWJsZSB0byBkbyBpdCBhbGwgaW4gVURQLiAgSSdsbCBmaXggdGhhdC4NCj4N Cj4+IGh0dHA6Ly9kbWFyY2lhbi5jb20vc3BmLXN1cnZleS9zaG9ydC1zcGYtcmVjb3JkLnRhbmEu aXQgaW5zdGVhZCBzYXlzOg0KPj4gIldBUk5JTkc6IEROUzogVHJ1bmNhdGVkIFVEUCBSZXBseSwg U1BGIHJlY29yZHMgc2hvdWxkIGZpdCBpbiBhIFVEUA0KPj4gcGFja2V0LCByZXRyeWluZyBUQ1Ai ICAgLS0gQlRXLCBJJ20gYW1hemVkIGF0IGhvdyBzaGFycGx5IHRoZQ0KPj4gZmxhdHRlbmluZyBj b21lcyBvdXQgaW4gdGhhdCBjYXNlLiAgQnJhdm8hDQo+PiANCj4+IEkgdGhpbmsgVGltJ3MgZGlh Z25vc2lzIGlzIGNvcnJlY3QsIGJ1dCBjYW5ub3QgZmluZCBhIHN0YXRlbWVudCBpbiB0aGUNCj4+ IHNwZWMgdGhhdCBzdXBwb3J0cyBpdCwgc2luY2UgYWxsIHJlY29yZHMgcmV0dXJuZWQgYnkgdGhl IFRYVCBxdWVyeSAoMQ0KPj4gcmVjb3JkLCB0aGF0IGlzKSBmaXQgVURQIHNpemUuLi4NCj4NCj5P Sy4gIEhvdyBhYm91dDoNCj4NCj4+ICBOb3RlIHRoYXQgd2hlbiBjb21wdXRpbmcgdGhlIHNpemVz IGZvciBxdWVyaWVzIG9mIHRoZSBUWFQgZm9ybWF0LCBvbmUNCj4+aGFzDQo+PiAgdG8gdGFrZSBp bnRvIGFjY291bnQgdGhlIHNpemUgb2YgYWxsIHJlY29yZHMgcmV0dXJuZWQgd2l0aCB0aGUgcXVl cnksDQo+PiAgaW5jbHVkaW5nIGFueSBvdGhlciBUWFQgcmVjb3JkcyBwdWJsaXNoZWQgYXQgdGhl IGRvbWFpbiBuYW1lLiAgSXQgaXMNCj4+bW9yZQ0KPj4gcmVsaWFibGUgaWYgYWxsIGFuc3dlcnMg Zm9yIGFsbCBxdWVyaWVzIG5lZWRlZCB0byBwcm9jZXNzIHRoZSBTUEYNCj4+cmVjb3JkIGNhbg0K Pj4gYmUgcmV0dXJuZWQgaW4gYSBzaW5nbGUgVURQIHBhY2tldC4NCg0KUmVwbGFjZSByZWxpYWJs ZSBieSBlZmZpY2llbnQgaW4gdGhlIGFib3ZlLCBvdGhlcndpc2UgeW91IG1heSBpbmZlciB0aGF0 DQpETlMgZmFsbGJhY2sgdG8gVENQIGlzIG5vdCBhIHJlbGlhYmxlIHN0YW5kYXJkLg0KDQo= From spf2@kitterman.com Sun Jan 20 15:15:54 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D893621F8803 for ; Sun, 20 Jan 2013 15:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2aDep1c4qEF for ; Sun, 20 Jan 2013 15:15:54 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id D912A21F87FD for ; Sun, 20 Jan 2013 15:15:50 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2A1C5D04066; Sun, 20 Jan 2013 17:15:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358723750; bh=YZwIdI1LTLEpImx+iJxTp6tx2Znby8cN21Rfbss/MN4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=kmh79AHPTK9DA4V1b1w+CFGfqGQx/YG9fumdk+4m4D8m8Q2/SND4okqMBlVfa1M5x MS+7BqLHFg4KxVGVCJ+BO9zWxqPhtjlY/XWqwofW0aUXSNU4aKlnOMQemIdd6dtlAZ yGYSFJp/PgWHrwAxkA8tDPR68cr1kXNpCUEWTOpo= Received: from [192.168.111.102] (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 DE4AAD04065; Sun, 20 Jan 2013 17:15:49 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 20 Jan 2013 18:04:24 -0500 To: "spfbis@ietf.org" Message-ID: <4367ef8f-a24f-4e3b-97d5-80754c520cff@email.android.com> 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: Sun, 20 Jan 2013 23:15:55 -0000 Franck Martin wrote: > > >On 1/19/13 7:05 AM, "Scott Kitterman" wrote: > >>On Saturday, January 19, 2013 12:47:35 PM Alessandro Vesely wrote: >>> On Fri 18/Jan/2013 20:51:29 +0100 Scott Kitterman wrote: >>> > On Friday, January 18, 2013 12:14:46 PM Alessandro Vesely wrote: >>> >> On a TCP connection, one can return a gabillizion IPs from an A >>> >> record lookup. >>> >> >>> >> Is that worth an additional paragraph in Section 3.4 and 5.3? >>> > >>> > What if we just changed the last sentence before the first hunk of >>>your >>> > patch> >>> > from: >>> > Note that when computing the sizes for queries of the TXT format, >>>one has >>> > to take into account any other TXT records published at the >domain >>>name.> >>> > to >>> > >>> > Note that when computing the sizes for queries of the TXT format, >>>one has >>> > to take into account the size of all records returned with the >query, >>> > including any other TXT records published at the domain name. >>> > >>> > I think that accomplishes the clarification you are after without >the >>> > tutorial on how DNS works. >>> >>> It doesn't, because they are actually two queries. For example, on >>> that base I'd conclude that the record short-spf-record.tana.it is >>> perfectly good. Indeed, http://www.kitterman.com/spf/validate.html >>> tells me the "SPF record passed validation test with pySPF", with no >>> complaints. >> >>That's because (surprise to me) the server that hosts that now >supports >>EDNS >>0, it was able to do it all in UDP. I'll fix that. >> >>> http://dmarcian.com/spf-survey/short-spf-record.tana.it instead >says: >>> "WARNING: DNS: Truncated UDP Reply, SPF records should fit in a UDP >>> packet, retrying TCP" -- BTW, I'm amazed at how sharply the >>> flattening comes out in that case. Bravo! >>> >>> I think Tim's diagnosis is correct, but cannot find a statement in >the >>> spec that supports it, since all records returned by the TXT query >(1 >>> record, that is) fit UDP size... >> >>OK. How about: >> >>> Note that when computing the sizes for queries of the TXT format, >one >>>has >>> to take into account the size of all records returned with the >query, >>> including any other TXT records published at the domain name. It >is >>>more >>> reliable if all answers for all queries needed to process the SPF >>>record can >>> be returned in a single UDP packet. > >Replace reliable by efficient in the above, otherwise you may infer >that >DNS fallback to TCP is not a reliable standard. That's the point. Operationally it's not reliable because it's unfortunately common for port 53 TCP to be blocked. Scott K From prvs=725ba6107=fmartin@linkedin.com Sun Jan 20 15:39:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC421F871E for ; Sun, 20 Jan 2013 15:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[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 imAjbogK6s+z for ; Sun, 20 Jan 2013 15:39:47 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id CA8A921F8700 for ; Sun, 20 Jan 2013 15:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1358725130; x=1390261130; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=a62mPsSlRbvAm02QEEIApbXcF2jLAV9XXuQWQ8v3VoM=; b=Bf34lgCT6xU/HSGXmHZPqtkycfECKUtf+4MC9GzQYUdApklD0PFug+V7 Sfmm+/13YNmfxF6yuQs3E1LuURNRw4G1o3KP7ob/XZxW4hjoXihq+DrCI c5KbwMB6le5xDb2JcuBPH3x9AhaQb8bdgrryzQ8JKaw1dGEtr+jOM5LBc k=; X-IronPort-AV: E=Sophos;i="4.84,501,1355126400"; d="scan'208";a="36871791" 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; Sun, 20 Jan 2013 15:38:27 -0800 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHN9W0FGn+8opfWQ0SliDov9l1m4JhQBayAgAELIYCAADdRAP//2bwAgAI+YgD//4N7AA== Date: Sun, 20 Jan 2013 23:38:26 +0000 Message-ID: In-Reply-To: <4367ef8f-a24f-4e3b-97d5-80754c520cff@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="utf-8" Content-ID: <30471F9906AC0046A4BCA76ADC7ACE80@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Sun, 20 Jan 2013 23:39:47 -0000 DQoNCk9uIDEvMjAvMTMgMzowNCBQTSwgIlNjb3R0IEtpdHRlcm1hbiIgPHNwZjJAa2l0dGVybWFu LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj5GcmFuY2sgTWFydGluIDxmbWFydGluQGxpbmtlZGluLmNv bT4gd3JvdGU6DQo+DQo+Pg0KPj4NCj4+T24gMS8xOS8xMyA3OjA1IEFNLCAiU2NvdHQgS2l0dGVy bWFuIiA8c3BmMkBraXR0ZXJtYW4uY29tPiB3cm90ZToNCj4+DQo+Pj5PbiBTYXR1cmRheSwgSmFu dWFyeSAxOSwgMjAxMyAxMjo0NzozNSBQTSBBbGVzc2FuZHJvIFZlc2VseSB3cm90ZToNCj4+Pj4g T24gRnJpIDE4L0phbi8yMDEzIDIwOjUxOjI5ICswMTAwIFNjb3R0IEtpdHRlcm1hbiB3cm90ZToN Cj4+Pj4NCj4+Pj4gIE5vdGUgdGhhdCB3aGVuIGNvbXB1dGluZyB0aGUgc2l6ZXMgZm9yIHF1ZXJp ZXMgb2YgdGhlIFRYVCBmb3JtYXQsDQo+Pm9uZQ0KPj4+Pmhhcw0KPj4+PiAgdG8gdGFrZSBpbnRv IGFjY291bnQgdGhlIHNpemUgb2YgYWxsIHJlY29yZHMgcmV0dXJuZWQgd2l0aCB0aGUNCj4+cXVl cnksDQo+Pj4+ICBpbmNsdWRpbmcgYW55IG90aGVyIFRYVCByZWNvcmRzIHB1Ymxpc2hlZCBhdCB0 aGUgZG9tYWluIG5hbWUuICBJdA0KPj5pcw0KPj4+Pm1vcmUNCj4+Pj4gcmVsaWFibGUgaWYgYWxs IGFuc3dlcnMgZm9yIGFsbCBxdWVyaWVzIG5lZWRlZCB0byBwcm9jZXNzIHRoZSBTUEYNCj4+Pj5y ZWNvcmQgY2FuDQo+Pj4+IGJlIHJldHVybmVkIGluIGEgc2luZ2xlIFVEUCBwYWNrZXQuDQo+Pg0K Pj5SZXBsYWNlIHJlbGlhYmxlIGJ5IGVmZmljaWVudCBpbiB0aGUgYWJvdmUsIG90aGVyd2lzZSB5 b3UgbWF5IGluZmVyDQo+PnRoYXQNCj4+RE5TIGZhbGxiYWNrIHRvIFRDUCBpcyBub3QgYSByZWxp YWJsZSBzdGFuZGFyZC4NCj4NCj5UaGF0J3MgdGhlIHBvaW50LiAgT3BlcmF0aW9uYWxseSBpdCdz IG5vdCByZWxpYWJsZSBiZWNhdXNlIGl0J3MNCj51bmZvcnR1bmF0ZWx5IGNvbW1vbiBmb3IgcG9y dCA1MyBUQ1AgdG8gYmUgYmxvY2tlZC4NCj4NCg0KWWVzIGFuZCBteSBwb2ludCBpcyB0aGF0IHRo ZXJlIGlzIG5vdGhpbmcgd3Jvbmcgd2l0aCB0aGUgcHJvdG9jb2wsIGl0IGlzDQphbiBvcGVyYXRp b25hbCBpc3N1ZS4gUGVvcGxlIGFyZSBmcmVlIHRvIHNob290IHRoZW1zZWx2ZXMgaW4gdGhlIGZv b3QuDQoNCg== From spf2@kitterman.com Mon Jan 21 07:39:01 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1610A21F8712 for ; Mon, 21 Jan 2013 07:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3QRd6nK9pLW for ; Mon, 21 Jan 2013 07:39:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 128C021F86F6 for ; Mon, 21 Jan 2013 07:38:59 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DC0CD20E40DE; Mon, 21 Jan 2013 10:38:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358782738; bh=VHezJF0rzWF+zrbytmXo1SzHeshp8bpbhOo/BUuGAQk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bTkBo53KWSxVHPDIRnhDYK911XWU9UeJZUY6yke5fL0qmFUsaXfLSq+7Jpmt1wLud +ZTF2GO27cCTyP2prHJOxMWumGClEZNdT31Ye0SFhOJf2T87f89EmjkMurKGw+gSdZ jSFPIYF0v/zxHGhJeJ9FrilRZsw1f4pOTAQWdypU= 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 BF02920E4079; Mon, 21 Jan 2013 10:38:58 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 21 Jan 2013 10:38:54 -0500 Message-ID: <1521021.ATLg1YSqgi@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.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] #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: Mon, 21 Jan 2013 15:39:01 -0000 On Sunday, January 20, 2013 11:38:26 PM Franck Martin wrote: > On 1/20/13 3:04 PM, "Scott Kitterman" wrote: > >Franck Martin wrote: > >>On 1/19/13 7:05 AM, "Scott Kitterman" wrote: > >>>On Saturday, January 19, 2013 12:47:35 PM Alessandro Vesely wrote: > >>>> On Fri 18/Jan/2013 20:51:29 +0100 Scott Kitterman wrote: > >>>> Note that when computing the sizes for queries of the TXT format, > >>one > >>>>has > >>>> to take into account the size of all records returned with the > >>query, > >>>> including any other TXT records published at the domain name. It > >>is > >>>>more > >>>> reliable if all answers for all queries needed to process the SPF > >>>>record can > >>>> be returned in a single UDP packet. > >>Replace reliable by efficient in the above, otherwise you may infer > >>that > >>DNS fallback to TCP is not a reliable standard. > > > >That's the point. Operationally it's not reliable because it's > >unfortunately common for port 53 TCP to be blocked. > > Yes and my point is that there is nothing wrong with the protocol, it is > an operational issue. People are free to shoot themselves in the foot. Which is why there's no 2119 mustard around the point. People are, but we shouldn't require people to be experts in DNS to write an SPF record. The guidance to fit into UDP is in RFC 4408 and I think that extending the advice to include mentioning other records is a reasonable thing to do. Scott K From spf2@kitterman.com Mon Jan 21 07:40:54 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0421F8746 for ; Mon, 21 Jan 2013 07:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSb3NIKkr-pX for ; Mon, 21 Jan 2013 07:40:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A59321F8742 for ; Mon, 21 Jan 2013 07:40:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0058420E40DE; Mon, 21 Jan 2013 10:40:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358782853; bh=0xySkO1c/5YgT1uXt2GzllL0zvYAZmZ9kx1U8W4exjc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PiPJRA4Ur+Eeb2sZ909gHuFOxlFlRW6xpYK0ZMP2dgXcFF7ejFrTkKW2ItJY9BjiC hRVCrJjU9M+UaC0InxyWJxMPCVyM5T7Uv3HYdYOM5JX8D93PSo5GiMM4DkjjE343oP X4I27Lp4+NylWvn1ff/YfVR6mvmnm0cM5ruLYDMc= 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 D74CA20E4079; Mon, 21 Jan 2013 10:40:52 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 21 Jan 2013 10:40:52 -0500 Message-ID: <1877012.fNkqOh70Vh@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <50FAFF5A.8030906@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3023970.Tl3Mi1YvPR@scott-latitude-e6320> <50FAFF5A.8030906@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] #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: Mon, 21 Jan 2013 15:40:54 -0000 On Saturday, January 19, 2013 09:17:30 PM Alessandro Vesely wrote: > On Sat 19/Jan/2013 16:05:34 +0100 Scott Kitterman wrote: > > On Saturday, January 19, 2013 12:47:35 PM Alessandro Vesely wrote: > >> I think Tim's diagnosis is correct, but cannot find a statement in the > >> spec that supports it, since all records returned by the TXT query (1 > >> record, that is) fit UDP size... > > > > OK. How about: > > Note that when computing the sizes for queries of the TXT format, one > > has > > to take into account the size of all records returned with the query, > > including any other TXT records published at the domain name. It is > > more > > reliable if all answers for all queries needed to process the SPF record > > can be returned in a single UDP packet. > > Yeah, that's the idea, more or less... I think that the reliability > gain obtained by UDP optimization is the same for TXT records as for > any other type. In that case, I could try and reword the whole > paragraph so as to avoid that dangling "more reliable", and s/a single > UDP packet/UDP packets/. > > You didn't say anything about the paragraph proposed for Section 5.3, > did you? That was: > > An UDP DNS reply might hold 20 type A records, or 10 type AAAA ones, > but is likey to get truncated at quantities near or above those > values, and thus require fallback to TCP connections. Publishers are > encouraged to carefully test their SPF records in such cases. > > Besides repeating the same concept, the latter also gives rough > estimates. The other types (mx and ptr) already have their own limits. I hesitate to give specific guidance because there are quite a number of variables involved. With the change in the first paragraph, it seemed to me the change for the second was no longer needed. Scott K From ajs@anvilwalrusden.com Tue Jan 22 15:14:22 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A3A21F8AC8 for ; Tue, 22 Jan 2013 15:14:14 -0800 (PST) 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 PRoAFjqrjvMF for ; Tue, 22 Jan 2013 15:14:13 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CBE0121F880B for ; Tue, 22 Jan 2013 15:14:09 -0800 (PST) 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 64E5B8A031 for ; Tue, 22 Jan 2013 23:14:02 +0000 (UTC) Date: Tue, 22 Jan 2013 18:13:57 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130122231357.GA6921@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <1420975.XPujRKHavV@scott-latitude-e6320> <50FA87D7.4080103@tana.it> <3023970.Tl3Mi1YvPR@scott-latitude-e6320> <50FAFF5A.8030906@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50FAFF5A.8030906@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Tue, 22 Jan 2013 23:14:23 -0000 No hat. On Sat, Jan 19, 2013 at 09:17:30PM +0100, Alessandro Vesely wrote: > Besides repeating the same concept, the latter also gives rough > estimates. The other types (mx and ptr) already have their own limits. I see no reason this document should have recommendations about how to run DNS in general. There already are documents about message size and the DNS. Moreover, the entire thing seems to hang on the dubious principle that you can usefully operate on the Internet today without EDNS0. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Jan 22 15:26:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A168A21F8A5A for ; Tue, 22 Jan 2013 15:26:28 -0800 (PST) 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 StxG03HpZ4Rh for ; Tue, 22 Jan 2013 15:26:27 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 94E4F21F87E7 for ; Tue, 22 Jan 2013 15:26:27 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A751E20E40FC; Tue, 22 Jan 2013 18:26:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358897186; bh=p22XrJdyzVB8zi9t2cGxBZZRz44hZlaGQh/vRTXMMqs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZhiHTBH+j6ON2Yis5OPQBNPA3KxsZ+QNfgl2FLaLAxVXz2ipkx0TSYnAsISiyYeob FZ/Upcu2IOBO+njPvtLKkmeK986WnoJlnbrTPrPJPGtazpkLoQCVMpa8lCuhI82wsx ShPP5pO0QIhsKPY0GgDEsOY9mYeOD4zGx70lPCjE= Received: from scott-latitude-e6320.localnet (243.sub-70-192-200.myvzw.com [70.192.200.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 826C720E4085; Tue, 22 Jan 2013 18:26:26 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 22 Jan 2013 18:26:24 -0500 Message-ID: <3896517.k8tBVMT4Fi@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130122231357.GA6921@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <50FAFF5A.8030906@tana.it> <20130122231357.GA6921@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #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: Tue, 22 Jan 2013 23:26:28 -0000 On Tuesday, January 22, 2013 06:13:57 PM Andrew Sullivan wrote: > No hat. > > On Sat, Jan 19, 2013 at 09:17:30PM +0100, Alessandro Vesely wrote: > > Besides repeating the same concept, the latter also gives rough > > estimates. The other types (mx and ptr) already have their own limits. > > I see no reason this document should have recommendations about how to > run DNS in general. There already are documents about message size > and the DNS. > > Moreover, the entire thing seems to hang on the dubious principle that > you can usefully operate on the Internet today without EDNS0. It is not rare to see problems due to TCP fallback being blocked. If EDNS0 were ubiquitous, I don't think it would come up. It's most reliable to fit an answer into a UDP packet still seems to me to be good advice (and is consistent with RFC 4408). Scott K From prvs=7272c9e8d=fmartin@linkedin.com Tue Jan 22 15:34:45 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393D421F8794 for ; Tue, 22 Jan 2013 15:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.299, 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 wXFpjhx5qBO9 for ; Tue, 22 Jan 2013 15:34:44 -0800 (PST) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBF121F86CC for ; Tue, 22 Jan 2013 15:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1358897684; x=1390433684; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4EPL5NtTu2pMeqy5SU1pDFvekbUQgi1FUsM798Zfo8A=; b=mpqxqw7X2nnklwaaSohMVtrVyFoFNr1ukfQkmuP+0kc8zfF5uN2qR3vK Ne2ZZ98eSOzbx7FOpqC4EbRJpwgDT/DUqrcmT6DVOjP+v9uNhtzHAorlR w+howQP5iz2fpvQleTdWCaP5F0XT3iEl6ZRvOJRu4ZykNVJosa3dQch+j 4=; X-IronPort-AV: E=Sophos;i="4.84,517,1355126400"; d="scan'208";a="36055471" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jan 2013 15:34:20 -0800 Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Tue, 22 Jan 2013 15:34:20 -0800 From: Franck Martin To: Scott Kitterman , "spfbis@ietf.org" Thread-Topic: [spfbis] #24: RFC 4408: Reasonable DNS error limits Thread-Index: AQHN9W0FGn+8opfWQ0SliDov9l1m4JhQBayAgAELIYCAADdRAIAAVycAgAToTICAAAN6AP//fC+A Date: Tue, 22 Jan 2013 23:34:19 +0000 Message-ID: In-Reply-To: <3896517.k8tBVMT4Fi@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.250] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Tue, 22 Jan 2013 23:34:45 -0000 DQoNCk9uIDEvMjIvMTMgMzoyNiBQTSwgIlNjb3R0IEtpdHRlcm1hbiIgPHNwZjJAa2l0dGVybWFu LmNvbT4gd3JvdGU6DQoNCj5PbiBUdWVzZGF5LCBKYW51YXJ5IDIyLCAyMDEzIDA2OjEzOjU3IFBN IEFuZHJldyBTdWxsaXZhbiB3cm90ZToNCj4+IE5vIGhhdC4NCj4+IA0KPj4gT24gU2F0LCBKYW4g MTksIDIwMTMgYXQgMDk6MTc6MzBQTSArMDEwMCwgQWxlc3NhbmRybyBWZXNlbHkgd3JvdGU6DQo+ PiA+IEJlc2lkZXMgcmVwZWF0aW5nIHRoZSBzYW1lIGNvbmNlcHQsIHRoZSBsYXR0ZXIgYWxzbyBn aXZlcyByb3VnaA0KPj4gPiBlc3RpbWF0ZXMuICBUaGUgb3RoZXIgdHlwZXMgKG14IGFuZCBwdHIp IGFscmVhZHkgaGF2ZSB0aGVpciBvd24NCj4+bGltaXRzLg0KPj4gDQo+PiBJIHNlZSBubyByZWFz b24gdGhpcyBkb2N1bWVudCBzaG91bGQgaGF2ZSByZWNvbW1lbmRhdGlvbnMgYWJvdXQgaG93IHRv DQo+PiBydW4gRE5TIGluIGdlbmVyYWwuICBUaGVyZSBhbHJlYWR5IGFyZSBkb2N1bWVudHMgYWJv dXQgbWVzc2FnZSBzaXplDQo+PiBhbmQgdGhlIEROUy4NCj4+IA0KPj4gTW9yZW92ZXIsIHRoZSBl bnRpcmUgdGhpbmcgc2VlbXMgdG8gaGFuZyBvbiB0aGUgZHViaW91cyBwcmluY2lwbGUgdGhhdA0K Pj4geW91IGNhbiB1c2VmdWxseSBvcGVyYXRlIG9uIHRoZSBJbnRlcm5ldCB0b2RheSB3aXRob3V0 IEVETlMwLg0KPg0KPkl0IGlzIG5vdCByYXJlIHRvIHNlZSBwcm9ibGVtcyBkdWUgdG8gVENQIGZh bGxiYWNrIGJlaW5nIGJsb2NrZWQuICBJZg0KPkVETlMwIA0KPndlcmUgdWJpcXVpdG91cywgSSBk b24ndCB0aGluayBpdCB3b3VsZCBjb21lIHVwLiAgSXQncyBtb3N0IHJlbGlhYmxlIHRvDQo+Zml0 IGFuIA0KPmFuc3dlciBpbnRvIGEgVURQIHBhY2tldCBzdGlsbCBzZWVtcyB0byBtZSB0byBiZSBn b29kIGFkdmljZSAoYW5kIGlzDQo+Y29uc2lzdGVudCB3aXRoIFJGQyA0NDA4KS4NCj4NCg0KQ29u c2lkZXJpbmcgdGhhdCBub3cgZ29vZ2xlIHVzZXMgMjA0OGJpdCBES0lNIGtleXMgKHRoYXQgZG9u J3QgZXZlbiBmaXQgaW4NCmFuIFVEUCBwYWNrZXQpLCBJIGhhdmUgYWxyZWFkeSBzZWVuIGEgZHVo ISBtb21lbnQuIEkgc3VzcGVjdCB0aGUgcHJvYmxlbQ0Kd2lsbCBnbyBhd2F5IHJlbGF0aXZlbHkg cXVpY2tseSBub3cgZXhjZXB0IGZvciB0aGUgbWFjaGluZXMsIHBhc3MgdGhlIGRvb3INCndpdGgg YSBzaWduIHNheWluZyAiQmV3YXJlIG9mIHRoZSBMZW9wYXJkIi4NCg0K From ajs@anvilwalrusden.com Tue Jan 22 17:01:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23021F882D for ; Tue, 22 Jan 2013 17:01:25 -0800 (PST) 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 abZmQwYDGOTO for ; Tue, 22 Jan 2013 17:01:24 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1237D21F8824 for ; Tue, 22 Jan 2013 17:01:23 -0800 (PST) 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 C17BC8A031 for ; Wed, 23 Jan 2013 01:01:21 +0000 (UTC) Date: Tue, 22 Jan 2013 20:01:20 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130123010120.GC7073@crankycanuck.ca> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <50FAFF5A.8030906@tana.it> <20130122231357.GA6921@mx1.yitter.info> <3896517.k8tBVMT4Fi@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3896517.k8tBVMT4Fi@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 23 Jan 2013 01:01:25 -0000 No hat. On Tue, Jan 22, 2013 at 06:26:24PM -0500, Scott Kitterman wrote: > It is not rare to see problems due to TCP fallback being blocked. This is true, but if we're going to say anything here it ought to be, "Blocking TCP fallback violates the DNS protocol and may negatively affect SPF." It's a flat-out violation of the protocol, and always has been. If people aren't going to use the protocol we depend on, we're screwed anyway. > If EDNS0 > were ubiquitous, I don't think it would come up. Unfortunately not true, as we have learned at length with DNSSEC deployment. The problem is mostly that people have extremely incorrect ideas about how big their buffers are, and misstate them in their EDNS0 buffer parameters. This causes EDNS0 to fail sometimes even where it's available. Again, however, I think, this is stuff that simply doesn't belong in the SPF document, because DNSOP is already busy explaining (or has already explained) all of this in various places. If we just need references, I'll dig them up (I guess we probably do, so I suppose I just volunteered to do work). > It's most reliable to fit an > answer into a UDP packet still seems to me to be good advice (and is > consistent with RFC 4408). I am perfectly happy if the document says, "This will be most reliable if all responses fit inside the traditional DNS UDP limit. Note that DNSSEC may strain that limit anyway." More than that seems to me to be borrowing trouble. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Jan 22 19:22:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0733E21F84F3 for ; Tue, 22 Jan 2013 19:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkdFLs1g3P8 for ; Tue, 22 Jan 2013 19:22:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB921F8444 for ; Tue, 22 Jan 2013 19:22:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D154A20E40FC; Tue, 22 Jan 2013 22:22:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358911356; bh=g67VKdsNVR0GY2fOW/hhQb+IX9KLpkWvzVQRDCa8l54=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VafyAriV7NXyqvf47UIQt526HVxtYg9wqXOzOW1taoyk3opxXwhIgfepTZ9JpT9pk NfJn4HTAKIQSbEe8gVOyeAF/QN0Lex3bX/TMekQzWmqc+DOZWSKI/KOZCVcuZ4/rMo LH9baWKNhdT07L308wIRZsICovbKFvo6UiPDXcCg= 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 B5BE220E4085; Tue, 22 Jan 2013 22:22:36 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 22 Jan 2013 22:22:35 -0500 Message-ID: <271785100.KEZggNLeh1@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130123010120.GC7073@crankycanuck.ca> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #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, 23 Jan 2013 03:22:42 -0000 On Tuesday, January 22, 2013 08:01:20 PM Andrew Sullivan wrote: > No hat. > > On Tue, Jan 22, 2013 at 06:26:24PM -0500, Scott Kitterman wrote: > > It is not rare to see problems due to TCP fallback being blocked. > > This is true, but if we're going to say anything here it ought to be, > "Blocking TCP fallback violates the DNS protocol and may negatively > affect SPF." It's a flat-out violation of the protocol, and always > has been. If people aren't going to use the protocol we depend on, > we're screwed anyway. > > > If EDNS0 > > were ubiquitous, I don't think it would come up. > > Unfortunately not true, as we have learned at length with DNSSEC > deployment. The problem is mostly that people have extremely > incorrect ideas about how big their buffers are, and misstate them in > their EDNS0 buffer parameters. This causes EDNS0 to fail sometimes > even where it's available. Again, however, I think, this is stuff > that simply doesn't belong in the SPF document, because DNSOP is > already busy explaining (or has already explained) all of this in > various places. If we just need references, I'll dig them up (I guess > we probably do, so I suppose I just volunteered to do work). > > > It's most reliable to fit an > > answer into a UDP packet still seems to me to be good advice (and is > > consistent with RFC 4408). > > I am perfectly happy if the document says, "This will be most reliable > if all responses fit inside the traditional DNS UDP limit. Note that > DNSSEC may strain that limit anyway." More than that seems to me to > be borrowing trouble. I think the change I proposed earlier is in line with this (slightly modified here): > Note that when computing the sizes for queries of the TXT format, one has to > take into account the size of records returned with the any associated > query, including any other TXT records published at the domain name. The total discussion on record length would be: The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This UDP limit is defined in section 2.3.4. This will keep even older DNS implementations from falling over to TCP. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the combined length of the DNS name and the text of all the records of a given type is under 450 characters, then DNS answers ought to fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one has to take into account any other TXT records published at the domain name. Records that are too long to fit in a single UDP packet could be silently ignored by SPF verifiers due to firewall and other issues that cause DNS over TCP to be less reliable than DNS over UDP. Note that when computing the sizes for queries of the TXT format, one has to take into account the size of records returned with any associated query, including any other TXT records published at the domain name. This is very similar to what's in RFC 4408. We could also add something about DNSSEC here and the references you are going to dig up if you want. Scott K From ajs@anvilwalrusden.com Tue Jan 22 19:58:15 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3521F8800 for ; Tue, 22 Jan 2013 19:58:15 -0800 (PST) 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 B3KsRopSadkr for ; Tue, 22 Jan 2013 19:58:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BD7AF21F87FE for ; Tue, 22 Jan 2013 19:58:14 -0800 (PST) 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 A236C8A031 for ; Wed, 23 Jan 2013 03:58:13 +0000 (UTC) Date: Tue, 22 Jan 2013 22:58:05 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130123035805.GA57671@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <271785100.KEZggNLeh1@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 23 Jan 2013 03:58:15 -0000 No hat On Tue, Jan 22, 2013 at 10:22:35PM -0500, Scott Kitterman wrote: > I think the change I proposed earlier is in line with this (slightly modified > here): > the text of all the records of a given type is under 450 characters, Apart from saying "450 octets (practically speaking, ASCII characters)" here, I'm completely content with this. I don't think the additional references are needed. People operating DNS services need to pay attention to those other RFCs anyway, IMO, and the references will just be clutter. Emphatically, though, this is no hat: if people feel otherwise, I'd like them to provide text with the required references. (If people want me to dig them up, I will. But I'm not going to extra work when I don't think it needed.) A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Jan 22 21:31:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9A21F87FB for ; Tue, 22 Jan 2013 21:31:38 -0800 (PST) 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 afet6PqvSuQm for ; Tue, 22 Jan 2013 21:31:37 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97021F87E7 for ; Tue, 22 Jan 2013 21:31:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8044A20E40FC; Wed, 23 Jan 2013 00:31:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1358919096; bh=8NopeKI8H0NfDGhenaWIc27a7KreUm+XCmqqrCzpEgI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=APPh7CpZ4yEklw6sflKOJ2TU0ffwyOxXGQiMz1chfUtEtJN+EkF69+/sHA57IF/Gi IK3ZNeZr91WQLJayrrzNwa35HOur6137zomd95xwN2Jm45Ql8CcGzQDoHaWqwyPaOM Xsqf+gpPmymF/zLOxZYE4+YHniXxBNafMBTX7djQ= 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 64D7320E4085; Wed, 23 Jan 2013 00:31:35 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 23 Jan 2013 00:31:35 -0500 Message-ID: <5092413.XEdFPZFKNc@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130123035805.GA57671@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <271785100.KEZggNLeh1@scott-latitude-e6320> <20130123035805.GA57671@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #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, 23 Jan 2013 05:31:38 -0000 On Tuesday, January 22, 2013 10:58:05 PM Andrew Sullivan wrote: > No hat > > On Tue, Jan 22, 2013 at 10:22:35PM -0500, Scott Kitterman wrote: > > I think the change I proposed earlier is in line with this (slightly > > modified> > > here): > > the text of all the records of a given type is under 450 characters, > > Apart from saying "450 octets (practically speaking, ASCII > characters)" here, I'm completely content with this. I don't think > the additional references are needed. People operating DNS services > need to pay attention to those other RFCs anyway, IMO, and the > references will just be clutter. Emphatically, though, this is no > hat: if people feel otherwise, I'd like them to provide text with the > required references. (If people want me to dig them up, I will. But > I'm not going to extra work when I don't think it needed.) Thanks. I think that's enough. Scott K From vesely@tana.it Wed Jan 23 00:52:11 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7381F21F871F for ; Wed, 23 Jan 2013 00:52:11 -0800 (PST) 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_21=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 zEBlckbJw+TI for ; Wed, 23 Jan 2013 00:52:10 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9570721F86FB for ; Wed, 23 Jan 2013 00:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1358931127; bh=3YuJshUaRChHXPCihsCNm8ohLp9pQRJi4WIwMrF54xc=; l=2157; h=Date:From:To:References:In-Reply-To; b=ZVt/RzEn2rtVyuQrorYybyrk7HhT0XaZvV3lC7dVJZK8SvM9ctEcosFbJTK4LM4Zd Xq35mH7/BQTMVc3drb5e3I7oNZLh/K/b2ZbcouN5OOhwunE+fuiFzyxbAnTws2Yf84 Pf6X01fNePVLzb6d3WJjEim5fvRLgC5cjnevGnFQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Wed, 23 Jan 2013 09:52:07 +0100 id 00000000005DC039.0000000050FFA4B7.00000213 Message-ID: <50FFA4B7.5040104@tana.it> Date: Wed, 23 Jan 2013 09:52:07 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> In-Reply-To: <271785100.KEZggNLeh1@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, 23 Jan 2013 08:52:11 -0000 On Wed 23/Jan/2013 04:22:35 +0100 Scott Kitterman wrote: > > The total discussion on record length would be: > > The published SPF record for a given domain name SHOULD remain What does /SPF record/ mean there? Is that a TXT record beginning with "v=spf1" or any DNS record queried during an SPF evaluation? How about: For efficiency and security reasons, the DNS records that a domain publishes for SPF --that is, the policy record itself as well as any record it references even indirectly-- are subject to size restrictions. ? > small enough that the results of a query for it will fit within > 512 octets. This UDP limit is defined in It may make sense to relax that to 4096 or whatever number we deem to be safe nowadays, accepting Andrew's offer to dig up a suitable ref. (Doing so would enable publishers to replace IP4s with longer IP6s without increasing the total number of queries, for example.) > section 2.3.4. This will keep even older DNS implementations from > falling over to TCP. Since the answer size is dependent on many > things outside the scope of this document, it is only possible to > give this guideline: If the combined length of the DNS name and > the text of all the records of a given type is under 450 characters, > then DNS answers ought to fit in UDP packets. Note that when > computing the sizes for queries of the TXT format, one has to take > into account any other TXT records published at the domain name. I'd rephrase the latter sentence as: For TXT records in particular, especially the first one, one has to take into account the size of any other TXT records published at the same domain name. > Records that are too long to fit in a single UDP packet could be > silently ignored by SPF verifiers due to firewall and other issues > that cause DNS over TCP to be less reliable than DNS over UDP. Although that is a /could be/, not a MAY, would we consider an implementation to be conforming if it aborts SPF evaluation when it finds unreasonably long records? That's why I mentioned security in the proposed rewording above. From spf2@kitterman.com Wed Jan 23 20:57:33 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00321F8457 for ; Wed, 23 Jan 2013 20:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_21=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 iMuVXr0Z75UE for ; Wed, 23 Jan 2013 20:57:31 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3821F844C for ; Wed, 23 Jan 2013 20:57:31 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 302D320E40CE; Wed, 23 Jan 2013 23:57:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1359003450; bh=jk9CrcluWN3LxwYk5TGsPV2cfJCNpI6+kxZgHB6cjEk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mInCXcc32GQS4nOlZRu0Q9jSbhGk+pdq0e7uOrXSybFcO2aUkQc7AH6ngpnDAR/8f V9li2Vg9aLs5osvWKocVajbwuz+Ja/1fuQQxJrBW0GLBZMsPLcQdM75ywrd1OQq7SM ZpiG2+7aefs1U80lp61eoY7R7VoVGfKC1KhT4Nmg= 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 0F84020E40A6; Wed, 23 Jan 2013 23:57:29 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 23 Jan 2013 23:57:29 -0500 Message-ID: <2109811.ocLZA3PpHA@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <50FFA4B7.5040104@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <271785100.KEZggNLeh1@scott-latitude-e6320> <50FFA4B7.5040104@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] #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, 24 Jan 2013 04:57:33 -0000 On Wednesday, January 23, 2013 09:52:07 AM Alessandro Vesely wrote: > On Wed 23/Jan/2013 04:22:35 +0100 Scott Kitterman wrote: > > The total discussion on record length would be: > > The published SPF record for a given domain name SHOULD remain > > What does /SPF record/ mean there? Is that a TXT record beginning > with "v=spf1" or any DNS record queried during an SPF evaluation? > > How about: > > For efficiency and security reasons, the DNS records that a > domain publishes for SPF --that is, the policy record itself as > well as any record it references even indirectly-- are subject > to size restrictions. > ? I don't think this helps. This isn't a formal restriction, but an operational limitation that's inferred from the way DNS works (or not) today. There's no MUST about UDP packet size and I don't think there should (SHOULD) be. > > small enough that the results of a query for it will fit within > > 512 octets. This UDP limit is defined in > > It may make sense to relax that to 4096 or whatever number we deem to > be safe nowadays, accepting Andrew's offer to dig up a suitable ref. > (Doing so would enable publishers to replace IP4s with longer IP6s > without increasing the total number of queries, for example.) No. I think we decided it wasn't safe to do this yet. 512 octets is still demonstrably more reliable so we want it if we can get it. For a variety of reasons, this will probably change, but I don't think we can write the spec banking on the pace of that change. > > section 2.3.4. This will keep even older DNS implementations from > > falling over to TCP. Since the answer size is dependent on many > > things outside the scope of this document, it is only possible to > > give this guideline: If the combined length of the DNS name and > > the text of all the records of a given type is under 450 characters, > > then DNS answers ought to fit in UDP packets. Note that when > > computing the sizes for queries of the TXT format, one has to take > > into account any other TXT records published at the domain name. > > I'd rephrase the latter sentence as: > > For TXT records in particular, especially the first one, one has > to take into account the size of any other TXT records published > at the same domain name. First doesn't matter. TXT records are returned in an arbitrary sequence so first is a meaningless concept. > > Records that are too long to fit in a single UDP packet could be > > silently ignored by SPF verifiers due to firewall and other issues > > that cause DNS over TCP to be less reliable than DNS over UDP. > > Although that is a /could be/, not a MAY, would we consider an > implementation to be conforming if it aborts SPF evaluation when it > finds unreasonably long records? That's why I mentioned security in > the proposed rewording above. Record size is not, so far as I'm aware, a security issue. To the extent a potential DoS threat exists, it's based on numbers of queries generated. If you think we need to add a new security consideration for maximum record size, I'd like to see the threat analysis behind that recommendation. Scott K From superuser@gmail.com Fri Jan 25 01:10:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1731F21F86B1 for ; Fri, 25 Jan 2013 01:10:34 -0800 (PST) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 A1dHcEJXfjFh for ; Fri, 25 Jan 2013 01:10:33 -0800 (PST) Received: from mail-la0-x22d.google.com (la-in-x022d.1e100.net [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A45F721F865D for ; Fri, 25 Jan 2013 01:10:29 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id er20so17525lab.18 for ; Fri, 25 Jan 2013 01:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sHSFkjrR/3Vo8EWngpOC49ISW1MEfk2g4X/3/JxISrM=; b=Krxk4wJ+n+fOAdYH2uYaTFjBHjhOlTFvhtlDv3uh85z//53ZcXz1fpQunjymNv0VmA qu9A0/Zxf0H6ECE9WfN4yhtZvXJCpeoxuxicXKDCKQfTtUxuXX1siqNeRMEFOVLPrv27 c5jX6IiB0Md0VJLDC4UHot/5FGZ/XHCsX33fCVWhpt5FE9bOrxEmRQhztWpCxrf6ew6t WZve4MozHFhQLhVE1zE2+KVtmb33Ac4Vetd4YLFnbJQgZnrhjVBxf2/zvZeIeP5dKsNg TsDiOuEiQlBoiSEVo6LDFryfJinp39Q4St+UfGdXEts6meym8eBqZRXsFOXgffHrLA9j gTMg== MIME-Version: 1.0 X-Received: by 10.112.25.198 with SMTP id e6mr1943376lbg.63.1359105028160; Fri, 25 Jan 2013 01:10:28 -0800 (PST) Received: by 10.112.61.67 with HTTP; Fri, 25 Jan 2013 01:10:27 -0800 (PST) In-Reply-To: <50FFA4B7.5040104@tana.it> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> <50FFA4B7.5040104@tana.it> Date: Fri, 25 Jan 2013 01:10:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=bcaec553fe2c6a7f1504d4194cb9 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: Fri, 25 Jan 2013 09:10:34 -0000 --bcaec553fe2c6a7f1504d4194cb9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 23, 2013 at 12:52 AM, Alessandro Vesely wrote: > > The published SPF record for a given domain name SHOULD remain > > What does /SPF record/ mean there? Is that a TXT record beginning > with "v=spf1" or any DNS record queried during an SPF evaluation? > Why does it matter? Regardless of the RRTYPE used (though it's always TXT now in this document), the size caveat applies. But if you prefer to avoid confusion with the deprecated SPF RRTYPE, we could change "SPF record" to "SPF policy". > > How about: > > For efficiency and security reasons, the DNS records that a > domain publishes for SPF --that is, the policy record itself as > well as any record it references even indirectly-- are subject > to size restrictions. > ? > I don't think this adds any clarity, and as Andrew mentioned it gets into DNS esoterica that probably don't belong here. I believe we already refer normatively to RFC1035; we don't need to restate much of what it and its later friends said. > > > small enough that the results of a query for it will fit within > > 512 octets. This UDP limit is defined in > > It may make sense to relax that to 4096 or whatever number we deem to > be safe nowadays, accepting Andrew's offer to dig up a suitable ref. > (Doing so would enable publishers to replace IP4s with longer IP6s > without increasing the total number of queries, for example.) > If we say 4096, we also have to talk about EDNS0, because RFC1035 says 512. I don't want to drag in a ton of DNSOP WG references if we can avoid it. Just to clarify here: Is the security reason alluded to the fact that SPF can't be evaluated if TCP fallback occurs, or is there some other threat? In any case, maybe it's safer to drop the specific 512 reference, and just talk more generally about avoiding truncation that would force fallback to TCP, which may not be possible. If people are worried about that, they can read up on it in RFC1035. (We could include a reference to that section.) > section 2.3.4. This will keep even older DNS implementations from > > falling over to TCP. Since the answer size is dependent on many > > things outside the scope of this document, it is only possible to > > give this guideline: If the combined length of the DNS name and > > the text of all the records of a given type is under 450 characters, > > then DNS answers ought to fit in UDP packets. Note that when > > computing the sizes for queries of the TXT format, one has to take > > into account any other TXT records published at the domain name. > > To be precise, even if the combined length is over 450 characters, you're still inside a UDP packet easily. It's the RFC1035 limit you hit, which is way smaller than the UDP limit. > I'd rephrase the latter sentence as: > > For TXT records in particular, especially the first one, one has > to take into account the size of any other TXT records published > at the same domain name. > Given that they can be returned in arbitrary order, I think this only complicates the matter for the reader. > > > Records that are too long to fit in a single UDP packet could be > > silently ignored by SPF verifiers due to firewall and other issues > > that cause DNS over TCP to be less reliable than DNS over UDP. > > Although that is a /could be/, not a MAY, would we consider an > implementation to be conforming if it aborts SPF evaluation when it > finds unreasonably long records? That's why I mentioned security in > the proposed rewording above. > We'd need to define "unreasonably long". I'm not sure "silently ignored" is right. Why would an SPF verifier silently ignore a reply that comes back with the truncation bit on, for example? As I understand it, you always get the count of available answers, and then as many of the matching RRs that fit in the reply. So if there are two or more answers, the one starting "v=spf1" might not be included in the set, but if it is, you're guaranteed that it's all there. But all of that is detail about "avoid truncation" that we don't really need to provide, IMHO. -MSK --bcaec553fe2c6a7f1504d4194cb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 23, 2013 at 12:52 AM, Alessandro Vesely <vesely@= tana.it> wrote:
> =A0 =A0The published = SPF record for a given domain name SHOULD remain

What does /SPF record/ mean there? =A0Is that a TXT record beginning<= br> with "v=3Dspf1" or any DNS record queried during an SPF evaluatio= n?

Why does it matter?=A0 Regardless of= the RRTYPE used (though it's always TXT now in this document), the siz= e caveat applies.=A0 But if you prefer to avoid confusion with the deprecat= ed SPF RRTYPE, we could change "SPF record" to "SPF policy&q= uot;.
=A0

How about:

=A0 =A0 =A0For efficiency and security reasons, the DNS records that a
=A0 =A0 =A0domain publishes for SPF =A0--that is, the policy record itself = as
=A0 =A0 =A0well as any record it references even indirectly-- are subject =A0 =A0 =A0to size restrictions.
?

I don't t= hink this adds any clarity, and as Andrew mentioned it gets into DNS esoter= ica that probably don't belong here.=A0 I believe we already refer norm= atively to RFC1035; we don't need to restate much of what it and its la= ter friends said.

=A0

> =A0 =A0small enough that the results of a query for it will fit within=
> =A0 =A0512 octets. =A0This UDP limit is defined in <xref target=3D&= quot;RFC1035"/>

It may make sense to relax that to 4096 or whatever number we deem to=
be safe nowadays, accepting Andrew's offer to dig up a suitable ref. (Doing so would enable publishers to replace IP4s with longer IP6s
without increasing the total number of queries, for example.)

If we say 4096, we also have to talk about EDNS0, because= RFC1035 says 512.=A0 I don't want to drag in a ton of DNSOP WG referen= ces if we can avoid it.

Just to clarify here: Is the security = reason alluded to the fact that SPF can't be evaluated if TCP fallback = occurs, or is there some other threat?

In any case, maybe it's safer to d= rop the specific 512 reference, and just talk more generally about avoiding= truncation that would force fallback to TCP, which may not be possible.=A0= If people are worried about that, they can read up on it in RFC1035.=A0 (W= e could include a reference to that section.)

> =A0 =A0section 2.3.4. =A0This will keep even older DNS implementations= from
> =A0 =A0falling over to TCP. =A0Since the answer size is dependent on m= any
> =A0 =A0things outside the scope of this document, it is only possible = to
> =A0 =A0give this guideline: If the combined length of the DNS name and=
> =A0 =A0the text of all the records of a given type is under 450 charac= ters,
> =A0 =A0then DNS answers ought to fit in UDP packets. =A0Note that when=
> =A0 =A0computing the sizes for queries of the TXT format, one has to t= ake
> =A0 =A0into account any other TXT records published at the domain name= .


To be precise, even if the combi= ned length is over 450 characters, you're still inside a UDP packet eas= ily.=A0 It's the RFC1035 limit you hit, which is way smaller than the U= DP limit.
=A0
I'd rephrase the latter sentence as:

=A0 =A0 =A0For TXT records in particular, especially the first one, one has=
=A0 =A0 =A0to take into account the size of any other TXT records published=
=A0 =A0 =A0at the same domain name.

Giv= en that they can be returned in arbitrary order, I think this only complica= tes the matter for the reader.
=A0

> =A0 =A0Records that are too long to fit in a single UDP packet could b= e
> =A0 =A0silently ignored by SPF verifiers due to firewall and other iss= ues
> =A0 =A0that cause DNS over TCP to be less reliable than DNS over UDP.<= br>
Although that is =A0a /could be/, not a MAY, would we consider an
implementation to be conforming if it aborts SPF evaluation when it
finds unreasonably long records? =A0That's why I mentioned security in<= br> the proposed rewording above.

We'd = need to define "unreasonably long".

I'm not= sure "silently ignored" is right.=A0 Why would an SPF verifier s= ilently ignore a reply that comes back with the truncation bit on, for exam= ple?=A0 As I understand it, you always get the count of available answers, = and then as many of the matching RRs that fit in the reply.=A0 So if there = are two or more answers, the one starting "v=3Dspf1" might not be= included in the set, but if it is, you're guaranteed that it's all= there.

But all of that is detail about "avoid truncation"= that we don't really need to provide, IMHO.

-MSK
=

--bcaec553fe2c6a7f1504d4194cb9-- From vesely@tana.it Fri Jan 25 02:57:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2A621F8759 for ; Fri, 25 Jan 2013 02:57:52 -0800 (PST) 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 ekve5JnKTs5U for ; Fri, 25 Jan 2013 02:57:51 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 42CBF21F85CC for ; Fri, 25 Jan 2013 02:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1359111469; bh=yg8fzl/AU1GpQo/LER5HzCPTcygFLehMYB7+PL9BWTg=; l=2277; h=Date:From:To:References:In-Reply-To; b=GE0J6AF3zWNy/drb7v3Y/J0N6p+FTP5BzOUt6sE0cDrCMUc1X7lHLQRYwzybXiWf4 dyrJTUoDWrDvgZ9mt6Fi/l7I1U23Kn5NK2eS9bgn1jpuo/yKogcblkeztCYHKWqt9H g6lXKv70DGNfqvGhZ6l/O7xVs0FI4fozxnkfWlJ4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 25 Jan 2013 11:57:49 +0100 id 00000000005DC039.000000005102652D.0000470B Message-ID: <5102652D.8000204@tana.it> Date: Fri, 25 Jan 2013 11:57:49 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> <50FFA4B7.5040104@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Fri, 25 Jan 2013 10:57:52 -0000 On Fri 25/Jan/2013 10:10:27 +0100 Murray S. Kucherawy wrote: > On Wed, Jan 23, 2013 at 12:52 AM, Alessandro Vesely > wrote: > >> The published SPF record for a given domain name SHOULD remain >> >> What does /SPF record/ mean there? Is that a TXT record beginning >> with "v=spf1" or any DNS record queried during an SPF evaluation? > > Why does it matter? Regardless of the RRTYPE used (though it's always > TXT now in this document), the size caveat applies. But if you prefer > to avoid confusion with the deprecated SPF RRTYPE, we could change > "SPF record" to "SPF policy". No, I meant including other record types, such as type-A, that can be triggered by an "a:" mechanism. There is lots of hype, on lists such as spf-help, on the size of type-TXT (or type-SPF), while the size of the other record types is never mentioned. I just wandered if that's an unintentional omission. > Just to clarify here: Is the security reason alluded to the fact that > SPF can't be evaluated if TCP fallback occurs, or is there some other > threat? The threat is only theoretical. I don't know of any good reason why one might want to set up a terabyte type-A record, assuming that is even possible. However, my ignorance is not a valid rationale to exclude that such beasts exist. Nor spfbis is the place to make such statement. Hence, an apparently innocent SPF record could theoretically reference a number (10) of third parties oversize records, and thus lend itself to DoS attacks. The question is, why does the spec put a SHOULD on the size of the "SPF record" only? > In any case, maybe it's safer to drop the specific 512 reference, and > just talk more generally about avoiding truncation that would force > fallback to TCP, which may not be possible. If people are worried > about that, they can read up on it in RFC1035. I agree. The protocol is right to recommend efficiency. Handy advice is welcome, but advice that is likely to become obsolete before the spec will be revised should be avoided. Testing the record seems to be necessary anyway. Since it is also sufficient, there is no reason to say more. We need to specify what tests a good test site should carry out, though. From ajs@anvilwalrusden.com Fri Jan 25 06:36:09 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D021F8464 for ; Fri, 25 Jan 2013 06:36:09 -0800 (PST) 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 WmMh5N34wC3z for ; Fri, 25 Jan 2013 06:36:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5D96621F8445 for ; Fri, 25 Jan 2013 06:36:08 -0800 (PST) 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 DC30F8A031 for ; Fri, 25 Jan 2013 14:36:06 +0000 (UTC) Date: Fri, 25 Jan 2013 09:36:04 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130125143603.GA11573@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> <50FFA4B7.5040104@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #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: Fri, 25 Jan 2013 14:36:10 -0000 No hat. On Fri, Jan 25, 2013 at 01:10:27AM -0800, Murray S. Kucherawy wrote: > > If we say 4096, we also have to talk about EDNS0, because RFC1035 says > 512. I don't want to drag in a ton of DNSOP WG references if we can avoid > it. > > Just to clarify here: Is the security reason alluded to the fact that SPF > can't be evaluated if TCP fallback occurs, or is there some other threat? > > In any case, maybe it's safer to drop the specific 512 reference, and just > talk more generally about avoiding truncation that would force fallback to > TCP, which may not be possible. If people are worried about that, they can > read up on it in RFC1035. (We could include a reference to that section.) Well, 4096 is as a practical matter impossible on the Internet anyway, but you might be ok somewhere in the 1500 range. But EDNS0 isn't a DNSOP reference, it's part of the DNS protocol (indeed, the IESG just approved it as Internet Standard). We probably need a reference anyway to that, but I don't think we should have a lot of guidance about how to operate the zone in here. > > For TXT records in particular, especially the first one, one has > > to take into account the size of any other TXT records published > > at the same domain name. > > > > Given that they can be returned in arbitrary order, I think this only > complicates the matter for the reader. Inded. In the DNS, there is no "first one". > I'm not sure "silently ignored" is right. Why would an SPF verifier > silently ignore a reply that comes back with the truncation bit on, for > example? Indeed, if it conforms even remotely to how DNS is supposed to work, it ought to reissue the query using TCP. I really strongly do not think this document is a good place to try to educate people about how to operate the DNS, particularly since SPF is one of the poster children for DNS abuse in the DNS community. If we want to have a big messy fight during IETF LC, then we can lard this draft with a lot of DNS advice. Otherwise, let's not. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Jan 25 06:49:06 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85D21F85EA for ; Fri, 25 Jan 2013 06:49:06 -0800 (PST) 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 hf7HSoFaOyCz for ; Fri, 25 Jan 2013 06:49:06 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id F02D921F8587 for ; Fri, 25 Jan 2013 06:49:05 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 5DE0AD04066; Fri, 25 Jan 2013 08:49:04 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1359125344; bh=OJs2voMCA5XL8TCkpQLbN9sknnONsKgoMvptQC1/Pu0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=CNtmd/vXAtJh7kRyEQQyj8ZqwjZ5UsNa2668nRISAy4u/t+2t28q2yH6ubW3e8nen BAjsMX2ECaXlpFZchHNN//GnSGcAR8YnWAe1oMn3Y5mcCsOk2sIp5gJOwoE6KvXdWt EHXkS9z8maG5ymMfqzh+qNUTtp6aQqmcLcxnmGnc= Received: from [IPV6:2600:1003:b006:9fa4:b5ec:d020:a073:54b7] (unknown [IPv6:2600:1003:b006:9fa4:b5ec:d020:a073:54b7]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 91639D04056; Fri, 25 Jan 2013 08:49:03 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <20130125143603.GA11573@mx1.yitter.info> References: <061.d98693d6d49da2032936529b51acdb1f@tools.ietf.org> <3896517.k8tBVMT4Fi@scott-latitude-e6320> <20130123010120.GC7073@crankycanuck.ca> <271785100.KEZggNLeh1@scott-latitude-e6320> <50FFA4B7.5040104@tana.it> <20130125143603.GA11573@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 25 Jan 2013 09:48:59 -0500 To: spfbis@ietf.org Message-ID: <7ab574aa-d13c-44e2-968e-4946bd05808c@email.android.com> 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: Fri, 25 Jan 2013 14:49:06 -0000 Andrew Sullivan wrote: >No hat. > >On Fri, Jan 25, 2013 at 01:10:27AM -0800, Murray S. Kucherawy wrote: >> >> If we say 4096, we also have to talk about EDNS0, because RFC1035 >says >> 512. I don't want to drag in a ton of DNSOP WG references if we can >avoid >> it. >> >> Just to clarify here: Is the security reason alluded to the fact that >SPF >> can't be evaluated if TCP fallback occurs, or is there some other >threat? >> >> In any case, maybe it's safer to drop the specific 512 reference, and >just >> talk more generally about avoiding truncation that would force >fallback to >> TCP, which may not be possible. If people are worried about that, >they can >> read up on it in RFC1035. (We could include a reference to that >section.) > >Well, 4096 is as a practical matter impossible on the Internet anyway, >but you might be ok somewhere in the 1500 range. But EDNS0 isn't a >DNSOP reference, it's part of the DNS protocol (indeed, the IESG just >approved it as Internet Standard). We probably need a reference >anyway to that, but I don't think we should have a lot of guidance >about how to operate the zone in here. I think 4408 got the amount of advice pretty much right. We might improve the wording a bit, but we should not jump in and be more expansive. >> > For TXT records in particular, especially the first one, one >has >> > to take into account the size of any other TXT records >published >> > at the same domain name. >> > >> >> Given that they can be returned in arbitrary order, I think this only >> complicates the matter for the reader. > >Inded. In the DNS, there is no "first one". > >> I'm not sure "silently ignored" is right. Why would an SPF verifier >> silently ignore a reply that comes back with the truncation bit on, >for >> example? > >Indeed, if it conforms even remotely to how DNS is supposed to work, >it ought to reissue the query using TCP. > >I really strongly do not think this document is a good place to try to >educate people about how to operate the DNS, particularly since SPF >is one of the poster children for DNS abuse in the DNS community. If >we want to have a big messy fight during IETF LC, then we can lard >this draft with a lot of DNS advice. Otherwise, let's not. > Agreed. Scott K From johnl@iecc.com Fri Jan 25 07:04:00 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BB21F87AD for ; Fri, 25 Jan 2013 07:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.596 X-Spam-Level: X-Spam-Status: No, score=-110.596 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG8FRqsrvkI4 for ; Fri, 25 Jan 2013 07:04:00 -0800 (PST) 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 AA2F821F842E for ; Fri, 25 Jan 2013 07:03:59 -0800 (PST) Received: (qmail 97359 invoked from network); 25 Jan 2013 15:03:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jan 2013 15:03: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=51029ede.xn--i8sz2z.k1301; i=johnl@user.iecc.com; bh=42Qp3Ko1nNfLZQqKNBESyGuMuXhgHb+w6m0qZKc2fPk=; b=aI+Hms4lob5uvJshRdYrlX+Vb1nvqOk9bet9jVV11a28nvM5UMybpJGrvy/dLAr0LcM0lqGyxoLqfNclMZ/TH/B5ez3MX0XQbRoyFZZxrX1dq1nw5dfJVVq6ujFJpEIU4RaOJr9c6c8yjoT3sP/bx4DL917UjnTLjGt/Itx/38g= 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=51029ede.xn--i8sz2z.k1301; olt=johnl@user.iecc.com; bh=42Qp3Ko1nNfLZQqKNBESyGuMuXhgHb+w6m0qZKc2fPk=; b=WQv/LbIVlwpMnFdg01vLT4Hm3rVWz4z8eiz9miQNhRtaEoeSIeJMjRnpdAf94/sU4H4mGEvikz0obmuti771Ep46216qf+vb3GvOaqUUeQrPTAuk+bhmLSyOpHrsWWLpEOYEz8Wiioh7bxxjjUr3RiQ1ish2vD8P8+kwIZhh6Mw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Jan 2013 15:03:36 -0000 Message-ID: <20130125150336.70908.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130125143603.GA11573@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] #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: Fri, 25 Jan 2013 15:04:00 -0000 >I really strongly do not think this document is a good place to try to >educate people about how to operate the DNS, particularly since SPF >is one of the poster children for DNS abuse in the DNS community. If >we want to have a big messy fight during IETF LC, then we can lard >this draft with a lot of DNS advice. Otherwise, let's not. Absolutely. SPF documents chronically suffer from gratuitous advice about stuff unrelated to the SPF protocol, from how to run a mail server to how to run DNS and more, all which might be described as somewhat above our pay grade. We need to tell people how to publish SPF records, and how to retrieve them and interpret them the context of a domain name and IP address. Then we need to stop. R's, John From dotzero@gmail.com Fri Jan 25 07:30:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0221F88BE for ; Fri, 25 Jan 2013 07:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV0L7nms6Sgi for ; Fri, 25 Jan 2013 07:30:46 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5221F8896 for ; Fri, 25 Jan 2013 07:30:46 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so935333lbb.13 for ; Fri, 25 Jan 2013 07:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p0BIoXiTVEz3ahBFTYiVmOfiHiNPefiSPXgVKOyVDKw=; b=VTeICWfLsnj/ZGYXmhuzMTrRE1mal1EFhnWDPtT3ju8X6rjjjuZZwm4Ynyy+axup4e mLrnUVwxuB920mKwzWO4ns5e25V7w/Rcj8KdJow1BnC7nyufCadA70yKysXWShLkQ3Ib ARmgIeKaV48/2jgicHfU6dJaT5OnRgQOJDsypbpEbo38OzgBqv8dQfVXq4Gv9s3JFp3X YOsZ9eaObIcPF3L+HpwRvpGJP27y1Fh86GekS3y5ddP8AreUlyeYT7Qtp3uQJgunCQZO p6paNALS1qSc3z4p9uqgtu70KKD/tR4es730XS5OG+VpaXgdEGBbd9ZSYTRcx7WfHHjC K45Q== MIME-Version: 1.0 X-Received: by 10.152.147.103 with SMTP id tj7mr5524163lab.54.1359127845141; Fri, 25 Jan 2013 07:30:45 -0800 (PST) Received: by 10.112.49.101 with HTTP; Fri, 25 Jan 2013 07:30:44 -0800 (PST) In-Reply-To: <20130125150336.70908.qmail@joyce.lan> References: <20130125143603.GA11573@mx1.yitter.info> <20130125150336.70908.qmail@joyce.lan> Date: Fri, 25 Jan 2013 10:30:44 -0500 Message-ID: From: Dotzero To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, ajs@anvilwalrusden.com 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: Fri, 25 Jan 2013 15:30:47 -0000 +1 On Fri, Jan 25, 2013 at 10:03 AM, John Levine wrote: >>I really strongly do not think this document is a good place to try to >>educate people about how to operate the DNS, particularly since SPF >>is one of the poster children for DNS abuse in the DNS community. If >>we want to have a big messy fight during IETF LC, then we can lard >>this draft with a lot of DNS advice. Otherwise, let's not. > > Absolutely. SPF documents chronically suffer from gratuitous advice > about stuff unrelated to the SPF protocol, from how to run a mail > server to how to run DNS and more, all which might be described > as somewhat above our pay grade. > > We need to tell people how to publish SPF records, and how to retrieve > them and interpret them the context of a domain name and IP address. > Then we need to stop. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From sm@elandsys.com Thu Jan 31 06:03:40 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A382E21F881C for ; Thu, 31 Jan 2013 06:03:39 -0800 (PST) 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 NIHIV6teq4dz for ; Thu, 31 Jan 2013 06:03:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C882821F8999 for ; Thu, 31 Jan 2013 06:03:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.158.80]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0VE3PaZ007953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 06:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359641016; bh=kbxq/fbDeb/yI9vQh/tMgjtZKXfV+NoOs42OSguOiVg=; h=Date:To:From:Subject:In-Reply-To:References; b=BtoTy3mYa6AnlhfHCyDkBXuV6387O7W5ks6jEGImw3s6hYg7/GN5U/3i6sdccd9Sr Ix0xxxEpmzLmLWftLBqPnBdI5tDLQiYiwcAaLekFRVkynRyPjSf5Pd7d6W4DE2wyH/ GMNsJ++urTz7PkIy7aNHZU7p1I54NpaYEDyjuf2o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359641016; i=@elandsys.com; bh=kbxq/fbDeb/yI9vQh/tMgjtZKXfV+NoOs42OSguOiVg=; h=Date:To:From:Subject:In-Reply-To:References; b=f3aq2i/SLRC0WBKU6vzwymeX8/MjauPJw99AsP0V2i2TqRdbv4ES1WY6k7zsT57qz xW5EMF66exErEeBSzFZOrJfHIixmZndr9ykL//l0g3Xg8ekeoqMMaivRdEZ0rDYJU3 UNIV/JL40S6MPjKXAy098ULpQaoauTtpZuek059I= Message-Id: <6.2.5.6.2.20130131054312.0a3241d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 05:47:00 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20130125143603.GA11573@mx1.yitter.info> <20130125150336.70908.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 31 Jan 2013 14:03:40 -0000 Hi Scott, There had been some discussion about Issue #24 over the last week. The issue is listed as open in the tracker [1]. Is the issue resolved? Regards, S. Moonesamy 1. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 From sm@elandsys.com Thu Jan 31 06:03:41 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A7E21F8767 for ; Thu, 31 Jan 2013 06:03:41 -0800 (PST) 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 3BFPPUkNBEUt for ; Thu, 31 Jan 2013 06:03:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896D721F87CE for ; Thu, 31 Jan 2013 06:03:40 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.158.80]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0VE3Pab007953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 06:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359641019; bh=vyvmFQ4KrhN8XpIVbjn3XS49fZUBYYzJjQkSbVlSxpE=; h=Date:To:From:Subject; b=oGK6lYv0WDsr+DBNYu0CwK0dg6u7hBxCQfaI06jAOfzIGvczc3Nf7kkUGZlyl0dAL CV0A5O4ln7jSroxfpxQQUGOWPjblzOtI//IB0giyGmBi+pavQ3nt1QRGVU8ZoBTvaf pz5AwZmOthzb6OQ9zXdm3Jc0gHbsp/L9+do+pZrQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359641019; i=@elandsys.com; bh=vyvmFQ4KrhN8XpIVbjn3XS49fZUBYYzJjQkSbVlSxpE=; h=Date:To:From:Subject; b=aJ0LMJIYGvsl6tM0jUt3KNkb6nrfvJ0skpHM2PoEUg+FnH6UDcbM8uperO3kPr0T+ gqbSbxRZwJg58JchPiMnTXg1rbcZqLGUqdxw1teUAOBroUp77gMeHX6HvS07if/My8 JuFEPUCAV7dEbPtMp80GurLcvaVr15CR1wJq8ljk= Message-Id: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 06:02:53 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:03:41 -0000 Hello, According to the SPFBIS WG Charter the working group was scheduled to submit draft-ietf-spfbis-4408bis for publication in December 2012. Here is the list of open issues [1]: #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion #24 RFC 4408: Reasonable DNS error limits #29 RFC 4408: Section 2.5.4 - mark on fail #34 Throw a temperror - Section 5.2 #35 authorized_spf domain name - Section 9.1.1 #36 RFC 2119 key words #37 spf classic #38 Deprecated #39 Temporary errors implied as only caused by DNS errors #40 Wildcard records #41 Multiple DNS errors #42 Record Evaluation #43 New requirement for mx: or ptr records #44 Section 5.4 does not mention requirement in section 4.6.4 #45 Section 5.5 steps #46 DNS reply in Section 5.7 #47 domain-spec #48 Section 8.1 - macro defs #49 IANA registry for SPF modifiers #50 Terminology #51 Remove A-R from 4408bis #52 Section 8.1 *Macro Definitions #53 Possible ABNF nit with Received-SPF #54 Section 9.2.1 of 4408bis #55 Section 9.2.2 Forwarding Services and Aliases #56 Section 9.2.2 Forwarding Services and Aliases #57 x-* fields in 4408bis #58 Local policy in 4408bis #59 Remove section 9.1.1 DNS Resource Considerations #6 RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization #33 Marked Failed Mail Exposure Regards, S. Moonesamy 1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1 From spf2@kitterman.com Thu Jan 31 06:22:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBF21F8794 for ; Thu, 31 Jan 2013 06:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 ktLg4dtWAW3Y for ; Thu, 31 Jan 2013 06:22:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F59D21F86F4 for ; Thu, 31 Jan 2013 06:22:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2086920E40CE; Thu, 31 Jan 2013 09:22:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1359642174; bh=elmWfwK23iOtusmxxsy+or8nU1KwHRruypTbJjvywco=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BzZ5zUlAHXH0WAxpB12C2PA5EKC5GFlNbpnmH3tAu9raHc+C3cNpCZRSy0O1nmI9d DhT6wKbkB6KxSvqhfCBCWWGOUJYbAMC6EPWKUCCoFuxaTSgbpcjLL1JiiUYQIFfh6X cLfV4edXvvvMV0vsVg/0Rga4Vtfx/QKorj+ziPto= 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 036F720E4085; Thu, 31 Jan 2013 09:22:53 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 31 Jan 2013 09:22:49 -0500 Message-ID: <1397680.5mhf1dVE2p@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-22-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131054312.0a3241d8@resistor.net> References: <20130125143603.GA11573@mx1.yitter.info> <6.2.5.6.2.20130131054312.0a3241d8@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: Thu, 31 Jan 2013 14:22:56 -0000 On Thursday, January 31, 2013 05:47:00 AM S Moonesamy wrote: > Hi Scott, > > There had been some discussion about Issue #24 over the last > week. The issue is listed as open in the tracker [1]. Is the issue > resolved? I think it will be resolved with the next revision. I think we've discussed it sufficiently. Next week looks to be good for me to take a stab at making progress on the remaining issues. Scott K From sm@elandsys.com Thu Jan 31 08:55:48 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FBD21F8563 for ; Thu, 31 Jan 2013 08:55:47 -0800 (PST) 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 bjhLYrsG3L-D for ; Thu, 31 Jan 2013 08:55:47 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A899821F855D for ; Thu, 31 Jan 2013 08:55:46 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.135.114]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0VGtYVx007136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 08:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359651345; bh=1EJUAPCzqpgzeSJjQglkS68Oq7JbGOS4ksHDBcBiufc=; h=Date:To:From:Subject:In-Reply-To:References; b=rV+FRrbPJPqn8yJvXGRk4jEdl6jbs1Guhhu49FLEpsKO+/AV3SmqpqBxffSXNjCbI KTqLBrI1jo5wMmkBM3jco9q+P+ETLlqU+vQGpwggUmEWG08k8gEVuw1BAT2+ejpFO/ zriemQ7XiNX9CQs7GYs+R6/eqmyvNZZH95uC4RnU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359651345; i=@elandsys.com; bh=1EJUAPCzqpgzeSJjQglkS68Oq7JbGOS4ksHDBcBiufc=; h=Date:To:From:Subject:In-Reply-To:References; b=Uz/DzdB5OJ/Dc2LRGm4b/FLcIzmzmESojf0MlvZ9gds0lh2KqZvM23CWi1hs/PU4H QYMW65IfLAN0O3hvkh1lNMFamrXYF4dN2IY2YwtNF/f0NvMefY7fB7ZsGrkErjN+MV yAnOjp+0lZU+Hv4YfE4e5LI2M4Ez+ok5hhrJnsFU= Message-Id: <6.2.5.6.2.20130131065211.0a323f48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 06:53:55 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1397680.5mhf1dVE2p@scott-latitude-e6320> References: <20130125143603.GA11573@mx1.yitter.info> <6.2.5.6.2.20130131054312.0a3241d8@resistor.net> <1397680.5mhf1dVE2p@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 31 Jan 2013 16:55:48 -0000 Hi Scott, At 06:22 31-01-2013, Scott Kitterman wrote: >I think it will be resolved with the next revision. I think we've discussed >it sufficiently. Next week looks to be good for me to take a stab at making >progress on the remaining issues. Thanks for the feedback. Regards, S. Moonesamy