RFC 5321 4.1.4 *prohibits* reject_unknown_helo_hostname AFAIK??!!!

[MrPete]

Although I registered dot com #43, and have run my own email servers forever... I certainly don't consider myself an authority let alone an expert. So I ask the following hoping that someone who Really Knows can answer :)

I've long configured with reject_unknown_helo_hostname.

An "important" (to me) email source got rejected by this. Wanting to be a Nice Guy, I went searching for the RFC that they had violated so I could gently nudge them to fix their config...

An SMTP server MAY verify that the domain name argument in the EHLO

command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. Information captured in the
verification attempt is for logging and tracing purposes. Note that
this prohibition applies to the matching of the parameter to its IP
address only; see Section 7.9 for a more extensive discussion of
rejecting incoming connections or mail messages.

Woah!

What am I missing? This seems quite direct. MUST NOT refuse the message just because there's no match between FQDN and IP.

(NOTE: In this particular case, the FQDN is a subdomain that....
* Is resolved as the RDNS of the various sending IP addresses
* Is NOT resolved by DNS
)

[MrPete]

Post by MrPete

An SMTP server MAY verify that the domain name argument in the EHLO

command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.

I further see (2.3.5)

Post by MrPete
The domain name given in the EHLO command MUST BE either a primary

host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal...

In this case, it does NOT resolve.

Putting all that together, I am now believing:
* The sender's EHLO MUST use either an FQDN that resolves to something, or an address literal
* It's fine to require that the sending IP has an RDNS that resolves to the claimed EHLO FQDN (if any). A 550 error should be used in such a case (7.9)

I've been also using reject_unknown_client_hostname -- which appears to be validating the above quote in section 2.3.5

Here's hoping I'm beginning to get this right? LOL