Re: [exim] Exim server behind NAT router (and HELO)

On Wed, Mar 23, 2005 at 11:44:54AM +0000, Matt Fretwell wrote:
> Brian Candler wrote:
>
> > Of course, even if it sends an IP address literal, it will be wrong if
> > it's behind a NAT firewall.
>
> Not it if announces the IP of the NAT unit. That is the IP it is seen as
> connecting from, so why not announce with that address.

Because there's no way, in general, for it to learn that information.
Consider the very common case when the client host is 192.168.0.1, is sat
behind a DSL NAT router, and the public external IP address is assigned
dynamically by the ISP.

Even with a fixed external IP, you can't statically configure the EHLO name
if you accept the argument in this thread which says "a client should not
say EHLO <foo> unless it can first prove to itself that <foo> is a valid
name or address for itself". And anyway, the client may be connecting to
some servers on the local side of the NAT box and some on the far side.

Maybe you'd argue that SMTP connections going via NAT should have the EHLO
line surreptitiously modified in-transit, in the same way that FTP
connections have to be modified when going through NAT. That makes me
shudder.

For me, the point is that the EHLO name is a *debugging tool*. That is, if a
client decides to announce itself as EHLO WINSRV01, then the string
"WINSRV01" will end up in a log file somewhere, and it may be useful when
tracing problems. The string "WINSRV01" may have local significance, or it
may have signficance to a remote site when combined with IP address
information.

Clearly (to me) it's more useful to have:

Received: from 192.0.2.1 (nat-fw-1.example.com [EHLO WINSRV01])

than to have only

Received: from 192.0.2.1 (nat-fw-1.example.com [nat-fw-1.example.com])

But what seems like a common-sense idea to me is clearly not shared by
everyone else on this list.

Obviously the EHLO value may be forged (in which case it has no value in
those cases); in the cases where it's not forged, it can be useful.

If the EHLO name is *forced* to have some correspondence to the DNS name of
the sending machine, then it loses its value entirely: in that case it
should have been omitted from the protocol altogether. The server can always
do a reverse DNS lookup of the remote IP itself to gain that information.
There's no point making the client do the same thing as well.

Checking the EHLO name against DNS has no value as an anti-spam measure
either. A spammer can make their EHLO name match their reverse DNS
trivially. But if you turn on this check, you *will* block legitimate mail
from systems which are either "badly configured" (by certain people's
reading of the RFCs), or are in an unusual situation, such as being behind a
NAT firewall.

So in summary: as far as I see it, the EHLO value is simply a tag which the
client can insert into log files at the server end to be associated with
this SMTP connection. The server can also log the IP address and reverse DNS
if it wishes. When reading log files, it may help you identify problems.

Regards,

Brian.