RFC5321 has a description of domain names in section 2.3.5 -
2.3.5. Domain Names
A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.
The domain name, as described in this document and in RFC 1035 [2],
is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
On Wed, Aug 2, 2017 at 4:10 PM, John Hascall <j...@iastate.edu> wrote:
> RFC1123 is updated by, among others, RFC5321 which says in section 4.1.4:
>
> 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.
>
>
> And t
> hen in section 7.9:
>
>
> It is a well-established principle that an SMTP server may refuse to
> accept mail for any operational or technical reason that makes sense
> to the site providing the server.
>
>
>
> John
>
> On Wed, Aug 2, 2017 at 2:43 PM, Tomasz Mrugalski <spam.post...@klub.com.pl
> > wrote:
>
>> Hi,
>>
>> I was investigating a rejected e-mail that was sent with the following
>> error message:
>>
>> NOQUEUE: reject: RCPT from unknown[46.248.167.50]: 504 5.5.2
>> <taiwangun-1>: Helo command rejected: need fully-qualified hostname;
>> from=<w...@tajeb.atomstore.pl> to=<myem...@mydomain.com.pl> proto=ESMTP
>> helo=<taiwangun-1>
>>
>> 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
>> client host.
>>
>> 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
>> RFC" part.
>>
>> Thoughts?
>>
>> If that makes any difference, my postfix is 2.11.3 running on Debian.
>>
>> Tomek Mrugalski
>>
>> p.s.
>> I'm absolute beginner with SMTP, but have quite a bit of experience with
>> IETF and RFCs.
>>
>
>
--
--
Dan Schwartz | LTS - Systems Engineering | Lehigh University |
d...@lehigh.edu | (610) 758-5061
