I was investigating a rejected e-mail that was sent with the following
NOQUEUE: reject: RCPT from unknown[184.108.40.206]: 504 5.5.2
<taiwangun-1>: Helo command rejected: need fully-qualified hostname;
from=<[hidden email]> to=<[hidden email]> proto=ESMTP
It was rejected, because I have reject_non_fqdn_hostname set in my
postfix. Sending HELO (not EHLO) with a non-fqdn hostname seems wrong
and I wanted to find specific RFC that governs that. Here's what the man
page for postfix says:
Reject the request when the HELO or EHLO hostname is not in fully-
qualified domain or address literal form, as required by the RFC.
Sadly, it does not cite specific RFC. So I kept digging. Here's what I
found. RFC1123, section 5.2.5 says:
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
But then there's this:
However, the receiver MUST NOT refuse to accept a message, even if
the sender's HELO command fails verification.
My interpretation is that with reject_non_fqdn_helo_hostname, postfix
violates that MUST NOT. Is my interpretation correct? If that is so,
perhaps docs should be updated pointing that out. I very well understand
why people may want to use that option (I use it myself). It's just a
matter of the docs being a bit misleading with the "as required by the
If that makes any difference, my postfix is 2.11.3 running on Debian.
I'm absolute beginner with SMTP, but have quite a bit of experience with
IETF and RFCs.
From RFC 1123 -
5.2.5 HELO Command: RFC-821 Section 3.5 The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter. 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. DISCUSSION: Verifying the HELO parameter requires a domain name lookup and may therefore take considerable time. An alternative tool for tracking bogus mail sources is suggested below (see "DATA Command"). Note also that the HELO argument is still required to have valid <domain> syntax, since it will appear in a Received: line; otherwise, a 501 error is to be sent. IMPLEMENTATION: When HELO parameter validation fails, a suggested procedure is to insert a note about the unknown authenticity of the sender into the message header (e.g., in the "Received:" line).
The "MUST NOT" seems to refer to validation that the HELO parameter validates to a correct domain name lookup, not that it can be a some other value that's not a domain name. In the discussion it clearly says that if it doesn't match the syntax, it should generate a 501 error.
On Wed, Aug 2, 2017 at 3:43 PM, Tomasz Mrugalski <[hidden email]> wrote:
In reply to this post by Tomasz Mrugalski
RFC1123 is updated by, among others, RFC5321 which says in section 4.1.4:
hen in section 7.9:
On Wed, Aug 2, 2017 at 2:43 PM, Tomasz Mrugalski <[hidden email]> wrote:
RFC5321 has a description of domain names in section 2.3.5 -
On Wed, Aug 2, 2017 at 4:10 PM, John Hascall <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|