Re: [spfbis] [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?

Hector Santos <> Sun, 24 February 2019 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B06C12D826 for <>; Sun, 24 Feb 2019 11:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=X+nZtqbX; dkim=pass (1024-bit key) header.b=0KyfkK6z
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i8SU9kRlcn5s for <>; Sun, 24 Feb 2019 11:19:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E09FE12D4F3 for <>; Sun, 24 Feb 2019 11:19:40 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2342; t=1551035973;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=qXkYlxj9J6UczRvCIVaxsvRIi1Y=; b=X+nZtqbXfIlomdSZe7Wj0M0MQxVUzZuiO8s2/7zTal8vQVIC0u7V2ROPSlvkxF SW1vYoPLHwuQN31eq4Zh734DZddDDXqGvNrnBwvqgQmH4gT72ejYk1Ia5b+PTIcL hICZuonYi5JQPBWX0Psu/nmsXB9w4qQruhlOoKwVIef5E=
Received: by (Wildcat! SMTP Router v7.0.454.6) for; Sun, 24 Feb 2019 14:19:33 -0500
Authentication-Results:; dkim=pass header.s=tms1;
Received: from ([]) by (Wildcat! SMTP v7.0.454.6) with ESMTP id 1442883779.1.3780; Sun, 24 Feb 2019 14:19:32 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2342; t=1551035667; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KoPN+XD 74YhDIuJWe994JtWPb8GcO1q39Wwz4kEfZIY=; b=0KyfkK6zXH4ODkTROIqbRng wP9YAqb2Gya1OYkgTpg4yw6OlyVUkcRCr+dG4O+tCo8Z254q7UcENvZh8Pa1q50Z PNm5kU2FyaGgDIwzZE4i8Y6iNM6Cg2iv5q3qLGM53UhXxQQfK0L2rxjxtrj0wvzO qM9M+g/XjH1QXJ74Wc7M=
Received: by (Wildcat! SMTP Router v7.0.454.6) for; Sun, 24 Feb 2019 14:14:27 -0500
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.6) with ESMTP id 1990777518.9.360968; Sun, 24 Feb 2019 14:14:26 -0500
Message-ID: <>
Date: Sun, 24 Feb 2019 14:19:26 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: "Kurt Andersen (b)" <>
CC:, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [spfbis] [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Feb 2019 19:19:44 -0000

On 2/23/2019 2:56 PM, Kurt Andersen (b) wrote:

> On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote:
>> Unless the conditions were limited to when this can be applied, I can
>> see where this can become really complex because of higher recursion
>> potentials.   You also have compatibility concerns as well.
> I think that the biggest problem with nested includes (I'm intentionally
> avoiding the "recursion" term because it should not be recursive or
> circular) is the table in RFC7208 section 5.2 which asserts that a neutral
> result from check_host ends up being treated as a "not-match" condition.
> The way I read that is that if d1.example has ?include:d2.example which in
> turn has a ?include:d3.example, then a check_host match on the d3.example
> record would not end up percolating up to d1.example as a neutral final
> result.


One question is, can each nested domain SPF record stand on its own, 
independent of its administrative domain's INCLUDE assertion to relax 
a potential hard pass/fail result to a relaxed neutral/softfail?  In 
other words, if d1 includes d2 which includes d3, it is possible to 
see d2 or d3 directly via a direct return path domain reference?

I think it continues to be an organizational issue, in particular when 
SPF network gets larger it is easier to see the complexities 
especially when augmenting SPF with additional protocols, i.e. DMARC.

It is also local policy with SPF trust considerations. For example, in 
our SPF parser, it has the following local policy options:

; SPF can return low trust results. A pass means the sender has
; a valid SPF record and is accepted. Softfail and Neutral means
; no match is found but rejection is not automatic.  Setting a
; true accept can provide a loop for potential spoofers who have
; SPF records and think they will allow them in.  The options
; below allow you to control this.

Accept-SPF-Pass      True            ; if false, continue testing
Accept-SPF-SoftFail  False           ; if false, continue testing
Accept-SPF-Neutral   False           ; if false, continue testing

In our case, continue testing means to "pass the buck" to the next 
real-time AVS filter to see what it can find.  Out of the box, it is a 
pass for Accept-SPF-PASS results which means SPF compliant "bad guys" 
with matching IPs get a pass.