Re: [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: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6B130E13 for <dmarc@ietfa.amsl.com>; Sat, 23 Feb 2019 11:00:02 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=lOG48ZrH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=eMGXLU8L
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 EopeTtuSZwOT for <dmarc@ietfa.amsl.com>; Sat, 23 Feb 2019 11:00:00 -0800 (PST)
Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id B81DB1286E7 for <dmarc@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=lOG48ZrHbp+ISkw+vrVnBIuAEV0U2zB0YIyqVjgXP4X6Fnf1w+cPsUXwzlCcn1 HEYWE6GqZBOe9sM3Uju/lFhpgy+UXDXnsf8mapFIOFjWkATflNgt/JDC+YEvkiTK 6EXZY+PbsfNMWj2mrWhbuP76Pbhb6Rx/BxMJHmBpzyI90=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@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.2820; 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=eMGXLU8LVp8Jc+zLhLhCDYS ojGUn1yxImGayeNty+GkSs4D3LXPa/nzpV0q5RT4BUz+xmyUUClSh5TPGFkT8X25 vXSEx5mFNzf7+D47u1yvRyT0350Hkm1eWijplqFMjntTR12kDOVrPqP1piUjK9Fp KA2+54afjJga3IqsOE1M=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@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/dmarc/Z2Tx4pM74LgVm9x4msVBajyFuZA>
Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2019 19:00:03 -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