Re: [exim] Delaying messages for 5 minutes?

Marc Perkel wrote:
> 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.

As to 'I'd know whether..' hopefully you don't propose a scenario
wherein the Mark One Perkel Eyeball has to control the branching for a
computer? And you'll sleep when?

In any case .. delay *alone* may not be your best tool.

Not mentioned was simply routing all your client-base-originated //
'customer' submitting to relay/be filtered <whatever contracted for>,

EG: 'outbound' traffic ... IF/AS/WHEN a 'flood' threshold is hit..

...through *supplemental* scanning (ClamAV, Sophie, SA, & sputniks) with
arguably stricter filters - much stricter - or at least 'different' ones
- than Wide World incoming submissions.

More expensive of server resources, yes.

Thats what 'puters are FOR.

But not dependent on one pair of eyeballs being awake, on-watch,
coherent, and not distracted by other demands...

JM2CW

Bill

>
>
> 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.
>>
>>
>>
>>
>>
>>
>