On 6/9/06, list1 <list1@???> 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? Also, the 4.6x
spec says helo_verify_hosts is obsolete.
Out of the loop...this is what I get for not touching my config file for a year.
Sam
