One of the important things I’ve learned in my nine years at Message Systems is that many of the people who work for ESPs and MSPs are very savvy technologists. We’ve been lucky to work with many of the smartest email industry veterans out there, and some have even come to work with us here. When I get a chance to chat with these technologists, I often ask them for a reality check: How much time did they spend in their previous companies developing technology that they now know Message Systems already has in place, and deploys with its core platform?

The answer is typically prefaced by the remark, “We thought Message Systems was too expensive and too complicated,” followed by: “Without the programmable policy engine included in the Momentum platform, everything else we did required development, which meant diverting precious resources away from our ESP core competency.” Indeed, without a programmable policy engine, activities like bounce/FBL processing need to be handled by routing messages to another application server, and it’s up to the operator to develop and maintain the processing systems. This typically means the operator has several developers dedicated to these external applications.

The Ongoing Value of Programmable Policy Engine

When it comes to managing deliverability, competing MTAs have, at best 20%, of the solution provided by Momentum’s Adaptive Delivery® modules.  Some solutions will stop traffic when certain temp fail messages are received, but have no concept of bounce or FBL rates. Without these capabilities, the operator is missing key indicators of potential trouble.  When an elevated FBL complaint rate eventually triggers a block from the receiver, the damage to the sender’s reputation is already done. The operator will spend excessive time and expense resolving the block.

While some solutions stop traffic based on temp fail messages, they do not restart traffic automatically. The operator must do this manually or develop yet another external application to manage traffic.  When you are managing traffic for hundreds or even thousands of senders, this kind of work can become a full-time job for one or more administrators. Message Systems, conversely, provides all the required logic developed by deliverability professionals based on the collective experience of our customer base. As such, our solutions free up resources in two areas: 1) cutting down on core application development, and 2) relieving deliverability specialists of many of the manual tasks required to maintain steady operation on commodity email servers. Taken together, these attributes within Momentum enable operations teams and deliverability teams to now focus on areas like message contentment, engagement strategies and sending best practices.

IP Warm-up is also very challenging: other solutions may provide a limit setting for traffic from a new IP. This single limit is enforced on each domain, and the setting must be adjusted manually for each IP address on a regular basis to ramp up volume. It’s up to the ESP to decide whether to develop yet another app to automate the process and then determine the ramp-up strategy.

Many of the technology decision-makers we work with in the ESP space look to pure performance metrics to guide buying decisions when it comes to messaging infrastructure. Yet simple performance tests are barely adequate to really drive understanding of what can be achieved using a messaging application server solution with programmable policy engine. Lower-priced MTA offerings might be able to provide performance approaching that of the most advanced commercial offerings like Momentum, but ongoing development and operational costs are where you’re going to see value from lower costs year over year into the future. And on that basis, a programmable policy engine is very valuable indeed.

About The Author: Kim Matz is VP of enterprise sales, US East at Message Systems. An experienced technology industry executive, Kim heads up Message Systems’ email services provider practice, working with many of the largest ESPs in North America. Kim writes frequently on issues and trends in the ESP space. 

In this whitepaper, email expert Len Shneyder introduces Message Systems Adaptive Delivery – The first solution of its kind specifically designed to automate the monitoring of bounces and complaints, and adjust connection rates and throughput accordingly. 

Adaptive Delivery Whitepaper

Starting with Momentum Version 3.0, Message Systems has included an embedded copy of the Lua language in the bundle as a replacement for Sieve. For years Message Systems customers used Sieve as a policy engine to script actions based on message details, but Sieve, even in its modified Sieve++ form, is limited. Lua is a big improvement, offering the ability to iterate over data and work with tables, among other features. Just like Sieve, we have modified our embedded version of Lua to extend its functionality in numerous ways.

Not surprisingly, Lua has a large following in the programming world. It’s a well-developed, multi-purpose language that is often used by game developers for its simplicity and speed, as well as its inherent ability to expose and use C modules as well as its own native scripting. In Momentum, Lua has been extended with a number of local functions specifically to help with messaging rules. Aside from the extensive documentation on our custom functions, there is also a whole community of Lua users and developers on the web (links at the end of the article).

You will see in the sample below that the code itself is quite simple to follow, and anyone who has written a policy script in Sieve will see this as manna from heaven. So what does Lua look like in Momentum? I can show you using a very basic policy script that will assign messages to a binding based on an X-Header value. Here is the heavily commented policy script:

— This policy script is a common, but very simple example
–[[
You can use comments in Lua with a “–” for a single line or multi-line comments can be framed as this one is.
]]–
— As with many languages, you can “require” helper modules
— We have developed dozens of helpers that make message management easier

require(“msys.core”)
require(‘msys.extended.message’);

— We define the following variable as “local” and make it a “table” using braces
— IE: the variable “mod” is a local table

local mod = {};

— We have predefined function names for each message phase.
— This one is active specifically in the set_binding phase.

function mod:validate_set_binding(msg)

— getting the value of the X-Binding header is this easy:

local mybinding = msg:header(“X-Binding” );

— Assigning a binding of the same name as the header is just as easy:

local err = msg:binding(mybinding);

— proper etiquette requires us to “end” the function

end;

— and finally we register the script so Momentum can use it.

msys.registerModule(“policy”, mod);

Toggle Comments »

Enabling the script to run with Momentum just requires adding a reference to the ecelerity.conf file:

scriptlet scriptlet {
script policy {
source = “/opt/msys/ecelerity/etc/conf/default/lua/policy.lua”
}
}

That is all there is to it. This is a very basic example but is probably the most common use of scripting in Momentum. Our clients have installed some extremely complex functionality with Lua including auto-responders, message cadence (recipient fatigue) protection and automated database list hygiene systems. If you do a little research you will find that Lua is embedded or core to many popular pieces of familiar code including Angry Birds, Civilization V, World of Warcraft, Far Cry, Fall Out, the Sputnik wiki engine, and the CISCO Adaptive Security Appliance. We are not alone in thinking Lua is awesome.

If you’re interested in gaining a better understanding of the Lua language, I recommend the book Programming in Lua, Second Edition by Roberto Ierusalimschy — A.K.A. the Lua Bible. There’s also a ton of links on the Internet, and I’ve listed a few of them below. By the way Lua is a proper name, and is not an acronym. Portuguese for “moon,” Lua was originally developed by a team at the Pontifical Catholic University of Rio de Janeiro in Brazil.

Tom Mairs
Manager, Enterprise Sales Engineering, Americas
tom.mairs@messagesystems.com