On 02/16/2014 09:27 AM, Wicus Roets wrote:
Thanks Eric.Steps I took upon noticing: 1.) qmailctl stop 2.)qmHandle -S"YOUR BLAH BLAH..." 3.) Reviewed bounce messages and deleted them with qmHandle upon review qmail-qstat qmail-qread qmHandle -mxxx quick check on mail message as listed with qmail-qread qmHandle -dxxx deletes relevant message 4.) Changed user's password 5.) qmailctl start
I'd do #4 first, but given that qmail is stopped I suppose it doesn't really matter.
It's been under control for the last 6 hours ...
Crossing fingers...
Exactly the same scenario played out on Thursday.
Hmmm. Makes one wonder how PW was compromised. I haven't actually heard of such a thing, but it wouldn't be impossible for some malware to send credentials to a spammer somewhere. If this happens again for the same user's account, I'd keep their ability to submit disabled until they've cleaned their computer of malware (or preferrably obtained a clean computer). Don't forget to change that password once again after they've got their computer cleaned up.
I'm pondering a script or option to recompile, whereby a specific user's account will be disabled (be it via vmoduser) when "sender_was_rejected" or related messages is received from an external mail server, rather than blocking the static public IP of the entire box.
Keep in mind, the blocking of your static public IP address is something that you don't have direct control of. IOW, QMT isn't doing that blocking.
The problem here is that account credentials are sometimes compromised. Having things set up so passwords are never sent in clear text is something that should always be done. However, this problem will always be present to some extent, as there is always the human factor. Bottom line, passwords will occasionally fall into the hands of spammers.
I'm convinced that the best solution to this problem is to have a throttle on qmail-remote which limits the rate at which emails are sent. This would likely keep QMT's IP from being blacklisted, as spam would be queued up, but would not flood any recipients. It'd be relatively easy to detect when this happens (queue has a lot of messages over a period of time), and the offending account could have submission rights suspended automatically. It'd also be relatively easy to script a process which cleans the queue before all the messages (eventually) are sent out.
I've written some specs for such a feature, but haven't begun writing it yet. If some of you would like to sponsor work on this, it could be developed in short order. If anyone's interested in sponsoring this development so that it happens sooner than later, please contact me off list and we'll see what we can do.
Though I can help myself quite well around a console, scripting at present is slightly out of my reach ...
Your help is none the less appreciated. Thanks Wicus. -- -Eric 'shubes' --------------------------------------------------------------------- To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
