1. Pure Message Fields
The following fields come from the message, and are not manipulated by ResponseMaster.
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.
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.
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.
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.
The timestamp when the message was sent.
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.
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 “”.
A comma separated list of the file names of attachments to the message.
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. BodyWithoutOriginalMessage
This is ResponseMaster’s best attempt to extract the message body from the bounce (or reply) without including the content of the original message which you sent.
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.
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.
A comma separated list of the MIME types for each part of the message.
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.
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.
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.
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
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.
2m. 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.
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.
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”)
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.
The date and time the message was processed by ResponseMaster.
A random string used to uniquely identify a message. This is generated by ResponseMaster and useful only for debugging.
A boolean field that indicates whether the message is from the Postmaster or a mail-daemon (true), or an actual user (false).
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
The name of the mailbox that the message was taken from.
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.
Contents
ResponseMaster provides the following message fields. Please refer to Advanced Topics for information about how to create your own message fields.