The following article provides information and examples on how to configure custom mail gateway rules. For the Mail Gateway service of the Barracuda NG Firewall, you can configure the following types of rules:
- Pre Settings – These rules are processed before all other mail gateway settings.
- Post Settings – These rules are processed after all other mail gateway settings.
In this article:
Configure Custom Rules
To configure custom rules for the mail gateway, complete the following steps.
- Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual server > Assigned Services > Mail-Gateway > Mail Gateway Settings.
- In the left menu, click Advanced Setup.
- Click Lock.
In the Expert Settings section, configure your custom rules. In the following table, complete the steps for the type of rules that you want to configure.
Task Steps To configure Pre Settings.
- From the Enable Pre Settings list, select yes.
- Next to Pre Settings, click Set or Edit.
- In the Pre Settings window, configure your custom rule.
To configure Post Settings.
- From the Enable Post Settings list, select yes.
- Next to Post Settings, click Set or Edit.
- In the Post Settings window, configure your custom rules.
The custom rules can be added to all five levels of an SMTP mail transmission. For more information, see RFC 2821 at http://www.ietf.org/rfc/rfc2821.txt.
Level Type Description 1
This is the connection level of the mail gateway server (like that banned hosts rule will affect the connect level).
This is the SMTP greeting level (SMTP "helo" or "ehlo" command).
In this level, the sender of a mail is announced (SMTP "mail from:" command. For example, banned sender rule will affect the sender level).
The recipient of a mail is announced in this level (SMTP "rcpt to:" command. For example, banned recipient or rewrite recipient rule will affect the recipient level).
In the last level of a SMTP transmission, the mail body (data) is transmitted. For example, the subject is part of the mail body (banned subjects rule will therefore affect the data level).
- Click OK.
- Click Send Changes and Activate.
Abstract Rule Language
The following sections provide information on the syntax and commands that can be used when configuring custom rules.
- Comment lines are ignored by the abstract rule parser. Format comment lines as follows:
// Comment line
- Separate expressions with spaces. For example, a double-slash (
//) must be followed by a space.
- Quote string variable values. For example:
- Separate parameters with a comma (
An expression assigns a value to an variable. You can combine multiple expressions with logical operators.
You can use the following variables and operators:
Text Operator. Equality.
Text Operator. Inequality.
The return code of rule parser.
The IP address of peer (client).
The hostname of peer (client).
0=outbound; 1=inbound (that is mail reception on internal IP).
The SMTP greeting name (ehlo/helo).
The sender email address after rewriting.
The local part of the sender email address after rewriting.
The domain of the sender email address after rewriting.
The recipient email address after rewriting.
The local part of the recipient email address after rewriting.
The domain of the recipient email address after rewriting.
sender (3) rcpt (4)
Reflects the email address before rewriting.
The subject of the mail body.
ACTION command specifies the actions to be performed by the Mail Gateway service. Lines with the
ACTION command require a semicolon (
;) at the end of the line. Expressions with the
ACTION command are space-delimited.
You can use the following actions:
|View rule debug messages in logs.|
|View SMTP debug messages in logs.|
|When specified in level 3, it affects the whole mail object. Otherwise, it affects the current rcpt.|
Target IP address.
When specified in level 3, it affects the whole mail object. Otherwise, it affects the current rcpt.
|Close the connection.||All||-|
|Deny mail delivery of current mail.|
|Drop current recipient.||4||-|
|If specified in level 3, rewrite sender (-part). Otherwise, rewrite current recipient (-part)|
|Mailboxes, local-parts, or domains.|
|Clone current recipient (-part).||4|
List of mailboxes, local-parts, or domains.
Assign scheduling priority. Allowed parameters:
Trigger an event. Allowed parameters:
Event type and description.
An IF statement is comprised of the following:
- A test expression that specifies conditions to be met.
- A statement that declares actions to be performed when the conditions are met.
You can use the following statements:
RETURN command exits the current level function, so subsequent instructions will no longer be performed.
Lines with the RETURN command require a semicolon (;) at the end. Expressions with the
RETURN command are space-delimited; this is also valid for the semicolon after the command:
Example Custom Rules
The following sections provide examples of the custom rules that you can configure for the Mail Gateway service.
Denying Mail with a Specific Greeting Name
Mail delivery from mail servers that send "spam" as the greeting name should be denied. Enter the following rule language code into the Helo field of the Pre or Post Settings:
IF (helo = "spam") THEN ACTION ("quit", ""); RETURN; ENDIF
Changing the Priority of an Email
The priority of emails arriving from a specific address should be changed to "high". Enter the following rule language code into the Sender field of the Pre or Post Settings:
IF (from = "email@example.com") THEN ACTION ("priority", "HIGH"); ENDIF
Cloning an Email from a Specific Address
Emails arriving from a specific address should be cloned and distributed to multiple recipients. Enter the following rule language code into the Recipient field of the Pre or Post Settings:
IF (from = "firstname.lastname@example.org") THEN ACTION ("clone", "email@example.com, firstname.lastname@example.org,email@example.com"); ENDIF
Spam emails should be redirected. The following rule language code can be entered in any expert Pre Settings. The following syntax applies:
ACTION ("redirect", "/opt/phion/bin/spam_redirect.sh");
For this example, the referenced
spam_redirect.sh script that is required for email redirection could read as follows:
#!/bin/bash # $1 ... path to mail files # $2 ... spoolid ## this script redirects mails with "[SPAM]" within subject # to an archive mail account DSTMAILBOX=mailboxname DSTDOMAIN=domainname DSTIP=serverip BODY_FILE=$1$2".body" ENV_FILE=$1$2".env" TMP_FILE="/tmp/"$2".env" SUBJECT=`cat $BODY_FILE | formail -c -x subject | grep "[SPAM]" | sed -e 's/.*\[SPAM\].*/[SPAM]/g'` if [ "_$SUBJECT" = "_[SPAM]" ]; then # redirect to spam mail box # 1. remove lines that start with "rcpt" # 2. insert infos for delivery to spam archive # (assumption: $DSTIP is an internalmailserver) mv $ENV_FILE $TMP_FILE cat $TMP_FILE | grep -v -e "^rcpt" -e"^recipient" -e"^numrcpts" > $ENV_FILE echo "numrcpts 1" >> $ENV_FILE echo "recipient" >> $ENV_FILE echo "rcpt id 0" >> $ENV_FILE echo "rcpt user $DSTMAILBOX" >> $ENV_FILE echo "rcpt domain $DSTDOMAIN" >> $ENV_FILE echo "rcpt status 0" >> $ENV_FILE echo "rcpt deliverdirect $DSTIP" >> $ENV_FILE echo "rcpt bindtype 1" >> $ENV_FILE echo "rcpt bind intern" >> $ENV_FILE rm -f $TMP_FILE fi echo "0"