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

Hector Santos <hsantos@isdg.net> Sun, 24 February 2019 19:19 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 4351112D4F3 for <dmarc@ietfa.amsl.com>; Sun, 24 Feb 2019 11:19:44 -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=IMUSUwJ1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=vvu11Q80
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 i4nXibFALwcI for <dmarc@ietfa.amsl.com>; Sun, 24 Feb 2019 11:19:41 -0800 (PST)
Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E63F212D7F8 for <dmarc@ietf.org>; Sun, 24 Feb 2019 11:19:40 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2342; t=1551035973; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=qXkYlxj9J6UczRvCIVaxsvRIi1Y=; b=IMUSUwJ1USnaeScg6wj6ytoWnHrhoI9LParvH79BVZWDpVbpR2Ww2DHX0+FWqd RCv+w+zRURlOfrzwWIRn1mIe86ebec+ziFBceFDBWzUb6cbFpndzmNYAbCUh152U 808dX4p9ztuNehspnTUXmpAwx0Bs0I+Wm4s920o0ioQdU=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 24 Feb 2019 14:19:33 -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 1442883888.1.3908; Sun, 24 Feb 2019 14:19:32 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2342; t=1551035667; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KoPN+XD 74YhDIuJWe994JtWPb8GcO1q39Wwz4kEfZIY=; b=vvu11Q80hllrawce8ToFDR1 gNd//R5w4Mcdp7008S69BICSA/AuPReqYlW9CUoLC73svQJkCJFn2DMnNsM+ApNs 7MitW4XWRqStU7IRkIlTvHdIlvLr8xnzJZgtMvLQwANbvnCWqfGXxoBDWkRekVpz wFexmxiMBFZxA5PKOG28=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 24 Feb 2019 14:14:27 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1990777518.9.360968; Sun, 24 Feb 2019 14:14:26 -0500
Message-ID: <5C72EE3E.2060907@isdg.net>
Date: Sun, 24 Feb 2019 14:19:26 -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>
CC: spfbis@ietf.org, "dmarc@ietf.org" <dmarc@ietf.org>
References: <CABuGu1oxZvM+kf_pvE9B5LFVwr1wOrZGJDxDoGEgUqhHW9x9gQ@mail.gmail.com> <5C719828.1000802@isdg.net> <CABuGu1okzHxqO7DupVOWa2YafoYw6OgH9ogynXMCpOyKs3eF4g@mail.gmail.com>
In-Reply-To: <CABuGu1okzHxqO7DupVOWa2YafoYw6OgH9ogynXMCpOyKs3eF4g@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/tCJN_9Qf6dWYstHbW1jWnLkWE7w>
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: Sun, 24 Feb 2019 19:19:44 -0000

On 2/23/2019 2:56 PM, Kurt Andersen (b) wrote:

> On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote:
>
>> 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
> result.

+1

One question is, can each nested domain SPF record stand on its own, 
independent of its administrative domain's INCLUDE assertion to relax 
a potential hard pass/fail result to a relaxed neutral/softfail?  In 
other words, if d1 includes d2 which includes d3, it is possible to 
see d2 or d3 directly via a direct return path domain reference?

I think it continues to be an organizational issue, in particular when 
SPF network gets larger it is easier to see the complexities 
especially when augmenting SPF with additional protocols, i.e. DMARC.

It is also local policy with SPF trust considerations. For example, in 
our SPF parser, it has the following local policy options:

; SPF can return low trust results. A pass means the sender has
; a valid SPF record and is accepted. Softfail and Neutral means
; no match is found but rejection is not automatic.  Setting a
; true accept can provide a loop for potential spoofers who have
; SPF records and think they will allow them in.  The options
; below allow you to control this.

Accept-SPF-Pass      True            ; if false, continue testing
Accept-SPF-SoftFail  False           ; if false, continue testing
Accept-SPF-Neutral   False           ; if false, continue testing

In our case, continue testing means to "pass the buck" to the next 
real-time AVS filter to see what it can find.  Out of the box, it is a 
pass for Accept-SPF-PASS results which means SPF compliant "bad guys" 
with matching IPs get a pass.


-- 
HLS