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

From: Todd Herr <[email-masked]>
Date: Tue, 19 Jan 2021 16:26:09 -0500

Picking up the thread on another ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

John Levine asserted that there wasn't a lot of strong opinion on the
matter, and therefore we'd be leaving the spec as is, with the MAIL FROM
SPF check the only one that matters for DMARC.

Ale replied, but I don't interpret his reply as challenging John's
assertion.

Can this ticket be closed?

On Thu, Dec 31, 2020 at 9:47 AM Alessandro Vesely <[email-masked]> wrote:

> On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote:
> >> 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.
> >
> > 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.
>
>
> 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.
>
> --

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

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: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Jan 2021 10:24:22 +0100

> Ale replied, but I don't interpret his reply as challenging John's

The thread went off-topic w.r.t. the purpose of ticket #1.

> Can this ticket be closed?

I agree that the spec needs some text somewhere to counter the passage in 
Section 2.3 of RFC 7208.  This, methinks, is the intended semantics of the 
second paragraph of section 3.1.2 of dmarcbis:

OLD:
    Note that the RFC5321.HELO identity is not typically used in the
    context of DMARC (except when required to "fake" an otherwise null
    reverse-path), even though a "pure SPF" implementation according to
    [RFC7208] would check that identifier.

I'd rather replace that paragraph and leave item 4 of Section 6.6.2 as is.  For 
a possibly less confusing wording:

NEW:

    Even tough a "pure SPF" implementation, according to [RFC7208], would
    avoid to check the RFC5321.MailFrom identity if the RFC5321.HELO was
    conclusively determined to pass, DMARC authentication requires the
    authenticated identity to be aligned.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 16:04:33 -0500

On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely <[email-masked]> wrote

>     authenticated identity to be aligned.
May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

CURRENT:

   DMARC permits Identifier Alignment, based on the result of an SPF
   authentication, to be strict or relaxed.

   In relaxed mode, the [SPF
<https://tools.ietf.org/html/rfc7489#ref-SPF>]-authenticated domain
and RFC5322 <https://tools.ietf.org/html/rfc5322>.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.

   Note that the RFC5321 <https://tools.ietf.org/html/rfc5321>.HELO
identity is not typically used in the
   context of DMARC (except when required to "fake" an otherwise null
   reverse-path), even though a "pure SPF" implementation according to
   [SPF <https://tools.ietf.org/html/rfc7489#ref-SPF>] would check
that identifier.

   For example, if a message passes an SPF check with an
   RFC5321 <https://tools.ietf.org/html/rfc5321>.MailFrom domain of
"cbg.bounces.example.com", and the address
   portion of the RFC5322 <https://tools.ietf.org/html/rfc5322>.From
field contains "[email-masked]",
   the Authenticated RFC5321
<https://tools.ietf.org/html/rfc5321>.MailFrom domain identifier and
the
   RFC5322 <https://tools.ietf.org/html/rfc5322>.From domain are
considered to be "in alignment" in relaxed

   mode, but not in strict mode.

NEW:

DMARC permits Identifier Alignment, based on the result of an SPF

authentication, to be strict or relaxed.

In relaxed mode, the [@!RFC3986]-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.

For example, if a message passes an SPF check with an

RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address

portion of the RFC5322.From field contains "[email-masked]",

the Authenticated RFC5321.MailFrom domain identifier and the

RFC5322.From domain are considered to be "in alignment" in relaxed

mode, but not in strict mode. In order for the two identifiers to

be considered "in alignment" in strict mode, the domain parts would

have to be identical.

The reader should note that SPF alignment checks in DMARC rely solely

on the RFC5321.MailFrom domain. This differs from section 2.3 of
[@!RFC7208],

which recommends that SPF checks be done on not only the "MAIL FROM"

but also on a separate check of the "HELO" identity.

--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jan 2021 16:35:09 -0500

> but also on a separate check of the "HELO" identity.

I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null, postmaster@HELO 
is the mail from for SPF purposes.  DMARC really can't change that.

As a result, there are cases where Mail From results actually are derived from 
HELO and it's unavoidable.  I believe the proposed text is clear enough about 
not using separate HELO identity results and that's appropriate.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 12:54:56 +0100

On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:
>> [...]
>>    [@!RFC7208], which recommends that SPF checks be done on not only the
>>    "MAIL FROM" but also on a separate check of the "HELO" identity. >
> HELO and it's unavoidable.

I doubt that SPF filters report envelope-from=postmaster@HELO; more likely they 
write helo=HELO.  In that case, the paragraph quoted above is deceptive.

> I believe the proposed text is clear enough about not using separate HELO
> identity results and that's appropriate.

My filter collects SPF results recorded from an upstream SPF filter.  It writes 
Received-SPF: lines for each identity.  For NDNs, it writes a Received-SPF: for 
the HELO identity only.  Am I allowed to use that result for DMARC?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jan 2021 08:14:45 -0500

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> > If you look at RFC 7208 Section 2.4, when Mail From is null,
> > postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
> > change that.
> > 
> > As a result, there are cases where Mail From results actually are derived
> > from HELO and it's unavoidable.
> 
> I doubt that SPF filters report envelope-from=postmaster@HELO; more likely
> they write helo=HELO.  In that case, the paragraph quoted above is
> deceptive.
> My filter collects SPF results recorded from an upstream SPF filter.  It
> writes Received-SPF: lines for each identity.  For NDNs, it writes a
> Received-SPF: for the HELO identity only.  Am I allowed to use that result
> for DMARC?

No.  You should only use Mail From results.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 17:47:51 +0100

> No.  You should only use Mail From results.

So NDNs having only an aligned HELO will never pass DMARC?

And what is a <scope>helo</scope> element in aggregate reports provided for?

The spec says:

          [SPF] can authenticate either the domain that appears in the
    RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
    HELO domain, or both.

And then:

    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.

So, consider the following message without DKIM signatures:

HELO example.org
MAIL FROM:<[email-masked]>

Received-SPF: pass (domain example.org
   designates 192.0.2.1 as permitted sender)
   identity=helo; helo=example.org;
Received-SPF: fail (domain of [email-masked]
   denies 192.0.2.1 as permitted sender)
   identity=mailfrom; envelope-from="[email-masked]";
Subject: Not using a mail client for this example
From: [email-masked]

Does it pass DMARC?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jan 2021 17:36:19 -0500

> From: [email-masked]

No.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2021 10:49:02 +0100

On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
>>>> I doubt that SPF filters report envelope-from=postmaster@HELO; more 
>>>> likely they write helo=HELO.  In that case, the paragraph quoted above
>>>> is deceptive. >>>>
>>>>> I believe the proposed text is clear enough about not using
>>>>> separate HELO identity results and that's appropriate. >>>>
>>>> My filter collects SPF results recorded from an upstream SPF filter.
>>>> It writes Received-SPF: lines for each identity.  For NDNs, it writes
>>>> a Received-SPF: for the HELO identity only.  Am I allowed to use that 
>>>> result for DMARC? >>>

Let's not be silly, Scott.  We have example.org as the SPF-authenticated domain 
and it is aligned with From:.  Are you saying that the message would pass if it 
had an empty bounce address, but since it can bounce it does not pass?!?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jan 2021 09:00:29 -0500

On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
> >> And what is a <scope>helo</scope> element in aggregate reports provided
> >> for?>> 
> >> The spec says:
> Let's not be silly, Scott.  We have example.org as the SPF-authenticated
> domain and it is aligned with From:.  Are you saying that the message would
> pass if it had an empty bounce address, but since it can bounce it does not
> pass?!?

All I'm saying is that DMARC only uses mail from results and that's 
appropriate.  I don't think the case of HELO name being aligned, but mail from 
domain is not is one to worry about.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2021 18:25:59 +0100

On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:
>>>>>> is deceptive.
>>>>>> result for DMARC?
>>>> for?
>> domain and it is aligned with From:.  Are you saying that the message
>> would pass if it had an empty bounce address, but since it can bounce it
>> does not pass?!? >
> appropriate.  I don't think the case of HELO name being aligned, but mail
> from domain is not is one to worry about.

That's abnormal, not appropriate.

AFAIUI, there's no reason why SPF would work with a logic substantially 
different than DKIM's.  DKIM can provide n identifiers, if one of them is 
aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers but 
one of them is of class B.  WTF?

Can anyone explain why we have a <scope>helo</scope> element in aggregate reports?

Can we fix this aberration?

The spec needs a fix anyway, because from the text I quoted above I understood 
that the example message passes DMARC.  Am I the only one?

In addition, as I said, SPF filters are likely to report HELO as helo and MAIL 
FROM as mailfrom.  If we want to carry over this quirk, the spec must say that 
a DMARC filter which gathers SPF authentication status from an upstream filter 
MUST make sure that mailfrom is empty before validating based on an aligned helo.

Dropping that absurd discrimination between SPF identifiers would make for a 
smoother spec.  Since non-null mailfroms are in most cases aligned with either 
From: or helo, the differences between existing compliant implementations and 
the smoother spec would be limited to a hardly noticeable set of test messages.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jan 2021 14:24:05 -0500

On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote:
> The spec needs a fix anyway, because from the text I quoted above I
> understood that the example message passes DMARC.  Am I the only one?
> 
> In addition, as I said, SPF filters are likely to report HELO as helo and
> MAIL FROM as mailfrom.  If we want to carry over this quirk, the spec must
> say that a DMARC filter which gathers SPF authentication status from an
> upstream filter MUST make sure that mailfrom is empty before validating
> based on an aligned helo.
> 
> smoother spec.  Since non-null mailfroms are in most cases aligned with
> either From: or helo, the differences between existing compliant
> implementations and the smoother spec would be limited to a hardly
> noticeable set of test messages.

Your absurd is my eminently reasonable.

I can't explain why it was added, but it makes sense, IMO, to have it there to 
aid in reconstructing the exact situation for trouble shooting purposes.

DMARC has always (for the SPF related portion) been about alignment of mail 
from and from.  I don't think adding HELO has appreciable value and is 
certainly not worth the added complexity to implement DMARC to include.

There are lots of ways that DMARC could have addressed SPF.  Personally I 
thought it might make sense to skip using the mail from SPF result and just 
check if the from address would pass if it were subjected to an SPF check, but 
that's not the existing design.  I don't think it should be changed now.

That said, I agree it's not 100% clear.  I too am interested in what others 
think.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Jan 2021 12:10:37 -0800

> one of them is of class B.  WTF?

DKIM (in its simplest form) returns N tuples of the form (d= domain,
pass/fail).  All of them were run through exactly the same check; all of
them were attached to the message in exactly the same way; all of them have
essentially identical semantics.  Giving them equal footing makes sense to
me.

The two identifiers in SPF hold different places in the SMTP session, and
have different semantics.  I think treating them differently is also just
fine.

Can anyone explain why we have a <scope>helo</scope> element in aggregate
> reports?

Not off the top of my head.  If it's not meaningful, it should go.

> MAIL

...or it doesn't evaluate against SPF at all in such a situation.

Dropping that absurd discrimination between SPF identifiers would make for
> a
> either

I don't think we should ignore what those two identifiers mean, how likely
they are to contain junk, how they are applied, outside of DMARC, etc.

-MSK, participating

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jan 2021 13:13:00 +0100

> aid in reconstructing the exact situation for trouble shooting purposes.

Can you expand on how ignoring helo aids trouble shooting?

> certainly not worth the added complexity to implement DMARC to include.

 From an implementer POV, the complication stays in the idiosyncratic 
identifier processing.  I wonder how many do follow it strictly.  IMHO, a 
reasonable DMARC spec should either smooth out the discrimination or provide a 
clear explanation of why such peculiar processing is needed and what would 
happen if all identifiers were treated equal.

> that's not the existing design.  I don't think it should be changed now.

Yeah, after you insisted, I vaguely recollected about an SPF argument that I 
had erased from memory.  I can't recall its merit.

DKIM'S d= are domains, and DKIM scope is exactly to identify a domain.  That's 
more akin to helo than mail from.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jan 2021 13:13:06 +0100

On Wed 27/Jan/2021 21:10:37 +0100 Murray S. Kucherawy wrote:
>> aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers
>> but one of them is of class B.  WTF?
> 

It is relevant that both identifier come from /the same/ SMTP session.  That's 
not true for many DKIM signatures.

>> based on an aligned helo. >

Dropping SPF altogether is too much.  I'm querying about dropping just the 
idiosyncrasy...

>> Dropping that absurd discrimination between SPF identifiers would make
>> for a smoother spec.  Since non-null mailfroms are in most cases aligned
>> with either From: or helo, the differences between existing compliant
>> noticeable set of test messages. >

How is that different from d= identifiers?

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jan 2021 12:40:49 -0800

> not true for many DKIM signatures.

I guess if report consumers really want this information, we can include
it.  I just don't see the value in the HELO parameter if it's effectively
random junk in the session.  At least a passing DKIM signature is
associated with a domain that existed at some point in time and whose DNS
contained apparently-valid public keys.  I can mostly type anything I want
to HELO or EHLO.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2021 12:02:55 +0100

On Thu 28/Jan/2021 21:40:49 +0100 Murray S. Kucherawy wrote:
>>> pass/fail).  All of them were run through exactly the same check; all
>>> of them were attached to the message in exactly the same way; all of
>>> them have essentially identical semantics.  Giving them equal footing
>>> makes sense to me. >>>
>>> The two identifiers in SPF hold different places in the SMTP session,
>>> and have different semantics.  I think treating them differently is also
>>> just fine. >>
>> It is relevant that both identifier come from /the same/ SMTP session. 
>> That's not true for many DKIM signatures. >
> it.

Helo is essential if mfrom is missing.  A second SPF identifier is optional anyway.

> I just don't see the value in the HELO parameter if it's effectively
> random junk in the session.

Where does that notion come from?  Most mail admins choose the helo name 
carefully, possibly so that it resolves both ways to the IP number.

I just run a quick test on my current folder.  Out of 3879 messages I extracted 
944 unique helo names.  721 of these matched the reverse lookup exactly.  Out 
of the 223 remaining, 127 had an SPF pass for the helo identity anyway.  So in 
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining ~90% 
something worth considering?

> At least a passing DKIM signature is associated with a domain that existed
> at some point in time and whose DNS contained apparently-valid public keys.

Why cannot one type DKIM-Signature: d=anyrandomjunk ...?

> I can mostly type anything I want to HELO or EHLO.

That's true for any identifier.  We know an identifier is associated with a 
domain that existed at some point in time only after it's been authenticated.

One may say DKIM authentication is somewhat more precise, because the vogue is 
to include whole classes of IPs in SPF records.  But then, such lack of 
accuracy affects mfrom and helo alike.

The real difference between helo and mfrom is that the former is a 
configuration parameter of the sending relay, while the latter is set by the 
submission client.  The former is akin to d= and s=, while the latter is akin 
to From:.  No rationale to discard either, AFAICS.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Jan 2021 12:30:49 -0800

> something worth considering?

I am admittedly quite heavily biased against using the HELO/EHLO value for
anything.  I have simply never found value in it, probably because at the
SMTP layer it's simply a value that gets logged or used in cute ways in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a bogus
value, so it's even explicitly not useful to me.

Even if it's not junk, there's pretty much always something else on which
to hang a pass/fail decision about the apparent authenticity of a message
that at least feels safer if not actually being more sound.  Or put another
way, if you present to me a DKIM-signed message with a MAIL FROM value and
the only thing that passes is an SPF check against HELO, I'm mighty
skeptical.

Anyway, I'll let consensus fall where it may.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Jan 2021 11:41:02 +0100

On Fri 29/Jan/2021 21:30:49 +0100 Murray S. Kucherawy wrote:
>> I just run a quick test on my current folder.  Out of 3879 messages I 
>> extracted 944 unique helo names.  721 of these matched the reverse lookup
>> exactly. Out of the 223 remaining, 127 had an SPF pass for the helo
>> identity anyway. So in 96 cases, roughly 10%, the helo name was indeed
>> junk.  Isn't the remaining ~90% something worth considering? >

There seems to be consensus on changing the MUST NOT there to a SHOULD NOT. 
See ticket #19 of emailcore.

> that at least feels safer if not actually being more sound.

I might understand being reluctant to spend a DNS lookup for a TXT record that 
many operators don't care to define.  However, we're discussing the case that 
an upstream SPF filter already acquired and evaluated that record.

> Or put another way, if you present to me a DKIM-signed message with a MAIL
> FROM value and the only thing that passes is an SPF check against HELO, I'm
> mighty skeptical.

We have helo as the only valid identifier in most DSNs.  What is idiosyncratic 
is that a message MUST be a DSN (i.e. have an empty mfrom) in order for an 
already authenticated helo to be considered significant.  What I'm proposing is 
actually a simplification.

> Anyway, I'll let consensus fall where it may.

Thank you
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sat, 30 Jan 2021 07:44:24 -0500

I have been using forward-confirmed DNS in my filtering logic for a long
time.   These are my results from a recent time period:
4.5% neither name confirmed
9.6% reverse DNS confirmed only
39.7% Helo confirmed only
46.2% Both confirmed

Of the ones where both were confirmed:
96% had the same domain in both names,
4% had different domains between HELO and REVDNS

I apply my DNS blacklisting rules to both domain names.
I often use a verified DNS domain (either type) with SMTP domain to define
corrections for sender SPF policy.
HELO is part of the SPF algorithm that I use, but I do not track how often
it is used to generate SPF PASS.
I use BATV to I don't worry much about SPF or DMARC for automatic messages.

Overall, I don't know how important HELO is to SPF, but it is verifiable
and often useful.

Doug Foster

On Sat, Jan 30, 2021 at 5:41 AM Alessandro Vesely <[email-masked]> wrote:

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

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 30 Jan 2021 11:59:13 -0800

On 29 Jan 2021, at 12:30, Murray S. Kucherawy wrote:

>> extracted
>> 944 unique helo names.  721 of these matched the reverse lookup 
>> exactly.
>> Out
>> of the 223 remaining, 127 had an SPF pass for the helo identity 
>> anyway.
>> So in
>> 96 cases, roughly 10%, the helo name was indeed junk.  Isn't the 
>> remaining
>> ~90%

The issue isn’t the existing use of HELO names, it’s how they could 
be (mis-)used. The fact that a message sender can put anything there 
makes HELO basically meaningless.

> Anyway, I'll let consensus fall where it may.

+1 to Murray’s comments. I realize that null MAIL FROM on bounce 
messages is a problem for SPF, but relying on HELO is  not a reasonable 
substitute.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 30 Jan 2021 16:23:38 -0500

>makes HELO basically meaningless.

This is DMARC -- the HELO domain has to match the header From: and there
has to be an SPF record that validates it.

The most plausible case is that it's a bounce messsage

 From: [email-masked]

the MAIL FROM is null, HELO is mta27.foo.bar.example.com, and the SPF
record for mta27.foo.bar.com says that IP is OK.

I don't feel strongly about whether to use the HELO name but it doesn't break anything.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 30 Jan 2021 16:27:02 -0500

As long as Helo is forward confirmed to the source IP, why is it a risk to
use it to indicate the domain name?

---

From: "John Levine" <[email-masked]>
Date: 30 Jan 2021 16:29:45 -0500

>record for mta27.foo.bar.com says that IP is OK.

I wish I could type: ... for mta27.foo.bar.example.com says that the IP is OK.

R's,
John

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 30 Jan 2021 13:39:56 -0800

> has to be an SPF record that validates it.

True, but only if the MAIL FROM address is null and there isn’t a 
valid aligned DKIM signature.

> record for mta27.foo.bar.com says that IP is OK.

So in this case, why involve the HELO at all? One could just check the 
SPF record of the header From: that it’s trying to align with. Except 
that’s probably SenderID, not SPF.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 30 Jan 2021 16:57:44 -0500

> True, but only if the MAIL FROM address is null and there isn’t a valid 
> aligned DKIM signature.

True, but I don't see why that matters.

> So in this case, why involve the HELO at all? One could just check the SPF 
> record of the header From: that it’s trying to align with. Except that’s 
> probably SenderID, not SPF.

Because that's how DMARC works.  The header From has to match a DKIM or 
SPF identity.

Part of the problem here is that DMARC generally sits on top of an SPF 
library which doesn't tell you how it got its result.  My DMARC code just 
calls the SPF library and uses the result.  I suppose I could put in a 
hack to say don't use the SPF result if the MAIL FROM is null, but I don't 
think that's what 7489 says.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 30 Jan 2021 14:02:17 -0800

> True, but I don't see why that matters.

Just confirming the context of your earlier statement.

> Because that's how DMARC works.  The header From has to match a DKIM 
> or SPF identity.
>
> library which doesn't tell you how it got its result.  My DMARC code 
> just calls the SPF library and uses the result.  I suppose I could put 
> in a hack to say don't use the SPF result if the MAIL FROM is null, 
> but I don't think that's what 7489 says.

Are changes to 7489 off the table here? I didn’t know.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 30 Jan 2021 17:09:06 -0500

On Sat, 30 Jan 2021, Jim Fenton wrote:
>> calls the SPF library and uses the result.  I suppose I could put in a hack 
>> to say don't use the SPF result if the MAIL FROM is null, but I don't think 
>> that's what 7489 says.
>

They are certainly possible, but I would want a good reason.  At this 
point, SPF using HELO seems harmless so I don't see a reason to disallow 
it.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Sat, 30 Jan 2021 14:44:47 -0800

On 1/30/21 2:09 PM, John R Levine wrote:
>>> Part of the problem here is that DMARC generally sits on top of an 
>>> SPF library which doesn't tell you how it got its result.  My DMARC 
>>> code just calls the SPF library and uses the result.  I suppose I 
>>> could put in a hack to say don't use the SPF result if the MAIL FROM 
>>> is null, but I don't think that's what 7489 says.
>>
> point, SPF using HELO seems harmless so I don't see a reason to 
> disallow it.
>
>
 From a security standpoint, I wonder why you would want to allow 
something you know can be gamed. But that is probably more a question 
for SPF itself.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 30 Jan 2021 18:06:17 -0500

> something you know can be gamed. But that is probably more a question

From a DMARC perspective, I don't think it can be in any useful way.  Agree 
that digging into it further is more about SPF itself, presumably OT here.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Sat, 30 Jan 2021 19:44:45 -0500

Anything can be gamed if it is trusted without verification. But verifiable
data is hard to game.   If you ensure that Helo can be forward confirmed
before considering it trusted, how is it risky?

---

From: Douglas Foster <[email-masked]>
Date: Sat, 30 Jan 2021 21:27:41 -0500

The SMTP address and the HELO name are very similar in their trust
characteristics.
Both of them can be manipulated maliciously, but both can be verified with
similar techniques:   Using a DNS lookup to associate the name
assertion with the Source IP.
(We all know that the Source IP can be manipulated with a NAT device
sitting outside a network perimeter, but we ignore that possibility.   If
it is happening, there are worse things than email verification occurring.)

We do know that Reverse DNS is often outside the control of the mail
domain, so it is actually a less reliable indicator of domain ownership
than Helo.

Overall, the SPF design seems very intuitive and defensible.
I think it is unrealistic to expect rapid implementation of DKIM signatures
on null-address messages, and HELO is a good substitute.  Nor does it seem
necessary.  I see no problem using HELO in my DMARC evaluations when the
SMTP address is null.

My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting.   It should not be ignored.

Doug Foster
.

On Sat, Jan 30, 2021 at 7:44 PM Douglas Foster <
[email-masked]> wrote:

> Anything can be gamed if it is trusted without verification. But
> verifiable data is hard to game.   If you ensure that Helo can be forward
> confirmed before considering it trusted, how is it risky?
>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Jan 2021 13:01:35 +0100

On Sat 30/Jan/2021 22:57:44 +0100 John R Levine wrote:
> 
> Part of the problem here is that DMARC generally sits on top of an SPF library 
> which doesn't tell you how it got its result.  My DMARC code just calls the SPF 
> library and uses the result.  I suppose I could put in a hack to say don't use 
> the SPF result if the MAIL FROM is null, but I don't think that's what 7489 says.

One way to interpret RFC 7489 is that you can put dmarc=pass based on the helo 
identity *only if* MAIL FROM is null.  So the hack there is a bit more tricky. 
  You want to use the SPF result only if MAIL FROM is null, except in cases 
when you authenticate based on MAIL FROM.  That's idiosyncratic!

On Sat 30/Jan/2021 20:59:13 +0100 Jim Fenton wrote:
> The fact that a message sender can put anything there makes HELO basically
> meaningless.

Here "message sender" has to be a mail server admin.  Compare with MAIL FROM, 
where "message sender" is the actual author submitting a message.  How come 
that the same assertion being more widely true for MAIL FROM doesn't make the 
latter basically meaningless?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 31 Jan 2021 11:52:10 -0500

On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> One way to interpret RFC 7489 is that you can put dmarc=pass based on the 
> helo identity *only if* MAIL FROM is null.

That would be consistent with 7489.

Sec 3.1.2 says

    Note that the RFC5321.HELO identity is not typically used in the
    context of DMARC (except when required to "fake" an otherwise null
    reverse-path), even though a "pure SPF" implementation according to
    [SPF] would check that identifier.

But then 4.1 says

    o  [SPF], which can authenticate both the domain found in an [SMTP]
       HELO/EHLO command (the HELO identity) and the domain found in an
       SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
       of SPF authentication of the MAIL FROM identity.  Section 2.4 of
       [SPF] describes MAIL FROM processing for cases in which the MAIL
       command has a null path.

That section of 7208 says that if there's a null bounce address, SPF 
pretends that the MAIL FROM was postmaster@HELO.

If we want, we can say not to use the SPF HELO identity, but that would be 
an incompatible change to 7489 and I suspect would not match what most 
DMARC checking code does.

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Sun, 31 Jan 2021 14:03:45 -0500

I don't see any justification for using HELO unless the SMTP address is
null.  If the SPF RFC says otherwise, this should be corrected.   Proving
that the server domain can be tied to the IP address does nothing to prove
that the SMTP address can be tied to the Source IP.

For DMARC, HELO is only useful if the message's From domain and the
server's HELO domain are aligned.  A high percentage of email domains use
servers from a different DNS domain, so this will only be true on an
exception basis..   Consequently, software products that apply DKIM
signatures to messages MUST be able to them to automatic messages as well.
 Once developers provide MTA and mailstore products which service the needs
of hosted domains, then users of non-hosted domains will be able to sign
their automatic messages as well.   Ergo, any supposed need for HELO with
DMARC will go away.

DF

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 31 Jan 2021 19:10:01 -0500

I think that we're well past learning anything new in this thread.

SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol 
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be 
able to consume the Mail From result.  End of story.

I'd suggest close the ticket and move on.

Scott K

On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> > > One way to interpret RFC 7489 is that you can put dmarc=pass based on
> > 
> > the
> >