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