From nobody Sat Feb 23 10:07:57 2019 Return-Path: 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 D08F3130DD6 for ; Sat, 23 Feb 2019 10:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 lB8NUu0eOZra for ; Sat, 23 Feb 2019 10:07:53 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 C937A12F19D for ; Sat, 23 Feb 2019 10:07:53 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id e24so7580803itl.1 for ; Sat, 23 Feb 2019 10:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to:cc; bh=OxrETRP9W0S7/ucM2//IinFG/6Tl9DIFogHtWfaBGt8=; b=RL8pERAvCXrhNeVqs+2oHJ575lLtzgnYagmS6K70zYmyO9KRIVVz0XnR03M7GdMkKK xppJiRRxOCvqM8xzjxCfiHzEC0rNL3VBey1Xr0VLGVccVkdYbVqyTXnmk+hM0TWz2uwY 1vD+HIKRjUxHUcOCGyU4BDl36vq1A29mxd23g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OxrETRP9W0S7/ucM2//IinFG/6Tl9DIFogHtWfaBGt8=; b=osZmuPUdKlt6AKLlgOpP9JtHkWIkz3HpVDDnwPdzp6/NvZTdu53NJGTF9TXWfoSkCy QnJazpPXJBacKNxEZtrLTikMN9yhrPR9v8wR41OkZZKqozZbrPjtMKoa5jazpwH0UxeW KTlEVExiTJY8bWNgJGLJ/kGcyn4Oc5ZwgTDcEac9s+13rHJdJrZyMvHm2x0fIEjRIUiz pOkkaB9Qh43V9K9CRvNR2Pm8peZuaQar2XccTtXXezxEFAl621GhbiD9Gqnu8MynhHUA dvtfUOESS0FqZIKRRF0+AcIw5vVKqQUn6NXZUVVmt3KS39WcJHrDHXH3scqy0Xa42IlT YwiQ== X-Gm-Message-State: AHQUAubvk7XltLct6A4OpgT9LOgP6P4HXOTdMmwz43Kw9+XC8Q4Zznwh wyE9loFkcR1CWp45V0/+cvjLXnWbtNW6jW1aziTxOA== X-Google-Smtp-Source: AHgI3IbJwDd/9Ex4/FjEuSFducVUs4L2KkSKQSMhQ803l6HszyVq8cqs2KUWi6yOBaHI5jPSOs8PcVqnvS6LG7elLps= X-Received: by 2002:a24:3c05:: with SMTP id m5mr6037961ita.78.1550945272700; Sat, 23 Feb 2019 10:07:52 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Sat, 23 Feb 2019 10:07:31 -0800 Message-ID: To: "dmarc@ietf.org" Cc: spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000000bbbb5058293963e" Archived-At: Subject: [spfbis] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 18:07:56 -0000 --0000000000000bbbb5058293963e Content-Type: text/plain; charset="UTF-8" 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 Andersen (I'm copying the spfbis list too because there may be folks lurking there who are not on the DMARC list) --0000000000000bbbb5058293963e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 &= quot;include" ends up granting a DMARC pass to a lot more potential au= thors than most organizations would necessarily choose to grant.=C2=A0
=
Instead of using the standard "(+)include:" approa= ch, if domain owners used "?include:" as their mechanism, then th= at would prevent the SPF result from granting a DMARC PASS result when traf= fic is coming from one of these massively included platforms. It would esse= ntially force the DMARC result to be driven only by the DKIM evaluation.

Thoughts?

--Kurt Andersen

(I'm copying the spfbis list too because there = may be folks lurking there who are not on the DMARC list)
--0000000000000bbbb5058293963e-- From nobody Sat Feb 23 10:39:19 2019 Return-Path: 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 93F7A130DE9; Sat, 23 Feb 2019 10:39:17 -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 FdnC2HRpRdMU; Sat, 23 Feb 2019 10:39:15 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 DFDDD12008F; Sat, 23 Feb 2019 10:39:14 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id p18so4455271ioh.5; Sat, 23 Feb 2019 10:39:14 -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=4xHEsg0hs5sFBAHveQfbBLV0VSwGDNlzUYLi6wI0yxg=; b=RHfpVJyokNw9hpu5ZaNNQ54jjx5uLeFxEFcn43m/kmMbchPBlWGFUiJ6/TjMAKuM4n rA5smKUwhaYFrLiuygOrx+uJWk/BMh/luTFnXOhvileGQUh5YZrf2SiMMx7phsWEWpuk iekGa3Y92LMXU8D4wCQT/Sf/VuulQdKSoycPrIkLfSOWSnMbOLw7v4+uxJR67qlxul+z S6YFGn5xN/5yvqbphC9qfzwI1mnwWOZvMEfP45FOlQe9Q09vhvKzGk//9RqJHtWjfRpg ds1SSh2zklptLI7uGa2kGNGSS0NOkqtU8RNzdRV+RMSjXm/o38R1tlE2VI3OEaK/bJ/Y e5Fg== 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=4xHEsg0hs5sFBAHveQfbBLV0VSwGDNlzUYLi6wI0yxg=; b=sxL4Wx7iB1KbFanRUS6xSE+f0jE8eeA1b8xE9AB8qVHtM5J/NTcuybcS7lMc+Y6IpN DmvgffPOU+ihj+ZhHTf5BInUzCzVb7/dqDSFjHaJNK7mZX1/FdkxKkvQ9WRvJcSEGU6Z 88KfCOeMIIZzm/0Obd7pgDLn0iqjxCIF0VI8njffowPYTmVpoWC2J0e159za/gl07Ca4 mHgc+NkT6+wTf/QCbaVGWjkH+jeIpqEkSgyMZ5wM7u9PYqpzq8v8NeKgwSOW7WyQNTYD 5to0Xi4/lBXmK23unq71GATvflEVklQtZfnUwajZpgPzcGWo0QR6G1DRnihCFc3dGY96 I6tw== X-Gm-Message-State: AHQUAubOUlwuGn9nffi7nwJbah/sHlJv+tq0CaXe2cwWOOhAI2kfZ5lp zwBQnp55o82Qz9xyHEPRfcaqJ0pxZM/OuWxd968= X-Google-Smtp-Source: AHgI3IYCCjORNnROjuuO+2kdpF7RTWSs4qhZeCcDU82leDABKU8c7YdNy0MWCbSTziffn9SKoMkpjZaMLh0wxmuxAQM= X-Received: by 2002:a5e:8d0e:: with SMTP id m14mr5909049ioj.30.1550947153771; Sat, 23 Feb 2019 10:39:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Sat, 23 Feb 2019 13:39:02 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a814d05829406cf" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 18:39:18 -0000 --0000000000002a814d05829406cf Content-Type: text/plain; charset="UTF-8" Kurt This is pretty interesting. I've been assisting several teams as we have been (very) slow rolling the DMARC policy out of reporting through quarantine into reject. They been pulling all the disparate teams into deploying DKIM, but I was pointing out they have been guessing on who is using DKIM vs. being in our datacenter (and thus our SPF records). Doing the ?include would assist especially on operational type deployments. Tim On Sat, Feb 23, 2019 at 1:08 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 Andersen > > (I'm copying the spfbis list too because there may be folks lurking there > who are not on the DMARC list) > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002a814d05829406cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kurt

This is pretty interesting.=C2=A0 = I've been assisting several teams as we have been (very) slow rolling t= he DMARC policy out of reporting through quarantine into reject. They been = pulling all the disparate teams into deploying DKIM, but I was pointing out= they have been guessing on who is using DKIM vs. being in our datacenter (= and thus our SPF records).=C2=A0
Doing the ?include would assist especi= ally on operational type deployments.=C2=A0

= Tim

On Sat, Feb 23, 2019 at 1:08 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
With the growth of huge platforms that emit mail fr= om the same common set of IPs (such as GSuite, O365, or large ESPs), regula= r SPF "include" ends up granting a DMARC pass to a lot more poten= tial authors than most organizations would necessarily choose to grant.=C2= =A0

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 w= hen traffic is coming from one of these massively included platforms. It wo= uld essentially force the DMARC result to be driven only by the DKIM evalua= tion.

Thoughts?

--Kurt An= dersen

(I'm copying the spfbis list too becaus= e there may be folks lurking there who are not on the DMARC list)
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002a814d05829406cf-- From nobody Sat Feb 23 11:00:10 2019 Return-Path: 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 ; 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 ; 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 ; 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 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)" , "dmarc@ietf.org" CC: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Sat Feb 23 11:35:23 2019 Return-Path: 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 E925E12F1AC; Sat, 23 Feb 2019 11:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 Fs1Bp7g2YewT; Sat, 23 Feb 2019 11:35:17 -0800 (PST) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24D512870E; Sat, 23 Feb 2019 11:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=ovTN3St5/G0cNoq/LN6G24V8hJ7DaC2gMzZom5psiZc=; b=b5uU2qOV6yUimVk8V2QTxuQd9bVq9rdKStTcyOuPzSVtWLAvUPC8dOmJaPctJvFMg7Zjz1ZdirsjfMCcXFSPn/CC1U9GgoPJNdIsFfdIKVVobbD1sFS3KMwvv7uMhiTLODL+X98iMW4WOdVE4K/wD1qzbn4ZMcFYfSrzwlZfT7A=; Received: by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1gxd4q-0006Ld-Vk; Sat, 23 Feb 2019 22:35:13 +0300 To: "Kurt Andersen (b)" , "dmarc@ietf.org" Cc: spfbis@ietf.org References: From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Sat, 23 Feb 2019 22:34:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F1534899CDA50ABE1BEA522A" Content-Language: en-US Authentication-Results: smtp43.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 05BA0F6AFA56F0D4CFECA6684D9AEF712F75FAB5E32BBE4E58F036E8D5F096F0 X-77F55803: CF41D5CA8C6D3C0C7F9F52485CB584D75945EECDF71DA5B36C04DA8CBDE389CF8AC1FD7ED340D6969F2CE8D267E3E01208D917D6130B1AFB X-7FA49CB5: 0D63561A33F958A58D5E7056FF0EE46A45B44C49A58D2D93403C3DAF84A848BA8941B15DA834481FA18204E546F3947CEDCF5861DED71B2F389733CBF5DBD5E9C8A9BA7A39EFB7666BA297DBC24807EA117882F44604297287769387670735209ECD01F8117BC8BEA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C224931C0090ACECF247D3AA81AA40904B5D9CF19DD082D7633A0E7DDDDC251EA7DABD81D268191BDAD3D78DA827A17800CE79C648FADE979CBA9CD04E86FAF290E2D40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE797E5B4CC63BA20E2E8D63C8E5283DC2875ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85C89CB6F4BC741D5127F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-Mailru-Sender: C5364AD02485212F436E8F04DAC399FA05BA0F6AFA56F0D4CFECA6684D9AEF7132DC3239582C72120BAB88DF5F162B013DDE9B364B0DF2892C9BDF2E11C8A96B6C1AAAEF533A82E5AE208404248635DF X-Mras: OK Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 19:35:21 -0000 This is a multi-part message in MIME format. --------------F1534899CDA50ABE1BEA522A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit It's bad idea, because "?" does not grant SPF authentication. SPF is important even if message is DKIM signed and regardless of DMARC, because it authenticates envelope address. As an example, NDR/MDN  may not be generated to envelope address which is not SPF authenticated, we actually use this rule in practice to eliminate secondary spam. GSuite, O365 and large ESPs should not allow to use unvalidated/spoofed e-mail address. If somebody allows to spoof sender, there is also a good chance it DKIM signs spoofed message, because DKIM signature is applied by the same party. 23.02.2019 21:07, Kurt Andersen (b) пишет: > 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 Andersen > > (I'm copying the spfbis list too because there may be folks lurking > there who are not on the DMARC list) > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------F1534899CDA50ABE1BEA522A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It's bad idea, because "?" does not grant SPF authentication. SPF is important even if message is DKIM signed and regardless of DMARC, because it authenticates envelope address. As an example, NDR/MDN  may not be generated to envelope address which is not SPF authenticated, we actually use this rule in practice to eliminate secondary spam.

GSuite, O365 and large ESPs should not allow to use unvalidated/spoofed e-mail address. If somebody allows to spoof sender, there is also a good chance it DKIM signs spoofed message, because DKIM signature is applied by the same party.

23.02.2019 21:07, Kurt Andersen (b) пишет:
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 Andersen

(I'm copying the spfbis list too because there may be folks lurking there who are not on the DMARC list)

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



-- 
Vladimir Dubrovin
@Mail.Ru
--------------F1534899CDA50ABE1BEA522A-- From nobody Sat Feb 23 11:56:59 2019 Return-Path: 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 9A991130E77 for ; Sat, 23 Feb 2019 11:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 muhcHd03BdOC for ; Sat, 23 Feb 2019 11:56:48 -0800 (PST) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 DDDBC130EED for ; Sat, 23 Feb 2019 11:56:46 -0800 (PST) Received: by mail-io1-xd43.google.com with SMTP id y13so4511890iop.11 for ; Sat, 23 Feb 2019 11:56:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=Cy2gOLlXpKjIZi9QT5tJB1A0tpvw5xIPQLU3qWe/FslPg/d5RI6hV036xMTRVmHX6i aX+AZAa5vUopR7V/7T8kS/Nbm3hE+aTcDW3IQIrF2aQa7nyEBl3+FCKbeeqLpdAfg1sF es7T+6Fn81Ktdq1NcRzPpOlWCRP+/9SLoS9Wk= 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=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=Jxj7QKQoJMkQISWYtD7iciEUjdbbDUQWCus5Ry/7snEixXM4Iwzszh+0ueE2nSrLAR 0/0Bjr5Q15XepjsI6xL1lIoiUh4/Ua1ACXscj6mJ0gx6tJS2MSAAMH+V57d1Nd6C9HP9 C8Y8TcMPLjdyVz80Nj+Tc+bCMh6u31+fK6/AqtEJhyy3G/m2LfjVC25EpfhxRMyrbaG0 81heGM9dcaDYKFgS03Idt8NHOlbIcF9TUADsxtMCpzM+r1z2LeaQcd9y5iadR8whirVU MWt9HL6GByiNjX01/b5Gw/M9c6UFg2n4/Hob+W3BwerTNE258AFDxvNDxbdR4y5uoc7w 9wMQ== X-Gm-Message-State: AHQUAua05fCb4bhHjbyPdKZNFek8Boat4jx3fxXyQatsfKLvSlnRNWIb TIK73glYQmHJlNbUz1YrPtf1Pf8RiLiBmsACNkzOu9zW X-Google-Smtp-Source: AHgI3IbE89cyO328x7ZYxZ/g3V/cfEfkEXzkfDYRJaSUv2xWdKZRSAJw/WfWBTFqF+DAxZn8aZbgloV9uizfLIThGwQ= X-Received: by 2002:a5d:8190:: with SMTP id u16mr6178195ion.238.1550951805745; Sat, 23 Feb 2019 11:56:45 -0800 (PST) MIME-Version: 1.0 References: <5C719828.1000802@isdg.net> In-Reply-To: <5C719828.1000802@isdg.net> From: "Kurt Andersen (b)" Date: Sat, 23 Feb 2019 11:56:24 -0800 Message-ID: To: Hector Santos Cc: "dmarc@ietf.org" , spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000007211e80582951b87" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 19:56:51 -0000 --0000000000007211e80582951b87 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 23, 2019 at 11:00 AM Hector Santos 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 --0000000000007211e80582951b87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 23, 2019 at 11:00 AM Hector S= antos <hsantos@isdg.net> wrot= e:
On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
>
> Instead of using the standard "(+)include:" approach, if dom= ain 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<= br> > massively included platforms. It would essentially force the DMARC res= ult
> to be driven only by the DKIM evaluation.
>
> Thoughts?
>

it shouldn't matter it its huge or tiny, the protocol applies equal= ly.

Quite so - however, some of the mec= hanisms and common usage patterns do differ depending on the scale and comp= lexity of the sender asserting the record.
=C2=A0
It helps to use an example. For exa= mple:=C2=A0 gmail.com has: [redirect elided]

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
include:_netblocks3.google.com ~all

The SPF processor result SHOULD be based on each one.=C2=A0 In this case, e= ach 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).
=C2=A0
it s= ounds like you are proposing an include prefix result should override match= ing result, including the default/final result.=C2=A0
No, I'm suggesting that the neutral mechanism prefix should= be promoted as a "better way" to cite includes of large common s= ending platforms. "Better" than the default pass evaluation resul= t.

So= for example, using one the includes for gmail.com:

v=3Dspf1 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.=C2=A0=C2=A0
=C2=A0
Unless the conditions were limited to wh= en this can be applied, I can
see where this can become really complex because of higher recursion
potentials.=C2=A0 =C2=A0You also have compatibility concerns as well.

I think that the biggest problem with nested= includes (I'm intentionally avoiding the "recursion" term be= cause it should not be recursive or circular) is the table in RFC7208 secti= on 5.2 which asserts that a neutral result from check_host ends up being tr= eated 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 percolat= ing up to d1.example as a neutral final result.

--= Kurt=C2=A0
--0000000000007211e80582951b87-- From nobody Sat Feb 23 13:03:54 2019 Return-Path: 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: <5C719828.1000802@isdg.net> In-Reply-To: From: Dotzero Date: Sat, 23 Feb 2019 16:03:32 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Hector Santos , spfbis@ietf.org, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4efcd0582960a90" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 21:03:47 -0000 --000000000000d4efcd0582960a90 Content-Type: text/plain; charset="UTF-8" Just provide a DKIM only mechanism/option. Michael Hammer On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) wrote: > On Sat, Feb 23, 2019 at 11:00 AM Hector Santos 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 > --000000000000d4efcd0582960a90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just provide a DKIM only mechanism/option.=C2=A0

<= /div>
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 dom= ain 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<= br> > massively included platforms. It would essentially force the DMARC res= ult
> to be driven only by the DKIM evaluation.
>
> Thoughts?
>

it shouldn't matter it its huge or tiny, the protocol applies equal= ly.

Quite so - however, some of the mec= hanisms and common usage patterns do differ depending on the scale and comp= lexity of the sender asserting the record.
=C2=A0
It helps to use an example. For exa= mple:=C2=A0 gmail.com has: [redirect elided]

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
include:_netblocks3.google.com ~all

The SPF processor result SHOULD be based on each one.=C2=A0 In this case, e= ach 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).
=C2=A0
it s= ounds like you are proposing an include prefix result should override match= ing result, including the default/final result.=C2=A0
No, I'm suggesting that the neutral mechanism prefix should= be promoted as a "better way" to cite includes of large common s= ending platforms. "Better" than the default pass evaluation resul= t.

So= for example, using one the includes for gmail.com:

v=3Dspf1 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.=C2=A0=C2=A0
=C2=A0
Unless the conditions were limited to wh= en this can be applied, I can
see where this can become really complex because of higher recursion
potentials.=C2=A0 =C2=A0You also have compatibility concerns as well.

I think that the biggest problem with nested= includes (I'm intentionally avoiding the "recursion" term be= cause it should not be recursive or circular) is the table in RFC7208 secti= on 5.2 which asserts that a neutral result from check_host ends up being tr= eated 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 percolat= ing up to d1.example as a neutral final result.

--= Kurt=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d4efcd0582960a90-- From nobody Sun Feb 24 11:19:45 2019 Return-Path: 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 8B06C12D826 for ; Sun, 24 Feb 2019 11:19:43 -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=X+nZtqbX; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0KyfkK6z 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 i8SU9kRlcn5s for ; Sun, 24 Feb 2019 11:19:41 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E09FE12D4F3 for ; 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=X+nZtqbXfIlomdSZe7Wj0M0MQxVUzZuiO8s2/7zTal8vQVIC0u7V2ROPSlvkxF SW1vYoPLHwuQN31eq4Zh734DZddDDXqGvNrnBwvqgQmH4gT72ejYk1Ia5b+PTIcL hICZuonYi5JQPBWX0Psu/nmsXB9w4qQruhlOoKwVIef5E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for spfbis@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 1442883779.1.3780; 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=0KyfkK6zXH4ODkTROIqbRng wP9YAqb2Gya1OYkgTpg4yw6OlyVUkcRCr+dG4O+tCo8Z254q7UcENvZh8Pa1q50Z PNm5kU2FyaGgDIwzZE4i8Y6iNM6Cg2iv5q3qLGM53UhXxQQfK0L2rxjxtrj0wvzO qM9M+g/XjH1QXJ74Wc7M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for spfbis@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 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)" CC: spfbis@ietf.org, "dmarc@ietf.org" References: <5C719828.1000802@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Mon Feb 25 02:24:36 2019 Return-Path: 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 9E7F812F1A5; Mon, 25 Feb 2019 02:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 aTuF3HonTgAN; Mon, 25 Feb 2019 02:24:33 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147F412D4E6; Mon, 25 Feb 2019 02:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1551090271; bh=ovwrj9n6tIIPY5973h1kFH33/r0P1WIhw88ADXw5Tig=; l=1174; h=To:Cc:References:From:Date:In-Reply-To; b=CSws7D93vD5h0KsbnwZMWHs4jsV2N+MqqamZHqzDhFD7ix0wfpGRzt2BWCfmsyIPj Vzezbv9ILEdiFsFZ+1Xa6Vt+lZKzQs5QERgdu5zn4z0dv1K/TV/wU+FftJnxAHVf/m yRWNCkRjUvFVaMCQCSNHhUtTjMjMXqY+oO/34Cbzb0d1Lua2fHVCa0oUF+ohM Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 25 Feb 2019 11:24:30 +0100 id 00000000005DC085.000000005C73C25E.0000546F To: "Kurt Andersen (b)" , "dmarc@ietf.org" Cc: spfbis@ietf.org References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <789e8c23-1826-4447-f072-45ce4bfec2fe@tana.it> Date: Mon, 25 Feb 2019 11:24:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spfbis] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 10:24:35 -0000 On Sat 23/Feb/2019 19:07:31 +0100 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. Hopefully, large organizations have a policy which enables them to drop non-compliant users contracts. The admin attitude. Alternatively, they could expunge offending IP addresses from their SPF records. The whitelist attitude. The rest is reputation. > 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. -1. If DKIM were flawless, maybe... Authentication of email messages forwarded through various providers is already DKIM-only driven, but that doesn't seem to improve reliability, does it? Best Ale --