Some RFC 2822 headers not detected or modified by Janusgate Mobile

Janusgate Mobile includes predicates and processors which indicate they should work on RFC2822 mail headers. However, in many situations the predicate(s) does not appear to be triggered when expected, or the processor(s) does not perform its expected action.

This is an artifact of the Exchange ActiveSync protocol that is being communicated between device and server. In essence the ActiveSync protocol often does not contain the full MIME content of the original message as it appears in the end-user's mailbox. In fact, by design, the ActiveSync protocol tends to carry as little information as possible to the mobile device.

Due to this behaviour and limitation of the ActiveSync protocol, Janusnet does not recommend use of predicates or processors which inspect or act upon RFC2822 headers, including:

  • HasRfc2822Header
  • Rfc2822HeaderTest
  • Rfc2822HeaderRemover
  • Rfc2822HeaderSetter
Article Information
known issue
Date created: 
06 Feb, 2013
Last updated: 
08 May, 2018 20:20
More Information: 

This limitation is due to the actual content that is sent over the Microsoft ActiveSync protocol. The protocol is designed to be very efficient and so the full MIME content of the original email in the end-user's mailbox is not necessarily synchronised to the device.

In fact, Exchange Server actively tends to minimise the amount of content sent to the device. It does this using a number of mechanisms including from least content to most:

  1. sending a simple plain text representation of the message body and minimal metadata to the device
  2. sending a HTML representation of the message body and minimal metadata to the device
  3. sending a RTF representation of the message body and minimal metadata to the device
  4. sending a MIME representation of the message and minimal metadata to the device

For the most expensive case where the MIME representation of the message is sent to the device, Exchange Server will also minimise the content in the MIME payload. So for example it may reduce the number of RFC2822 mail headers in the MIME structure so that only a minimum set for RFC2822/MIME compliance are present. This often means optional or extension headers (x-headers, such as the X-Protective-Marking header) are not present in the MIME representation.

In some rare instances we have observed that a good MIME representation of the original message is relayed in the protocol from server to the device, but we emphasise these instances are rare and hence cannot be relied upon. It appears to depend on the version of Exchange Server and the type and operating system version of the device.

For these reasons it is difficult to make use of the predicates and processors which act or inspect RFC2822 mail headers, particularly for protocol traffic going from server to device.

For traffic going from device to server you may have more success, particularly for new messages created on the device (but generally excluding replies and forwards). This is because the device tends to submit the new message using a RFC2822/MIME syntax. Nonetheless, we have observed instances where Exchange Server will not use the submitted syntax verbatim but instead interprets it and creates a new MIME message. This becomes particularly evident if trying to add an extension header (x-header) for inbound content. If you do attempt to use such a predicate or processor for inbound traffic ensure you have tested for the expected outcome(s) using all the devices as used by your end-users.

Applies To
Janusgate Mobile