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

[Jim Fenton <[e-mail]>]

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

> On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely <[e-mail]> 
> 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?

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.

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

+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