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

At 2:14 pm +0000 2005/03/23, Brian Candler wrote:
>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.

see further down

>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.

that is a valid point of view (but see below); unfortunately,
perhaps, the protocol does not agree.

[...]
>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.

wait. A spammer can trivially fix his HELO but a bona fide server
cannot? I know what you mean, but a spammer, and in particular a
spambot, will have a hard time (although it's possible to do it)
finding the correct value for the HELO when using a compromised
Windows box, and that is an indication to me that at the other end
there is not a human that has correctly configured a machine, so spam
flags on and possible rejection. Let's not consider dynamic
addresses, as whoever runs a mailserver on a dynamic allocation
should use a smarthost or pay for a static allocation.
Note that the validity of <helo arg> --> IP address (ignore the
reverse) gives me other clues via the whois record for the declared
domain.

Real client machines (MUA) instead always talk to a server that
accepts them either by IP or by AUTH (or equivalent mechanism). For
them the private IP address or machine name makes much more sense,
and the HELO criteria have no place in the relay process.

I feel so sorry having contributed to this thread...

Giuliano