Subject: [spfbis] Should we encourage the use of SPF "soft include" for common platforms?

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 23 Feb 2019 10:07:31 -0800

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)

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 23 Feb 2019 13:39:02 -0500

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) <[email-masked]> 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
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hector Santos <[email-masked]>
Date: Sat, 23 Feb 2019 13:59:52 -0500

> to be driven only by the DKIM evaluation.

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: Vladimir Dubrovin <[email-masked]>
Date: Sat, 23 Feb 2019 22:34:28 +0300

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. 
>
> 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)
>

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 23 Feb 2019 11:56:24 -0800

On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <[email-masked]> wrote:

> used
> 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]
>
> 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.

> result rather than use the matching result or final/default result of

Not an override - just a different result.

> 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

---

From: Dotzero <[email-masked]>
Date: Sat, 23 Feb 2019 16:03:32 -0500

Just provide a DKIM only mechanism/option.

Michael Hammer

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Feb 2019 14:19:26 -0500

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

> On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote:
>

+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: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Feb 2019 11:24:30 +0100

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.

> 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
--