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

Top Page
Delete this message
Reply to this message
Author: Brian Candler
Date:  
To: Giuliano Gavazzi
CC: exim
Subject: Re: [exim] Exim server behind NAT router (and HELO)
On Wed, Mar 23, 2005 at 03:52:29PM +0100, Giuliano Gavazzi wrote:
> >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?


Yes.

Of course it depends on what you mean by "fix". If the EHLO name is really a
locally-significant string to be inserted into logs at the remote end, as I
believe it is, then there is nothing to fix. But if the significance of the
EHLO name is "some string which must match the reverse IP address that the
connection appears to come from", then any device sending via a layer 3 or 4
proxy will not know it.

It's like putting an arbitary high-jump in front of the sender:

         "Stop! Who approacheth the Bridge of Death
          must answer me these questions three,
          ere the other side he see."


The assertion that a bona-fide E-mail user will be able to pass these checks
and a spammer will not, seems bizarre to me. If you want a more reliable
check for spammers, then you can use the Evil Bit in the IP header (RFC
3514)

> 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


Are you saying that Windows boxes in general don't have a DNS resolver? It's
pretty easy if you ask me.

Maybe it's true that today some reasonable percentage of spam has an EHLO
string which doesn't match its reverse DNS. But the more systems which
enforce this arbitary constraint, the more that spammers will update their
code to adjust. At that point, all you've succeeded in doing is reducing the
overall reliability of E-mail, and you will be receiving just as much spam
as before.

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


I think you're saying that non-spammers are better at configuring machines
than spammers. I disagree: for spammers, E-mail is their business. They know
all about spam filters, and how to get around them. But against the few
hundred big-league spammers in the world, there are millions of legitimate
Internet users, companies, schools, universities etc. who run their own
mailservers but don't take RFCs to bed with them to read.

> Note that the validity of <helo arg> --> IP address (ignore the
> reverse) gives me other clues via the whois record for the declared
> domain.


What additional clues do you get, which you do not get from the source IP
address alone?

Brian.