Technical Discussion of How Social Networking Sites Send Transactional Email

Shortly after JangoMail launched its own transactional email platform, we took on a flood of new clients with a need to send "social networking" type transactional emails, including "You have a new message" notifications and "You have a new friend request" notifications. Then we launched our SMTP relay for email marketers, and the floodgates ripped off.

We're often asked what the best practices are from a technical standpoint, with respect to issues like Content, From Addressing, DomainKeys and DKIM, and SPF/SenderID. Should the content of a message sent from one member to another be included in the email notification, or should the recipient have to log in to the site to read the message? Should a "friend request" email come "from" the friend or "from" the social networking site? Should the email contain Plain Text, or HTML, or both? To best answer these questions, I've analyzed transactional email from the most notable social networking sites -- Facebook, LinkedIn, Friendster, and MySpace. Note that this is an article about the technical aspects of sending transactional email. If you're looking for an article on transactional email strategy (what to send, how often, to whom...), then you won't find that here, but you can in many other places.

The following are the properties of each social networking site's email that I will analyze:

1. Presence of a DomainKeys header.
2. Presence of a DKIM header.
3. Sender Policy Framework (SPF) compliant email.
4. The From Address
5. The From Display Name
6. The SMTP MAIL-FROM Address used in the SMTP transaction
7. The Sender header, if present
8. The Reply-To header, if present
9. Use of a unique identifier in the SMTP MAIL-FROM address
10. The content, particularly whether a friend's message is present in the Email Body, or whether the user must log in to read the message.
11. The use of HTML versus Plain Text MIME parts.

Let's get started with the biggest social network of all, Facebook:

Facebook:

When somebody sends me a message on Facebook, I get an email notification with the Subject line:

"Mary Parker sent you a message on Facebook..."

The Body of the email contains the actual message, which is convenient, because it prevents me from having to log in to Facebook to read the message.

From Address: notification+mummiv~d@facebookmail.com
Reply-To: noreply@facebookmail.com
From Name: Facebook
DKIM-Signature: v=1; a=rsa-sha1; d=facebookmail.com; s=q1-2009b; c=relaxed/relaxed;q=dns/txt; i=@facebookmail.com; t=1253415012;h=From:Subject:Date:To:MIME-Version:Content-Type;bh=fLwGefDfPrLKUK2vwWzaC5k5iNo=;b=DfJugajI0Fsc5FIppBQSfSAAiV+WuK1ugzc00USpIkJku3sUgcupO+TPua0Tcxw7qJDUE0yRohPMWz3jPwPfRA==;

A DKIM-Signature header for facebookmail.com is present, but it is noteworthy that a DomainKey-Signature header is not present.

The SMTP MAIL-FROM address is: notification+mummiv~d@facebookmail.com

Facebook Transactional Email SMTP Log:

69.63.178.170 [03A4] 22:50:13 Connected
69.63.178.170 [03A4] 22:50:13 >>> 220 mail.silicomm.com ESMTP IceWarp 9.1.0; Sat, 19 Sep 2009 22:50:13 -0400
69.63.178.170 [03A4] 22:50:13 <<< EHLO mx-out.facebook.com
69.63.178.170 [03A4] 22:50:13 >>> 250-mail.silicomm.com Hello mx-out.facebook.com [69.63.178.170], pleased to meet you.
69.63.178.170 [03A4] 22:50:13 <<< MAIL FROM:<notification+mummiv~d@facebookmail.com>
69.63.178.170 [03A4] 22:50:13 >>> 250 2.1.0 <notification+mummiv~d@facebookmail.com>... Sender ok
69.63.178.170 [03A4] 22:50:13 <<< RCPT TO:<AjayGoel@silicomm.com>
69.63.178.170 [03A4] 22:50:13 >>> 250 2.1.5 <AjayGoel@silicomm.com>... Recipient ok
69.63.178.170 [03A4] 22:50:13 <<< DATA
69.63.178.170 [03A4] 22:50:13 >>> 354 Enter mail, end with "." on a line by itself
69.63.178.170 [03A4] 22:50:13 *** <notification+mummiv~d@facebookmail.com> <ajay@us.jangomail.com> 1 2021 00:00:00 OK BLS56313
69.63.178.170 [03A4] 22:50:13 >>> 250 2.6.0 2021 bytes received in 00:00:00; Message id BLS56313 accepted for delivery

The SPF record for facebookmail.com is:

"v=spf1 mx ip4:204.15.20.0/22 ip4:69.63.176.0/20 -all"

The connecting IP is 69.63.178.170, which is a part of the "ip4:69.63.176.0/20" directive and therefore this IP is SPF-valid for sending email "FROM" facebookmail.com.

Noteworthy Points:

1. It's excellent that Facebook is employing both SPF and DKIM.
2. The email lacks a DomainKey-Signature header for backwards compatibility for receiving systems that might not be DKIM-compliant yet.
3. The email is from "Facebook" and not my friend "Mary Parker". This is likely to prevent people from attempting to reply to the email as a way of writing back to "Mary Parker". The only way to reply to the message is to login to Facebook and use their internal messaging system.
4. Facebook's transactional emails come from the domain facebookmail.com rather than the more recognizable facebook.com. This is perhaps to separate email reputation from their actual high-value business domain facebook.com. That way, should their emails be treated as spam by a network, the domain name facebookmail.com will be punished, not facebook.com.
5. The X-Mailer header of the email is:
   
   X-Mailer: ZuckMail [version 1.00]
   
   Presumably, ZuckMail is an email system written by, or an homage to, Facebook's founder Mark Zuckerberg.

LinkedIn:

LinkedIn sends transactional email differently than Facebook. While Facebook "friend request" email comes from "Facebook" and a no-reply facebookmail.com email address, LinkedIn's "Join my network" emails usually come "From" the person trying to add you.

The relevant headers from a LinkedIn transactional email are below:

DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns; h=Sender:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type:X-LinkedIn-fbl;b=KQVq9LfSNIZ+6tOuz7xUaUW1wx86f62EndMqyY+bbkmI8jHQDNe8HdtW ZfJsxH50d8nvAnQHryCdQKGfBEY0u2t5sXkrRmf7yCAhhg4Q9aqBo20KZ LSUvTK726opFnO0;
Sender: messages-noreply@bounce.linkedin.com
From: "Mary Parker" <maryparker@hotmail.com>
To: Ajay Goel <AjayGoel@silicomm.com>

Note that the the From Name is my friend "Mary Parker" and the From Address is Mary's email address, maryparker@hotmail.com. Because no Reply-To header is present, clicking "Reply" on my email client will auto-address the message to the From Address, maryparker@hotmail.com.

From an authentication perspective, it's interesting that the LinkedIn transactional email contains the DomainKey-Signature header, but not the more modern DKIM-Signature header. JangoMail transactional emails contain both the DomainKey-Signature and the DKIM-Signature headers, for the highest level of compatibility with all receiving email systems.

LinkedIn Transactional Email SMTP Log:

64.74.98.137 [057C] 12:16:54 Connected
64.74.98.137 [057C] 12:16:54 >>> 220 mail.silicomm.com ESMTP IceWarp 9.1.0; Thu, 03 Sep 2009 12:16:54 -0400
64.74.98.137 [057C] 12:16:54 <<< EHLO mail15-a-aa.linkedin.com
64.74.98.137 [057C] 12:16:54 >>> 250-mail.silicomm.com Hello mail15-a-aa.linkedin.com [64.74.98.137], pleased to meet you.
64.74.98.137 [057C] 12:16:54 <<< MAIL FROM:<s-vEJ2DMWLs51nh5KhMMSL430pk-MMh3YJi-KV_N5M-Qy28fihJyfjtc@bounce.linkedin.com> SIZE=3706
64.74.98.137 [057C] 12:16:54 >>> 250 2.1.0 <s-vEJ2DMWLs51nh5KhMMSL430pk-MMh3YJi-KV_N5M-Qy28fihJyfjtc@bounce.linkedin.com>... Sender ok
64.74.98.137 [057C] 12:16:54 <<< RCPT TO:<AjayGoel@silicomm.com>
64.74.98.137 [057C] 12:16:54 >>> 250 2.1.5 <AjayGoel@silicomm.com>... Recipient ok
64.74.98.137 [057C] 12:16:54 <<< DATA
64.74.98.137 [057C] 12:16:54 >>> 354 Enter mail, end with "." on a line by itself
64.74.98.137 [057C] 12:16:54 *** <s-vEJ2DMWLs51nh5KhMMSL430pk-MMh3YJi-KV_N5M-Qy28fihJyfjtc@bounce.linkedin.com> <AjayGoel@silicomm.com> 1 4048 00:00:00 OK KZT46754
64.74.98.137 [057C] 12:16:54 >>> 250 2.6.0 4048 bytes received in 00:00:00; Message id KZT46754 accepted for delivery

Noteworthy Points:

1. 1. The SMTP MAIL-FROM address is a string of characters followed by @bounce.linkedin.com. LinkedIn is using a sub-domain of its high-value business domain, linkedin.com. JangoMail also offers the option to setup a sub-domain based off your corporate domain name. The string of randomly generated characters is presumably to track any bounce that occurs as a result of this particular transactional email. If the silicomm.com MTA sends a notification back to s-vEJ2DMWLs51nh5KhMMSL430pk-MMh3YJi-KV_N5M-Qy28fihJyfjtc@bounce.linkedin.com, the LinkedIn system will be able to immediately tie the identifier present in that email address and use that information to immediately notify Mary Parker that the email to me bounced. JangoMail also handles bounces to transactional emails, but with a unique identifier in the X-VConfig header of the message as opposed to within the MAIL-FROM address itself. Both options are legitimate for tracking bounces.
2. The SPF record for bounce.linkedin.com is:
   
   "v=spf1 redirect=linkedin.com"
   
   The redirect directive then tells us to look up the SPF record for linkedin.com, which is:
   
   "v=spf1 ip4:70.42.142.0/24 ip4:208.111.172.0/24 ip4:64.74.220.0/24 ip4:64.74.221.0/26 ip4:64.71.153.211 ip4:64.74.221.30 ip4:69.28.149.0/24 ip4:208.111.169.128/26 ip4:64.74.98.128/26 ip4:64.74.98.16/29 mx ~all"
   
   The sending IP 64.74.98.137 is covered by the "ip4:64.74.98.128/26" designation, therefore this email passes the SPF test.
3. Emails with subject line "Invitation to connect on LinkedIn" always has the user's information as the From Name / From Address.
4. Emails with subject line "Join my network on LinkedIn" sometimes have the From Name / From Address of the user, but other times From Name is "Mary Parker (LinkedIn Invitations)" and From Address is invitations@linkedin.com.
   
   I have been unable to determine the reason for the ambiguity with the "Join my network on LinkedIn" emails.

Friendster:

The following are the relevant headers from a Friendster "new message" notification:

From: Friendster <message-2219486617@mail.friendster.com>
Subject: New Friendster Message from Vikki - 09/07/09 10:17 PM
To: AjayGoel@silicomm.com

Friendster Transactional Email SMTP Log:

209.11.169.65 [03A4] 01:17:58 Connected
209.11.169.65 [03A4] 01:17:58 >>> 220 mail.silicomm.com ESMTP IceWarp 9.1.0; Tue, 08 Sep 2009 01:17:58 -0400
209.11.169.65 [03A4] 01:17:58 <<< EHLO c350a-5.friendster.com
209.11.169.65 [03A4] 01:17:58 >>> 250-mail.silicomm.com Hello c350a-5.friendster.com [209.11.169.65], pleased to meet you.
209.11.169.65 [03A4] 01:17:58 <<< MAIL FROM:<message-2219486617@mail.friendster.com> SIZE=9837
209.11.169.65 [03A4] 01:17:58 >>> 250 2.1.0 <message-2219486617@mail.friendster.com>... Sender ok
209.11.169.65 [03A4] 01:17:58 <<< RCPT TO:<AjayGoel@silicomm.com>
209.11.169.65 [03A4] 01:17:58 >>> 250 2.1.5 <AjayGoel@silicomm.com>... Recipient ok
209.11.169.65 [03A4] 01:17:58 <<< DATA
209.11.169.65 [03A4] 01:17:58 >>> 354 Enter mail, end with "." on a line by itself
209.11.169.65 [03A4] 01:17:58 *** <message-2219486617@mail.friendster.com> <AjayGoel@silicomm.com> 1 10017 00:00:00 OK POZ63258
209.11.169.65 [03A4] 01:17:58 >>> 250 2.6.0 10017 bytes received in 00:00:00; Message id POZ63258 accepted for delivery

Noteworthy Points:

1. The complete lack of both DomainKeys and DKIM signatures.
2. The email is SPF compliant. The SPF record for mail.friendster.com is "v=spf1 mx ip4:209.11.168.0/23 mx:c300a-1.gbxsc.friendster.com -all" and the sending IP is 209.11.169.65, which is covered by the "ip4:209.11.168.0/23" directive.
3. The email is not "from" my friend but instead is from "Friendster". The From Email is also not of my friend, but a Friendster unique email address, in this case message-2219486617@mail.friendster.com. The From Address is the same as the SMTP MAIL-FROM address shown in the SMTP transaction. Therefore bounces at the MTA level will be sent to message-2219486617@mail.friendster.com, and the unique number that's a part of that From Address presumably allows the Friendster mail system to know that it was this particular transactional email that bounced.
4. There is no Reply-To address, so if the user does hit Reply in his email client, the reply will go to the From Address, message-2219486617@mail.friendster.com, and sending to this will presumably cause the email to be lost in the ether.

MySpace:

The following are the relevant headers from a MySpace "new message" notification:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=pmta; d=message.myspace.com;h=MIME-Version:From:To:Reply-To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=noreply@message.myspace.com;bh=T25HyvwBLohBcz5zhA0xB0tJqdc=;b=SeqKqNrcg4jDIyy0lmlo2BJje2frO0hgd16E9M/Y7U42LNLPh+cLlr7q5muDN7ASuPzwaNIvjj9VKq9VzNSvnxNukRsF2ICj+jT7GFRHdO39feZXnyJgcGbu0eHGLF7v83PL8CApEF80w/f3HuZ8xZgzYQcagUvNeD2jUmTqj/4=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=pmta; d=message.myspace.com;b=SlJszI5cM6w78pK5nSJLzVTrrFw5YgU2vX8GraxP8yPjhbb6/hZ+oMjr7HUF21r8wyK774IEA/o/u3Y6z+kcpRHTf7D3TWD94TCZW+mQDGxl3t+FSdqLLt4ISVUvGu+LTAIMfpSOzVKNnz3C/4QHpAg1c2a2jRu1IFmrPbqOaK0=;
From: MySpace <noreply@message.myspace.com>
To: AjayGoel@silicomm.com
Reply-To: MySpace <noreply@message.myspace.com>
Subject: MaryParker has sent you a new message!

MySpace Transactional Email SMTP Log:

204.16.33.83 [0664] 18:04:01 Connected
204.16.33.83 [0664] 18:04:01 >>> 220 mx.silicomm.com ESMTP IceWarp 9.1.0; Fri, 10 Jul 2009 18:04:01 -0400
204.16.33.83 [0664] 18:04:01 <<< EHLO vmta20.myspace.com
204.16.33.83 [0664] 18:04:01 >>> 250-mx.silicomm.com Hello vmta20.myspace.com [204.16.33.83], pleased to meet you.
204.16.33.83 [0664] 18:04:01 <<< MAIL FROM:<noreply@message.myspace.com> BODY=8BITMIME
204.16.33.83 [0664] 18:04:01 >>> 250 2.1.0 <noreply@message.myspace.com>... Sender ok
204.16.33.83 [0664] 18:04:01 <<< RCPT TO:<AjayGoel@silicomm.com>
204.16.33.83 [0664] 18:04:01 >>> 250 2.1.5 <AjayGoel@silicomm.com>... Recipient ok
204.16.33.83 [0664] 18:04:02 <<< DATA
204.16.33.83 [0664] 18:04:02 >>> 354 Enter mail, end with "." on a line by itself
204.16.33.83 [0664] 18:04:02 *** <noreply@message.myspace.com> <AjayGoel@silicomm.com> 1 5669 00:00:00 OK RDO05602
204.16.33.83 [0664] 18:04:02 >>> 250 2.6.0 5669 bytes received in 00:00:00; Message id RDO05602 accepted for delivery

MySpace is the only one of the four social networking sites to use both the DomainKey-Signature and the DKIM-Signature headers, so kudos to MySpace for considering the entire email ecosystem.

Noteworthy Points:

1. Both DKIM and DomainKeys headers present.
2. SPF passes. The SPF record for message.myspace.com is "v=spf1 ip4:63.208.226.0/24 ip4:204.16.32.0/22 ip4:216.178.32.0/20 ip4:216.178.38.0/20 a ~all" and the sending IP is 204.16.33.83, which is included in the "ip4:204.16.32.0/22" directive.
3. The email is From "MySpace" rather than "Mary Parker", and the From Address is noreply@message.myspace.com instead of maryparker@hotmail.com. The From Address clearly implies that you should not reply to it, unlike Friendster's address. Clearly MySpace wants you to log in to the site to reply rather than by email.
4. The SMTP MAIL FROM is noreply@message.myspace.com, and does not contain a unique identifier.
5. The Reply-To header is present, but its value is the same as the From Address. So regardless, if you hit Reply on your email client, the email is going to noreply@message.myspace.com.

Conclusion:

If I had to rank the social networking sites in order of best to worse in sending authenticated, compliant, and useful transactional email, this would be the ranking:

1. Facebook (Best)

Positive: Emails are DKIM and SPF compliant. Email notifications of "You have a new message" include the message in the body of the email.
Negative: No DomainKeys signature, and the Reply-To address is one that cannot receive replies.

2. MySpace

Positive: Emails are SPF, DKIM, and DomainKeys compliant - the only social network to use all three.
Negative: Notifications of "You have a new message" force you to login to read your message. The Reply-To address is one that cannot receive replies.

3. LinkedIn

Positive: Emails are SPF and DomainKeys compliant. Sometimes emails are "From" the actual friend rather than LinkedIn. Proper use of the Sender header.
Negative: No DKIM signature, which means LinkedIn is complying with the older DomainKeys standard but not the newer DKIM standard. Notifications of "You have a new message" force you to login to read your message.

4. Friendster (Worst)

Positive: Emails are SPF compliant.
Negative: No DomainKeys signature. No DKIM signature. Notifications of "You have a new message" force you to login to read your message. The Reply-To address is one that cannot receive replies.

JangoMail Best Practice Recommendations:

When using JangoMail to send transactional emails for a social network, you can optimize the deliverability and usability of your emails by following these guidelines:

1. Ensure your emails are SPF compliant. In most cases, your emails will already be SPF compliant. Whether you're using your-username@jangomail.com as your From Address or noreply@MySocialNetwork.com as your From Address, SPF validates the SMTP MAIL-FROM Address, not the Display From Address that the recipient sees. The SMTP MAIL-FROM Address, meaning the From Address that shows in the SMTP logs, will always be your-username@jangomail.com, unless one of the following is true:

a. You've setup a custom sub-domain, in which case your sub-domain will be reflected in the SMTP MAIL-FROM.
b. You've explicitly set the SMTP MAIL-FROM by unchecking the "Use JangoMail MAIL-FROM" box on the Send Email page.
c. You've explicitly set the UseSystemMailFrom=False option when calling the SendTransactionalEmail API method.
d. You've unchecked the Use JangoMail MAIL-FROM box under My Options --> SMTP Relay, and you are using the smtp relay to send your emails.

2. Ensure your emails are signed with DKIM and DomainKeys. Once you've setup your account to use DKIM, your emails will automatically include both a DKIM and a DomainKeys signature. Read this guide to learn how to configure DomainKeys/DKIM for your emails.

3. Determine whether the content of a "You have a new message" email should appear in the Body of the email or whether you want to force the recipient to login to read the new message. I personally favor Facebook's method of including the original message in the email notification but forcing the recipient to log in to reply. After all, free social networks need to generate page-views, and they can't do that if they allow back-and-forth messaging functionality all within email.

4. Determine whether the From Address and/or Reply-To Address should be that of your social network's or that of your user's. We've seen that in the big four, LinkedIn is the only site that shows the user's name and email address in the From Line. This allows the recipient to conveniently reply to the sender of the message via email. The disadvantage to the owner of the social network is that the recipient need not visit the web site to reply to the message.

Therefore, If you wish to optimize the user experience, set the user's name and email address in the From line of the email message. If you employ this strategy, consider these points:

a. Your emails will still be SPF compliant so long as the SMTP MAIL-FROM contains a single consistent domain and SPF has been setup properly for that single domain.
b. Return Path, a large email deliverability company, recommends that if you send emails in this manner, be sure to include the "Sender" header as well. In JangoMail, you need only contact Support to have the Sender header turned on for your account.
c. There is a small chance that your emails will not be SenderID compliant, since SenderID may validate the Display From Address in addition to the SMTP MAIL-FROM address. However most SPF records for major domains are just that - SPF records and not SenderID records. In fact, all four major social networking sites use ONLY SPF, and not SenderID, as shown by the v=spf1 designation in all four records.

The best option may be to set the From Address to the social network site's address (noreply@MySocialNetwork.com), and set a Reply-To Address equal to the user's email address. The advantage of this setup is that you need not worry about any SPF/SenderID issues, and if the recipient hits Reply, the email will be directed to the user, not the social network web site. It is still important to have the Sender header inserted, however.

Data Center Move Part 3: What went right and what went wrong

This is the third and final installment of my account of our data center move. This is also my favorite part to write, because I get to recount everything that went right and wrong during after the move. And I love learning from my mistakes.

I had six total people, including myself, coordinating this effort - five at the data centers, and one remote man who could test connectivity from the outside and perform tasks related to the move that didn't require being on-site. Our downtime was scheduled from 12:00 AM to 4:00 AM EST on a Saturday night / Sunday morning.

11:00 PM

The five met at the New Data Center at 11:00 PM. I wanted to make sure the New Data Center had the WAN cable drop ready, that our access card worked, that the combinations to the cabinet doors worked, and plan out our access into and out of the building and determine where to park our cars while unloading equipment. The New Data Center came equipped with remote-access Power Distribution Units (PDUs) in both cabinets, one cabinet with 30 Amps and one with 20 Amps.

11:30 PM

Our inspection of the New Data Center was complete, and we drove the eight blocks to the Old Data Center to prepare for the take-down of the core servers: the web server, the database server, and the API server.

11:40 PM

We arrived at the Old Data Center. The primary check we needed to do prior to shutting down the servers ensuring that the standby database server had up-to-date copies of files from the primary database server. The primary log-ships to the standby server, so we needed to ensure the last of the log files had been restored to the standby server.

12:00 AM

The equipment was transported in three waves:

1. At 12:00 AM, I took the firewall and the main switch to the New Data Center. I wanted to get the firewall appliance connected to the WAN connection from the New Data Center, plug my laptop in to verify that connectivity to the Internet was working. The team transporting the three core servers would wait for my call from the New Data Center signaling that connectivity was working.

2. After my call to verify connectivity, a team of two (the primary two) would begin dismantling the three core servers (web server, database server, API server), and transport them to the New Data Center.

3. Then the remaining two (the back two) would begin dismantling and transporting the last set of servers, including corporate mail, incoming mail, standby DB server, corporate web server, the rendering servers, and a few other standby servers and appliances.

12:30 AM

Testing connectivity was a critical first step, because the type of connectivity was different from that of the Old Data Center. The New Data Center required a layer 3 routing device, while the Old Data Center did not. The firewall had to be reconfigured with a static IP, a range of DMZ IPs, and a gateway. All DMZ devices would then use the firewall as the gateway. At the Old Data Center, all devices, including the firewall, were assigned IPs from the same class C, and the gateway IP for all devices, was the same IP, and an IP provided to us by the Old Data Center. While the new connectivity setup seemed complicated at first, it worked just as expected.

After the firewall and switch were plugged in and connected, I had the sixth man who was remote, connect to the firewall via web browser, and begin changing the Network Address Objects' IP addresses. Simultaneously, he logged into our third party DNS system and begin making DNS changes for the main domain names, like jangomail.com and www.jangomail.com and mail.jangomail.com and relay.jangosmtp.net.

12:45 AM

After having verified connectivity, I called the core two, and had them initiate take-down and transport of the three core servers.

1:15 AM

Within thirty minutes, the team arrived, and we began rack-mounting the three core servers. We plugged them in, connected them to the switch, but they did not come back online.

This is where we ran into problem #1: While the IPs for the New Data Center had been assigned to the second NIC on each of the core 3 servers, the second NIC on each of the servers was disabled. Each needed to be re-enabled for connectivity to the servers to be established. I needed to login to each server, and activate the NIC, but I forgot the Keyboard-Video-Mouse (KVM) unit at the Old Data Center, and had no way of configuring anything on these three servers.

1:45 AM

I took a vehicle back to the Old Data Center, retrieved the KVM switch, checked in on the back two that were moving the ancillary servers, and drove back to the New Data Center.

2:15 AM

I mounted the KVM switch, and one by one, plugged it into each of the 3 core now-mounted servers, and activated the NIC with the new IP. One problem - I could only activate the NIC on 2 of the 3 servers. On the third, the API server, the keyboard/mouse ports were USB, and our KVM unit doesn't have USB connectors for keyboard/mouse. I had no way of actually configuring the API server. The New Data Center had mentioned the availability of a KVM crash cart on the floor, so I searched for it.Ten minutes later, I found it, locked behind another customer's cage.

2:45 AM

The web server and database server were operational, 75 minutes prior to the end of our downtime window. However, the API is mission critical to 30% of our customers, so I had to find a way to get it up and running.

Unable to fabricate an immediate solution to this problem, I drove back to the Old Data Center to check on the two men dismantling the ancillary servers.

3:00 AM

I pulled up, and they were just loading up the car. All equipment had now been removed from Old Data Center's racks. I was going to lead the car back to the New Data Center.The car wouldn't start. The car's battery had died while the flashers were on in, parked in front of the building.I pulled up alongside the car, we moved the equipment from his vehicle to mine, had a quick chat with the building doorman about not towing the now defunct car, piled back into my vehicle, and the three of us drove to the New Data Center.

3:20 AM

We loaded up the ancillary equipment on carts, and rolled the carts into the New Data Center. Once the equipment was in the data center, I had my core two men rack-mount the equipment. I let the back two use my laptop, still connected directly to the firewall, to Google for a store that was still open at the hour that would carry jumper cables. They didn't find one, but left anyway in my vehicle in search of jumper cables.

The three of us continued to rack-mount the remaining ancillary equipment. One by one, we turned each device on, and re-configured the NIC for its new IP address

After all equipment was powered on and connected, I still needed to get the API up. I decided to use the standby database server as my new primary API server, until such time as I could configure the API server with a USB keyboard/mouse.

Post Move - 5:30 AM

The three of us drove back home to Dayton, Ohio.

Post Move - 6:30 AM

I arrived at my home in Dayton and fired up my laptop to do some final testing from the outside. I noticed a few problems:

My BlackBerry wasn't receiving any email.

My BlackBerry receives all my work email by having our corporate mail server, mail.silicomm.com, forward my email to my TMobile BlackBerry email account. The email wasn't being forwarded.

I first remoted into mail.silicomm.com, did an MX lookup on tmo.blackberry.net, which is the T-Mobile BlackBerry domain, and attempted to connect to port 25 on that IP. The connection was made and immediately dropped. I assumed it was due to the new IP for mail.silicomm.com never having sent email before. As a temporary work-around, I had mail.silicomm.com forward my email to my GMail account, and then I had my GMail account forward email to my TMobile BlackBerry account.

Email I was sending wasn't being received.

I sent a test email from mail.silicomm.com to my GMail account, and it wasn't received.

Our corporate email system, IceWarp, has its own DNS settings, separate from the DNS settings in Windows TCP/IP. I hadn't changed the DNS servers of IceWarp to the New Data Cetner's DNS servers, and therefore, outbound email wasn't being transmitted since the MX lookups couldn't be performed.

JangoMail notification emails weren't being received.

All JangoMail notifications, such as "Sending Complete" and "Import Complete" notifications are sent via the JangoMail SMTP relay service. You can authenticate into the SMTP relay either by IP address or by From Address. For our own system notifications, we authenticate by IP address. We had forgotten to change the authenticated IP address in our own JangoMail account - the one that handles all these customer notifications. Once that was changed, customers received the email notifications.

One-Three Days After Data Center Move

Clients were reporting that the API was still inaccessible.

The API was inaccessible to at least three clients, because they were connecting to the API by IP address, rather than the domain name api.jangomail.com. This was discovered in the 48 hours following the move.

Clients were reporting that the JangoMail web-database connectivity feature wasn't working.

Clients were unable to use the web-database connectivity feature of JangoMail because they had restricted access to their web servers/database servers by IP address, and they had our Old Data Center IP range in their firewalls. They did not have the New Data Center IPs in their firewalls.

Five Days After Data Center Move

While examining the headers of a forwarded email in my GMail account, I noticed that an email forwarded by mail.silicomm.com to my GMail account had the originating IP listed as
209.173.128.118, which is not the IP for mail.silicomm.com. The IP for mail.silicomm.com is 209.173.141.195, and the reverse lookup for this IP is appropriately, mail.silicomm.com.

Upon further examination, I discovered that all servers in the DMZ were connecting to the outside as 209.173.128.118, which is the IP of the firewall. If I pointed a web browser on any device to www.whatismyip.com, the result was the same - 209.173.128.118. I was baffled, since all devices had been assigned public, routable IP addresses. I called SonicWall support, but I was declined support because I didn't have a support contract, and they refused to do a per-incident support ticket. I posted on the SonicWall forums, and was told I had to put in a Network Address Translation (NAT) setting in order for the firewall to prevent the firewall IP from routing the outbound connections. Once, I did that, the original BlackBerry forwarding issue was resolved. The BlackBerry email server was dropping the connection immediately because the source IP of the connection, 209.173.128.118, did not have a reverse DNS entry for it. It was the firewall's IP, so it doesn't need a rDNS entry.

Lessons Learned

There were several areas where planning was weak, including planning what equipment would be moved in what phase, and under assessing the impact of switching to new IP addresses. Given the experience I've outlined, I would have done the following differently:

1. Activated the NIC with the New Data Center IP while still at the Old Data Center.
2. Made sure to have a USB keyboard/mouse with me.
3. A week prior to the move, informed all customers that our IP addresses were changing, including the new IP range.
4. Informed all API customers that anyone connecting directly to our IP address needed to connect to the domain api.jangomail.com instead.
5. Been more conscious of the JangoMail accounts that we ourselves use and dependencies on IP addresses.
6. Been more aware that some applications don't inherit the TCP/IP settings of Windows, and have them set manually.
7. And lastly, I would have made sure at least one vehicle carried jumper cables.
   

New Video Tutorial: Configuring Gmail with the JangoMail SMTP Relay

We have a new Video Tutorial on how to configure Gmail with the JangoMail SMTP Relay Service:

Video: How to Configure Gmail with the JangoMail SMTP Relay

The JangoMail SMTP Relay improves your sending capabilities by providing the following features for your person-to-person emails:

• Open Tracking
• Click Tracking
• DomainKeys/DKIM Signing
• Easy web-based access to SMTP Logs
• API methods to retrieve Reporting data

For more information, screenshots, and written directions, read our post on configuring your Gmail account with the JangoMail SMTP Relay Service.

If you are not a Gmail user, watch our other Video Tutorials on Configuring the JangoMail SMTP Relay with a Desktop Client or a Web Server.

Data Center Move Part 2: The Planning

There were several components to my planning of the data center move:

1. Connectivity / IP Addresses - We'd be getting a whole new set of IP addresses, so I had to map the old IPs to the new IPs. And, in order for the domains to map to the new IPs as soon as we came live at the new data center, I set all TTLs for important domains, like jangomail.com, to 60 seconds.
2. Reverse DNS - Because we operate several email servers, I needed to ensure that rDNS would work properly on all of them post-move. So prior to the move, I contacted the support team at the New Data Center to put in rDNS entries for 3 of our IPs, that would map to mail.silicomm.com, mx.jngo.net, and mail.jangomail.com.
   
3. Human labor – I’d need to find enough people to move our equipment over in the desired amount of time.
4. Rails – we were moving from non-Dell cabinets to Dell cabinets. We needed to make sure the rails purchased for our non-Dell cabinets would work in the New Data Center’s Dell cabinets.
5. Firewall – All of our server access rules are controlled by our firewall, and we’d need to make sure the firewall would be ready, with the rules around the new IP addresses.
6. Software/OS configuration changes – We would need to ensure that all web servers, email servers, database servers that had services bound to a designated IP would have those IPs changed.

IP Addresses

Prior to the day of the move, I took inventory of all our equipment and the IPs to which they were assigned. I then made an Excel spreadsheet detailing the device, the old IPs assigned to it, and the new IPs that would be assigned to it.

Reverse DNS

This was relatively simple. Since we don't own our IP addresses, and since we only control forward DNS in our own DNS system, we would rely upon the New Data Center's tech team to setup rDNS for us on 3 of our IPs, each of which would be assigned to a different email server.

Human Labor

I enlisted a team of 6, including myself: 5 doing the actual move, and one man on the outside to test things and remotely make configuration changes to our firewall and DNS system. The goal was to be offline for no more than 4 hours. The plan was simply this:

1. Within the first hour, I’d take the firewall from the Old Data Center to the New Data Center to test connectivity to the Internet. A team of 2 would begin dismantling the most important servers, the primary web server, the primary database server, and the API server, but not load them into a vehicle until I had called from the New Data Center to verify connectivity was working. If for some reason, connectivity wasn’t working, then we could easily fall back to the Old Data Center.
2. Within the next two hours, the primary 2, would meet me in the New Data Center with the 3 most critical servers.
3. During the last hour, the secondary 2 would arrive at the New Data Center with all other remaining equipment.

Rails

Several weeks prior to the move, we brought rails from the Old Data Centerto the New Data Center to ensure they were compatible. They were not, but with a lug, washer, and screw, we made them work. We tested mounting a 1U server two weeks prior to the actual move.

Firewall

We only had a single firewall appliance running in the Old Data Center, and I contemplated purchasing a second appliance of the same model prior to the move. That would enable me to have the second firewall configured with the New Data Center’s IPs, and would save time in having to manually re-configure the Old Data Center’s firewall mid-move. But the price tag of the appliance convinced me otherwise, and I determined it would only take 10 minutes of time to swap out the old IPs on the firewall with the new IPs once I was able to connect my laptop to its LAN port in the New Data Center.

A few days prior to the move, we became aware of a major difference between our connectivity setup at the Old Data Center and the setup at the New Data Center. At the Old Data Center, we were simply given a range of IPs, the gateway to use, and DNS servers. All servers and devices, including the firewall, used this configuration.

The connectivity setup at the New Data Center was slightly more complicated, requiring a Layer 3 routing device. An IP would have to be assigned to the WAN port on the firewall, and that WAN port would use the facility’s IP as its gateway. Then, all the devices connected to our DMZ would use the IP that we assigned to our firewall as their own gateways. I was wary of this new setup, and therefore wanted to test connectivity during the move (see step 1 above), prior to reaching a point of no-return with the move. And because the firewall would now serve as the gateway for all of our servers on the DMZ, the firewall now became an essential piece of equipment to our uptime. At the Old Data Center, the firewall could've been removed from the network flow, and the servers would remain online. But that wasn't the case anymore.

Software Configuration Changes

The software services that runs JangoMail consist of web servers, FTP servers, SMTP servers, SQL Servers, and some monitoring systems. We have many instances of IIS running, and prior to the move, I documented which applications would need configuration changes because of the new IPs. Many of our IIS web/FTP sites are bound not to a specific IP but to “All Unassigned”, which benefitted us because it prevented us from having to manually change the IP that a particular site was bound to. But some services, like our corporate email server (IceWarp), has to have DNS servers specifically set by IP address. It doesn’t inherit the DNS settings from the NIC’s configuration. It was given that I’d be changing the IPs and Gateway and DNS servers associated with all NICs on all servers, but I wanted to minimize the amount of additional IP changes that would have to be done on top of NIC changes.

With my planning finished a mere 3 hours before the move, I was ready to go. Stay tuned for Part III, where I’ll detail what went right and what went wrong during the move, and whether we were able to complete the move within our announced downtime window!

Data Center Move Part 1: Why I did it

This past Saturday night, we did what I hope we only have to do every 5 or more years - we switched data centers. We had to physically move all of JangoMail's servers out of one data center and into another, while minimizing the impact to our customers. JangoMail was offline during the entire move, which makes it a stressful experience. The worst case scenario would be for JangoMail to go offline and never come back online. A lot would have to go wrong to realize the worst case scenario, but still, taking your life’s work offline for multiple consecutive hours while trying to move and reconfigure equipment as fast as possible in the wee hours of a Sunday morning is a large undertaking. I decided to write this article 1. As an account for myself of what we did right and wrong and 2. To help other sysadmins navigate the messy waters of switching data centers.

Why I moved data centers

Because this article isn’t meant to be an endorsement or complaint against any organization, I won’t mention the names of the old data center and the new data center. I’ll simply refer to them as Old Data Center and New Data Center.

I moved because I was unhappy with Old Data Center. Old Data Center has colocation facilities all over the country and if the cabinet space you need is under a certain size, you can’t buy from them directly – you must go through one of their reseller partners. We rent two full cabinets to house our equipment.

My issues with Old Data Center were:

1. Every 6 months for the last 2 years, they increased their prices.
2. I was unimpressed with the onsite staff at Old Data Center. Whenever I needed to see them in person for a simple issue of getting a new access card made for a new employee, I’d show up at the assigned time and ALWAYS have to wait for the right person to be available. They weren’t dressed well, nor were they articulate.
3. 18 months ago, when we expanded from 1 to 2 cabinets, as part of the setup for the second cabinet, a data center employee physically cut the Ethernet cable connecting our main cabinet #1 to the WAN. We were down for 7 hours, and no explanation was provided by Old Data Center as to why that employee thought cutting that cable was a good idea. I requested a credit, and 12 days later Old Data Center responded that we would get a credit of $46.38. I protested, citing the damage that had been done to our business, and the credit was increased to $324.66. Our monthly fee for the one cabinet was approximately $1,200 and it was my opinion that for such a boneheaded mistake, one full month’s credit should’ve been issued.
4. Setup fees were, in my opinion, too high. When we needed to increase the Amps for our power circuit, along with paying for the increased Amps, a $500 setup fee was incurred. When we wanted to move from regular cabinet doors to mesh cabinet doors for better heat dispersion, we were quoted $750 per cabinet.
5. On the few times that there were connectivity issues with Old Data Center, we would call the support number of the reseller reporting the outage, and then they would contact Old Data Center on our behalf to get an explanation. I didn’t like the multiple layers involved.
6. After four years of having been a customer of reseller of Old Data Center, and never being late on an invoice payment, they suddenly informed us that we owe them a security deposit of $2,315. The reason? Apparently Old Data Center was suddenly charging reseller a security deposit. Again, I wasn’t pleased with this multi-vendor relationship.
7. I didn’t feel like a valued customer.

The reasons I picked New Data Center were:

1. It was a single, independent company that owned, managed, and supported the datacenter.
2. The monthly fee was less than that of Old Data Center, and already included mesh doors.
3. New Data Center also provided Internet-connected PDUs in each of our two cabinets.
4. When I toured New Data Center, all employees were dressed professionally, courteous, gave me their business cards, explained their positions, and offered help above and beyond what I expected.

Stay tuned for Part II, in which I’ll detail the planning of the data center move, and Part III, where I’ll detail the actual move operation.

Behind the scenes of our SMTP Service

The last couple of days have been a challenging and learning experience for the team in charge of our SMTP Relay service. As the volume of email that passes through the relay grows, so do the problems associated with performance and scaleability.

The first version of the relay service operated in a single-threaded linear fashion. Meaning, all emails sent to relay.jangosmtp.net, are processed and sent one at a time. Whenever an email message arrives at relay.jangosmtp.net, the following steps are executed:

1. The originating IP address and From Address are examined to determine what JangoMail user account the email message belongs to.

2. The tracking options for that particular user are loaded.

3. The email message is disassembled, the tracking mechanisms are added, and then the email message is re-assembled.

4. The email message is transmitted to the appropriate JangoMail sending server, based on whether the user account is enrolled in the Sender Score Certified program or based on the domain of the recipient email address.

5. The sending email server receives the message, signs the message with DomainKeys and DKIM, and then transmits the email message to the final destination email server based on the recipient domain.

A traditional SMTP service is much simpler and only need incorporate step 1 and a part of step 5. It can take our processes anywhere from 1/10th of a second to 3 seconds to process and deliver a single email message. The amount of time depends on the size of the email, the encoding of the email, and the tracking options selected.

Tuesday morning, a larger client submitted 50,000 transactional emails to relay.jangosmtp.net. The emails arrived at the relay.jangosmtp.net server over the course of 5 hours. Our linear process went to work, processing and transmitting each email message individually. As a result, email messages from other, smaller customers were delayed, some for serveral hours. We were alerted to the problem very soon after the backlog of emails began to build. Since all JangoMail staff members use the JangoMail SMTP relay with their desktop email clients, it was easy for them to tell something was wrong -- emails my staff was sending to customers, prospects, and themselves weren't being received. We realized that having a single process, processing each email one by one, just isn't going to cut it for scenarios where a customer transmits a large amount of email messages at once.

Within 8 hours, we re-architected the entire process so that multiple threads could operate on groups of email messages simultaneously. We now have the ability to assign a dedicated processing thread to any large customer. Since all threads operate simultaneously, a large amount of email from one customer will now not hold up a small amount of email from another customer.

After we deployed the new code last night, we thought our problems were solved. We awoke Wednesday morning to discover that the multi-threaded process was crashing, due to I/O concurrency issues. The constant crashing of the new code resulted in another backlog of undelivered email messages. Within 10 minutes, we discovered the issue was that all threads were attempting to log their activities to the same log file, and this was resulting in I/O disk errors. Within 60 minutes, we corrected the issue and deployed the new code, and since then (1:15 PM EST Wednesday), there have been no errors and no backlogs.

We appreciate our SMTP service customers' support over the last couple days, especially those that were adversely affected by the backlog of emails. One of the factors that I think makes JangoMail a different type of company is the awesome skill and dedication of our developers. When an architectural or functional issue is discovered, our programmers work until the problem is solved. We react swiftly, coming up with creative solutions to difficult problems within minutes -- because if we don't, the problems get worse: backlogs build, emails stop sending, the system could grind to a halt. The types of development problems we face are generally not the type that can be solved with a Google search. This is because much of JangoMail's technology is unique. We've done things that very few companies in our industry have done, including writing our own Email Rendering Tool, writing our own SMTP sending engine from scratch, and now, introducing the world's first SMTP service with tracking.

I hope this post sheds some light on the inner workings of the JangoMail operation, my staff's committment to delivering an amazing service, and a little bit of our secret sauce on how the magic happens. If anyone has any questions about the SMTP service, email me at ajay AT us dot jangomail dot com.

You Can Now Use JangoMail's SMTP Relay with Gmail

Gmail allows users to use a custom From Address to send emails, but some recipients would see both the From Address and the Gmail Sender Address. Messages would appear to recipients as "From username@gmail.com On Behalf Of username@customdomain.com". Gmail announced last week that users can now send with their custom domain through their company's email servers, and that will eliminate the "On Behalf of" message.

This means that you can now use the JangoMail SMTP Service with Gmail to eliminate the "On Behalf of" message and give you the added benefits of Open Tracking, Click Tracking, SMTP logging, and participation in the Sender Score Certified Program.

Configuring Your JangoMail Account

Before configuring Gmail, set up an Authentication method in your JangoMail account.

1. Go to My Options and Settings > SMTP Relay.
2. Choose Authenticate by From Address, click From Addresses and enter the From Address from which you’ll be sending email. You may enter multiple From Addresses.

Configuring Your Gmail Account

Set up Gmail to use the JangoMail SMTP Relay.

1. Sign into your Gmail account.
2. Go to Settings in the upper right corner.
3. Click on the Accounts tab.
4. In the Send mail as: section, click edit info next to the account that you want to change. You should already have your business email address set up to send through Gmail. If you don't, click the Add Another Email Address option and follow the steps provided.
5. Hit the Next Step button.
6. Choose the Send through [your domain] SMTP servers option.
7. For SMTP Server, erase the default address and type in relay.jangosmtp.net
8. For Port, choose 25.
9. Type in your JangoMail Username and Password.
8. Save Changes
Gmail will now send your emails via the JangoMail SMTP Relay instead of its own servers. Enjoy the Open Tracking, Click Tracking, and all the other benefits of our SMTP service.

To view Gmail's announcement of this new feature, visit:
http://gmailblog.blogspot.com/2009/07/send-mail-from-another-address-without.html

Video Tutorials Now Available on Trackable SMTP Relay Configuration

JangoMail has two new Video Tutorials on configuring our SMTP Relay Service:

1. Using JangoMail SMTP Relay with a Desktop Email Client

2. Using JangoMail SMTP Relay on a Web Server

Watch these to learn how to configure JangoMail's SMTP Relay Service to work with a Desktop Email Client like Outlook, Thunderbird, and Lotus Notes and how to configure it for use on a Web Server. This new service improves your sending capabilities by offering these benefits:

• Open Tracking
• Click Tracking
• DomainKeys/DKIM Signing
• Easy web-based access to SMTP Logs
• Categorization of different types of transactional emails
• API methods to retrieve Reporting data

New Feature: List-Unsubscribe Header

In response to users' frustrations with trying to figure out how to unsubscribe from mailings, Hotmail and GMail have created features in their interface to standardize unsubscribing and make it easier. Users can now simply click one link in their email interface to unsubscribe from a mailing. This feature offers an alternative to using the Mark As Spam button to unsubscribe. We are now supporting this List-Unsubscribe Header option for GMail and Hotmail users.

On Wednesday, July 29 we will turn on this option on for all of our customers. This feature does not apply to transactional emails. You can turn this feature off or on by following these steps:

1. Click on My Options and Settings in your JangoMail account.

2. Under Reply Management, choose Unsubscribe Options.


3. Find the Use List-Unsubscribe Header checkbox. To turn on the List-Unsubscribe feature, keep the box checked. To turn off this feature, uncheck the box.

4. Save your preferences by clicking the Update Unsubscribe URL button.


This feature adds code into the header of the email that includes two links for an email client to use to unsubscribe the user:

1. A URL that will unsubscribe the user when visited
2. A mailto address that the email client can use to send the unsubscribe request

The header of the email looks like the below screenshot:

Click to Enlarge

The email client will follow one of these links to unsubscribe the user. If they follow the URL, JangoMail can match that unsubscribe to the email campaign it came from and it will show up in your Reporting. If the email client uses the mailto address, the unsubscribed address will only show up in your universal unsubscribe list and JangoMail won't be able to track it to a specific campaign. Unfortunately, it's up to the email client to choose which of these two links to use.


GMail users can unsubscribe from a mailing in two ways:

1. Mark the mailing as spam and choose the Unsubscribe option

2. Click the "show details" link in the top right hand corner and click "Unsubscribe from this sender"


Hotmail users can unsubscribe simply by hitting the "Unsubscribe" link at the top of the page when they are reading the mailing.

As more email clients adopt the List-Unsubscribe Header, they will be adding their own link for recipients to unsubscribe.

For the official website on the List-Unsubscribe Header, visit: http://www.list-unsubscribe.com/

To read the technical specification on the List-Unsubscribe Header, visit: http://www.faqs.org/rfcs/rfc2369.html

To read about GMail's implementation, visit: http://gmailblog.blogspot.com/2009/07/unsubscribing-made-easy.html

New options for sharing unsubscribe data between master/sub accounts

We have introduced a new option today that allows any account within a master/sub-account grouping to use the unsubscribe lists of all the other master/sub-accounts in the group, during the pre-processing stage of an email campaign.

Previously, a sub-account could elect to have its campaigns cross checked against its own unsubscribe list and that of the master account's unsubscribe list. Now, with the addition of the new mechanism, a sub-account can elect to have its campaigns cross checked against:

1. Its own unsubscribe list
2. Its master account's unsubscribe list
3. All the other sub accounts' unsubscribe lists.

This option can be toggled on and off for each individual sub-account. Simply login to the master account, go to Account Info, click Manage Sub-Accounts, and set the "Use Subs Unsub" to True or False.

Geo Tracking Phase III (Google maps overlay) is complete!

We are happy to announce that the third and final phase of our geo tracking rollout is complete - you can now view your Open/Click/Web Page View data visually as an overlay on top of Google Maps. Zoom in, zoom out, drag west, drag east...drill down to the county level in the United States and to the national level for countries outside the United States. This new feature has been one of our most intensive code development efforts to date. JangoMail is one of the few Email Marketing Service Providers to provide this feature.

Here's an example from a recent campaign we sent to all JangoMail customers (the one about the SMTP relay service). This screenshot shows Open Tracking plotted over Ohio. The purple areas represent the counties from which Opens came. The raw data is shown in the table below.


After clicking Franklin country (where Columbus is), we further drill-down until we see Google Maps markers, depicting exactly where the Opens came from:


Similar data is available for Clicks, and Page Views if you're using JangoMail's Web Site Activity Tracking feature.

You can also read earlier blog posts about Phase I and Phase II of our Geo Tracking deployment. These previous posts show you how to view raw location data on Opens, Clicks, and Page Views, as well as segment your data by distance from a particular zip code.

JangoMail Featured in Entrepreneur.com Article

CEO Ajay Goel discusses online lead generation and the launch of the new JangoMail web site: http://www.entrepreneur.com/ebusiness/buildingawebsite/article202458.html

Bug fix: Using the unsubscribe link in transactional emails

We have fixed a bug that prevented the unsubscribe link from working properly in transactional emails, including emails sent with the trackable SMTP relay.

To insert an unsubscribe link into transactional emails, do so the same way as you would with a regular email broadcast campaign, using a snipped of HTML code:

Just link to this URL:

http://x.jango9.com/u.z?***uniqueid****

and be sure to replace x.jango9.com with your account's actual Tracking Domain. The system default Tracking Domain is currently x.jango9.com.

If you link to the above URL in a transactional email, the ***uniqueid**** will be replaced by the JangoMail email engine with a string unique to your recipient. Then, then the URL is clicked, the recipient will be added to your account's unsubscribe list, preventing said person from receiving future emails from your account.

Bug Fix: Bounce processing of email addresses with apostrophes

Previously, if an email address containing an apostrophe bounced, then the email address would be added to your account's Bounce list but with the apostrophe stripped out! Then, the next time you sent an email campaign, the "bad" email address that had previously bounced would still end up on the recipient list since it wouldn't be filtered out during the Bounce list crosscheck.

This has been fixed so that the full email address, including any apostrophes, will be preserved when added to an account's Bounce list, and therefore future email campaigns will not attempt to send to this address.

Frequently Asked Questions (FAQ) about the SMTP relay service

Q. How are bounces handled?

A. If you send an email message to an address that is on your account's Bounce list, then that email message won't be sent, and instead, a notification will be sent back to the sender with this error message:

Web Service Exception BouncedEmailAddressException: Email address is on account's Bounce list. System.Exception: JangoMailNamespace.BouncedEmailAddressException: Web Service Exception BouncedEmailAddressException: Email address is on account's Bounce list.

If you send an email message to an address that is not yet on your account's bounce list, but the recipient address is invalid, then that address will then be added to your account's Bounce list. If you wish to receive an email notification of the bounce-back, like you would with a "regular" SMTP service, then set the appropriate options under My Options and Settings --> Bounce Handling.

Q. How are unsubscribes handled?

A. If you send an email message to an address on your account's Unsubscribe list, the email message will not be sent and instead an error notification containing the following text will be sent back to the From Address on the email message:

Web Service Exception UnsubscribedEmailAddressException: Email address is on account's Unsubscribe list. System.Exception: Namespace.UnsubscribedEmailAddressException: Web Service Exception UnsubscribedEmailAddressException: Email address is on account's Unsubscribe list.

You have the option to have the SMTP relay bypass your account's unsubscribe list and not perform this check. To do so, check the appropriate box under My Options and Settings --> SMTP Relay.

Q. How is word wrapping handled?

By default, the SMTP relay is set to wrap lines at 76 characters. Many of Microsoft's email clients wrap lines at 76 characters, so we chose this as the default. You can, however, customize this setting under My Options and Settings --> SMTP Relay. Most desktop email clients, like Outlook, Thunderbird, and Eudora already transmit the email to the SMTP server with proper word wrapping in place. Many programming-based components, like PHP, ASP, and ASP.Net email components that send email programatically via an SMTP server, may not do any word wrapping at all. It is for this reason that the SMTP relay will do the word wrapping at 76 characters by default. To prevent the SMTP relay from doing any word wrapping, set the Wrapping option to 0 under My Options and Settings --> SMTP Relay

Q. Can I use the standard JangoMail unsubscribe link in my email messages sent via the SMTP relay?

A. Yes, you can. Just link to:

http://x.jango8.com/u.z?***uniqueid****

x.jango8.com can be replaced with the Tracking Domain specific to your account.

Q. My email client sends emails encoded in base 64 or quoted-printable. Will there be any issues with this?

A. Everything will work fine. JangoMail's SMTP relay will not only preserve your email client's original encoding scheme, but it will also still be able to add the open-tracking and click-tracking entities to your email message.

Q. What are the costs to use the SMTP relay?

A. The pricing is the same as that of the regular JangoMail email broadcast service. It is based on the number and size of the emails you send per month. Pricing is at http://www.jangomail.com/pricing.asp

Q. What happens if I attempt to send more emails through the SMTP relay than my account allows?

A. If your account is marked as an "overage allowed" account, then you will never encounter this issue. If your account does have set limits, as most do unless you've requested otherwise, then when your emails exceed your account limits, the sender will get return notifications indicating that the account is over limit and that the email was not delivered.

Q. Is my email message delivered to my recipient instantly through the SMTP relay?

A. Your email message is delivered within 3-5 seconds after it arrives at relay.jangosmtp.net. That 3-5 seconds is required for processing, such as adding the open-tracking and click-tracking mechanisms, signing with DomainKeys (and DKIM), and checking against your account's Bounce list.

Q. Can click-tracking affect phishing filters?

A. Yes, depending on the email program that the recipient is using. Since click-tracking alters your original URL, spam filters may detect this as a phishing attempt. The smarter email clients get though, the less of an issue this will become over time. Additionally, if your display text itself isn't a URL, then there won't be an issue. For example:

This is the best web site. (good way to link)

versus

http://www.google.com is the best web site. (bad way to link)

Q. What happens if I send email from either an IP address or a From Address that I have not yet authorized under My Options and Settings --> SMTP Relay?

A. An error notification will be sent to the Sender of the email message with the IP and From Address infomation:

Relaying denied for [IP Address] / "Joe Smith"

Bug Fix: SendTransactionalEmail

Previously, the SendTransactionalEmail API method was not rejecting domains that have been unsubscribed in an account and system-wide unsubscribed domains. For example, the domain antihotmail.com is a domain that is in the JangoMail system-wide blocklist.

This has now been corrected.

Now if you use SendTransactionalEmail to send to xxxxx@antihotmail.com, the following exception will be thrown:

JangoMailNamespace.SystemDomainAddressException: Web Service Exception SystemDomainAddressException: Email address is on system-wide domain block list.

Similarly, if you unsubscribe the domain abccompany.com within your individual JangoMail account, and then you attempt to send an email to xxxxx@abccompany.com via SendTransactionalEmail, this exception will be thrown:

JangoMailNamespace.UserDomainAddressException: Web Service Exception UserDomainAddressException: Email address is on account's domain block list.

HTML Editor Upgraded to EditLive Version 6.7.1.17

We have upgraded the HTML Editor that JangoMail uses on the Send Email page. The upgrade is to the latest version of Ephox's EditLive Java-based HTML editor, version 6.7.1.17.

Bug Fixes Included in Version 6.7.1.17

• Merge Inline Styles did not merge with the first P tag
• Table corruption when merging between rows in the last column
• Word Count did not exclude removed text
• Inserting an image next to another image copied the attributes of the previous image
• Proxy servers specified by IP address were resolved to a hostname, which can cause issues with local servers
• Spell Checker did not automatically load the correct dictionary when using the Portuguese, Brazilian Portuguese, Norwegian or Dutch interface translations
• Address tags with inline styles crashed the editor
• EditLive! corrupted cookies with spaces
• Inserting new rows into a table with the inline table toolbar present caused the editor to move focus above the table

PDF Document now available on Trackable SMTP Relay feature

The official PDF guide is now available:

http://www.jangomail.com/documents/Public/JangoMail-Tutorial-SMTP-Relay-Tracking.pdf

Read this step by step guide to learn how to track every single person to person email that you send. The new SMTP service has lots of benefits over your existing SMTP service:

• Open Tracking
• Click Tracking
• DomainKeys/DKIM Signing
• Easy web-based access to SMTP Logs
• Categorization of different types of transactional emails
• API methods to retrieve Reporting data

Use it with Outlook or any desktop email program. Use it with your web page scripts that send email (ASP, ASP.Net, PHP, JSP, all web platforms are supported). Use it anywhere you designate an outbound SMTP server.

Two new API methods to delete Group members

Tonight we have launched two new API/web service methods that allow for mass deletion of Group members. These two methods and their descriptions are below. Click each method to go directly to the API test form.

Groups_DeleteAllMembers
Deletes all members of a Group.

Groups_DeleteBulkMembers
Deletes all specified email addresses in a Group.

The Groups_DeleteAllMembers method is analagous to the Delete All Members button within the JangoMail web interface. The Groups_DeleteBulkMembers is analagous to the Delete Group Members In Bulk button in the web interface.

Feature Enhancement: The Email List Importer can now handle multi-GigaByte files

We are happy to announce that we have enhanced our Group Import algorithm such that even super-large files can be uploaded for import. Previously, files over 150 MB would not process correctly and our data team would have to manually import the email list. Now, multi-GigaByte files can be uploaded through the web interface or via FTP, and JangoMail will begin to instantly process the file.

For more information on importing data into JangoMail Groups, see this tutorial.

For more information on how to FTP data files for importing into JangoMail, see this blog post.

New Feature: Geo Tracking Phase II (segment by location data)

In addition to being able to see geo tracking location data for Opens, Clicks, and Web Page Conversions on your email marketing campaigns, you can now segment your data by location or by a distance from a particular location.

Let's say I want to know who opened my email campaign within 100 miles of downtown Chicago (zip code 60610). I simply enter the data in the distance box and filter my data down:

Instead of filtering by distance, I can also choose a specific location by which to segment by using the Location dropdown menus:


Here is the sample filtered report for all Opens within 100 miles of zip code 60610. Note that actual email addresses have been blurred:

What's next?

Our final phase III rollout of Geo Tracking will include a spectacular visual overlay on Google Maps showing you graphically where Opens, Clicks, and Web Page Views/Conversions came from. Additionally, you'll be able to export any segemented data into a new JangoMail Group with a single click. This will make sending followup email campaigns to geo targetted segments a snap!

New Feature: Trackable SMTP relay now in beta

Today we have launched a feature into beta, that no other email marketing service provider has -- an SMTP relay service built specifically for email marketers. Any JangoMail active account holder can test it right now.

You can now send all of your person-to-person and transactional emails through the JangoMail SMTP relay at relay.jangosmtp.net.

The benefits of relaying your individual email messages through relay.jangosmtp.net instead of your corporate email server or your ISP email server are:

1. Open Tracking
2. Click Tracking
3. SMTP Logging
4. DomainKeys/DKIM signing
5. Automatic plain text and HTML message generation
6. Grouping of different types of emails into different categories for ease of reporting

We will soon be publishing a detailed document on how to use the SMTP relay service, but for now, follow these steps:

1. Login to your account and go to My Options and Settings --> SMTP Relay.

2. Review the settings and setup an authentication scheme, either by IP Address or by From Address.

3. If you choose to authenticate by From Address, then your email system will have to authenticate into the SMTP relay service with your JangoMail account username/password. Additionally, all of your emails must come from the From Address(es) that you specify under My Options and Settings --> SMTP Relay --> From Addresses.

4. After you've setup your authentication and tracking preferences, start relaying your email through relay.jangosmtp.net. You can connect on port 25 or port 2525.

5. All Reporting is in real-time under Reporting --> Transactional Emails.

------------------------------------------------------

Update on 6/15/09: Official PDF document now available at http://www.jangomail.com/documents/Public/JangoMail-Tutorial-SMTP-Relay-Tracking.pdf

New Feature: Geo Tracking is here (Phase I)

We're excited to announce the availability of Geo-Tracking data for Open Tracking, Click Tracking, and Web Site Activity Tracking reports. JangoMail is one of the few email marketing service providers to provide Geo-Tracking data.

The following data is now available along with the email address of the subscriber that took the action:

• City
• State
• Zip Code
• Country
• ISP
• Latitude
• Longitude

To view these additional columns, click the "By Location" tab on any of the Open Tracking, Click Tracking, or Web Site Activity Tracking reports.

Here is a sample Open Tracking with Geo Tracking Report data from our client, Popcorn Palace:


Here is a sample Click Tracking with Geo Tracking Report from JangoMail's own JangoMail account:


A similar Web Site Activity with Geo Tracking Report is available if you implement Web Site Activity Tracking on your site, which allows you to see what web pages your subscribers are visiting after clicking on and leaving your email campaign. We're not showing a screenshot of that report, since the above two clearly illustrate the Geo Tracking columns.

What's coming ahead?

1. The ability to segment Geo Tracking data based on any of the above parameters, and then send a new campaign to just those subscribers.
2. The ability to do distance based segmentations. For example, send my second campaign to everybody that opened the first campaign within 100 miles from Chicago, Illinois.
3. A visual overlay of geo tracking data over Google Maps.

New Feature: Autoresponders now work with Triggers

Want to setup triggered emails to fire based on recipient activity on an autoresponder email? Now you can do that. Any triggers associated with an email campaign used as an autoresponder, will now have those same triggers fired when action is taken by the recipient upon the autoresponder email.

For more information about Triggers with JangoMail, see http://www.jangomail.com/documents/Public/JangoMail_Tutorial_Triggers.pdf.

For more information about Autoresponders with JangoMail, see http://www.jangomail.com/documents/Public/JangoMail_Tutorial_Autoresponder.pdf

New API/Web Service Methods: Web Page Views and Mailbox Full Data

We have just released six new API methods for the JangoMail Email Marketing API.

These three methods allow you to retrieve web page view data for a particular email campaign if you're using JangoMail's Web Site Activity Tracking feature:

Reports_GetPageViews_Dataset
Retrieves all web site page views from an email campaign that is using JangoMail Activity Tracking. Returns a .NET DataSet.

Reports_GetPageViews_String
Retrieves all web site page views from an email campaign that is using JangoMail Activity Tracking. Returns a String.

Reports_GetPageViews_XML
Retrieves all web site page views from an email campaign that is using JangoMail Activity Tracking. Returns an XML document.

These three allow you to retrieve "mailbox full" soft-bounce data for a particular email campaign:

Reports_GetMailboxFull_Dataset
Retrieves the "mailbox full" soft-bounces for a particular email campaign. Returns a .NET DataSet.

Reports_GetMailboxFull_String
Retrieves the "mailbox full" soft-bounces for a particular email campaign. Returns a String.

Reports_GetMailboxFull_XML
Retrieves the "mailbox full" soft-bounces for a particular email campaign. Returns an XML document.

New JangoMail website is LIVE

After 8 years of thinking about it, it's finally live - http://www.jangomail.com

New JangoMail website design coming in next few days

Within the next seven days, we'll be launching a new website design. The login form that you're used to seeing in the upper-left will now be in the upper-right corner of the screen. Click the purple LOGIN button, and the login form will instantly appear. See the below image for a preview of the new website and the new LOGIN button.


We're excited about our new website design. It's the first re-design in our company's 8 year history. Additionally, after the new website is live, I'd love to hear your feedback.

New Feature: Determine Size of Email Before Sending

You can now determine the size of your email message using the Spam Check tool on the Send Email page.

Why would I care about the size of my email message?

JangoMail measures both number of emails sent and total data bytes sent from your account. Both are a factor in your account's pricing. Now, the Spam Check tool will include the exact size of your email message in bytes, taking into account the HTML/Plain Text parts, any attachments, and embedded images, if you choose to set your email marketing campaign that way.

Here's a live example from our customer, Popcorn Palace:


And here is the result of the Spam Check:

The size of this email at 191 KB is bigger than the average email marketing message, and that's because it's using the Embedded Images feature, which encodes the content of each image within the actual email content, rather than referencing the images off a web server.

If this email did not use the Embedded Images feature, the total size would be around 1,500 bytes, or 1.5 KB, for a size savings of over 99%!

New Feature: Pause/Resume an email marketing campaign in progress

Did you hit Send by mistake? Did you just notice that your Subject line is spelled wrong, but you already hit Send?

You can now Pause and Resume an email marketing campaign in progress.

Go to Reporting, find your campaign, and click the red PAUSE link. You may also click the status message to the left in parentheses to see the sending progress of your email campaign. Click the parenthetical status and the popup will show you many messages in your email campaign have been sent and how many remain to be sent.

Here is a live example from our client, Popcorn Palace:

Click the red PAUSE link to pause an email marketing campaign.

After clicking PAUSE, the email campaign is paused and the text changes to RESUME. If you made a mistake in the content of your email, you can go back to the Send Email tab, and make any necessary edits. Click the RESUME link to continue the sending of the email campaign.

Click the (sending) or (paused) status to launch a popup displaying progress statistics of the email campaign, including how many emails have been sent and how many remain to be sent.

Email Notifications:

If you pause a campaign, JangoMail will email you daily email reminders alerting you that you have a paused email campaign, and that you have 7 days after the Pause date to Resume your email campaign. Here is a sample email notification:

Dear Michelle:

This is a reminder that you have a PAUSED email campaign in your account:

Subject: Mother's Day Popcorn Specials
Mass Email ID: 233288445
Total Recipients: 46781
Pause Date: May 9 2009 5:51PM

You have SEVEN DAYS after the Pause date to resume your email campaign, otherwise you will not be able to resume it. You can resume your campaign by finding your campaign in Reporting and clicking the green RESUME link.

Please direct any questions to https://www.jangomail.com/Support/.

Sincerely,

The JangoMail Administrator
https://www.jangomail.com/Support/
http://www.jangomail.com
1-888-709-4099 or 614-343-3864



API / Web Service Reference:

ResumeMassEmail
Resumes a paused mass email campaign

PauseMassEmail
Pauses a mass email campaign

New Feature: Inbox Shadow

Tonight we have released a new feature called the "Inbox Shadow", which allows you to filter out recipients from an email campaign that have received a previous email campaign from you in a designated number of past days.

Sample Scenarios:

1. You wish to send an email campaign, but make sure you do not send to anyone that has received a campaign in the last 30 days.

2. You may want to schedule a daily recurring email campaign to go out to a Group, but upon each daily send, have those recipients that have received any email campaign in the last 7 days filtered out.

To use this feature, simply set the proper field on the "Send Email" page:


You can also set a recurring schedule for an email by filling out the Recurring Scheduling section: