Sam Michaels wrote:
> On 6/9/06, list1 <[EMAIL PROTECTED]> wrote:
>
>>I'd like to reject some spam based on HELO, but they are always changing and
>>i't difficult to set up a regex match.
>
>
> I've had a lot of success using something posted to this list a while back.
>
> Enable verification in the ACLs
> helo_try_verify_hosts = *
>
> ...in the HELO ACL...
>
> #You can't use an IP:
> deny
> message = ...
> log_message = ...
> condition = ${if isip {$sender_helo_name}{true}{false}}
>
>
> #The name should not resolve to us:
> deny
> message = ...
> log_message = ...
> condition = ${if eq {${lookup dnsdb{a=$sender_helo_name} {$value}}} \
> {$interface_address} \
> {true}{false}}
>
> #And of course...
> warn
> !verify = helo
> log_message = ...
>
> And now to hijack the thread :)
>
> It seems redundant to me...doesn't setting helo_try_verify_hosts
> already check both of those conditions? And if we're going to be
> rejecting it anyway, would it make more sense to use
> helo_verify_hosts? Doesn't the RFCs use a big capitalized "MUST NOT"
> when talking about rejecting based on the HELO/EHLO?
Yes BUT....
Take the example of those folks who have chosen to register a
domain.tld with NetWork Solutions (sic) and use NetSol's MX:
NetSol - or third-party contractor(s) - use a 'cluster' of MX,
separating inbound and outbound. Reasonable for such a
very-high-volume service provider with a huge number of domains.
However - the IP's from whence they send, and the HELO's they
utilize, either do not resolve to a host, or are a mismatch
where they can be resolved - even so far as to resolve to
different domain *and* tld than those they claim in the HELO.
All easily corrected with a few DNS entries, but NetSol do not
seem to care - they do not have to.
Unfortunately, the combination of an IP that does not resolve,
and an apparently forged HELO (it is in the prefix.domain.tld
format, not just 'snoopy'), are also characteristic of Zombie
farms, and we would like to take that combination as yet-another
reason to reject at smtp time.
Our 'solution' is to assign 'points' in acl variables, look for
further failings, then test the accumulation against
user-specific thresholds. We also 'whitelist' for those
customers who (also) use NetSol, or their regular correspondents.
So - in our case, not rejecting on HELO/EHLO chaos *only*, but
still making use of yet-another 'cheap' test to help ID Zombies.
> Also, the 4.6x
> spec says helo_verify_hosts is obsolete.
>
As any of us past 60 might say, 'obsolete doesn't mean useless'.
> Out of the loop...this is what I get for not touching my config file for a
> year.
>
> Sam
>
BTDT,GTTS.
The older the violin....
;-)
Bill Hacker
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
