Here is a small script that monitors queue size and send an email in case it grows over certain limit: ********************** #/bin/sh email=m...@domain Max_Size=15 cola=`tail -50 /var/log/qmail/send/current | grep status | tail -1 | cut -d ' ' -f 6 | cut -d '/' -f 1` if test $cola -gt $Max_Size then /opt/qmailtoaster-plus/bin/qmqtool -l > /tmp/cola_saliente cat /tmp/cola_saliente | mail -s"COLA SALIENTE CON $cola MENSAJES" $Email fi **********************
I'm using it in 2 servers and it permits to detect when an abused account is used to send spam. Hope it helps. Salutti, Natalio. On Fri, Oct 1, 2010 at 4:04 PM, Eric Shubert <e...@shubes.net> wrote: > Tonix (Antonio Nati) wrote: > >> Il 01/10/2010 20:32, Eric Shubert ha scritto: >> >>> Tonix (Antonio Nati) wrote: >>> >>>> Il 01/10/2010 18:24, Eric Shubert ha scritto: >>>> >>>>> David wrote: >>>>> >>>>>> On 10/01/2010 10:18 AM, Jake Vickers wrote: >>>>>> >>>>>>> On 10/01/2010 10:44 AM, David wrote: >>>>>>> >>>>>>>> How can a limit be set on a single account or all accounts in a >>>>>>>> domain to limit the number of emails that can be sent in certain time >>>>>>>> frame? >>>>>>>> This may have been covered already but I am behind a little on >>>>>>>> this. >>>>>>>> --Dave >>>>>>>> >>>>>>> >>>>>>> You can only really limit it on a server level with >>>>>>> concurrencyremote. >>>>>>> What are you trying to accomplish? >>>>>>> >>>>>>> This spawned from a another list I was working on talking about >>>>>> security on large networks. >>>>>> >>>>>> I did have 2 accounts get compromised for weak passwords. I had over >>>>>> 50,000 emails go out in 2 days and blacklisting me in few places. >>>>>> I can usually resolve this quickly but I need a watchdog to either >>>>>> alter me or limit my server from sending so much mail out at one time. >>>>>> Which >>>>>> can raise red flags all over the place with RBLs and other block lists. >>>>>> >>>>>> --Dave >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------------------- >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> That's indeed an interesting problem. I really like the way that >>>>> gmane.org handles it. >>>>> >>>>> gmane.org handles the list submission side of things (as opposed to >>>>> the reading/delivery side) by throttling the frequency of sending, per >>>>> user. >>>>> It will only send out one message per user every 5 minutes. If there are >>>>> more messages than that, they remain in the queue. It accomplishes this by >>>>> processing the send queue every 5 minutes, and processing only one message >>>>> per sender. >>>>> >>>>> Perhaps qmail-send could (be modified to) do something similar for >>>>> remote deliveries (I don't see a point in doing this for messages going to >>>>> qmail-local). Any developers out there who would like to look into this? >>>>> >>>>> >>>> This is one feature I planned already to put inside chkuser, limiting >>>> acceptance (for authenticated users) to both a user limit and a domain >>>> limit. >>>> I feel two basic limits should be placed both for domain and single >>>> user: daily threshold and montly threshold. limits like 500 daily and 10000 >>>> montly for user are very large for single user and useless for spammers. >>>> But, honestly, I've no time to implement it in short period. >>>> >>>> Regards, >>>> >>>> Tonino >>>> >>>> >>> While this approach might be an attractive feature for ISPs, I don't >>> think it's the best solution for the problem of compromised passwords. >>> >>> Messages should still be allowed to be queued, but there needs to be a >>> throttle/governor put on the rate at which they're sent/delivered (not >>> submitted). The limit should be something along the line of one message >>> every so many seconds, not so many messages per units of time. There should >>> be user, domain, and host values, in that order of precedence. The default >>> would be not to throttle, which is the present behavior. I think this would >>> be ideal. >>> >>> In order to implement such a feature, the parameters for host, domain, >>> and users would need to be stored somewhere (MySQL, or filesystem in the >>> traditional qmail fashion). In addition, there would need to be a timestamp >>> stored for each account (same storage options). The qmail-send program would >>> need to access the 3 parameters, and each account's timestamp of the last >>> message sent. If the alloted time has not elapsed since the last message was >>> sent from a given account, then all messages submitted from the same account >>> would be bypassed, and left in the queue for processing later. >>> >>> The qmail-send program would need to identify the account name of the >>> submitter, which appears to be in the first Received header added to the >>> message (appears as the last Received header in the file). The user/domain >>> throttle values could only be applied to messages that were submitted with >>> authentication. The host value would be used for unauthenticated >>> submissions. >>> >>> I think this be a worthwhile enhancement to the qmail-send program. It'd >>> be great if we could find a few folks who would sponsor its development. >>> >>> >> There are too many sides to examine. >> > > I have a pretty clear picture of what I have in mind. Perhaps I haven't > communicated it well, or am not considering something. > > Can you expound a bit? > > > I'd prefer to stop the user is he/she making pop/smtp from too many >> different IPs, unless he/she declares to be a roaming user... in this case, >> limits to acceptance are enought. >> > > I don't see where that would do anything about compromised passwords. > I also don't see a point in somehow keeping track of roaming users. > > -- > -Eric 'shubes' > > > > > --------------------------------------------------------------------------------- > Qmailtoaster is sponsored by Vickers Consulting Group ( > www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > > --------------------------------------------------------------------------------- > Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > >
