Re: [spfbis] Question about SPF checks based on RFC 7208

<> Mon, 02 May 2016 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADFB012D137 for <>; Sun, 1 May 2016 20:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9r3VPSRA8SVy for <>; Sun, 1 May 2016 20:31:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99C7212D0C1 for <>; Sun, 1 May 2016 20:31:56 -0700 (PDT)
Received: from FRANKB ([]) by (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$> <> <> <5060996.Nvmh582kyi@kitterma-e6430> <>
In-Reply-To: <>
Date: Sun, 1 May 2016 22:31:46 -0500
Message-ID: <000b01d1a423$288cc5e0$79a651a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
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: <>
Subject: Re: [spfbis] Question about SPF checks based on RFC 7208
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 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.


-----Original Message-----
From: spfbis [] On Behalf Of Stuart D. Gathman
Sent: Sunday, May 01, 2016 9:44 PM
To: Scott Kitterman <>;
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
> if neither A nor AAAA exist.  Implementations could either do the extra
> or just not count it as void if only looking up one.  From an
> 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