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