Mailbox rules let you configure any actions, replies, or both, that must occur for messages retrieved from a mailbox.
Mailbox rules let you perform any of the following email actions:
This action is useful for system-level messages such as Out of Office or Mail Delivery errors.
This action typically handles email replies where the object identifier is embedded in the email. If no object identifier is present, the failure response message is typically sent.
This action is the standard behavior of the mail daemon (Mail Eater) in which the email does or does not contain Text API keywords.
The table (usp_mailbox_rule) maintains the rules which apply to the connection to each mail server account (usp_mailbox)—rules belong to specific mailboxes.
CA SDM provides predefines rules which you can customize or you can create mailbox rules.
You can create rules that recognize specific keywords or elements of the incoming messages, and perform any actions, replies, or both, that must occur for incoming messages which contain those keywords or elements.
Note: The rules that are applicable for one mailbox cannot be associated with another mailbox. To reuse the same rules for a different mailbox, recreate them for the other mailbox. You can also copy the existing mailbox.
Important! We recommend that you set the associated mailbox to inactive before you configure a mailbox rule. Otherwise, any messages that the mail server retrieves between your first change and the last change are processed with whatever rules are in effect.
To create a mailbox rule
The Mailbox Rules List page appears and lists rules.
The Mailbox Rule Detail page appears.
The mailbox rule is created and in effect.
Complete the following mailbox rule fields, as appropriate:
Specifies the sequence number of the rule. Messages are checked against rules in sequence number order from lowest to highest.
Specifies the mailbox to which this rule belongs.
Sets the rule to active or inactive.
Specifies what part of the email to search for the filter pattern, for example, Subject contains. For more information, see the Pattern Matching in Mailbox Rules topic.
Specifies a regular expression string to match with the email content. For example, [ \t\r\n]request[ \t\r\n]. The placeholder {{object_id}} lets you specify the artifact value for the Text API to use for associating the message with a specific ticket. For more information, see the Filter String Object Identifier Restrictions and Special Characters in Regular Expressions topics.
Specifies whether to consider letter case when matching patterns.
Specifies the action to take when the filter criteria matches, for example, Create/Update Object.
Note: For information about rule actions, see the Administration Guide.
Displays the type of ticket object to which message actions apply, for example, Request.
Sets the minimum type of artifact checking that you want to allow:
Specifies no validation of artifacts. This value is the same as not adding the keyword to the input file. Also accepts Text API ticket ID commands.
Validates a ticket against the hash for confirmation. If confirmation fails, the artifact is considered invalid and the email fails filtering where filtering is looking for an artifact ({{object_id}}).
Validates the ticket number from an encrypted data block. If the value is not a valid encrypted ticket number, the artifact is considered invalid and the email fails filtering where filtering is looking for an artifact ({{object_id}}).
Note: Types that are more secure than what is set are allowed. In other words, if you set the minimum type to PROTECTED, then both PROTECTED and SECURE are allowed, but NONE is not. Also, if PROTECTED or SECURE are selected, Text API ticket ID commands are not accepted. For more information about the artifiacts, see the Artifacts Use Considerations topic.
Specifies a notification method to send an automatic response. For example, Email. If you do not set this option, no response is returned. The response indicates success or failure of the actions performed for the message, and is separate from any notifications. If you are using multiple mailboxes, we recommend you to use the notification method to configure email replies.
Specifies a subject line for the reply, for example, Service Desk Response.
Write email text to the standard log (stdlog) if the filter matches.
Specifies a prefix to add when writing email text to the standard log entries. Use this option to enable matching log entries to rules.
Adds the subject line from the original message to the message body before processing. You can append, prepend, or not add a subject line. The subject line is attached to either the ticket Description or a Log Comment, depending on the actions for the message.
Specifies additional default commands for the Text API when the filter matches. Combines with the contents of the [EMAIL_DEFAULTS] section of the text_api.cfg file. The TextAPI Defaults field includes TextAPI keyword commands that are applied to a ticket when it is created from an email that matches a mailbox rule. The commands are not applied when the message affects an existing ticket.
To specify TextAPI Defaults commands, place each command on a separate line in the TextAPI Defaults field. Format the commands as follows:
OBJECT.FIELD=value
Note: Do not include a leading percentage symbol (%), which is required only for corresponding commands that are embedded in the body of the email.
For example, format the commands as follows:
REQUEST.PRIORITY=3
PROBLEM.CATEGORY=Facilities
INCIDENT.GROUP=Plumbing
Specifies additional Ignore Details for the Text API when the filter matches. Combines with the contents of the [EMAIL_IGNORE_INCOMING] section of the text_api.cfg file.
The TextAPI Ignore Incoming field lists TextAPI keyword commands that are not permitted to be used in the text of the incoming email message. Any commands that are listed in this field are ignored when they are found in an incoming email message.
To specify TextAPI Ignore Incoming commands, do the following steps:
OBJECT.FIELD
Note: Do not include a leading percentage symbol (%), which is required only for the corresponding commands that are embedded in the body of the email.
For example, format the commands as follows:
CHANGE.ASSIGNEE
PROBLEM.GROUP
REQUEST.EFFORT
Specifies information about the rule.
Specifies the plain-text contents of a reply message when the message is processed successfully. For example:
Thank you for submitting an update to your request. A support technician will contact you within the next 24 hours.
You can also enter a notification phrase, if already created. For example, you can use a notification phrase for email auto-replies.
Thank you for submitting your request.
@{notification_phrase[notification phrase code].phrase}
Specifies HTML contents of a reply message when the message processes successfully. The following options let you edit and preview HTML text:
Opens the HTML Editor which you can use to format the HTML.
Previews the HTML.
Shows the HTML source.
You can also use a notification phrase, for example,
Thank you for submitting your request.</p>
@{notification_phrase[notification phrase code].phrase}</p>
Specifies the plain-text contents of a reply message when the message does not process successfully. You can also enter a notification phrase, if already created. For example, you can use the following text:
Thank you for submitting your request.
@{notification_phrase[notification phrase code].phrase}
Specifies HTML contents of a reply message when the message does not process successfully.
An email artifact refers to something that arises from the mail process, for example, an email address that is included in a forwarded email. The Text API uses artifacts that contain a ticket ID (such as a reference number) for reply support. When the ticket ID is found, an existing Text API keyword (such as %INCIDENT_ID) is set and added to the input for the Text API. The Mail Eater identifies that a reply is associated with a particular ticket by finding the artifact in the message.
The Mailbox rules let you specify the artifact and the value that the Text API uses. For example, you can define a rule for incidents as Incident:{{object_id}}%. When a rule finds Incident:1234, the Text API uses %INCIDENT_ID=1234 (1234 is the ref_num for the Incident). Because the artifact must be unique in an email and easy to find, you can make the artifact more distinctive such as %Incident:{{object_id}}%. A percentage sign (%), whitespace, or some other character that cannot appear in an artifact value must follow {{object_id}}. Uppercase and lowercase letters, numbers, forward slashes, commas, and plus symbols are potentially part of a value. The secure artifacts are Base64-encoded after encryption. If you do not use the Secure artifacts, the characters that follow the artifact must not be contained in the ticket ID suffix, if any, which has been configured for that type of ticket.
When using the filter string of the mailbox rules to identify the ticket ID Artifact, the keyword {{object_id}} represents the position in the filter string where the ticket ID artifact is expected. This keyword is case-sensitive, even if the mailbox rule is not.
Example: Email Artifact Use
The following example shows an ARTIFACT format for use in a mailbox rule for a change request ticket.
Usage: %REQUEST=@{call_req_id.ref_num}%
Example: %REQUEST=1234%
When you construct the filter string of the mailbox rule, consider the following conditions:
Mailbox rules use regular expressions for pattern matching. Consider the following whitespace characters that apply to regular expressions in mailbox rules:
Specifies a horizontal tab.
Specifies a carriage return character.
Specifies a line feed or new line character.
The characters that represent line breaks in text can vary with the operating system, mail server, and mail client, for example:
In certain circumstances, the mail processing elements of CA SDM exchange substitute one of these line break characters for another to establish or maintain a distinction between different text elements, such as message text and attached parameters. As a result, when you want to use a line or paragraph break, build your filters so that either \r or \n can be matched, whichever is found. If you want to indicate a line break between two keywords, build your filters so that a sequence of one or more \r and \n characters can be matched.
Line wrapping by the mail client that sends a message can cause unexpected line breaks to appear in the middle of the text which is expected to match your filter string, when the filter string searches the body of the message. A space can change to a carriage return, line feed, or both, or the carriage return, line feed, or both can be inserted after a space. If a message is composed in HTML, and contains bulleted or numbered lists or indented paragraphs, tabs can also be present after the mail client converts and sends the message. When you include spaces in the middle of a filter string, use a Regular Expression block which represents any whitespace of variable size. This block is [ \t\r\n]+ (open-bracket, space, backslash, t, backslash, r, backslash, n, close-bracket, plus sign), and represents any sequence of one or more spaces, tabs, carriage returns, and line feeds.
Example: Use [ \t\r\n] to Match a Keyword Exactly
This example demonstrates how you can use whitespace characters to match the keyword "request" and not match other possible keywords such as the following words:
requester requesting requested orequestra
To match only the keyword request, precede and follow the keyword request by one or more whitespace characters as follows:
[ \t\r\n]request[ \t\r\n]
The Mail Eater matches only the word request or the word as part of a sentence, and not as part of another word such as requester.
Restrictions apply to the mailbox rule filter strings which determine the object identifier (for example, %Incident:{{object_id}}%) in an email. Text that surrounds an object identifier ({{object_id}}) must be unambiguous in both content and length; the text must clearly define the beginning and end of the ticket ID artifact value that is between the text.
The following restrictions apply to how the Mail Eater interprets the start of the ticket ID artifact value:
The following restrictions apply to how the Mail Eater interprets the length of the ticket ID artifact value:
Any of these characters can exist within the ticket ID artifact value. When a bracketed set (several characters between brackets, of which the filter check can match any one), precedes or follows the {{object_id}} placeholder, the bracketed set must not contain any of these characters.
Pattern matching for the filters in mailbox rules follows the rules for ASCII Regular Expressions with C-style special characters.
Important! We recommend that you are familiar with Regex syntax to use special characters in regular expressions.
For example, consider the following special characters for Regex patterns that apply to regular expressions in mailbox rules:
Specifies a horizontal tab. In filter strings for mailbox rules, \t matches the beginning and end of text (and tabs), and is specific to the Mail Eater.
Specifies a carriage return (return to the beginning of the current line).
Note: Do not use \r for searching message subjects or sender addresses.
Specifies a newline (combination of line feed and carriage return).
Note: Do not use \n for searching message subjects or sender addresses.
\t, \r, and \n are the special characters that occur most often in regular expressions for mailbox rules.
Example: \t, \r, and \n Use
[ \t]request[ \t]
Searches text for the word request. The brackets match any one character from the set, including the space, so [ \t] matches a space or a tab.
[\r\n]+critical[ \t\r\n]
Searches text for the word critical at the start of a line, the start of the message, or as the entire contents of a line. The brackets match any one character from the set, and the + (plus sign) matches one or more of the previous, so [\r\n]+ matches one or more carriage returns and newlines.
|
Copyright © 2013 CA.
All rights reserved.
|
|