Traffic Control Blog

New Blog Location

noreply@blogger.com (Desmond Liao) — Mon, 30 Apr 2012 22:59:00 +0000

We noticed that this blog is still averaging 20 visitors a day. For the latest on MailChannels, email security trends, and our outbound spam filtering software, please visit our new blog!

Direct From The MailChannels Labs : Plesk Installer Of Traffic Control

noreply@blogger.com (Phil Whelan) — Fri, 07 Nov 2008 01:02:00 +0000

Installing Traffic Control For Plesk from MailChannels Corporation on Vimeo.

The Architecture Of Traffic Control 3.1

noreply@blogger.com (Phil Whelan) — Fri, 03 Oct 2008 17:17:00 +0000

This is a response to a question to a question we recently received.

Your traffic control looks like a very interesting approach, but there are
a couple of questions I have that your online documentation didn't seem to
answer:

1. One problem I have is that I'm using Apple XServes running OSX 10.5,
which has a hard coded limit of 2500 processes per server. I'm running Exim
which launches one process per email delivery. Does Traffic Control do the
same? If not (eg, it might use a thread per incoming mail connection), then
it could be very useful.

The architecture of the latest version of Traffic Control uses several processes. One process for management, one for logging and then several (default of 3) child processes that are single threaded processes. We have found this single threaded architecture is the most efficient way to handle large volumes of connections. Using mulitple child processes allows us to spread the work across several processors or cores and also allows us to continue processing and renewing processes if any problem were to occur. Also, this allows us to use very few persistent connections to your email server.

2. Does traffic control act as a pass-through SMTP proxy, or does it accept
email, then relay it. This makes a big difference to my rejection policy. I
like to reject at SMTP time, instead of accepting then possibly bouncing
email.

We do everything inline. We do recipient validation with your email server, and when we have fully accepted the email and it has passed all our tests it is passed to your email server. We then proxy back the response from the email server to the connecting client. Once again, this is done inline. This is very efficient since the load on the email server is usually vastly reduced due to the number of connections that are removed by our throttling and RBL checks.

Using syslog with Traffic Control

noreply@blogger.com (Phil Whelan) — Fri, 26 Sep 2008 23:17:00 +0000

The file you need to edit is /opt/TrafficControl/conf/log.conf

If you want to direct the Traffic Control log into syslog as well then you can change

  log4perl.logger.traffic_logger     = INFO, TrafficLogfile

  log4perl.logger.traffic_logger     = INFO, TrafficLogfile, Syslog

You can also append ", Syslog" onto the end of the other logs if you wish.

  log4perl.logger.error_logger       = ERROR, ErrorLogfile

  log4perl.logger.debug_logger       = FATAL, DebugLogfile

Once the file is edited you can call reload-proxy.sh

  sudo /opt/TrafficControl/scripts/reload-proxy.sh

Installing MailChannels Traffic Control In 90 Seconds!

noreply@blogger.com (Phil Whelan) — Tue, 22 Jul 2008 18:10:00 +0000

My previous installation video for MailChannels Traffic Control was 6 minutes long (long!). It actually only takes about 90 seconds to install Traffic Control on your server, so I recorded this video to show that and also save time for those sysadmins that only have 90 seconds and not 6 minutes.

Please visit mailchannels.com/download to freely download Traffic Control

You've read the Anvil(8) man page - is this as good as it gets for spam DDoS protection?

noreply@blogger.com (Ken Simpson) — Wed, 16 Jul 2008 21:37:00 +0000

MailChannels Traffic Control provides innovative email traffic shaping solutions for organizations of all sizes, enabling customers to simultaneously solve their spam problems and reduce their email infrastructure costs. On this page, you'll learn how Traffic Control compares with Postfix Anvil, and why you should consider Traffic Control if you are already using or considering using Anvil.

What is Anvil?

Anvil is a light-weight connection rate control mechanism for Postfix, which allows you set limits on how hard someone can hammer your Postfix server. Anvil was created in response to the dramatic up-tick in spam that started happening several years ago, as a way to protect Postfix installations from high connection concurrency and resource exhaustion. It is commonly recommended as the preferred solution to loading issues relating to spam. Anvil is essentially a side-car process that communicates with Postfix to maintain various counters relating to the hosts connected to your Postfix server. Postfix queries anvil to update and retrieve these counters, and take appropriate action to limit the damage from abusive hosts.

What is Traffic Control?

Traffic Control is a highly scalable SMTP proxy server that seamlessly integrates with Postfix. It increases connection capacity so that thousands of concurrent connections can be efficiently prioritized with negligible system load. Legitimate connections are processed right away, known spam is rejected, and suspicious connections are slowed down causing the vast majority of spammers to give up before completing message delivery.

Traffic Control integrates seamlessly with Postfix using the XCLIENT command (see www.postfix.org/XCLIENT_README.html), front-ending SMTP connections, and applying TCP traffic shaping to suspicious connections before passing on legitimate email to Postfix. Traffic Control is implemented using a very efficient libevent-based asynchronous IO layer, which enables handling up to 25,000 concurrent SMTP sessions with low overhead.

Comparison

Feature	Postfix Anvil	Traffic Control
Description	Works in conjunction with Postfix to maintain and enforce connection, message, and other rate limits on a per-host basis.	Applies TCP traffic shaping and connection multiplexing, increasing the capacity of Postfix to handle up to 25,000 concurrent connections, while reducing spam by 70-95% more than connection blocking alone.
Method of Operation	Receives connection statistics from Postfix, which are maintained in a database and reported back to Postfix via a TCP socket. Postfix enforces rate limits based on the counts reported by Anvil.	Receives SMTP connections, assessing their reputation and behavior through a commercially supported reputation network and set of customizable triggers. Contacts Postfix via SMTP to validate recipients and other SMTP commands in real time, and finally delivers messages to Postfix if the sender adheres to the SMTP protocol and persists long enough to get its message delivered.
Effectiveness against botnets	Rate limiting effectively stops high volume senders from abusing Postfix. Protection against botnet-based attacks is minimal, because individual zombies typically "fly under the radar," making only a limited number of connections.	Hits botnets where it hurts, tying up essential SMTP connection resources and causing 70-95% of zombie-based connections to abort before message delivery has taken place. Abusive high volume senders are forced to wait up to 10 minutes for message delivery, greatly reducing the impact of their traffic on Postfix and downstream users.
Pricing	Anvil is free - it is part of the open source Postfix package.	Traffic Control is commercial software; however, it is free for low-volume and non-commercial users. Please refer to our download page for details.

How to find out more

Our Traffic Control blog is an excellent source of commentary on Traffic Control, and the Traffic Control manual explains how it works in much more detail. Of course, you can always download Traffic Control and try it yourself. Or shoot us an email by filling in our inquiry form.

Where to find the Traffic Control Manual

noreply@blogger.com (Phil Whelan) — Fri, 11 Jul 2008 17:09:00 +0000

I had an email this morning from somebody using Traffic Control who wanted to know if there is an online version of the user manual. Yes there is. It can be found in the following locations.

Traffic Control Manual (HTML)

Traffic Control Manual (PDF)

Some key chapters that you'll want to check out are

Less Configuration = More Time For Beer

noreply@blogger.com (Phil Whelan) — Thu, 10 Jul 2008 22:12:00 +0000

I've been looking at all the configuration parameters that are recommended for configuring Postfix for anti-spam prevention, and there's quite a lot to learn.

This Postfix webpage gives a pretty thorough explanation and it's all good stuff.
http://www.postfix.org/uce.html

But with this many configuration parameters there's a lot of tweaking to do to get good spam protection.

body_checks check_client_access check_etrn_access check_helo_access check_recipient_access check_recipient_maps check_sender_access content_filter default_rbl_reply defer_if_permit header_checks invalid_hostname_reject_code maps_rbl_reject_code non_fqdn_reject_code permit_auth_destination permit_mx_backup permit_mx_backup_networks permit_mynetworks rbl_reply_maps reject_code reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_recipient reject_non_fqdn_sender reject_rbl reject_rbl_client reject_rhsbl_client reject_rhsbl_recipient reject_rhsbl_sender reject_sender_login_mismatch reject_unauth_destination reject_unauth_pipelining reject_unknown_client reject_unknown_hostname reject_unknown_recipient_domain reject_unknown_sender_domain relay_domains relay_domains_reject_code smtpd_client_restrictions smtpd_etrn_restrictions smtpd_expansion_filter smtpd_helo_required smtpd_helo_restrictions smtpd_recipient_restrictions smtpd_sender_login_maps smtpd_sender_restrictions unknown_client_reject_code unknown_hostname_reject_code warn_if_reject

Traffic Control, on the other-hand, is inherently designed to fight spam. The process of throttling unknown senders is so effective at removing spam, even before the email content is sent to your servers, that we can all have more time for the finer things in life.

What to do if Spamassassin is filtering slower than Postfix is receiving the email?

noreply@blogger.com (Phil Whelan) — Thu, 10 Jul 2008 20:49:00 +0000

Problem

Frank has a problem on one of his SPAM servers that uses Postfix and Spamassassin. Spamassassin is filtering slower than Postfix is receiving the email. So the Postfix queue grows larger and larger. He been trying to speed up Spamassassin, but he cannot make it fast enough.

Solution

If Frank were to install Traffic Control in front of his Postfix, then it could slow down bad senders and speed up good senders. Since most bad senders simply give up when they faced with throttling, the overall number of messages being received by Postfix and Spamassasin would be greatly decreased, lowering the load and preventing the Postfix queue from growing.

Download a free version of Traffic Control and see how throttling unknown senders and multiplexing to your mail server can relieve your sysadmin headaches.

How To Freely Download And Install Traffic Control 3.1

noreply@blogger.com (Phil Whelan) — Mon, 07 Jul 2008 17:30:00 +0000

This video will show you how to download MailChannels Traffic Control from our website and install it on your server. It only takes a few minutes to get up and running with Traffic Control.

Installation Process

Installing Traffic Control is easy. Simply:

Read the installation guide in the Traffic Control manual
Download the tar ball
Run install.sh as root
Follow the instructions presented by the installer
Modify your mail server configuration to accept Traffic Control as a proxy
Start Traffic Control using the start-proxy.sh command

New - Traffic Control Support Blog

noreply@blogger.com (Phil Whelan) — Thu, 03 Jul 2008 19:53:00 +0000

If you're reading this then you've probably noticed that we've got a new blog on our website. This is a blog specifically for Traffic Control. We've got a great blog at http://blog.mailchannels.com, but there we're focusing mainly on non-MailChannels-specific things and discussing the anti-spam industry as a whole. In doing so, it has made it hard for us to talk about our own technology and the great things we are doing here at MailChannels with our core product, Traffic Control, without it seeming like a blog for self promotion.

Here we'll talk about installing Traffic Control, look at some key configurations, ideas for optimizations, and focus on statistics of throttling using Traffic Control. Please feel free to email us with any suggests you have for topics at tc-support@mailchannels.com