Does reject_non_fqdn_helo_hostname violate RFC?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Does reject_non_fqdn_helo_hostname violate RFC?

Tomasz Mrugalski
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=<[hidden email]> to=<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does reject_non_fqdn_helo_hostname violate RFC?

Dan Schwartz
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:
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=<[hidden email]> to=<[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does reject_non_fqdn_helo_hostname violate RFC?

John Hascall
In reply to this post by Tomasz Mrugalski
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 <[hidden email]> 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=<[hidden email]> to=<[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does reject_non_fqdn_helo_hostname violate RFC?

Dan Schwartz
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 <[hidden email]> 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 <[hidden email]> 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=<[hidden email]> to=<[hidden email]> 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 | [hidden email] | (610) 758-5061

Loading...