Direct From The MailChannels Labs : Plesk Installer Of Traffic Control

Installing Traffic Control For Plesk from MailChannels Corporation on Vimeo.

The Architecture Of Traffic Control 3.1

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

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

to

  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!

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?

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

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

• Traffic Control Introduction
• A Quick Start Guide
• Traffic Control Configuration
• Understanding Traffic Control Logging

Less Configuration = More Time For Beer

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.