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
- [spfbis] Should we encourage the use of SPF "soft… Kurt Andersen (b)
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Tim Wicinski
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Hector Santos
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Vladimir Dubrovin
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Kurt Andersen (b)
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Dotzero
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Hector Santos
- Re: [spfbis] Should we encourage the use of SPF "… Alessandro Vesely
- Re: [spfbis] [dmarc-ietf] Should we encourage the… Brandon Long