Re: [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 76BAC130E5A 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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oERH1-xOmEb7 for <>; Sat, 23 Feb 2019 11:56:47 -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 DF307130F06 for <>; Sat, 23 Feb 2019 11:56:46 -0800 (PST)
Received: by with SMTP id k21so4497279ior.13 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=L427ErtYhRQ+WcYUtYU2XLutQ+nZ+MOoqysAkHrN/uqAhZu2WQQmJgI3d3M8UhA/pT ho0ei4qXit23Nwksr8FRwAqMQV9SeK3xw/ZwnADdLL3+kEv+NJHEC2joTWhYwdtXkxy2 IhsXgs7V5i9xrGRepetxcDhEgm7ii1kg4WjZOEgj/xYzM0ONKjgraZ6fYuQHWbk/8uYk 1GjpR6wfCmNXCQvu0NZur6c8WfBQL1jc2nVPyjlRJXT0yeVQ24WYpqgyU6TpWPYtEpKU goXf7ufF+PQqYxTgQXjdBNVkMDDvFBDwEU7qd/2+HuGK9EOq2n1GiHQT8U/3VSC5sDsO toiQ==
X-Gm-Message-State: AHQUAuYKNz1DMToVwDwWnRJ8bomzUTh9EnuDdfRe6OhE7O8WDcWyXA5s Zk4fTDclGJcABiO7hxp+xazDa/Wf3UCUWrmwZ3pD7w==
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: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
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