Understanding Rule Actions

MailMarshal rule actions are performed by each rule. MailMarshal performs the actions if the user matching criteria and the other conditions of the rule evaluate true.

You can include more than one action in a MailMarshal rule. MailMarshal can also apply more than one set of actions to a message if more than one rule triggers. However, some actions are terminal actions. If a terminal action is performed, MailMarshal stops processing rules for the affected message.

The following actions are available for selection in Content Analysis Policy rules. Details of each action are given in the text following.

•Archive the message to the Cloud Email Archive Service (post-processing action)

Tip

Tip: You must select exactly one Terminal Action for each rule.

To apply additional rules to a message, select Pass the Message to Rule or Continue Processing.

This action sends one or more email messages based on the templates selected in the rule action panel. To view or edit the details of a particular template, select it, and then click Edit Template. To create a new template, click New Template. The new template will automatically be selected for use when you return to the template selection panel. For further information about templates, see “Notifying Users with Message Templates and Message Stamps”.

This action writes a record classifying this message to the MailMarshal database.

Select one or more logging classifications from the list in the rule action panel. Select the check box to write a logging classification for every component of the message (for example a separate record for each image file in a message). To view or edit the detailed information in the classification, click Edit in the selection panel. To create a new classification, click New in the selection panel. For details on classifications, see “Using Folders and Message Classifications”

Tip

Tip: If a rule moves the message to a folder, MailMarshal automatically logs a classification for the message. In this case, usually you do not need to include a classification action as well.

This action copies the email message file to the specified quarantine folder. You can make the message processing log available in the same folder by selecting the check box at the bottom of the panel. The message log showing how the message was processed will then be available in the Console.

You can specify how MailMarshal will process the message by default if it is released from this folder. Click the Release action link to specify the action. By default when a message is released, MailMarshal continues processing with the rule immediately after the rule that moved the message. For more information, see Help for the Release Action panel.

This action allows you to specify the DMARC disposition that MailMarshal will report to the Domain Owner in DMARC aggregate reports. Select the appropriate disposition (None, Quarantine, or Reject).

This action tags the message for delivery to the configured Cloud Email Archive server. Archive delivery is performed after all rule processing is completed.

This action allows you to avoid sending NDR messages. This action could be used for inbound messages where MailMarshal has a valid list of accepted recipients and is responsible for sending NDRs. In this situation any refusal from the internal mail server is taken as an error or unexpected blockage that should not be reported to the sender.

Information

Note: This action should not be applied to outgoing messages.

This action runs an external application. The application can be a Windows executable or batch file. For instance, an external command to release a message from quarantine is included with MailMarshal.

Choose one or more commands to be run from the list of pre-defined external commands. For information about defining external commands, see “Extending Functionality Using External Commands”. To run the same application with different parameters under different conditions, use more than one external command definition.

You can also choose to repack the message when a command action succeeds. Use this setting if you have created a custom external command that could make changes to the message content.

Tip

Tip: To minimize processing overhead, only repack when required. For more details see Help.

This action adds the attachments to the MailMarshal list of “valid fingerprints” (normally used for images or other files which require special treatment, such as company logos). In the rule action panel, choose whether to add all attachments, or only images, to the list. For more information, see the rule condition “Where attachment fingerprint is/is not known.”

This action allows you to add members to a MailMarshal user group based on any rule criteria, such as the sender or recipients of a message. You can use this action to automate the generation of lists of safe senders or blocked senders, based on other features of messages.

Information

Note: When you use this action to add members to a group, you should consider enabling automatic pruning to limit the size of the group. See “Pruning a MailMarshal Group”.

In the rule action panel, select one or more groups MailMarshal should add users to. Choose whether to add the sender or recipients.

In the rule action panel, choose one or more message stamps to be used. A stamp will add text at the top or bottom of the message as selected when it is created. To view or edit the details of a particular message stamp, select it, and then click Edit Stamp. To create a new stamp, click New Stamp; the new message stamp will automatically be selected when you return to the stamp selection panel. For details on message stamps, see “Notifying Users with Message Templates and Message Stamps”.

This action removes one or more specific attachments from a message. Only the attachments that triggered the rule conditions for this rule will be stripped. This action would typically be used to remove attachments of specific file types or file names

Information

Note: MailMarshal does not save stripped attachments. If you use this action, normally you should copy the original message so that you can retrieve the attachment if necessary. You should stamp the message to inform the recipient that an attachment has been stripped.

You can use this action in combination with a virus detection condition to strip infected attachments and allow the message to be delivered. To ensure that the message no longer contains a virus, you must include another virus scanning rule to run after the stripping action. Otherwise MailMarshal treats the message as possibly infected and will move it to the Dead Letter\Virus folder.

Use this action to modify, add, or delete any message header, including custom headers. You can repair blank or missing headers, insert a notification into the subject, or reroute email.

Within the rule action panel, click Add to create a new header rewrite rule. For more information about this adding and editing header rewrite rules, see “Using Rules to Change Headers”.

You can include more than one Rewrite rule in the same action. If you include more than one Rewrite rule, the order of application of the rules can be significant. The rules listed first in the Header Rewrite panel will be evaluated first. Adjust the order of evaluation by selecting a rule and using the up and down arrows on the panel.

Information

Note: Header Rewrite rules are only available within the rule where they are created. To perform the same action in more than one rule (or within a rule and the Header Rewrite function of the MailMarshal Receiver), create a Header Rewrite rule in each place.

Use this action to add text at the beginning of the message subject. You can use this action to provide results of message scanning (such as “external sender” or “suspect spam”) in a way that the recipient will easily see.

This action can be used to protect users against malicious websites listed in the Trustwave Blended Threats URL database. The action modifies web links (URLs) in the subject and body of email messages, so that when a user clicks the link, the URL is tested by the Trustwave Blended Threat service.

This action can only be used in rules that affect inbound messages (messages addressed to your local domains).

Information

Note: If the Blended Threats service is not licensed, you cannot save a rule that uses this condition.

You can exclude trusted URL domains from rewriting and scanning. For more information, see “MailMarshal Properties – Advanced”.

For information about what is rewritten and what is excluded from rewriting by default, see Trustwave Knowledge Base article Q14548.

For more information about Blended Threats Scanning, see Trustwave Knowledge Base article Q12876.

This action sends a copy of the message to a specific server. Unlike the BCC action, this action does not modify the recipient fields.

Tip

Tip: You can use this action to provide a true copy to an external service.

This action sends a blind copy of the message to one or more email addresses. Enter each address as a complete SMTP address (for example user@domain.topdomain). Separate multiple entries using semi-colons. You can also use variables in this field. The original message will not be modified in any way by this action, so the original recipient would not know a copy had been taken.

Tip

Tip: You can use this action in combination with “delete the message” to effectively redirect a message to a different recipient.

This action allows a message to be marked for sending using TLS. If the message cannot be delivered using TLS for any recipient, it will not be sent to that recipient. You can use this action to implement specific TLS requirements based on any rule condition such as the sender, recipient, or message content.

You can also require TLS for messages sent to all users in specific domains. See MailMarshal Properties > Array Properties > Sender Properties > Outbound Security (TLS).

Information

Note: This action is not a terminal action. It sets the requirement of TLS delivery for the message, but it does not send the message immediately or stop rule evaluation. MailMarshal continues to evaluate remaining applicable rules.

This action allows a message to be marked for sending to a selected email server. You can use this action to implement dynamic routing based on the recipient, the message headers, or the content of a message.

In the rule action panel, enter a host name or IP address, and a port number, to which MailMarshal should send the message. If you entered a host name, select a protocol to use for delivery (IPv4, IPv6, or either). MailMarshal uses this address when it attempts delivery, even if the message is “parked” first, or quarantined and later released. If several rules invoke this action, MailMarshal uses the last address.

Information

Note: This action is not a terminal action. It sets the route for the message, but it does not send the message immediately or stop rule evaluation. MailMarshal continues to evaluate remaining applicable rules. Generally you should not use the actions Delete the message and Set message routing to host for the same message. If you do, the message will be deleted and not delivered.

If you are integrating MailMarshal and MailMarshal Secure Email Server (for encryption and decryption processing), check the box This is a MailMarshal Secure Email Server.

Information

Note: If you are not directing mail to a MailMarshal Secure Email Server, ensure this box is not checked. For more information about this feature, see the MailMarshal Secure Email Server User Guide.

This action allows you to skip DANE validation (when DANE is enabled). You can use this action in a rule with User Matching. The group used for matching should contain domain wildcard entries. For more information about using DANE with MailMarshal, a list of the reason codes, see Trustwave Knowledge Base article Q21213.

This action signs the message according to the DKIM standard. Signing of the message takes place after all rules are processed.

Information

Note: Before using this action, you must import a private key for the local domain from which the message was sent. You must also publish public key information in a DNS TXT record so that signed messages can be validated. See “Configuring DKIM”.

You can set the action to take if signing does not succeed (continue processing, or move the message to a folder, and optionally send an email notification). For details of the settings, see Help.

This action moves the email message file to the specified quarantine folder. To make the message processing log available in the same folder, select the check box at the bottom of the rule action panel. The message log explaining how the message was processed will then be available in the Console. If a new folder is required, click Add to open a panel that allows you to create a folder.

You can select a “category” that will be used to generate Dashboard graphs and other message statistics.

This is a terminal action. MailMarshal does not process any further rules for a message if this action is performed (unless the message is later released).

This action moves the email message file to the specified parking folder for release according to the schedule associated with that folder. To create a new folder with a different schedule, click Add to open a panel that allows you to create a folder.

This is a terminal action. If this action is performed, MailMarshal does not process any further rules for a message until the message is released from the parking folder. When a message is released from a parking folder, MailMarshal continues processing with the rule after the rule that parked the message.

This action moves the email message file to a special “hold queue” for the specific rule. You can configure a hold period after which the message will be re-submitted to the rule that caused the hold.

You can configure the number of times MailMarshal should retry the rule before continuing to the next rule. For details of the settings, see Help.

Caution

Caution: Use this action only with a rule condition that can change when re-evaluated (such as scanner signature out of date conditions). If you use this action with a condition that never changes, affected messages will be delayed for no benefit.

This is a terminal action. If this action is performed, MailMarshal does not process any further rules for a message until the hold time expires. When a message is released from the hold queue, MailMarshal continues processing with the rule that caused the hold. If the number of retries is exceeded, MailMarshal continues processing with the rule after the hold rule.

You can force an immediate retry of held messages using the Hold Queues listing in the Console.

This action deletes the email message file. The message will not be sent to its original destination.

You can select a “category” that will be used to generate Dashboard graphs and other message statistics.

This is a terminal action. MailMarshal does not process any further rules for a message if this action is performed.

This action allows a choice of which further rules to apply. Several choices are available in the rule action panel:

•Skip to the next policy group (do not apply further rules in this policy group).

•Skip all remaining rules (pass the message through to the intended recipients).

Information

Note: It is only possible to skip to a rule which is evaluated after the current rule. The order of evaluation can be changed. See “Understanding the Order of Evaluation”.

When skipping to a rule in a different policy group, remember that the parent policy group conditions can prevent its having any effect. For instance, skipping from the MailMarshal default Policy Management (Inbound) policy group to the Policy Management (Outbound) policy group is allowed, but rules in the Outbound policy group will have no effect on inbound messages.

Information

Note: These actions take effect immediately. If you use both types of actions in Connection Policy rules, check the order of evaluation carefully to ensure that MailMarshal checks for any exceptions first.

This action directs MailMarshal to accept the message for delivery subject to Content Analysis Policy rules. The message could be relayed to an address outside the MailMarshal local domains. This condition can be used in conjunction with the condition “Where sender has authenticated” or an IP address match, to allow relaying by specific email users.

This action directs MailMarshal to refuse the message. MailMarshal sends a SMTP response refusing delivery to the sending server. This action can be used in conjunction with a size-limiting condition to conserve bandwidth, or to refuse messages sent from specific problem addresses as detected by User Match, IP Address, or Reputation Service conditions.

On the rule action panel, enter the SMTP response code and message to be returned as the message refusal.

•Message Number: Enter a SMTP message number (between 400 and 599) to return. The default number 550 is a standard SMTP “message refused” response.

Information

Note: If you use a number in the 400 range the sending server will treat the refusal as temporary and will retry the delivery later. If you use a number in the 500 range the sending server will treat the refusal as permanent and will mark the message as undeliverable.

•Message Description: Enter a short message giving details of the reason for refusal. Within this message, the following variables are available:

Table 14: Variables for message description
Variable	Data inserted
{Recipient}	The “To:” SMTP address of the original message.
{Sender}	The SMTP address of the sender. This is the address in the “From” field unless it is empty, in which case the “Reply to” address is used.
{SenderIP}	The IP address of the sender.

This action has no effect on the message. It can be used with a logging-only condition such as “Where the SPF evaluation is set to log only.”

The following actions are available for use in Dead Letter Policy rules. Note that in some cases Dead Letter actions allow fewer options than the corresponding Content Analysis actions.

Caution

Caution: Messages that are dead lettered are not scanned for viruses, or checked by any other content rules (in most cases), because MailMarshal could not process them. If you choose to release or re-route these messages, ensure that the recipients are aware of the risks.

Tip

Tip: You must select exactly one Terminal Action for each rule.

To apply additional rules to a message, select Pass the Message to Rule or Continue Processing.

Tip

Tip: You can use this action in combination with “delete the message” to effectively redirect a message to a different recipient.

This action writes a record classifying this message to the MailMarshal database.

Tip

Tip: If a rule moves the message to a folder, MailMarshal automatically logs a classification for the message. In this case, usually you do not need to include a classification action as well.

Tip

Tip: You can use this action in combination with “delete the message” to effectively redirect a message to a different recipient.

This action allows a message to be marked for sending to a selected email server. You can use this action to route dead letters to a different server (for additional security, since the content could not be scanned).

MailMarshal uses this address when it attempts delivery, even if the message is passed through.

Information

This action moves the email message file to the specified folder. Select one of the pre-configured dead letter folders.

This is a terminal action. MailMarshal does not process any further rules for a message if this action is performed.

This action deletes the email message file. The message will not be sent to its original destination and will not be available for further review.

When you select this action, you can choose not to create an entry in the MailMarshal SQL logging database for the deleted message. By default MailMarshal logs information about deleted messages so that you can report on the reasons for deletions.

Caution

Caution: If you choose not to create a SQL database entry, you will reduce database usage, but you will seriously affect your ability to audit MailMarshal activity. Trustwave recommends that you create SQL entries.

This is a terminal action. MailMarshal does not process any further rules for a message if this action is performed.

This action allows you to specify that a deadlettered message should be passed through to the original recipient addresses. The destination is subject to the “set message routing to host” action.

Trustwave MailMarshal 10.1.0 User Guide March 2024
< Previous Section | Next Section >
Full document: see MailMarshal Documentation.