Delivery Rule Overrides

Delivery rule overrides enable you to globally override all delivery rules for an account. For example, if you wanted to change the throttling for an account to 50 messages per hour, per domain, per IP, you can do it here.

Each delivery rule override gets overlaid on top of any existing delivery rules that would otherwise apply.

Sender and Receiver Control

It is now possible to independently control an accounts ability to accept new mail and/or to send mail already in queue.

New Bounce Processing Engine

Under the hood is an entirely new bounce processing engine that is much more efficient and customizable than ever before. For most users this will be completely transparent, but for those of you who like to dive deep into bounce data, all of our bounces are categorized by codes now. The following KB article explains it more: http://www.socketlabs.com/78

Restarts on Config Changes Minimized
We have optimized the internals so that far fewer restarts are required when making configuration changes.

If you have an up to date support contract and you would like to upgrade, with just a click you can easily grab the new builds, with these new features by using the built in Update option included with Hurricane MTA Server.

Hurricane MTA Server is more important to us than ever now, since we are using it to power our SocketLabs Email On-Demand solution. This has led to several innovations and improvements in Hurricane MTA Server. Lately we have been working under-the-hood, strengthening the foundation of Hurricane MTA Server for future growth and leverage.

The latest production release of Hurricane MTA Server was pushed out quietly earlier this month but contained some really big improvements including:

• Support for running natively in 64-bit mode now allows Hurricane MTA Server access to much more RAM, increasing performance dramatically.
• Fully upgraded the backend statistical database to further increase its performance and scalability.
• Totally replaced the internals of the bounce and failure processing and analysis to provide much more accurate and specific bounce and failure codes.

Each of these items were a massive undertaking for us in their own right and we have been working on them for over a year. It is really great to finally see them come to fruition.

Follow John Alessi on Twitter: @johnalessi

The latest production release of Hurricane MTA Server adds powerful automatic suppression lists that boost your deliverability and protect your reputation by automatically blocking repeat emails to invalid addresses and email addresses that have filed complaints against you. This incredibly intelligent and automatic feature is out of beta and currently in production.

See this article for more information.

More Powerful IP Based Authentication and Account Mapping

Now, any account can be selected and authenticated by the source IP address. Simply edit the IP whitelist and add the account id to the end of the IP address separated by a pipe.

For example if you wanted all email coming from 66.72.15.29 to go through account 1024, you would enter the following entry in the whitelist:

66.72.15.29|1024

Critical Alerts

System alerts are now broken out into two levels: critical and standard. Critical and standard alerts can be sent to different email address lists, making it easy to escalate critical issues.

The alert level of each Dynamic Block Rule can now be set to standard or critical.

fbl-test@service.socketlabs.com
Auto responds to From address with a feedback loop report in ARF format.

bounce-test@service.socketlabs.com
Auto responds to the Return-Path with a bounce message.

As a side note, the autoresponder was built using the .Net API in Hurricane MTA Server.

First, now our new Dynamic Block Rules are a part of the Smart Delivery Rules. Now, protecting your reputation is automatic. You can read more about Dynamic Block Rules here.

Second, Smart Delivery Rules can now be updated easily from within the Hurricane MTA Server interface without having to update the entire application.

The Administrative configuration page has a new option to download and apply the latest set of Smart Delivery Rules directly from our database.

With these two enhancements it is now easier than ever to leave things up to us and still be assured of the highest deliverability possible. Enjoy!

Dynamic Block Rules are a new part of Hurricane MTA Server’s Delivery Rule system. Hurricane MTA Server’s Delivery Rules enable traffic shaping to specific ISPs. The new Dynamic Block Rules are a subset of a Delivery Rule. The Dynamic Block Rule system scans ISP responses for known codes and text which indicate that the ISP wants you to pause sending them email. The Dynamic Block System then automatically pauses delivery to that ISP for the time period setup in the block rule.

Multiple Dynamic Block Rules may be specified for each Delivery Rule and they are evaluated in the order of their priority, top-down, until a match is made, in which event that rule is activated. Only one rule can ever be active at one time. Each time a Dynamic Block Rule is activated, a Delivery Alert will be posted to the Hurricane MTA Server alert system. There is also a Dynamic Block Rule option to “Only Alert” without pausing delivery.
Each rule consists of the following pieces of information:

So what are some of the reasons why an ISP would want you to stop delivering mail? This could be the result of sending too much mail per hour, receiving too many complaints about your email, trying to deliver to bad email addresses or various other reasons. The important thing is that the ISP wants you to pause sending and failure to do so can damage your reputation.

The Dynamic Block Rule system is a part of the latest release of Hurricane MTA Server. There is also a new Dynamic Block Rule log file that can be enabled via the log settings for each account. A future post will outline that log file and show you how it can be used to analyze the effectiveness of your Dynamic Block Rules and and fine tune them to obtain the highest deliverability possible.

Within the next month we will incorporate block rules into Hurricane MTA Server’s Smart Delivery Rule list. Smart Delivery Rules are a set of Delivery Rules defined and periodically updated by SocketLabs to properly shape traffic to the large ISPs.

Until then, you can try your hand at creating your own Dynamic Block Rules to get a feel for how the system works.

Tuesday July 14th 4PM EDT (click here to register)
Tuesday July 21st 9AM EDT (click here to register)
Wednesday July 29th 2PM EDT click here to register)

Space is limited, so please reserve your seat now.

This has not been an easy task in the past, but with the new features in Hurricane MTA Server it just became a whole lot easier. Hurricane MTA Server is now capable of intercepting feedback loop report messages from ISPs, which it will automatically analyze and process. The results of the analysis of each feedback loop report received are logged, passed to a new plugin API event and also included on the brand new built-in feedback loop report.

Feedback Loop Report

A new plugin API event (courtesy of the new IDynamic plugin interface) can also be handled to push the results right out to your own databases in real-time.

Hurricane MTA Server has the ability to process feedback loop reports that are in the Abuse Feedback Reporting Format (ARF) such as Aol, Yahoo, Comcast and others as well as non ARF feedback loop reports from Hotmail and MSN.

Feedback loop reports are specific to each ISP so you must sign up with each ISP separately. Normally you are required to fill out a form on each ISP’s web site proving that you are the owner of the IP addresses you wish to monitor and providing an email address to send the reports to. Once your feedback loop is setup with the ISP, you must configure Hurricane MTA Server to accept and process the messages.

The email address you choose must have its mail exchange set to the IP of your Hurricane MTA Server and Hurricane MTA Server must be configured with the same address so that it knows to accept the messages. Feedback loops are configured in Hurricane MTA Server in the new FBL tab of the account settings. Once setup correctly Hurricane MTA Server will start accepting the reports and parsing them.

Feedback loop configuration is per account.

When feedback loops are processed the results can also be put into a feedback loop log file (enabled in account log file settings) or processed by your code in real time with the new feedback loop plugin API event

See our list of feedback loop signup links.

Good luck!

These “pre-casted” event methods are easy to use, but unfortunately they are pretty much immutable. Due to the limitations imposed by the architecture of .Net we can not extend these methods or interfaces without breaking the original interface and forfeiting its backwards compatibility – and the backwards compatibility of the Hurricane MTA Server plugins you have developed.

Our answer to this is the new IDynamic plugin interface. Unlike the other interfaces supported by the Hurricane MTA Server plugin API, the IDynamic interface contains only one method, OnDynamicEvent().

object OnDynamicEvent(DynamicEventId eventId, ref Dictionary eventParams)

OnDynamicEvent() and its parameters are generic. Hurricane MTA Server can trigger this method for any type of event, which it identifies by the eventId parameter and can pass an unlimited number of parameters via the eventParams dictionary object.

Additionally since eventParams is passed by reference, plugins can add to or modify the values it contains as a way of instructing Hurricane MTA Server to do something differently. The return value of OnDynamicEvent is an object type which further enables plugins to return rich information to Hurricane MTA Server where applicable.

Lets take a look at a simple implementation of the IDynamic interface.

public class Feedbackloop : PluginBase, IDynamic
{
     public object OnDynamicEvent(DynamicEventId eventId, ref Dictionary eventParams)
     {
         if (eventId == DynamicEventId.Init)
         {
             eventParams["OnFirstConnection"] = 1;
         }
         if (eventId == DynamicEventId.OnFirstConnection)
         {
             //do work here to handle OnFirstConnection event
         }
         return null;
    }
}

The first thing you will notice is that since the OnDynamicEvent() method can be called for any number of events, we are checking the eventId parameter to see which event is actually being fired.

One event that we must handle in every OnDymanicEvent() implementation is Init. OnDynamicEvent() will be called with the eventId parameter set to DynamicEventId.Init the first time OnDynamicEvent() is called after the plugin is loaded. The Init event must be handled to instruct Hurricane MTA Server to call OnDynamicEvent() for other events that you want to handle. This is for performance as it would not be efficient for Hurricane MTA Server to call OnDynamicEvent() for every event it supports, even if you are not building a handler for it.

When the Init event is fired, eventParams will contain an item for each of the events supported by OnDynamicEvent(). You must handle the Init event and set the value to 1 for each event you want fired.

In the above example we are setting the value of the eventParams dictionary item OnFirstConnection to 1, to indicate that we are going to handle the OnFirstConnection event. OnFirstConnection is an event that is fired just before a new connection is made to an ISP.

             eventParams["OnFirstConnection"] = 1;

This is how we tell Hurricane MTA Server to fire OnDynamicEvent(). Below is another way of doing the same thing. It is not as clean looking but is more error proof because the event identifier is being taken from a predefined enumeration.

             eventParams[DynamicEventId.OnFirstConnection.ToString()] = 1;

Lets expand the sample with some more code that will actually do something each time the OnFirstConnection event is fired. First, I need to tell you a bit more about the OnFirstConnection event.

OnFirstConnection is called when a connection is about to be made to an ISP. The eventParams parameter will contain the following items:

By handling the OnFirstConnection event, we can modify the DeliveryRule dictionary object, changing the delivery rule for this ISP in real time.

public class Feedbackloop : PluginBase, IDynamic
{
     public object OnDynamicEvent(DynamicEventId eventId, ref Dictionary eventParams)
     {
         //Tell the system we only want to get feedback loop events.
         if (eventId == DynamicEventId.Init)
         {
             eventParams["OnFirstConnection"] = 1;
         }
         if (eventId == DynamicEventId.OnFirstConnection)
         {
             if (someConditionExists)
             {
                 StringDictionary rule = eventParams["DeliveryRule"];
                 rule["Action"]="Defer";
             }
         }
         return null;
     }
}

In this example, if the variable someConditionExists evaluates to true, then we set the delivery rule action to “Defer”. This changes the delivery rule in the Hurricane MTA Server process to defer all email which is subject to this delivery rule until the action is changed back to “Normal”. Keep in mind that this only affects the delivery rule in memory and not the value in the configuration file for this rule. That means that restarting the server will cause the action to revert back to the value in the config file (since the config file is reloaded when the server starts), which is in most cases “Normal”.

So, you might be asking, why would I want to write a plugin to change a delivery rule’s action to “Defer”? Well one reason would be if you wanted to write some code to monitor the responses you receive from ISPs and change your delivery rules based on those responses. For example you could also handle the OnFail event to monitor the responses and then keep some state as to how you want to change the delivery rule for that ISP the next time a connection attempt is made. If an ISP response indicated that you were being blocked, you might want to automatically start deferring email to that ISP. By coding this way you can add your own strategic logic to the delivery process. Not all of our customers get this involved with the API, but a few power users do – and exploit it to great benefits.

The IDynamic interface is a part of the current SDK which is included in the latest production version of Hurricane MTA Server released in June 09. Its documentation and samples can be found in the plugins directory of your Hurricane MTA Server installation.

The following code illustrates how the event can be handled by your code. If you have not read about the new IDynamic plugin API interface yet I would suggest that you do because it contains the basic information on the OnDynamicEvent() method which is used to fire the feedback loop events.

public class Feedbackloop : PluginBase, IDynamic
{

     public object OnDynamicEvent(DynamicEventId eventId, ref Dictionary eventParams)
     {
         //Tell the system we only want to get feedback loop events
         if (eventId == DynamicEventId.Init)
         {
             eventParams[DynamicEventId.OnFeedbackLoopParsed.ToString()] = 1;
         }
         //Handle feedback loop event
         if (eventId == DynamicEventId.OnFeedbackLoopParsed)
         {
             string OrignalRecipient = eventParams["OriginalRecipient"].ToString();
             string OrignalMessageId = eventParams["SystemMessageID"].ToString();
             string CustomMailingID = eventParams["CustomMailingID"].ToString();
             string CustomMessageID = eventParams["CustomMessageID"].ToString();
             string UserAgent = eventParams["User-Agent"].ToString();
             string Type = eventParams["Type"].ToString();

             /// To-do: Do database work to unsubscribe user.

         }
         return null;
     }

}

Also, in cash you missed it, find out all the info on the new feedback loop processing and reporting in Hurricane MTA Server.