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

S Moonesamy <> Mon, 02 May 2016 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8978312D59D for <>; Mon, 2 May 2016 09:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.786
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: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=Hvpfbrn8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=HJ4EZ76L
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vLPNvCjHHh7G for <>; Mon, 2 May 2016 09:48:54 -0700 (PDT)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id 2B2D012B024 for <>; Mon, 2 May 2016 09:48:54 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (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;; 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;; s=mail; t=1462207732; x=1462294132;; bh=DfXMW+RaayVeJnA5mKsRYcBmqkXN7MwcHGGh7itxPMk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HJ4EZ76LPA7ldBMLwBDwt3pWnexAti6s2862Tm+2ZQc7CMaoONqzreiGaZcmzFjF8 iOg7f0vHWS0Yby4mU8pC5TRAN4gXaAze69+x5uMeOlXYAi/EW5Ur1JdK/Gq7482R5u IQEThEz5gV82riABCkwLfoEpm0pbfQzd5ONXMrAg=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 02 May 2016 09:48:00 -0700
To: Kurt Andersen <>,
From: S Moonesamy <>
In-Reply-To: <CABuGu1qf8tdzvwy+fhaTqKNyKQ1L0San8f54Cu-XbZXDLwn8fw@mail.g>
References: <002101d1a342$c93e3000$5bba9000$> <> <>
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-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 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? :-)

S. Moonesamy