The critical problem is that SPF PASS on HELO cannot produce PASS if the
>From domain is using a hosting service. This is a fundamental flaw, given
that so many domains are hosted on third-party servers.
Quick check of some cloud services:
- Outlook.com publishes SPF records on their HELO names, but that only
produces an aligned PASS for domain Outlook.com.
- ProofPoint and Barracuda do not appear to publish SPF on their HELO names
My numbers are also very different from yours. I wonder if the difference
has to do with the issue of alignment. Another possibility is that my
data includes a lot of spam. I started down this road because of the need
to distinguish between wanted and unwanted null sender messages, and it
quickly became evident that SPF on HELO would be of no help:
Overall:
322 (1.1%) of null sender records have a DKIM signature
29,810 (98.92%) of null sender records lack an aligned DKIM signature
Further dividing the ones without a DKIM signature
29,171 (98.2%) HELO has no alignment with FROM, SPF on HELO cannot produce
DKIM PASS
54 (0.18%) HELO has relaxed aligned with FROM, SPF on HELO could
produce DKIM PASS
163 (0.55%) HELO has strict alignment with FROM, SPF on HELO could
produce DKIM PASS
An earlier comment you made is correct: Non-deliverable messages come
from the server domain. Auto-replies such as out-of-office come from the
original recipient address. On rare occasions, I have seen legitimate null
sender messages that are neither auto-reply nor non-delivery notices.
SPF on From assumes that any server which generates legitimate messages
from Example.Com can also be expected to generate legitimate auto-reply
messages from Example.Com.
If SPF on HELO produces PASS, it tells us that the server owner has
authorized the server to send mail for at least one domain. I expect
legitimate organizations to enforce this at their firewall, by allowing or
blocking port 25. So the real value I gain from SPF on HELO is that the
server organization is properly identified. This is essentially the same
result produced by checking the HELO name for forward and reverse match to
the Source IP. But this piece of data tells me nothing about whether the
server is authorized to speak for the From domain, and as I have indicated,
the alignment test has a fatal flow when used in this context.
Doug Foster
On Sun, Jun 9, 2024 at 1:32 PM Richard Clayton <[email protected]>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <CAH48Zfwke97+H66f3+MRqGkmha=MhA7tbzoSzRj2ELsw93ZK-
> [email protected]>, Douglas Foster <[email protected]>
> writes
>
> > I would be happy to have you or anyone else explain to me
> > (a) What data indicates that a non-trivial number of servers have
> > SPF policies on their host name, and
> > (b) How the answer to that lookup provides information useful to
> > an evaluation decision.
>
> I looked at the data from $DAYJOB$ for last Wednesday UTC (a typical day
> I believe)
>
> For email with a null "MAIL FROM" (which includes a certain amount of
> spam as well as delivery status reports ...)
>
> I see
>
> dkim fail, spf fail: 11%
> dkim fail, spf pass: 6%
> dkim pass, spf fail: 14%
> dkim pass, spf pass: 69%
>
> $DAYJOB$ is coy about absolute numbers but the smallest category there
> is more than 10 million and less than 100 million messages.
>
> When I look at the spf=pass results I see more than 650,000 unique EHLO
> strings. I think that qualifies as non-trivial.
>
> Evaluation decisions at $DAYJOB$ are very complex indeed; but that 11%
> will not be an issue RSN (because of "no auth no entry" policies)
>
> YMMV ... but I would be interested in learning what sort of volume you
> are drawing conclusions from.
>
> - --
> richard Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZmXmrd2nQQHFxEViEQJi/QCgqBl0/6ll/WSu+KKt7qNzE8LPJBAAoM6W
> 4xmGfD6kE8ikBoD87vv1dvgq
> =wD4z
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> dmarc mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
