New Feature: Preserve Custom headers when using the SMTP service

You now have the option to preserve custom headers when relaying transactional email through relay.jangosmtp.net. To enable this option, go to Settings --> SMTP Relay, and check the Preserve Headers checkbox.



Enabling this option will preserve any custom headers that are a part of your email message. Prior to this feature, custom headers would be stripped off by the SMTP Relay before the email was delivered to the recipient. Now, if your email message includes custom headers or headers added on by an email client like:

X-MSMail-Priority
User-Agent

they will be included in the final email sent to the recipient. Additionally, if you have custom headers that help identify an email message in your internal system, such as:

X-CustomEmailID

those will also be preserved.

In the future, we'll be enabling an option such that you can set a particular custom header's value to show in Reports, allowing you to tie each individual sent email, open, and click back to your internal system's own identification mechanism.

How to separate transactional email into separate JangoSMTP accounts when sending from a single IP address

Over the year and a half since we launched JangoSMTP, we've had a handful of clients come to us with a unique setup request that we were unable to accommodate -- until now. We had some agency type users that were setting JangoSMTP up on behalf of their clients. They wanted to authenticate into the SMTP service by IP address, because their system didn't allow them to use SMTP AUTH. However, since they were coordinating transactional email on behalf of multiple clients, they wanted the different emails to go into different JangoSMTP accounts, even though all email would be sent from the same single IP address.

This is now possible with a custom header that will force JangoSMTP to assign an email to a particular account:

X-SMTPUsername: TheAccountUsername

If you include this header in each email message, then the message will be assigned to the JangoSMTP account with the username designated in the header, regardless of the IP address from which it is sent. The sending IP address would still need to be added to one of the JangoSMTP accounts, but it wouldn't matter which account.

For example, let's say you're a web development agency, and you have five clients, and you host all five of your clients' web sites on a shared server with a single IP address. You might create five JangoSMTP accounts with the usernames:

1. BrownieKitchen
2. CookieMonsterCo
3. PizzaFactory
4. ScoopOfCream
5. ChickenChaCha

You would add the IP of the shared web server to any one of the five accounts -- it doesn't matter which one. But, for each transactional email sent through the SMTP relay service, you would include the header:

X-SMTPUsername: PizzaFactory

to assign that email to the PizzaFactory account, for example.

Location metrics have been relocated within Reporting

To improve consistency and avoid confusion in a campaign's Reporting metrics, Geotracking Location data has been moved to display along with the Raw Data of a Campaign's Details reports. This data had previously been located along the different ways to group data (by Domain, by Sender, by Email Client, etc.), though it did not group by location.

Now, you will find the location data in the raw data report itself.

The additional columns showing Geotracking's Country Code, Region, City, Zip Code, ISP, Domain Name, Latitude, and Longitude are on the right.

New web service method to fetch SMTP log of transactional email

We've launched a new JangoSMTP API method to retrieve the SMTP log for a transactional email message. The method, Reports_GetSMTPLog_Transactional, is described in detail below.

Reports_GetSMTPLog_Transactional
Returns the SMTP log session for the specified transactional email message

The method takes, as input parameters, the JangoSMTP account username, password, and the numeric Transactional ID corresponding to the transactional email for which the SMTP Log should be retrieved. The method was designed around the Transactional ID rather than a recipient email address, since the Transactional ID will always be unique per individual transactional email message. With email addresses, there can be multiple transactional emails to the same address within an account.

Thet Transactional ID can be retrieved from the User Interface in Reporting, or via other API methods, like Reports_Transactional_GetRecipients_XML.

A sample output of Reports_GetSMTPLog_Transactional is shown below:


JangoSMTP is the only email service that offers access to SMTP logs for transactional email, and is now also the only service to do so through an API. The full API, including documentation and test forms, is at http://api.jangomail.com. The methods that apply to JangoSMTP are in the categories Transactional Sending and Transactional Reporting.

How replies are routed when you send a transactional email to an email-to-SMS gateway address

We recently had a JangoSMTP client report to us that when they used JangoSMTP to send an email message to an SMS-gateway address, that replies didn't go to the From Address. We investigated and found that transactional emails sent to SMS-gateway email addresses replies routed not to the From Address, but to the SMTP level MAIL-FROM used during the SMTP transaction.

The MAIL-FROM address is also known as the "envelope sender" or the "Return Path".

The MAIL-FROM address is a different part of the email message than the regular From Address which most recipients see. The MAIL-FROM address is used during the communication between two servers as an email message is sent. In our research we've found that the MAIL-FROM only ever receives replies if the email is sent to an SMS gateway email address.

To make sense of the technical details, it's easiest to look at an example. I use T-Mobile for my BlackBerry. My mobile number is 937-838-0921 (I've altered the number to protect my phone from ringing off the hook after this post.) Anyone can send me an SMS message by sending an email to 9378380921@tmomail.net. tmomail.net is the domain T-Mobile is using for their email-to-SMS gateway. If you send an email to 9378380921@tmomail.net, that email message generates an SMS to my BlackBerry.

[Above is an email message "from" ajay.goel@silicomm.com that generates the SMS]

[Above is the SMS message on my BlackBerry]

Let's examine the SMS message on my BlackBerry. Notice that the From Address of ajay.goel@silicomm.com shows in the message, but it's not the From Address of the message, because SMS messages don't have From Addresses. The sender of an SMS message is usually a mobile number or a short-code, but in this case, the sender is simply shown as 3662. The actual text of the SMS message is a concatenation of the various parts of my original email...specifically, the text of the SMS message is my email's From Address plus its Subject plus its Message.

Therefore replying to this text will not send an email to ajay.goel@silicomm.com. It sends it to a T-Mobile system, identified by the number 3662.



T-Mobile receives the reply and then sends an email, but where will T-Mobile send this email? One would guess that the reply would be routed to the From Address of the original email (ajay.goel@silicomm.com), but in fact the reply is routed to the MAIL-FROM of the original email (ajay.goel@jangomail.com). In this case, "ajay.goel" is the username of the JangoSMTP account used to send the email, which is why the MAIL-FROM is ajay.goel@jangomail.com.

The MAIL-FROM address is shown in the SMTP log of the original email message:



Why do replies to text messages work this way?

We don't know exactly, and our research into how SMS works hasn't provided any answers. We've verified that replies work this way on both T-Mobile's and AT&T's networks. Our best guess is that mobile phone companies all use the same software to translate email messages into text messages, and during the transmission of the email to the SMS gateway, the first address seen is captured and stored as the reply address. Since an actual SMS message doesn't have a property for a return email address, the mobile network must store the reply address on its end, outside of what the mobile phone user sees, and then associate that reply address with the SMS user's response to the 4-digit sender code (3662 in the above example). The first address that's seen is the MAIL-FROM address during the initial SMTP communication, and therefore that becomes the reply address that the mobile company uses.

What happens when an email is sent to your-username@jangomail.com?

JangoSMTP is intelligent enough to receive the email sent to your-username@jangomail.com, identify the email as a legitimate reply to your message, and then forward the message to an email address of your choosing. Any legitimate reply email messages sent to a MAIL-FROM address that is controlled by JangoSMTP, such as any @jangomail.com addresses, are then forwarded to the address that you used when you first created your JangoSMTP account. This can be changed by contacting our Support team. In the future, this will be a configurable parameter under Settings.

How JangoSMTP sets the MAIL-FROM address

By default, the MAIL-FROM address is your JangoSMTP account username followed by @jangomail.com. So if your username is "browniekichen" your default MAIL-FROM address is browniekitchen@jangomail.com.

Even if you set your actual From Address on your transactional email to joe@browniekitchen.com, the MAIL-FROM will be browniekitchen@jangomail.com. It is set this way to ensure SPF/SenderID compliance and to allow for automated bounce processing.

However, JangoSMTP does allow you to override the default and take control the MAIL-FROM address. There are two methods to accomplish this, and they are both explained in step 1 of the post on optimizing transactional email deliverability.

Both methods provide for better deliverability than the default option.

Resources:

Wikipedia's list of email-to-SMS gateways
Wikipedia article on the MAIL-FROM address
JangoSMTP Support