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.
Rubbish. There are a multitude of ways to work around that.
> 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".
Proving to itself the legitimacy of it's own identity is irrelevant.
If someone cannot set up an outgoing system with a legitimate HELO, that
is pure numptyness. The software should not have to prove anything to
itself because some plonker cannot configure it correctly.
> And anyway, the client may be connecting to some servers on the local
> side of the NAT box and some on the far side.
To where it is connecting is also pretty much irrelevant. This again
comes down to the skills, or lack of, of the admin responsible.
> 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.
Rather the opposite, in fact. The system should be correctly configured
regardless of where or how it connects to anyone.
Firewalls and NAT routers have one specific purpose. They should be used
for only that, not altering smtp traffic because of poor configuration by
the client|server admin.
> 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.
With regards to the above, and an internal hostname, internal and
external should be seperate. An internal server should not be connecting
externally, or if it does, it should have, and use, a valid external
identity.
> 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.
Again, this comes back to my original point. If the clients admin cannot
be arsed to configure their system correctly, why should they expect to be
allowed any degree of courtesy from remote systems? What is the point of
making the server do what the client should have already done.
Matt
