From nobody Sat Apr 30 17:45:47 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 C1C9712D10F for ; Sat, 30 Apr 2016 17:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_FAIL=0.001] autolearn=no 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 5QywFmm2Ut1m for ; Sat, 30 Apr 2016 17:45:44 -0700 (PDT) Received: from premieronline.net (mail.premieronline.net [IPv6:2607:fe28:0:4000::20]) (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 F066612B018 for ; Sat, 30 Apr 2016 17:45:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from FBULKPC (unverified [199.120.69.4]) by premieronline.net (SurgeMail 7.1e) with ESMTP id 81941282-1729245 for ; Sat, 30 Apr 2016 19:45:41 -0500 From: "Frank Bulk" To: Date: Sat, 30 Apr 2016 19:45:40 -0500 Message-ID: <002101d1a342$c93e3000$5bba9000$@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+CRYh0ldjGGZQ== Content-Language: en-us X-Originating-IP: 199.120.69.4 X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.99/21511/Sat Apr 30 11:38:04 2016 v0.65-36 X-SpamDetect: ********: 8.0 sd=8.0 0.87((!X-Verify-Helo:+OK), (X-myrbl:unknown)) [nnot=0, ng=0, nsum=0, nb=0, nw=0, 4.82] X-Aspam: Words 0.0 -bearings -quotation -truck +returned -pivot -scales -sizes -friction -2nd X-Aspam: External-IP matched 199.120.69 2.0 X-Aspam: Best match was sample aspam_good\m5.msg X-Aspam: Total 2.0 X-LangGuess: English X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=13 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 136, in=6783, out=0, spam=0 ip=199.120.69.4 Archived-At: Subject: [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: Sun, 01 May 2016 00:45:46 -0000 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.)." 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? 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. Frank 5.4. "mx" This mechanism matches if is one of the MX hosts for a domain name. mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then it performs an address lookup on each MX name returned. The is compared to each returned IP address. To prevent denial-of-service (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be followed. If the MX lookup limit is exceeded, then "permerror" is returned and the evaluation is terminated. If any address matches, the mechanism matches. Note regarding implicit MXes: If the has no MX record, check_host() MUST NOT apply the implicit MX rules of [RFC5321] by querying for an A or AAAA record for the same name. From nobody Sat Apr 30 18:08:58 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 38FD612B045 for ; Sat, 30 Apr 2016 18:08:56 -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 2nFAPRSlFPRc for ; Sat, 30 Apr 2016 18:08:53 -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 CA22E12D1AD for ; Sat, 30 Apr 2016 18:08:53 -0700 (PDT) Received: from [192.168.111.103] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 940C2C40152; Sat, 30 Apr 2016 20:08:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1462064932; bh=buE9yMxuLcI7BksK7t/m/y2qFIlcMDfFH0AUdZLnx4A=; h=In-Reply-To:References:Subject:From:Date:To:From; b=nG4wpEs7hjrc9sDlEfmc2x1SyLrJrhipNwjW+qr5XOoMBRkyNHk4WtjcPzbL2QUFQ jl5gJRC4hSdxPraoR07yvhqKnW+JZ8B1wyTY0qbiTjls32uJj21Up00Nnx9v/5J/Oo 1GOdPlNDL0lY3CGjOpajvRdQG2hkpvVzVFP2Z23s= User-Agent: K-9 Mail for Android In-Reply-To: <002101d1a342$c93e3000$5bba9000$@iname.com> References: <002101d1a342$c93e3000$5bba9000$@iname.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 30 Apr 2016 21:08:50 -0400 To: spfbis@ietf.org Message-ID: <255DF248-2870-4727-9F10-259598592509@kitterman.com> 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: Sun, 01 May 2016 01:08:56 -0000 On April 30, 2016 8:45:40 PM EDT, 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.)." > >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? > >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. > >Frank > > >5.4. "mx" > > This mechanism matches if is one of the MX hosts for a domain > name. > > mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] > > check_host() first performs an MX lookup on the . Then > it performs an address lookup on each MX name returned. The is > compared to each returned IP address. To prevent denial-of-service > (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be > followed. If the MX lookup limit is exceeded, then "permerror" is > returned and the evaluation is terminated. If any address matches, > the mechanism matches. > > Note regarding implicit MXes: If the has no MX record, > check_host() MUST NOT apply the implicit MX rules of [RFC5321] by > querying for an A or AAAA record for the same name. 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. Scott K From nobody Sat Apr 30 21:14:42 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 6D18512B029 for ; Sat, 30 Apr 2016 21:14:40 -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 DTnG9P2091gH for ; Sat, 30 Apr 2016 21:14:37 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 D026712B016 for ; Sat, 30 Apr 2016 21:14:37 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d62so142254152iof.2 for ; Sat, 30 Apr 2016 21:14:37 -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=OFwnhRd8UYhH3vNdB50gused74t3ZJtwcz3Wrm2cI9I=; b=e+uAY1mejV5KKna9Duza1hXsWOnmnjNXhb4yP6eEUxqYqiTTJONISdeZarLTFlm5vt eB2CD/5+F2DNqvv7r2qsemxZHD0sEC8F/ql3H41DmB5cGSi8kH/DnmI6DUSJqh3paP+A erQW8zmegQLIyq2vwnQMOktpm4uEUYa3VBWuk= 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=OFwnhRd8UYhH3vNdB50gused74t3ZJtwcz3Wrm2cI9I=; b=WCOeLmtHTeSOjlgvAMJeiQLvyskTLiCjy8cD52rWbm0VrbFMqJxNZpPv7h4506C7j3 bAPB64f2Iv2f9+YyOFtLQ5iU5INjs9JsTErcYS5cBWtuvbmma0zmI9jhwSMV9PItxQDy 4rvoLTewWIrNp71Yfna3ZFOUCtgJeza6yCfXLa7qhysp05o0mmrgXp3lWun+kNu2y9e5 Z+ix8s+qwUYGQpuhghWdU9Maty+PQHEFx3QinA8i+b2zLVJNrANLaMhaErsHqaBNpVD1 D/wpWbL03xWBYJYy7OPyQjRwwaA8+uYCCZ6Ff+BxVLL7jdGNEM+F9pyTDoc8/hhzaBrt zqFA== X-Gm-Message-State: AOPr4FUTtc5xRhMXP4KGwnG/q0lGNBo43r9IRjz2DW0YVrHYxPv8pyCYtiVGTVtaY9/GbIAu+bSJbAZ0tUn0sA== MIME-Version: 1.0 X-Received: by 10.107.129.75 with SMTP id c72mr34264596iod.102.1462076077186; Sat, 30 Apr 2016 21:14:37 -0700 (PDT) Received: by 10.107.32.13 with HTTP; Sat, 30 Apr 2016 21:14:37 -0700 (PDT) In-Reply-To: <255DF248-2870-4727-9F10-259598592509@kitterman.com> References: <002101d1a342$c93e3000$5bba9000$@iname.com> <255DF248-2870-4727-9F10-259598592509@kitterman.com> Date: Sat, 30 Apr 2016 21:14:37 -0700 Message-ID: From: Kurt Andersen To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a113f99b03763620531c01d06 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: Sun, 01 May 2016 04:14:40 -0000 --001a113f99b03763620531c01d06 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 30, 2016 at 6: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. > > Scott K Scott, your own analysis tool also has a problem with the scenario that was described as do several others that I checked. When the connection is coming in on an IPv6 connection, it seems that only AAAA records are being sought in the resolution of the MX records into IP addresses. When the first two that are checked result in no AAAA found, it is more or less game-over according to the 7208 spec. This seems like a lurking time-bomb in SPF as people begin sending mail on IPv6, potentially before they enable inbound connections on IPv6. --Kurt Andersen --001a113f99b03763620531c01d06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 30, 2016 at 6:08 PM, Scott Kitterman <spf2@kitterman.com>= wrote:


I think they are just wrong.=C2=A0 If either an IPv4 or IPv6 ad= dress is returned it's not a void look up.=C2=A0 That's described a= t the end of 4.6.4 and is, I think clear.=C2=A0 I'd report it as a bug.=

Scott K

Scott, your own analysis tool also = has a problem with the scenario that was described as do several others tha= t I checked. When the connection is coming in on an IPv6 connection, it see= ms that only AAAA records are being sought in the resolution of the MX reco= rds into IP addresses. When the first two that are checked result in no AAA= A found, it is more or less game-over according to the 7208 spec. This seem= s like a lurking time-bomb in SPF as people begin sending mail on IPv6, pot= entially before they enable inbound connections on IPv6.

--Kurt Andersen
--001a113f99b03763620531c01d06--