On Fri 29/Jan/2021 21:30:49 +0100 Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely <ves...@tana.it> 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
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
