New Setting: Preserving the original Message-ID header in transactional email

We've added a new checkbox on the Settings --> SMTP Relay page, that allows you to preserve the Message-ID of an email sent via the SMTP relay, rather than have it be overwritten by the JangoSMTP system Message-ID, which is the default behavior.


The JangoSMTP system Message-ID looks like:

Message-ID: <254970262215471@jngomktg.net>

It's a unique number followed by @jngomktg.net. Some JangoSMTP users have asked that the original Message-ID of the message transmitted through the relay be used instead of being overwritten by the JangoSMTP system Message-ID. For example, if you send an email using Mozilla Thunderbird, the Thunderbird-generated Message-ID looks like:

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

In Thunderbird's case, the Message-ID contains a unique string of alphanumeric characters and uses the domain of the receiving email address. If the Preserve Message-ID box is checked, this will also be the Message-ID in the final email delivered to the recipient. If unchecked, this Message-ID will be replaced by the JangoSMTP system generated 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?

Allowing you full control of the Message-ID header value 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.

Fix: Transactional email delivery to the Sprint SMS email gateway

A JangoSMTP user recently reported that transactional email sent by JangoSMTP 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 Sprint's postmaster team was unwilling to assist our deliverability team in resolving the issue.

Through trial and error, the issue was isolated to the Message-ID header present in all transactional email sent from JangoSMTP. 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 JangoSMTP. 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 JangoSMTP service, resolved the issue.

Message-ID: <254970262215471@jsmtp.net>

Therefore, all transactional emails delivered from JangoSMTP to @messaging.sprintpcs.com recipients will have a Message-ID containing jsmtp.net, while all other emails will continue to 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 JangoSMTP customers and the transactional email community at large, in resolving delivery issues to the SMS email gateway for Sprint.