3
Build 8825: Webmail login failing for all @info mailboxes
Problem reported by Bruce - 3/5/2024 at 6:06 AM
Submitted
I have a strange problem with Build 8825.

We updated earlier his morning, and everything has been running fine, but in the last 30 minutes, a problem has occurred with the webmail service with all info@ mailboxes.

Trying to log in to an info@ mailbox in the webmail service returns the error;

Username or password is incorrect.

We have tried reloading the domain and restarting SmarterMail, but this has not fixed the issue.

There are no errors in the log files, which show a successful login.

Does anyone else have this issue and know how to fix it?


25 Replies

Reply to Thread
0
Bruce Replied
And as if by magic, the problem seems to have resolved itself, and all info@ mailboxes are now working again with the webmail service.
1
Webio Replied
I've experienced similar very random issues which has been documented on ticket 0A9-2D53D316-0B20 (open). On my end problematic was biuro@... mailboxes since biuro means office here. This is probably most popular mailbox name next to kontakt@..... (contact). Every time issue occured it was auto resolved by itselt after some period of time (10-30 minutes). 
1
jordan Car Replied
Same issue here, restarting the Smarter Mail service has brought it back to life but then had similar issues with other mailboxes that also requires service restarts afterwards.
0
Webio Replied
@jordan Car - does this issue on your end also occured on the same name of mailboxes?
0
Webio Replied
So .. anyone else experienced this issue?

I've experienced it on friday and again today. This time for biuro@... mailboxes. Take a look here:


I've opened direct GUI to webmail to .net core app without IIS to check if issue will exists also there and yes it is. You can see here that username biuro@..... has valid authentication request with success true but all next requests are failing with:

Token not found in settings error
0
Ricardo Ranieri Replied
Hello friends, does anyone still have this problem? 
Here accounts with the same suffix from different domains are logged out if used simultaneously.
Thank You.
0
Bruce Replied
Yes, we still have this issue.
0
Webio Replied
@Ricardo Ranieri - logged out but can log in or logged out and can't log in for some period of time? I stil have opened ticket about this issue and issue occurs every few days and it looks exactly how I described above. One thing which I found helpful (I'm not sure if it helps for all mailboxes or just for only one) is to use Expire password function against problematic mailbox.

BUT this is only for scenario where users can't log in to their mailboxes

BUT if you are asking for scenario that users are being logged out and can log in then I might also experiencing this but it's hard to check. Recently I'm getting more and more reports that they are being logged out of their mailboxes suddenly. They don't report it but when some other issue occurs like this one from this topic they of course bring other issues too and one of them is being logged out quite often (multiple times per day) and maybe this is somehow related to this issue too.
0
Sébastien Riccio Replied
This thread is really intriguing and would explain why we have users getting randomly logged ouf of webmail They all seems to be mailboxes that have common names (info, contact, ...).

Also some times they can't log in and I suspect this is related to some IDS triggered for a mailbox username. For example I remember seeing in current active IDS blocks a block for mailbox "info" (without a domain name)... 
Might this block all users having info@ mailboxes from logging into the webmail (whatever their domain is) ?
Sébastien Riccio System & Network Admin https://swisscenter.com
0
Webio Replied
@Sébastien Riccio have you checked admin log for that? In my case when users can't log in to their mailboxes in administrative log only thing which gets logged is that user logged in successfully (screenshots above also confirm that auth request returns success but next requests are failing)
1
Bruce Replied
I have not thought to check the IDS blocks. I will need to remember to check the blocklist next time it occurs. 

It does seem to last about an hour each time it occurs, and rebooting the smartermail service doesn't fix the issue, so it would fit it as an IDS block issue.
0
J. LaDow Replied
info@* is one of the most targeted accounts on our servers.

Followed by sales@*, support@*, billing@*, admin@*

Accounts that use "single word names" like joe@, dave@ along with the above are all prohibited due to the SHEER AMOUNT of spam those accounts receive whether they're a "brand new domain and username" or not.

In the past, we have had countless issues where malicious login attempts to accounts like above completely killed any chances of actual users being able to login to their accounts because IDS/IPS was doing it's job. 

In ANY of those cases, the dictionary or "common name" accounts are only aliases, that cannot login. The actual user accounts are then required to have a two-part name usually separated by a period or hyphen. This defeats 90% of the attacks that trigger IDS logins, helps to generate log-monitors that watch for "rogue" servers attempting to login to those accounts and create firewall rules for them as needed.

NOTE:
This does NOT resolve any "token issues" as described in some posts above. This is simply a response to the potential issue that IDS/IPS is interfering. Some posters describe an IDS issue, while others describe a bug being tracked with token usage (and this will NOT solve that).




MailEnable survivor / convert --
1
Sébastien Riccio Replied
Well,

I checked our administrative logs for EmailBruteForceDetector and found this:

[2024.03.20] 00:50:16.395 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,997426 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 00:51:58.402 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9975387 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 00:52:14.313 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,9971007 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 01:24:08.409 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,9972983 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 01:26:07.730 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,997513 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 01:26:40.670 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,997522 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 01:57:53.965 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,9975733 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 02:00:12.711 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9974181 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 02:00:18.185 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,9973368 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:13:48.149 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9974281 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:15:32.435 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,9975847 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:21:01.126 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,9974775 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:47:23.586 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9975575 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:48:40.639 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,9973126 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 06:55:10.098 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,9975129 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 07:19:27.125 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9974293 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 07:23:03.238 [EmailBruteForceDetector] Added test to IDS block list. Duration: 1799,9973051 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 07:30:33.004 [EmailBruteForceDetector] Added mail to IDS block list. Duration: 1799,997317 seconds, Description: Default Brute Force by Email rule
[2024.03.20] 10:31:25.209 [EmailBruteForceDetector] Added info to IDS block list. Duration: 1799,9975803 seconds, Description: Default Brute Force by Email rule
I would not be surprised this could be somehow related...

00:50:16.256 [170.83.173.29] SMTP Attempting to login user: test@somedomain.ch
00:50:16.256 [170.83.173.29] SMTP Login failed: Domain [somedomain.ch] not found
00:50:16.256 [170.83.173.29] SMTP Login failed: That domain was not found. Double check your email address.
	Brute force attempts increased to 3 of 25 in 10 minutes.
	User brute force attempts increased to 1 of 50 in 10 minutes.
	Next clean available at 20.03.2024 00:51:07
00:50:16.392 [test] Added to IDS block list for violating rule Type: Password Brute Force by Email, Description: Default Brute Force by Email rule
Interestingly, it looks in some cases they are trying to login to users for domains that does NOT exist on our server.

But then SmarterMail still adds an IDS block for that username.. 
so what domain is it using for the IDS ban ? All domains ? and maybe therefore blocking all mailboxes with this user name ?

Sébastien Riccio System & Network Admin https://swisscenter.com
1
J. LaDow Replied
-- and then the additional question to ask is if the IDS triggers in any way, are all session tokens instantly invalidated or are current sessions preserved (and to test if "expected" matches "actual").
MailEnable survivor / convert --
0
Sébastien Riccio Replied
Good question indeed
Sébastien Riccio System & Network Admin https://swisscenter.com
0
Bruce Replied
I don't think this is the issue as SMTP, POP, and IMAP all continue working, its just the webmail stops working for all mailboxes with for example info@

Even trying to impersonate the account as the server administrator doesn't allow you to view any of the mailboxes that start with info@

If it was an IDS block the admin would still be able to impersonate the user.
0
Sébastien Riccio Replied
Well, who knows, maybe IDS blocks on mailbox usernames (without a specific domain) maybe also prevent somehow to impersonate to these ...

For now and according to the findings in the logs, I have no other track to follow to troubleshoot this one.
Sébastien Riccio System & Network Admin https://swisscenter.com
1
Webio Replied
On my end I've disabled IDS for mailbox locking because of multiple failed logins since IMHO this is crazy to punish our clients which can't log in to their accounts because of some remote source is trying to log in to their accounts don't you think?

So my two issus (unable to log in and logging out suddenly) are not related to IDS mechanism (probably).
1
Sébastien Riccio Replied
This makes sense Webio. So if it's not related to IDS, it's then still a mystery...
Sébastien Riccio System & Network Admin https://swisscenter.com
1
Sébastien Riccio Replied
The issue raise again for different customers today.

They are able to log into the webmail with their mailbox info@domain.tld.
I'm also not able to their mailbox via impersonate.

[2024.03.21] 15:32:56.862 [192.168.50.35] Webmail Attempting to login user: info@domain.tld
[2024.03.21] 15:32:56.862 [192.168.50.35] Webmail Login successful: With user info@domain.tld
This time I have IDS for mailbox name turned off ...

We have a lot of angry users here.
Sébastien Riccio System & Network Admin https://swisscenter.com
1
Sébastien Riccio Replied
The ONLY way I found to have the different info@ users to be able to log in is to kill all existing info@ connections from this panel. This is getting ridiculous :(

Sébastien Riccio System & Network Admin https://swisscenter.com
1
Sébastien Riccio Replied
But it only lasts a few minutes before the logins are rejected again... and I need to drop again all info@ webmail connections for a user to be able to log in
Sébastien Riccio System & Network Admin https://swisscenter.com
0
Webio Replied
If some client is on the phone with you and agrees to change password for accessing his mailbox then using Expire password from admin GUI will solve his problem.

When you expire password for certain mailbox you will be able to impersonate his mailbox right away and user will be able to log in using old password but will be forced to change password.
0
Sébastien Riccio Replied
Only way I found to get back to a normal situation that seems to last is to stop smartermail and delete all auth-tokens.sbin files from all users....

With bash
```
rm -f D/SmarterMail/Domains/*/Users/*/auth-tokens.sbin E/SmarterMail/Domains/*/Users/*/auth-tokens.sbin F/SmarterMail/Domains/*/Users/*/auth-tokens.sbin G/SmarterMail/Domains/*/Users/*/auth-tokens.sbin
```
Sébastien Riccio System & Network Admin https://swisscenter.com
0
Ricardo Ranieri Replied
Hi

Good news, I inform you that version 8867 completely resolved our webmail logout case.

Reply to Thread