Subject: [dmarc-ietf] Best Guess SPF should not be deprecated.

From: Douglas Foster <[email-masked]>
Date: Sat, 4 Dec 2021 17:35:17 -0500

I have multiple objections to this paragraph in section 5.7.2

"Heuristics applied in the absence of use by a Domain Owner of either SPF
or DKIM (e.g., [Best-Guess-SPF
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#Best-Guess-SPF>
]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a
Message Receiver not to consider the results of that underlying
authentication protocol at all."

First, it is unnecessary.   A sender who wants SPF ignored for purposes of
DMARC can simply publish "?ALL" to produce the desired result.

Second, I don't know why a sender would want this behavior.   I understand
that some senders have difficulty describing their environment within SPF
complexity limits, but Google, Microsoft, and Amazon seem to have been able
to cope with the constraint.    Even when complexity is the problem, a
partial list of clauses, terminated with "?ALL", would be preferable to no
policy.

My experience has been that SPF=NONE has a high probability of being
unwanted mail.   There is enough usage of SPF that serious participants are
unlikely to use it.

I have been using default SPF clauses for the last couple of years, with
good results, so I need some serious convincing to backtrack.

I think this text was inserted because of an open ticket when discussion
was going nowhere and a new draft was created.  Perhaps the originator of
that ticket can elaborate on his thinking.

Counter-proposal

Another part of the draft observes that SPF policies can become too loose.
 For example, this could happen from range consolidation or nested
includes, either of which might cause unauthorized servers to be included
in the allowed list.  If a sender knows that his SPF has this problem, and
that all of his messages are DKIM-signed, he might want to publish a flag
which says, "All my messages are signed.  Any messages that are not
DKIM-verified should be treated as DMARC FAIL, even if they pass SPF."  I
still doubt that we have a critical mass of domain owners who would use
this option if it were available, and it seems like yet another avenue for
false positives.   But if such a capability is desired, it should be
implemented as part of the DMARC policy statement, not as a general
constraint on evaluators.

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 16:23:40 -0800

> that ticket can elaborate on his thinking.

I believe the admonishment against best-guess SPF was based at least in
part on the sentiments found here:

http://www.open-spf.org/FAQ/Best_guess_record/

...which is to say it's apparently a discouraged practice.

It makes it difficult for DMARC to be deterministic when the things upon
which it's built behave in unpredictable ways.  That's not to say this is
unique though; DKIM, for example, allows verifiers to decide what an
acceptable signature is (a favorite I remember from the early days was "I
don't want to accept a DKIM signature that didn't cover the Subject
field"), which again means one site's "pass" is another site's "fail".

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 4 Dec 2021 16:51:54 -0800

On 12/4/2021 4:23 PM, Murray S. Kucherawy wrote:
> DKIM, for example, allows verifiers to decide what an acceptable 
> signature is (a favorite I remember from the early days was "I don't 
> want to accept a DKIM signature that didn't cover the Subject field"), 
> which again means one site's "pass" is another site's "fail".

I'm going to suggest that that analysis is not formally correct.

The DKIM specification precisely defines validation for the signature 
and it precisely defines what coverage is 'required'.

A receiver can indeed choose to apply stricter requirements, but a 
failure to satisfy these is NOT a DKIM fail. The extra requirements are 
outside the scope of the DKIM specification and therefore the failure 
has nothing to do with the standard.

This is not a minor point, but it does seem to be a common point of 
confusion.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 01:47:49 +0000

>field"), which again means one site's "pass" is another site's "fail".

Much like Dave's response about DKIM, I think what an SPF result is is well defined.  The so called "Best Guess" isn't an SPF result at all.  Implementation and interoperability requirements for SPF are defined by RFC 7208 (and formerly RFC 4408).  Neither it nor it's predecessor ever defined this.  It's not implemented in Mail::SPF, which is the closest thing there is to a reference implementation.

We already say to use DKIM and SPF.  If you want an enumerated list of all the things that aren't DKIM or SPF to tell people not to do, I think it would be a long list.  As far as I know, no RFC even mentions "Best Guess" and this one should not be the first.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Sat, 4 Dec 2021 18:10:27 -0800

On Sat, Dec 4, 2021 at 17:48 Scott Kitterman <[email-masked]> wrote:

> Much like Dave's response about DKIM, I think what an SPF result is is
> well defined.  The so called "Best Guess" isn't an SPF result at all.
> Implementation and interoperability requirements for SPF are defined by RFC
> 7208 (and formerly RFC 4408).  Neither it nor it's predecessor ever defined
> this.  It's not implemented in Mail::SPF, which is the closest thing there
> is to a reference implementation.
>
> We already say to use DKIM and SPF.  If you want an enumerated list of all
> the things that aren't DKIM or SPF to tell people not to do, I think it
> would be a long list.  As far as I know, no RFC even mentions "Best Guess"
> and this one should not be the first.

+1

>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank * | Chief Product Officer
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 03:08:03 +0000

>constraint on evaluators.

The alternative is not needed either.  If operational advice is needed, then it should be in an appendix or perhaps another document.  It shouldn't be part of the protocol specification.  It's not particularly good advice either.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 19:52:37 -0800

> This is not a minor point, but it does seem to be a common point of

Right, I stand corrected.  The distinction is actually in the definition of
Authentication-Results, where a DKIM "pass" can be reported as a "policy"
result rather than a "pass" when the algorithm completed successfully but
some aspect of the signature was not acceptable to the verifier.

-MSK

---

From: Todd Herr <[email-masked]>
Date: Mon, 6 Dec 2021 08:04:44 -0500

On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster <
[email-masked]> wrote:

> ]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes
> a Message Receiver not to consider the results of that underlying
> [snip]
To be clear, the text at issue is present in RFC 7489, Section 6.6.2.

That doesn't make it immutable, of course...
-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 13:29:02 +0000

On December 6, 2021 1:04:44 PM UTC, Todd Herr <todd.herr=[email-masked]> wrote:
>> or DKIM (e.g., [Best-Guess-SPF <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#Best-Guess-SPF>

Thanks for the clarification.  I'd forgotten that was there.  I definitely think it should be removed, regardless of the origin.

In addition to my comments about leaving SPF best guess out, I think the DKIM part is problematic too.  There really aren't any DKIM heuristics to use "in the absence of use by a domain owner".  The only DKIM related heuristics that might apply to this section are the ones we've discussed about recovering signatures that failed due to in transit modification.  Those are a good thing, even if they aren't broadly applicable enough to warrant standardization.

I think what better goes in this spot is a more general comment about local policy (it doesn't seem to be discussed elsewhere).  That would include mentioning ARC as an input to local policy.  I have also suggested an appendix or possibly a separate document on things mail senders, intermediaries, and receivers can do to improve the reliability of DMARC through indirect mail flows.  This would be one place that should be referenced.

I'll provide text if people like the concept.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 20:01:10 +0100

On Mon 06/Dec/2021 14:29:02 +0100 Scott Kitterman wrote:
> On December 6, 2021 1:04:44 PM UTC, Todd Herr <[email-masked]> wrote:
>>On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster <[email-masked]> wrote:
>>

I assume you said one can locally evaluate Best-Guess-SPF, but should not taint 
DMARC results by considering its outcome.  That paragraph should then be left 
there, no?

> In addition to my comments about leaving SPF best guess out, I think the DKIM part is problematic too.  There really aren't any DKIM heuristics to use "in the absence of use by a domain owner".  Th…

Agreed.

However, I wonder if there are heuristics for DMARC itself.  Step 2 seems to 
suggest to skip any SPF or DKIM verification if no policy is found.  By the 
same logic, it could even suggest to skip verifications if p=none and no rua/ 
ruf were found.  Instead, IMHO, there's some value in carrying out 
verifications nonetheless.

> I'll provide text if people like the concept.

IMHO that'd be interesting.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 14:09:31 -0500

On Monday, December 6, 2021 2:01:10 PM EST Alessandro Vesely wrote:
> >>On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster 
<[email-masked]> wrote:
> >>> <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#Best
> >>> -Guess-SPF> ]) SHOULD NOT be used, as it may be the case that the Domain
> >>> Owner wishes a Message Receiver not to consider the results of that
> >>> underlying
> > Thanks for the clarification.  I'd forgotten that was there.  I definitely
> > think it should be removed, regardless of the origin.
> I assume you said one can locally evaluate Best-Guess-SPF, but should not
> taint DMARC results by considering its outcome.  That paragraph should then
> be left there, no?

No.  The so called best guess is no part of SPF.  The document says use the 
SPF result.  It's not an SPF result.  There's nothing we can do to stop people 
from doing non-standard things.  We already say what they should do for 
interoperability and protocol consistency.  It's not feasible nor is it a good 
idea to attempt to enumerate the things people shouldn't do.  I struggle to 
understand why this should be called out and not, to pick an example, Sender 
ID.  I'd prefer we don't act as publicity for bad practices.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 11:16:06 -0800

On 12/6/2021 5:29 AM, Scott Kitterman wrote:
> I think what better goes in this spot is a more general comment about local policy (it doesn't seem to be discussed elsewhere).

"Local policy" is just another way of saying "doing something outside of 
the specification".  People are always 'allowed' to do whatever they 
want.  It has nothing to do with interoperability through the specification.

Telling people that they can do things outside of the specification is 
not helpful.  In fact, it often is counter-productive, because having 
such language in a specification makes it seem to carry extra weight.  
Which it doesn't.  For example, it often seems to be granting permission 
or constraint, but it is doing that for something about which the 
specification has no power or authority.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 19:56:36 +0000

>specification has no power or authority.

Agreed, in general.  Somewhere we need to explain about how ARC related to DMARC.  If it's going to be in the protocol specification, this is the place.  Otherwise it would go in the appendix I keep mentioning that we need which explains options senders, intermediaries, and receivers can do to mitigate DMARC interoperability challenges.

I think it's slightly better to do it in an appendix , as long as we remember to write it.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 12:04:37 -0800

On 12/6/2021 11:56 AM, Scott Kitterman wrote:
> Somewhere we need to explain about how ARC related to DMARC.  If it's going to be in the protocol specification, this is the place.  Otherwise it would go in the appendix I keep mentioning that we need which explains options senders, intermediaries, and receivers can do to mitigate DMARC interoperability challenges.
>

You want to comment on ARC in the DMARC specification?  Don't do that.

ARC currently has nothing to do with DMARC.  And DMARC currently has 
nothing to do with ARC.

To change this will require writing a specification, presumably as an 
enhancement to DMARC, to include consideration of ARC.

In technical terms, the ARC specification must not know about or care 
about DMARC, since ARC is attempting to augment DKIM, rather than an 
upper-level function that uses DKIM, which is what DMARC is.

If it helps, draw boxes with labels for different functions, like SPF, 
DKIM, and DMARC.  Draw arrows between them,to establish which provides 
functionality and which uses it.

A providing specification must not know or document anything about a 
consumer.  Otherwise it is, effectively, a layer violation.  It also 
invites messy complexity and out-of-date references, as specifications 
change.

To the extent that there is a strong benefit in having a document that 
discussion an aggregation of components, then it's a separate operations 
or architecture document.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 15:12:20 -0500

On Monday, December 6, 2021 3:04:37 PM EST Dave Crocker wrote:
> > Somewhere we need to explain about how ARC related to DMARC.  If it's
> > going to be in the protocol specification, this is the place.  Otherwise
> > it would go in the appendix I keep mentioning that we need which explains
> > options senders, intermediaries, and receivers can do to mitigate DMARC
> > interoperability challenges.
> > 

That's fine.  I was thinking something conceptually similar to RFC 7208 
Appendix D, but I think there's nothing wrong with a separate document if 
that's what the group prefers.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Dec 2021 16:18:56 -0500

It appears that Scott Kitterman  <[email-masked]> said:
>No.  The so called best guess is no part of SPF.  

The "best guess" was a short term hack around 2003 when SPF was new
and not widely deployed.  It is now 18 years later, anyone who can
run a mail server can publish SPF and that hack is totally dead.

Please can we all pretend it never existed, we never heard of it,
and we certainly are not going to say anything about it.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 13:22:16 -0800

> and we certainly are not going to say anything about it.

My best guess is that you are referencing something that has no business 
even being referenced in an IETF specification.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 17:28:01 -0500

> even being referenced in an IETF specification.

Agreed (on both of your points).  It was a mistake to put it in RFC 7498, but 
that's no IETF specification.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 7 Dec 2021 12:39:39 +0100

On Mon 06/Dec/2021 21:04:37 +0100 Dave Crocker wrote:
>> Somewhere we need to explain about how ARC related to DMARC.  If it's going 
>> to be in the protocol specification, this is the place.  Otherwise it would 
>> go in the appendix I keep mentioning that we need which explains options 
>> senders, intermediaries, and receivers can do to mitigate DMARC 
> ARC currently has nothing to do with DMARC.  And DMARC currently has nothing to 
> do with ARC.

That seems to imply that the reporting extensions aimed at ARC (ticket #56) 
should not actually mention it.  Aggregate reporting would describe a 
completely abstract method to add piggyback functionality to reporting.  That 
arguably entails a registry of optional contents and possibly places to specify 
which additional contents a consumer is interested in...

> enhancement to DMARC, to include consideration of ARC.

Or else, an enhancement to ARC to include consideration of DMARC.  In 
particular, ARC should consider From: rewriting and provide a way to restore 
the original value locally if the message is authenticated.

> In technical terms, the ARC specification must not know about or care about 
> DMARC, since ARC is attempting to augment DKIM, rather than an upper-level 
> function that uses DKIM, which is what DMARC is.

Yes, ARC originated as an alternative to conditional DKIM signatures.  But that 
was in the context of DMARC effect on indirect mail flows.

> If it helps, draw boxes with labels for different functions, like SPF, DKIM, 
> and DMARC.  Draw arrows between them,to establish which provides functionality 
> and which uses it.

It's just an extension of the drawing in Section 4.4 of the draft.  I attach an 
attempt
(Would something like that serve for the html version of the I-D?)

> A providing specification must not know or document anything about a consumer.  
> Otherwise it is, effectively, a layer violation.  It also invites messy 
> complexity and out-of-date references, as specifications change.

The trick is to replace the rewritten From: in the MDA Filtering Engine, 
/after/ any external forwarding.

> discussion an aggregation of components, then it's a separate operations or 
> architecture document.

Yes.

Best
Ale
--