This article applies to:
- Trustwave SEG/MailMarshal SMTP 6.0
Question:I want messages released in the End User Spam Console to bypass all remaining rules.
- If I release a message in the Spam Quarantine Manager (SQM), it is blocked by another rule.
Causes:There is a limitation within the Spam Quarantine Manager (SQM) functionality in MailMarshal SMTP 6.0, whereby released messages will always continue processing through the remaining rules. There is no option to have the message bypass all remaining rules. For this reason, there is always a chance that the released messages will trigger on one of the subsequent rules it goes through.
Note: If you are using MailMarshal SMTP 6.1, please refer to the following article for configuring the message release behaviour:
Q10190 - How can messages released in the End User Spam Console bypass all remaining rules?
The only workaround for this issue is to mark the messages that are quarantined as Spam. Then if a message is released, subsequent rules can check for the Spam marker. If the Spam marker is present, bypass the rule. If it is absent, the rule is tested as normal.
The steps necessary to implement the workaround are as follows:
Step 1 - Mark all messages which are blocked as Spam.
Use Header Rewriting to insert an x-SpamCat custom header field into the message. In this example, we modify the Block Suspect Spam rule. (See notes below which outline the Header Rewrite rule setup.)
Standard Rule: Block Suspect Spam
When a message arrives
Where the message is incoming
Where message size is less than '100 KB'
And where message is categorized as 'Spam'
Rewrite message headers using 'SpamSuspect'
And move the message to 'Spam - Suspect'
The SpamSuspect Header Rewrite rule will use the following parameters:
Header Rewrite Name: SpamSuspect
Add Custom field: x-SpamCat
Field Parsing Method: Entire line
Insert if missing: SpamSuspect
Step 2 - Create a TextCensor script to detect the absence of the Spam marker (x-SpamCat).
This can be used as a condition in any subsequent rule. Its effect will be to have the rule not trigger if the header field is detected (i.e. subsequent rules will not trigger if the message previously triggered the Block Suspect Spam rule).
- TextCensor Script Name: 'SpamHeaderMissing'
- NOTE *** Apply script to Header only
- Enable special characters: -: (hyphen and colon)
- Trigger level: 5
- Weighting of TextCensor item: 5
- Words and phrases (exactly as written below):
- NOT x-SpamCat:SpamSuspect
Step 3 - Configure subsequent rules NOT to trigger if Spam marker (x-SpamCat) is present.
Add the TextCensor 'SpamHeaderMissing' as a condition to every rule which you want to skip for released Spam messages. Keep in mind the reverse logic here. If the TextCensor triggers, it means the Spam marker is absent and was not previously blocked by the Spam rule.
Standard Rule: Spam - URLCensor
When a message arrives
Where message is incoming
Where message triggers text censor script(s) 'SpamHeaderMissing'
And where message is categorized as 'URLCensor Blacklisted'
Move the message to 'Spam - URLCensor'
- This article was previously published as: