Must an SMTP client provide the MTA a globally resolvable hostname in the HELO?

Question

In short: I'm trying to figure out if I should tell a mail administrator of a friend's employer whether their mail configuration should be fixed, or if I should revise my own policy to be more liberal in what I accept, or neither.

A friend was complaining of being unable to reach anything on my mailserver. I dug into it and it seems that the hostname provided by his mail server when it connected to mine was somewhere in the *.local space, meaning it wasn't globally resolvable.

They were rejected with "Helo command rejected: Host not found;" by my postfix mailserver. I'm perhaps strict on my UCE checks in postfix, so I whitelisted their (in my opinion, misconfigured) server but now I'm trying to figure out to what extent they actually are misconfigured, versus whether I'm just being too harsh in what I accept.

So then I checked the RFCs - RFC 821 says "The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification." which suggests to me that I'm actually the one violating the RFC.

Was this portion of RFC 821 ever replaced by a future RFC, that I can point to? Or must mail servers accept mail with bogus HELOs? Are there any well respected authorities I can point to that state the HELO hostname should be valid, as a reference for contacting their mail admin?

Answer 1

Yes they should. Lots of other systems, including yahoo, will reject mail from hostnames they can't reverse map to the connecting IP, or that they can't resolve.

Answer 2

As you cite, the RFC 822 standard leaves the behavior up to the MTA. These days, rejecting connections at the HELO stage if the name can't be resolved (and checking it against a blacklist such as spamhaus) is the only way for MTAs to keep up with the flood of spam generated by botnets.

So there's no standard that says you MUST, but if you don't, your email won't get very far.

Answer 3

SMTP RFCs do not require it, but lots of popular systems will reject mail with bogus HELOs. Note that RFC 1033 and RFC 1912 both require all internet-reachable hosts to have a valid name; simply listing that name in the HELO will fix many problems. Some spam filters, unfortunately, also reject mail from hostnames containing strings that imply they are in dynamic address pools (e.g. "dynamic", "dsl", or a dash-separated IP address as is common with many ISPs).

One option if your friend does not have control over their reverse DNS is to use a suitable machine as smarthost for outgoing mail; e.g. their ISP's mailserver.

Answer 4

Eh, I disagree. It can provide total garbage within the EHLO/HELO if it wants to. As long as it says something, and as long as I can resolve the ip address it's coming from, I'm happy.

Inside the EHLO is often a short hostname, not a FQDN.

Answer 5

Strictly, you're both violating the RFC.

The sections of note are:

The sender-SMTP MUST ensure that the parameter in a HELO command is a valid principal host domain name for the client host.

and

The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

Due to the prevalence of spam, mailservers these days are considerably stricter than the RFCs say they should be, and it is common to find all sorts of proprietary checks and reasons for rejection.

However, they're not doing themselves any favours at all by having an incorrect hostname in their HELO string. Whereas your mailserver will probably work perfectly well, theirs is likely to have trouble sending and receiving email from many systems.

I would let them know. If only because of their misconfiguration, they're probably not getting all the email they should be.