BarricadeMX: Version 2.0 is out!

BarricadeMX 2.0 is now out!

I had the chance to work a lot with it and here is a little review/announcement:

New Features (by category):

Flexibility

• Now available in more formats
• Binaries (yum repository, rpm, FreeBSD package, etc)
• VMware Appliance (soon)
  
• ISO self-install CD (installs CentOS and BarricadeMX 2.0)
  
• Combo Tags
  
• This allows rules with more than one criteria. Before, you could only say, for example, skip all tests for this IP address. Now you can say, for example, "skip all test for this IP address, then the recipient is user@domain.com". The same can be said for creating more targeted black list entries.
  
• Improved spamd support: Can now tag and add headers
• In the previous version, it could only reject when the SpamAssassin score was above the configured level. Now it is also possible to deliver the message, but adding a tag in the subject or add headers for client-side filtering
• smtp-delay-checks
• This feature is very helpful for 2 reasons:
  
• Whitelising: In the previous version, some tests could not be disabled for one recipient, for example, because the rejection took place as soon as one test was triggered. For example, DNSBL tests. Since we get the IP address of the sending host before the recipient or sender, the rejection was immediate if the IP is on a configured DNSBL. When this parameter is enabled, then when a test is triggered, the rejection is delayed until each recipient has had a chance to be checks for white listing.
• Diagnostics: Since we often didn't get the sender or recipient address, someone who was saying "I can't get mail from this person" would need to provide more information to be able to fix the problem. With this parameter enabled, logs show sending IP address, sender and recipient, so it is a lot easier to find the information we're looking for.
  

Spam catch rate

• Grey-content
• This adds one criteria to bypass greylisting. It makes sure that it is effectively a retry of the same message. Spam bots have started sending the same message a few times to the same recipient to bypass greylisting and this new mechanism helps defeat that. Also, spammers try to send different messages to avoid bayesian analysis (or to poison the bayes database). Whith the classic grey-listing, the tuple of ip, sender, and recipient meant that one of the attempts would eventually get through classic grey-listing
• New outbound anti-spam mechanism
• This prevents someone within your network from sending through a BarricadeMX server using a false address from some place completely different like yahoo, hotmail, gmail, etc.
• Read the other's servers headers (X-spam-status:Yes)
• This improves the catch rate quite a lot. It can read the headers inserted by the previous mail servers, it can then react by rejecting when the spam-status is Yes in the headers, or when it is a score, it compares it to its own thresholds and react accordingly (deliver, tag, or reject). The idea here being, if the sending server identified the message as spam, then why would we consider it otherwise?
  

Performance

• New threading model, with a pool of pre-spawned threads
  
• Means better response on port 25 and more efficiency (you get more out your hardware!)
  
• Call-ahead improvement (detects dumb hosts and catch-alls by domain)
• On the first call-ahead(s), it tries a kind of sure-to-be-invalid email addresses, and if the backend server doesn't reject it, the host is considered as 'dumb host' and call-ahead will not be used anymore for this recipient domain.
  

Reduction of FP

• Well behaved host processing
• It recognizes good behavior from sending hosts and once a host (or group of hosts) have shown that it (they) behave well, some tests are not applied. This can help reduce delays, and relieves the sending hosts of some load.
  

Reporting

• Better logging
• You'll see for yourself, but basically a lot of efforts have been put into logging improvements so that a maximum number of information is available in every log entry. The logging configuration is as always very extensive and can also be turned right down to "terse mode" where the summary log lines provide as much info as possible about the state of the session or message transaction.
• New administration commands
• New commands allow to see current SMTP sessions and kill specific sessions if needed.
  
• More stats (per-route, 60-minute rolling window)
  

Other new features

• Avast! and F-Prot anti-virus support added, in addition to the ClamAV support.
• Null-Rate-To: tag is another backscatter reduction method that monitors the number of messages from the null sender per minute and can be configured by recipient address, domain, or globally.
  

That is about it for the new features, but here is a reminder of the features that were in version 1.x.

• Better Greylisting
• The Greylisting mechanism has been improved so that it can:
• Recognize groups of mail servers. Once one of them has passed greylisting, all the others will not be greylisted
• Only check what it is supposed to validate: Is the sending client implementing a queue.
• Call ahead (checks if the e-mail address is valid on the destination server before doing all its tests)
• A mechanism that inserts a code in the headers, allowing BarricadeMX to tell if the email is a response to an e-mail that went out through this server (prevents backscatters and alows replies to be auto-whitelisted)
  
• Several mechanism that recognizes non-RFC/standards compliant hosts, as almost no spam-sending system is compliant. It can also throttle smtp connections based on different criterias.
  
• Can check with SpamAssassin and ClamAV daemons directly.
  
• Works in front of ANY MTA (sendmail, postfix, exim, qmail, Exchange, Domino, etc)
• Use of dnsbls, dnsgl, dnswl, and URIBLs (URIBLs tests are done at many levels, not only in the message body)
• It can append to the rejection message custom text to provide contact details.
• SPF checks and workarounds
• Shared cache for call-ahead and greylisting
  

The nicest thing about BarricadeMX is that it does everything at the SMTP transaction. This means:

• No quarantine
  
• Less storage needed
• Senders get notified quickly about the rejection (and no "bounce" is used)
• Recipients don't have to look at their quarantine to see if they missed something

• Efficiency
• Many very simple tests are performed early in the SMTP transaction, so most messages don't get as far as body tests, which are the most resource-expensive ones.
• Tests has been done and BarricadeMX is able to handle an extraordinary amount of concurrent SMTP connections, while keeping hardware resources usage low.

I currently use BarricadeMX + Clamd + Spamd at one site and BarricadeMX + MailSCanner (SA, Clamd, etc) at many site and it works flawlessly.

Well, to wrap up, the original version of BarricadeMX was very good, especially for high-volume sites, and this new version adds a lot of new improvements and is very flexible. For a free trial, please follow this link.

For more information, please contact Fort Systems LTD

As usual, comments are welcome :)