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

"Kurt Andersen (b)" <> Sat, 23 February 2019 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A991130E77 for <>; Sat, 23 Feb 2019 11:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id muhcHd03BdOC for <>; Sat, 23 Feb 2019 11:56:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDDBC130EED for <>; Sat, 23 Feb 2019 11:56:46 -0800 (PST)
Received: by with SMTP id y13so4511890iop.11 for <>; Sat, 23 Feb 2019 11:56:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=Cy2gOLlXpKjIZi9QT5tJB1A0tpvw5xIPQLU3qWe/FslPg/d5RI6hV036xMTRVmHX6i aX+AZAa5vUopR7V/7T8kS/Nbm3hE+aTcDW3IQIrF2aQa7nyEBl3+FCKbeeqLpdAfg1sF es7T+6Fn81Ktdq1NcRzPpOlWCRP+/9SLoS9Wk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=Jxj7QKQoJMkQISWYtD7iciEUjdbbDUQWCus5Ry/7snEixXM4Iwzszh+0ueE2nSrLAR 0/0Bjr5Q15XepjsI6xL1lIoiUh4/Ua1ACXscj6mJ0gx6tJS2MSAAMH+V57d1Nd6C9HP9 C8Y8TcMPLjdyVz80Nj+Tc+bCMh6u31+fK6/AqtEJhyy3G/m2LfjVC25EpfhxRMyrbaG0 81heGM9dcaDYKFgS03Idt8NHOlbIcF9TUADsxtMCpzM+r1z2LeaQcd9y5iadR8whirVU MWt9HL6GByiNjX01/b5Gw/M9c6UFg2n4/Hob+W3BwerTNE258AFDxvNDxbdR4y5uoc7w 9wMQ==
X-Gm-Message-State: AHQUAua05fCb4bhHjbyPdKZNFek8Boat4jx3fxXyQatsfKLvSlnRNWIb TIK73glYQmHJlNbUz1YrPtf1Pf8RiLiBmsACNkzOu9zW
X-Google-Smtp-Source: AHgI3IbE89cyO328x7ZYxZ/g3V/cfEfkEXzkfDYRJaSUv2xWdKZRSAJw/WfWBTFqF+DAxZn8aZbgloV9uizfLIThGwQ=
X-Received: by 2002:a5d:8190:: with SMTP id u16mr6178195ion.238.1550951805745; Sat, 23 Feb 2019 11:56:45 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Kurt Andersen (b)" <>
Date: Sat, 23 Feb 2019 11:56:24 -0800
Message-ID: <>
To: Hector Santos <>
Cc: "" <>,
Content-Type: multipart/alternative; boundary="0000000000007211e80582951b87"
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: Sat, 23 Feb 2019 19:56:51 -0000

On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <> wrote:

> On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
> >
> > Instead of using the standard "(+)include:" approach, if domain owners
> used
> > "?include:" as their mechanism, then that would prevent the SPF result
> from
> > granting a DMARC PASS result when traffic is coming from one of these
> > massively included platforms. It would essentially force the DMARC result
> > to be driven only by the DKIM evaluation.
> >
> > Thoughts?
> >
> it shouldn't matter it its huge or tiny, the protocol applies equally.

Quite so - however, some of the mechanisms and common usage patterns do
differ depending on the scale and complexity of the sender asserting the

> It helps to use an example. For example: has: [redirect elided]
> v=spf1
> ~all
> The SPF processor result SHOULD be based on each one.  In this case, each
> include results in a softfail (~all) when there is no match.

Note that terminal "all" mechanisms are ignored in the handling of the
include evaluation (RFC7208 section 5.2).

> it sounds like you are proposing an include prefix result should override
> matching result, including the default/final result.

No, I'm suggesting that the neutral mechanism prefix should be promoted as
a "better way" to cite includes of large common sending platforms. "Better"
than the default pass evaluation result.

So for example, using one the includes for
> v=spf1
> ? ~all
> where you want to override the results of _netblock3 with a neutral
> result rather than use the matching result or final/default result of
> the specific include.

Not an override - just a different result.

> 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