From nobody Thu Jun 23 10:19:21 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 A94F112D511 for ; Thu, 23 Jun 2016 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 k5KETp9FB3s7 for ; Thu, 23 Jun 2016 10:19:18 -0700 (PDT) Received: from premieronline.net (mail.premieronline.net [IPv6:2607:fe28:0:4000::10]) (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 387FC12D1F0 for ; Thu, 23 Jun 2016 10:19:18 -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.2b) with ESMTP id 111845118-1729245 for multiple; Thu, 23 Jun 2016 12:19:14 -0500 From: "Frank Bulk" To: "'S Moonesamy'" , , References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> In-Reply-To: <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> Date: Thu, 23 Jun 2016 12:19:14 -0500 Message-ID: <000501d1cd73$5d6a0f60$183e2e20$@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+CRYh0ldjGGZQBMRlyACj/hLUA= Content-Language: en-us X-Originating-IP: 199.120.69.4 X-Virus-Status: Clean X-Virus-Scanned: ClamAV 0.99/21776/Thu Jun 23 05:18:10 2016 v0.65-40 X-SpamDetect: ********: 8.0 sd=8.0 0.93((Received:for multiple), ((X-myrbl:unknown), (!Dear sir))) 0.87((!X-Verify-Helo:+OK), (X-myrbl:unknown)) [nnot=0, ng=0, nsum=0, nb=0, nw=0, 7.73] X-Aspam: Words 0.0 -coupon -spent -citizen -subsequently -returned -livery -browser -e-mails -purchased X-Aspam: External-IP matched 199.120.69 2.0 X-Aspam: Best match was sample aspam_good\m7.msg X-Aspam: Total 2.0 X-LangGuess: English X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=21 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 190, in=8922, out=0, spam=0 ip=199.120.69.4 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: Thu, 23 Jun 2016 17:19:20 -0000 I'm looping back into the conversation again because we've had two different ag-business customers get bitten by this in the last two days, trying to send emails (via IPv6) to the USDA who apparently uses an SPF implementation that checks for the MX record's AAAAs and fails on too many void lookups. The workaround, in both cases, has been for us to move 'mx' to end of the ag-business' SPF record. Scott's suggestion that the RFC clarify that that an mx mechanism is only void if neither A nor AAAA exist is a good one -- would we also need to state that those void lookups don't count against the maximum of 10 DNS lookups? I'm not an RFC writer, but I'd be happy to review any new one or erratum. Kind regards, Frank -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com] Sent: Monday, May 02, 2016 2:59 AM To: Frank Bulk ; spfbis@ietf.org Subject: Re: [spfbis] Question about SPF checks based on RFC 7208 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 Fri Jun 24 11:14:38 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 316B112B05B for ; Fri, 24 Jun 2016 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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=Wk3tNMdc; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=1m6iVXKA 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 k0MW8B5sq2bI for ; Fri, 24 Jun 2016 11:14:35 -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 E5A7012B037 for ; Fri, 24 Jun 2016 11:14:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.82.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u5OIEMbk027458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 11:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1466792074; x=1466878474; bh=RSpZf6J4FL5XwOxhcENcqSZfAXe+fjprlrmFAEUKI8s=; h=Date:To:From:Subject:In-Reply-To:References; b=Wk3tNMdcI5sxzKRj8jrKIF/OGmIGjriYhJ7SxraksCxIvERGfy7iuLwehwaFn60+I u67dira+6fRAw+Jt+xnjkTBVH0TsF90mTky425vyWwYbtAL6elhyuzGDK8db4QXKtW 6HMjRaRGNcUS/z+EIpth70DTBPN9aPeFVeeNGITw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1466792074; x=1466878474; i=@elandsys.com; bh=RSpZf6J4FL5XwOxhcENcqSZfAXe+fjprlrmFAEUKI8s=; h=Date:To:From:Subject:In-Reply-To:References; b=1m6iVXKAUwBAvS4FyCuarLfOC3NHXd3ww2mYHwU/gaHZGhKox/0+J5VKy2xJ1tnn0 37dMQbYPD47oYddibyAPcVOvphMse7NQfO7UypR+i9mtTPWC4+8GQvgGR5AaApbmRX vJa0L8f8T5tBNVl3WbgGGyOaq3Hahk7T63tMmrUo= Message-Id: <6.2.5.6.2.20160624110436.0a357d98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Jun 2016 11:12:30 -0700 To: Frank Bulk , spfbis@ietf.org From: S Moonesamy In-Reply-To: <000501d1cd73$5d6a0f60$183e2e20$@iname.com> References: <002101d1a342$c93e3000$5bba9000$@iname.com> <6.2.5.6.2.20160502003646.101fc9c8@resistor.net> <000501d1cd73$5d6a0f60$183e2e20$@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: Fri, 24 Jun 2016 18:14:37 -0000 Hi Frank, At 10:19 23-06-2016, Frank Bulk wrote: >I'm looping back into the conversation again because we've had two different >ag-business customers get bitten by this in the last two days, trying to >send emails (via IPv6) to the USDA who apparently uses an SPF implementation >that checks for the MX record's AAAAs and fails on too many void lookups. >The workaround, in both cases, has been for us to move 'mx' to end of the >ag-business' SPF record. I'll look into this in the next few weeks. Regards, S. Moonesamy