Not sure what's happening, but we are getting POUNDED with spam, despite having pretty much everything you offer being licensed.

I'm hoping ST can fast track the Content Filtering / Spam button code we've been discussing in those other two threads. Daily I get bogus offers from "Amex" and bogus bills from "Charter CC" and all kinds of crap that I know my users are getting, too. It's not just the inconvenience of getting this crap, but some of the emails look legit and they're paying those bills, not realizing they're bogus. We need that button so we can begin filtering out this stuff at the server level.

Spam is a many-headed hydra, and spam filtering is big business.   The big cloud-based spam filtering vendors want $15 to $20 per user per year for what they provide.  But given the number of big organizations that are hit with ransomware, I don't think even that kind of money will actually buy you immunity.

Every time you find a spam message, you need to block as many of these as are implicated in the attack:
(a) the IP address,
(b) the Helo/EHLO domain name,
(c) the reverse DNS domain name
(d) the smtp Mail From domain, and
(e) the From domain.

Many spam filtering products do not even examine all of those attributes.  But if we don't close these obvious attack vectors, we should expect to get more spam from the same sources.   I did not see any hope of getting this accomplished with either of my two commercial appliances or the embedded SmarterMail features, so I have looked elsewhere.

After a long look at many expensive products, I found Declude (for free), and it is the core of my source- filtering process. It permits multi-factor filter rules and customization, while my two commercial spam filters do not.   I integrated Declude with a SQL database to improve performance and simplify data analysis.    I still use my commercial spam filtering appliances for content analysis of the messages that Declude lets through, but most of my garbage gets blocked by Declude based on source reputation rules.   Getting to this point has required a lot of time staring at the message log to decide what should and should not be allowed.

The necessary companion to good email filtering is good web filtering.   I currently use Sophos UTM for that function, but it will need to be replaced with something else in the next few years, and I don't yet know what to use for its replacement.

With the combination of a good spam filter, a good web filter, and a mostly cautious user base, we have been able to keep the ransomware monsters at bay.  Don't wait for SmarterTools to solve your problem; you need to solve it yourself.

And don't get me started about Microsoft and Office365.   It looks to me like their strategy is to capture everybody's data so that they can index it for building a search revenue-generation engine that is better able to compete with Google.   Once you give away your data to them, will you ever get it back?

There are an increasing number of grossly mismanaged ISP's that have large blocks of IP's that are sources of SPAM, denial of service, and brute force password attacks, and nothing of value - such as 193.169.252.0-193.169.255.255.  Blocking the most notorious IP ranges on the firewall works wonders.  (We have 7 ranges blocked and no issues with legitimate email being blocked.)

@Doug, that sounds like something I can get behind. We have Declude on our box already, and I'm quite familiar with SQL Server. Do you have anything you're willing to share?

Happy to share, but it will take a few days for me to assemble the files and review my previous attempts at documenting the way I approached the filtering problem.

Please send your email via private message.

I have several C blocks of IPs and always getting scanned. One thing I did is I set up a "honey pot" on my firewall.

Registered a domain name
Assigned my domain name MX records to my honeypot IPs
In SM added that name to my honeypot IPs

Someone scans one of those IPs along with the typical mail ports, I add them to a blacklist.

Seems to help a bit with Spammers, some days I have more in my blackhole than other days.

Does anyone know if SM can do something similar?

To follow up my previous post, this is a summary of how I use SQL with Declude

Pre-Requisites:

You need authentication scripts to assess SPF, DKIM, and fcDNS.   I have these already, mostly from freeware sources with a little customization.   They are written in Python, and are called from a custom filter implemented as a vbscript.    Authentication Results are written to SQL, and keyed on TrxID (the number used to create the name of the .HDR and .EML files)  Once the initial transaction record is created, additional data can be added by matching on the TrxID.

Matching Logic

Host names and email addresses are broken at segment boundaries and loaded into a temporary table.
 Example:   John @ bounce.e.example.agency

Becomes these temporary table entries:

The temporary table is joined to the policy table using inner join.   This reduces flexibility slightly, but it eliminates the performance problems associated with “ends-with” matching rules.   Instead, all matching is based on exact equality and can use SQL indexes and query optimization.  I currently have tables with several thousand entries, but they could probably grow 100-fold with minimal performance impact.

An additional parameter to the query is whether the source item is validated or not.   A flag on the data record indicates whether a validated match is required.    If the validation-required bit is set on the policy record, then the source data must be validated for the record to match.      This fits a security design which says that untrusted names do not need to be verified, because spoofing is not a concern.   Trusted names must always be verified before they can be trusted, because I need to rule out spoofing.

Design flaw:   Because of this design, two entries for the same name may be required, one to set an action for the verified name, and one to set an action for an unverified name.  This has not been a huge issue because an unwanted and unverified name is often blocked based on a shorter segment of the name.  Nonetheless, a better design would be to have set two flags on each record, one for verified and one for unverified.  I intend to switch to that design in the future.

The SQL query sorts by length of the match string, and returns the TOP 1 record.   The result data element is a simple letter starting from A.   (Z indicates no match).    When multiple queries are consolidated, the lowest letter wins.   The design is intended to provide flexibility of interpretation, but I currently use these codes:

I have tables and supporting stored procedures to implement these types of queries:

This approach provides a lot of flexibility.   The single-attribute matches are mostly used to block unwanted sources.   The multi-attribute matches are used for allow actions such as overriding a sender’s incorrect SPF policy, as well as block actions.

HELO name and Reverse DNS name are treated interchangeably, which fits my experience with actual data flows.   In many cases, the two names match.   When they are different, the HELO name is more likely to forward-confirm.    But when the Reverse DNS name can forward-confirmed, it can be useful.   For example, outlook.com servers will always forward-confirm on the Reverse DNS name but never forward-confirms on the HELO name, even though both names have similar suffixes.

When I find spam that uses a spammers infrastructure, I always block based on the server DNS name.    Blocking on IP address and email domains are also appropriate, but host name seems to be the most powerful weapon against them.   When I find an attack from a gmail account, I create a policy record to block the single address.

One mass mailer takes both wanted and criminal clients.   Consequently, the incoming content varies from password reset messages for critical websites, to fraudulent messages pretending to be from a bank.   I trust the mailer not to allow spoofed email addresses, so DMARC verification is not essential.   I use the #6 filter to handle this source.   Messages from known clients whose content is needed will be whitelisted.    Messages from known clients whose content is unwanted will be blocked.   Messages from uncategorized clients will be quarantined so that the sender can be categorized.

I still use Declude filters for some things, since they have more flexibility.

All of this is done on an incoming gateway.  I am a firm believer that the incoming gateway and the mail store should be separate servers.

Updating the policy file could be a full-time job, but a few months of regular effort produced a significant improvement in spam control, so now it needs less attention.    It is easier to block spammers by their source than by their content.   As I said earlier, I still use commercial products downstream to handle content filtering, after Declude discards the known junk sources.

Sources available on request.

 

Wow. That may be marketable as an add-on to Declude or SM itself.

My ego will be satisfied if other people use it.   I want to stop the ransomware scum from destroying our civilization.    

The failings of commercial spam filters make my blood curdle.   We pay them big money, expecting them to understand the problem that they claim to solve.   If they did, we would not have so many products that are unable to configure a multiple-attribute allow rule.

Two of the big players in spam filtering, major companies that pitch their ability to enforce DMARC, also have secure email solutions.  Those secure email solutions violate DMARC whenever a non-client responds to a secure message sent by a client.   I have filed security incidents with them.   Did they change their products?   No way!