Page 25 - Mercury Manual.book

The Mercury Core Module 20
Alerts and Notifications

contents of a text file to the sender when it receives any message, while a TFILE: alias re-
turns a formatted message using a template file (see above).

To create a FILE: or TFILE: alias, enter the alias as normal, but for the real world address
enter either TFILE: or FILE: followed immediately by the path to the file you want to use.

Examples:
info = FILE:\\myserver\sys\system\mercury\info.txt
faqs = TFILE:r:\system\mercury\faq.mer
Note that it is very important that the file specified in a TFILE: alias is actually a template
file: if you do not specify a valid template file, Mercury may crash when it tries to send the
reply.

TFILE: and FILE: aliases are completely secure - they are only accepted if they actually ap-
pear in your alias file: a user cannot send a message to a TFILE: address to obtain files ille-
gally from your system.

FILTER: aliases are used to associate a set of Mercury filtering rules with an address on your
system. This powerful feature allows you to create addresses that are completely automated,
and which can perform extremely complex processing on incoming mail messages. For the
same general security reasons as for TFILE: and FILE: aliases, filtering rules can only be
tied to addresses through aliases – doing it this way removes the possible security threats im-
plicit in allowing users to create dangerous rule sets for their accounts. To create a FILTER:
alias, first create and edit a Mercury General Rule set (see the section Mail Filtering later in
this manual for more information on this). When you have done this, open the alias editor
window and create a new alias. For the alias, enter whatever real-world mail address you
wish to trigger the rule set, and for the real address portion, enter FILTER: followed imme-
diately by the full path to the file in which you saved the Mercury rule set.

Alerts and Notifications

If you have purchased a license for your copy of Mercury, you can enable Mercury's auto-
matic notification service. This process periodically checks with the Mercury development
team to see if there have been security bulletins or alerts, notifications of new releases or up-
dates, or simply general news about the system.

The presence of a valid license will enable the controls in this dialog. Once you have specified
local recipients in the Distribute advisories to... field, Mercury will then poll using the period
you have defined: if the development server reports new advisories of the types in which you
have specified interest, they will be automatically downloaded and distributed to the users
you specify (notifications take the form of standard e-mail messages).

Important note: In order to implement this feature, Mercury "calls home" - that is, it estab-
lishes a connection to the Mercury development server, validates its license information with
that server, then retrieves any new advisories the server offers. Mercury does not supply any
other information or data from your system or environment during this process. If you work
in a corporate, military or government environment, you should check with the appropriate
authorities in your organization that you can implement this type of "phone home" operation.
If you run a firewall, you must also allow your copy of Mercury to establishing outgoing con-
nections to Port 110 (POP3) on the notification host through your firewall.