Using SPF on HELO/EHLO hostnames is repurposing SPF to validate a different thing

September 26, 2020

Back in June I discovered that in theory we should have SPF records for EHLO hostnames too. The conventional explanation for this (apart from 'big email providers say so', the usual reason to do anything in modern SMTP) comes from, for example, this writeup of small mailserver best current practices, and goes like this (I'm paraphrasing):

People use SPF to validate the envelope sender domain (the SMTP MAIL FROM). However, when you send a bounce, it has a null sender and thus no sender domain to use for SPF checks. So the sender domain is taken from the EHLO hostname, for lack of a better place to get it from (since there is no SMTP level 'the bounce claims to have been sent by X domain' information to be had, although this is commonly in the message headers).

This is of course kind of bogus. What is really happening here is that receiving mail servers are attempting to validate that the EHLO/HELO hostname itself is not forged and are using SPF for this purpose. This is a complete repurposing of SPF, which we can see since 'Sender' is right in the name 'Sender Policy Framework' and there's no 'sender' of the bounce that is visible at the SMTP level (and no entirely standard way that it's visible in the mail headers, either).

There are some lessons here for email related 'standards' and in general any Internet standards, which I can summarize this way: if there's a hole that people think needs filling, any nearby peg will get hammered into it regardless of what the peg was originally designed for.

PS: This elaborates on a recent tweet of mine that was sparked by adding SPF DNS records for our EHLO hostnames (and writing the official explanation of the change for our records).

Sidebar: This explanation and RFC 7208

RFC 7208 says two things in section 2.3, The "HELO" Identity:

  • it's RECOMMENDED that you check the HELO identity (but carefully) all the time, and do so before checking MAIL FROM.

  • if the envelope sender is the null sender, the message is presumed to come from 'postmaster@<HELO name>' and this is used as the MAIL FROM to check (even if you already checked the HELO identity).

I haven't gone through RFC 7208's section on doing SPF checks to see if it treats HELO and MAIL FROM checks somewhat differently in its algorithm, because frankly I'm not interested enough.

This means that RFC 7208 itself is a superset of the conventional explanation I summarized above. In RFC 7208, you have SPF records for your EHLO hostnames both because of bounces and because receivers are recommended to check them all the time. This implies that all of your mail sending machines should have SPF records, not just the ones that can send bounces.

(Now that I've looked that up, I may need to update some of our DNS records. Again.)

Written on 26 September 2020.
« Python virtual environments transparently add themselves to sys.path
We rebooted all of our servers remotely (more or less) and it all worked »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 26 16:47:39 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.