SMTP Relay Server Enhancements

We've deployed a couple of enhancements and bug fixes to the SMTP service.

1. MIME encoded Subject lines containing a Transactional Group are now handled properly.
   
   According to the SMTP MIME specification, certain email headers can be MIME encoded. It's called the encoded-word syntax. For example, the Subject of an email might actually look like:
   
   Subject: =?utf-8?Q?Savings_For_Today{Daily_Alert}?=
   
   This represents a subject that is character-encoded as UTF-8 and content-transfer-encoded as quoted-printable. This Subject, properly rendered by an email client would look like:
   
   Subject: Savings for Today{Daily Alert}
   For the purposes of the JangoMail SMTP Server, the subject can contain the Transactional Group that the message should be assigned to in curly brackets. So if this message was relayed through relay.jangosmtp.net, then the actual Subject would be "Savings for Today", and this message would be assigned to the Transactional Group "Daily Alert" in the user's account. Previously, our system was not decoding the Subject properly in order to determine the correct Transactional Group name to which to assign the email, but that has now been corrected in today's release.
   
2. If the Sender header is specified in the original email, that header is now preserved.
   
   The Sender header, similar to the From header of an email, can be used to denote additional information about where the email originated. Most email messages do not contain a Sender header, but in some cases, a Sender header is inserted by an email system if the user is using a From Address not local to that particular email system. For example, GMail users who send "from" an address other than their gmail.com address will have a Sender header inserted into the email where the Sender header equals the gmail.com address and the From address equals the user's chosen From Address.
   
   On the receiving side, some email clients will show the Sender header as a phrase to the email recipient, saying "From [From Address] On Behalf Of [Sender Address]"
   
   Previously, if an email was relayed through the relay server that included a Sender header, the Sender header would be discarded by our system and not included in the final email message. Now, the system is preserving the Sender header.

Why you can't connect to the SMTP relay server

We often get inquiries from customers telling us that they're unable to relay emails through relay.jangosmtp.net. Here is a list of the most common reasons why it doesn't work.

1. Your Internet Service Provider (ISP) is blocking access to external email servers. By default, the SMTP server listens on port 25, and many ISPs block connections on port 25 in order to prevent you from emailing through an external email server. For this reason, our SMTP server also listens on port 587 and 2525. You can also connect securely over SSL/TLS on port 465. You can test connectivity from a Command Prompt by typing:
   
   telnet relay.jangosmtp.net 25
   
   
   
   
   Successfully connecting to relay.jangosmtp.net
   
   
   If that doesn't work, try:
   
   telnet relay.jangosmtp.net 2525
   
   You should get a response from the server as shown in the screenshot above.
2. You haven't setup a proper authentication method. In order to relay emails through relay.jangosmtp.net, you must login to your account, go to Settings --> SMTP Relay, and authenticate either by IP Address or Username/Password.
3. You are connecting to the wrong server. We've had customers attempt to connect to relay.jangosmtp.com, relay.jangomail.com, and relay.jangomail.net, all of which are incorrect. The correct server is relay.jangosmtp.net.
4. You are manually inputting SMTP commands in order to complete a SMTP transaction. Unfortunately, unless you manually input the data for a proper and well-formed email message, including a Subject and a Message, our system will discard it.

How do you know if your email goes through the relay server properly? You will see your email almost instantly in Reporting after you send it.

New API method to retrieve SMTP log files

Several years ago, we were the first email service provider to provide access to SMTP logs for email marketing campaigns. Now we're the first to provide access to SMTP logs via an API. Today we have launched the method Reports_GetSMTPLog to retrieve the SMTP log for a given email address for a given email campaign. Just pass in the campaign ID and the recipient email address.

This method only retrieves SMTP logs for broadcast email marketing campaigns. We are working on a method to retrieve SMTP logs for transactional email messages as well, but this poses some challenges not seen with broadcast campaigns. For example, while broadcast campaigns generally don't have duplicate email addresses, it is very possible that in a Transactional Group's email messages, a single email address has received multiple transactional messages over time. Thus, simply passing in a Transactional Group Name and an email address won't suffice for retrieving the log, since the API needs to be able to determine the time range of logs to search in order to display them to the caller.

Reports_GetSMTPLog
Returns the SMTP log for a specified recipient of a specified email campaign

Two new API methods to change Group names

We have deployed two new API methods. Groups_Rename allows you to change the name of an Email Group (aka Email List). And TransactionalGroups_Rename allows you to change the name of a Transactional Email Group.





Both of these methods were the request of a client.

TransactionalGroups_Rename
Renames a transactional group. Returns a String.

Groups_Rename
Renames a group. Returns a String.