Szerző: Ben Dátum: Címzett: exim-users Tárgy: Re: [exim] Spam control via ratelimiting.
On Friday, December 16, 2011 06:48:24 pm Steve Devine wrote: > Enough complaining, here is what I and my Director would like to be able
> to do.
>
> -- Identify likely spammers via ratelimiting
> -- Freeze these messages using control=freeze
> -- Allow them to be delivered very slowly. And this is where it gets
> ugly - I could just let these messages sit in the queue ( I don't have
The configuration we're using does this pretty well. In essence we've got 2
levels of ratelimiting (keyed off of the envelope sender address). The first
one is quite low (defaults to about 30 per hour - an indivual can send
messages to 30 email addresses per hour without any impact at all). Above 30,
and every message we recieve gets "queueonly" control applied to it (to
prevent immediate delivery). There's also an SQL database which is updated
with a "QUEUE" status (see later).
As far as the client is concerned all messages have been accepted, but for the
moment they're not going anywhere.
We then have a system filter which checks the sender's status in the database,
and if it's set to "QUEUE", it checks the time the message has been waiting
($message_age variable) and if it's less than a set amount (20 minutes seems
to work well), delivery is deferred. If it's older than 20 minutes then
delivery proceeds as normal. We run the queue at 5 minute intervals.
If a sender continues to blast messages at us they eventually reach the "high"
limit (say 300-400 within an hour). At this point they get a "FREEZE" entry in
the database, and when the system filter runs it freezes the message outright.
No deliveries happen, and it's up to manual intervention to either unfreeze or
delete (with the subsequent account disabling etc).
Also "FREEZE" beats "QUEUE", so any initial messages currently sat on the
queue are automatically frozen too during subsequent trips through the system
filter.
In the year this's been running, we've had a total of 3 complaints about
"delays" in sending email. People for the most part expect that if they're
sending messages to a bunch of people it won't be absolutely instantaneous (or
they don't care). Also, it's per sender configurable (i.e. if geoff@???
consistently sends batches of emails to 500 people, we just set his "FREEZE"
limit a bit higher).
Spammers will usually hit the "QUEUE" limit in the first message. They then
continue to fire them out as quickly as possible, so for the most part we
catch the spam run before it even happens. Even if they don't, they don't get
many messages out before we get them. Compromised accounts used to send around
500,000 spams a month from our servers. This last year it's been cut to 2000
in total (and most of that was a single config error on our part).
The majority of "legit" big senders are only delayed for around 30 minutes max
and we either point them at our list server or increase their limit.
