Back to Community Threads
2
Disabled user with changed password - spammers are still sending emails for next 10 minutes
Question asked by Webio - 7/12/2018 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
Ron Raley Replied
7/12/2018 at 4:14 PM
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
7/13/2018 at 12:56 PM
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
7/18/2018 at 2:43 AM
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
7/18/2018 at 3:53 AM
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
Ron Raley Replied
7/18/2018 at 5:37 AM
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
7/18/2018 at 1:03 PM
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
7/18/2018 at 6:19 PM
That is a silly fix, especially for someone with a server as large as ours that takes 30+ minutes to start.
1
echoDreamz Replied
7/18/2018 at 6:20 PM
When you disable a user, SmarterMail should really check sessions (even existing ones) and kill them.
0
Matt Petty Replied
7/18/2018 at 6:56 PM
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
7/18/2018 at 6:57 PM
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
7/18/2018 at 9:46 PM
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
7/19/2018 at 4:06 AM
Sadly, given SM's history with new releases, it will likely be some time after release before v17 is stable.
0
Linda Pagillo Replied
7/19/2018 at 5:30 AM
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
7/19/2018 at 8:30 AM
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
7/19/2018 at 8:37 AM
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
7/19/2018 at 9:30 AM
Yeah, we have many 10s of thousands of users to process and load. This is where (hopefully) SM 17 makes it all better.
0
echoDreamz Replied
7/19/2018 at 9:31 AM
Matt, does this also apply to API calls?
0
echoDreamz Replied
7/19/2018 at 9:33 AM
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.
0
echoDreamz Replied
7/19/2018 at 11:22 AM
There is no need check constantly, this is the point of events etc.
0
Webio Replied
7/19/2018 at 11:26 AM
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
7/19/2018 at 11:26 AM
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
7/19/2018 at 1:56 PM
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
7/19/2018 at 1:59 PM
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
7/19/2018 at 2:00 PM
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
7/19/2018 at 2:07 PM
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
7/19/2018 at 11:26 PM
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
7/20/2018 at 4:48 PM
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.
0
Matt Petty Replied
7/23/2018 at 10:00 AM
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
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

Recommended SPAM SettingsSmarterMail > Antispam and Antivirus
Set up Autodiscover for SmarterMailSmarterMail > Installation and Configuration
Deploying Rspamd For Use With SmarterMailSmarterMail > Server Configuration and Management
Find a Compromised AccountSmarterMail > Troubleshooting
How to Setup Microsoft 365 (Office) Accounts in SmarterTrack Using OAuthSmarterTrack > Installation and Configuration