Hi all,
I'd strongly recommend greylisting. From experience I can say that
most concerns about delays are easily dealt with. I wrote a greylisting
system for exim back in 2003. We used it to filter all e-mail to
Aberystwyth University from 2003 until the powers-that-be decided to
outsource to Microsoft last year. It caused almost no problems over
those 10 years.
You can get around most delivery delay issues by having a whitelist of legit
hosts that send lots of mail to your machine and a whitelist of
sender/recipient pairs - you make outgoing mail create the whitelist entry
and you can then accept inbound mail without delaying it.
My greylisting implementation managed both the host and
sender/recipient whitelists automatically. It used MySQL as the backend
because we were running a cluster of several mail servers and I wanted
the greylist to be common to all. It should be quite easy to change it
to use SQLite, for example.
Here's a link:
http://users.aber.ac.uk/auj/spam/
Spamassassin should really be your last resort when trying to deal with high
throughput. It can take several seconds for a message to pass through
the filters, so knocking off the worst cases nice and early is
worthwhile.
Here's a bit of sneaky stuff to put in your "acl_smtp_connect" ACL.
# ACL for initial connects.
# Let's try and deter them here.
check_connect:
# Internal addresses.
accept hosts = +relay_hosts
# Addresses in one of these DNSBLs get delayed for 60 seconds.
accept dnslists = sbl.spamhaus.org
logwrite = Delayed $sender_host_address - dnsbl $dnslist_domain
delay = 60s
# Addresses without a reverse DNS get delayed for 10 seconds.
accept condition = ${if def:sender_host_name {no}{yes}}
logwrite = Delayed $sender_host_address - missing reverse DNS
delay = 10s
# Everyone else gets 2 seconds to screw them up if they're
# trying to "pump and dump"
accept delay = 2s
Basically, every inbound connection gets delayed for 2 seconds. If they're
in sbl.spamhaus.org the connection gets delayed for 60 extra seconds. If
they have a missing reverse DNS they get 10 seconds added. This is enough
to cause a lot of spamware to give up on you, and the RFCs suggest that
sending software should be willing to wait up to 5 minutes.
The unconditional 2 seconds delay breaks spamware that tries to use
pipelined commands.
Note that nothing in the above ACL causes rejection. It just gives broken
spamware a chance to fail.
I also have an "acl_smtp_helo" which blocks people who HELO as my server
(my server being ty-penguin.org.org or mail.ty-penguin.org.uk) or who
HELO with an invalid value.
check_helo:
# MSA or SMTPS gets a free pass.
accept condition = ${if or {{eq {$interface_port}{587}}{eq {$interface_port}{465}}}}
drop condition = ${if or {\
{eq {$sender_helo_name}{[$interface_address]}}\
{eq {$sender_helo_name}{$interface_address}}\
{eq {$sender_helo_name}{ty-penguin.org.uk}}\
{eq {$sender_helo_name}{mail.ty-penguin.org.uk}}\
}{yes}{no}}
message = You're not me! Are you a spammer?
delay = 3s
drop condition = ${if or {\
{eq {$sender_helo_name}{localhost}}\
{eq {$sender_helo_name}{127.0.0.1}}\
{eq {$sender_helo_name}{[127.0.0.1]}}\
{match {$sender_helo_name}{\N^\.\N}}\
{match {$sender_helo_name}{\N\.\.\N}}\
{match {$sender_helo_name}{\N^[^\.]+$\N}}\
}{yes}{no}}
message = Invalid HELO address
delay = 3s
accept
I think it's perfectly fair to drop stuff that has a clearly invalid HELO. I
also give them a 3 second delay to slow them down a bit. In my experience,
lots of spamware sends dodgy HELO lines in the hope of fooling you into
thinking the mail is local.
Cheers,
Alun.
