Hah. I had Settings > Protocols: Allow Relay set to Nobody, but had Require Auth Match set to None. It is now set to Email Address. Good call. Domain > Configuration has Require SMTP Authentication set on.

I definitely have to improve the bad email addresses removal, but that's a whole 'nother thing.

The issue with SORBS was that three hacker email addresses were able to hit their honeypot address three times in three days. We changed the password for that account on the box and then asked to be removed from the list. Hopefully between the pw change and fixing the setting, above, will prevent this from happening again.

Thanks for the advice!

Update: after some testing, setting Require Auth Match to Email Address stopped the bulk emailing capability cold. I set it back to none and the emails are going through. I'll get with support to see what the best settings are and bring the results back here, in case anyone else ever tries this kind of set up.

Mik, those results lead me to believe you've got a compromised account somewhere. When you set it to Email Address that stopped whichever account is being used from generating spoofed messages. I'd recommend checking out this KB article here: 

Hey Kyle. I think you misunderstand what's happening on this server.

I host many websites, and they all have emailing capabilities (contact form, dynamic forms, bulk emailing ala Constant Contact) that use my bulk email server, using SM latest version, licensed. All websites hit this bulk email server with the same login / password, and send From: a single email address (not the login one, for security sake).

This bulk email server is not a general use email server. There is only one email account that is used by all websites for sending emails.

As a side note, I see continuous login attempts by IPs all over the planet, which I would love to block, if possible, while still allowing the world to send bounces back.

The problem is that all traffic uses SMTP:

o My CMS sending email

o Email servers out there sending bounces

o Hackers trying to send email through my server

I was hoping that by setting Require Auth Match to Email Address I would instantly block all incoming hack attempt traffic, but it actually stopped my CMS from being able to send out legitimate emails.

So, the question is, can I blacklist the world from using my bulk email server as a transmission point, while still allowing the world to send me bounces? Again, both use SMTP.

Perhaps you could add a new security feature that black/white list IPs for logging in purposes, and also black/white list IPs for general email reception.

That would stop hacking cold, while still allowing for bounces to be delivered.

The only other thing I can think of is setting up another bulk email server, just for sending emails, and blacklist the planet while whitelisting my CMS. I could then have this other bulk email server just for receiving bounces, and have the one email account Disabled (allow mail), which we can use the APIs to Enable and Disable as we automatically check for the bounce emails.

BTW, the link you sent is for version 15, and the steps did not match how 17 works. Build 7776 (Apr 16, 2021)

Mik - Ultimately there are a few issues here - and I think we're mixing areas that aren't related. In this scenario turning on Require Auth Match: Email Address would definitely break your web forms since they're authenticating with one address and sending another. This setting will have no impact on hackers attempting to guess passwords, as they're not actually getting far enough to be checked by this security setting, and are simply trying bad passwords to guess accounts on your server. 

These are best handled by tweaking the rules found in Settings>Security>IDS Rules so that the Brute-Force by Protocol rules catch and temporarily blacklist these attackers. 

Lastly, as I noted on your ticket you can definitely blacklist a range of IPs that covers the entirety of the internet, then whitelist only the servers and clients you want to be able to connect regardless of the blacklist entry. This will prevent inbound/outbound SMTP access from anyone and everyone aside from the IPs you've whitelisted explicitly. 

On the KB article I sent you, these instructions should be more or less the same. Ultimately you'll want to head into reports and then down to Message Traffic where you can set the Mode to Domains. This will allow you to further drill down into each domain's message traffic and see how is sending (on average) more than usual. That being said though, I don't think this will help in that case as you're sending all of your contact forms via a single account. 

All in all I recommend adjusting your IDS settings to catch these password hack attempts and blacklist them for long periods of time. I usually set these (in production) to the following: 

Because most email clients will stop attempting to log on after a few failures, these rule changes should not catch the legitimate password failures and should only be applied to users who are deliberately failing authentication to guess passwords. I hope this helps!

Hey Kyle,

Thanks for explaining how the Auth by Email works. Makes perfect sense.

Not going to use the Blacklists on SMTP as I need to allow incoming emails from servers out there just for the purposes of delivering bounces.  If ST is able to split up SMTP security by login-for-sending vs. hand-off-for-delivery that would be helpful, as I could blacklist the world and whitelist my web servers for sending, and leave delivery open for returning bounced emails.

Thanks also for reminding me about the IDS Rules. These are the two I have for SMTP (below). I figure my web servers have the un/pw saved and will never get it wrong, so I can keep the thresholds very low.

One last question, just to confirm. If I want to block the world for POP but allow one of my web servers POP access (to retrieve the bounced emails), I could blacklist 0.0.0.0 - 255.255.255.255 and whitelist just the one IP for my web server, correct? I wouldn't have to blacklist 0.0.0.0 - my server's IP -1, and my server's IP +1 - 255.255.255.255

And on the same thought, I should probably blacklist the world for IMAP, right? That won't prevent me from logging in via the web interface, correct?

Thanks

For best results, you need to have an incoming gateway which receives traffic from the world using unauthenticated SMTP, which is separate from the mail server that handles authenticated SMTP from  your users. 

The incoming gateway box can be configured with an IDS rule to block after 1 login failure, since no login should ever be attempted.   This is discussed on a previous topic that I started.   I have been converting the temporary IDS blocks into permanent ones.   Between the two, I currently have 5500 blocked IPv4 addresses.   Others have said that the attackers move on, so they have the IDS rule block for a few days but they don't worry about making blocks permanent.

An incoming gateway also simplifies spam filtering, because unathenticated users need identity assessment (spf, dmarc, and local policy) while authenticated users do not.   So the spam configuration is different.

SmarterMail Free is one option for the incoming gateway, but certainly not the only one.   SmarterTools will treat it as fully supported when it is used in conjunction with your licensed server.

I'm good for now. Can't imaging setting up yet another email server. Would love it if SM split up security, blacklist and whitelist settings for these two types of SMTP: authenticated (for sending) and non-authenticated (for receiving). That would be amazing. Also, a sharing of blacklists across SM customers, and server-level content filters, used only for authentic spam.

Yea you can do the little trick there of blacklisting everything and whitelisting what you want. We look at whitelist before blacklist and will bypass blacklist checking if it's whitelisted.

Disabling IMAP or blocking all connections on IMAP will have no impact on the web interface.