I do something like this to slow down our developers.
This is a send throttle based on the recipient (our devs love to send 10,000 emails to the same person for testing), but it would be trivial to change to the sender
rename /var/qmail/bin/qmail-remote to /var/qmail/bin/qmail-remote.orig and make this shell script /var/qmail/bin/qmail-remote
plus you'll need to create a '/var/qmail/sendthrottle' dir
#!/bin/bash
#
STAT="/usr/bin/stat -c%Z"
TOUCH="/bin/touch"
SENDTHROTTLE="/var/qmail/sendthrottle"
DKREMOTE="/var/qmail/bin/qmail-remote.orig"
THROTTLE=6
NOW=`/bin/date +%s`
ROUTETO=$1
SENDERDOMAIN=${2##*@}
SENDERLHS=${2%%@*}
RECIPDOMAIN=${3##*@}
RECIPLHS=${3%%@*}
shift
shift
#send throttle
LASTSEND=0
if [ -f $SENDTHROTTLE/$RECIPLHS@$RECIPDOMAIN ]; then
LASTSEND=`$STAT $SENDTHROTTLE/$RECIPLHS@$RECIPDOMAIN`
fi
$TOUCH $SENDTHROTTLE/$RECIPLHS@$RECIPDOMAIN
if [ $((LASTSEND+THROTTLE)) -gt $NOW ]; then
sleep $((RANDOM % (4*THROTTLE)))
echo -n -e "s\000ZOutbound Throttle $LASTSEND $NOW"
exit
fi
exec "$DKREMOTE" "$ROUTETO" "${SENDERLHS}@${SENDERDOMAIN}" "$@"
Scott Brynen
direct +1.604.638.9804 mobile +1.778.788.0543
web visioncritical.com<
http://www.visioncritical.com/>
From: Mark Jackson [mailto:mark@verndalesystems.com]
Sent: Tuesday, 27 May, 2014 1:11 PM
To: qmail@list.cr.yp.to
Subject: Re: rate-limit relay clients
Hi All,
I have the same problem. I ended up with 39,000 messages queued, which caused Plesk a few problems!
I've only a few clients using my server and they don't send many e-mails so I run the code below as a background task. I'd be grateful if anyone has any better ideas or can point out any areas for improvement. (I doubt I'd get the warning e-mails if my server was flooded, but at least the mailer should stop.) Combining this with Josh's sleep() should be quite effective.
#!/bin/bash
V_PID_FILE=/tmp/`basename $0`.pid
V_TODAY=`date +"%y%m%d%H%M%S"`
V_QUEUE_SIZE_FILE=/var/log/qmail_queue_size.log
V_QMAIL_BIN=/var/qmail/bin
V_MAIL_TO=<your e-mail address here>
V_SIZE_WARN=10
V_SIZE_LIMIT=20
V_RUN=true
# Param check
if [ $# -ne 0 ] ; then
echo -e "\nERROR - Too many parameters supplied\n"
echo -e "Usage:\n"
echo -e " `basename $0` \n"
exit 1;
fi;
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": `basename $0` started.\n"
echo $$ > $V_PID_FILE
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Pid $$ written to pid file '$V_PID_FILE'\n"
trap "V_RUN=false" SIGHUP SIGINT SIGTERM
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Signal trap set for SIGHUP SIGINT SIGTERM\n"
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Queue size stats file is '$V_QUEUE_SIZE_FILE'\n"
while $V_RUN; do
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Checking mail queue size...\n"
V_QUEUE_ENTRIES=`$V_QMAIL_BIN/qmail-qstat | awk 'BEGIN {FS=" "} /messages in queue:/ {print $4}'`
echo `date +"%d/%m/%Y %H:%M:%S"` $V_QUEUE_ENTRIES >> $V_QUEUE_SIZE_FILE
# Check if queue size is above warning level
if [ $V_QUEUE_ENTRIES -gt $V_SIZE_WARN ] ; then
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Queue entry count > queue size warning threshold\n"
touch /tmp/message.txt
echo -e `date +"%d/%m/%Y %H:%M:%S"` "WARNING - QMAIL MESSAGE QUEUE REACHED $V_QUEUE_ENTRIES MESSAGES\n\n" > /tmp/message.txt
/usr/bin/mail -s "WARNING - QMAIL MESSAGE QUEUE EXCEEDED $V_SIZE_WARN MESSAGES" "$V_MAIL_TO" < /tmp/message.txt
rm /tmp/message.txt
fi
if [ $V_QUEUE_ENTRIES -gt $V_SIZE_LIMIT ] ; then
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Queue entry count > queue size limit threshold\n"
touch /tmp/message.txt
echo -e `date +"%d/%m/%Y %H:%M:%S"` "ERROR - QMAIL MESSAGE QUEUE REACHED $V_QUEUE_ENTRIES MESSAGES - MAIL SERVER SHUT DOWN\n\n" > /tmp/message.txt
/usr/bin/mail -s "ERROR - QMAIL MESSAGE QUEUE EXCEEDED $V_SIZE_LIMIT MESSAGES - MAIL SERVER SHUT DOWN" "$V_MAIL_TO" < /tmp/message.txt
rm /tmp/message.txt
sleep 2
/usr/sbin/service qmail stop
V_RUN=false
fi
sleep 15
done
echo -e `date +"%d/%m/%Y %H:%M:%S"` ": Monitoring finished.\n\n"
On 27/05/2014 20:09, Joshua Megerman wrote:
Hi All,
I need some insight on fighting against the problem of "stolen passwords".
I run a "standard" netqmail server using the qmail-smtp-auth patch with
vpopmail vchkpw which worked fairly well the last years. I get more and
more trouble these days with stolen passwords, used to deliver tons of
spam to my server to be relayed to external users.
Today, I had a single client delivering about 2500 mails within a minute
before my queue stats detected it. My best idea is to rate-limit a user
to not send more than X mails within a period of time and perhaps even
block the user after a certain number of mails. Any ideas/plugins on how
to achieve that?
Any further ideas are welcome.
I don't have any immediate suggestions other than to put an increasing
sleep() call between completion of receipt of an email and accepting the
next one, but that doesn't help for emails with multiple recipients.
Although an increasing sleep() call between recipients after a certain
number might work too, assuming it won't cause problems for legitimate
mails.
I too have this happen to me on occasion, usually when I'm unable to even
find out about it for a day or two :( If you come up with a solution I'd
be very interested to see it.
Thanks,
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
qmail@honorablemenschen.com<mailto:qmail@honorablemenschen.com>
--
________________________________
Verndale Systems Ltd Reg Office: 2a Grove Parade, Buxton, High Peak SK17 6AJ. Company No. 2376672 All Correspondence To: 71 High Street, Fareham PO16 7BB.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be assured to be secure or correct as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. (c) 2005 Verndale Systems Ltd. All rights reserved.