From nobody Tue Feb 9 15:32:12 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C41B2A6F for ; Tue, 9 Feb 2016 13:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8GmDqZ6ZGr6 for ; Tue, 9 Feb 2016 13:44:05 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A471B2A4F for ; Tue, 9 Feb 2016 13:44:05 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id f81so1973858iof.0 for ; Tue, 09 Feb 2016 13:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jHVrKMK0HkHRtWfYzwR0zfgNRb/ql9McdkEvRpdBG78=; b=DT5YrY+MhWwWBZyboyGpnmjrLHWck6MXN6w6MNsNjFcQcIJOldhEb7Og8tXYjIrGZj 5lXIeR89lWbmVTYUiPZwNW0+g0xwk8rWKtsan2vtvHBXjNFB3a6X96q//TTOMuaEdlDu DJUCrP6iOz4ckpzWyBeJSmU9jdqQCEVZLZ+h294tzyTnHqLN51uT49GVnqm6D9gE42C4 MUQGsmTVUMQvi7ZgsTGlTxROt75PbfB4TXQjw3K8eIbe7jQZNNySWguNd5cXF7pZc9h+ FMH1y+3Dm+eNgerTOpiRNTt8O/bKD7+g2kFDhuSizfxTOmMvRuHkmqBXPI7Zi+ZyMZv7 /NUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jHVrKMK0HkHRtWfYzwR0zfgNRb/ql9McdkEvRpdBG78=; b=lpuzaWa6PpTDeg5UXdHia51ZY9RU/ARO3m8trviV56jCgv6mU0yfmjRiID8Aj5/lPm N3KNjbTK7Nn7hJ+dppnO1sABbK6K496j+lbyKJzBx5g+I1c6PR+KncDhusSed0nPVYAg zVLIiQC+2+WA6Go+oEqEJfDaOCXK4M1Lk7vvsCB9huVRS7UW7XJ3Ge4x5csKQRorfhQp tVmh4gEFa3O9OPE/aA5tcrI3LJF+LH8WRwXPQNHEnI02zHFgA2C8tDEh8OYbvjC5GFbs xfeAxguAwUcs2LVs2JO9Z4IkkuUd1vQxBpbaBUNUmXW6E/4l9eGheryb+99Ow2PEA1lI Rq5A== X-Gm-Message-State: AG10YOStPxdsdomUEPARaH/Ow/4xTCwc4tEstWmRsnnkbKnlGYOEHCw9ZesTg3zs8s7OnPV+YdRPdIfZ/dBvUa3M MIME-Version: 1.0 X-Received: by 10.107.153.11 with SMTP id b11mr2784008ioe.113.1455054244368; Tue, 09 Feb 2016 13:44:04 -0800 (PST) Received: by 10.64.62.194 with HTTP; Tue, 9 Feb 2016 13:44:04 -0800 (PST) Date: Tue, 9 Feb 2016 13:44:04 -0800 Message-ID: From: Brandon Long To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=001a1140faa25dcbcb052b5d37d9 Archived-At: X-Mailman-Approved-At: Tue, 09 Feb 2016 15:32:11 -0800 Subject: [spfbis] auth-results and spf X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 21:44:06 -0000 --001a1140faa25dcbcb052b5d37d9 Content-Type: text/plain; charset=UTF-8 Not sure the best list to send this to... but anyone know why the IP isn't a formal field in the spf method for the Authentication-Results header (RFC 7601)? For "iprev", there is policy.iprev, but there isn't one for spf. We put it in the comment now, but it would seem like an obvious requirement for what was evaluated. Brandon --001a1140faa25dcbcb052b5d37d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not sure the best list to send this to... but anyone know = why the IP isn't a formal field in the spf method for the Authenticatio= n-Results header (RFC 7601)?

For "iprev", ther= e is policy.iprev, but there isn't one for spf.=C2=A0 We put it in the = comment now, but it would seem like an obvious requirement for what was eva= luated.

Brandon
--001a1140faa25dcbcb052b5d37d9-- From nobody Tue Feb 9 16:10:15 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE621B3258 for ; Tue, 9 Feb 2016 16:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FAxRjninyUI for ; Tue, 9 Feb 2016 16:10:11 -0800 (PST) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AEA1B325C for ; Tue, 9 Feb 2016 16:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1455063011; bh=ra1nn0lLPKdrYIAXBkXu6fKg7jeDirvE0+BhXhPJYOk=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=LP1Cq08mYBuk+WeikIYnkA/cqzOq82sjGwk+SS9n9AkvN5NP51CwHkWVQp/uE5tWE L4WEYDC7OczUXk012QDuBDGpf0JikyT2dOJjmvT2kYu6mnSHgap8M8q7fjyCria/18 qwBP7QUz0Nuve4RbBe2nRgDKm8+2Owe5NwszkV/s= Authentication-Results: mail522.prod x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="74.125.82.46"; spf=softfail smtp.mailfrom="fmartin@linkedin.com" smtp.helo="mail-wm0-f46.google.com"; dkim=none (message not signed) header.d=none; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [74.125.82.46] ([74.125.82.46:38336] helo=mail-wm0-f46.google.com) by mail522.prod (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 89/CA-30456-2EF7AB65; Wed, 10 Feb 2016 00:10:11 +0000 Received: by mail-wm0-f46.google.com with SMTP id p63so5596538wmp.1 for ; Tue, 09 Feb 2016 16:10:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ra1nn0lLPKdrYIAXBkXu6fKg7jeDirvE0+BhXhPJYOk=; b=Pp89Fcihkq1/Tv4qyqAxFi7SdU37MTr2WXXISgNVSJk28To7tafMxlEvQThzIulQwQ o2vEsJdAvlAjElmKyyFcpH4smZ3ltrSSQF4Ja2U+cT6kUUQCv7PAl/S6RtOZ+7h7hvOT V44qyFp/DQXVfRCjTpiESP0tVM59Fuav6QG9N6mY/23y6mP4OHrYIstamowLughGrLzo L/FmmbRgC9ycp+4yISUjq6e1YFTEuxUPqGQWEckZ+uSODIpiJcMxQn9CI8r2Ct4bhoRX mbNXQRoU23cCKChm12xMzzwv/txTkzGww+EHcXSQ9iLebjBklhtsc6DOCcz4SA1EeBb+ x76A== X-Gm-Message-State: AG10YOSYgDdrmybcfLHxvMtZqJbZ6paMmGb24GTAZkCTrTGTo0ubWakFdCZZ2oSPY+HYdXkP9qp7dB4VQX2gi4PUfQGwRqSmyOcaxwr+5vwLRw6diWricMaphV4IEPV1qr0t6H8QsYuF+/QXgF/8N3E0N9CAYacyKA== X-Received: by 10.194.203.5 with SMTP id km5mr17000300wjc.172.1455063009482; Tue, 09 Feb 2016 16:10:09 -0800 (PST) X-Received: by 10.194.203.5 with SMTP id km5mr17000285wjc.172.1455063009317; Tue, 09 Feb 2016 16:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.82.36 with HTTP; Tue, 9 Feb 2016 16:09:49 -0800 (PST) In-Reply-To: References: From: Franck Martin Date: Tue, 9 Feb 2016 16:09:49 -0800 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=047d7bae4532cbfa41052b5f41ed Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] auth-results and spf X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:10:13 -0000 --047d7bae4532cbfa41052b5f41ed Content-Type: text/plain; charset=UTF-8 Well, for instance with DMARC we do not add again the SPF and DKIM identifiers used to get the DMARC results. So I guess this is the same, you have policy.iprev to indicate the connecting IP, this is what I use in Authentication-Results. If you were just doing the Received-SPF header, then it has client-ip, because this header needs to be able to stand on its own. So I feel there is no need to add a client ip key within the SPF construct in the Authentication-Results header, just make sure to have policy.iprev in this header. Also in the SPF portion of the Authenticated-Results, I make sure to have the value for the rfc5321.mailfrom and rfc5321.helo there, because the SPF pass depends on one or the other if your SPF local policy is only based on the RFC7208.MAILFROM. Technically, there are 2 SPF results, one for RFC7208.HELO and one for RFC7208.MAILFROM. Your local policy decide on which one will do what... Many people ignore RFC7208.HELO. On Tue, Feb 9, 2016 at 1:44 PM, Brandon Long wrote: > Not sure the best list to send this to... but anyone know why the IP isn't > a formal field in the spf method for the Authentication-Results header (RFC > 7601)? > > For "iprev", there is policy.iprev, but there isn't one for spf. We put > it in the comment now, but it would seem like an obvious requirement for > what was evaluated. > > Brandon > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > --047d7bae4532cbfa41052b5f41ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, for instance with DMARC we do not add again the SPF = and DKIM identifiers used to get the DMARC results. So I guess this is the = same, you have policy.iprev to indicate the connecting IP, this is what I u= se in Authentication-Results.

If you were just doing the= Received-SPF header, then it has client-ip, because this header needs to b= e able to stand on its own.

So I feel there is no = need to add a client ip key within the SPF construct in the Authentication-= Results header, just make sure to have policy.iprev in this header.

Also in the SPF portion of the Authenticated-Results, I m= ake sure to have the value for the rfc5321.mailfrom and rfc5321.helo there,= because the SPF pass depends on one or the other if your SPF local policy = is only based on the RFC7208.MAILFROM. Technically, there are 2 SPF results= , one for RFC7208.HELO and one for RFC7208.MAILFROM. Your local policy deci= de on which one will do what... Many people ignore RFC7208.HELO.

On Tue, Feb 9, 2016 at 1= :44 PM, Brandon Long <blong@google.com> wrote:
Not sure the best list to send this to= ... but anyone know why the IP isn't a formal field in the spf method f= or the Authentication-Results header (RFC 7601)?

For &qu= ot;iprev", there is policy.iprev, but there isn't one for spf.=C2= =A0 We put it in the comment now, but it would seem like an obvious require= ment for what was evaluated.

Brandon

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


--047d7bae4532cbfa41052b5f41ed-- From rag@ragged-software.com Tue Feb 9 15:33:51 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A541B2E37 for ; Tue, 9 Feb 2016 15:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwT0D_FocmZ5 for ; Tue, 9 Feb 2016 15:33:49 -0800 (PST) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id C13161B2E35 for ; Tue, 9 Feb 2016 15:33:49 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u19NXmYT013510 for ; Tue, 9 Feb 2016 18:33:48 -0500 Received: (qmail 11214 invoked by uid 0); 9 Feb 2016 23:33:48 -0000 X-TCPREMOTEIP: 107.209.217.9 X-Authenticated-UID: rag@ragged-software.com Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@107.209.217.9) by 0 with ESMTPA; 9 Feb 2016 23:33:48 -0000 To: spfbis@ietf.org From: "Roy A. Gilmore" X-Enigmail-Draft-Status: N1110 Organization: RAGged Software Message-ID: <56BA775B.9050109@ragged-software.com> Date: Tue, 9 Feb 2016 15:33:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:10:28 -0000 I'm not sure how to go about this, but, I'll start here and maybe somebody could point me in the right direction. I think placing the spf information in a TXT record directly attached to the domain is a mistake. I think the spf information should be placed in a TXT record attached to a _spf selector (e.g. _spf.example.com). This behavior already has a history of being used by other services (i.e. _kerberos.example.com, _dmarc.example.com, etc.), and would make retrieving the spf information much easier and much more robust. This would also be a trivial change to implement. Any thoughts? From nobody Tue Feb 9 16:36:14 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246FE1B32F5 for ; Tue, 9 Feb 2016 16:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7A4e7VnMZfj for ; Tue, 9 Feb 2016 16:36:12 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940C21B32F1 for ; Tue, 9 Feb 2016 16:36:12 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 3933F1FCAE7; Wed, 10 Feb 2016 00:36:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1A2D5160047; Wed, 10 Feb 2016 00:36:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 09D331600A5; Wed, 10 Feb 2016 00:36:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vfj5cbnFgWbJ; Wed, 10 Feb 2016 00:36:07 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id BE208160047; Wed, 10 Feb 2016 00:36:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9A90F41C28F6; Wed, 10 Feb 2016 11:36:05 +1100 (EST) To: "Roy A. Gilmore" From: Mark Andrews References: <56BA775B.9050109@ragged-software.com> In-reply-to: Your message of "Tue, 09 Feb 2016 15:33:47 -0800." <56BA775B.9050109@ragged-software.com> Date: Wed, 10 Feb 2016 11:36:05 +1100 Message-Id: <20160210003605.9A90F41C28F6@rock.dv.isc.org> Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:36:14 -0000 In message <56BA775B.9050109@ragged-software.com>, "Roy A. Gilmore" writes: > I'm not sure how to go about this, but, I'll start here and maybe > somebody could point me in the right direction. I think placing the spf > information in a TXT record directly attached to the domain is a > mistake. I think the spf information should be placed in a TXT record > attached to a _spf selector (e.g. _spf.example.com). This behavior > already has a history of being used by other services (i.e. > _kerberos.example.com, _dmarc.example.com, etc.), and would make > retrieving the spf information much easier and much more robust. This > would also be a trivial change to implement. Any thoughts? This group won't allow the double query and will introduce spurious interoperablity arguments. See the history of the SPF record type which if the group hadn't abandoned would be well on the way to being done by now as they abandoned the process just as the libraries using the new code point were being deployed. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 9 17:17:46 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9011B34C4 for ; Tue, 9 Feb 2016 17:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emaIJ18kaXuA for ; Tue, 9 Feb 2016 17:17:42 -0800 (PST) Received: from mail.gathman.org (mail.gathman.org [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED451AD2D5 for ; Tue, 9 Feb 2016 17:17:40 -0800 (PST) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1455067057; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=jy+VgGzFkQFkF+kh22+hz3uCyGipToiC/32A3FANmAM=; b=OS+NfDk+bDvKQZJsEsi/Ztr9o6ftVtqQ0jU2pCVd6rA2XvdSnfX+9u1mKkBQg5m0TLBKs4 eD0dI6irWHRF96Np2U5CuqvL7AllZkPwKojhOyRHg/4bUPjDqwoh78c+1dXhLUXxGaKRzIVT ckbAwlLagcsDXGhhcrYtkSpztJqoY= Received: from sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net (sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:809::2] (may be forged)) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u1A1HQjd013651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Feb 2016 20:17:36 -0500 Date: Tue, 9 Feb 2016 20:17:26 -0500 (EST) From: "Stuart D. Gathman" To: Mark Andrews In-Reply-To: <20160210003605.9A90F41C28F6@rock.dv.isc.org> Message-ID: References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "Roy A. Gilmore" , spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 01:17:44 -0000 On Wed, 10 Feb 2016, Mark Andrews wrote: > In message <56BA775B.9050109@ragged-software.com>, "Roy A. Gilmore" writes: >> somebody could point me in the right direction. I think placing the spf >> information in a TXT record directly attached to the domain is a >> mistake. I think the spf information should be placed in a TXT record >> attached to a _spf selector (e.g. _spf.example.com). This behavior > > This group won't allow the double query and will introduce spurious > interoperablity arguments. See the history of the SPF record type > which if the group hadn't abandoned would be well on the way to > being done by now as they abandoned the process just as the libraries > using the new code point were being deployed. The big problem with the SPF record type was certain common DNS servers that would completely ignore (read TIMEOUT) queries for an RR type they didn't know about (instead of returning NXDOMAIN). The _spf subdomain would not have that problem, and so would have some legs for another try. But I think having been burned by the SPF record type, no one is anxious to try. From nobody Tue Feb 9 17:27:47 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D441B34CF for ; Tue, 9 Feb 2016 17:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A46fxhrzrq7d for ; Tue, 9 Feb 2016 17:27:44 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2566C1B34D5 for ; Tue, 9 Feb 2016 17:27:44 -0800 (PST) Received: from [192.168.111.103] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D0BC6C4017C for ; Tue, 9 Feb 2016 19:27:42 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1455067662; bh=Y26+HgtLThaVh8QXso+eqHL9KeLxyIF631yEd8sD9io=; h=In-Reply-To:References:Subject:From:Date:To:From; b=XXIfXgOhRn0gW5kzdbAbfTJwt1V8j6IX7P74KIOUevbXrB2ZkI0ByHI13t9ivflTi 7DjzzyGtXlX+pSD3a+qvOnqFwdXG9IQH84Vv3KgkW+jFIL+sNkGIfsT7v7gCoHN+I3 L2GAhFApbCJylTV5apNf6SiD/rVQKU4T2AbGX2bA= User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 09 Feb 2016 20:27:31 -0500 To: spfbis@ietf.org Message-ID: <341A0C2E-388B-4945-8877-A6F4C93D9D82@kitterman.com> Archived-At: Subject: Re: [spfbis] auth-results and spf X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 01:27:45 -0000 On February 9, 2016 4:44:04 PM EST, Brandon Long wrote: >Not sure the best list to send this to... but anyone know why the IP >isn't >a formal field in the spf method for the Authentication-Results header >(RFC >7601)? > >For "iprev", there is policy.iprev, but there isn't one for spf. We >put it >in the comment now, but it would seem like an obvious requirement for >what >was evaluated. If I recall correctly, this goes back to the original discussions on mail-vet-discuss@mipassoc.org and what became RFC 5451. You can check the list archive for details, but I believe it wasn't included on the theory that IP address is an input, not an output of the SPF check. This was hotly debated at the time and this is how it came out. It's one of the reasons that A-R isn't a complete replacement for Received-SPF. Scott K From nobody Tue Feb 9 18:24:40 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38FE1B3591 for ; Tue, 9 Feb 2016 18:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVTlU5SnDakU for ; Tue, 9 Feb 2016 18:24:38 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965651B3590 for ; Tue, 9 Feb 2016 18:24:38 -0800 (PST) Received: (qmail 69024 invoked from network); 10 Feb 2016 02:24:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 02:24:36 -0000 Date: 10 Feb 2016 02:24:14 -0000 Message-ID: <20160210022414.98457.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <341A0C2E-388B-4945-8877-A6F4C93D9D82@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: spf2@kitterman.com Subject: Re: [spfbis] auth-results and spf X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 02:24:39 -0000 >If I recall correctly, this goes back to the original discussions on >mail-vet-discuss@mipassoc.org and what became RFC 5451. You can check the list archive >for details, but I believe it wasn't included on the theory that IP address is an input, >not an output of the SPF check. Also, you should be able to see the IP address in the Received: header under the A-R header. R's, John From nobody Tue Feb 9 18:25:51 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A541B3595 for ; Tue, 9 Feb 2016 18:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6-Az1vAiLqi for ; Tue, 9 Feb 2016 18:25:50 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17031B3590 for ; Tue, 9 Feb 2016 18:25:49 -0800 (PST) Received: (qmail 69133 invoked from network); 10 Feb 2016 02:25:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 02:25:47 -0000 Date: 10 Feb 2016 02:25:25 -0000 Message-ID: <20160210022525.98482.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <56BA775B.9050109@ragged-software.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 02:25:50 -0000 > I think the spf information should be placed in a TXT record >attached to a _spf selector (e.g. _spf.example.com). You're right, but you're also a decade too late. Forget it. R's, John From nobody Tue Feb 9 19:24:40 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7051B3623 for ; Tue, 9 Feb 2016 19:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE0d_M9gBPFH for ; Tue, 9 Feb 2016 19:24:37 -0800 (PST) Received: from atl4mhob20.myregisteredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) by ietfa.amsl.com (Postfix) with ESMTP id E54F81B3624 for ; Tue, 9 Feb 2016 19:24:36 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob20.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1A3OYeQ032035 for ; Tue, 9 Feb 2016 22:24:34 -0500 Received: (qmail 32700 invoked by uid 0); 10 Feb 2016 03:24:34 -0000 X-TCPREMOTEIP: 107.209.217.9 X-Authenticated-UID: rag@ragged-software.com Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@107.209.217.9) by 0 with ESMTPA; 10 Feb 2016 03:24:33 -0000 To: spfbis@ietf.org References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> From: "Roy A. Gilmore" X-Enigmail-Draft-Status: N1110 Organization: RAGged Software Message-ID: <56BAAD71.8080009@ragged-software.com> Date: Tue, 9 Feb 2016 19:24:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210003605.9A90F41C28F6@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 03:24:39 -0000 I hope I don't come across as argumentative, that is not my intention. I don't have any idea how these workgroups work. I'm curious about a behavior that I THINK (I could be wrong) is incorrect with spf, and trying to learn, so I'm asking what I think are good questions. Double query? What if a single domain query returns multiple TXT records. How long will it take to process multiple free form (i.e. RFC 1035: "The semantics of the text depends on the domain where it is found.") TXT records to be sure you select the right one? Can you be sure you selected the right one? If you query for a _spf TXT record, you know you got the right one (well, I guess in the degenerate case where DNS has been misconfigured, you could get multiple TXT records). I suppose someone could say that only one TXT record should be returned. RFC 1035 doesn't say whether TXT is a singleton resource record or not. But, RFC 1035 has been updated by so many RFC's and BCP's that I'm not sure (I'll have to look into that). I know bind allows multiple TXT records per key (I'm not sure if "key" is the correct terminology here). Anyway, assume for a minute that only one TXT record should to be returned, should spfbis hijack that TXT record? I don't think so. What about all the other services that query for a service specific TXT record, are their workgroups "wrong", and the spfbis workgroup "right"? I'd willing to bet the other workgroups have some pretty smart people too (probably some of the same smart people). The double query argument was used with SRV records (RFC 2782) not allowing CNAMEs for targets, which effectively made the whole point of CNAMEs useless. If I have a CNAME record pointing to a LDAP server, and I replace the LDAP server, instead of just changing the CNAME record, I have to change all the SRV records too, so why even bother with a CNAME in the first place (rhetorical, don't bother answering)? I suppose it doesn't really matter, does anybody actually use SRV records on the internet (rhetorical again, bordering on sarcasm)? SRV records seem to be used mainly on intranets, particularly ones with Microsoft Active Directory Domains where a lot of the SRV record configuration happens "under the hood" with little human input. As to spurious interoperablity arguments, that's easy, set a transition period where either record is acceptable with a preference for the _spf TXT record (i.e. query for the _spf TXT record first, and fall back to the domain TXT record if the _spf TXT record doesn't exist). Maybe, even a "double" transition period where in the first transition period the domain TXT record was the preferred record. POP3 didn't replace POP2 overnight. And IMAP4 still hasn't replaced POP3 even though it has many advantages. Sorry about being so long winded. I'll try to be more concise in the future. On 02/09/2016 04:36 PM, Mark Andrews wrote: > In message <56BA775B.9050109@ragged-software.com>, "Roy A. Gilmore" writes: >> I'm not sure how to go about this, but, I'll start here and maybe >> somebody could point me in the right direction. I think placing the spf >> information in a TXT record directly attached to the domain is a >> mistake. I think the spf information should be placed in a TXT record >> attached to a _spf selector (e.g. _spf.example.com). This behavior >> already has a history of being used by other services (i.e. >> _kerberos.example.com, _dmarc.example.com, etc.), and would make >> retrieving the spf information much easier and much more robust. This >> would also be a trivial change to implement. Any thoughts? > This group won't allow the double query and will introduce spurious > interoperablity arguments. See the history of the SPF record type > which if the group hadn't abandoned would be well on the way to > being done by now as they abandoned the process just as the libraries > using the new code point were being deployed. > >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis From nobody Tue Feb 9 19:31:30 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED801B3638 for ; Tue, 9 Feb 2016 19:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n_1jnvFi6Ih for ; Tue, 9 Feb 2016 19:31:28 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541061B3639 for ; Tue, 9 Feb 2016 19:31:28 -0800 (PST) Received: (qmail 45832 invoked from network); 10 Feb 2016 03:31:27 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 03:31:27 -0000 Date: 10 Feb 2016 03:31:04 -0000 Message-ID: <20160210033104.98651.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <56BAAD71.8080009@ragged-software.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 03:31:29 -0000 In article <56BAAD71.8080009@ragged-software.com> you write: >I hope I don't come across as argumentative, that is not my intention. I >don't have any idea how these workgroups work. I'm curious about a >behavior that I THINK (I could be wrong) is incorrect with spf, and >trying to learn, so I'm asking what I think are good questions. Old joke: Q. How could God create the world in six days? A. He didn't have an installed base. SPF works well enough that there is no incentive for anyone to change the existing running code that is in tens of thousands of mail systems all over the world. If we were doing SPF from scratch, there's all sorts of stuff we'd do differently, but like I said, it's a decade too late. R's, John From nobody Tue Feb 9 19:35:39 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78BF1B3643 for ; Tue, 9 Feb 2016 19:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuv6iACgRyvt for ; Tue, 9 Feb 2016 19:35:37 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067FB1B3642 for ; Tue, 9 Feb 2016 19:35:36 -0800 (PST) Received: (qmail 46260 invoked from network); 10 Feb 2016 03:35:35 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 03:35:35 -0000 Date: 10 Feb 2016 03:35:13 -0000 Message-ID: <20160210033513.98688.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <56BAAD71.8080009@ragged-software.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 03:35:38 -0000 PS: >As to spurious interoperablity arguments, that's easy, set a transition >period ... That was the plan with the type 99 SPF record. See RFC 6686 to see how well that worked. There's huge pressure for people to move from IPv4 to IPv6 since the price of IPv4 addresses has in the past few years increased from roughly zero to about $10 per address while IPv6 is still nearly free and always will be. But it'll still be decades before IPv4 goes awy. R's, John From nobody Tue Feb 9 19:51:58 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F621B3661 for ; Tue, 9 Feb 2016 19:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Saiu9p8j77VZ for ; Tue, 9 Feb 2016 19:51:55 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84F051B3660 for ; Tue, 9 Feb 2016 19:51:55 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1A3prSw008212 for ; Tue, 9 Feb 2016 22:51:53 -0500 Received: (qmail 14736 invoked by uid 0); 10 Feb 2016 03:51:53 -0000 X-TCPREMOTEIP: 107.209.217.9 X-Authenticated-UID: rag@ragged-software.com Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@107.209.217.9) by 0 with ESMTPA; 10 Feb 2016 03:51:53 -0000 To: spfbis@ietf.org References: <20160210022525.98482.qmail@ary.lan> From: "Roy A. Gilmore" X-Enigmail-Draft-Status: N1110 Organization: RAGged Software Message-ID: <56BAB3D8.8060607@ragged-software.com> Date: Tue, 9 Feb 2016 19:51:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210022525.98482.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 03:51:57 -0000 Why should it matter if I'm a decade too late? If I'm right (and I'm not saying that I am), why shouldn't the behavior be changed. RFC's aren't set in stone, they are updated and/or obsoleted all the time. This proposed change is trivial to implement. On 02/09/2016 06:25 PM, John Levine wrote: >> I think the spf information should be placed in a TXT record >> attached to a _spf selector (e.g. _spf.example.com). > You're right, but you're also a decade too late. Forget it. > > R's, > John > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From nobody Tue Feb 9 20:12:54 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81C1B3696 for ; Tue, 9 Feb 2016 20:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGs9OKq61nn8 for ; Tue, 9 Feb 2016 20:12:52 -0800 (PST) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id EA1E41B3691 for ; Tue, 9 Feb 2016 20:12:51 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u1A4CoV7014755 for ; Tue, 9 Feb 2016 23:12:50 -0500 Received: (qmail 16843 invoked by uid 0); 10 Feb 2016 04:12:50 -0000 X-TCPREMOTEIP: 107.209.217.9 X-Authenticated-UID: rag@ragged-software.com Received: from unknown (HELO thor.internal.ragged-software.com) (rag@ragged-software.com@107.209.217.9) by 0 with ESMTPA; 10 Feb 2016 04:12:50 -0000 To: spfbis@ietf.org References: <20160210033104.98651.qmail@ary.lan> From: "Roy A. Gilmore" X-Enigmail-Draft-Status: N1110 Organization: RAGged Software Message-ID: <56BAB8C1.50809@ragged-software.com> Date: Tue, 9 Feb 2016 20:12:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160210033104.98651.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:12:53 -0000 While I'm aware that there are "tens of thousands of mail systems all over the world", there are only a few SMTP implementations that are run on all those systems. You only have to get the SMTP developers on board. This is a trivial change (maybe not a one-liner, but, close), would simplify there code and make it more robust. This change could easily rolled out as a bug fix. Bug fixes are released all the time, and SHOULD be applied ASAP. If a server administrator is still using the same version of his/her SMTP implementation next year that he/she is using this year, he/she is not doing his/her job and should be fired. On 02/09/2016 07:31 PM, John Levine wrote: > In article <56BAAD71.8080009@ragged-software.com> you write: >> I hope I don't come across as argumentative, that is not my intention. I >> don't have any idea how these workgroups work. I'm curious about a >> behavior that I THINK (I could be wrong) is incorrect with spf, and >> trying to learn, so I'm asking what I think are good questions. > Old joke: > > Q. How could God create the world in six days? > A. He didn't have an installed base. > > SPF works well enough that there is no incentive for anyone to change > the existing running code that is in tens of thousands of mail systems > all over the world. If we were doing SPF from scratch, there's all > sorts of stuff we'd do differently, but like I said, it's a decade too > late. > > R's, > John > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From nobody Tue Feb 9 20:14:56 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4511B369A for ; Tue, 9 Feb 2016 20:14:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Cp1vKXG_kuV for ; Tue, 9 Feb 2016 20:14:54 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F461B3698 for ; Tue, 9 Feb 2016 20:14:54 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id e6so5279897vkh.2 for ; Tue, 09 Feb 2016 20:14:54 -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 :content-type; bh=1pm+ef5TJ128/JaVJfy2TSFoeC6ClGfDdgnabajfyXQ=; b=vBMI0xyyXQpyBIQfKU7Ik1nNWHuu4wdd1ZAutmxVKYQPe798TB0LkJD1TPHI0I7r2x Ea6ZwqlQ7vT6DcIgojMo9f+r3+w2UdyL67+I+nzq/lOgtasQKVmt0Uo2EyYeReneQjY3 kLqsTZXeg/ze2FB5Hz79eHTYAsuropPsxY8Un8BIEFZ7F+eoNPcVGvXs5RmjxvYNjtf5 GrvLtOn5ztxz64ItOljFm/1yA4SL8ZXE9ingChXEyBg/RQ6WkMPIprrzpIqGIbNUJwIJ akV9SL2BF0Uf9ZC3bPHQE8YmwlMTZ8zmXY45WV4m5Jzb8mCG2hvA4yaEEgA56dehR4EM NNUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1pm+ef5TJ128/JaVJfy2TSFoeC6ClGfDdgnabajfyXQ=; b=Qxz9mNaGn2zIw0umcl/cgjeQSG1jMcwnzdGeE61VprUzAiQqNiUT1o5MAwignmD6xS Rkj14YDy39uwr6wzJaI1G2XVyyjjPvj0n3MutWWb4KeziKB3uZ2WF6I4qwBcO9O4ncYF zLi8x42fnmCuBUQRD/lRzJUcYxyK4gtCp9PaA7k5ROem74zMlyjO2KMvfkNDemzt2ISm PY06uolQ+XjPb59m9oFXJ5RT312xKlN+4ZO9XzxnhzK4lq1y8dQHWSQqbIfBAlWHzs6d cCTM33+XtmQ2o65zhi91bfapaEvgfzQQ12hzPjpmS+s3MwoouivQj2WnYm7GfMsqKfYC GARQ== X-Gm-Message-State: AG10YOSwMzvZkGHUYZsurzSc1I66rDKFPBNdPOhPB5egIEuXpZsK8rWZyz0+NnhOxlCK06bKDMO9OXSSQ5/lsA== MIME-Version: 1.0 X-Received: by 10.31.47.205 with SMTP id v196mr28003082vkv.18.1455077693567; Tue, 09 Feb 2016 20:14:53 -0800 (PST) Received: by 10.103.32.194 with HTTP; Tue, 9 Feb 2016 20:14:53 -0800 (PST) In-Reply-To: <56BAB3D8.8060607@ragged-software.com> References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> Date: Tue, 9 Feb 2016 23:14:53 -0500 Message-ID: From: Dotzero To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=001a1143920e0bbaa5052b62ad96 Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:14:56 -0000 --001a1143920e0bbaa5052b62ad96 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 10:51 PM, Roy A. Gilmore wrote: > Why should it matter if I'm a decade too late? If I'm right (and I'm not > saying that I am), why shouldn't the behavior be changed. RFC's aren't > set in stone, they are updated and/or obsoleted all the time. This > proposed change is trivial to implement. > > The fact that you believe this to be a trivial change to implement makes clear that you don't understand what is actually involved. This horse has been beaten so much it is only fit for the glue factory. You are absolutely right that _spf would be a better approach... if there was not already a large installed base to consider. SPF works (for some definition of works). The change you are proposing sets up interoperability issues that we have dealt with before. --001a1143920e0bbaa5052b62ad96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 9, 2016 at 10:51 PM, Roy A. Gilmore <<= a href=3D"mailto:rag@ragged-software.com" target=3D"_blank">rag@ragged-soft= ware.com> wrote:
Why shou= ld it matter if I'm a decade too late? If I'm right (and I'm no= t
saying that I am), why shouldn't the behavior be changed. RFC's are= n't
set in stone, they are updated and/or obsoleted all the time. This
proposed change is trivial to implement.

=
The fact that you believe this to be a= trivial change to implement makes clear that you don't understand what= is actually involved. This horse has been beaten so much it is only fit fo= r the glue factory. You are absolutely right that _spf would be a better ap= proach... if there was not already a large installed base to consider. SPF = works (for some definition of works). The change you are proposing sets up = interoperability issues that we have dealt with before.
--001a1143920e0bbaa5052b62ad96-- From nobody Tue Feb 9 20:17:39 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7155C1B36B1 for ; Tue, 9 Feb 2016 20:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ_N4YV6O2bs for ; Tue, 9 Feb 2016 20:17:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD141B36AA for ; Tue, 9 Feb 2016 20:17:35 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 0FF10349315; Wed, 10 Feb 2016 04:17:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0507B160047; Wed, 10 Feb 2016 04:17:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E9E5B160048; Wed, 10 Feb 2016 04:17:32 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m7oG9Zk5Ck97; Wed, 10 Feb 2016 04:17:32 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id AA92D160047; Wed, 10 Feb 2016 04:17:32 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8562541C5BF9; Wed, 10 Feb 2016 15:17:30 +1100 (EST) To: "Roy A. Gilmore" From: Mark Andrews References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> In-reply-to: Your message of "Tue, 09 Feb 2016 19:51:52 -0800." <56BAB3D8.8060607@ragged-software.com> Date: Wed, 10 Feb 2016 15:17:30 +1100 Message-Id: <20160210041730.8562541C5BF9@rock.dv.isc.org> Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:17:37 -0000 In message <56BAB3D8.8060607@ragged-software.com>, "Roy A. Gilmore" writes: > Why should it matter if I'm a decade too late? If I'm right (and I'm not > saying that I am), why shouldn't the behavior be changed. RFC's aren't > set in stone, they are updated and/or obsoleted all the time. This > proposed change is trivial to implement. As is the change to use type99 which works with wildcard records. _spf doesn't work with wildcard records. Mark > On 02/09/2016 06:25 PM, John Levine wrote: > >> I think the spf information should be placed in a TXT record > >> attached to a _spf selector (e.g. _spf.example.com). > > You're right, but you're also a decade too late. Forget it. > > > > R's, > > John > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 9 20:31:21 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F4B1B36C7 for ; Tue, 9 Feb 2016 20:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLEpqwP5QVfB for ; Tue, 9 Feb 2016 20:31:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979491B36C5 for ; Tue, 9 Feb 2016 20:31:19 -0800 (PST) Received: from [10.72.181.183] ([12.236.144.210]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u1A4VIqN000483 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2016 20:31:18 -0800 To: John Levine , spfbis@ietf.org References: <20160210022525.98482.qmail@ary.lan> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56BABD0C.8070504@dcrocker.net> Date: Tue, 9 Feb 2016 20:31:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210022525.98482.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 09 Feb 2016 20:31:19 -0800 (PST) Archived-At: Cc: rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 04:31:20 -0000 On 2/9/2016 6:25 PM, John Levine wrote: >> I think the spf information should be placed in a TXT record >> attached to a _spf selector (e.g. _spf.example.com). > > You're right, but you're also a decade too late. Forget it. +1 Yes, it should have been done that way. No it does not seem possible to get the installed base to move to a different model. d/ From nobody Tue Feb 9 21:09:51 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790231B36FD for ; Tue, 9 Feb 2016 21:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ6CIoZHdvx4 for ; Tue, 9 Feb 2016 21:09:48 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E986B1B36FE for ; Tue, 9 Feb 2016 21:09:47 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 722F21FCAE6; Wed, 10 Feb 2016 05:09:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3CC48160047; Wed, 10 Feb 2016 05:09:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2B775160048; Wed, 10 Feb 2016 05:09:43 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uXoOjNIby91e; Wed, 10 Feb 2016 05:09:43 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id DDDD5160047; Wed, 10 Feb 2016 05:09:42 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 58CBD41C61C4; Wed, 10 Feb 2016 16:09:40 +1100 (EST) To: dcrocker@bbiw.net From: Mark Andrews References: <20160210022525.98482.qmail@ary.lan> <56BABD0C.8070504@dcrocker.net> In-reply-to: Your message of "Tue, 09 Feb 2016 20:31:08 -0800." <56BABD0C.8070504@dcrocker.net> Date: Wed, 10 Feb 2016 16:09:40 +1100 Message-Id: <20160210050940.58CBD41C61C4@rock.dv.isc.org> Archived-At: Cc: spfbis@ietf.org, rag@ragged-software.com, John Levine Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 05:09:49 -0000 In message <56BABD0C.8070504@dcrocker.net>, Dave Crocker writes: > > > On 2/9/2016 6:25 PM, John Levine wrote: > >> I think the spf information should be placed in a TXT record > >> attached to a _spf selector (e.g. _spf.example.com). > > > > You're right, but you're also a decade too late. Forget it. > > > +1 -100000 _spf was never right. > Yes, it should have been done that way. No it does not seem possible to > get the installed base to move to a different model. No, you just needed a longer time frame to transition than this group was willing to accept for a organic transition or to actually publish a timeframe. A simple instruction to nameserver developers to "automatically publish a SPF record if a TXT spf records exist" would have push the transition along enourmously by getting a large amount of SPF records out there. Actively sending out messages to those only publishing TXT spf records would have also helped. No one said "we want this transition done in N years" so it didn't happen in that amount of time and there there where complaints that the transition failed when the transition didn't happen overnight. Expectations where not set so no one could meet them. Mark > d/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 10 07:06:32 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1821B2BB9 for ; Wed, 10 Feb 2016 07:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTf-Q1trGBGT for ; Wed, 10 Feb 2016 07:06:23 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64A61A902D for ; Wed, 10 Feb 2016 07:06:22 -0800 (PST) Received: (qmail 67101 invoked from network); 10 Feb 2016 15:06:21 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 15:06:21 -0000 Date: 10 Feb 2016 15:05:59 -0000 Message-ID: <20160210150559.963.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <56BAB8C1.50809@ragged-software.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 15:06:29 -0000 In article <56BAB8C1.50809@ragged-software.com> you write: >While I'm aware that there are "tens of thousands of mail systems all >over the world", there are only a few SMTP implementations that are run >on all those systems. You only have to get the SMTP developers on board. Well, OK. Why don't you start contacting them, encourange them to change their SPF implementations with a suitable transition period, and let us know when we can throw the switch. One immutable rule of the standards and open source world is that telling other people to do work that you're not willing to do yourself is, ah, ineffective at best. R's, John From nobody Wed Feb 10 10:13:30 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0D1B2E41 for ; Wed, 10 Feb 2016 10:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS48csdF2kxq for ; Wed, 10 Feb 2016 10:13:27 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF871ACD7F for ; Wed, 10 Feb 2016 10:13:27 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id k196so19537363vka.0 for ; Wed, 10 Feb 2016 10:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Qx9hD4bDUT5vEBKGTcJvumNbgN21zFJTKSZg4SJrde8=; b=OIKjE/8sDX+ev2lp8y2oOzjrEe+sUqo5pm2KDABzbCFL6vfelmVM2KawPUiO+NJJz6 4jbc5F2B/p5jelj+1In2cZv/l6S44c6scRygO5hMmkKy0th1XqkL+532Ov/Z/2OqOFs2 pZqvWthJvlL8QfdzGSbf+nK2Ho0ZPK8K1cnAY1TztA6TQWdJV86dMOLVVn7YpIZbrmxW vGdFm59VacPxiIPSXhev7aGv163XM6vUIitqYu9r10pESjAYbBVI9GdSC6BFFnKcuEt3 axchnsrwLYcH8BKiCgcvXC+URJHW9me4raXhKXJHUCVQrGGBBzTDEytDgzyYQkEdR2hM BVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=Qx9hD4bDUT5vEBKGTcJvumNbgN21zFJTKSZg4SJrde8=; b=SbJHBubH0mLnwIk+OLtWZ1gxOwGuv7izOoT78A2n9ePYWEhTmr2Z+Q/BwOU6qjnIOA 2HvyE/R4hFEpiheZgVSTb6MfBACO63wZ9lfN32qLIccGCBupGRAYYylz6gtvQCeCkjB9 momNJmM+rD3hpAIh/h37O8MwPhkm5eWiGfOi6PbHrNk0ChS7UxvmqXCaBzpTA2hN3u1n Xo5seYfYpNExpzevrSu2ape0enI3aRxJ7SiifjOk7nTFj8w2LhwbXyzHs54JV28nZULP bBa0q1ZzMbZASb3Mhi8AOKCTwXwg+Uq6D0SaSGb9bVEFz8aSGAQMe1n0UH+rrQpqe4q2 mteg== X-Gm-Message-State: AG10YORNRfPNNULeZRHiQOyLJL+X1MkXvtBYwMLHrcyQ0NpXYzpiy86iJ9vEJyhFYwX1ce6Ba6cxvYw6Iwp54A== X-Received: by 10.31.41.14 with SMTP id p14mr31205820vkp.151.1455128006430; Wed, 10 Feb 2016 10:13:26 -0800 (PST) MIME-Version: 1.0 Sender: leibzon@gmail.com Received: by 10.159.40.230 with HTTP; Wed, 10 Feb 2016 10:12:59 -0800 (PST) In-Reply-To: <20160210150559.963.qmail@ary.lan> References: <56BAB8C1.50809@ragged-software.com> <20160210150559.963.qmail@ary.lan> From: William Leibzon Date: Wed, 10 Feb 2016 10:12:59 -0800 X-Google-Sender-Auth: IATa2CBXfSCeo0uz4qmkQoFNeuU Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a113ef6bced143c052b6e6373 Archived-At: Cc: spfbis@ietf.org, rag@ragged-software.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:13:29 -0000 --001a113ef6bced143c052b6e6373 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 10, 2016 at 7:05 AM, John Levine wrote: > In article <56BAB8C1.50809@ragged-software.com> you write: > >While I'm aware that there are "tens of thousands of mail systems all > >over the world", there are only a few SMTP implementations that are run > >on all those systems. You only have to get the SMTP developers on board. > > Well, OK. Why don't you start contacting them, encourange them to > change their SPF implementations with a suitable transition period, > and let us know when we can throw the switch. > > One immutable rule of the standards and open source world is that > telling other people to do work that you're not willing to do yourself > is, ah, ineffective at best. > That's a double-edged sword - expecting implimentors to change first while they are expecting a fully accepted standard that will tell them what they need to do. But yes this ship has sailed and I've been through _spf and SPF RR discussions several times. _spf has a problem because of no wildcard support and that's why it was discarded as an option after considerable dicussion on spf-discuss mail list 10 years ago. I was from the start and still am in favor of SPF RR. And DNS providers and vendors of email software were given enough time (5+ years) to try to do "the rght thing" and switch and it did not happen in big enough numbers. Go ahead and find who to blame if you like. And if you want to blame IETF, sure its your right. But it has no enforcing power what so ever. It just gives out tech documents (with minimum potential for conflict it can) and hope people find them useful. Like with open-source software, some standards and documents survive and become very popular and many don't survive even through they were or are a good idea and well intended for benefits of everyone (or at least some). William --001a113ef6bced143c052b6e6373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 10, 2016 at 7:05 AM, John Levine <johnl@taugh.c= om> wrote:
In article <56BAB8C1.50809@ragged-soft= ware.com> you write:
>While I'm aware that there are "tens of thousands of mail syst= ems all
>over the world", there are only a few SMTP implementations that ar= e run
>on all those systems. You only have to get the SMTP developers on board= .

Well, OK.=C2=A0 Why don't you start contacting them, encourange = them to
change their SPF implementations with a suitable transition period,
and let us know when we can throw the switch.

One immutable rule of the standards and open source world is that
telling other people to do work that you're not willing to do yourself<= br> is, ah, ineffective at best.

That's= a double-edged sword - expecting implimentors to change first while they a= re expecting a fully accepted standard that will tell them what they need t= o do.

But yes this ship has sailed and I've been thro= ugh _spf and SPF RR discussions several times. _spf has a problem because o= f no wildcard support and that's why it was discarded as an option afte= r considerable dicussion on spf-discuss mail list 10 years ago. I was from = the start and still am in favor of SPF RR. And DNS providers and vendors of= email software were given enough time (5+ years) to try to do "the rg= ht thing" and switch and it did not happen in big enough numbers. Go a= head and find who to blame if you like.

And if you want to blame IET= F, sure its your right. But it has no enforcing power what so ever. It just= gives out tech documents (with minimum potential for conflict it can) and = hope people find them useful. Like with open-source software, some standard= s and documents survive and become very popular and many don't survive = even through they were or are a good idea and well intended for benefits of= everyone (or at least some).

William
--001a113ef6bced143c052b6e6373-- From nobody Wed Feb 10 11:25:50 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE2D1B2EF2 for ; Wed, 10 Feb 2016 11:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQBgNFFMkJym for ; Wed, 10 Feb 2016 11:25:47 -0800 (PST) Received: from mail.gathman.org (mail.gathman.org [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD321B2EDB for ; Wed, 10 Feb 2016 11:25:47 -0800 (PST) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1455132344; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=fdI+DJ0O5unSEvqPo+6kNrE4Kd8aMBDacfdgwW+4jUA=; b=W9kpmAZqcnWJBw6HwUQpNkGbBn0Cyq/oI8SF7T2HHzIderjQfCQ2ZhBsLLM1Li/YyfX026 ZIu/bhSBdeap7Zd63RPiCN5HXZZ1mI1yQXyrG1FpLJH2Czez/ZP3AXD3RPURRDroqgclQbxa gRf7QXC3c0auUH010chM/3Uo7lX+U= Received: from sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net (sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:809::2] (may be forged)) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u1AJPgq0016590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Feb 2016 14:25:43 -0500 Date: Wed, 10 Feb 2016 14:25:42 -0500 (EST) From: "Stuart D. Gathman" To: "Roy A. Gilmore" In-Reply-To: <56BAB8C1.50809@ragged-software.com> Message-ID: References: <20160210033104.98651.qmail@ary.lan> <56BAB8C1.50809@ragged-software.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 19:25:48 -0000 On Tue, 9 Feb 2016, Roy A. Gilmore wrote: > While I'm aware that there are "tens of thousands of mail systems all > over the world", there are only a few SMTP implementations that are run > on all those systems. You only have to get the SMTP developers on board. > This is a trivial change (maybe not a one-liner, but, close), would Changing the SPD implementation is trivial. I've done it, a long time ago. I voted to keep type99 for the production RFC. Actually working efficiently with braindead DNS servers is *not* trivial. I've tried to do it, and gave up. I still have TYPE99 code in my SPF implementation, and I periodically turn it on to see if a certain huge DNS server provider is still screwing up . . . From nobody Wed Feb 10 11:33:00 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6745A1B2EFF for ; Wed, 10 Feb 2016 11:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hofUR5wKaUZu for ; Wed, 10 Feb 2016 11:32:58 -0800 (PST) Received: from mail.gathman.org (mail.gathman.org [IPv6:2001:470:5:c85::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1406B1B2EC5 for ; Wed, 10 Feb 2016 11:32:57 -0800 (PST) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1455132776; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=d60K+RClSn10EjKQ1Zr9V9jn8PhkaqZ2Y+L2SMCM7R8=; b=d3BeaDkkIDkD8/291AkE+P0uTg5inrgbZcMEei57U6DUjg3oqnUAr902j0qq6/LkFopLRN 5J8BPuDZsxEcbwe9A0802oc4Vr7X6Qss3/o6oelbyakLUiYZaBiljfpp+Pcf+cBCaq2V0NqW thXJeGdpdwop4K9OmaJsN6DurgeIk= Received: from sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net (sdgathman-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:809::2] (may be forged)) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u1AJWoJU016618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Feb 2016 14:32:55 -0500 Date: Wed, 10 Feb 2016 14:32:50 -0500 (EST) From: "Stuart D. Gathman" To: "Roy A. Gilmore" In-Reply-To: <56BAB3D8.8060607@ragged-software.com> Message-ID: References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 19:32:59 -0000 On Tue, 9 Feb 2016, Roy A. Gilmore wrote: > Why should it matter if I'm a decade too late? If I'm right (and I'm not > saying that I am), why shouldn't the behavior be changed. RFC's aren't > set in stone, they are updated and/or obsoleted all the time. This > proposed change is trivial to implement. As a pyspf developer, the _spf idea is *not* trivial to implement. The SPF RR is trivial to implement. The problem was braindead DNS servers. I still publish both SPF and TXT records (no SPF police are stopping me). I still have the type99 code in my SPF implementation. Type99 is only deprecated. If you can convince DNS server providers to operate correctly for unknown RR types (or failing that, to recognize SPF RR), and convince lots of people to publish both, then a switch could be reconsidered. Especially if there is a new backward incompatible SPF version. From nobody Wed Feb 10 12:43:39 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1EA1B2FB3 for ; Wed, 10 Feb 2016 12:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmkM9Mu_b_Tz for ; Wed, 10 Feb 2016 12:43:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA441B2FB5 for ; Wed, 10 Feb 2016 12:43:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 1FE893493C4; Wed, 10 Feb 2016 20:43:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1570F160048; Wed, 10 Feb 2016 20:43:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 04BB31600AC; Wed, 10 Feb 2016 20:43:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YDdvv7EDslvB; Wed, 10 Feb 2016 20:43:33 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id AC1CD160048; Wed, 10 Feb 2016 20:43:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6DC5241D2E99; Thu, 11 Feb 2016 07:43:31 +1100 (EST) To: "Stuart D. Gathman" From: Mark Andrews References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> In-reply-to: Your message of "Wed, 10 Feb 2016 14:32:50 -0500." Date: Thu, 11 Feb 2016 07:43:31 +1100 Message-Id: <20160210204331.6DC5241D2E99@rock.dv.isc.org> Archived-At: Cc: "Roy A. Gilmore" , spfbis@ietf.org Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 20:43:38 -0000 In message , "Stuart D. Gathman" writes: > On Tue, 9 Feb 2016, Roy A. Gilmore wrote: > > > Why should it matter if I'm a decade too late? If I'm right (and I'm not > > saying that I am), why shouldn't the behavior be changed. RFC's aren't > > set in stone, they are updated and/or obsoleted all the time. This > > proposed change is trivial to implement. > > As a pyspf developer, the _spf idea is *not* trivial to implement. > The SPF RR is trivial to implement. The problem was braindead DNS > servers. No the problem is brain dead firewalls. Apart from some load balancers that get anything other than A (and now sometimes AAAA) right, nameservers return NODATA or at worst NOTIMP when they don't implement a type. For many of the loadbalancer it is bad configuration not that the load balancer is incapable of returning a correct answer so you need to nag the operators of the load balancers to correctly configure them. The vast, vast, vast majority of nameservers have always done the correct thing. RFC 1034 actually tells developers to return NODATA. Nameservers put in SPF support in a timely manner. It's still there because there is no point in removing it. > I still publish both SPF and TXT records (no SPF police are stopping > me). I still have the type99 code in my SPF implementation. > Type99 is only deprecated. If you can convince DNS server providers > to operate correctly for unknown RR types (or failing that, to > recognize SPF RR), and convince lots of people to publish both, > then a switch could be reconsidered. Especially if there is a new > backward incompatible SPF version. The biggest problem we had was not setting expectations. I didn't expect the transition to complete in 5 years (look at how long it took before you could rely on just publishing a MX record for email) yet we have had people saying 5 years was more than enough time in this thread. If you wanted a 5 year transition it required active pushing of every to achieve that and I saw none of that. It takes about that long for new nameserver code to make it into OS's as the OS vendors don't pickup the code in a timely manner. I also expect everyone in this group to support the publication of https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-01 when it comes up as it is trying to get the remaining bad actors weeded out of the ecosystem by actively looking for them and informing the operators that they have a problem. You have all seen the issues cause by non RFC compliant code being deployed which is what these tests are looking for. It isn't impossible to test for whether servers answer correctly for various types including unknown types. See https://ednscomp.isc.org/compliance/tld-typereport.txt Note: there are false positives with timeouts as rate limiters kick in. Mark > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 10 20:37:54 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB801A8AD3 for ; Wed, 10 Feb 2016 20:37:53 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8l9nZOBnSBr for ; Wed, 10 Feb 2016 20:37:51 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C90F1A8AD2 for ; Wed, 10 Feb 2016 20:37:51 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id k196so28963666vka.0 for ; Wed, 10 Feb 2016 20:37:51 -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=SnC9FFjgpsntQ6FsqmGOptBtzOGKAlOXz/IuKx4OwCU=; b=gRTLw8nnsY+AAz8wOLY3bqa/Q7xj1vamvuLd1rvCSTPJlhk4E4/bvN/puQpjzn9X5z aqN/GNJUXXKbL6zxj+wrXJCI4MbJ9IG/pU2ii1K+jr6EcIg2zBDXxW8kR2WnY8FQfSv8 paGLt3ApqwFAnGoHQVs3+1f8b1zYE2H44c6Si5IZzxB/lifUSFvWUVWUGF5wr+zTnZO5 +tbIVRNOMt+b8mBhQ5fUhfSd2JtoBVLjgueyr06b1bukTGUMUvMbVUvmsI42hneRneNo iswjDvvjYd3AODbLg+xRna/uaC1rm/BfbbXMCMJruoTYXzanAuoQUueJYHbhqJ9kElR+ htqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SnC9FFjgpsntQ6FsqmGOptBtzOGKAlOXz/IuKx4OwCU=; b=S8BaN/sHY3E4eg/a8EpbHjrYJnRvAdJdcjhzOxa7S1Chrt0k5GVGS34EjjlVluaKiY Fs8oXFQEXAMfhC4kRnG1jwwUUqwvO20W81hJdOvGG9JKH5DcAI6iZby6G37cBu+dyg8T lMn3huKdCj4p4l9VcX8Cw/CyFLgmLZdUe1q+Ydijp2oFJgwhxxb9ejMeWCj3fYKqN6ZU mU2uh/W2Ag2chMZ5vshq/E2T25x8+dX5etGLVA8VYQRc2Y4QuMKYx/TTkE4jZFznmocU 8QxVnW+7i1Kx57MYMrAHhfgevsnNo2NTbZet2ojL1atyiyp9Dng41PS38mRD2f9k9uod Ymzw== X-Gm-Message-State: AG10YOQYL7Aj8f+yhIBo2Q64p8rSN9WXBSEpaDPbQYQ3I3jhK0p4jcHV1yGbKVKcyYBQbZQ9hu8oc2GnGNrD5A== MIME-Version: 1.0 X-Received: by 10.31.159.136 with SMTP id i130mr33745768vke.144.1455165470599; Wed, 10 Feb 2016 20:37:50 -0800 (PST) Received: by 10.103.72.195 with HTTP; Wed, 10 Feb 2016 20:37:50 -0800 (PST) In-Reply-To: <341A0C2E-388B-4945-8877-A6F4C93D9D82@kitterman.com> References: <341A0C2E-388B-4945-8877-A6F4C93D9D82@kitterman.com> Date: Wed, 10 Feb 2016 20:37:50 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a1142ed96f6f0d5052b771c17 Archived-At: Cc: "spfbis@ietf.org" Subject: Re: [spfbis] auth-results and spf X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 04:37:53 -0000 --001a1142ed96f6f0d5052b771c17 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 5:27 PM, Scott Kitterman wrote: > If I recall correctly, this goes back to the original discussions on > mail-vet-discuss@mipassoc.org and what became RFC 5451. You can check > the list archive for details, but I believe it wasn't included on the > theory that IP address is an input, not an output of the SPF check. > > This was hotly debated at the time and this is how it came out. It's one > of the reasons that A-R isn't a complete replacement for Received-SPF. > > Yeah, that was mostly it. A-R was meant to provide (a) the outputs of authentication methods, and (b) what thing was actually authenticated, i.e., what part of the visible message you think is "safe" as a result. For most methods I can think of, it's the domain name in the From: field or the MAIL FROM parameter, so there was no need to report the IP address as well; what would a typical user do with that? Someone was pushing to add it so that SPF could be re-evaluated by the MUA, but there wasn't much in the way of support for that (and, in fact, it resulted in what is now Appendix C of RFC7601). -MSK --001a1142ed96f6f0d5052b771c17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 9, 2016 at 5:27 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
If I recall correctly, this= goes back to the original discussions on mail-vet-discuss@mipassoc.org and what became RFC 5451.= =C2=A0 You can check the list archive for details, but I believe it wasn= 9;t included on the theory that IP address is an input, not an output of th= e SPF check.

This was hotly debated at the time and this is how it came out.=C2=A0 It= 9;s one of the reasons that A-R isn't a complete replacement for Receiv= ed-SPF.


Yeah, that was mostly it.= =C2=A0 A-R was meant to provide (a) the outputs of authentication methods, = and (b) what thing was actually authenticated, i.e., what part of the visib= le message you think is "safe" as a result.=C2=A0 For most method= s I can think of, it's the domain name in the From: field or the MAIL F= ROM parameter, so there was no need to report the IP address as well; what = would a typical user do with that?

Someone was pushing to= add it so that SPF could be re-evaluated by the MUA, but there wasn't = much in the way of support for that (and, in fact, it resulted in what is n= ow Appendix C of RFC7601).

-MSK
--001a1142ed96f6f0d5052b771c17-- From nobody Wed Feb 10 20:49:26 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7D1A8AEA for ; Wed, 10 Feb 2016 20:49:25 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ly1VlTvMvzl for ; Wed, 10 Feb 2016 20:49:23 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C551A8AE5 for ; Wed, 10 Feb 2016 20:49:22 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e185so29010791vkb.1 for ; Wed, 10 Feb 2016 20:49:22 -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=b3bEFdLPtV8mEpBEe0+8/34+/5g9V7b0syzGLFka4zQ=; b=UVL2vYc1W+LeS3xkx+xMLO4eYEgQDEkMk3r8lNgZL3Iha6KCBi1zHOPXm6AAPPvX6o obr5l/MmC2TX042c4ZXFHciBT595rVM3hdq+xq0kHHmTyc7bCIpvZT8cRmXGRspBX7MK JSvYr6A3x7QdB+ip6xEQiIJWATZX/c93LaSvUWueQziwbGOiPS4VoLFva/e4j10vjgv/ qtrtNa9j0b48RxAl8UievAhSxRH6XQM5snwKIH5HPzkVS1MUIvpq5c0DCXYxNJ5Frqg+ +lNzJ0gNH+sC+SU8jewx2CoSlfJVY+rOkaVDk4SsbIO9niFCAnhcMeghlC6yfbkgntzz dQSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b3bEFdLPtV8mEpBEe0+8/34+/5g9V7b0syzGLFka4zQ=; b=J8s2Ams/152T5ustmP/wPCnegndZgMnPHOmKrFTwKe5l+NPoGEoEx5ZOZQ0AnnY4Dh lg7/ZINS1etq+zYvjG32lPp+MOnDc+nb2SabCyNsAY4jyDr/VAB9xFtV/UQWeGijE4zM De3urQlqP8vmbOopLkmupekD+V7oLz+8jYhWLR1S6eeaY/Tpz3NvjVV3VS/sh5Vuj7Ho Lep7/hNoV3PD9JWLyXPuVqKBuMiSVHJPDd2OhFixP8rtL8W/N7H/Q5x+xGIS+eTOJaKL 0Z/K4J+dF3p3Bj+zY03z4UJ82+WhP6HSD4iGahvvLlYse/mFEiwnwQrpQAkHCSKDFKDd tO3g== X-Gm-Message-State: AG10YOQ2fsUPKEb8pVaYXVP1CamKoLEOB09Qf0YULKo7NKdZmrmcvsVUJ1WUj6cqDkeYzwNmWnCdzIlLgNcsSQ== MIME-Version: 1.0 X-Received: by 10.31.49.23 with SMTP id x23mr34171954vkx.0.1455166161936; Wed, 10 Feb 2016 20:49:21 -0800 (PST) Received: by 10.103.65.93 with HTTP; Wed, 10 Feb 2016 20:49:21 -0800 (PST) In-Reply-To: <20160210003605.9A90F41C28F6@rock.dv.isc.org> References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> Date: Wed, 10 Feb 2016 20:49:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11437e362be933052b7746bc Archived-At: Cc: "Roy A. Gilmore" , "spfbis@ietf.org" Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 04:49:25 -0000 --001a11437e362be933052b7746bc Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 4:36 PM, Mark Andrews wrote: > This group won't allow the double query and will introduce spurious > interoperablity arguments. See the history of the SPF record type > which if the group hadn't abandoned would be well on the way to > being done by now as they abandoned the process just as the libraries > using the new code point were being deployed. I am mystified that the bitterness on this topic remains impervious to things like evidence. The history of the SPF record type is documented in RFC6686. I'm happy to let that document and the data it contains speak for itself. I also contend that the record shows that the working group and the community made an informed decision. -MSK --001a11437e362be933052b7746bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11437e362be933052b7746bc-- From nobody Wed Feb 10 21:02:31 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ACE1A8BB2 for ; Wed, 10 Feb 2016 21:02:29 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTClE7if_tfE for ; Wed, 10 Feb 2016 21:02:28 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24141A8BB3 for ; Wed, 10 Feb 2016 21:02:27 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id c3so29061257vkb.3 for ; Wed, 10 Feb 2016 21:02:27 -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=0k24defXxQgRwTck0IlxYmfvGQHUtAiaEKSox1mH3Ek=; b=W1ZnQyK5udyWuJj2YZUld21enO3W2140mQAe4UHV3LVhK7Fj/DRutb3GGWlY7UdxCy xOsb1ARRWfaQ9kBT+5WsAIjyEm9XsaKPj5uR0gcAbnFudF/1TjShc+RLIt7o0cUrqOHr r83nhASbNdlDnPB5nD1+uqa8VekwjjODWpwkuYl3MMuVWstxak+2BsdPuthJjS1OpiD7 mkOw0WJBSdBLGgu7/ZeHUVrRFt7jxkogKrztxxyMJE7gEbaEqSzd6P/don7VNh9Gd0Qm JrbhkTPmqLbxz80mrvovsEKwGBJzaKmEMO63gXUeFN4/2mdZ1SDAbdEyXgJLNuMR+/a6 rpog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0k24defXxQgRwTck0IlxYmfvGQHUtAiaEKSox1mH3Ek=; b=jm1gJ3LigsOYD70f3bmNACnM7MZHRTbMmSW5AiZBxD4RBmd20CRio3xyOHeLc5iBdm miPqEymf27aViOcYi6hfHNsou/gM2IvKd6xxC0nYZyH1YE3H0Y8lRAnlyihmpE2UhdQE zHHMW5houCW7gZxsEIlCTOVfnFLWDyINe49vLLqfOcdeWZCs8rU46dexnV1p1uAJEY6l YgeFhtGlpzYjPnOgX2NdhTWs5NvfkicnIwnkcQpsag33lVDIuHEHB0D/AEEwkykxwhU7 Gj0Jp7ppe53+WJkDP8INQDBBgDyaflX2bgU1KLYaQcJsigyMhIh1FPFGvimFasHvam2k b1rg== X-Gm-Message-State: AG10YOQFbuezF5B4I7/THCxUj3k631h2yKTY4MYzLydr99WTAOHSFa2pHSFViPt8nz+mcvSYFkH4KrfFFWrVtg== MIME-Version: 1.0 X-Received: by 10.31.49.23 with SMTP id x23mr34198324vkx.0.1455166946797; Wed, 10 Feb 2016 21:02:26 -0800 (PST) Received: by 10.103.65.93 with HTTP; Wed, 10 Feb 2016 21:02:26 -0800 (PST) In-Reply-To: <56BAB8C1.50809@ragged-software.com> References: <20160210033104.98651.qmail@ary.lan> <56BAB8C1.50809@ragged-software.com> Date: Wed, 10 Feb 2016 21:02:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Roy A. Gilmore" Content-Type: multipart/alternative; boundary=001a11437e36f3ed9c052b77745e Archived-At: Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:02:29 -0000 --001a11437e36f3ed9c052b77745e Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 8:12 PM, Roy A. Gilmore wrote: > While I'm aware that there are "tens of thousands of mail systems all > over the world", there are only a few SMTP implementations that are run > on all those systems. You only have to get the SMTP developers on board. > This is a trivial change (maybe not a one-liner, but, close), would > simplify there code and make it more robust. This change could easily > rolled out as a bug fix. Bug fixes are released all the time, and SHOULD > be applied ASAP. If a server administrator is still using the same > version of his/her SMTP implementation next year that he/she is using > this year, he/she is not doing his/her job and should be fired. > In an ideal world, you'd be right. But in reality, a lot of things don't get updated until there's pain happening and the only solution is to update. After trying only a few domains off the top of my head, I found a university mail server running an installation of sendmail dating back to 2006, 11 releases back from latest. If SPF is working fine as-is, there's little impetus for operators to change it. You're right that software and RFCs can be modified, but is it worth the effort to do either? What's the pain point you're trying to solve that makes this worth doing? -MSK --001a11437e36f3ed9c052b77745e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 9, 2016 at 8:12 PM, Roy A. Gilmore <r= ag@ragged-software.com> wrote:
=
While I'm awa= re that there are "tens of thousands of mail systems all
over the world", there are only a few SMTP implementations that are ru= n
on all those systems. You only have to get the SMTP developers on board. This is a trivial change (maybe not a one-liner, but, close), would
simplify there code and make it more robust. This change could easily
rolled out as a bug fix. Bug fixes are released all the time, and SHOULD be applied ASAP. If a server administrator is still using the same
version of his/her SMTP implementation next year that he/she is using
this year, he/she is not doing his/her job and should be fired.

In an ideal world, you'd be right.=C2=A0 But i= n reality, a lot of things don't get updated until there's pain hap= pening and the only solution is to update.=C2=A0 After trying only a few do= mains off the top of my head, I found a university mail server running an i= nstallation of sendmail dating back to 2006, 11 releases back from latest.<= br>
If SPF is working fine as-is, there's little impetus = for operators to change it.

You're right that softwar= e and RFCs can be modified, but is it worth the effort to do either?
What's the pain point you're trying to solve that makes= this worth doing?

-MSK
--001a11437e36f3ed9c052b77745e-- From nobody Wed Feb 10 21:26:48 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501571A8F4B for ; Wed, 10 Feb 2016 21:26:47 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fluFMCI3hgmw for ; Wed, 10 Feb 2016 21:26:45 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B111A8F45 for ; Wed, 10 Feb 2016 21:26:44 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id e6so29292867vkh.2 for ; Wed, 10 Feb 2016 21:26:44 -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=cKatrB9FoPJT6hpZcMEgRQdsut62BJyREC3RciYjMWk=; b=NII+TaGOT7oM5mYVdYimf9tlfolUr8w9mHJGOx+2a5+KyUYG+z63cDlXyFSM8R2+ND 3I2Z6bF356vmPCqo/NOO8yGjl2NSvG8mwWAOWz4t1ZkR3SBN8mnCPRa9PVqXibd1hiz8 9HeKvJs+dGhf5iF4tqSDKKFQjHC6l3my104wZhu1iWMzeoP4ZTARhcUlI/gRLhfVAJfD Li7NidOITrVFaFpLk9ti8WB2QrLkqvjyI1l0Z9ibojU1fYO6iHuCoTMj7RaWSmT5lwxg Jcsq3vy+cQA/5GCikf0yx0vqPo293vXTrE4ohsgU+ggt5Dopdh6lwbH477Kyjd+pIGPu UViw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cKatrB9FoPJT6hpZcMEgRQdsut62BJyREC3RciYjMWk=; b=RmeQkVVkiaWa3zTJV+SiB9ed2dLKwQPmfgK6/cPt6VH+F7fnFqTGXsJpRcccFrK5Zm VFjMbxKMRdWYg9JdHvdAyhcCyYfnH0Vwt2DQzdvrJsur2ojlbDBpGv4JxNg6deTc1hPQ 65aK/U58gVdZLPqN8k5cq6Guyu6JZ1TWVmsXZUruJhNGv/CecP1EK6AmmqQWNymAOKRj 6f4o2J5aCDyERnf+IGegomkFgKe/KuD6ywLgLUGt+Zgwqfsm8cZJrdsREjnnyg2HkSUD ywCvE8p43+WLHVnSyvOsFMcMwdGDTVqGh4Y3ssIYZccICn/DJlw22MocKsAEbDVs+V4B NVcA== X-Gm-Message-State: AG10YOQuOBxJzQ4nDJDRDStaqi2xLBE55sccacHJgIAYY0UfnGIS00vjXfIQVFZSP90uKHuQujhy6nbUORF7jw== MIME-Version: 1.0 X-Received: by 10.31.52.147 with SMTP id b141mr33556217vka.82.1455168403733; Wed, 10 Feb 2016 21:26:43 -0800 (PST) Received: by 10.103.72.195 with HTTP; Wed, 10 Feb 2016 21:26:43 -0800 (PST) In-Reply-To: <56BAAD71.8080009@ragged-software.com> References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> <56BAAD71.8080009@ragged-software.com> Date: Wed, 10 Feb 2016 21:26:43 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Roy A. Gilmore" Content-Type: multipart/alternative; boundary=001a1143f846cb00e1052b77cb5c Archived-At: Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 05:26:47 -0000 --001a1143f846cb00e1052b77cb5c Content-Type: text/plain; charset=UTF-8 On Tue, Feb 9, 2016 at 7:24 PM, Roy A. Gilmore wrote: > Double query? What if a single domain query returns multiple TXT > records. Section 4.5 of RFC7208 covers that. > How long will it take to process multiple free form (i.e. RFC > 1035: "The semantics of the text depends on the domain where it is > found.") TXT records to be sure you select the right one? I don't think processing time is the concern here. > Can you be > sure you selected the right one? Yes, because after discarding things that aren't SPF records, you evaluate what's left: if there's none, you get a "none" result; if one, you get the real result; if more, you get an error. > If you query for a _spf TXT record, you > know you got the right one (well, I guess in the degenerate case where > DNS has been misconfigured, you could get multiple TXT records). I don't know that wildcard TXT records constitute a "degenerate" case. > I > suppose someone could say that only one TXT record should be returned. > RFC 1035 doesn't say whether TXT is a singleton resource record or not. > But, RFC 1035 has been updated by so many RFC's and BCP's that I'm not > sure (I'll have to look into that). I know bind allows multiple TXT > records per key (I'm not sure if "key" is the correct terminology here). > Anyway, assume for a minute that only one TXT record should to be > returned, should spfbis hijack that TXT record? I don't think so. What > about all the other services that query for a service specific TXT > record, are their workgroups "wrong", and the spfbis workgroup "right"? > I'd willing to bet the other workgroups have some pretty smart people > too (probably some of the same smart people). > The rules for handling the DNS reply in RFC7208 cover all of these possibilities, I believe. They have to, given how much random stuff one finds in the domain-level TXT reply sometimes. Query for the TXT of "ut.edu", for example. And that's a bunch cleaner than what I found when I did the RFC6686 surveys. I found some that had valid SPF records mixed in with junk like that. SPF isn't making a claim to the domain level TXT record. That's just where it landed (again, see RFC6686 for the history), and it can easily coexist with other things. The spfbis archive, going back to early 2013 at least, documents the extensive discussions we had on how we got here and why we should never do it again, but fixing it now is simply not pragmatic. As to spurious interoperablity arguments, that's easy, set a transition > period where either record is acceptable with a preference for the _spf > TXT record (i.e. query for the _spf TXT record first, and fall back to > the domain TXT record if the _spf TXT record doesn't exist). Maybe, even > a "double" transition period where in the first transition period the > domain TXT record was the preferred record. POP3 didn't replace POP2 > overnight. And IMAP4 still hasn't replaced POP3 even though it has many > advantages. > Sure, transition periods could work if everyone is on board with making the change. Selling that is the challenge. What problem are you really trying to solve here? -MSK --001a1143f846cb00e1052b77cb5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 9, 2016 at 7:24 PM, Roy A. Gilmore <r= ag@ragged-software.com> wrote:
=
Double query? Wha= t if a single domain query returns multiple TXT
records.

Section 4.5 of RFC7208 covers that= .
=C2=A0
How long will it take = to process multiple free form (i.e. RFC
1035: "The semantics of the text depends on the domain where it is
found.") TXT records to be sure you select the right one?
=

I don't think processing time is the concern here.<= br>
=C2=A0
Can you be
sure you selected the right one?

Yes, becau= se after discarding things that aren't SPF records, you evaluate what&#= 39;s left: if there's none, you get a "none" result; if one, = you get the real result; if more, you get an error.
=C2=A0
If you query for a _spf TXT record, you
know you got the right one (well, I guess in the degenerate case where
DNS has been misconfigured, you could get multiple TXT records).

I don't know that wildcard TXT records constitute= a "degenerate" case.
=C2=A0
I
suppose someone could say that only one TXT record should be returned.
RFC 1035 doesn't say whether TXT is a singleton resource record or not.=
But, RFC 1035 has been updated by so many RFC's and BCP's that I= 9;m not
sure (I'll have to look into that). I know bind allows multiple TXT
records per key (I'm not sure if "key" is the correct termino= logy here).
Anyway, assume for a minute that only one TXT record should to be
returned, should spfbis hijack that TXT record? I don't think so. What<= br> about all the other services that query for a service specific TXT
record, are their workgroups "wrong", and the spfbis workgroup &q= uot;right"?
I'd willing to bet the other workgroups have some pretty smart people too (probably some of the same smart people).

The rules for handling the DNS reply in RFC7208 cover all of these p= ossibilities, I believe.=C2=A0 They have to, given how much random stuff on= e finds in the domain-level TXT reply sometimes.=C2=A0 Query for the TXT of= "ut.edu", for example.=C2=A0 And t= hat's a bunch cleaner than what I found when I did the RFC6686 surveys.= =C2=A0 I found some that had valid SPF records mixed in with junk like that= .

SPF isn't making a claim to the domain level TXT re= cord.=C2=A0 That's just where it landed (again, see RFC6686 for the his= tory), and it can easily coexist with other things.

The s= pfbis archive, going back to early 2013 at least, documents the extensive d= iscussions we had on how we got here and why we should never do it again, b= ut fixing it now is simply not pragmatic.

As to spurious interoperablity arguments, that's easy, set a transition=
period where either record is acceptable with a preference for the _spf
TXT record (i.e. query for the _spf TXT record first, and fall back to
the domain TXT record if the _spf TXT record doesn't exist). Maybe, eve= n
a "double" transition period where in the first transition period= the
domain TXT record was the preferred record. POP3 didn't replace POP2 overnight. And IMAP4 still hasn't replaced POP3 even though it has many=
advantages.

Sure, transition periods co= uld work if everyone is on board with making the change.=C2=A0 Selling that= is the challenge.

What problem are you really trying to = solve here?

-MSK
--001a1143f846cb00e1052b77cb5c-- From nobody Wed Feb 10 22:57:38 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB601A9120 for ; Wed, 10 Feb 2016 22:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdm0Nf3JKZGh for ; Wed, 10 Feb 2016 22:57:36 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372541A9124 for ; Wed, 10 Feb 2016 22:57:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id E9EC21FCB11; Thu, 11 Feb 2016 06:57:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C00F816004B; Thu, 11 Feb 2016 06:57:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AE23616005C; Thu, 11 Feb 2016 06:57:31 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JwpXpg6f8Q-1; Thu, 11 Feb 2016 06:57:31 +0000 (UTC) Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 632A816004B; Thu, 11 Feb 2016 06:57:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8775E41E14C4; Thu, 11 Feb 2016 17:57:29 +1100 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> In-reply-to: Your message of "Wed, 10 Feb 2016 20:49:21 -0800." Date: Thu, 11 Feb 2016 17:57:29 +1100 Message-Id: <20160211065729.8775E41E14C4@rock.dv.isc.org> Archived-At: Cc: "Roy A. Gilmore" , "spfbis@ietf.org" Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 06:57:37 -0000 In message , "Murray S. Kucherawy" writes: > --001a11437e362be933052b7746bc > Content-Type: text/plain; charset=UTF-8 > > On Tue, Feb 9, 2016 at 4:36 PM, Mark Andrews wrote: > > > This group won't allow the double query and will introduce spurious > > interoperablity arguments. See the history of the SPF record type > > which if the group hadn't abandoned would be well on the way to > > being done by now as they abandoned the process just as the libraries > > using the new code point were being deployed. > > > I am mystified that the bitterness on this topic remains impervious to > things like evidence. Basically because the experiment's terms of reference appeared to change. I doubt anyone in the DNS community thought it was going to be "can we migrate a established base to a new code point in a couple of years" when the experiment was "a examination of whether Sender ID or SPF was the best model". The code point being used for SPF was irrelevent to the examination of Sender ID vs SPF. The DNS community was worried about getting to the right point for the DNS in the end if SPF won the experiment. If we thought we were in a experiment to move the code point in a couple of years lots of things would have been done differently. The evidence actually showed the transition was on track. Nameservers support SPF were deployed. Libraries supporting SPF as well as TXT were being deployed. None of this is captured in RFC6686. But hey lets look at records that have been entered at the begin of what was expected to be a long transition process and declare defeat. Mark > The history of the SPF record type is documented in RFC6686. I'm happy to > let that document and the data it contains speak for itself. > > I also contend that the record shows that the working group and the > community made an informed decision. > > -MSK -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Feb 11 06:03:57 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00691B31FB for ; Thu, 11 Feb 2016 06:03:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLJkV3QSkQIN for ; Thu, 11 Feb 2016 06:03:54 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC281B31FE for ; Thu, 11 Feb 2016 06:03:52 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id k196so37064366vka.0 for ; Thu, 11 Feb 2016 06:03:52 -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=zrP9D0w2+/Lb83GjpLQMrvAbk2leH9WJzMyJrBSP6Ag=; b=upFmra6teVq8kn7MSBpzGERHgOcigpl/ivssNfqh0Txfq6eUjpcOk/MdfQH25NMjPi cF3zRTuNhdnBlkDSustw2qvNhMnezI40cVTSp4zSuonzmp8VLwI7dQ8qAUaZFBeiYQLR jy6EKpdOG+rR7kakVJ/+dBZh3oE4awf0ufPIZk398o4HFtWCGFi1FIyQrSGl9VmOjIrR J4EMPMlKpygGRFMMo2ATJlycRJBjUte1iEznusRyixrcbhArmmMPaFCtXdvhHKgpFcee oWcaYouyR0d3Q2A8WalhTJMkdggSBBHGYbfo3ZBU0NMGkfoyiDYGFOzo1mgScTAzgt26 Rj7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zrP9D0w2+/Lb83GjpLQMrvAbk2leH9WJzMyJrBSP6Ag=; b=GmycGBrixv9b58cJ7jBUdotEa+gleteuR6da6vlk+IoOnsV26rQkxKamHGZt7eFm1J 7NDzyzEUQJS54tQLP9oLh5C5tN7C5wX/E68yZe7MnhT4v5CU0kOLnGib8euSDkptNyoy UJQ5+1dJoieIgf19oouavvTN60Ix/lL7eFQijfuK77a++Z7L/6NfIjlqzU9ZqVEVJg81 bfQGhnjRSDk3683SNpaI5u1nryo09E7uPI78XAUMuz4OeHMeoqikoSjlkmbkoVJyo1Rj nUjyY6WpnRe/c/kb4o7KR2GWhJ0j3CCyrDltoNf1+3wMBQLF/QZcpG+YehY2L0DgsuVX IxVQ== X-Gm-Message-State: AG10YOQ0KAghJ8FGeYFnYBNkuRWnsAajvSjlxzxBkAdBHa+Y2o/gpSp1yDsvKmHrbYGka2yTGLh3xb+LrLw85Q== MIME-Version: 1.0 X-Received: by 10.31.52.147 with SMTP id b141mr34929340vka.82.1455199431865; Thu, 11 Feb 2016 06:03:51 -0800 (PST) Received: by 10.103.72.195 with HTTP; Thu, 11 Feb 2016 06:03:51 -0800 (PST) In-Reply-To: <20160211065729.8775E41E14C4@rock.dv.isc.org> References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> <20160211065729.8775E41E14C4@rock.dv.isc.org> Date: Thu, 11 Feb 2016 06:03:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1143f84636b958052b7f05d3 Archived-At: Cc: "Roy A. Gilmore" , "spfbis@ietf.org" Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:03:56 -0000 --001a1143f84636b958052b7f05d3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 10, 2016 at 10:57 PM, Mark Andrews wrote: > The evidence actually showed the transition was on track. After six years, it didn't appear to the working group that a transition of any kind was actually happening. > Nameservers support SPF were deployed. I thought it was pretty clear that this wasn't the problem. The major obstacles were poor provisioning systems and faulty firewalls (as you pointed out, and as the experiments we did suggested). The problem is that they are widespread, and that's unlikely to change. Libraries supporting SPF as well as TXT were being deployed. We specifically looked for this (especially the "being deployed" part) when preparing RFC6686, and found no evidence of it. Exactly one source of type 99 queries was identified. So, although there existed software support, nobody was using it. We asked around, and nobody was planning to use it, either; many operators didn't even know what we were talking about. > None of this is captured in RFC6686. Because it wasn't supported by evidence. If we had seen data to the contrary, we'd have written a different report. -MSK --001a1143f84636b958052b7f05d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 10, 2016 at 10:57 PM, Mark Andrews <marka@isc.o= rg> wrote:
The evidence actually showed the tran= sition was on track.=C2=A0

After six years= , it didn't appear to the working group that a transition of any kind w= as actually happening.
=C2=A0
Na= meservers support SPF were deployed.

I thou= ght it was pretty clear that this wasn't the problem.=C2=A0 The major o= bstacles were poor provisioning systems and faulty firewalls (as you pointe= d out, and as the experiments we did suggested).=C2=A0 The problem is that = they are widespread, and that's unlikely to change.

Libraries supporting SPF as well as TXT were being= deployed.
We specifically looked for this (especially the = "being deployed" part) when preparing RFC6686, and found no evide= nce of it.=C2=A0 Exactly one source of type 99 queries was identified.=C2= =A0 So, although there existed software support, nobody was using it.=C2=A0= We asked around, and nobody was planning to use it, either; many operators= didn't even know what we were talking about.
=C2=A0
None of this is = captured in RFC6686.

Because it wasn't = supported by evidence.=C2=A0 If we had seen data to the contrary, we'd = have written a different report.

-MSK
--001a1143f84636b958052b7f05d3-- From nobody Thu Feb 11 06:30:34 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098241B325B for ; Thu, 11 Feb 2016 06:30: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5YmE4b9Vi5m for ; Thu, 11 Feb 2016 06:30:29 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CB41B3265 for ; Thu, 11 Feb 2016 06:30:26 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e6so37470916vkh.2 for ; Thu, 11 Feb 2016 06:30:26 -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=pbFQ0U3sX25jvhWiOG/blAGllc+qESsym7X26krCl1k=; b=jgQ2iyA491HWkn52fVBNTasCj83wsyqGeCjs1TzL2zdw0ZaBw5oyYjojMTSJe7Kplo NHmJoJbp+pEK+WmLM3ftHTFVMnvCCV2RmETkMKIPpRMZaTAQ88FF1kF/Kn3vIX0LStyK a0CyOV30vV5gArANaPPofM+5SEtpYLYcTz8hTwHQ2I/uc/8JaCPACoN0KnREKzB+ISmu nFw667MB1cue7EOGd8HnSCiFKy4qYyZ7bg3C9v6Vzwgt5ZRtIQYy3DMRFmIFMJC0oTsK EiDwJXYgGWJhjEAEVAdFaYKitZfYwt0xL94BH/GAHlrdfQdiwXg3y8c4Ryi5m6h9MHb4 HOwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pbFQ0U3sX25jvhWiOG/blAGllc+qESsym7X26krCl1k=; b=SQ3FVxg1pc9WiTrciuE+GuUDeAL/nE2xdN9iAUED0n/Bs0jiRte3mX/pymCA7ncubI gTziX5Di7jdY4H9Fv2w1ocEohfYJD3FBthw/gF+ThbSsmQQ3MuIxRGmU13VH+JXoddlv NfGk1Pf0QYihA9A47MhJF38L/jCeGhp3dTou92a0nqEn44T76QkmGYAp1UZSA/DCMytt K/ykOIZpz+JM2LgVOjcrGGZoAaE+5MDDkpAbjWLifMY0ncXu9xDNcoSrLgUys8/mnF+I bTwnvJhuh4FsmB2ApPhZsF6ZAxBF6MuRAQte2P7oy7/mWenx0CfIWZeNMHWUA/25eMWv nAzQ== X-Gm-Message-State: AG10YOTamN9nApspN6vGDujVPSkvfSH9lp4n8BRuU/ZL0x7o/io4mpLmKv/aCeq8Qezlwt5iI4mHrkHf6ONyaw== MIME-Version: 1.0 X-Received: by 10.31.162.20 with SMTP id l20mr31834230vke.137.1455201025228; Thu, 11 Feb 2016 06:30:25 -0800 (PST) Received: by 10.103.32.194 with HTTP; Thu, 11 Feb 2016 06:30:25 -0800 (PST) In-Reply-To: References: <56BA775B.9050109@ragged-software.com> <20160210003605.9A90F41C28F6@rock.dv.isc.org> <20160211065729.8775E41E14C4@rock.dv.isc.org> Date: Thu, 11 Feb 2016 09:30:25 -0500 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1143f2ac2f8a50052b7f642c Archived-At: Cc: "Roy A. Gilmore" , "spfbis@ietf.org" , Mark Andrews Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:30:34 -0000 --001a1143f2ac2f8a50052b7f642c Content-Type: text/plain; charset=UTF-8 On Thu, Feb 11, 2016 at 9:03 AM, Murray S. Kucherawy wrote: > On Wed, Feb 10, 2016 at 10:57 PM, Mark Andrews wrote: > >> The evidence actually showed the transition was on track. > > > After six years, it didn't appear to the working group that a transition > of any kind was actually happening. > To reinforce Murray's comment, there was quite a bit of discussion in the working group before the consensus to drop support for type 99. And there was incredibly little implementation in the wild after ~6 years. > > >> Nameservers support SPF were deployed. > > > I thought it was pretty clear that this wasn't the problem. The major > obstacles were poor provisioning systems and faulty firewalls (as you > pointed out, and as the experiments we did suggested). The problem is that > they are widespread, and that's unlikely to change. > > Libraries supporting SPF as well as TXT were being deployed. > > > We specifically looked for this (especially the "being deployed" part) > when preparing RFC6686, and found no evidence of it. Exactly one source of > type 99 queries was identified. So, although there existed software > support, nobody was using it. We asked around, and nobody was planning to > use it, either; many operators didn't even know what we were talking about. > > >> None of this is captured in RFC6686. > > > Because it wasn't supported by evidence. If we had seen data to the > contrary, we'd have written a different report. > It was captured in the working group discussions and the data that was brought back to the working group clearly showed non significant implementation in the wild. Mike --001a1143f2ac2f8a50052b7f642c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 11, 2016 at 9:03 AM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Wed, Feb 10, 2016 at 10:57 PM, Mark Andrews <marka@isc= .org> wrote:
The evid= ence actually showed the transition was on track.=C2=A0
<= br>
After six years, it didn't appear to the working g= roup that a transition of any kind was actually happening.
<= /div>

To reinforce Murray's comme= nt, there was quite a bit of discussion in the working group before the con= sensus to drop support for type 99. And there was incredibly little impleme= ntation in the wild after ~6 years.
=C2=A0
Nameserv= ers support SPF were deployed.

I tho= ught it was pretty clear that this wasn't the problem.=C2=A0 The major = obstacles were poor provisioning systems and faulty firewalls (as you point= ed out, and as the experiments we did suggested).=C2=A0 The problem is that= they are widespread, and that's unlikely to change.

Libraries supporting SPF as well= as TXT were being deployed.

We specifically looked = for this (especially the "being deployed" part) when preparing RF= C6686, and found no evidence of it.=C2=A0 Exactly one source of type 99 que= ries was identified.=C2=A0 So, although there existed software support, nob= ody was using it.=C2=A0 We asked around, and nobody was planning to use it,= either; many operators didn't even know what we were talking about.
=C2=A0
None of this is captured in RFC6686.

Because it wasn't supported by evidence.=C2=A0= If we had seen data to the contrary, we'd have written a different rep= ort.
=

It was captured in the w= orking group discussions and the data that was brought back to the working = group clearly showed non significant implementation in the wild.

Mike
=C2=A0
--001a1143f2ac2f8a50052b7f642c-- From nobody Thu Feb 11 07:57:12 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4811B33CB for ; Thu, 11 Feb 2016 07:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjAMNSGRQOAC for ; Thu, 11 Feb 2016 07:57:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C921B33DC for ; Thu, 11 Feb 2016 07:57:08 -0800 (PST) Received: (qmail 82833 invoked from network); 11 Feb 2016 15:57:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Feb 2016 15:57:02 -0000 Date: 11 Feb 2016 15:56:40 -0000 Message-ID: <20160211155640.5340.qmail@ary.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 15:57:10 -0000 >I am mystified that the bitterness on this topic remains impervious to >things like evidence. > >The history of the SPF record type is documented in RFC6686. I'm happy to >let that document and the data it contains speak for itself. There is a belief in parts of the DNS community that adding new RRTYPEs is trivially easy. Provisioning system problems don't matter either because they don't exist, or because any zone file of any importance is created with vi. A decade ago when 4408 was published, the belief was pervasive enough that its adherents demanded that the SPF record be added at the last minute or the draft wouldn't be published, and it was added so quickly that the language was botched and describes implementations that don't interoperate. Since all existing SPF implementations already used TXT records, and type 99 SPF records involved considerable pain and no operational benefit (I know about having the server automatically add the SPF records, my provisioning system did it), it's not surprising that nobody used them. And since that experience showed a treasured belief to be wrong, well, the reactions are not surprising. R's, John From nobody Thu Feb 11 13:50:50 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED90B1B3AF0 for ; Thu, 11 Feb 2016 13:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucANWy1xnH-D for ; Thu, 11 Feb 2016 13:50:41 -0800 (PST) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B7EB21B3A65 for ; Thu, 11 Feb 2016 13:50:40 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=608; t=1455227431; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=0JyxjzBFeYAhVruCLxC28egaCaQ=; b=aIPZNpcJAgHbaE8MFm6mXRMgDcBwZ33BGGjlEoMkjPYF9RNun/O5kS/fPvvC8m Dl77TyGsKbLftPWWoY8GEmXXw/KZId2rtNMYCKGRwuibENE0lZMMGVMr5L2V9+IA IFuWgQ19qMhoNRPs7Z30ftxdrsIYz/aIOQJt6HVKv6Be4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for spfbis@ietf.org; Thu, 11 Feb 2016 16:50:31 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3386587406.1.3844; Thu, 11 Feb 2016 16:50:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=608; t=1455227357; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kuIh6Ba 5IhTGKTFnUq0UwxV5Xe8wbvOE8jTMu0wMoGI=; b=NinK4rzWB3qoHjOB/kPoBg9 aB7jJGe+H0WW28YV1yoesrvOoHPjZf70mPwQfoO9a0OE1gMhDJfEvChyR7rBd+e6 ENYqdFgRxsHzRWa5do5L7O7THuj7Ckq9Jua62BGmMkU3Roxy/C3uA5Xz6q5LiR+5 FnXdmKD5bb4srBbFjMgU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for spfbis@ietf.org; Thu, 11 Feb 2016 16:49:17 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3386641890.9.36480; Thu, 11 Feb 2016 16:49:17 -0500 Message-ID: <56BD0217.9040506@isdg.net> Date: Thu, 11 Feb 2016 16:50:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Mark Andrews , dcrocker@bbiw.net References: <20160210022525.98482.qmail@ary.lan> <56BABD0C.8070504@dcrocker.net> <20160210050940.58CBD41C61C4@rock.dv.isc.org> In-Reply-To: <20160210050940.58CBD41C61C4@rock.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: spfbis@ietf.org, rag@ragged-software.com, John Levine Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 21:50:46 -0000 On 2/10/2016 12:09 AM, Mark Andrews wrote: > > In message <56BABD0C.8070504@dcrocker.net>, Dave Crocker writes: >> >> >> On 2/9/2016 6:25 PM, John Levine wrote: >>>> I think the spf information should be placed in a TXT record >>>> attached to a _spf selector (e.g. _spf.example.com). >>> >>> You're right, but you're also a decade too late. Forget it. >> >> >> +1 > > -100000 _spf was never right. +100000. Its all wasted wasted overhead especially when relaxed policies (with no hard rejection capabilities). If you are going to do this, please make it for hard policies. -- HLS From nobody Thu Feb 11 15:43:01 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8331B3C8D for ; Thu, 11 Feb 2016 15:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaUafYDMBb6S for ; Thu, 11 Feb 2016 15:42:55 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B901B3C7E for ; Thu, 11 Feb 2016 15:42:55 -0800 (PST) Received: from [10.58.168.93] (unknown [166.170.28.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2C3CDC40159 for ; Thu, 11 Feb 2016 17:42:54 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1455234174; bh=s7UWOWTxWI4HYCoUnehDS5LrM3w+PxFnmmoDY9wmJ90=; h=In-Reply-To:References:Subject:From:Date:To:From; b=rLDinXH/zq/dDODDZgeviDo+RqAdmCtVGNMIgAWdIc1yGeB1D3cyMauYoqgdlweK5 WcvRnRzj8X9k3+zH0W85I678YXcWhi9VDjkR+XYsdF3OSjp0RJE3l5DIVBdCgjDA/V IfwWMLcmfDPPgtkj59K7e659QUzKWkTfAiZr1BLk= User-Agent: K-9 Mail for Android In-Reply-To: References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 11 Feb 2016 18:42:48 -0500 To: spfbis@ietf.org Message-ID: Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:43:00 -0000 On February 10, 2016 2:32:50 PM EST, "Stuart D. Gathman" wrote: >On Tue, 9 Feb 2016, Roy A. Gilmore wrote: > >> Why should it matter if I'm a decade too late? If I'm right (and I'm >not >> saying that I am), why shouldn't the behavior be changed. RFC's >aren't >> set in stone, they are updated and/or obsoleted all the time. This >> proposed change is trivial to implement. > >As a pyspf developer, the _spf idea is *not* trivial to implement. >The SPF RR is trivial to implement. The problem was braindead DNS >servers. > >I still publish both SPF and TXT records (no SPF police are stopping >me). I still have the type99 code in my SPF implementation. >Type99 is only deprecated. If you can convince DNS server providers >to operate correctly for unknown RR types (or failing that, to >recognize SPF RR), and convince lots of people to publish both, >then a switch could be reconsidered. Especially if there is a new >backward incompatible SPF version. I think a backward incompatible update is exactly the right time to reintroduce use of the SPF RR. I think I can even describe much of what an update should contain: - Combine a:, ip4:, and ip6: into a single mechanism (in retrospect there was no need to make them separate and combining would simplify things) - Drop the PTR mechanism entirely - Drop (or possibly radically simplify macros) I personally doubt it would get a lot of deployment, but that kind of incompatible update is what the SPF RR type should be used for. In any case, I think the new RR type is a better idea than _spf. Scott K From nobody Fri Feb 12 02:16:55 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4131B42D2 for ; Fri, 12 Feb 2016 02:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwg64rNOQCca for ; Fri, 12 Feb 2016 02:16:52 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1421B42D3 for ; Fri, 12 Feb 2016 02:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1455272207; bh=RYV3W0igBero/950l+WCY7swHJrN6kcOO3tf440Vgv8=; l=1883; h=To:References:From:Date:In-Reply-To; b=H+QCu/J0us34B807PrYKv8JWbF2XNJxnopNQ9uLpMgbU/G2dn7BjoI6XFNJ7CGP6s xlgyA9+XtG3H2pkazWZPOo8qStXzk7xTl5ejVY519iDqv0EFeImFBzgzvNSEkuT2cE W4CNXy6fFi+OjA8JnJvTbtM0FPASSkUFleJq+R2Q= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 12 Feb 2016 11:16:47 +0100 id 00000000005DC050.0000000056BDB10F.0000269F To: spfbis@ietf.org References: <20160210022525.98482.qmail@ary.lan> <56BAB3D8.8060607@ragged-software.com> From: Alessandro Vesely Message-ID: <56BDB10F.4070701@tana.it> Date: Fri, 12 Feb 2016 11:16:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spfbis] Proposed spf TXT record change X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 10:16:54 -0000 On Fri 12/Feb/2016 00:42:48 +0100 Scott Kitterman wrote: > On February 10, 2016 2:32:50 PM EST, "Stuart D. Gathman" wrote: >> On Tue, 9 Feb 2016, Roy A. Gilmore wrote: >> >>> Why should it matter if I'm a decade too late? If I'm right (and I'm >>> not saying that I am), why shouldn't the behavior be changed. >> >> As a pyspf developer, the _spf idea is *not* trivial to implement. The SPF >> RR is trivial to implement. >> >> If you can convince DNS server providers to operate correctly for unknown >> RR types (or failing that, to recognize SPF RR), and convince lots of >> people to publish both, then a switch could be reconsidered. Especially >> if there is a new backward incompatible SPF version. > > I think a backward incompatible update is exactly the right time to > reintroduce use of the SPF RR. I think I can even describe much of what an > update should contain: > > - Combine a:, ip4:, and ip6: into a single mechanism (in retrospect there > was no need to make them separate and combining would simplify things) > > - Drop the PTR mechanism entirely > > - Drop (or possibly radically simplify macros) Those considerations don't have to be simultaneously valid for both the binary on-the-wire format and the format used for declarations. Records could be compiled from high level directives. > I personally doubt it would get a lot of deployment, but that kind of > incompatible update is what the SPF RR type should be used for. Whenever such an incompatible update will be needed, that is. Paraphrasing Roy, why should it matter if it will not arise within a decade? > In any case, I think the new RR type is a better idea than _spf. One doesn't preclude another. Possibly related to _spf, looking up helo records by administrative domain --à la DMARC-- would greatly simplify deployment. Ale