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

[Alessandro Vesely <[e-mail]>]

On Fri 29/Jan/2021 21:30:49 +0100 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? >
> 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.


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


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


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