RE: [exim] Q: ACL HELO name checks (This time w/ a subject l…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Herb Martin
Dátum:  
Címzett: exim-users
Tárgy: RE: [exim] Q: ACL HELO name checks (This time w/ a subject line!)

> -----Original Message-----
> From: exim-users-bounces@??? 
> [mailto:exim-users-bounces@exim.org] On Behalf Of Michael Peek
> 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:
>   # Deny if HELO does not match host
>   deny
>     condition = ${if !match{$acl_m8}{$acl_m9}{true}{false}}
>     message = Forged HELO/EHLO: You are not $sender_helo_name
>     log_message = bad HELO: Hostname/HELOname mismatch: 
> $sender_helo_name != $acl_m9


> The problem with this is that so many legitimate hosts aren't
> configured to tell me who they really are. Exim will deny
> mail from roam4321.utk.edu if they HELO as mail.utk.edu.
>
> So my next brilliant idea was to accept HELO's that are
> "close" to each other, and I defined close as being if the
> first 3 out of 4 octets of their IP addresses are the same.
> I replaced the final deny above with the
> following:


This isn't going to give you good results
no matter HOW you do it.

Too many SMTP admins think they have to
name the "Email server HELO" to match the
domain, and frequently the machine has
another FIXED name (PTR) that isn't the
same.

As some else answer, you can treat such
connections as 'suspicious' (he suggested
delaying 20 seconds). We treat them as
suspicious by driving the connection through
"greylist" checks where we temp-reject the
message on the first try and accept after
some (short) delay.

90% of such "never return" and are in fact
spam bots.

The problem is some portion of that other
10% -- some of these are even well known
big name ISPs who have no real excuse for
not naming the sending servers the same
as the domain/zone/users.

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


Greylisting. Also combining such checks (host
doesn't match helo) with in "certain reliable
blacklists", or "looks like a dynamic address",
or from certain (usually spammy) countries, etc.

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


Yes, because a company might not "own their addresses"
OR their email server might be (legitimately) located
elsewhere.

You will never be truly happy with such schemes
unless you use MULTIPLE criteria or can accept
losing GOOD mail.

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


Not really.

> Maybe I should just chuck it out the window?


Or use it to drive greylisting rather than the
simple rejection.

--
Herb Martin