Re: [exim] Delaying messages for 5 minutes?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Ben Allen
Date:  
À: exim-users
Sujet: Re: [exim] Delaying messages for 5 minutes?
On Saturday 09 April 2011 18:07:58 Marc Perkel wrote:

> So - what I'm thinking is that if I have a high rate sender I'd like to
> be able to delay delivery of the email for 5 minutes and then either
> send the email if that are determined to be sending good email - or
> discard the emailhish if they are sending spam.
>
> Just wondering if there is an easy way to tell Exim to hold email for 5
> minutes?
>


That's basically what we do to limit the effect of phished accounts. Our
method works as follows:
- Check the recipient rate of all outbound mail (i,e, PER_RCPT).
- If it's highish (say 40 recipient over 10 minutes) then the sender is
treated as suspicious. Use a "control=queue_only" to prevent immediate
delivery.
- Use a system filter to check the $message_age variable to see if it should
deliver (i.e. if the has been queueing for sufficient time).
- In the mean time, if the sender's rate continues to increase above a
higher threshold, a flag is set in a database that means "Freeze this sender's
messages". "control=freeze" is used for new messages (i.e. run during the ACL
stage). And there's a check in the system filter that'll freeze messages
that've already made it onto the queue and are waiting to be delivered.

The system has a SQlite database recording who gets queued and frozen, set up
in such a way that if a user gets themselves "frozen", none of their mail (old
or new) can get delivered until a human takes a look. If they're just in the
"suspicious" state, a reduction in rate will remove the entry altogether (mail
goes straight through as usual).

Bear in mind that 5 minutes is not (in our experience) long enough for
spammers to "hang themselves". We find that 20 minutes is more suitable. The
problem is that we found that several of our users would (with reasonable
frequency) send out messages to several hundred people at once. So we settled
on queueing at rates over 20 RCPTS per 10 minutes, and freezing at more than
500 recipients per hour. That'll be very site (and user) specific though.

It's only part of the anti spam stuff we do, but it's working well, and after
some tweaking it now effectively takes care of itself. Spammers are still
trying their luck, but they're not getting anywhere.

Hope that gives you some ideas.