Michael Peek wrote:
> Hello exim users.
>
> I have an ACL question for you guys. It's more of a policy question than
> a technical question. I would like to deny hosts whose
> $sender_helo_name/address doesn't match their $sender_host_name/address.
> I started off with the following in my acl_smtp_mail ACL:
>
<SNIP>
> This is probably a terrible hack job that will make more knowledegable
> gurus cringe, but it worked... sort of. This still denies some things
> like
> eagle.colostate.edu [129.82.103.90] as not being "close enough" to
> eagle.acns.colostate.edu [129.82.100.90].
>
> Before I go much farther with this (like dropping the required "closeness"
> from 24 bits to 16 bits -- all I really care about is that the remote host
> isn't obviously lying), what clever things have you guys implemented?
>
> I suppose it would be nice to be able to look up the owner of both
> addresses in whois and check to see if they're both in the same block, but
> my guess is that's darned near impossible to automate, what with whois
> being broken up and deregulated and all.
>
> Is there a rule in the SMTP protocol that says the HELO name has to match
> the remote sender's hostname/address in some way?
>
> Maybe I should just chuck it out the window?
>
> Whaddaya think sirs?
According the RFC, you're not supposed to block because of a 'bad'
HELO/EHLO. However, I think most of us would agree that there some
cases where it is useful. But I would recommend keeping it simple.
At our site we reject if the incoming HELO/EHLO is:
1) Our hostname
2) Our IP address (in the legal format [IP])
3) A bare IP
If the HELO/EHLO cannot be verified, we do a delay of 20 secs in the
connect and helo phases. These delays catch a lot of spambots.
This has been very effective and has had zero false positives from the
Internet. You may have issues with local, trusted email clients though,
but you can make exceptions for those hosts pretty easily.
I hope this helps,
M
--
Michael F. Sprague | mfs@???
http://www.saneinc.net | use STD::disclaimer;
System and Network Engineering (SaNE), Inc
