Subject: Re: [dmarc-ietf] Section 5 - DKIM-only authentication

From: Ken O'Driscoll <[email-masked]>
Date: Tue, 4 Jan 2022 14:33:42 +0000

Organisations using DKIM-only (also SFP-only) with an enforcing DMARC policy are more common than you may think. While some configurations are perhaps in error, many I have encountered are deliberate decisions based on specific use cases.

For example, I have a finance house that uses DKIM-only auth with p=reject on their main domain. When deploying DMARC they risked it and decided that giving a third-party control of their SPF (via an include) was not an option. It’s a valid reason whether one personally agrees with it or not. There are tons of other reasons why organisations make similar decisions.

Single auth is actively used in the wild.

Ken.

From: dmarc <[email-masked]> On Behalf Of Douglas Foster
Sent: Monday 27 December 2021 13:51
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] Section 5 - DKIM-only authentication

These two sections assume that some domain owners will want DMARC authentication to be based on DKIM only.

5 Policy
A Domain Owner can also choose to not have some underlying authentication technologies apply to DMARC evaluation of its domain(s). In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result.

5.7.2. Determine Handling Policy
Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [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.

We agreed to drop the reference to Best-Guess-SPF, but we have not addressed the underlying requirement.  Do we actually have domain owners who do not want SPF included in the DMARC evaluation process?  If so, why?

I am guessing that this request could only originate from a domain owner with a valid but overly inclusive SPF record, probably because of include clauses.   The suggested strategy of no SPF record, or the equivalent "?ALL", or not acceptable.   These approaches only make a weak SPF policy even weaker.    To allow an overly-broad SPF policy to be ignored for DMARC purposes, we should provide an explicit policy flag for this purpose.

But each new option adds complexity.   Is this option actually valuable to somebody?

---

From: Tobias Herkula <[email-masked]>
Date: Tue, 4 Jan 2022 14:42:15 +0000

One big thing missing in the Discussion are Receiver obligations, I encountered a lof of Mailbox Providers that demand a valid and concise SPF record, and in this case the Sender has no way to state that he requires DKIM signatures for DMARC, the often stated argument of simply not publishing SPF records if a Sender wants DKIM-only DMARC is not a viable solution in the real world.

/ Tobias

Von: dmarc <[email-masked]> Im Auftrag von Ken O'Driscoll
Gesendet: Dienstag, 4. Januar 2022 15:34
An: Douglas Foster <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Betreff: Re: [dmarc-ietf] Section 5 - DKIM-only authentication

Ken.

From: dmarc <[email-masked]<mailto:[email-masked]>> On Behalf Of Douglas Foster
Sent: Monday 27 December 2021 13:51
To: IETF DMARC WG <[email-masked]<mailto:[email-masked]>>
Subject: [dmarc-ietf] Section 5 - DKIM-only authentication

5 Policy

---

From: "John Levine" <[email-masked]>
Date: 4 Jan 2022 17:53:54 -0500

It appears that Tobias Herkula  <[email-masked]> said:
>the often stated argument of simply not publishing SPF records if a Sender wants DKIM-only
>DMARC is not a viable solution in the real world.

If your SPF record accurately describes the sources of your mail, can you explain why
it would be a problem for that to validate DMARC?

The obvious problem would be "my mail provider is so incompetent that they let
other people send phishes with my address" but that is definitely not a problem
for anyone else to solve.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Tue, 4 Jan 2022 19:13:02 -0500

Tobias is correct.   When I checked my message log, I had no trouble
finding messages with SPF=none, aligned DKIM=verified, and DMARC policy
exists.  "store.apple.com" is one example.  We need to acknowledge that
this has become standard practice.

Nonetheless, a protocol should not depend on unpublished information when
an alternative is available.   I would be content with language like this:

When domain owners wish to prevent using SPF Alignment for DMARC, they
SHOULD publish an SPF policy of "?ALL".   However, since current usage
often implements SPF NONE for this purpose, mail evaluators are RECOMMENDED
to treat SPF NONE as equivalent to "?ALL" when the DMARC policy is
"quarantine" or "reject".

The restriction to quarantine and reject is intentional.  When the
policy is "none", the domain owner is telling me that some of his messages
may not produce DMARC PASS, and yet he does not want me to block unverified
messages that are legitimately from his domain.   Given that stated
ambiguity, the domain owner cannot also say, "But do not use any
other method or guesswork to identify the messages that are legitimate but
unverified."   If the policy is "none", guesswork is fair game.

Doug

On Tue, Jan 4, 2022 at 5:54 PM John Levine <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 4 Jan 2022 16:26:27 -0800

On 1/4/2022 6:42 AM, Tobias Herkula wrote:
> One big thing missing in the Discussion are Receiver obligations, I 
> encountered a lof of Mailbox Providers that demand a valid and concise 
> SPF record, and in this case the Sender has no way to state that he 
> requires DKIM signatures for DMARC, the often stated argument of 
> simply not publishing SPF records if a Sender wants DKIM-only DMARC is 
> not a viable solution in the real world.

The specification is very clear about the interpretation and limitations 
of DMARC.

I believe what you are describing are things that some receivers do that 
are outside of the DMARC specification.  Operational variations are 
important, of course, but they really are outside the scope of the 
protocol specification.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 4 Jan 2022 19:27:52 -0500

Correction.   I should have said that Ken Driscoll was correct, when he
said that SPF NONE was a commonplace way of making DMARC into a one-sided
test.

DF

---------- Forwarded message ---------
From: Douglas Foster <[email-masked]>
Date: Tue, Jan 4, 2022 at 7:13 PM
Subject: Re: [dmarc-ietf] Section 5 - DKIM-only authentication
To: IETF DMARC WG <[email-masked]>

Doug

---

From: Tobias Herkula <[email-masked]>
Date: Wed, 5 Jan 2022 13:59:25 +0000

Hi John,

I have one bigger example back from the days when I was working for an ESP. The Situation was that a financial Institution decided to sign all their messages with DKIM and deploy a DMARC reject policy and an active decision against a strict SPF record. Because a huge part of their Emails where constantly forwarded by their customer base and that created a lot of FP DMARC reports. At the same time a lot of their customers used a Mailboxprovider that required strict SPF records for Bulkmailersender. This dilemma wasn't solvable back then and isn't solvable now. As SPF is a global decision that needs to be made in comparison to DKIM where it is applied individually for each Email send Splitting that up into multiple Domains or Subdomains is not a viable alternative regarding Brand recognition, if my main goal is to reduce phishing attacks to my userbase.
And I'm pretty sure that there are lot of people on this list here that are aware of Mailboxproviders who are very strict on requirements for Bulkmailsender, and it would be much easier to comply with these requirements if DMARC would allow to specify that a valid DKIM Signature is needed to pass the DMARC check, so that a SPF policy can be omitted to prevent forwarding problems or can be published to honor MBP requirements without increasing the perceived Risk of loose SPF-RR...

/ Tobias

-----Ursprüngliche Nachricht-----
Von: John Levine <[email-masked]> 
Gesendet: Dienstag, 4. Januar 2022 23:54
An: [email-masked]
Cc: Tobias Herkula <[email-masked]>
Betreff: Re: [dmarc-ietf] Section 5 - DKIM-only authentication

It appears that Tobias Herkula  <[email-masked]> said:
>the often stated argument of simply not publishing SPF records if a 
>Sender wants DKIM-only DMARC is not a viable solution in the real world.

If your SPF record accurately describes the sources of your mail, can you explain why it would be a problem for that to validate DMARC?

The obvious problem would be "my mail provider is so incompetent that they let other people send phishes with my address" but that is definitely not a problem for anyone else to solve.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2022 11:32:59 -0500

> I have one bigger example back from the days when I was working for an 
> ESP. The Situation was that a financial Institution decided to sign all 
> their messages with DKIM and deploy a DMARC reject policy and an active 
> decision against a strict SPF record. Because a huge part of their 
> Emails where constantly forwarded by their customer base and that 
> created a lot of FP DMARC reports. At the same time a lot of their 
> customers used a Mailboxprovider that required strict SPF records for 
> Bulkmailersender. ...

I believe it, but we all know why those are not smart things to do if you 
want people to get they mail they want to receive.  We could make all 
sorts of changes to DMARC, and operators will continue to do foolish 
things that loses their users' mail.  So I do not want to waste time on 
it.

R's,
John

PS: How do you say "you can't fix stupid" in German?

---

From: Dotzero <[email-masked]>
Date: Wed, 5 Jan 2022 12:37:13 -0500

On Wed, Jan 5, 2022 at 11:33 AM John R Levine <[email-masked]> wrote:

> I have to strongly agree with John on this. From an operational
> perspective I believe Sending domains SHOULD get control of their outbound
> mail, subdomains, etc. It is a one time cost but involves reworking
> business processes, not just technical issues. Mailbox providers will make
> local policy decisions regardless of IETF standards. There was a Polish
> mailbox provider that would reject inbound mail if the MailFrom and From
> address did not match exactly. I think it is a foolish choice but it is
> their choice to make. We should be focusing on interoperability and NOT
> local policy choices. Anything along the lines of local policy issues and
> choices are best left to a BCP to be taken up at a later point if at all.
>

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Wed, 5 Jan 2022 10:46:42 -0800

On 1/5/2022 5:59 AM, Tobias Herkula wrote:
> I have one bigger example back from the days when I was working for an ESP.

You've described a company making a set of operational decisions that 
are known to create problems when using DMARC.

They also choose an ESP that imposes an operational requirement known to 
cause deliverability problems.

And you somehow want to modify DMARC to 'fix' this?

This is reminiscent of the explanation I got from a CEO, about the 
complaints sales folk were making about an excellent product, claiming 
that it needed this or that change:  It saves them from doing their job 
of actually selling the existing product.

The company needs to use the technology that exists, in a way that 
works, and to choose vendors that do the same.  If they can find a 
serious constituency of other companies wanting similar changes, then 
maybe there is a task for DMARC to embrace.  But only maybe.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Wed, 5 Jan 2022 22:23:45 -0500

Like everyone else, receivers will do what they perceive as their own self
interest.   The goal of a document like this is to a lay out a plan where
everyone can pursue their own self interest in a way that benefits the
group.  In this case, the "group" is senders of wanted mail and the
receivers who want that mail.

Senders who want to use a DKIM-only strategy for DMARC should consider how
that strategy will be received by evaluators who do not implement DMARC.
 Based on the implementations that I have observed, I would expect such
participants to only use SPF FAIL for rejecting suspected impersonation and
absence of MX/A to reject messages from suspected fake names.  But based on
your experience, some of them require an SPF record also.

The sender can ensure DKIM-only for DMARC by causing any SPF result other
than PASS.   FAIL and SOFTFAIL should be avoided, leaving  NONE, NEUTRAL,
and PERMFAIL as options.   I have suggested that they should publish "?ALL"
to ensure a result of NEUTRAL, since this will ensure that DMARC cannot be
SPF aligned, while also ensuring that Best-Guess SPF will not be used in
response to NONE.

In your experience, what do these SPF-mandatory evaluators consider to be
an acceptable SPF policy and policy result?  Do you think "?ALL" would have
qualified?

Doug Foster

On Tue, Jan 4, 2022 at 9:42 AM Tobias Herkula <[email-masked]>
wrote:

> encountered a lof of Mailbox Providers that demand a valid and concise SPF
> record, and in this case the Sender has no way to state that he requires
> DKIM signatures for DMARC, the often stated argument of simply not
> publishing SPF records if a Sender wants DKIM-only DMARC is not a viable
> solution in the real world.
>
>
>
> / Tobias
>
>
>
> *Von:* dmarc <[email-masked]> *Im Auftrag von *Ken O'Driscoll
> *Gesendet:* Dienstag, 4. Januar 2022 15:34
> *An:* Douglas Foster <[email-masked]>
> *Cc:* IETF DMARC WG <[email-masked]>
> *Betreff:* Re: [dmarc-ietf] Section 5 - DKIM-only authentication
>
>
>
>
>
> Organisations using DKIM-only (also SFP-only) with an enforcing DMARC
> policy are more common than you may think. While some configurations are
> perhaps in error, many I have encountered are deliberate decisions based on
> specific use cases.
>
>
>
> For example, I have a finance house that uses DKIM-only auth with p=reject
> on their main domain. When deploying DMARC they risked it and decided that
> giving a third-party control of their SPF (via an include) was not an
> option. It’s a valid reason whether one personally agrees with it or not.
> There are tons of other reasons why organisations make similar decisions.
>
>
>
> *From:* dmarc <[email-masked]> *On Behalf Of *Douglas Foster
> *Sent:* Monday 27 December 2021 13:51
> *To:* IETF DMARC WG <[email-masked]>
> *Subject:* [dmarc-ietf] Section 5 - DKIM-only authentication
>
>
>
> A Domain Owner can also choose to not have some underlying authentication
> technologies apply to DMARC evaluation of its domain(s). In this case, the
> Domain Owner simply declines to advertise participation in those schemes.
> For example, if the results of path authorization checks ought not be
> considered as part of the overall DMARC result for a given Author Domain,
> then the Domain Owner does not publish an SPF policy record that can
> produce an SPF pass result.
>
>
>
> Heuristics applied in the absence of use by a Domain Owner of either SPF
> or DKIM (e.g., [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.
>
>
>
> We agreed to drop the reference to Best-Guess-SPF, but we have not
> addressed the underlying requirement.  Do we actually have domain owners
> who do not want SPF included in the DMARC evaluation process?  If so, why?
>
>
>
> I am guessing that this request could only originate from a domain owner
> with a valid but overly inclusive SPF record, probably because of include
> clauses.   The suggested strategy of no SPF record, or the equivalent
> "?ALL", or not acceptable.   These approaches only make a weak SPF policy
> even weaker.    To allow an overly-broad SPF policy to be ignored for DMARC
> purposes, we should provide an explicit policy flag for this purpose.
>
>
>