Subject: [dmarc-ietf] Ticket #1 - SPF alignment

From: "John R Levine" <[email-masked]>
Date: 1 Dec 2020 17:17:15 -0500

We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.

Ticket #1 is about SPF alignment.  We need to replace references to 4408 
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF 
counts, if you want to align your bounces, sign them.  The other is to 
explicitly say that HELO alignment is OK on bounces.

R's,
John

================================================================

From: Anne Bennett <anne@…>
Date: Fri, 16 Jan 2015 19:10:56 -0500
Subject: [dmarc-ietf] SPF RFC 4408 vs 7208

On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
However, -12 still has, in section "3.1. Identifier Alignment":
For example, [DKIM] authenticates the domain that affixed a
signature to the message, while [SPF] authenticates either
the domain that appears in the RFC5321.MailFrom? portion of
[SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
is null (in the case of Delivery Status Notifications).
Actually, RFC 7208 states that:
Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
if both are checked.

... and implies that if the first check passes, the second
is unnecessary:

If a conclusive determination about the message can be made
based on a check of "HELO", then the use of DNS resources to
process the typically more complex "MAIL FROM" can be avoided.
So the RFC5321.EHLO/HELO domain is checked not only if the
RFC5321.MailFrom? is null - in fact in cases where sites have
followed the RFC 7208 recommendation, it will be checked first,
at least by a "pure SPF" implementation.
This means, first of all, that the -12 text above needs fixing.
But also, I'm struggling with what it means for alignment.
I can think of some real-life cases where only one of
HELO or MAIL FROM aligns with RFC5322.From, even though
both would "pass" in a pure SPF check. IMHO, Section
"3.1.2. SPF-authenticated Identifiers" needs to be clarified
to better take HELO into account.
I'd like to see an approach similar to that for DKIM, where it
is explicitly stated that:
a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is
aligned and verifies.
Similarly, I think that for SPF, it should be considered a pass
if either the MAIL FROM or the HELO is aligned and results in a
pass at the SPF level.
But whether it is decided to take into account both HELO and MAIL
FROM, or whether it is decided to ignore HELO (modulo its use to
construct an artificial MAIL FROM if the latter is null), the text
should IMHO make this clear one way or another, both in "3.1.2.
SPF-authenticated Identifiers":
In relaxed mode, the [SPF]-authenticated domain and
RFC5322.From domain must have the same Organizational Domain.
In strict mode, only an exact DNS domain match is considered
to produce identifier alignment.

... and in "4.1. Authentication Mechanisms":

o [SPF], which authenticates the domain found in an
[SMTP] MAIL command when it is the authorized domain.
In both cases, the text should specifically mention HELO,
and whether to include or exclude a HELO SPF result, in view
of HELO's prominence in RFC 7208.
If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.

---

From: Douglas Foster <[email-masked]>
Date: Tue, 1 Dec 2020 18:20:12 -0500

1) ACCEPTABLE:   Server Domain matches RFC 5322 From domain, and RFC 5321
Mail From is missing.
HELO is an appropriate proxy for the missing Mail From, especially since a
missing Mail From implies a system message, such as a server might need to
generate.

2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC
5321 Mail From is a different domain.
All this tells us is that the Mail From domain is a client on that system.
 Being a client of a hosting service does not give the right to speak for
the hosting service.

Doug Foster

On Tue, Dec 1, 2020 at 5:17 PM John R Levine <[email-masked]> wrote:

> Policy", item 4 should be updated to reflect that as
> well._______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 2 Dec 2020 11:37:37 +0100

On Tue 01/Dec/2020 23:17:15 +0100 John R Levine wrote:
> [...]
> I think that for SPF, it should be considered a pass if either the MAIL FROM
> or the HELO is aligned and results in a pass at the SPF level.

+1, especially for bounces.

> Policy", item 4 should be updated to reflect that as well.

If alignment is not known at step 4, both domain names (if different) must be 
passed to step 5.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 2 Dec 2020 11:40:32 +0100

On Wed 02/Dec/2020 00:20:12 +0100 Douglas Foster wrote:
> 
> 2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC 5321 
> Mail From is a different domain.
>   Being a client of a hosting service does not give the right to speak for the 
> hosting service.

What if I wanted to collect bounces at a different domain?

OTOH, an MSA can relay using a different HELO (or even a different IP), 
according to the right (categorization) it wants to supply.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 23:05:49 -0800

Point of clarification:

> with 7408, ando clarify what if anything we do with SPF HELO checks if

The new SPF is RFC 7208, not 7408.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 23:12:50 -0800

> explicitly say that HELO alignment is OK on bounces.

I have a slight preference for the first option.  HELO is too arbitrary in
the protocol for me to put much value in using it in any of these systems.

-MSK

---

From: Dotzero <[email-masked]>
Date: Mon, 7 Dec 2020 06:09:14 -0500

> the protocol for me to put much value in using it in any of these systems.

+1

Michael Hammer

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 7 Dec 2020 13:55:29 -0800

> the protocol for me to put much value in using it in any of these systems.

There's a bit of an implementation detail though. If one is relying on an
encapsulated ck_host() function then you may not know whether it checked
the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
seems like it verges on a layering violation.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 17:13:44 -0500

>seems like it verges on a layering violation.

You should be able to look at the bounce address and if it's null,
skip the SPF check.  No need to peek inside SPF for that.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Mon, 7 Dec 2020 22:20:16 -0500

Is there an identifiable attack vector which can be based on using the
(forward confirmed) HELO name for SPF pass?

If not, why change?

On Mon, Dec 7, 2020, 6:09 AM Dotzero <[email-masked]> wrote:

>> I have a slight preference for the first option.  HELO is too arbitrary
>> in the protocol for me to put much value in using it in any of these
>> systems.
>>
>> -MSK
>>
>
> +1
>
> Michael Hammer
> _______________________________________________
> dmarc mailing list
> [email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 9 Dec 2020 12:46:41 +0100

> skip the SPF check.  No need to peek inside SPF for that.

That would discard most bounces, since many MTAs send them directly, without 
going through a signing filter.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 30 Dec 2020 16:06:01 -0500

> Ticket #1 is about SPF alignment.  We need to replace references to 4408 with 
> 7408, ando clarify what if anything we do with SPF HELO checks if
> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF counts, 
> if you want to align your bounces, sign them.  The other is to explicitly say 
> that HELO alignment is OK on bounces.

I didn't hear a lot of strong opinions, but I think they leaned in the 
direction of only checking the MAIL FROM, since the name of the MTA often 
is unrelated to the From: domain.

This means that if you want your bounces to be DMARC aligned, they'd need 
DKIM signatures.

R's,
John

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 15:46:45 +0100

On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote:
> direction of only checking the MAIL FROM, since the name of the MTA often is 
> unrelated to the From: domain.
> 
> This means that if you want your bounces to be DMARC aligned, they'd need DKIM 
> signatures.

Bounces with HELO mta.example.com should have From: [email-masked], 
where example.com may be a virtual domain or the "real" domain name, depending 
on the configuration.

Best
Ale
--