[RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss Digest, Vol 39, Issue 5)

[Alan Brown]

On Thu, 13 Apr 2006, Administrative Account wrote:

> 	Alex,
>
> 	For a an example of why the *host* name of the server simply will
> not work in some cases, I ask that you consider NAT as described in RFC1631
> and RFC2663 and in particular consider section 4.4 of RFC2663 (and yes, this
> is not a standard, but is only "Informational").
>
> 	The client as seen by the "foreign" MTA is defined by the IP of
> the source packets in the SMTP transaction, but in the case of NAT, these
> do not have the same IP as the actual sending machine *knows* itself to have
> and in the situation described in RFC2663 section 4.4 there is no one to one
> mapping, so no particular hostname can be chosen that will provide any way
> to successfully perform a check of HELO/EHLO argument == rDNS of client IP.
>
> 	Simply put, in this case (even without "private" RFC1918 IP addresses)

And if the NATed host _is_ in RFC 1917 space, its canonical hostname by
definition must not appear in global namespace.

Which is why any attempt to define a FQDN as "must resolve" in HELO
checks is doomed to failure in a high enough percentage of cases to
cause mail problems.

Some _very_ large organisations equipped with historically ancient /8
allocations force all traffic onto the net via gateways. Until recently
the entire country of Vietnam did so too.

(Not to mention all those winblows boxen which are going to give
non-resolvable HELOs when their MUAs connect, necessitating exeception
lists for "local" IP ranges on port 25 connections, or some way of
forcing all users to use MSA/smtps connections.)


-- 
      If a person, or organisation, starts to play on your fears
      it may be that person or organisation that you should fear.