> Date: Wed, 5 Dec 2001 15:46:31 +0000
> From: Drav Sloan <exim-users@???>
> To: Matthew Byng-Maddick <exim@???>
> Cc: exim-users@???
> Subject: Re: [Exim] Re: Request for anti-spam feature in exim4
>
> Matthew Byng-Maddick wrote:
> > Right. In which case you can run continual relay probes, rather than every
> > time they connect. And accepting the probes can be part of your AUP.
>
> !!! Are you mad? :) We have _alot_ of IPs (I work for a large UK ISP).
> I would more inclined to see this as intruding on the customer, connecting
> to all your customers is something I'm not willing to contemplate.
>
> Where as dealing with hosts *as they connect to you* seems fair, they
> are using your service your checking that as part of there AUP they
> are not operating Open mail relays.
My inclination (and we just might set this up in the Netherlands when
we update our T&Cs) would be:
1) we already have a /etc/blocked.nets file where we put open relays
when we find them. We would keep this. Exim has:
host_accept_relay = "! /usr/exim/cf/blocked.nets : \
/usr/exim/cf/netblocks"
2) run a database 'relay-tests' with key = customer IP, data = last
tested timestamp and status = OK/BLOCK/UNKNOWN
For each incoming mail from the customer, exim queries the database
for the customer IP. If they are not found, the mail is
accepted. If they are found and the status is OK or UNKNOWN, the mail is
accepted. If they are found and the status is BLOCK, the get a 5xx
error.
Run a separate process tailing mainlog and watching for the '<=' lines
and extracting the IP. This process looks up in the same database
'relay-tests' as exim is using.
If the host isn't present in the
database or if the last tested timestamp is old enough (1 or 2 weeks),
the status is set to UNKNOWN and a relay test email is sent to the
customer and set the last tested timestamp to the current time. The
mail is sent both to from a special user which processes incoming mail
and bounce messages. The message includes the host IP, the time and an
MD5 signature so that it's not susceptible to forged messages.
If the status is UNKNOWN and the last tested timestamp is > say 48 hours,
we assume they simply drop relay attempts rather than bounce, so we
set the status to OK. If they really are an open relay but take more
than 48 hours to turn it around, we'll deal with that by adding them
manually to blocked.nets when we learn of it.
If the we get a bounce message from a test, we mark the customer
status OK.
The special user address processes incoming mail (procmail):
If we get our relay test back, we mark the status as BLOCK and add
them to blocked nets. We also send an email to
postmaster@??? CCed our abuse department informing them
that they've been blocked and why.
The thinking is that blocked.nets is the least resource intensive for
customers with open relays. But an untested customer with an open
relay will get past this and could be being used for sending thousands
of SPAM emails in one session. Running a relay test which the customer
fails will update the database and will cut them off in mid-session.
The blocked.nets file is useful to our abuse and support people when
they get calls about being unable to send mail - the problem is easily
identified.
It also, eventually, catches people who manage to collect mail with
POP3 and still run an open relay (we just had a customer who collected
all their mail with POP3, then remailed anything where the message To
or CC wasn't their own domain. Sigh).
I think this addresses all the requirements, without embedding the
relay testing in exim (where it doesn't belong). It's a totally
separate process and can be tuned to meet requirements without
touching exim or its configuration.
We'll still end up in ORBZ every once in a while, but it would reduce
the occurrence greatly.
--
Jim Segrave jes@???
