For the past month, I have been working on a mail server in the Cognac region of France and they were getting killed with spam and viruses. Hosting almost 70, high-traffic, legitimate domains: mostly building contractors and other local businesses, they were getting killed with junk e-mail.
I implemented the same antispam settings we use on our ChicagoNetTech SmarterMail server, which runs only the internal RBL and URIBLs, along with a few custom rules, used to catch some of the newer domains, and we are now trapping out almost 100% of the spam and viruses which were previously plaguing their customers.
Make certain you follow ALL of the instructions, including blocking the ability of users to override spam settings and forcing everyone to use GREYLISTING, or you will only shoot yourself in the foot and make your frustrations greater.
You also need to make certain that you are not set for OPEN RELAY. Enforce SMTP authentication for EVER MESSAGE SENT through your SmarterMail server - no whitelisting, no bypass: NO EXCEPTIONS!
Make certain you are not being compromised by BRUTE FORCE PASSWORD attacks (the customer in France is now blocking 278 IP ADDRESSES - all automatically, using the SmarterMail ABUSE DETECTION capabilities, available under SECURITY ===> ADVANCED SETTINGS.
Here's how we have their POP, SMTP, IMAP and XMPP password brute force protection setup (SmarterMail 14.4.5801) - and it catches the perpetrators and it works, blocking the offending IP addresses for 45.51 days, or until the SmarterMail service is restarted or the server rebooted:
POP Password Brute Force Protection Settings
SMTP Password Brute Force Protection Settings
IMAP Password Brute Force Protection Settings
XMPP Password Brute Force Protection Settings
In the case of my customer, one of their administrative accounts had been compromised, via a BRUTE FORCE password attack, and was being used to send more than 50K spam messages PER HOUR. The PASSWORD BRUTE FORCE abuse detection triggers, the configuration of which is shown above, now abates that ability significantly, but there is still a small chance of someone getting someone's password.
The spam senders were also using a different IP ADDRESS and different REPLY TO ADDRESS on all of the messages, so until the client could change the user's password, we also set SmarterMail to enforce a MATCH on the SENT FROM and REPLY TO e-mail addresses.
The BOTS, which are still busy trying to send the spam messages, are not too intelligent, and still trying to use the old passwords: unsuccessfully.
You don't need to add external spam checks. You can do so, but you will need to make certain that the spam scoring is set identical to the spam scoring we have setup in the SmarterMail RBL / URIBL checks, or you will only confuse the SmarterMail scoring and, potentially, allow more spam through. Therefore, we use no external checks, only the internal antispam checks discussed in the document available at: https://portal.chicagonettech.com/kb/a171/smartermail-antispam-settings-document.aspx.
Remember, to be effective, you must follow the protocols and procedures outlined in the document to the letter - no variances, no overrides, of any kind, for anyone.
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net
Phonr: (773) 491-9019
Phone: (224) 444-0169
E-Mail and DNS Security Specialist
Network Security Specialist
Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/
Web and E-Mail Hosting, E-Mail Security and Consulting