From nobody Tue Jan 12 08:09:42 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 A35751B2AEB for ; Tue, 12 Jan 2016 08:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3Y8irBNL3eKx for ; Tue, 12 Jan 2016 08:09:39 -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 85AA91B2ACE for ; Tue, 12 Jan 2016 08:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1452614976; bh=w4vtGRVRrj72L92RKsSXqPJNCD8CEok4/+TiBQk5xXM=; l=1406; h=To:From:Date; b=GPgyyc5OXoXy7L3bJdmmicQGpheCGc02AIkuMFrL2w0w7iAgBf1dcy5u5RKHmw1Nb T4UpspeMOt7UTjIZ6VcjztMqaF/ERRba3iiNFwp6k/Bk/F1xeaHn0CmjUrgtNUCaim rTsUX8gFQ78Tqq+tSt69mOvDCKc4U+I4ysBZ2sNQ= 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; Tue, 12 Jan 2016 17:09:35 +0100 id 00000000005DC05C.000000005695253F.00001B1C To: spfbis From: Alessandro Vesely Message-ID: <5695253F.6060702@tana.it> Date: Tue, 12 Jan 2016 17:09:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [spfbis] Result of record evaluation with non-implemented mechanism 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, 12 Jan 2016 16:09:40 -0000 Hi, RFC 7208 doesn't seem to be very clear on the requirements for "exists" mechanisms. I don't know if that deserves an errata. The spec defines mechanisms, but Section 4.6.4 "DNS Lookup Limits" does not mention "exists", while Section 5.7 "exists" does not mention return values. OTOH, dmarcian reports that "exists" mechanisms are not fully supported by all high-volume receivers. In fact, google.com returns permfail for the record in the first bullet of Appendix D.1, unless a match is found before "exists". According to Section 2.6.7 "Permerror", Google signal an error condition that definitely requires DNS operator intervention to be resolved. Tools which parse DMARC aggregate feedback correctly report an issue, to no avail :-O You see, SPF receivers are divided into two categories: those with a loaded check_host() function and those who never reject on fail. Google never reject on fail. Why do they return permerror, then? Wouldn't "none" be fine? 4.6.2. *Mechanisms* The second paragraph there may be a good point to pin an errata: OLD When a mechanism is evaluated, one of three things can happen: it can match, not match, or return an exception. NEW When a mechanism is evaluated, one of three things can happen: it can match, not match, or return an exception. Non-implemented mechanisms MUST NOT return an exception. Better ideas? Ale From nobody Tue Jan 12 19:56: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 9B94E1B2CE8 for ; Tue, 12 Jan 2016 19:56:31 -0800 (PST) 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 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 fv0YOikxSbnY for ; Tue, 12 Jan 2016 19:56:30 -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 0D0E41B2CE7 for ; Tue, 12 Jan 2016 19:56:29 -0800 (PST) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AFAC5C405C9 for ; Tue, 12 Jan 2016 21:56:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1452657388; bh=hl/ItDos+IXiWvmTLlP67gH/GGzbZOJeOMf0MmtnVO0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=y70vTwDnUkVrlxUCl3o5r9du7kn+Uv5zTMBN1ebBDfNQU1Srp575PsiJD4sbYo0vj q9aXLALAvwZ/LrytKPJZhsduyzw8wKGV6RINgzG5/JrDqN2y1xWoMKa9K8gxRbbIlN t5VGN2GQnK0t8Pf9clwqXVx3UqPWLK+8EdfxcMNA= From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 12 Jan 2016 22:56:28 -0500 Message-ID: <1880087.thFNaSE3HX@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-71-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5695253F.6060702@tana.it> References: <5695253F.6060702@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism 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, 13 Jan 2016 03:56:31 -0000 On Tuesday, January 12, 2016 05:09:35 PM Alessandro Vesely wrote: > Hi, > RFC 7208 doesn't seem to be very clear on the requirements for "exists" > mechanisms. I don't know if that deserves an errata. > > The spec defines mechanisms, but Section 4.6.4 "DNS Lookup Limits" does not > mention "exists", while Section 5.7 "exists" does not mention return values. > > OTOH, dmarcian reports that "exists" mechanisms are not fully supported by > all high-volume receivers. In fact, google.com returns permfail for the > record in the first bullet of Appendix D.1, unless a match is found before > "exists". > > According to Section 2.6.7 "Permerror", Google signal an error condition > that definitely requires DNS operator intervention to be resolved. Tools > which parse DMARC aggregate feedback correctly report an issue, to no avail > :-O > > You see, SPF receivers are divided into two categories: those with a loaded > check_host() function and those who never reject on fail. Google never > reject on fail. Why do they return permerror, then? Wouldn't "none" be > fine? > > 4.6.2. *Mechanisms* > > The second paragraph there may be a good point to pin an errata: > > OLD > When a mechanism is evaluated, one of three things can happen: it can > match, not match, or return an exception. > > NEW > When a mechanism is evaluated, one of three things can happen: it can > match, not match, or return an exception. Non-implemented mechanisms > MUST NOT return an exception. > > Better ideas? The way the RFC is designed, mechanisms aren't optional. What you're asking for is not something that should be done via errata. 4.6.2 is correct and exists is no different than any other mechanism. Scott K From nobody Thu Jan 14 07:37:06 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 652ED1A0029 for ; Thu, 14 Jan 2016 07:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] 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 h9DozIZXrhV3 for ; Thu, 14 Jan 2016 07:37:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FA01A0026 for ; Thu, 14 Jan 2016 07:37:03 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.227.80.132]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u0EFaoQQ013100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2016 07:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1452785822; x=1452872222; bh=8Pwiju+VPs4j931VQmKZ22eyO5sPGV8VWA2D6YZhdqE=; h=Date:To:From:Subject:In-Reply-To:References; b=NX1eav5sUJ9btulJeKq198If+95hCNk3EhOe87kWMTuRiveKdWQeminxe8BU6GKwv NeRJpqTNgPQBSZrvIYHBh9U1XVY7w6Gj2gKUhSP8DRQ33jSMLOWW2SczUmmnpLvAye gYeMIyeWubN6Usb3SioBf6nXsLVPxzJSkKCMDaCo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1452785822; x=1452872222; i=@elandsys.com; bh=8Pwiju+VPs4j931VQmKZ22eyO5sPGV8VWA2D6YZhdqE=; h=Date:To:From:Subject:In-Reply-To:References; b=L7VFgIKl6qzog8eso7jYyRTlsm3MgIpLdOFu+M8VQDk3lhI20zYECK5CiCdFZnIKs Y8ZzIQ+bsxxKcDyAYmjOBs16XHY2tSraOhDCbDHq4r9AMnhbHwlAt4OMQiKNRwHuU0 xzpgovUUYF1BJA25Uy0BlLKHEmUhmkf5kxDkKYgw= Message-Id: <6.2.5.6.2.20160114071739.0e0ec630@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Jan 2016 07:36:41 -0800 To: Alessandro Vesely , spfbis@ietf.org From: S Moonesamy In-Reply-To: <5695253F.6060702@tana.it> References: <5695253F.6060702@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism 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, 14 Jan 2016 15:37:04 -0000 Hi Alessandro, At 08:09 12-01-2016, Alessandro Vesely wrote: >RFC 7208 doesn't seem to be very clear on the requirements for "exists" >mechanisms. I don't know if that deserves an errata. Section 5 lists "exists" as a designated sender mechanism. >4.6.2. *Mechanisms* > >The second paragraph there may be a good point to pin an errata: > >OLD > When a mechanism is evaluated, one of three things can happen: it can > match, not match, or return an exception. > >NEW > When a mechanism is evaluated, one of three things can happen: it can > match, not match, or return an exception. Non-implemented mechanisms > MUST NOT return an exception. > >Better ideas? The suggested text is about non-implemented mechanisms. There is a "do not use" mechanism. Would that be a non-implemented mechanism? There isn't an explanation for the "MUST NOT" in the suggested text. Regards, S. Moonesamy From nobody Thu Jan 14 08:15: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 BF9981A1A14 for ; Thu, 14 Jan 2016 08:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 XNExPeoeh6aN for ; Thu, 14 Jan 2016 08:15:55 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 164F71A1A12 for ; Thu, 14 Jan 2016 08:15:54 -0800 (PST) Received: from [192.168.1.20] (unknown [67.58.115.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D0321CB46; Thu, 14 Jan 2016 11:14:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Draegen In-Reply-To: <5695253F.6060702@tana.it> Date: Thu, 14 Jan 2016 11:15:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5695253F.6060702@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.2104) Archived-At: Cc: spfbis Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism 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, 14 Jan 2016 16:15:56 -0000 > On Jan 12, 2016, at 11:09 AM, Alessandro Vesely = wrote: >=20 > OTOH, dmarcian reports that "exists" mechanisms are not fully = supported by all > high-volume receivers. Speaking for dmarcian.com's SPF tool, Hotmail used to skip exists = mechanisms due to the impact of expanding macro resolutions and trying = to cache it all. Search RFC 7208 for "cache" for some related text. Two things: 1. It's not the exists: mechanism itself, its the use of macros that can = be painful to DNS caching. Apparently Hotmail saw macro-based DNS = explosions in the context of the exists: mechanism, and act accordingly. = However, other mechanisms can use macros, too. 2. Hotmail's infrastructure has been moved (or is just about finished = moving) to all-Outlook. Part of this transition means no more skipping = of exists. I'm OK with removing the exists: mechanism warning shown to users of = dmarcian's SPF tool. One thing I'm not sure about is if warning about = the use of macros should replace it. Is concern about DNS caching infrastructure still relevant, or are these = concerns rooted in an older time? I'll be asking more "DNS people" = about this, as I'd like to give correct guidance. -=3D Tim From nobody Thu Jan 14 12:15: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 486FD1ACCE9 for ; Thu, 14 Jan 2016 12:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 8KepRfT1PzJp for ; Thu, 14 Jan 2016 12:15:35 -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 2792D1ACCE8 for ; Thu, 14 Jan 2016 12:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1452802532; bh=kJKBoT0g1MJWPIw1FrsV06zURvtQHVkz9xPxbqRm0j8=; l=403; h=To:References:Cc:From:Date:In-Reply-To; b=xepmRmvMh+IfIV8dTf5Bh6Y404SJmOzzUEZsI0YEHr5UGBQw1HxaP3xMS9jFJj9IQ wirqfdv/XIaHHDtqs5Qc1a87jX5/GVT9MPkkJPG0xbp8uNqpOY/NSysf19+q8JQ7XU gxNVh+3kGNn/TfXKXCtL0CGrspJDvAXZpUi8D2to= 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; Thu, 14 Jan 2016 21:15:32 +0100 id 00000000005DC061.00000000569801E4.0000544B To: Tim Draegen References: <5695253F.6060702@tana.it> From: Alessandro Vesely Message-ID: <569801E4.3090609@tana.it> Date: Thu, 14 Jan 2016 21:15:32 +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=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: spfbis Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism 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, 14 Jan 2016 20:15:37 -0000 On Thu 14/Jan/2016 17:15:52 +0100 Tim Draegen wrote: > I'm OK with removing the exists: mechanism warning shown to users of > dmarcian's SPF tool. One thing I'm not sure about is if warning about the > use of macros should replace it. Yes, please. It would clean up the interface a bit. Would it be possible to turn it on only after actual SPF permerror's show up in aggregate reports? Ale From nobody Thu Jan 14 12:50: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 C98FC1ACD6E for ; Thu, 14 Jan 2016 12:50:39 -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 9R8COtlgzfbE for ; Thu, 14 Jan 2016 12:50:38 -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 8631A1ACD61 for ; Thu, 14 Jan 2016 12:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1452804635; bh=HhjHrcoSmHVKgU0i+p9r8Wbo+/q2DiWDlwKGfRyyalM=; l=1629; h=To:References:From:Date:In-Reply-To; b=XmQr3Pn7i6y50KZy62N90e+NX+tSqsXLFLg9FzF6GIsSjPCPQJSbX62rHZZ/cEuVG kCftbm3mtPqqvs9SMKMDL61IL1FCsHAFXdygPMcLXxFORbQx/QFthXScvYf3LheGfm m4NFOpu+JX9L17HrsxQGDQb4Nk36JCDW19jmGC4k= 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; Thu, 14 Jan 2016 21:50:34 +0100 id 00000000005DC059.0000000056980A1A.000055A0 To: S Moonesamy , spfbis@ietf.org References: <5695253F.6060702@tana.it> <6.2.5.6.2.20160114071739.0e0ec630@resistor.net> From: Alessandro Vesely Message-ID: <56980A1A.2090603@tana.it> Date: Thu, 14 Jan 2016 21:50:34 +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: <6.2.5.6.2.20160114071739.0e0ec630@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] Result of record evaluation with non-implemented mechanism 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, 14 Jan 2016 20:50:40 -0000 Hi SM, On Thu 14/Jan/2016 16:36:41 +0100 S Moonesamy wrote: > At 08:09 12-01-2016, Alessandro Vesely wrote: >> >> NEW >> When a mechanism is evaluated, one of three things can happen: it can >> match, not match, or return an exception. Non-implemented mechanisms >> MUST NOT return an exception. >> >> Better ideas? > > The suggested text is about non-implemented mechanisms. There is a "do not > use" mechanism. Would that be a non-implemented mechanism? There isn't an > explanation for the "MUST NOT" in the suggested text. Yeah, that would have been a bit freaky. Yet, a cute evaluator could optimize an evaluation in some ways. Consider a record ending like so: ... ?exists:%{ir}.blah ?all There is no reason to evaluate the exists. Now what if you had: ... ?exists:%{ir}.blah -all Suppose you know your internal policy only differentiates between "pass" and "not-pass". Getting "neutral" or "fail" wouldn't make a real difference, except for the formal result name that you write on reports. Does it really hurt to put "none" as in "nothing relevant here"? The note at the end of Section 4.8 seems to allow some leeway in the reported result, but only for malformed names. There are some other head-scratchers before the example in the first bullet of Appendix D.1 can be used in practice. One is the query quota that a whitelist may impose. Let me use this post as an occasion to apologize to Google for having wrongly imagined that their implementation skips proper evaluation of mechanisms. In fact, the resulting DNS queries fail precisely because it doesn't. Ale