Tuesday, June 14, 2011

New Feature: Automatically append social data to your Email Lists

We're happy to announce that, starting today, Email Lists, can now have social data appended to them. Specifically, subscribers' age, gender, and location can be added on as three additional fields to your existing Email Lists. This data is provided for free. Eventually, other socially-available premium fields will be available for a fee.

Overview:

The process of appending social data to your Email List is automatic, and you only need to designate an Email List to accept social data, in order for the data to be appended. To set an Email List to have social data appended, simply select the Email List, click the List Settings Tab,  and click Yes next to Append Social Data. Then click the Save button at the bottom of the page.



How can I use this social data?

You can use age, gender, and location to segment your Email Lists and send personalized email content based on their demographic profile. For example, if your business is a restaurant, you may want to send one offer to those subscribers under 21 years of age, and another for those over 21. If you're a clothing retailer, you may want to send different content to males versus females.



Frequently Asked Questions:

Q: If I choose to append social data, how exactly will my Email List be modified?

A: Three new fields will be added. They are social_age, social_gender, and social_location. The "friendly names" for the fields will be Age, Gender, and Location respectively.

Q: Where does JangoMail get the social data from?

A: We use a third-party data aggregator called Rapleaf. Rapleaf retrieves its personalization data from publicly available sources.

Q: Are other data points, other than just age, gender, and location, available?

A: Yes, we will soon be providing access to premium data, which includes data points such as household income and profession.

Q: Will all of my existing Email Lists automatically have social data appended?

A: No. Social data will not be automatically appended. For Email Lists, you must set them manually to receive social data using the instructions above.

Q: How long does it take after I set my List to receive social data, for the data to be appended?

A: It depends on the size of your Email List and system load, but generally, a list under 5,000 recipients should have data appended to it within 5 minutes after you change the setting.

Q: Will the appended-data be periodically refreshed to ensure accurate data?

A: Yes, by default, subscribers in Email Lists will have their social-appended data refreshed every 90 days.

Q: How do I remove social data from an Email List?

A: After social data has been appended to an Email List, to remove it, go to Lists and click the Edit Icon next to your list. Click the Fields tab and delete the social data fields: social_age, social_gender, social_location.

Q: I don't use Email Lists to store my subscriber data. I configure JangoMail to pull my list in real-time from my CRM system. Can social data still be appended?

A: No, but we will soon be introducing an API method to let you retrieve social data so that you may append data to your own CRM or external database system.

Monday, June 06, 2011

Fix for IE9 customers using the Connect to Local Database feature

We've recently been getting reports from our users who are unable to use JangoMail's Connect to Local Database feature after upgrading to Internet Explorer 9. The browser would freeze after clicking the Connect button, and would have to be shut down using Task Manager. After some exhaustive research, we've finally found a fix.


The Fix:

The fix involves adding a registry key to the Windows registry. You can download the reg file directly from us as a text file:
  1. Click here to download the registry entry as a text file.
  2. Rename the .txt file to a .reg file, and then double-click the .reg file to run it. This will add the necessary key to your Windows registry.
If you examine the .reg file in Notepad, you'll see that the specific key added to the Windows registry is:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\New Windows]
"DetourDialogs"="no"


Interested in learning more?



This issue is caused by an esoteric bug in Internet Explorer 9 involving ActiveX controls and modal dialog boxes. You can read about the bug here. We hope that Microsoft releases a fix to this in the next IE9 release, in which case, adding the above-mentioned registry key won't be necessary. Until then, please use the registry key as a workaround.

Background

The Connect to Local Database feature is based on an ActiveX control. ActiveX technology is Microsoft-specific, and therefore this feature only works in Internet Explorer. It allows a user to connect to a local data source, like an Excel file, Access file, text file, or any ODBC data source (even SQL Server and Oracle), without having to upload the entire data file, and without having to export and import data. It's one of JangoMail's standout features, and one that separates us from our competitors. When we first launched this feature in 2004, Internet Explorer was the dominant browser. As the years went on, and Safari, Firefox, and Chrome chipped away at IE's market share, the number of users able to use the Connect to Local Database feature shrank. Unfortunately the functionality provided by this ActiveX control is extremely difficult to duplicate in a browser-universal technology like Flash, Java, or Silverlight. For now, we'll continue supporting our IE users taking advantage of this feature, but we hope that in the future, we'll be able to port this feature to a browser-agnostic technology.

Thursday, June 02, 2011

SMTP Relay and CodeIgniter

Any SysAdmin will tell you that having a good toolkit at your disposal makes your job much easier. And if you think about, it's a universal truth. Whatever your profession, you absolutely need the right tools for the job. As a SysAdmin I rely heavily on my toolkit because I know that the process of troubleshooting is much quicker when I have a tool that will uncover that critical bit of information to pinpoint the root cause of a problem, or that critical byte in the case of a recent support issue here at JangoMail.

The JangoMail support team had an issue pop up whereby some users of the CodeIgniter PHP framework were not able to successfully send messages via the JangoMail SMTP relay. A cursory check of our incoming logs showed that in all cases, the SMTP transaction was stalling out at the DATA command. All other parts of the system were in working order and we had no complaints from other users. It was a good time to open up that SysAdmin toolkit and see what else we could dig up.

For my money, Wireshark is an indispensable tool. It has been a lifesaver for me on multiple occasions. The old-school Unix/Linux admin would likely use the tcpdump tool for similar reasons. These tools capture all network traffic on the computer and dump it in a human readable format. Wireshark has an especially nice GUI and a helpful feature to trace an entire TCP stream and decode the application layer protocol as necessary.

Back to our CodeIgniter issue... after firing up Wireshark, it took just one SMTP transaction with CodeIgniter to pinpoint the issue. RFC 2821 requires commands to be terminated with CRLF (that's carriage return followed by line-feed), but the CodeIgniter client was only sending a LF character. As a result, the JangoMail SMTP relay server was waiting for more input until it ultimately timed out, resulting in an un-sent message. One single byte was the reason messages were not flowing!

A quick Google search turned up the fact that CodeIgniter defaults to using only LF as its line terminator, but that can be adjusted. The code to set the proper line terminator is as follows:

...
$config['crlf'] = "\r\n";
$config['newline'] = "\r\n";
...


A good illustration of the fact that when communicating between systems on the Internet we should try and follow Internet standards as much as possible. Perhaps it's also time we all finally agree on a single line-terminator. Microsoft's Windows, Apple's OSX and the Linux operating system all use different line-terminator character sequences by default(!) - CRLF, CR and LF respectively.

Solving a problem often comes down to having the right tool for the job. So what does your toolkit look like?

Monday, May 30, 2011

Enhancement: Much faster sending for broadcast email marketing campaigns

We deployed a code change last week that will allow for significant faster email sending for our high volume clients. The change allows for true parallel sending of email messages across multiple IP addresses hosted on a single server instance. In the past, we employed a round robin approach to sending across multiple IPs, in the case where a set of IP addresses was hosted on one server. With this change, sending speeds will increase by five-fold in some cases.

JangoMail has always used a custom, coded-from-scratch MTA (Mail Transfer Agent). Most email marketing service providers use one of several third party commercially available MTAs, but we chose to build our own for the absolute tightest integration with our Reporting system, and because it allows us to adopt standards faster than our competitors. For example, JangoMail was one of the first Email Service Providers to offer support for DomainKeys/DKIM and allow complete control over domains and their associated keys.

Internally, we call the JangoMail MTA the JangoMail Sending Service, or JMSS. It's a Windows Service written in .Net, and is tightly integrated with SQL Server, which is the core database platform for JangoMail. Over the years, third party MTA vendors like Port 25 and Message Systems have pitched us on their solutions, but in our evaluation, we've found that JMSS better suits our clients. And now, with the speed improvement and an upcoming announcement regarding better DKIM customization, we're more confident than ever in our choice to continue using our homegrown MTA.

Wednesday, May 25, 2011

New Feature: A two-step unsubscribe process

We've added a new setting under Settings --> Unsubscribes, that allows you to ask your recipient to confirm intent to unsubscribe after clicking the unsubscribe link in an email campaign.


By enabling the two-step unsubscribe process, a recipient that clicks the unsubscribe link will be taken to a web page where he needs to click a secondary link to actually unsubscribe. Without this setting, clicking the original link in the email will unsubscribe him. This feature enforces a two-step unsubscribe process versus a one-step unsubscribe process.

Our clients have been asking for this feature because:
  1. Often times subscribers click the unsubscribe link unintentionally. With this feature activated, clicking the link in the email will not immediately unsubscribe a recipient.
  2. Some anti-spam systems scan the body of an email and programmatically visit every URL in the email, thus triggering the click of the unsubscribe link. The two-step confirmation process will prevent software from automatically unsubscribing a recipient.
By default, this feature will be off. You must check the box to turn the feature on.

Monday, May 16, 2011

New Feature: Event API for Transactional Emails

We are excited to announce our newest feature: an event API for transactional emails. The transactional email event API is a system that can call any web service or web page on your server upon a specified transactional email event. The following transactional email events can trigger a call to your web service:
  1. A sent email
  2. An open of an email
  3. A click of a URL in an email
  4. An unsubscribe
  5. A bounce
  6. A complaint, via Feedback Loop
The transactional email event API is now offered in addition to our long-time existing broadcast email event API, which is covered in this PDF tutorial, this blog post for ASP.Net users, and this blog post for users who use a custom web service.

Why is the transactional email event API important?

You can now easily sync transactional email data with your own database or CRM system using the Event API. You only need one script on your web server to handle the calls from JangoMail. The calls are made in real-time when an event happens.

How do I set up an event-based web service call?

To set this up, go to Settings --> Integrating JangoMail with Other Systems --> Transactional Event API.  Click on the tab for each event for which you would like a web service called, and then enter the details for the web service.


What is the difference between the "Transactional Email Event API" and the "Standard API"?

The Standard API allows a programmer to interact with JangoMail much like a user would interact with JangoMail through the web-based interface. With the Standard API, you can pull reporting data, and send transactional email. The Event API pushes event data (opens, clicks, etc.) to your system when the event happens. The Standard API needs to be polled by your system to retrieve open or click data.

Some notes on this feature:
  1. If there are 1,000 consecutive failures when calling a specific web service for a specific event, then calls to the web service will cease until the URL or one of the parameters is modified. A failure is any HTTP response that is not status 200.
  2. When you first designate a web service and its attributes, JangoMail will call the web service for the last seven days worth of data. So if you specify a web service for the "open" event today, open data from the last seven days will immediately be posted to the web service.
  3. The parameter values will be URL-encoded before they are passed to your web service via HTTP POST or GET.
  4. You do not need to specify all parameters for a particular event. You only need to specify those parameters whose values you'd like your web service to receive.
  5. Every time JangoMail makes a call to your web service, it is recorded in the Event API Log, which can be viewed under Reports --> Logs --> Transactional Event API. From here you can see a list of all successful and failed calls to your web service.

Thursday, April 28, 2011

New Feature: Preserve the Message-ID in Transactional Emails

JangoMail now has a new checkbox on the Settings --> SMTP Relay page, that allows you to preserve the original Message-ID of an email sent via the SMTP relay. By default, the Message-ID is overwritten by the JangoMail system Message-ID.


Here is an example of a JangoMail system Message-ID:

Message-ID: <254970262215471@jngomktg.net>

It's a unique number followed by @jngomktg.net. We have received a few requests from JangoMail clients to preserve the original Message-ID of the message transmitted through the relay instead of overwriting it with the JangoMail system generated Message-ID. For example, an email sent using Mozilla Thunderbird has a Thunderbird-generated Message-ID that looks like:

Message-ID: <4DB66014.1070804@silicomm.com>

In this example, Mozilla Thunderbird's Message-ID contains a unique string of alphanumeric characters and uses the domain of the receiving email address. If you check the Preserve Message-ID box, this will also be the Message-ID in the final email delivered to the recipient. If you leave this box unchecked, this Message-ID will be replaced by the JangoMail system Message-ID.

Calling the API directly

If calling the transactional email API directly via the SendTransactionalEmail method, you can specify a custom Message-ID in the Options parameter using the CustomHeaders attribute:

Options:

OpenTrack=True,ClickTrack=False,NoClickTrackText=True,SkipUnsubCheck=False,SkipBounceCheck=False,UseSystemMailFrom=True,CustomHeaders=Message-ID:<4DB65FC8.8050705@silicomm.com>

Why is this useful?

The new Preserve Original Message-ID setting grants you full control of the Message-ID header value. This is useful if you have a custom reply management system in place, such that responses and bounces can be tagged with their original Message-ID.

Tuesday, April 26, 2011

Issue Resolved: Delivery of SMS text messages to Sprint via the email gateway

Several weeks ago, a client reported that transactional email sent to the SMS email gateway for Sprint (@messaging.sprintpcs.com domains) were not being delivered. Upon investigation by our deliverability team, we found the SMTP logs showed successful delivery, which indicated that some type of filtering was taking place after receipt by Sprint's email servers but before delivery to the customer's phone. Isolating the issue proved to be difficult, as the postmaster team at Sprint was unwilling to assist our deliverability team in resolving the issue. Through a series of trial and error tests, the issue was isolated to the Message-ID header present in all emails sent from JangoMail. Typically, the Message-ID header looks like:

Message-ID: <254970262215471@jngomktg.net>

It's a unique number followed by the domain jngomktg.net, which is a domain not used for anything else except the Message-ID header in emails sent by JangoMail. The Message-ID must be a syntactically valid email address, but not a real-world valid email address, as specified by RFC 2822, section 3.6.4.

In our trial and error testing, we found that the presence of the domain jngomktg.net resulted in non-delivery of the text messages to Sprint phones. Changing the domain in the Message-ID to jsmtp.net, another one of the many domains used throughout the JangoMail application, resolved the issue.

Message-ID: <254970262215471@jsmtp.net>

Therefore, all emails, including both broadcast and transactional emails, delivered from JangoMail to @messaging.sprintpcs.com recipients will have a Message-ID containing jsmtp.net, while all other emails will use the traditional Message-ID domain of jngomktg.net. Furthermore, we will soon be launching a feature that allows you, the user, to completely customize the Message-ID header with your own internally generated identifier.

We don't yet have an explanation as for why jsmtp.net results in delivery while the presence of jngomktg.net results in non-delivery, but we hope this information proves useful to JangoMail customers and the email marketing community at large, in resolving delivery issues to the SMS email gateway for Sprint.

Sunday, April 03, 2011

New Feature: RSS to Email Campaigns

This morning we're excited to announce the launch of our RSS to Email feature -- the ability to have JangoMail monitor your blog, and automatically email your subscribers whenever a new article is posted. The JangoMail RSS Email Campaign generator supports the following feed types:
  • RSS 1.0
  • RSS 2.0
  • Atom
There are two steps to setup RSS to email publishing for your blog.

Step 1: Create an RSS email template

Go to the Messages section and click on Compose New Message. You can either create a campaign from scratch, or use the existing Basic RSS to Email Template that appears as an option when you click on with a JangoMail Smart Template. Click the Select icon to select this template.

An RSS campaign template can have the following personalization variables in the Subject and Message areas:

%%rss_author%%
%%rss_title%%
%%rss_content%%
%%rss_url%%

The provided basic RSS template makes use of all of these variables. You can also customize the basic template by choosing it and then making your own modifications.



Important Note: To save your template to the system, just Send or Preview it to at least one recipient.

Step 2: Setup your blog's RSS feed in JangoMail

Next, set up your blog's RSS Feed under Settings --> Sending and Receiving --> RSS Feeds.



If you don't know your blog's RSS feed, try your blog address, followed by "atom.xml" or "rss.xml". For example, the feed for the JangoMail In Progress blog can be accessed at either:

http://blog.jangomail.com/atom.xml or http://blog.jangomail.com/rss.xml

You will need to know the location of your blog's feed before you can proceed with this feature.

Click on Add RSS Feed and fill out the rest of the form, as shown below. In this example, we are monitoring the TechCrunch blog, and the feed URL is http://www.techcrunch.com/feed/atom. We have to set it to send immediate email notifications whenever a new blog post is published, and the emails will go to the List #41172369, as well as to recipients from the web database included in the given SQL query:




Choosing Recipients


When specifying which recipients will receive RSS email campaigns, you can choose from:
  1. An entire Email List, or multiple Email Lists.
  2. A segment of an Email List. If there are no items in the dropdown menu, you can create List Segments under Lists. Click on the Edit Lists Icon next to the list you would like to filter. Then click the List Tools Tab and go to Filter and Send. Choose your filter settings and save the query. It will now show up as an option undder Send to List Segment in the screen above.
  3. A SQL query called against your web site's database. For this to work, you must have a Master Profile already set up under Settings --> Integrating JangoMail with Other Systems --> Set Master Profile for Web DB. Once this is set, specify a SQL SELECT statement in this box.

Scheduling

JangoMail will check feeds for new posts once every minute and will send out your new post to your subscribers almost instantly, if you have your feed Schedule set to send Immediately. If you instead set it to Daily and enter a time of day, then JangoMail will wait until the specified time, either on the same day, or the next day, before sending out new posts.

Reports

After you've sent some RSS email campaigns, you can view your campaigns' statistics under the Reports tab. Go to Broadcast Message Reports and click the Filter icon. To view just the statistics for RSS email campaigns, set the appropriate Filter:


How is JangoMail's RSS-to-Email feature different from other RSS-to-Email services?

JangoMail's RSS to Email campaign feature does much more than other RSS/email tools, including allowing you full control of the design of the emails, full tracking (opens, clicks, integration with Google Analytics), and complete list management (unsubscribes, bounces, complaints via feedback loops).

Additionally, JangoMail's tool allows you to send to an entire Email List, a segmented portion of an Email List, or a set of recipient data pulled in real-time from your web site's database.

Resources:

To read more about RSS and ATOM specifications, see the articles:

http://en.wikipedia.org/wiki/RSS

http://en.wikipedia.org/wiki/Atom_%28standard%29

http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared

Tuesday, March 22, 2011

Patrick White from Webletter.org tells us about his advanced integration with JangoMail

Webletter provides print, newsletter, survey, and email marketing services to companies in the print industry. Patrick has built a variety of cool features on top of the JangoMail platform to offer a unique and valuable service to his clients. He took some time to tell us about how he's integrated JangoMail into his service.  Here's what he had to say:

JM: Hi Patrick. Thanks for taking the time to talk to us. Could you tell us a little bit about Webletter and the service that you provide?

Patrick: We began using JangoMail as the back-end system for our turn-key email service targeted at commercial printing organizations. We produce a monthly email newsletter that is syndicated by many printers and mailed to their lists, with the from address being a variable that matches the sales rep to the prospect or account. Each rep gets their own login to our system for contact management, as well as a report that provides view information for their contacts only.

We recently added some 1:1 features as well, including a new tool we call QuickNote that sends a follow-up message that can be easily edited by a sales rep. The edited message is dropped into an HTML format that is already set up, allowing the rep to send a highly stylized, 1:1 email. This feature is integrated into Highrise's sales app as well.

We added a sub-account feature about a year ago, allowing our printing industry clients to manage email campaigns for their clients (this enables them to take a snail-mailed postcard, for example, and convert it to a broadcast email for cross-media marketing). We often assist them in creating the email for their clients.


JM: That's a really cool feature! Have you built other features on top of JangoMail that are specifically useful to your industry?

Patrick: Yes, here are the biggies:

LIST:

A. Compartmentalization by sender (sales reps). This is an issue in terms of both managing/viewing contacts as well as in terms of reporting. These reps would never share their lists with each other. With JangoMail, an admin needs to compile the list and then manage the upload, reporting, etc. We've tackled this extensively.

B. We built a tool that determines a contact's gender automatically and our reports include information on not only campaign results, but results broken down by gender as well. This is very helpful to see if their is gender bias in the campaign design.

C. We built a name splitter into our app that splits the contact into first and last and is really intelligent about three or more word names. For example: Billy Jean and King vs. Jill and St. John.

CONTENT:

A. We've built a tool that allows an organization to access our own or their own story content to not only provide blog-style on the Web, but to email on-demand anytime they want. Typically we create a new story each month for this vertical, and they send it to all of their clients. Yet the story we wrote six months ago can be resent to a prospect requesting the information, for example. This system was designed for content relevant to the commercial printing space, but now can be used by any organization in any vertical industry.

B. We added an HTML code checker when clients try to design their own broadcast emails, that gives them suggestions by parsing the HTML and CSS tags and then makes suggestions and warnings if the code is incompatible with key email browsers. It's not as cool as your client preview tool but a lot faster/more realistic to use.

C. We added a survey tool.

D. We have an awesome, unbelievable back-end form/landing page tool, that allows the client to create a form without knowing any HTML and then use the link to embed into the broadcast email. The form is actually viewed from what we call a "universal viewer" HTML page on their web site that, based on the query string, displays the newsletter, an archive story, a survey, a form, or whatever. The form uses either MSXML2.ServerXMLHTTP or a frameset to build the page. The advantage of this system is it allows the marketer to create landing pages without having to involve IT. In effect it makes him or her a mini-webmaster for email campaigns.


JM: Can you tell me more about which features of JangoMail you use with your service?

Patrick: Yes. We use the API pretty much exclusively to deliver the message with a number of variable fields for both sender and contact. We also use the bounce, opt-out and views reporting features of the API to poll for results and pull them into our system.

A few cool features about our reports:

A. Compartmentalized/filtered by sender so that each sales reps' contacts are only shared with him or her (with Jangomail's built in reporting, it's hard to share results with a sales team without revealing one rep's contacts to the others, a big issue with our small-business clients)
*JangoMail can do this on the large scale for Agencies, using a Master/subaccount setting, but not within an individual smaller account.

B. An push-email that goes to every rep of the views report once an admin checks the views. This keeps the reps engaged in the broadcast email campaigns to motivate them to add and update their contact lists.

C. A cool, side-by-side views report that allows you to select multiple campaigns, and then view a report that tells you who is interested in what. Our clients tend to sell multiple services, so by enabling them to see who's interested in what topics, it gives them insight into new opportunities to target a specific contact with the identified need based on the views. It's actually really insightful.


JM: You've created some helpful tools that can be used for creating email newsletters. One of them that you mentioned was your Gender Finder. How did that come about and how does it work? Can you give an example of some success that you've seen from using that?

Patrick: Gender Finder works by taking US Census data for first names and comparing the ratio of that name to the overall US Population for male vs. female. For example, if your name is Tracey, you are about nine times more likely to be a woman than a man. We augmented that with the most popular male and female names for a variety of other cultures including Indian, Italian, French, Latin/Spanish, etc. by manually adding popular male/female names to the respective lists.

To tell you the truth, there hasn't been a lot of interest in using the tool yet, though I haven't promoted it at all. This is strange to me because you would not believe the discrepancy in views when filtered by gender.
You don't have to mail through our system to use this tool. It can be used to "genderize" any list, which then can be analyzed once results come in by genderizing the results. Marketers should really be paying attention to this, because if gender bias does exist in their creative/offer/overall strategy, it can easily be addressed to improve results inexpensively.


JM: You have a number of other tools and cool features available. What have you found to be the most popular?

Patrick:
A. gnimage.com pulls all photos from an entire Web site and presents them. It has served up about 10 million images so far.

B. We have a really cool test list calculator that determines the size required for a valid multivariate or A/B test. It's free.


JM: Is there anything else that you'd like to highlight about Webletter?

Patrick: Yes. I'd love to be seen as someone who:
A. ...can help an organization integrate the API into their system or provide documentation on this area.
B. ...can provide an interface for doing some niche things, like adding a forms tool, or whatever.
C. ...can help a small business set-up a godaddy database to then integrate with JangoMail, including the forms front-end and back-end, etc. This is huge!
D. ...can help a company with classic ASP code development or maintenance issues.
E. ...can help a company create, write, design and/or code an email campaign


JM: Thanks for taking the time to work with us. We're excited to have such a cool client integration!

Wednesday, February 23, 2011

New HTML Editor Option: TinyMCE is here!

We've just added a third choice of HTML editor to JangoMail, and it's a crowd favorite: TinyMCE. TinyMCE is a lightweight, powerful JavaScript-based HTML editor that loads fast. We'll continue to option our other two editors, the simple ActivEdit editor and the powerful Java-based EditLive editor as well. Most of the features we offered in the EditLive editor have been replicated in the TinyMCE editor, including:
  1. One-click ability to insert a CAN-SPAM footer, View as Web Page link, Twitter and Facebook sharing icons
  2. One-click ability to insert custom, pre-defined HTML snippets at the cursor location.
  3. Ability to load templates directly from the editor


Additionally, with the TinyMCE editor, you can switch between the Plain Text Editor and the HTML editor instantly, without having to re-load the page.

While the Java-based EditLive is still quite powerful, some users found it too slow to load and too clunky for rapid keystrokes. The TinyMCE editor is powerful, feature-rich, and lightning fast.

To set your account to use TinyMCE, begin composing a new message. Click the Settings Icon and choose the TinyMCE editor out of the three available options.


Thursday, February 17, 2011

New Feature: Restrict JangoMail SMTP Relay by From Address

We've launched a new feature that allows you to restrict who can use JangoMail via the SMTP relay service by From Address. Under Settings > Transactional > From Addresses, you may designate which email addresses and domains can send through the relay.



By default, all email addresses and domains can send through the relay.

You only need to specify From Addresses if you wish to restrict the relay to use just by certain people. If you wish to restrict the use of the relay to an entire domain, you can use the wildcard notation *@domain.com as the From Address to represent all addresses for domain.com.

Note: Specifying From Address restrictions only apply to emails sent through the SMTP relay, and not through the transactional email API.

Wednesday, February 16, 2011

New Feature: Delivery Optimization Tool

Ensuring good delivery of customer campaigns is of paramount importance here at JangoMail. We've blogged before about steps you as a user can take to help boost your deliverability. Now, we've taken it a step further and created a tool to help you see what you might be able to change to optimize delivery of your campaigns.

The new tool (fittingly named the "Delivery Optimization Tool" can be accessed from your Reports screen by clicking the ***Delivery Tools*** drop-down and choosing Delivery Optimization.




The Delivery Optimization Tool has two different modes of operation. In the first, the tool will analyze the most recent domains you've used for sending in both JangoMail and JangoSMTP; in the second, you can analyze a specific domain. The former is good for general use while the latter is handy if you are setting up a new domain that you have not yet sent from and want to verify you've taken all the correct steps for delivery optimization.





Make your selection (and enter a domain name if applicable) and click the Optimize button to start the analysis. You'll get a report listing any steps you should consider to help improve delivery. And of course, if you need any assistance implementing the steps outlined in your report feel free to contact your JangoMail / JangoSMTP support team.



Friday, February 11, 2011

New Feature: Merge two Email Lists

We've just launched a new feature under Lists that allows you to merge one Email List into another. You can do this via the web interface by going to the Lists tab, selecting the destination Email List for which you want to merge into, and visiting the List Tools tab. There you select Merge email lists and then select the source Email List whose members should be merged.




Notes: The email addresses in the Source Email List will then be copied to the Destination Email List. The Source Email List will not be modified. If the two Email Lists have different fields, then only the fields they have in common will be copied.

Web Service Method

You can also merge Email Lists with the API, using the MergeEmailLists method:


  • MergeEmailLists
    Merges two Email Lists by copying the List members from the Source List to the Destination List. Returns a String.

  • Wednesday, February 02, 2011

    New SMTP Relay option to preserve custom headers

    We have launched a new feature that will give you the option to preserve custom headers when using the JangoMail SMTP relay at relay.jangosmtp.net. To enable this option, go to Settings --> SMTP Relay, and check the Preserve Headers box.



    Enabling this option will preserve any custom headers that are a part of your original mail message. The SMTP relay previously would strip off custom headers before teh email was delivered to the recipient. With this feature, 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.

    We will be enabling an option in a future launch 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.

    Wednesday, January 12, 2011

    Location metrics have been relocated within Reporting

    To improve consistency and avoid confusion in an email 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.


    More Resources

    For more information on this feature set, visit our previous blog posts:



    You can also read earlier blog posts about Phase I, Phase II, and Phase III 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.

    Tuesday, January 04, 2011

    New API method to retrieve SMTP log for transactional email

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



    The method takes, as input parameters, the 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.

    The output of Reports_GetSMTPLog_Transactional includes the SMTP log as an XML string:




    Note: This new method is in addition to our existing method that retrieves SMTP logs for broadcast email messages:



    JangoMail is the only email service that offers access to SMTP logs for both broadcast email campaigns and 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/
  • Reports_GetSMTPLog
    Returns the SMTP log session for the specified broadcast campaign's email address


  • Reports_GetSMTPLog_Transactional
    Returns the SMTP log session for the specified transactional email message
  • Tuesday, December 21, 2010

    An adjustment to how we calculate open rates

    Tonight we've made a slight adjustment to how our system detects an "open" on a broadcast email campaign.

    First, some background

    Email marketing systems detect that an email has been opened by inserting a 1-pixel image at the bottom of the email message and waiting for that image to be downloaded from the server. Some email clients block images by default, and therefore they prevent email marketing systems like JangoMail from detecting the "open". If an email message can be understood by its recipient by not seeing the actual images, because perhaps there is enough text to explain the email message, then it's even more likely that the 1-pixel image won't be downloaded.

    Therefore, we have always only counted an email as being "opened" if the 1-pixel image at the bottom of the email was downloaded, meaning that the recipient had viewed the email, and that images (even if there aren't any in the email body) are turned on.

    New way to detect an open

    We recently determined, however, that in many cases, a recipient may click a URL in an email (thus counting as a click), but never downloads the images in the email (thus NOT counting the open). And since clicking the email is indicative of also opening it, we've made the following change to Open Tracking:

    If an email is clicked, but that recipient has not yet been counted as an "open" for that email campaign because images haven't been downloaded, the recipient now WILL get counted as an "open" anyway due to the click.
    The net effect of this change is that you will now see higher Open Rates, and the Open Rates will be more accurate and reflective of what recipients are actually doing with the email message.

    How much of a difference does this make?

    Our analysis shows that this makes a big difference. For a recent email campaign we did to a segment of our own customers, these were the statistics in Reporting:

    Recipients: 6,369
    Unique Opens: 993 (15.6%)
    Unique Clicks: 384 (6.0%)

    An analysis of the data showed that there were 118 unique recipients that clicked that never registered as having opened the email. So if we add the 118 to 993, that's now a total of 1,111 opens, for an actual open rate of 17.4% instead of 15.6%.

    Thursday, December 09, 2010

    Holiday Email Templates - For Free!

    TemplateZone is offering their Holiday Email Template package for free to any JangoMail client who "Likes" them on Facebook.

    Visit TemplateZone's facebook page and "Like" them now to get your free email templates.

    Monday, December 06, 2010

    New Feature: No need to specify From Addresses when using SMTP server

    If you're using JangoMail to send transactional email, and specifically you're using the SMTP service to send transactional messages, then this post applies to you!

    When using the SMTP service, you no longer need to specify your From Addresses in your JangoSMTP Settings when using SMTP Authentication (SMTP AUTH) to authenticate into relay.jangosmtp.net.

    This is a substantial enhancement to the JangoMail SMTP service. By simply setting your email client to use SMTP AUTH and passing in your JangoMail username and password, the system will be able to assign your emails to your account. This is especially beneficial to organizations that send emails from many different From Addresses through one single JangoMail account.

    As a result, we will soon be taking away the screen within Settings where you would normally specify a list of From Addresses when using SMTP username/password authentication.

    [This screen will soon be removed.]

    Note that this only applies to users using username/password to authenticate into the SMTP server. If you're using IP authentication, then there is no change, as users using IP authentication have always been able to send without specifying From Addresses.