I am very excited to announce that our new suppression list feature is currently in beta. This new feature goes way beyond what is normally thought of when we think of suppression lists. Typically, suppression lists are used to prevent future mailings to addresses that have unsubscribed. Our suppression lists can do that, but also much, much more. Please read on…

This feature will skyrocket your deliverability, and cut loads of administrative work out of the process.

It Will Dramatically Increase Deliverability

How will it increase deliverability? Because, in addition to giving you the ability to specify and block addresses which have unsubscribed, this new functionality will:

• Automatically block email to addresses which have previously hard bounced
• Automatically block email to any recipient which has previously complained about one of your mailings

Two things which will kill your deliverability are 1) repeatedly sending to invalid addresses and 2) sending to people who have complained about your email. Imagine how deliverability will soar when Hurricane MTA Server takes charge and ensures that neither of these things will ever happen again!

This is really monumental release for us because it is the cumulation of so many things we have worked towards over the years. We have had cutting edge bounce handling in Hurricane MTA Server for years. (btw, it is going to get even better soon, but you did not hear that from me) Earlier this year we rolled out automatic feedback loop report processing. Now the new suppression list feature harnesses the power of the bounce processing and feedback loop handling to protect your reputation and catapult your deliverability to new heights.

By maintaing lists of all hard bounce addresses, and addresses associated with feedback loop complaints, Hurricane MTA Server can automatically suppress redelivery to those same addresses.

It Will Reduce Development and Administration

How will it reduce development and administration? Because…

It will no longer be necessary for you to do your own list hygiene – Hurricane MTA Server will do it for you – automatically, and accurately.

That is right. This is fully automatic suppression lists on steroids!

Suppression lists can be set at the account level, globally, shared between accounts, etc… It is all very flexible and very automatic. Suppression lists are stored as standard CSV files, so it is easy to interface them with your existing data. Our suppression lists support both plain text and MD5 encoded addresses for extra security.

This new feature is currently available in our latest beta build.

If you are a SocketLabs customer, and would like to participate in our beta program, please log into your support console and create a ticket, requesting beta access.

If you are not a SocketLabs customer, but would like to be, please contact us to discuss it.

Be sure to check out the video above for a walkthrough.

Now there is a great resource for most of the known bounce codes to help simplify your tracking and processing. The eec’s Deliverability Roundtable has put together a repository of common and available bounce strings senders might see from current ISPs (email receivers).

The forum is setup on Get Satisfaction as a dynamic and interactive site that allows users to request information and update bounce strings as they change. The ISP serving the bounce, the bounce string text and next steps for a sender are written out by bounce code here.

http://www.getsatisfaction.com/deliverability/tags/bounce_codes

Return Path did not state where they believe the email to be, but we suspect that it is floating in deep space, possibly captured in the crystal prison of the three Krypton prisoners from Superman.

Some other notable points from the study:

• It is easier to deliver to US ISPs than Canadian ISPs. Inbox placements of mail sent to US ISPs was 82% in contrast to 75% sent to Canadian ISPs.
• B2B delivery rates are less than that of B2C email 72% vs 79%. This is in strong opposition to what has normally believed to be the case. Accounting for this is the fact that businesses are being protected by ever advancing systems like Postini, Synamtec and MessageLabs.
• In the US, Gmail is the hardest ISP to penetrate and Cox is the easiest.
• In Canada, Primus.ca was the hardest ISP to penetrate and Telus was the easiest.

I encourage you to download the full study, which is brief but very informative, and includes colorful charts and graphs:

Return Path Deliverability Benchmark Report

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.