In message <20050323141410.GB39708@???>, Brian Candler
<B.Candler@???> writes
>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.
you don't necessarily need general mechanisms when specific ones work
fine...
my box says EHLO mail.highwayman.com and (as many people check) you'll
find that mail.highwayman.com resolves to the connecting IP address.
You'll also find (if entirely bored) that the in-addr.arpa value doesn't
mention highwayman.com ... but that sort of mismatch is hardly unusual
for any machine and getting anal about that is going to reduce your
circle of friends quite considerably :(
>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.
there's a mixing up here of the issues that arise with NAT and the
issues that arise with dynamic IP addresses :(
In practice, it's quite possible to arrange for the DNS to work as
above, even for dynamic addresses (which on most systems are never quite
as dynamic as people sometimes imagine anyway). Most xDSL routers these
days come with features to automatically kick Dynamic DNS systems when
the DHCP client gets a new answer... and modern Windows does dynamic
DNS magic out of the box (unless you're wise enough to turn it off!)
>Even with a fixed external IP, you can't statically configure the EHLO name
of course you can ... ah... but there's more to your sentence :)
>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".
I can think of ways of doing that... but they'd involve a trusted third
party -- and frankly I'd very much rather my machine did what I told it
to in the configuration file -- and stopped trying to "prove" things to
itself :) Mind you a warning in the log file wouldn't be the end of
the world and might stop the odd bullet-in-foot incident :)
>For me, the point is that the EHLO name is a *debugging tool*.
What needs to be clearly understood is that this month (and for several
months past) it has been a very useful heuristic in spotting wickedness.
However there's no reason _whatsoever_ to believe that it will be a
useful heuristic next month (there is overwhelming evidence of the
extremely rapid evolution of spam sending techniques) but today, and
probably even for the rest of the week, using it will make some people
happy.
So I'm prepared to let them get on with it, without excessive quoting of
RFC contents. There's much worse heuristics and very damaging half-
baked ideas floating around :( and I'd rather save the bandwidth for
flaming those :)
>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])
I agree :) so I may be shooting the messenger here :)
- --
richard Richard Clayton
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
