Here’s my next post in the series on application-generated email “Denial of Service Protection – Prevent Rouge SMTP Applications from Impacting your Production SMTP Channel“.
We’ve heard some truly horrifying stories about internal applications “going wild” and totally flooding entire SMTP application relaying channels with messages. The resultant flood of messages results in delayed mail and, in some cases, a chain reaction of other negative downstream side effects. For example, during a recent SMTP application relaying modernization project, one of the customer’s email administrators told me that a few weeks prior to our conversation one of their internal SMTP applications, “went wild” and sent out literally hundreds of thousand of messages to several internal employees. Eventually, the internal employees Exchange Mailboxes filled up, which then caused the entire Exchange Server to go off-line because it ran out of disk space, which caused a widespread production outage for employees who didn’t even receive the email messages in the first place.
The connection control component of Sendmail’s Sentrion Message Processing Engine is designed to prevent this type of problem from impacting your messaging infrastructure. It provides complete control over inbound and outbound email traffic by throttling trusted email or dropping abusive traffic. It collects broad statistics about the behavior of individual senders, sender reputation, sending hosts, and network address blocks, and enforces pre-defined limits. Based on the behavior or reputation of the connection, a range of actions are possible: permanently or temporarily reject; rate limit or throttle; or suspend. This scalable traffic shaping mechanism defends against a variety of attacks and unwanted email, as well as helps to smooth the flow of legitimate traffic.
Typically, within the context of an SMTP application modernization project, we work with customers in order to create a normal baseline for each of their internal SMTP applications. Meaning that during normal operations how many of each of the items listed below should the Sentrion appliance expect to see from each specific application:
- Number of different senders
- Number of different recipients
- Number of connections
- Number of messages (aka envelopes)
- Aggregate volume of mail
Generally, after this type of analysis in completed what we end up with are several application categories or groups. For example, low, medium and high volume applications, each with its own set of “normal” baseline operating parameters. Based on those figures, we can then configure individual Connection Control Classes to manage each group of applications. The purpose of each individual Class is to detect when an application deviates from its baseline and prevent it from adversely affecting the entire application relaying channel. A sample baseline and Sentrion Connection Control Class can be found below. Note that Classes can be setup to monitor one or more of the bulleted items listed above, the Class does not have to contain a baseline for each individual item.
- High Volume Application Baseline
- 100,000 messages per hour
- High Volume Flow Control Class Limit
- 175,000 messages per hour
(An increase of 75% when compared to the normal baseline)
In this example, any application that sends more than 175,000 messages in an hour will automatically be prevented from sending any additional messages for a period of 30 minutes. As a result of the restriction, the risk of a high volume email application flooding the channel with an excessive amount of mail messages, potentially causing an impact to the entire channel is eliminated.
Corporations cannot run the risk of allowing an internal rouge application from bringing down their entire SMTP application relaying channel. The downtime associated with these types of issues is costly and frustrating. Therefore, technology that has the capability to detect and prevent these types of production impacts, such as Sendmail’s Sentrion Message Processing Engine Connection Control component, is absolutely essential.
Please let me know if you’ve seen similar problems occur within your organization and if you were able to solve it as we do with Sentrion.