Back to Community Threads
5
SMTP service detect when password is changed and drop connections from that account
Idea shared by Dave Lerner - 12/11/2014 at 7:57 PM
Proposed
Suggestion for future versions of SmarterMail...
 
When user account gets hacked, we of course detect that with various abuse detection rules, and then change the password. The problem is that in a distributed form of this attack (the usual vector), dozens, maybe hundreds of SMTP connections are opened with that user's credentials...all of which are actively sending spam. The suggestion I would propose is that, like the RBL rules that detect a change and don't require a server restart, the SMTP process would behave the same way.
 
Currently, we have to stop and start the SMTP process to drop all open SMTP connections opened by the hacked account. It would be a great feature if the password change could be detected, and maybe via tick box, all open SMTP connections for the affected account be dropped.

13 Replies

Reply to Thread
0
Employee Replied
12/12/2014 at 11:08 AM
Employee Post
Currently, in SM 13, you can set specify the maximum number of messages per SMTP session.  Setting this option would effectively accomplish this.
0
Yeah, I know this...but the problem is some clients, when they hit that limit, do not automatically log in...and this creates user confusion...and resulting phone calls.
0
BTW, I think I will try this option again, maybe with a higher threshold it won't cause so many problems. Thanks!
0
Employee Replied
12/12/2014 at 11:57 AM
Employee Post
I'm not clear what you mean by "automatically log in?" Whenever the number of messages sent exceeds the specified max messages per session, the session closes and the SM server responds with a 421. Starting up another SMTP would require proper user authentication with your new user password.
0
Employee Replied
12/12/2014 at 11:58 AM
Employee Post
Let me know if setting a higher threshold works for you.
0
The main thing to take from this thread is that user logins should not be cached by Smartermail. Even when I change an AD user password I expect outlook to start complaining. However something is caching it. This has been discussed before and I thought it was eventually going to happen?
0
when a session is dropped, when max message # is send, then smtp client has to log in again. That cannot be cached. When pass is changed the authentication will fail, because that's a new session. imho
0
Would like fact here instead of opinion, is this really how it works?
0
Employee Replied
12/15/2014 at 8:02 AM
Employee Post
Richard Frank is correct. After the specified max number of messages is sent over SMTP, the session is disconnected and the SMTP client must reestablish a connection against the new credentials.
0
OK although that may address the OP... It does nothing for my situation.
0
Employee Replied
12/16/2014 at 9:28 AM
Employee Post
Steve, there is a token that is established when we first authenticate an AD user. This is similar in effect to caching. This token is valid for 10 mins before SM polls AD again for credentials. There is no way for AD to push to SM that an user's credentials have changed. There would be a significant performance hit if SM had to poll AD for valid credentials each transaction.
0
OK fair enough, so it's just a 10 minute delay. Sounds reasonable. Thanks!
0
Thanks, Robert...after a few new break-ins, and after playing with the threshold settings, we are still not seeing this setting as effective. We first notice an attack in progress (password compromised) and spam is going out, however, if the spammer has an accurate mailing list, with few (if any) bounces, the rule is never triggered. We did this recently...saw an obvious compromise and spam going out, changed the user password, and spam continued to pour out unmitigated. It was not until we stopped and started the SMTP process did it abate. That, in my opinion, is a huge impact on usability and so I'd still vote for an automatic dropping of sessions upon password change. As for "automatically log in" ...I mean the "auto" login that happens due to your credentials being saved in their email client. Some clients establish an SMTP session and assume its kept open, and if you recycle the SMTP process (thus dropping the sessions) the client software does not behave as you'd expect...instead of just silently logging in it just either hangs. This is not a problem with smartermail, per-se, I'm just making the observation.
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

How to Setup Microsoft 365 (Office) Accounts in SmarterTrack Using OAuthSmarterTrack > Installation and Configuration
Set up Autodiscover for SmarterMailSmarterMail > Installation and Configuration
Migrate an Account From Another Service into SmarterMailSmarterMail > Domain/User Configuration and Management
Integrating Google Apps with SmarterMailSmarterMail > Domain/User Configuration and Management
Configure an EAS Account in Outlook on AndroidSmarterMail > Desktop and Mobile Synchronization