From SRS0=fNnQE=Q3==stuart@gathman.org Sun May 1 18:24:33 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFA812B042 for ; Sun, 1 May 2016 18:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org 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 fNYaTfiAWVFW for ; Sun, 1 May 2016 18:24:32 -0700 (PDT) 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 73A5412B015 for ; Sun, 1 May 2016 18:24:32 -0700 (PDT) Authentication-Results: mail.gathman.org; iprev=pass policy.iprev="2001:470:8:809:11::1009" (elissa.gathman.org); auth=pass (PLAIN sslbits=128) 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=1462152269; h=Subject : To : References : From : Message-ID : Date : MIME-Version : In-Reply-To : Content-Type : Content-Transfer-Encoding : Subject : From : Date; bh=QK4GXjkPadYUzd+/1YdJqHE1etlEgjgCJNLwgN1nkEY=; b=dejWDilQtewMcctAXxH2nFHMBvIRVux9JTP6hj4sxPT3WAp5Cpz1sSXCHj4Kd4iv+lS8xO 1x+q2hepHo40TaMNq8MDQZQhWfMwhqwIdY88yXWuKARHTvXVI/obcoUosB4b5n3k805kcNhC +lVEOWHQH9e2TOujaGYtSFFIrD7AI= Received: from elissa.gathman.org (elissa.gathman.org [IPv6:2001:470:8:809:11::1009]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u421ON12031462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 1 May 2016 21:24:29 -0400 To: spfbis@ietf.org References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> From: Stuart Gathman Organization: Gathman Systems Jabber-Id: stuart@gathman.org Message-ID: <5726AC48.7090306@gathman.org> Date: Sun, 1 May 2016 21:24:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <255DF248-2870-4727-9F10-259598592509@kitterman.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:23:34 -0000 On 04/30/2016 09:08 PM, Scott Kitterman wrote: > I think they are just wrong. If either an IPv4 or IPv6 address is retu= rned it's not a void look up. That's described at the end of 4.6.4 and i= s, I think clear. I'd report it as a bug. If the connection is an IPv6 connection, then only AAAA RRs are queried (because an A RR could never match). If the domain has only A RRs, then the AAAA queries will have empty results. This seems to be indistinguishable from a non-existent domain. This is the problem the OP is complaining about. This means that pyspf, on detecting 2 "void" lookups for an AAAA, would then have to make at least 2 additional useless queries for the A record type to see if the lookups were actually "void" according to your interpretation. Since I think your interpretation is somewhat reasonable, this *could* be an errata.=20 But I don't think so. This is actually a case of "doctor, doctor, it hurts when I do this!" Don't use an mx mechanism with A only names when valid connections can come in via IPv6. Or at least, make it the *last* mechanism as recommended. I can't think of any good reason to tweak or "clarify" the spec to enable this kind of SPF record. From nobody Sun May 1 19:33:12 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1012B018 for ; Sun, 1 May 2016 19:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 AjU-sMbcEIVC for ; Sun, 1 May 2016 19:33:09 -0700 (PDT) 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 1D8BC12B014 for ; Sun, 1 May 2016 19:33:09 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A3141C40152 for ; Sun, 1 May 2016 21:33:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462156387; bh=D0+Xxrs5sVv9U95S5uq0/ATJDu0kYL77JrjOsOMldqc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Yz0P/a6XACA3VVpOqYVzLW8qqpcR4PevVXiKF93inlWxC0BgiEFN4/4aYli8O7pEX yOkteL+LZQhJ9OrQFWApyyMAMBTKSMsc13MkQSfOVj63IW2fdGRnjiDIopdWPo5lNf zb7ufcG1v5xoiahAykk9rI9UvdOSWosNF1CHRG2w= From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 01 May 2016 22:33:06 -0400 Message-ID: <5060996.Nvmh582kyi@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5726AC48.7090306@gathman.org> References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> <5726AC48.7090306@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:33:11 -0000 On Sunday, May 01, 2016 09:24:24 PM Stuart Gathman wrote: > On 04/30/2016 09:08 PM, Scott Kitterman wrote: > > I think they are just wrong. If either an IPv4 or IPv6 address is > > returned it's not a void look up. That's described at the end of 4.6.4 > > and is, I think clear. I'd report it as a bug. > If the connection is an IPv6 connection, then only AAAA RRs are queried > (because an A RR could never match). If the domain has only A RRs, then > the AAAA queries will have empty results. This seems to be > indistinguishable from a non-existent domain. This is the problem the > OP is complaining about. > > This means that pyspf, on detecting 2 "void" lookups for an AAAA, would > then have to make at least 2 additional useless queries for the A record > type to see if the lookups were actually "void" according to your > interpretation. Since I think your interpretation is somewhat > reasonable, this *could* be an errata. > > But I don't think so. This is actually a case of "doctor, doctor, it > hurts when I do this!" Don't use an mx mechanism with A only names when > valid connections can come in via IPv6. Or at least, make it the > *last* mechanism as recommended. I can't think of any good reason to > tweak or "clarify" the spec to enable this kind of SPF record. I think it might make sense that to clarify that an mx mechanism is only void if neither A nor AAAA exist. Implementations could either do the extra lookup or just not count it as void if only looking up one. From an interoperability perspective, I think either would be fine. Scott K From nobody Sun May 1 19:43:43 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6DB12D18E for ; Sun, 1 May 2016 19:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org 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 ktFi_v3QMx5E for ; Sun, 1 May 2016 19:43:40 -0700 (PDT) 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 6D19A12D166 for ; Sun, 1 May 2016 19:43:40 -0700 (PDT) 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=1462157018; h=Date : From : To : cc : Subject : In-Reply-To : Message-ID : References : MIME-Version : Content-Type : Date : From : Subject; bh=yNiQWdvFjSiCWzjpHMS+/h/esP8gIm8kLmXxHy4QQik=; b=EGSyhYrp9ORFRFBUM4g9DuIn7Hn0Ost9cIW9AAyh5INi+SN7pyyAdAwShDQs2qLaW3fVKi jxVktgSUws7SMl/Ru/sfBAWJFeLM7keU8kM/8VEh1MfnvgNXaANzia7/fZAVGRbEjWu8/X71 c8N1jj7vwkgqHZmNhdwZZAKSLIq9M= 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 u422hX9O031626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 May 2016 22:43:37 -0400 Date: Sun, 1 May 2016 22:43:33 -0400 (EDT) From: "Stuart D. Gathman" To: Scott Kitterman In-Reply-To: <5060996.Nvmh582kyi@kitterma-e6430> Message-ID: References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> <5726AC48.7090306@gathman.org> <5060996.Nvmh582kyi@kitterma-e6430> 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] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:43:42 -0000 Implementations will *always* lookup only one of A/AAAA - the type matching the connect IP. So taking your second option would mean that A,MX mechanisms would never be void! On Sun, 1 May 2016, Scott Kitterman wrote: > I think it might make sense that to clarify that an mx mechanism is only void > if neither A nor AAAA exist. Implementations could either do the extra lookup > or just not count it as void if only looking up one. From an interoperability > perspective, I think either would be fine. -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. From nobody Sun May 1 19:55:40 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0812D0B0 for ; Sun, 1 May 2016 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 WSbWQFRgDTT0 for ; Sun, 1 May 2016 19:55:37 -0700 (PDT) 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 4274712D0A6 for ; Sun, 1 May 2016 19:55:37 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5A1EEC40152 for ; Sun, 1 May 2016 21:55:36 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462157736; bh=/1W5kKV42sjkUgpHeiSpIGfgEQ7IYXqXaMCS/BJziYs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ax+5UxQdLL0/AQ75PZOfiCGq8VL4EBuJIkPxD1H+RstO5imrlLNZLsr59G3j41JDh 5S/PHIoXDgMBpP1IbuAhiGGlJxNja/TzIg/U1F5yTSjfqCOZPcsW4FRcBmG4fKwLS/ iDvc8jdRBu03fBWoMcrGC6SylznjK6i1mlzRuMJs= From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 01 May 2016 22:55:35 -0400 Message-ID: <6348765.abvlTfSS9j@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <002101d1a342$c93e3000$5bba9000$@iname.com> <5060996.Nvmh582kyi@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:55:38 -0000 While I believe your assessment of the type of records that do this is correct (mx would have been next on my list to deprecate after ptr if I thought we could have pulled it off), I think it's only technically correct to count an mx as void if you've checked both (and that's what RFC 7208 already says). We may want to make that clearer, but changing it so that only A or AAAA missing counts as void would be a technical change that has interoperability risks. I don't think we should do it. Scott K On Sunday, May 01, 2016 10:43:33 PM Stuart D. Gathman wrote: > Implementations will *always* lookup only one of A/AAAA - the type > matching the connect IP. So taking your second option would mean that > A,MX mechanisms would never be void! > > On Sun, 1 May 2016, Scott Kitterman wrote: > > I think it might make sense that to clarify that an mx mechanism is only > > void if neither A nor AAAA exist. Implementations could either do the > > extra lookup or just not count it as void if only looking up one. From > > an interoperability perspective, I think either would be fine. From nobody Sun May 1 20:31:59 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFB012D137 for ; Sun, 1 May 2016 20:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9r3VPSRA8SVy for ; Sun, 1 May 2016 20:31:56 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C7212D0C1 for ; Sun, 1 May 2016 20:31:56 -0700 (PDT) Received: from FRANKB ([199.120.69.4]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MgtFu-1bJ1K00vYm-00M4OG; Mon, 02 May 2016 05:31:48 +0200 From: To: "'Stuart D. Gathman'" , "Scott Kitterman" References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> <5726AC48.7090306@gathman.org> <5060996.Nvmh582kyi@kitterma-e6430> In-Reply-To: Date: Sun, 1 May 2016 22:31:46 -0500 Message-ID: <000b01d1a423$288cc5e0$79a651a0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGjQUiwgr7sDCPlS+CRYh0ldjGGZQALqVMAADLVyAAAAmY6AAAAXW6AAAk6QTA= Content-Language: en-us X-Provags-ID: V03:K0:mqpUUMi81YPnLxLzxS7E5J3y4IdvNlvgN68JCh/I18jqGzXvs6B 3cHhl36l/DPySakU/j+ktj2NuvnvDbmHaUjlWreoGNnPz4fyu4pnJZpz1d976F10cBoN8Ei VXQJbeHWjDv5/sZl3EylNyi67Y23ccx7FjwPVgbDMyCzrse0NW/sArZ7/vBysh0zEndrPYe Bw1vuvtUIO3BPVN90ndZw== X-UI-Out-Filterresults: notjunk:1;V01:K0:K6yaQvHn7HM=:tFznQFIMjWFpf9S6iQr50C o8lTUDmvENQcyXhT2+TbHlhYHVko5UQkbXtE/wURHGuRXsuNt+/XEBxRZUIafwrwTCshoIuH/ o5C1DPudNNxg3PhLj1x79Mxd+vTSvt5+6ADW/1BwHVssjIfYINXJB9icCGZEDowkfTMm3sJwp CyjtOFeR55mX345Kq4YzLCD0waS2O/+wnuI2vjtKp0cAh9ELAYM365jSnJKJz9EdZvdSwYGcO WzAHrZxd1luGMhmmRZjln+KqIdqGsyx8Peg8c2Mnf+jfMVUE5Hg+nxuW7+8hGCeallQ1eSYeq N2OMbmx4TMMJh0LP2EyyP1pH8FTeTct++OfUseNC8wsjTOj464QFHPALCqlDo3t3Q8F8L4ImL wlAClF+nuIU3L+S2KEGlPvywkx/yjhPXosI+MBbBEdx7aDtbwt+k01LFBZWtS874zgdkja3Qn cTbkwKmLt+gf6BiytjDg3AdpXtBeer6MLNcLKT/gUsnqyniRFWh0apGUKiZvs+vZVaG0jqZie bWQrt3Dhu4EFJmles1b3AKQPvGCdpUtTEn1gMT2jPifYDb/cCpALjYmax8nd/2zzQGq26+blb 5Fzd8+db1vn63SL38Vn9eANsmfvWdhf75zquwPWe5iPDgDbU8HuvUt3ochUVDm6FIfJKYCdkn NF2TolPJSYdB/u+N0X8C7lbXsSgRx7rGloiw8qJj3dgUVX/3HlPCW7zrCbWtFIE8qsxeyUdd8 fqae5fWKBnmm+PukMypC3laQc2PGKFOm4J1tRDXBYJR8IlcR4LgUSBh6GNv2iq6++wzWsh3lK xxexYLi Archived-At: Cc: spfbis@ietf.org Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: frnkblk@iname.com List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 03:31:58 -0000 If I connect over IPv6 and the SPF record has 'mx' in it, that should not result in failure just because there are no AAAA's for any of the MX records. Just because a domain has valid IPv6 senders that does not mean it can accept email over IPv6. Or that one can only use SPF if IP address versions for sender and receiver are in the same family. Sending IPv6 connectivity should not dictate that any of the MX records have an AAAA, and Sending IPv4 connectivity should not dictate that any of the MX records have an A. Doing so is requiring more than what SPF means to accomplish. I don't know if I'm saying it right, but I'd like to see it clarified that when an 'mx' is evaluated that failure to obtain an A or AAAA should not impact the void lookup count. If that's unacceptable, then perhaps mx should be deprecated, or it should be augmented with mx4 or mx6 to avoid void lookup counts. Frank -----Original Message----- From: spfbis [mailto:spfbis-bounces@ietf.org] On Behalf Of Stuart D. Gathman Sent: Sunday, May 01, 2016 9:44 PM To: Scott Kitterman Cc: spfbis@ietf.org Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 Implementations will *always* lookup only one of A/AAAA - the type matching the connect IP. So taking your second option would mean that A,MX mechanisms would never be void! On Sun, 1 May 2016, Scott Kitterman wrote: > I think it might make sense that to clarify that an mx mechanism is only void > if neither A nor AAAA exist. Implementations could either do the extra lookup > or just not count it as void if only looking up one. From an interoperability > perspective, I think either would be fine. -- Stuart D. Gathman "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial. _______________________________________________ spfbis mailing list spfbis@ietf.org https://www.ietf.org/mailman/listinfo/spfbis From nobody Mon May 2 01:01:08 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AED12D0F5 for ; Mon, 2 May 2016 01:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=vDcmKLt+; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=yWTSUrMc 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 dhq0ZLizegqD for ; Mon, 2 May 2016 01:00:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C165712D0CF for ; Mon, 2 May 2016 01:00:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.55.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u4280jMa016884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 01:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1462176056; x=1462262456; bh=2q+ZeaIiChxzZQbEJJelyaBnZoIvNyjsALjUy4g40BM=; h=Date:To:From:Subject:In-Reply-To:References; b=vDcmKLt+uUpMXKKj7wcYfMw4LcKjS4nlHY85xHAgxKUApqH4Or4B2U+onF4KppOb/ YG88S524LML2vNyucpZptj/hNof/Ev9L+rhd9OUenY54E3nE0WHtNsGe6xnDSPeJFr hNngi/tU6x+gh0NLDyTqH1zN8cXzbQJQ6ORFmgW4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1462176056; x=1462262456; i=@elandsys.com; bh=2q+ZeaIiChxzZQbEJJelyaBnZoIvNyjsALjUy4g40BM=; h=Date:To:From:Subject:In-Reply-To:References; b=yWTSUrMca8yR/AVDZo/hN/e3fhOUIVNiuIrMEYeTm6rwNvCqKh5ULFUvgbZ1td8/S +IHI9wzG0tJkwBMEMmpBzxmZEw1sVNUC2DL+bd8K7SP05spf4zOyyPtvav8VBUPwPo bhGUsmxLt3XKZ+uX7v69xkBGXate//7juKZOPj1A= Message-Id: <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 May 2016 00:58:55 -0700 To: Frank Bulk , spfbis@ietf.org From: S Moonesamy In-Reply-To: <002101d1a342$c93e3000$5bba9000$@iname.com> References: <002101d1a342$c93e3000$5bba9000$@iname.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 08:01:07 -0000 Hi Frank, At 17:45 30-04-2016, Frank Bulk wrote: >While working through a SPF failure for a message sent from our IPv6-capable >email server (for premieronline.net), I ran an across an SPF checker >(http://vamsoft.com/support/tools/spf-policy-tester) that had a hard fail >when these values were entered: > 2607:fe28:0:4000::20 > fbulk@premieronline.net > >premieronline.net's record is as follow: > v=spf1 mx ip4:96.31.0.0/24 ip6:2607:fe28:0:1000::/64 >ip6:2607:fe28:0:4000::/64 ~all > >The tool tries to work through the MX records of premieronline.net, but for >some reason it specifically queries for an AAAA for each MX record, of which >we don't have one (because our inbound email gateway does not yet support >IPv6). Since we have four MX records, it work through two of them (which >both fail) and then the tool hard fails saying that, > "The maximum void DNS lookup limit of 2 has been exceeded during the >evaluation (see RFC7208 Section 4.6.4.)." There is the following in Section 5 of RFC 7208: 'When any mechanism fetches host addresses to compare with , when is an IPv4, "A" records are fetched; when is an IPv6 address, "AAAA" records are fetched. SPF implementations on IPv6 servers need to handle both "AAAA" and "A" records, for clients on IPv4-mapped IPv6 addresses [RFC4291]. IPv4 addresses are only listed in an SPF record using the "ip4" mechanism.' It does not make sense to query for an "A" record when the client address is an IPv6 address. The issue in your case is that your outbound is over IPv6 while you do not have inbound IPv6. I took a quick look and I did not find a discussion about that in relation to the void DNS lookup limit in the mailing list archive. >This is the only SPF tool to fail in this way, which makes we wonder if it's >the site's SPF checking methodology for RFC 7208 section 5.4 is correct. If >so, and other email gateways have implemented their SPF checking in the same >way, there could be more incorrect SPF evaluation checks out there. If the >site's SPF checking methodology is incorrect, can you point me to a section >in any RFC that would suggest a better/proper approach? I didn't find any text in the RFC about a better or proper approach. >Either way, does RFC 7208 need some clarification on this matter? My guess >is that "it performs an address lookup on each MX name" is not equivalent to >"check for an AAAA on each MX name and check for an A on each MX name", but >I'm not sure. Your question is about whether there is a "bug" in the technical specification. The second sentence is about how to get around a "void DNS lookup". At the moment I am not sure about what would be the appropriate answer. Regards, S. Moonesamy From nobody Mon May 2 08:56:26 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC27212D0C2 for ; Mon, 2 May 2016 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 HOsDyyexy99g for ; Mon, 2 May 2016 08:56:18 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 BBC0D12B038 for ; Mon, 2 May 2016 08:56:18 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id f89so171617953ioi.0 for ; Mon, 02 May 2016 08:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cASn+w7umGLuoA0FoJl4AaKlnLhYCCg071O/tBUuEYE=; b=NAiFnBJSVbJHgEEwuTzr4H0fdfoGE1H0tMeiXjGRSWDz7/FNkovE6L+8RRtvLDgfKV VIwiA851vppkb6VYiHCNsxt71nyF1WZgjBhnVN1iqYO9BbZuh1lMANaoXF2HC9IaHFzL 7zpp2SmEwVRNqrNBzOEchvPrpnvuZk3fi9kQg= 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; bh=cASn+w7umGLuoA0FoJl4AaKlnLhYCCg071O/tBUuEYE=; b=RQWzH3RV20ZJJ2CxLC6N7aLUVPkomz0Cu72eaRbpWa9VX9+tBLk3Xkv2Lp+BBeTQdP QtvOcOhEK6eGJc/0yUbjYbtKe8HRzNiOwsRdk3U2tX2nMvxjVmwNFXXIirWYUsqqWh2r sggiapcm6+0Begjz21L42vqGViD2yoUXvGhXWRGJgdHSrCUvGAy0B/l+9HvIHZdgMQhD /P9MlTGJdca840QhIFT9cyvdNyAFwAKywLHPECL2pec4G8o9Q7f1hS+AFl+Hw0GeGkqp zHZZWu2XZddEHKLrxh75gzb1Q5N/cQq3XV1ezMPL3cnLtTyXcxwZMP+09lRiDn4bUd9C sdrA== X-Gm-Message-State: AOPr4FVrG4iH5walbWucnR7xeyq9uwrnbjQuvb0pB7EeEiVEmNVPB8TUyFzA0jAFNK3Ves0e4GL9M0jsFco14w== MIME-Version: 1.0 X-Received: by 10.107.175.104 with SMTP id y101mr42408128ioe.113.1462204577932; Mon, 02 May 2016 08:56:17 -0700 (PDT) Received: by 10.107.32.13 with HTTP; Mon, 2 May 2016 08:56:17 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> Date: Mon, 2 May 2016 08:56:17 -0700 Message-ID: From: Kurt Andersen To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11449af67510da0531de08fe Archived-At: Cc: "spfbis@ietf.org" , Frank Bulk Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 15:56:25 -0000 --001a11449af67510da0531de08fe Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2016 at 12:58 AM, S Moonesamy wrote: > Hi Frank, > At 17:45 30-04-2016, Frank Bulk wrote: > >> >> . . . tries to work through the MX records of premieronline.net, but for >> some reason it specifically queries for an AAAA for each MX record, of >> which >> we don't have one (because our inbound email gateway does not yet support >> IPv6). Since we have four MX records, it work through two of them (which >> both fail) and then the tool hard fails saying that, >> "The maximum void DNS lookup limit of 2 has been exceeded during >> the >> evaluation (see RFC7208 Section 4.6.4.)." >> > > It does not make sense to query for an "A" record when the client address > is an IPv6 address. The issue in your case is that your outbound is over > IPv6 while you do not have inbound IPv6. I took a quick look and I did not > find a discussion about that in relation to the void DNS lookup limit in > the mailing list archive. > > . . . does RFC 7208 need some clarification on this matter? My guess >> > is that "it performs an address lookup on each MX name" is not equivalent >> to >> "check for an AAAA on each MX name and check for an A on each MX name", >> but >> I'm not sure. >> > > Your question is about whether there is a "bug" in the technical > specification. The second sentence is about how to get around a "void DNS > lookup". At the moment I am not sure about what would be the appropriate > answer. > My suggestion is to clarify exactly what constitutes a "void DNS lookup" in the case of an MX mechanism. I suggest that we define a void MX lookup to be one that either returns no records or returns the "null MX record" (RFC7505). Could this be done as an erratum item? I think we also need to highlight the importance of putting "lookup dependent mechanisms", and especially 2nd degree dependent mechanisms (such as mx) *after* any explicit IP specifications to publishers of SPF records. The "traditional"/historical suggestion that has been provided by many record creation "wizards" is flawed by putting "a mx" at the beginning of their recommendations. --Kurt Andersen --001a11449af67510da0531de08fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 2, 2016 at 12:58 AM, S Moonesamy <sm+ietf@elandsys.com><= /span> wrote:
Hi Frank,<= br> At 17:45 30-04-2016, Frank Bulk wrote:

. . . tries to work through the MX records of premieronline.net, but for=
some reason it specifically queries for an AAAA for each MX record, of whic= h
we don't have one (because our inbound email gateway does not yet suppo= rt
IPv6).=C2=A0 Since we have four MX records, it work through two of them (wh= ich
both fail) and then the tool hard fails saying that,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The maximum void DNS lookup limit of 2 ha= s been exceeded during the
evaluation (see RFC7208 Section 4.6.4.)."

It does not make sense to query for an "A" record when the client= address is an IPv6 address.=C2=A0 The issue in your case is that your outb= ound is over IPv6 while you do not have inbound IPv6.=C2=A0 I took a quick = look and I did not find a discussion about that in relation to the void DNS= lookup limit in the mailing list archive.

. . . does RFC 7208 need some clarification = on this matter?=C2=A0 My guess
 is that "it performs an address lookup on each MX name" is not eq= uivalent to
"check for an AAAA on each MX name and check for an A on each MX name&= quot;, but
I'm not sure.

 Your question is about whether there is a "bug" in the technical = specification.=C2=A0 The second sentence is about how to get around a "= ;void DNS lookup".=C2=A0 At the moment I am not sure about what would = be the appropriate answer.

My suggestio= n is to clarify exactly what constitutes a "void DNS lookup" in t= he case of an MX mechanism. I suggest that we define a void MX lookup to be= one that either returns no records or returns the "null MX record&quo= t; (RFC7505). Could this be done as an erratum item?

I think we also need to highlight the importance of putting "lookup= dependent mechanisms", and especially 2nd degree dependent mechanisms= (such as mx) after any explicit IP specifications to publishers of = SPF records. The "traditional"/historical suggestion that has bee= n provided by many record creation "wizards" is flawed by putting= "a mx" at the beginning of their recommendations.

=
--Kurt Andersen
--001a11449af67510da0531de08fe-- From nobody Mon May 2 09:48:57 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8978312D59D for ; Mon, 2 May 2016 09:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=Hvpfbrn8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=HJ4EZ76L 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 vLPNvCjHHh7G for ; Mon, 2 May 2016 09:48:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2D012B024 for ; Mon, 2 May 2016 09:48:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.49.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u42GmbMR016720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 09:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1462207732; x=1462294132; bh=DfXMW+RaayVeJnA5mKsRYcBmqkXN7MwcHGGh7itxPMk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Hvpfbrn8EfC8HRkkVEftSNIDvAn4YGe0SMyxUK+H/NCzBG6o5dh6LF6XrudCK+Fba KMmZlcHYHRh6zyjEudqmqm8SwG2u2IV3TqLiOGy+E/QlmY0qmrr3ck+/mXKeuF7ZhF HxDyJDZAAp0hjZOE7ShZN0qd3TqJFmMqvfSQAEQs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1462207732; x=1462294132; i=@elandsys.com; bh=DfXMW+RaayVeJnA5mKsRYcBmqkXN7MwcHGGh7itxPMk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HJ4EZ76LPA7ldBMLwBDwt3pWnexAti6s2862Tm+2ZQc7CMaoONqzreiGaZcmzFjF8 iOg7f0vHWS0Yby4mU8pC5TRAN4gXaAze69+x5uMeOlXYAi/EW5Ur1JdK/Gq7482R5u IQEThEz5gV82riABCkwLfoEpm0pbfQzd5ONXMrAg= Message-Id: <6.2.5.6.2.20160502093100.0878c9f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 May 2016 09:48:00 -0700 To: Kurt Andersen , spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Frank Bulk Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:48:55 -0000 Hi Kurt, At 08:56 02-05-2016, Kurt Andersen wrote: >My suggestion is to clarify exactly what constitutes a "void DNS >lookup" in the case of an MX mechanism. I suggest that we define a >void MX lookup to be one that either returns no records or returns >the "null MX record" (RFC7505). Could this be done as an erratum item? Please see https://www.rfc-editor.org/errata.php for information about how to report an erratum and how the erratum will be processed. The above might be too much for an erratum. >I think we also need to highlight the importance of putting "lookup >dependent mechanisms", and especially 2nd degree dependent >mechanisms (such as mx) after any explicit IP specifications to >publishers of SPF records. The "traditional"/historical suggestion >that has been provided by many record creation "wizards" is flawed >by putting "a mx" at the beginning of their recommendations. There is the following in Section 4.6.4: "SPF implementations SHOULD limit "void lookups" to two. An implementation MAY choose to make such a limit configurable. In this case, a default of two is RECOMMENDED. Exceeding the limit produces a "permerror" result." The following is from Section 11.1: 'Operational experience since the publication of [RFC4408] suggests that mitigation of this class of attack can be accomplished with minimal impact on the deployed base by having the verifier abort processing and return "permerror" (Section 2.6.7) as soon as more than two "void lookups" have been encountered (defined in Section 4.6.4).' In my personal opinion any text change would not be a clarification. Which section of RFC 7208 would you like to change? :-) Regards, S. Moonesamy From tobias@perschon.at Mon May 2 11:55:45 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C4A12D5F2 for ; Mon, 2 May 2016 11:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bitconnect.onmicrosoft.com 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 996LvYjcLhdZ for ; Mon, 2 May 2016 11:55:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0067.outbound.protection.outlook.com [104.47.2.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBFE12D11C for ; Mon, 2 May 2016 11:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitconnect.onmicrosoft.com; s=selector1-perschon-at; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w8OiobFZgUjYy+loB4S9+24tNkr7gHABoPmG7qageuw=; b=fYhQwLR4XY3f8iZ90tvQ4c66EFeDdTmqc2oVnr6jHDUb03iPd516Xj8EThgR95g75Cnl92BSCb7guc+8YvUGOtBdEkyAYTzbiZxgRg9ssO0oap7og11vc6h+9kMUYF6kGrer0ntIvnopH2RfT9pWRn5tHfugzEpkKa5GOlQjel4= Received: from AM4PR09MB0659.eurprd09.prod.outlook.com (10.167.85.141) by AM4PR09MB0659.eurprd09.prod.outlook.com (10.167.85.141) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 2 May 2016 18:55:37 +0000 Received: from AM4PR09MB0659.eurprd09.prod.outlook.com ([10.167.85.141]) by AM4PR09MB0659.eurprd09.prod.outlook.com ([10.167.85.141]) with mapi id 15.01.0477.014; Mon, 2 May 2016 18:55:37 +0000 From: Tobias Perschon To: "spfbis@ietf.org" Thread-Topic: SPDF Domain Name Syntax Thread-Index: AdGkox4zrZk54OdxSwWRjOgLCh7uFQ== Date: Mon, 2 May 2016 18:55:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=perschon.at; x-originating-ip: [62.178.37.36] x-ms-office365-filtering-correlation-id: 137bdfec-912a-4796-de2e-08d372bb5941 x-microsoft-exchange-diagnostics: 1; AM4PR09MB0659; 5:0BNMG92jqU7oAz86/DvfEN9EqziU7PtUuA+nud415N+1DeoT621fd4LYPD0uHIzBJLRQ8OEsOz0Wiq5QJ76Uz9jWDAvDJLa1Ntk9CYGOtDL7T8FiEf4T6rByAyS5RZjj6ucFZmv7Y9mijrrllbRgZg==; 24:v+N363/lj6zdp4xBSIR8AGn0+u9D0le/abCynofxyoYhy4YYfbX4FQZp+2WhOEA2SlSfH9rXqby7JoCMz4u1Glz2oSNGmE8AilkbOSeqPMA=; 7:3h+mw/dxlHxEopjWQXHoVhC49CNr6h7qLszl4dwvrB4w9rmfEhH96+GH6VfkXf7dZMcaR3RhzKqs2BCzWOV7vYWgno1vuDkUBbhuz7H/koKfWHufpXDi9+VL662mKGn5UaC8nc87pqdK3ZOcJ3RKP05YTOYVy/nix4v8WOLQt4d6GRKweG4SVUNaW4dK9gHC x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR09MB0659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521096)(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:AM4PR09MB0659; BCL:0; PCL:0; RULEID:; SRVR:AM4PR09MB0659; x-forefront-prvs: 0930AAFAD9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(71364002)(10400500002)(19617315012)(5004730100002)(2900100001)(77096005)(15975445007)(11100500001)(19300405004)(19625215002)(3480700004)(5003600100002)(5002640100001)(33656002)(74316001)(189998001)(110136002)(74482002)(107886002)(66066001)(5640700001)(1730700002)(16236675004)(5630700001)(2501003)(102836003)(790700001)(6116002)(92566002)(1220700001)(76576001)(50986999)(86362001)(450100001)(3280700002)(54356999)(586003)(5008740100001)(229853001)(19580395003)(2906002)(19580405001)(87936001)(3846002)(122556002)(9686002)(3660700001)(81166005)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR09MB0659; H:AM4PR09MB0659.eurprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR09MB065930FACFA477EA02EE919ADD790AM4PR09MB0659eurp_" MIME-Version: 1.0 X-OriginatorOrg: perschon.at X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2016 18:55:37.0217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9b9c1be5-48f7-48d6-8a10-d1acc1c925b3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR09MB0659 Archived-At: X-Mailman-Approved-At: Mon, 02 May 2016 12:03:45 -0700 Subject: [spfbis] SPDF Domain Name Syntax X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:56:40 -0000 --_000_AM4PR09MB065930FACFA477EA02EE919ADD790AM4PR09MB0659eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sir or Madam, I have a question regarding RFC 7208. Is a domain name e.g. for an "a:" dir= ective supposed to be a FQDN; more precisely: can a domain name contain a t= railing dot? e.g.: should this be able to be handled by any software that implements spf= : v=3Dspf1 a:domain.com. ~all Postfix for example has no problems with an domain name with trailing dot b= ut I have found a software "mdeamon" which cannot perform a dns lookup if t= he domain name is a FQDN (with trailing dot). I wrote the developers but th= ey say, they think it's not a bug in their software because "all of the pag= es about SPF, don't talk about domains with trailing dot" and the RFC does = not make it explicit if a FQDN is acceptable. I hope you can clarify. Kind regards, -- Tobias Perschon Bitconnect EDV/IT Dienstleistungen & Handel e.U. -- https://www.bitconnect.at tp@bitconnect.at +43 (0) 699 10 86 75 17 -- This e-mail may contain confidential and/or privileged information. If you = are not the intended recipient (or have received this e-mail in error) please notif= y the sender and destroy this e-mail. Any unauthorised copying, disclosure or distributi= on of the material in this e-mail is strictly forbidden. --_000_AM4PR09MB065930FACFA477EA02EE919ADD790AM4PR09MB0659eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sir or Madam,

 

I have a question regarding RFC 7208. Is a domain na= me e.g. for an “a:” directive supposed to be a FQDN; more preci= sely: can a domain name contain a trailing dot?

e.g.: should this be able to be handled by any softw= are that implements spf:

v=3Dspf1 a:domain.com. ~all

 

Postfix for example has no problems with an domain n= ame with trailing dot but I have found a software “mdeamon” whi= ch cannot perform a dns lookup if the domain name is a FQDN (with trailing = dot). I wrote the developers but they say, they think it’s not a bug in their software because “all of the pag= es about SPF, don’t talk about domains with trailing dot” and t= he RFC does not make it explicit if a FQDN is acceptable.

 

I hope you can clarify.

 

Kind regards,

--

Tobi= as Perschon

Bitconnect EDV/IT Dienstleistun= gen & Handel e.U.

--

https://www.bitconnect.at

tp@bitconnect.at

+43 (0) 699 10 86 75 17

--

This = e-mail may contain confidential and/or privileged information. If you are n= ot

the i= ntended recipient (or have received this e-mail in error) please notify the= sender

and d= estroy this e-mail. Any unauthorised copying, disclosure or distribution of= the

mater= ial in this e-mail is strictly forbidden.

 

--_000_AM4PR09MB065930FACFA477EA02EE919ADD790AM4PR09MB0659eurp_-- From nobody Mon May 2 19:39:50 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5DF12D67A for ; Mon, 2 May 2016 19:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VeZL4TodIz6n for ; Mon, 2 May 2016 19:39:46 -0700 (PDT) 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 B560212B042 for ; Mon, 2 May 2016 19:39:46 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 6B8E71FCAB7; Tue, 3 May 2016 02:39:43 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4258616006A; Tue, 3 May 2016 02:39:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 29BC0160067; Tue, 3 May 2016 02:39:42 +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 uyp7S4LP1AhJ; Tue, 3 May 2016 02:39:42 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id BA111160048; Tue, 3 May 2016 02:39:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 492ED47DB7D7; Tue, 3 May 2016 12:39:38 +1000 (EST) To: Tobias Perschon From: Mark Andrews References: In-reply-to: Your message of "Mon, 02 May 2016 18:55:37 +0000." Date: Tue, 03 May 2016 12:39:38 +1000 Message-Id: <20160503023938.492ED47DB7D7@rock.dv.isc.org> Archived-At: Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPDF Domain Name Syntax X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:39:48 -0000 In message , Tobias Perschon writes: > Dear Sir or Madam, > > I have a question regarding RFC 7208. Is a domain name e.g. for an "a:" > directive supposed to be a FQDN; more precisely: can a domain name > contain a trailing dot? > e.g.: should this be able to be handled by any software that implements > spf: > v=spf1 a:domain.com. ~all > > Postfix for example has no problems with an domain name with trailing dot > but I have found a software "mdeamon" which cannot perform a dns lookup > if the domain name is a FQDN (with trailing dot). I wrote the developers > but they say, they think it's not a bug in their software because "all of > the pages about SPF, don't talk about domains with trailing dot" and the > RFC does not make it explicit if a FQDN is acceptable. Postfix is being liberal in what it accepts. It should already be treating names in SPF records as absolute (like all names in DNS records). Appending periods is a local convention to prevent suffixes being appended be they search lists or current origin in master files ( which doesn't apply the the contents of TXT (SPF) records). Mark > I hope you can clarify. > > Kind regards, > -- > Tobias Perschon > Bitconnect EDV/IT Dienstleistungen & Handel e.U. > -- > https://www.bitconnect.at > tp@bitconnect.at > +43 (0) 699 10 86 75 17 > -- > This e-mail may contain confidential and/or privileged information. If > you are not > the intended recipient (or have received this e-mail in error) please > notify the sender > and destroy this e-mail. Any unauthorised copying, disclosure or > distribution of the > material in this e-mail is strictly forbidden. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon May 2 23:45:35 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B347712B011 for ; Mon, 2 May 2016 23:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=Oz1Wxnu9; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=HujjAVky 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 cv1kVUQdf_3a for ; Mon, 2 May 2016 23:45:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4557512D126 for ; Mon, 2 May 2016 23:45:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.49.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u436jFHC011766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 23:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1462257928; x=1462344328; bh=CCc1b1tXNNv7Zy2jSC0TVvS7BFOwHoOcMwad9ly7h58=; h=Date:To:From:Subject:In-Reply-To:References; b=Oz1Wxnu9tDR9O5CIu6PenNZWoQ8bojlPmqr1CoqGCBDMAkNr1es39xTBdj0XudtuQ /al5Jc5P9bqxqADjsc9PiuwACJkqoYHKAcMdXTIIWS+af7YSmR01RiOVV86oPak7Mc PeT5Y0jHPQitIER6+o/fFowxdsSClWe0sI+Iztr4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1462257928; x=1462344328; i=@elandsys.com; bh=CCc1b1tXNNv7Zy2jSC0TVvS7BFOwHoOcMwad9ly7h58=; h=Date:To:From:Subject:In-Reply-To:References; b=HujjAVkyYUPTFBWQsLULPs3nXssFawXP07Y/GmEf5qux4nmsjvJ0KlJ2PHT7M2/ju BSYKz++233dlmBzqZHh4Nia0tKfuYCqrDJovOstlJJ3yR/UeBvuQQkQ8vf2tQ3TmG9 XMRzXFhnvklInx+Sqt/DiXLGahuObQBEef+aOd/g= Message-Id: <6.2.5.6.2.20160502233007.0dae73b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 May 2016 23:44:55 -0700 To: Tobias Perschon , spfbis@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [spfbis] SPDF Domain Name Syntax X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 06:45:32 -0000 Hi Tobias, At 11:55 02-05-2016, Tobias Perschon wrote: >I have a question regarding RFC 7208. Is a domain name e.g. for an >"a:" directive supposed to be a FQDN; more precisely: can a domain >name contain a trailing dot? >e.g.: should this be able to be handled by any software that implements spf: >v=spf1 a:domain.com. ~all > >Postfix for example has no problems with an domain name with >trailing dot but I have found a software "mdeamon" which cannot >perform a dns lookup if the domain name is a FQDN (with trailing >dot). I wrote the developers but they say, they think it's not a bug >in their software because "all of the pages about SPF, don't talk >about domains with trailing dot" and the RFC does not make it >explicit if a FQDN is acceptable. Section 4.8 of RFC 7208 discusses about "domain-spec". The issue is whether the software implements RFC 7208 and, if so, whether it adheres to the ABNF defined in RFC 7208. The software should be able to handle the above-mentioned example. Regards, S. Moonesamy From nobody Tue May 3 22:16:13 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E8912D0A3 for ; Tue, 3 May 2016 22:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OPOHf6vGUmh8 for ; Tue, 3 May 2016 22:16:10 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 002DD12D0C1 for ; Tue, 3 May 2016 22:16:09 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id g133so58222311ywb.2 for ; Tue, 03 May 2016 22:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2/mPz2D3G0X4vBsYgkUsFxsC9mXZLVUDvYk9u/bMN20=; b=ohb4mNFk5a/lBV6O1nMf4jw6bwlajgCshSEl1EjKQ5MuTJeaQ+P3b7F3V+gacIoLro ZG1qot1rnuRWh9Efw1zZeYe+nky2t2w69TCBYS+lYnIxolKxUm05hN6sqfKGoGb3g15R KuIvsQbYcQNcuNk/75eYpe9rkjPfnlftAdnMBnNVkFcWnJLUzcL/+3/nJlDGQUYtWGTi A0gKwH6cwDkYTeUPgbi6rVauycaYTVAURSO/5rU1fgmGTF6NJliEn/KUqpQDncMb7uVo Xam/6gKyCmpAg4txJzGLH7hAwZjEU2zA7dZzsTVZQHehK1qqc0tSxjU+aLakWE86BFBo rQgA== 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; bh=2/mPz2D3G0X4vBsYgkUsFxsC9mXZLVUDvYk9u/bMN20=; b=WHWo112+hFvnaPgF5MxpHW152mTUKbKJe2vgzpJ43XjWBIA7pI0XgN0ePyLAVWqVKy WpRSmyYqzbHge53u1Chsph0GuVW+mqSKzbWqja4B0NCwY2ovJ/xWyEYJ6fWQf2CCb398 2ksQ86JdzKlDxibzbRl2yg132Cq03m5jHFQRFqdlUnYeaaXBbLFCXLZ6wdTZAalhhL+u xCNW4t+9spVNTMed/3ojhbivQHmMReAnYi1SPx4sAH87rCQdjUcXQr5i8fDw+zRA3TCK gmBrZVaKCooN9iNvtPVWBB5pryMG5lmafi2jZj3crCMdt2w00PBpmumBhZSe0IXeUpl7 DX7A== X-Gm-Message-State: AOPr4FUk/J/O/Jqy5+8kIZmA5p+xGJrhhJBq9bOOiJmNpPmH5RgjyMWVQ3PsSPweiB/Lq7QIzuSuk4FoFUBDBQ== MIME-Version: 1.0 X-Received: by 10.159.38.75 with SMTP id 69mr3588829uag.139.1462338969260; Tue, 03 May 2016 22:16:09 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Tue, 3 May 2016 22:16:09 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20160502093100.0878c9f0@elandnews.com> References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> <6.2.5.6.2.20160502093100.0878c9f0@elandnews.com> Date: Tue, 3 May 2016 22:16:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a113e4aa8cdd9260531fd523a Archived-At: Cc: "spfbis@ietf.org" , Kurt Andersen , Frank Bulk Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 05:16:12 -0000 --001a113e4aa8cdd9260531fd523a Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2016 at 9:48 AM, S Moonesamy wrote: > My suggestion is to clarify exactly what constitutes a "void DNS lookup" >> in the case of an MX mechanism. I suggest that we define a void MX lookup >> to be one that either returns no records or returns the "null MX record" >> (RFC7505). Could this be done as an erratum item? > > > > Please see https://www.rfc-editor.org/errata.php for information about > how to report an erratum and how the erratum will be processed. The above > might be too much for an erratum. I guess we used the term in the lists but the definition never made it into the document. Damn. Anyway, I support logging an erratum for this if that's the main issue. Who knows if and when there will be enough energy and interest to do an update. -MSK --001a113e4aa8cdd9260531fd523a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2016 at 9:48 AM, S Moonesamy <sm+ietf@e= landsys.com> wrote:
My suggestion is to clarify exactly what constitutes a= "void DNS lookup" in the case of an MX mechanism. I suggest that= we define a void MX lookup to be one that either returns no records or ret= urns the "null MX record" (RFC7505). Could this be done as an err= atum item?
Please see https://www.rfc-editor.org/errata.php for inform= ation about how to report an erratum and how the erratum will be processed.= =C2=A0 The above might be too much for an erratum.

I guess we used the term in the lists but the definition never made= it into the document.=C2=A0 Damn.

Anyway, I support logg= ing an erratum for this if that's the main issue.=C2=A0 Who knows if an= d when there will be enough energy and interest to do an update.

-MSK
--001a113e4aa8cdd9260531fd523a-- From nobody Wed May 4 08:43:13 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E71D12D804 for ; Wed, 4 May 2016 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 rfqgV3vUSJ6q for ; Wed, 4 May 2016 08:43:10 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 81B1412D843 for ; Wed, 4 May 2016 08:37:34 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id u10so151400474igr.1 for ; Wed, 04 May 2016 08:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OxWAN4nejxsL/0QzMNm4tsDlH8BDyzffKUsj4lQGdsA=; b=fU8dVRoa5c19hKunsgqSYHrsFc4j0kzy5teOXOO7jNnttjNqaHPeLj63pLwGRCp5ac kigb5+AfxQJS94Jz5Czscxra2F56waQtzkvse7yKNpeMt5lRdfCzv07bMiUqORecaXxz 0rMkXcSCXcciTAGhtOhimbWgRAS6ruapIXVxw= 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; bh=OxWAN4nejxsL/0QzMNm4tsDlH8BDyzffKUsj4lQGdsA=; b=UHoRQlyd1a+uh8JGrEeTYDNBchLsdrP/qBKmnEbCGGtgsKdTld4xhjowXHv9R+UAa4 9xNDnYL65BmxqGoQtsXt+8XRzqS+dmsnxoY8qy/VnnFul8Pax1KThD1NoldbXOgzVWaM yW0occCDKgE/d1l0FG798Say+RY9XpooQhY8LRmLflhUQPGSv7T/mmdrGXRRHwi2gFxt KdGsos5FxCU94ytzSH0VuxbwQvILm8K8bGop7ROGJ+ZRDZ30N2a+4lqgKE+paIF4dKFP IuicXqQbP3BKYyMob9xh0N2KCps6HQ2IOkmA8oQMhKtx9he4PfMFDDzoVGK9XcQEn3cI STVw== X-Gm-Message-State: AOPr4FXSCMVN88IMEcTs2kkz75QHblPXA5XqhckptDsEoY87AVsiI0lMJloU9slC2fOdcZWUpQ5n+yHbbjlbfw== MIME-Version: 1.0 X-Received: by 10.51.17.4 with SMTP id ga4mr11828904igd.88.1462376253775; Wed, 04 May 2016 08:37:33 -0700 (PDT) Received: by 10.107.32.13 with HTTP; Wed, 4 May 2016 08:37:33 -0700 (PDT) In-Reply-To: References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> <6.2.5.6.2.20160502093100.0878c9f0@elandnews.com> Date: Wed, 4 May 2016 08:37:33 -0700 Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1134b422227ef40532060170 Archived-At: Cc: "spfbis@ietf.org" , S Moonesamy , Frank Bulk Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:43:12 -0000 --001a1134b422227ef40532060170 Content-Type: text/plain; charset=UTF-8 On Tue, May 3, 2016 at 10:16 PM, Murray S. Kucherawy wrote: > On Mon, May 2, 2016 at 9:48 AM, S Moonesamy wrote: > >> My suggestion is to clarify exactly what constitutes a "void DNS lookup" >>> in the case of an MX mechanism. I suggest that we define a void MX lookup >>> to be one that either returns no records or returns the "null MX record" >>> (RFC7505). Could this be done as an erratum item? >> >> >> Please see https://www.rfc-editor.org/errata.php for information about >> how to report an erratum and how the erratum will be processed. The above >> might be too much for an erratum. > > > I guess we used the term in the lists but the definition never made it > into the document. Damn. > > Anyway, I support logging an erratum for this if that's the main issue. > Who knows if and when there will be enough energy and interest to do an > update. > > -MSK > I'll have to go back and research the usage of the term in the spfbis mailing lists. I'll follow up with a note here once I have a proposal with concrete wording. --Kurt --001a1134b422227ef40532060170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 3, 2016 at 10:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Mon, May 2, 2016 at 9:48 AM, S Moonesamy = <sm+ietf@eland= sys.com> wrote:
My suggestion is to clarify exactly what const= itutes a "void DNS lookup" in the case of an MX mechanism. I sugg= est that we define a void MX lookup to be one that either returns no record= s or returns the "null MX record" (RFC7505). Could this be done a= s an erratum item?
Please see https://www.rfc-editor.org/errata.php for inform= ation about how to report an erratum and how the erratum will be processed.= =C2=A0 The above might be too much for an erratum.

I guess we used the term in the lists but the definition nev= er made it into the document.=C2=A0 Damn.

Anyway, I suppo= rt logging an erratum for this if that's the main issue.=C2=A0 Who know= s if and when there will be enough energy and interest to do an update.

-MSK

I'll have to go= back and research the usage of the term in the spfbis mailing lists. I'= ;ll follow up with a note here once I have a proposal with concrete wording= .

--Ku= rt
--001a1134b422227ef40532060170-- From SRS0=42CRp=Q5==stuart@gathman.org Wed May 4 09:01:10 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AED012DA59 for ; Wed, 4 May 2016 09:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org 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 z8wmhP-egxmW for ; Wed, 4 May 2016 09:01:04 -0700 (PDT) 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 0B70912DAA0 for ; Wed, 4 May 2016 08:54:17 -0700 (PDT) Authentication-Results: mail.gathman.org; iprev=pass policy.iprev="2001:470:8:809:11::1009" (elissa.gathman.org); auth=pass (PLAIN sslbits=128) 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=1462377254; h=Subject : To : References : From : Message-ID : Date : MIME-Version : In-Reply-To : Content-Type : Content-Transfer-Encoding : Subject : From : Date; bh=Js7wvPmM6OkBsT0VkhJyck4Jg+rOjGMFiYq5n6Cz+cw=; b=HwaPU2ZDgnjpOuYpxzCfkuPTSQreyv8qmEJbILAo34G7GHZ9a8BFpt7F/pnY+c/KiQxJif an5OyFCbN8gW4GT3rry3jTAPyhsxBcUuH/bQPKAn9hjQAIMptGQLTzbXB+Tu5rj20h6MKzmS Qh8VelFuCBRnGmE2C1YIp2KFcHSwI= Received: from elissa.gathman.org (elissa.gathman.org [IPv6:2001:470:8:809:11::1009]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u44FsEwI009731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 May 2016 11:54:14 -0400 To: spfbis@ietf.org References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> <6.2.5.6.2.20160502093100.0878c9f0@elandnews.com> From: Stuart Gathman Organization: Gathman Systems Jabber-Id: stuart@gathman.org Message-ID: <572A1B27.9050502@gathman.org> Date: Wed, 4 May 2016 11:54:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:41:36 -0000 On 05/04/2016 11:37 AM, Kurt Andersen wrote: > > I guess we used the term in the lists but the definition never made it > into the document. Damn. > Kind of like "Natural Born Citizen". From nobody Wed May 4 10:40:09 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE912D8C9 for ; Wed, 4 May 2016 10:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org 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 wSx6yC8-zB7N for ; Wed, 4 May 2016 10:40:06 -0700 (PDT) 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 2D41012D895 for ; Wed, 4 May 2016 10:40:06 -0700 (PDT) Authentication-Results: mail.gathman.org; iprev=pass policy.iprev="2001:470:8:809:11::1009" (elissa.gathman.org); auth=pass (PLAIN sslbits=128) 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=1462383603; h=To : From : Subject : Message-ID : Date : MIME-Version : Content-Type : From : Subject : Date; bh=JPY4KqrgFU1teaHLHfhiwNKBM2NGHO4lqTCQNyKn9GM=; b=JyogbJfdYSWt3dPig48fhyRT3L0Ciw53E2l9PDf12mFzRL91SxX2TeVEVsUasQgIt/SP1j tUCAp93jXI39Jn+xtFiq15gEtGG6tk4Dcj3M5xF6jsLgrUaTSssXytd6CyPauIqQNUwqGkIC M88N/V1gggwE+MfeMT+dr7I9W+LIE= Received: from elissa.gathman.org (elissa.gathman.org [IPv6:2001:470:8:809:11::1009]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id u44He2Ol010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 May 2016 13:40:03 -0400 To: spfbis@ietf.org From: Stuart Gathman Organization: Gathman Systems Jabber-Id: stuart@gathman.org Message-ID: <572A33F3.7070100@gathman.org> Date: Wed, 4 May 2016 13:40:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080603080606030203090506" Archived-At: Subject: [spfbis] [meta-issue] Mis-use of MAIL FROM for list authentication X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:40:08 -0000 This is a multi-part message in MIME format. --------------080603080606030203090506 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm behind on my own promised volunteer work, so I'm only posting this to make sure it is on record as a problem. When I post to the spfbis mailing list, I have to confirm my posting, as the list uses MAIL FROM to identify the poster, and my MAIL FROM is variable to make it signed and possible to validate: Return-Path: However, the list *should* be looking at the From: header, which is also signed and validated by ietf: Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass (10= 24-bit key) header.d=3Dgathman.org =2E.. DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dgathma= n.org; i=3D@gathman.org;=20 q=3Ddns/txt; s=3Ddefault; t=3D1462377254; h=3DSubject : To : Referen= ces : From=20 : Message-ID : Date : MIME-Version : In-Reply-To : Content-Type :=20 Content-Transfer-Encoding : Subject : From : Date;=20 bh=3DJs7wvPmM6OkBsT0VkhJyck4Jg+rOjGMFiYq5n6Cz+cw=3D;=20 b=3DHwaPU2ZDgnjpOuYpxzCfkuPTSQreyv8qmEJbILAo34G7GHZ9a8BFpt7F/pnY+c/K= iQxJif an5OyFCbN8gW4GT3rry3jTAPyhsxBcUuH/bQPKAn9hjQAIMptGQLTzbXB+Tu5rj20h6M= KzmS Qh8VelFuCBRnGmE2C1YIp2KFcHSwI=3D =2E.. From: Stuart Gathman --------------080603080606030203090506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm behind on my own promised volunteer work, so I'm only posting this to make sure it is on record as a problem.

When I post to the spfbis mailing list, I have to confirm my posting, as the list uses MAIL FROM to identify the poster, and my MAIL FROM is variable to make it signed and possible to validate:

  Return-Path: <SRS0=42CRp=Q5==stuart@gathman.org>

However, the list *should* be looking at the From: header, which is also signed and validated by ietf:
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=gathman.org
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org;
 i=@gathman.org; 
 q=dns/txt; s=default; t=1462377254; h=Subject : To : References : From 
 : Message-ID : Date : MIME-Version : In-Reply-To : Content-Type : 
 Content-Transfer-Encoding : Subject : From : Date; 
 bh=Js7wvPmM6OkBsT0VkhJyck4Jg+rOjGMFiYq5n6Cz+cw=; 
 b=HwaPU2ZDgnjpOuYpxzCfkuPTSQreyv8qmEJbILAo34G7GHZ9a8BFpt7F/pnY+c/KiQxJif
 an5OyFCbN8gW4GT3rry3jTAPyhsxBcUuH/bQPKAn9hjQAIMptGQLTzbXB+Tu5rj20h6MKzmS
 Qh8VelFuCBRnGmE2C1YIp2KFcHSwI=
...
From: Stuart Gathman <stuart@gathman.org>
--------------080603080606030203090506-- From nobody Wed May 4 11:31:25 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DB312D0AE for ; Wed, 4 May 2016 11:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=R9elAj+z; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=RxIjnW3R 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 DtYcLtQuoPPd for ; Wed, 4 May 2016 11:31:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6712D116 for ; Wed, 4 May 2016 11:31:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.50.83]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u44IV0Q9002172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2016 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1462386671; x=1462473071; bh=hPqmKlLO0FWAY6sqAm1ipXZqekew1+l2xIV63f9W2rk=; h=Date:To:From:Subject:In-Reply-To:References; b=R9elAj+zo8xpKoXb2BH28KqOWL5AZ+CoT7zi0HdXO+YwALR2HkYiIMLsGQjd5u1ib HQ5R1EjLKijwlVGALwbeqJsOeTmEH7jQPWoFgvswY9BV0bMSVU/at0YQlt22FuFbfc ml+Q7omdn5s0JLpu5XtVBuH83gwqJaHoTA+Ib1F4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1462386671; x=1462473071; i=@elandsys.com; bh=hPqmKlLO0FWAY6sqAm1ipXZqekew1+l2xIV63f9W2rk=; h=Date:To:From:Subject:In-Reply-To:References; b=RxIjnW3RkwgR7A3RixA1AWXb8qYJGRE5mBanXgEbhiiR+1zmW3XetwTZxCJwCdq9N 9J5z9Phc6yej42knIjNmvtvers6eAmzxtgZBSgKQ8AcBnkA/IT/IYtR4un54S4gde4 27uaCqKpgdNhWig43dB++m1dWBZDUvvs7eSKPaTU= Message-Id: <6.2.5.6.2.20160504112048.1004b960@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 May 2016 11:29:57 -0700 To: Stuart Gathman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <572A33F3.7070100@gathman.org> References: <572A33F3.7070100@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [spfbis] [meta-issue] Mis-use of MAIL FROM for list authentication X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 18:31:25 -0000 Hi Stuart, At 10:40 04-05-2016, Stuart Gathman wrote: >When I post to the spfbis mailing list, I have to confirm my >posting, as the list uses MAIL FROM to identify the poster, and my >MAIL FROM is variable to make it signed and possible to validate: > > Return-Path: > > >However, the list *should* be looking at the From: header, which is >also signed and validated by ietf: I am one of the list moderators for this mailing list. The above is about an operational issue. I can enquire about the issue or you, or anyone else, could send an email to ietf-action@ietf.org to enquire [1] about this issue. Regards, S. Moonesamy 1. http://www.ietf.org/contact.html From nobody Wed May 4 13:14:07 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C94412D5DE for ; Wed, 4 May 2016 13:14:06 -0700 (PDT) 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 autolearn_force=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 7dSHrJLPHs72 for ; Wed, 4 May 2016 13:14:04 -0700 (PDT) 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 9FB3312D551 for ; Wed, 4 May 2016 13:14:04 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u44KDhQt002397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 May 2016 13:13:43 -0700 To: S Moonesamy , Stuart Gathman , spfbis@ietf.org References: <572A33F3.7070100@gathman.org> <6.2.5.6.2.20160504112048.1004b960@resistor.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <572A57EF.9060906@dcrocker.net> Date: Wed, 4 May 2016 13:13:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20160504112048.1004b960@resistor.net> 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]); Wed, 04 May 2016 13:13:46 -0700 (PDT) Archived-At: Subject: Re: [spfbis] [meta-issue] Mis-use of MAIL FROM for list authentication X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 20:14:06 -0000 Never one to consider the obvious as above mentioning, but I do appreciate the irony of this (frankly entirely valid 0complaint, given the nature of SPF's basic authentication premise... d/ On 5/4/2016 11:29 AM, S Moonesamy wrote: > Hi Stuart, > At 10:40 04-05-2016, Stuart Gathman wrote: >> When I post to the spfbis mailing list, I have to confirm my posting, >> as the list uses MAIL FROM to identify the poster, and my MAIL FROM is >> variable to make it signed and possible to validate: >> >> Return-Path: >> >> >> >> However, the list *should* be looking at the From: header, which is >> also signed and validated by ietf: > > I am one of the list moderators for this mailing list. The above is > about an operational issue. I can enquire about the issue or you, or > anyone else, could send an email to ietf-action@ietf.org to enquire [1] > about this issue. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/contact.html > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 4 13:57:40 2016 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D979B12D864 for ; Wed, 4 May 2016 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 bxRXw4TpaeGj for ; Wed, 4 May 2016 13:57:36 -0700 (PDT) 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 DCC8F12D869 for ; Wed, 4 May 2016 13:57:35 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D5E05C4029A for ; Wed, 4 May 2016 15:57:33 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462395453; bh=34mk84q//c3pMy4u7ECoVOIx20T5n4okCh/YsaMGWpE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=V/iaybXX1sVVqE6QoF8LYvcTqVyKUNPZsYcuOPHG/RktyGFFEoyoWauX7YBSOiE4I dX43Ex/dqezctWt5tv+/H2ZYi6QatYXGL90AGyz3s5IVS3lsf/SP4vh8XqR73BBfwJ YBNd0ttu4AdALtAy4JXI6eXVSJpuq+1C9Em3O9R4= From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 May 2016 16:57:32 -0400 Message-ID: <7596256.udTDuNhnso@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <002101d1a342$c93e3000$5bba9000$@iname.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:57:39 -0000 On Wednesday, May 04, 2016 08:37:33 AM Kurt Andersen wrote: > On Tue, May 3, 2016 at 10:16 PM, Murray S. Kucherawy > > wrote: > > On Mon, May 2, 2016 at 9:48 AM, S Moonesamy wrote: > >> My suggestion is to clarify exactly what constitutes a "void DNS lookup" > >> > >>> in the case of an MX mechanism. I suggest that we define a void MX > >>> lookup > >>> to be one that either returns no records or returns the "null MX record" > >>> (RFC7505). Could this be done as an erratum item? > >> > >> Please see https://www.rfc-editor.org/errata.php for information about > >> how to report an erratum and how the erratum will be processed. The > >> above > >> might be too much for an erratum. > > > > I guess we used the term in the lists but the definition never made it > > into the document. Damn. > > > > Anyway, I support logging an erratum for this if that's the main issue. > > Who knows if and when there will be enough energy and interest to do an > > update. > > > > -MSK > > I'll have to go back and research the usage of the term in the spfbis > mailing lists. I'll follow up with a note here once I have a proposal with > concrete wording. > > --Kurt SPFbis picked this up from Mail::SPF under the charter terms that allowed "addition of any enhancements that have already gained widespread support" [1], so the relevant section of the Mail::SPF documentation [2] may also be a useful source of information. Scott K [1] https://datatracker.ietf.org/wg/spfbis/charter/ [2] https://metacpan.org/pod/Mail::SPF::Server