Disabled user with changed password - spammers are still sending emails for next 10 minutes
Question asked by Webio - July 12 at 1:16 PM
Unanswered
Hello,
 
is this normal that after changing mailbox password and disabling it (I've literally saw number of emails sent in Spool summary to have higher and higher number next to red [disabled] information) spammers are sending emails for next 10 minutes until they start to have "535 Authentication failed" errors?
 
I'm using SM 15.7.6754 but this is not the first time I've encountered this problem.
 
Thanks

28 Replies

Reply to Thread
0
Ronald Raley Replied
Webio, sometimes a password change is not enough. You must kill the actual IP session to ensure they are completely disconnected.
0
Linda Pagillo Replied
Ronald is correct. You have to restart the SM service and that will kick them off.
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
Webio Replied
Shouldn't this be considered as a bug then? IMHO when mailbox is being disabled (or password changed) then all active connections should be automatically ended.
 
I can't restart SM service because of having a lot of active users and as far as I remember I didn't saw IP present in SMTP log in Current Connections section.
0
Alisha Hessle Replied
Why don't you unsubscribe them. After then you will not received the the message.
Alisha Hessle is the content marketer who formerly worked for the automotive industry. Her passion is to write on the trendy and upcoming cars and bikes in the market.
0
Ronald Raley Replied
I have seen spammers connected and the only way ever to truly 100% disconnect them is to restart SmarterMail. But your right, how do they continue to "cling"?
1
David Fisher Replied
Hi Webio,
 
  What I do is blacklist the user, add the user to the SMTP Blocking (Login as Admin, Settings -> Advanced Settings -> SMTP Blocking), and it immediately disconnects the session (Or almost immediately), and I delete the entry after a few minutes.
 
0
echoDreamz Replied
That is a silly fix, especially for someone with a server as large as ours that takes 30+ minutes to start.

Christopher

1
echoDreamz Replied
When you disable a user, SmarterMail should really check sessions (even existing ones) and kill them.

Christopher

0
Matt Petty Replied
Employee Post
SmarterMail 16 does this on disable, rename, and password change, all protocols get disconnected including the web connection they will get booted back to login page. Also, from the "Connections" area SMTP, IMAP, POP, XMPP, and ActiveSync can all be killed individually. Webmail can be killed from the "User Activity" area.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Matt Petty Replied
Employee Post
Note the password change disconnection only happens if it comes from a domain admin or system admin. Done via the user keeps them connected on webmail.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Webio Replied
Ok thanks. I'm waiting for stable v17 to be released for upgrade from current 15.x. Maybe I will consider moving to v16 since there is quite silent recently about it performance issues.
0
Paul Blank Replied
Sadly, given SM's history with new releases, it will likely be some time after release before v17 is stable.
0
Linda Pagillo Replied
I agree. Also, your SM service should not be taking 30 minutes to start. Have you spoken to ST support about this?
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
Merle Wait Replied
Well.. in defense of SM... it takes too much over-head to continually check for changes in a user's account (once the session is established) .. I promise.. you really wouldn't want that....
Having said that.  we do what David Fisher  in this thread suggests.. 
We NEVER reboot the service.. just kill their IP.
We also sometimes route their traffic - outbound.. 
 
But usually just as Mr. Fisher indicated
0
Paul Blank Replied
With all due respect, nobody would expect SM to check continually; only when a user's password is changed. Should not really be a problem for this action to trigger a clean-up process.
 
Indeed, from a security point of view, one should expect nothing less.
 
Just sayin'
 
0
echoDreamz Replied
Yeah, we have many 10s of thousands of users to process and load. This is where (hopefully) SM 17 makes it all better.

Christopher

0
echoDreamz Replied
Matt, does this also apply to API calls?

Christopher

0
echoDreamz Replied
That is the great thing about it though, you don't have to continuously check or monitor for password changes. You simply add events or calls to the methods that handle password resets. PasswordChangeRequest => Was it a Domain Admin || System Admin? => Yes? => DisconnectUserSessions.

Christopher

0
echoDreamz Replied
There is no need check constantly, this is the point of events etc.

Christopher

0
Webio Replied
The same on my end. 5k domains and 37k users is taking some time to load. I remember that I was checking startup process using ProcessMonitor and it had a lot of mailinglist.db checking. I even wrote post about it:

https://portal.smartertools.com/community/a87717/mailinglist_db-loading-during-smartermail-startup-making-startup-process-quite-long.aspx
0
Nicolas Fertig Replied
Also this would be nice if it does it when the change password request is done via the API. I'm not sure it is...
0
Matt Petty Replied
Employee Post
Unfortunately it does not. At the moment we do not store the tokens we issue to clients. As long as the token is valid in terms of expiration and validity it will be accepted. However, I've already brought up a plan on how we could avoid this by storing all tokens we issue and requiring a quick check against the list of known and valid tokens. It would allow us to remove tokens at will like when a password changes for example.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Matt Petty Replied
Employee Post
When a client connects to a protocol and as soon as we see some sort of information identifying that client-ip combo to a user email address that information gets saved into the session. That way we can have an event that comes by later on saying "remove all connections with authenticated email address X". So it doesn't require constant checking.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Matt Petty Replied
Employee Post
When a client connects to a protocol and as soon as we see some sort of information identifying that client-ip combo to a user email address that information gets saved into the session. That way we can have an event that comes by later on saying "remove all connections with authenticated email address X". So it doesn't require constant checking.

I mentioned this above but this is a similar question so I pasted it here too.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Matt Petty Replied
Employee Post
@Nicolas Fertig
If you authenticate using a domain or system admin token to perform the API call to change password, it should still do the kicking. Since as far as the server can tell, you did it as that system or domain admin. (Using the new SmarterMail 16 APIs which aren't fully documented)
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Alain Néris Replied
I had a few times the same trouble, sometimes with a blacklisting regarding the amount of SPAM mail sent. I finally killed the hacked mailbox and replaced it by an alias.

But I would like that SmarterTools would find a way to fix this problem.
0
echoDreamz Replied
So my issue still stands. When we disable a user through our control panel, they can still continuously send mail as long as their SMTP session remains active. That is our primary concern, when we disable a user (not change password), all SMTP sessions should stop immediately.

Christopher

0
Matt Petty Replied
Employee Post
You mentioned API calls which use our token system in your previous reply and you are now mentioning SMTP? SMTP gets killed, issued tokens (used for interacting with the web interface) are still active, and even these can be killed under certain cirtumstances. In the example you gave the SMTP session would be killed immediately.

EDIT: Oh I see where the confusion is. If you use the new APIs to disable a user I know for a fact the sessions are killed. However, I'm not sure if the old APIs trigger this behavior.
EDIT2: So I checked the code for UpdateUser in SM 16 (the old API) and changing the user password WOULD trigger a full-account disconnect across all protocols. It looks like disabling a user would also trigger this behavior.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Reply to Thread