|
Filtering Mail Using Rules
The Pacific Online mail server can automatically filter messages
using automated rules. Rules may be used to perform actions on
messages that meet a certain set of criteria. For example a rule
may forward, delete or send an automatic reply every time a specific
e-mail address sends you a message.
Each rule has a name, priority, a set of conditions, and a set
of "actions". The higher priority rules are checked first: a rule
with the priority level of 9 is applied before a rule with the
priority level of 1.
If a message meets all rule conditions, the rule actions are performed,
and automated processing either stops, or proceeds checking other,
lower-priority rules.
Mail administrators may configure rules for any e-mail address
they administer. Individual users may configure rules for their
e-mail account. For more information on mail administration please
see our mail administration tutorial.
Rules are a powerful feature and should be used with caution.
Incorrect use of rules may result in lost mail.
Creating, Renaming and Removing Rules
Mail administrators may configure rules by clicking on the account
they wish to configure in their Mail Administration Console and
then clicking "Autoresponders/Forwarding & Rules".
Any user may configure rules for their e-mail address through
WebMail. Login to WebMail then
click "Options" then "Autoresponders/Forwarding & Rules".
When the list of rules appears in a browser window, new rules
may be created by typing the rule name then clicking "Add Rule".
You may also use this screen to delete rules and change rule priorities.
After you have modified the rule names and/or priorities, click the
Update button. The list is displayed re-sorted by priority.
Rules with the disabled priority are not applied to the
messages, but they are not deleted from the account rules set, and they
can be reenabled at any moment.
To remove a rule, select the checkbox in the Delete column and click
the "Update" button.
To modify the rule conditions and actions, click the Edit link.
Rule Conditions
Each rule can have zero, one, or several conditions. The conditions
are checked in the same order they are specified. If a message meets all
the rule conditions, the rule actions are performed.
The condition operations is and is not process their
parameters as "pictures": the asterisk (*) symbols in
parameters are processed as wildcards that match zero or more symbols in
the tested string. To check that a string contains the
@thatdomain substring, the is *@thatdomain* operation should
be used, and to check that a string does not end with the somedomain.com substring,
the is not *somedomain.com operation should be used.
The condition operations in and not in process their
parameters as sets of one or more "pictures" separated with the comma (,)
symbols. The tested string is compared to all picture strings. The in
condition is met if the tested string matches at least one picture string.
The not in condition is met if the tested string does not match any
picture string in the specified set.
Note: do not use excessive spaces around the comma signs: spaces before the
comma sign become trailing spaces of the previous picture, and spaces after the
comma sign become leading spaces of the next picture.
The following rule conditions are supported:
From [is | is not | in | not in] string
This condition checks that the message From address is
(or is not) equal to the specified string.
Sample:
This condition will be met for all messages coming from any account
on any of pacificonline.com subdomains.
Sender [is | is not | in | not in] string
Reply-To [is | is not | in | not in] string
To [is | is not | in | not in] string
Cc [is | is not | in | not in] string
Reply-To [is | is not | in | not in] string
The same as above, but the message Sender, Reply-To, To, or Cc address is checked.
If a message has several addresses of the given type, the condition is met if it is true
for at least one address. If a message has no addresses of the specified type, the condition
is not met.
Any To or Cc [is | is not | in | not in] string
The same as above, but all message To AND Cc addresses are checked. If the message
has no To/Cc addresses, the condition is not met.
Each To or Cc [is | is not | in | not in] string
All message To AND Cc addresses are checked. The condition is met if it is true for
each To and Cc address of the message, or if the message has no To/Cc addresses.
Sample:
This condition will be met for messages where all To and CC addresses are
addresses in the mycompany.com domain or addresses in the mydept.mycompany.com
domain.
Return-Path [is | is not | in | not in] string
This condition compares the message "Return-Path" (a.k.a. MAIL FROM)
envelope address with the specified string.
'From' Name [is | is not | in | not in] string
The same as above, but the instead of the address, the "address
comment" (the real name) included in the From address is checked.
Sample:
This condition will be met for messages with the following From: addresses:
From: jsmith@company.com (John J. Smith)
From: "Bill J. Smith" b.smith@othercompany.com
From: Susan J. Smith <susan@thirdcompany.com>
Subject [is | is not | in | not in] string
This condition checks if the message subject is (or is not) equal to
the specified string.
Sample:
This condition will be met for messages with the following Subject fields:
Subject: we urgently need your assistance
Subject: Urgent!
Message-ID [is | is not | in | not in] string
This condition checks if the message ID is (or is not) equal to the specified string.
Sample:
This condition will be met for all messages without the Message-ID flag
and for messages that have Message-ID without the @ sign.
Message Size [is | is not | less than | greater than] number
This condition checks if the message size is less than (or greater
than) the specified number of bytes.
Sample:
This condition will be met for messages larger than 100 kilobytes.
Human Generated
This condition checks if the message is not generated by some automatic
message generating software.
It actually checks that the message header does not contain any of
the following fields:
Precedence: bulk
Precedence: junk
Precedence: list
X-List*
X-Mirror*
X-Auto*
X-Mailing-List
This condition also checks that the message has a non-empty Return-Path.
Header Field [is | is not | in | not in] string
This condition checks if the message RFC822 header contains (or does not contain)
the specified header field. The additional fields added using the Add Header
operation (see below) are checked, too.
Sample:
Any Recipient [is | is not | in | not in] string
This condition compares message "Envelope" addresses and
the specified string.
Each Recipient [is | is not | in | not in] string
The same as above, but the condition is met only if it is met for all message
envelope addresses (if used in an Account-Level Rule - for all
message addresses routed to that account).
Time Of Day[is | is not | less than|greater than]time string
This condition checks the current time of day in the Server time zone. This condition
allows you to compose rules that are applied to messages only at certain times of day.
A time string should be specified as hh:mm or hh:mm:ss, where
hh is the hour, mm - minutes, ss - seconds. Time strings can contain the
am or pm suffix.
Sample:
Current Date [is | is not | less than | greater than] date
This condition checks the current time and date. This condition
allows you to compose rules that are applied to messages only
before or after the specified date and time.
A date string should be specified in one of the following formats:
- DD MM YYYY
- DD MM YYYY hh:mm
- DD MM YYYY hh:mm:ss
- DD MM YYYY hh:mm:ss +ZZZZ
- DD MM YYYY hh:mm:ss -ZZZZ
where:
DD is the day of month
MM is month specified as 3-letter English abbreviation:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
YYYY is the year
hh is the hour
mm is the minute
ss is the second
+ZZZZ or -ZZZZ is the time zone; if the time zone
is not specified, the Server time zone is used.
Sample:
Current Day [is | is not | in | not in] day string
This condition checks the current day of week (using the Server local time zone).
This condition allows you to compose rules that are applied to messages only on certain days of week.
Days should be specified either as numbers (0 for Sunday, 6 for Saturday), or as RFC822 abbreviations
(Sun, Mon, Tue, Wed, Thu, Fri, Sat).
Sample:
Rule Actions
Each rule can have zero, one, or several actions. If a message meets
all the rule conditions, the rule actions are performed.
The following rule actions are supported:
Stop Processing
This action should be the last one in a rule. Execution of this rule
stops and no other (lower-priority) rules are checked for that message.
The message is stored in the INBOX.
Discard
This action should be the last one in a rule. No other (lower-priority) rules are checked for that message.
The message is not stored in the INBOX, but a Delivery Notification
is sent back to the message sender (if requested).
Sample:
IF From is *that_annoying_guy@* THEN Discard
Reject [error message text]
This action should be the last one in a rule. No other (lower-priority) rules are checked for that message.
The message is rejected, and a negative Delivery Notification is sent back
to the message sender.
If the action parameter text is not empty, it is used as the error message text.
You can still store the rejected message using the Store action
before the Reject action.
Sample:
IF Subject is *UCE* THEN Reject please do not send such messages here
Mark operation [, operation...]
This action sets or resets the specified flag(s) for the message. Initially,
the set of message flags is empty.
- The Read operation adds the Read (Seen) flag to the message flag
set, the Unread operation removes the Read (Seen) flag.
- The Flagged operation adds the Flagged flag to the message flag
set, the Unflagged operation removes this flag.
- The Answered operation adds the Answered flag to the message flag
set, the Unanswered operation removes this flag.
When a message is stored in a mailbox as a result of the Store in action,
as well as when a message is stored in the INBOX after all rules
are applied, the message is stored with the specified flag set.
Sample:
IF Sender is *list* THEN Mark Flagged
Add Headers header fields
This action adds RFC822 header fields to the message. Initially,
the set of additional message header field contains the Return-Path field
generated using the return-path in the message envelope.
When a message is stored in a mailbox as a result of the Store in action,
as well as when a message is stored in the INBOX after all rules
are applied, the message is stored with the additional header fields.
Sample:
IF Subject is *purchase*order* THEN Add Headers X-Special-Processing: order
Note: the following actions are not implicit "Discard"
actions, and they do not prevent the original message from being stored in the
INBOX. If you want, for example, to redirect a message without keeping
a copy in your INBOX, specify the Redirect action followed with the Discard
action.
Store in mailbox name
The message is copied to the specified mailbox in your account. The
mailbox should already exist.
If the mailbox name is specified as ~user_name/mailbox_name,
the message is stored in the mailbox_name mailbox in the user_name account.
You should have the Insert access right to that mailbox.
Sample:
IF Subject is *Make*$* THEN Store in ~postmaster/abuse Discard
Redirect to addresses
The message is redirected to one or several specified E-mail addresses.
If several addresses are specified, they should be separated with the comma
(,) sign.
Forward to addresses
The message is forwarded to the specified addresses. The From address
is changed to this account address.
Mirror to addresses
The message is mirrored (redirected) to the specified addresses. Unlike
the Redirect to operation, the Mirror-to operation does not change the
message headers, only the Return-Receipt-to: and Errors-to: header fields
(if any) are removed, and the X-Mirrored-by header field is added to the
"mirrored" messages.
Reply with message text
The specified text is used to compose a reply message. The reply is
sent to the address specified in the Reply-To address of the original message.
If the Reply-To header is absent, the reply is sent to the original message
From address.
The header fields Subject: Re: original message subject and
In-Reply-To: original message-ID are added to the reply message.
The specified message text can contain the following macro symbols that are substituted
with actual data when a reply message is composed:
^S is substituted with the Subject of the original message
^F is substituted with the From address of the original message
^T is substituted with the Date field of the original message
^I is substituted with the Message-ID field of the original message
Sample:
If the specified text starts with the '+' sign, the lines following
this sign are added to the message header. The text should specify the Subject
field, since the system will not automatically add the Subject: Re: original subject
and In-Reply-To: original message-ID fields into the reply message.
The specified header portion can contain additional To, Cc, and Bcc
fields and the reply message will be sent to those addresses (the Bcc fields
will be removed from the message header).
If the specified header does not contain the From field, the account address is
added as the From field. If the From field is specified, the
account address is added as the Sender field.
The ^S and other macro symbols can be used in the additional header fields, too.
An empty line should separate the message body from the additional header fields:
If the specified text starts with the [charsetName] string, the text is
converted to the specified charset (all non-ASCII texts are stored in the UTF-8 charset).
If the text does not start with the '+' sign, the header fields
MIME-Version: 1.0 Content-Type: text/plain; charset=charsetName
are added to the message headers.
If the text starts with the '+' sign, the '+' sign must be specified after the [charsetName] string,
and you should specify the MIME-Version and Content-type fields yourself.
Reply to All with message text
The same as above, but the reply is sent to all addresses listed in
the original message To: and Cc: fields.
React with message text
The specified message text should contain a header, an empty line,
and the message body. The header should contain any number of To, Cc, and Bcc
fields, the Subject field, as well as any number of additional fields.
The composed message is sent to the specified addresses. The system
uses the account address to compose the From field for these reaction messages.
If the specified header already contains the From field, the
account address is added as the Sender field.
The specified message header and the message body can contain macro symbols listed above.
Sample:
The message text can start with the [charsetName] string (see above),
in this case you need to specify the MIME-Version and the Content-Type header fields:
Sample:
|