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

Hector Santos <hsantos@isdg.net> Sat, 23 February 2019 19:00 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18841286E7 for <spfbis@ietfa.amsl.com>; Sat, 23 Feb 2019 11:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=MTeBVymg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=RBknDaBT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zRDWpEoPEZx for <spfbis@ietfa.amsl.com>; Sat, 23 Feb 2019 11:00:00 -0800 (PST)
Received: from mail.winserver.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id BE550130E09 for <spfbis@ietf.org>; Sat, 23 Feb 2019 10:59:59 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2230; t=1550948391; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=P6v8RuYFj4602tCm8hjnIfoGiRw=; b=MTeBVymgL3+/yFhsdi9ILQiwN09gwsjGV0L/zoeJbf0zNv8C8D/dQpSuSwJ7Ng FyMex4r0f1gOZhbg/q5JdroxhTeJZLag+xOVzgJ4oAWUdWSZGslH2Z3c5f3zhVVB NEl/SvwQE+FmtFxINLtxdMHN8/Qz3/z3CK2DTnkgZ/BlI=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for spfbis@ietf.org; Sat, 23 Feb 2019 13:59:51 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1355302072.1.3084; Sat, 23 Feb 2019 13:59:49 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2230; t=1550948087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fyrbf/s mdH6rhk7cQixiPrKpB9/Ce5qL4z6ZfunXq2s=; b=RBknDaBTmC1c4Ka4eO8xsWa piquVPLZHg9SrpR3CzOW7y8TJjOiWzFYwT27VHWk1i/mj0SeHftuEEG5RDJM1yaj +1ZkEyKRADJ2MTxdQAAl1HGNw4CxZgSWAfgiPwyUXCGBTnvxarolfkSTGzUA0qbj e0VffM2GjcXm9l0k7PC8=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for spfbis@ietf.org; Sat, 23 Feb 2019 13:54:47 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1903197283.9.355064; Sat, 23 Feb 2019 13:54:46 -0500
Message-ID: <5C719828.1000802@isdg.net>
Date: Sat, 23 Feb 2019 13:59:52 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
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)" <kboth@drkurt.com>, "dmarc@ietf.org" <dmarc@ietf.org>
CC: spfbis@ietf.org
References: <CABuGu1oxZvM+kf_pvE9B5LFVwr1wOrZGJDxDoGEgUqhHW9x9gQ@mail.gmail.com>
In-Reply-To: <CABuGu1oxZvM+kf_pvE9B5LFVwr1wOrZGJDxDoGEgUqhHW9x9gQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/R7fILwS2Tku-HDWwqOs989DOLpU>
Subject: Re: [spfbis] [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2019 19:00:04 -0000

On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
> With the growth of huge platforms that emit mail from the same common set
> of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up
> granting a DMARC pass to a lot more potential authors than most
> organizations would necessarily choose to grant.
>
> 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?
>

Kurt,

In general, in the name of cooperative competition, I am *always* in 
favor of a protocol "standard" that applies to all scales. So it 
shouldn't matter it its huge or tiny, the protocol applies equally.

It helps to use an example. For example:  gmail.com has:

v=spf1 redirect=_spf.google.com

which returns:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com 
include:_netblocks3.google.com ~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.

Keeping in mind the recursive complexity that can occur here with 
multiple layers of includes, it sounds like you are proposing an 
include prefix result should override matching result, including the 
default/final result.  So for example, using one the includes for 
gmail.com:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com 
?include:_netblocks3.google.com ~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.

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 have to recheck to how my legacy platform SPF code is designed for 
such a recursive include result override "change request" but is this 
what you are basically asking for here?



-- 
HLS