A Long Time Ago in an APAR Far, Far Away ... (or How the Email Listener Handles RFC822 Content)

Body

Stuart Bowden (IBM UK) and Sampath Sriramadhesikan (IBM US) contributed to this article.

Introduction

APAR IZ88552 brought about some functionality in Maximo to handle email with a content type of 'message' (i.e. RFC 822 content).   Two-and-a-half years later is not too late to clarify what this feature entails.

Maximo, nor the JavaMail API, are capable of encoding or decoding proprietary message formats. The Outlook message format is a proprietary binary encoded format.

1) The value of the mxe.listener.rfc822extension property is not a "mode" setting, it is an arbitrary value for the extension of the message file to be attached to the ticket.

It is simply the desired extension for the resulting text based attachment and setting a particular extension does not imply compatibility with Outlook (or any other application). The extension can be 'cat' or 'msg' or 'txt'. Calling it 'msg' does not make it an Outlook msg any more than calling it 'cat' would make it a household pet or calling it an 'xls' would make it a spreadsheet.

It can be problematic to call the file something for which there is an existing Windows association that suggests a proprietary format and therefore a compatibility that does not exist.

2) The attached content arrives from the server as content/type "message/*" (i.e. a MimeMessage), not as an Outlook file.

The file comes into Maximo from the email server *not* as an Outlook message file attachment, but as a MimeMessage object which is specifically text based, showing message headers, content headers and content. This is why 'txt' or 'eml'  (a plain text Mime format recognized by many email clients) are more appropriate values for the extension.  Maximo cannot convert back to what the email server has undone.

If the proprietary Outlook content file arrived from the server with a content/type of "attachment", the rfc822 processing code would not be involved, and it would simply be handled like any other attached file.

3) Maximo does not decode the content of the MimeMessage.

Maximo performs no decoding on the content, nor is it capable of it.  The MimeMessage content is simply saved as a file with the desired extension. Therefore if the context is encoded in a non-human readable format such as base64, that's what will be in the file.

In this case a 'txt' extension would not be appropriate. If the file is saved as an eml (an open, cross brand format) file, we found that email applications such as Lotus Notes as well as Thunderbird and Outlook Express will open these files and email will be human readable.  

If the eml file does not open in your version(s) of Outlook, seek the support of the vendor as this is a known issue (e.g. http://support.microsoft.com/kb/956693).