Dear all,
An anti-spam trick was suggested to me a few weeks ago by a colleague in
our university. The idea is that we add longish delays into the smtp
conversation if we suspect that the sender is a spammer. i.e. if the
sender is on an RBL list we add an acl like:
accept dnslists = rbl-plus.mail-abuse.ja.net
delay = 1m
My colleague has reported that this trick is successful at reducing the
amount of spam he sees being delivered into his department.
However, I am concerned that my process tables will fill up with RBL'ed
hosts connecting to my server and filling up my (smtp_accept_max)
connections. So, I'd like to defer RBL'ed hosts at a lower limit (to get
rid of their connections). A one line patch makes the number of
connections available in the ACLs. Note patch is against exim-4.14 (or
maybe 4-20):
--- a/src/expand.c 2003-03-11 12:20:20.000000000 +0000
+++ b/src/expand.c 2004-01-16 23:01:27.000000000 +0000
@@ -292,6 +292,7 @@
{ "sender_ident", vtype_stringptr, &sender_ident },
{ "sender_rcvhost", vtype_stringptr, &sender_rcvhost },
{ "smtp_command_argument", vtype_stringptr, &smtp_command_argument },
+ { "smtp_accept_count", vtype_int, &smtp_accept_count },
{ "sn0", vtype_filter_int, &filter_sn[0] },
{ "sn1", vtype_filter_int, &filter_sn[1] },
{ "sn2", vtype_filter_int, &filter_sn[2] },
Then use a condition in the ACLs to reserver some connections for non
RBLed hosts:
defer message = Too many connections for RBL listed host. Try
later.
condition = ${if and { gt {$smtp_accept_count}{50} }
{ eq {$acl_c0}{spam} }
{yes}{no} }
Note that in our configure file $acl_c0 is set to spam if the submitter
is listed on our favourite RBLs). We have smtp_accept_max=90 so this
setup reserves a decent number of connections for non-RBLed hosts.
Also note that smtp_accept_reserve is used to list our organisations
internal hosts... so I don't want to use it for this reason.
Two questions:
1. What to people think about this delay trick?
2. What are the chances of getting this patch included in a future exim
release?
Cheers,
Martin.
--
-- Dr MDT Evans, Computing Services, Queen Mary, University of London
