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 2525. 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 SMTP 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 Feature: Floating Buttons on Send Email page

We're always striving to improve our user interface, and today we've added an option that will make using the Send Email page much easier. This page has a lot of form fields on it, and every time you make a change to a field, if you want to send yourself a test email, you have to then scroll up or down to find the buttons. Not any more...now you can choose to have the buttons float at the bottom of your screen.

To set this option, go to Settings --> Send Email Page, and check the box to enable Floating Buttons.


The buttons on the Send Email page will now remain constant at the bottom of your page.



Please note that this feature will not work with Internet Explorer 6. It will work with Internet Explorer 7 and greater, and with Firefox, Safari, and Chrome.

Press Release: JangoMail Takes Lead in Delivering Runner Updates During NYC Half-Marathon

New York Road Runners again chose JangoMail to deliver race updates for last Sunday's Half-Marathon.

Read our press release to learn more about how JangoMail helped NYRR deliver race updates via email.

https://www.jangomail.com/JangoMail-Takes-Lead-In-Delivering-Race-Updates-For-NYC-Marathon.asp

New Feature: Self Service Upgrades!

We've just launched a tool to allow you to upgrade your account without contacting Support. This feature is available only in our new no-frames interface. And we've only rolled it out to a portion of our accounts, to test it out. If you don't see the Upgrade Account button in your account yet, you soon will.


To upgrade your account click the Account Info link in the blue top area, and then you'll see the screen above. Then click the Upgrade Account button.



You'll then be taken to the Upgrade Account tool. From here you have several options:

1. Upgrade the number of emails for just the current billing cycle.
2. Upgrade the number of emails for both the current billing cycle and all future billing cycles (a permanent upgrade)
3. Upgrade the number of data bytes for just the current billing cycle.
4. Upgrade the number of data bytes permanently, for the current and all future billing cycles.

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.

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

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.

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.

Groups_Rename
Renames a group. Returns a String.

TransactionalGroups_Rename
Renames a transactional group. Returns a String.

Both of these methods were the request of a client.