1. Pure Message Fields

The following fields come from the message, and are not manipulated by ResponseMaster.

1a. Subject

The subject of the message. This is taken directly from the message without any processing. The recipient’s mail server, in most cases, changes the original subject to one that is related to the reason that the mail was sent back.

1b. FromAddress

The From address of the message. If there are multiple From addresses, they are concatenated, separated with semicolons. In most cases this address is that of the recipient’s mail server.

1c. ToAddress

The To address of the message. This is almost always the address of the mailbox that is being monitored. If there are multiple To addresses, they are concatenated, separated with semicolons.

1d. ReceivedTimestamp

The timestamp when the message was received at the mailbox ResponseMaster is monitoring. Note: If POP3 is used to access the mailbox, this field returns the current time since POP3 does not support this message field.

1e. SentTimestamp

The timestamp when the message was sent.

1f. SizeOfMessage

The size of the message, in bytes.

1g. AttachedMessageSubject

The subject of the attached message (if there is one).

2. Manipulated Fields

The following fields are derived by ResponseMaster from the returned mail.

2a. Attachment

This message field is the concatenation of all the parts of the message that are text or HTML, but not the body or delivery status data. If there are multiple parts, they are separated by “”.

2b. AttachmentFileNames

A comma separated list of the file names of attachments to the message.

2c. Body

The main part (“body”) of the message. The body is defined as the first message part (most messages are Multipart) that is text or HTML and not delivery status data. The body under-goes heavy processing, so this field rarely matches the body of the actual message exactly. The most significant piece of processing is that HTML tags are removed.

2d. DeliveryStatusData

Some mail servers actually follow the standards proposed in the RFCs and attach a text file with information about why a message was not delivered for bounces, mail blocks, and message restrictions. In that case, this field contains the contents of that attachment. Otherwise, it is null.

2e. HtmlBody

If the body is HTML, this contains more-or-less the original body of the message, including the HTML tags. If the body is not HTML, it is null. Please refer to the notes in the Body section for more information.

2f. MimeTypes

A comma separated list of the MIME types for each part of the message.

2g. OriginalDate

The date that the original message was sent (extracted from the headers), or the current date if it can’tbe found.

Note: This field was added in build 732. It is currently in beta.

2h. OriginalFrom

The From address of the original message(extracted from the headers), or the To address of the response if there are no headers.

Note: This field was added in build 732. It is currently in beta.

2i. OriginalSubject

The Subject of the original message. We look first for headers of the original message, but look other places if those aren’t found. As a last resort, we use the Subject of the response.

Note: This field was added in build 732. It is currently in beta.

2j. StatusCode

The SMTP status code (eg 5.1.1) from the bounce.

Please remember that this status code is often wrong or misleading, so we strongly encourage you to look at the Category instead of this for doing any processing.

Note: This field was added in build 682

2k. X-ResponseMaster01

A comma separated list of any X-ResponseMaster01 headers found in the bounced message. If you add this header to your outgoing messages, frequently, the bounced message will contain it. Note: You can also use your own header names if you configure a Parameterized Message Field.

2l. X-ResponseMaster02

Same as X-ResponseMaster02, but it looks for the X-ResponseMaster02 header instead of X-ResponseMaster01.

3. Generated Fields

The following fields are generated by ResponseMaster.

3a. Category

The name of the category that the message was placed into. Please refer to the Categories documentation for more information on the definition of each category.

3b. RuleMatched

The name of the categorization rule that the message matched. This is useful for debugging incorrectly categorized messages. The name of the categorization rule is the name of the XML file that defines it (without “.xml”)

3c. OriginalToAddress

The address that the returned message was originally sent to.

This is probably the most important field (aside from the category) for taking action on a message.

For the SubscribeRequest, UnsubscribeRequest, UserReply, and OutOfOfficeReply categories, this field is the FromAddress.

3d. OriginalToAddressRuleMatched

The name of the rule that was used to determine the OriginalToAddress. This can be useful for debugging and also for determining the confidence we have in the OriginalToAddress.

3e. ProcessedTimestamp

The date and time the message was processed by ResponseMaster.

3f. MessageGUID

A random string used to uniquely identify a message. This is generated by ResponseMaster and useful only for debugging.

3g. FromPostmaster

A boolean field that indicates whether the message is from the Postmaster or a mail-daemon (true), or an actual user (false).

3h. FromMobile

A boolean field that indicates whether the message is from the a mobile device. It is not 100% reliable, as it is based primarily on the text that is often automatically included by mobile devices at the bottom of the message, for example

“Sent from my iPhone”

Note: This field was added in build 701

3i. MailboxName

The name of the mailbox that the message was taken from.

3j. Subfolder

The name of the subfolder that the message was taken from.

3k. FieldExtractionError

The text of any error messages encountered while extracting the other message fields. Note: This is almost always Null.