Requirements for Fighting SPAM
Idea shared by Douglas Foster - May 17 at 10:46 AM
Proposed
SmarterMail provides both Mail Server and Spam Filter features.   I am accustomed to thinking of these as independent solutions.   I currently have SmarterMail hidden behind two different spam filters from two different vendors.   I am increasingly frustrated by their inadequacies, so they shall remain nameless.   I know that I could configure a second SmarterMail system in Smart host mode to be a dedicated gateway, but I don't see it as an adequate solution to the problem either.   Below are the requirements that I plan to use for my next spam filter procurement.   Unfortunately, I am not sure the product exists.   Since SmarterTools wants to be in this space, I am sharing it here first. 
 
Requirements for Fighting SPAM

Message Log with Query Interface

A Message Log Viewer helps to identify possible SPAM.  When investigating complaints or penetrations, it becomes important to determine what other message were received from the suspicious source.     Without a good view into the message log, patterns become impossible to identify.
To support real-time analysis, the spam filter should retain at least 30 days of messages for analysis using its query interface.   Then it should allow export of the logs to a relational database for longer-term retention and more sophisticated analysis.

Blacklisting

A typically spam investigation will typically start from a suspicious message, and then look for related messages by searching the message log for:
  • All message with the same IP address or within an adjacent IP address range
  • All messages with similar Reverse DNS name suffixes
  • All message with the same FROM address (most spam filters capture the SMTP from, rather than the From Header.   The SMTP From is probably more useful for organization-level threat analysis.  Ideally, both From entries should be available for searching.)
The message log viewer should make this type of navigation as simple as possible, so the complete range of blocks can be determined and the complete set of mishandled emails can be identified.
Once the three-part analysis is complete, the corresponding blacklist entries need to be made.  Because spammer organizations do not use stable configurations, most actions should involve four actions:
  • Block the offending IP address or range
  • Block the offending Reverse DNS suffix
  • Block the offending from addresses
  • Notify the vendor to update his database
The three-part block is a logical “OR”, any one match is sufficient to block the message.   This helps to ensure that future messages are blocked even if the sender changes identity or servers.
The ideal spam filter should integrate the search, reporting, and blacklisting into one seamless process.
Whitelisting
I have worked with spam filters that consider whitelisting to be the reverse of blacklisting – the user can pick one criterion, and then it will allow all traffic for any messages that match the rule.  They make one exception, messages with confirmed malware attachments are blocked even if otherwise whitelsted.
Anyone familiar with the email infrastructure should recognize this as folly.   Assume that I want to whiltelist messages from “ExampleCompany.com”, which is hosted in the cloud using services provided by “HostingExample.com” .  If I whitelist all messages from “@ExampleCompany.Com”, I am vulnerable to anything that has a fraudulent sender address (which is common).   If I whitelist all servers at “HostingExample.com”, I am vulnerable to all messages sent from other clients of that hosting service.   The whitelist must be multi-part:  From a particular email domain and from an expected set of servers.
Additionally, I have been frustrated with spam filters that have an all-encompassing whitelist action.   If I am whitelisting something because the sender has an incomplete SPF entry, I really only want to create an exception for SPF, not necessarily for every possible rule.
If I am going to whitelist a message, I also need to know all of the reasons that the message was blocked.   The typical spam filter will process rules until a block condition is detected, then stop.   If I have followed the blacklisting strategy listed above, removing the blacklist may require multiple block rules to be modified.   Therefore, the spam filter should provide a simulation tool so that I verify that a reference message will be allowed the next time that it is attempted.

Policy Test Mode

SPF is an example of a defense where the ramifications of enforcement are difficult to predict.  A good spam filter should allow me to collect SPF results on messages without acting on those results.  After a period of data collection, the system administrator can determine what exceptions need to be configured before the policy is activated.   Test-mode data collection should be available for at least these defense mechanisms:
  • SPF
  • DKIM
  • DMARC
  • New RBL sources
  • Forward-Confirmed Reverse DNS
Previously-Dispositioned Messages
A blacklist investigation typically involves these steps:
  • Review the message log, particularly “Allowed” messages, for suspicious entries
  • Identify a problem and take corrective action to blacklist or whitelist those messages in the future.
  • Continue reviewing the message log for other issues.
To support the “continue” step, it would be highly desirable to filter the message log for “Allowed” messages that have not had a disposition change as a result of the revised blacklist/whitelist rule set.
Here is one way to achieve this result:
  • Using the integrated search-and-blacklist process described earlier, the user proposes a set of new rules, and then evaluates the message log to review all of the historical messages that would be affected by the new rule(s).
  • The user is pleased with the results of this analysis, and approves the changes.   The spam filter activates the new rules, and simultaneously flags the historical messages with the disposition that would have been applied under the new rules.
  • The user starts  a new investigation by selecting message that “would be allowed under current rules” rather than “messages that were allowed under previous rules”

DMARC

DMARC was invented because DKIM and SPF did not work as standalone methods.   The technology involves enforcement rules, feedback  data collection by  the receiving organization, which is then transmitted to the sending organization for evaluation.   The feedback evaluation process is unrelated ot the spam filtering effort, and is financially prohibitive for most smaller organizations.   The feedback collection and transmission feature is desirable but not strictly required.   However, DMARC is mature technology and there is no excuse for a spam filter which cannot evaluate messages based on DMARC instead of considering SPF and DKIM individually.

Authentication-Results header

RFC 7601 lays out an architecture for a trusted spam filter to pass authentication test results to a trusting mail server or mail user agent.   While there is a shortage of mail user agents that support this feature, the concept is important for integrating the end user into the spam defense system.

10 Replies

Reply to Thread
0
Hi Douglas. Just a few thoughts and comments for you...
 
Antispam development and mail server software development are 2 completely differnt business as you already know. SmarterTools' job is to provide a great mail server, which they do. Fighting spam is not any mail server software developer's core compentency.
 
I believe that everything that you are suggesting is already included in SmarterMail, but in my opinion those things are not going to be the best antispam solution because of a few reasons.
 
Everyone should in fact have SPF, DKIM and DMARC set up. SPF, DKIM and DMARC will help to prevent spoofing very well, but those things are not going to be proficient in fighting spam as the best solution possible as a whole. Also, not sure if you are aware, but implementing DMARC is actually free. We use an awesome site called dmarcian.com to set up our DMARC records.
 
Also, you said that you wanted the ability to have more robust logging via a Message Log with Query Interface. SmarterMail already has solid logging and you can search for anything you need in their logfiles. My thoughts about your suggestion is that if one has to constantly check logs to fight spam, you will end up fighting a losing battle. Also, digging through logs on a contant basis is very time consuming and I'm sure all of us have better things to do. :)
 
Blacklisting is a good idea for known spamming IPs and addresses. However, there is the problem of pre-tested spam. I'm sure you're familiar with pre-tested spam, but in case you are not, pre-tested spam occurs when a spammer obtains new, fresh IPs and domain names then they send good mail out from those IPs until antispam systems trust them. Once trusted, they blast out tons of spam. That spam gets through all of the spam filters that people have because the IPs and senders are clean. Only after the spam is sent can the antispam systems start to pick up the IPs and block them as spammers.
 
Discussions like this are great and there are so many different options and solutions available for antispam today. You have some really great ideas! If you would like to pick one of these things that is most important to you, I will be very happy to continue this discussion and try to help you get in place something that you like and that will work well for you and your customers. That's my 2 cents. Hope this helps and thanks again for posting this. It's a very interesting discussion!
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
(An aside:) I read your posts about GDPR with great interest. Thanks for posting that material.

I am referring to a query interface that treats each message as a data record, with to, SMTP from, Header From, Subject, timestamp, action, reason for action, and encryption status as fields in that record. SmarterMail logs the chatter between itself and adjacent devices, which is probably useful for debugging code, but it is an obstacle to understanding the logs.

My incoming mail is scanned by 2 RBLs, a scoring engine, and 2 AV engines before hitting SmarterMail. Still a lot of spam gets through. Not malicious attachments, but plenty of unsolicited advertising from sources with dubious web links and dubious ethics. I actually am looking at the logs every morning, and am appalled by what I am seeing.

As far as I can tell, SmarterMail does little of what is on my list. It can do DMarc in the newer releases. It can do single-attribute blacklisting. And that is pretty much where it stops.

It does not do anything to integrate log review with blacklisting. It does nothing to help navigate from one unwanted message to all of the related traffic. It does not provide any feature simulation or restriction testing. Unless there is a lot more in the newest releases than what I understand. i am badly behind the release cycle but plan to catch up.

SmarterMail is a great mail solution for us -- almost all of the functionality of Exchange, with a lot less complexity and a lot less cost. It never needed to be our spam filter, and i would not be happy with its limitations.

But I am actively looking for alternatives so that I know what I want to pursue when the budget climate or raw fear makes management ready to approve an upgrade.
0
Thanks Douglas. Can you please post a header from one of the spam messages that made it through? I would like to review it.
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
I sent some data by private message. A public summary: I picked a random message from today's history, then expanded the search to find related messages on the same subject and from adjacent IP addresses.

Today I received at least 197 attempts from servers in the range 23.94.187.195 to 222. Each server had a unique Reverse DNS entry and these involved 11 different subject lines. That information would be hard to determine from the SmarterMail logs. It could be made easier with custom-developed parsing software, but the export-and-parse process means that it would be hard to use on a real-time or same-day basis.

Can anyone listening, using any available spam filter, determine whether they have been hit from this IP address range, and whether their spam defenses blocked all of their attempts? I would love to find someone who is happy.
0
I responded to your private message. Please have a look at what we found when looking at your sample. Thanks!
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
Impressed by your results.
0
I have found that log review is very effective.  There are several types of spam sources --
 
One situation involves a widely-used and legitiimate mail service such as gmail or hotmail, which has a specific account being used for malware.   The recipient has to rely primarily on content filters to defend against these attacks.
 
There are mass mailing services which send a mix of wanted and unwanted mail.   Sometimes these can be separated based on sender address, but not always.   However, even the unwanted mail is generally not harmful.
 
There is the individual PC, probably at a house, that is infected and being used as a spam bot.   These devices can be blocked by IP because they will not send legitimate mail even when they are disinfected.   Better ISPs prevent home users and dynamic-ip users from sending on port 25, but not all.
 
The last category is the spam-only services that send fraudulent and malicious content.   These can be blocked  by IP and Reverse DNS an Sender address.   They change this information, but I don't expect that the block will ever need to be removed.   For these people, a content-based block strategy is insufficient, because they are always changing their content and will eventually slip through.   Permanent blocks are more appropriate.   
 
I have found that a couple of weeks of aggressive log review, followed by IP and Reverse DNS blocking, has trimmed our volume of unwanted and hostile mail pretty dramatically.
 
IPv6 will make blocking by source more difficult, because there are so many more addresses for the spammers to hide behind.
0
Thank you!
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 
0
So what did you find, Linda?
0
Hi Scot. Douglas had provided the headers from a spam message that he received. I took that header and analyzed it against our anti-spam software. I determined that this is an example of pre-tested spam. As we know, these are extremely difficult to catch as they tend to be new spam campagins where the IP was not on any public RBL's. Our system manged to identify these as spam with 2 specific tests... SPAMZONES our private RBL, and Message Sniffer. I also found that we had 560 spamming attempts starting at 09:26:09 that morning from IP's in the 23.94.187.0/24 range, but we managed to catch them ALL as spam.
Linda Pagillo
Mail's Best Friend
Email: linda.pagillo@mailsbestfriend.com
Web: www.mailsbestfriend.com
Authorized SmarterTools Reseller
Authorized Message Sniffer Reseller
 

Reply to Thread