|
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 (usebsd
free.fr)
Date: Mon Oct 03 2005 - 13:26:44 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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).
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]