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

[Douglas Foster <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>