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
It's been under control for the last 6 hours ...
Exactly the same scenario played out on Thursday.
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.
Though I can help myself quite well around a console, scripting at present
is slightly out of my reach ...
-----Original Message-----
From: Eric Shubert [mailto:[email protected]]
Sent: 16 February 2014 06:11 PM
To: [email protected]
Subject: [qmailtoaster] Re: Spamming via valid vpopmail account
There are bit flags associated with each user account which can be set with
the /home/vpopmail/bin/vmoduser command. There is no other (gui) way I know
of to set these flags.
# ./vmoduser
vmoduser: usage: [options] email_addr or domain (for each user in domain)
options: -v ( display the vpopmail version number )
-n ( don't rebuild the vpasswd.cdb file )
-q quota ( set quota )
-c comment (set the comment/gecos field )
-e encrypted_passwd (set the password field )
-C clear_text_passwd (set the password field ) the following
options are bit flags in the gid int field
-x ( clear all flags )
-d ( don't allow user to change password )
-p ( disable POP access )
-s ( disable SMTP AUTH access )
-w ( disable webmail [IMAP from localhost*] access )
( * full list of webmail server IPs in vchkpw.c )
-i ( disable non-webmail IMAP access )
-b ( bounce all mail )
-o ( user is not subject to domain limits )
-r ( disable roaming user/pop-before-smtp )
-a ( grant qmailadmin administrator privileges )
-S ( grant system administrator privileges - access all domains )
-E ( grant expert privileges - edit .qmail files )
-f ( disable spamassassin)
-F ( delete spam)
-m ( disable maildrop)
[The following flags aren't used directly by vpopmail but are]
[included for other programs that share the user database.]
-u ( set no dialup flag )
-0 ( set V_USER0 flag )
-1 ( set V_USER1 flag )
-2 ( set V_USER2 flag )
-3 ( set V_USER3 flag )
#
So to disable a user's ability to submit emails, #
/home/vpopmail/bin/vmoduser -s [email protected] should disable
their ability to submit.
As best I can tell, to enable/unset the flag, you'd need to clear all flags.
Let us know if you use these, and how they work. I've never used the flags
myself.
--
-Eric 'shubes'
On 02/16/2014 08:57 AM, Wicus Roets wrote:
> You are correct in your second statement, that the particular user was
> never at the referred IP. Passwords across the entire virtual domain
> has now been changed for the second time.
>
> This being the second successful spam attack, in two days, with the
> same modus operandi, has us quite concerned.
>
> As an interim option, the CHKUSER_RCPTLIMIT and CHKUSER_WRONGRCPTLIMIT
> has been set to 10 and 1 respectively.
>
> Is there any mechanism to block/disable a user's mail account in such
> a scenario than having the mail server's IP blacklisted ?
>
>
> -----Original Message-----
> From: Eric Shubert [mailto:[email protected]]
> Sent: 16 February 2014 05:35 PM
> To: [email protected]
> Subject: [qmailtoaster] Re: Spamming via valid vpopmail account
>
> It appears that either the password for "valid vpopmail account" has
> been compromised, or the computer being used by that user has some malware
in it.
>
> The address of origin (46.228.199.219) has no rDNS record:
> $ host 46.228.199.219
> Host 219.199.228.46.in-addr.arpa. not found: 3(NXDOMAIN) so that's not
> much help.
>
> If that user was legitimately at that IP address, then the user's
> computer is infected. If that's the case, they need to get rid of the
> malware on their computer.
>
> I expect it's more likely that the user was never at the
> 46.228.199.219 address. If that's the case (and probably in any case),
> you should change the password on that account. You might also advise
> the user to change the password on any other accounts which they have
> that use the same compromised password, for their own security.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
