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