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

Dotzero <dotzero@gmail.com> Sat, 23 February 2019 21:03 UTC

Return-Path: <dotzero@gmail.com>
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 0FC7C130EE5; Sat, 23 Feb 2019 13:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OHLDPTiGNZDt; Sat, 23 Feb 2019 13:03:44 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3D0130ECD; Sat, 23 Feb 2019 13:03:43 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id t18so5925234wrx.2; Sat, 23 Feb 2019 13:03:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dlFAv+WYqIWxtzz0emGRF2Dkvqd8OQ+1UAabmXAQgX4=; b=SHhXjUde02ePlpxLuTfKKzQZbZxfSo9caaWBlORMxoiF6bFAvLtvRSQ9/R3VqbtL9e iobDSk9OYSdqjKWOxT9rQf0rgwx1fEXuIKViRGcLQ9B20kk3/5Si1zuOu57Up5uMbGYO +RSffq7kdpmVWj/fB4Khu5DwPg8Uxl0wSqI2BnnRHbH9TnXY+aRItunyTGuE9k0IlbMZ QeGmPq5oFXS4P61RE6mvY+7i/H0nR37eHLHqKKZKnb9suM24OzoGLDUF51ZP+wixqK1W jmpjUPbGB669k6vAmphrAp0oLLwb0znYIZfVAZgWMv7FiTlSQvphsGA76rwXiX0Ix9/i HjFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dlFAv+WYqIWxtzz0emGRF2Dkvqd8OQ+1UAabmXAQgX4=; b=qv2TBlRMIYOoEMqi94ThahOpkpITOQLx2XaGPDTzUdcUwylEMzrwui9W5zcb+TbjHs 1VaIp4nF4J+nEajuo1lrL87cxUyKQbkjgITcjepF+LE0vv5Mn5KPpaDhYRm2qQ1IVlkl oGBa1Mozpn5VIw/gldBTmSmjClWaLq1N/YIjx6+Di2rx4Ux7c29ire8NWRtypcc8dO93 cS8l3/jJOpDY3OEMkZcFNAxGepsiiGi9IhkrMM++5ypPJpqYDgZem429lNrtuw1/ldnk QSA6DSASvlJl+FUnBH+eKNQVw4c62S0AcVpQRiYQh4ZK1YUuR7vwCSxxCriJHoV4zzkj lw0Q==
X-Gm-Message-State: AHQUAub4FJV2HMPYZSkRtnp8/gssW6X0ajF1GZu0U8sPP7xAS08R+YKQ xfJI08cXMCiJr8DNAvme0Ey/tauZ4OP5IBfU5ES4Cw==
X-Google-Smtp-Source: AHgI3IaeJElp1GWkbOawZS/E89CpVnvs+snjnTOxmSSfztzqz7oIjS+RLkbXt4CQajA5dwp491aET67T5U8ZMORMVSs=
X-Received: by 2002:adf:d845:: with SMTP id k5mr7490015wrl.145.1550955821984; Sat, 23 Feb 2019 13:03:41 -0800 (PST)
MIME-Version: 1.0
References: <CABuGu1oxZvM+kf_pvE9B5LFVwr1wOrZGJDxDoGEgUqhHW9x9gQ@mail.gmail.com> <5C719828.1000802@isdg.net> <CABuGu1okzHxqO7DupVOWa2YafoYw6OgH9ogynXMCpOyKs3eF4g@mail.gmail.com>
In-Reply-To: <CABuGu1okzHxqO7DupVOWa2YafoYw6OgH9ogynXMCpOyKs3eF4g@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Sat, 23 Feb 2019 16:03:32 -0500
Message-ID: <CAJ4XoYd2cE8yUDbPJEC=37qWGmdKUgS9Mua6N8Z5Nz8jxujazw@mail.gmail.com>
To: "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: Hector Santos <hsantos@isdg.net>, spfbis@ietf.org, "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4efcd0582960a90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/4DNQbjoNkWnxKV3Tf4JwENOQdlE>
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 21:03:47 -0000

Just provide a DKIM only mechanism/option.

Michael Hammer

On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) <kboth@drkurt.com>; wrote:

> On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <hsantos@isdg.net>; 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
> record.
>
>
>> It helps to use an example. For example:  gmail.com has: [redirect
>> elided]
>>
>> 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.
>>
>
> 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 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.
>>
>
> 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
> result.
>
> --Kurt
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>