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.
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
