OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: reject_non_fqdn_hostname and RFC

From: mouss (usebsdfree.fr)
Date: Mon Oct 03 2005 - 13:26:44 CDT


Mariano Cunietti a écrit :

>Hi,
>after setting up my "reject_non_fqdn_hostname", I looked around to see
>what RFCs mandate about HELO syntax, and I did find this:
>
>
>
[snip]

>RFC 2821:
>
>4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
> These commands are used to identify the SMTP client to the SMTP
> server.
>
the rule is:

> The argument field contains the fully-qualified domain name
> of the SMTP client if one is available.
>
and the exception is:

> In situations in which the
> SMTP client system does not have a meaningful domain name (e.g., when
> its address is dynamically allocated and no reverse mapping record is
> available), the client SHOULD send an address literal (see section
> 4.1.3), optionally followed by information that will help to identify
> the client system.
>
So if you don't give an fqdn, you SHOULD give a literal. This is the
currently accepted practice.

You can also look at RFC1123 ("Requirements for Internet Hosts,
Applications and Support").

=> Note that "localhost", "com", "org", ... etc are fqdn, but will be
rejected by reject_non_fqdn_hostname. While this is debatable, it's a
non-issue (just whitelist those TLDs you want to accept in the right place).

Some people also check that the helo name can be resolved (IP(helo) !=
empty) and some even require it to resolve to the client IP (IP(helo)
contains client_ip). The standards do not recommend rejecting based on
these checks though. one may use them in specific situations (such as if
client is listed in a DUL).