Thanks Ben,
This might be what I'm looking for. I'll have to dig up the docs about
what controls when the queue is processed. I might look into 20 minutes
as well. I just used 5 minutes as an example.
I also though of doing a piping trick. Haven't tries it your but was
thinging something like this:
|delay|exim -bS
What delay is a shell script:
#!/bin/bash
sleep 300
cat
The idea being that when the message came around the second time I'd
know whether to pass it or discard it.
On 4/10/2011 4:37 PM, Ben Allen wrote:
> 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.
>
>
>
>
>
>
