Implement an easy and effective workaround for DOS-ing a mailbox
Idea shared by David - 11/9/2023 at 6:42 AM
I am a long time SM user. Lately I've been having many issues with password brute force attacks. In short, this is what happens:
- an email address in my domain is targeted, for password brute force
- attacks are happening very slowly, so DOS IDS rule will not trigger
- attacker is obviously using a botnet, on each try source IP address is different (this avoids the IDS IP blocking rule)
- what happens in the end is that end user mailbox gets locked, serveral times a day, because of too many wrong passwords tried, effectively causing a DOS for this users mailbix.

Smartermail doesn't have many options to cope with this. In need to use SMTP to send emails, so this protocol needs to be enabled. I can't configure a default SMTP port to only allow receiving emails and a different one for sending emails. I can't configure IDS rules separately either (separate IDS rule for separate SMTP ports).

What comes to mind as an easy an effective measure is this:
- allow the user to authenticate with a different username (different from email@domain.com)
- allow us to disable authentication with email@domain.com

Speaking from a developer perspective, as a developer, this should be relatively easy to implement - and would be super effective in preventing just anyone to DOS a mailbox with too many failed login attempts from different IPs.

Email addresses are public. When that is being used as a username, it's dead simple to DOS a mailbox. And that's what happening to us.

Could you please give us such an option in Smartermail ?
I am standing by if you need any further clarifying.

4 Replies

Reply to Thread
This is an extremely good idea. I hadn't heard of (or thought of) this sort of attack with email accounts, but of course it will happen.

Pretty much the same thing as with many other online accounts, where usernames and email addresses are intentionally not identical.

And when the username is entered, a password should be requested, without the end-user being told whether or not the username is valid.

I think SM and other email providers need to think seriously about implementing this, as it most certainly can add another layer of security. 

Not foolproof, but seems completely reasonable to me.

For anyone having these issues and trying to find a solution, read below.

I've been having lots of issues with this, ever since posting here. My colleagues mailbox and mine are obviously targeted so, we get a blocked mailbox several times per day. Smartermail developers seem to ignore this request completely.

Today I came up with the idea to rename our mailboxed and use some other address for the mailbox, that noone knows about, then create an alias to point to that mailbox. This way the user can log in with "user-randomstring@domain.com" and give out the email address "user@domain.com" which is actually an alias. You can't login with an alias so... We have a solution.

Smartermail has an option to rename an existing mailbox, so that's good !
1. rename your existing mailbox from "user" to "user-randomstring" or whatever you want to login with. Keep this address private, don't list it, don't share it. This is your new username that nobody should know.
2. create an alias for "user" to point to your renamed mailbox. For this alias, enable the option to use it as "From" address. You will need this if you use webmail, to make outgoing emails from the renamed mailbox to use the alias address instead.
3. reconfigure your mailbox to use the alias address as "From address"
4. reconfigure your email clients to use your renamed mailbox address as username and keep you alias as your "From" address.

That's it. Now it not so damn easy for someone to block your mailbox x times a day. Or to crack your mailbox, which would be much worse.

I still think it would be much better (and easier and more safe) for users if Smartermail developers would implement a separate "username" for mailbox and discontinue the use of email address as the username (or give an option to turn that off, for us to have a more secure mailbox). But in the mean time - while we are waiting for the sun to shine on this one - you can use this trick with alias to achieve the same result. For a limited amount of mailboxes it's doable.

We have used the solution described by David for years with victim mailboxes even before we moved to SM. MailEnable was even less able to handle situations like this. 

It's a VERY effective means to combat the problem. Integrated with an external solution, and you can instantly block IPs that are attacking the alias rather than let them continue to abuse the server.

MailEnable survivor / convert --
The only issue I see with that method is that the "envelope" address in emails sent by that user will match the user's login name. This can of course be gleaned from the header of any emails then sent by that user. But a hacker would need to see a received email sent by the user and dig into the header, so it's still a reasonably effective workaround.

Better than nothing, but implementing something where the login name is completely different still seems a great idea.

But wait: While it might be good for webmail login, I do see an issue with standard email authentication (e.g.IMAP), which is based on the email address plus password. Correct me if I'm wrong, but a separate login name in the authentication handshake would require a new RFC. Daunting? 

Reply to Thread