The FI and MU mail systems provide some services to limit the spread of infected mail and to at least partially detect spam. The control takes place on two levels: the first is the university mail server and the second is the faculty mail server.
This protection is not and cannot be 100%. Still: do not open attachments you have received from unknown senders (or from apparently known senders where the message looks suspicious).
Checking incoming mail at the faculty level
If the email originates from an external network and is delivered to the destination mailbox by the Anxur or Aisa server (this includes forwarding using Procmail), it will by default pass antispam checking on the following stages:
Anti-spam control settings
The coarsest configuration of the filter can be done using https://fadmin.fi.muni.cz/auth/sys/mail_nastaveni.mpl. Its capabilities include:
- Specification of the mailbox where dSpam and/or SpamAssassin will deposit spam
- disabling either or both filters completely
- controlling the filter's handling of duplicate mail
- and more
Settings for drag-and-drop message retrieval
If you are accessing mail using
IMAP (this is true even if you are using
a web client), you can set up
dSpam re-learning by moving a message to re-learn the dSpam filter just by dragging the message to/from the spam folder (by default
mailbox.spamor after scrolling
mailbox.spam.1). You then do not have to deal with forwarding spam and non-spam messages to
Redirecting the message
You can also re-learn the statistical filter by redirecting (redirect, bounce) messages to
notspamhh83UdsTf@fitgWP_5B2j.muniv20oUgct4.cz. You can do this in
b key, in Thunderbird the
Simple Mail Redirection plugin makes this function available.
Whitelisting and blacklisting
A whitelist is a list of addresses from which no incoming mail should be marked as spam. There can be multiple entries in the whitelist that mark the entire domain using the '*' character - so the entry "
*@example.muni.cz" whitelists all addresses in the
example.muni.cz domain. There are two levels of whitelist - global (maintained by CVT, valid for all email users on Anxur or Aise) and user (valid for incoming mail of a specific user). On FI, the whitelist is implemented using the SpamAssassin program (see below). You can define your whitelist by adding any number of lines of the following form to the
whitelist_from WhitelistovanyOdesilatel@example.com whitelist_from *@whitelistovana.domena.example.com
In order for this configuration file to be taken into account:
- set the home directory and the
~/.spamassassindirectory to "
x" for the user
setfacl -m u:spamd:x ~ ~/.spamassassin
- assign the right "
r" to the file
~/.spamassassin/user_prefsfor the others:
chmod o+r ~/.spamassassin/user_prefs
In a similar way, you can whitelist based on the text in the mail header
Subject. Any mail whose subject line contains the specified text as a substring will also avoid antispam checking. The format of the lines is as follows:
Blacklist (by sender and by subject) has a dual function to whitelist: a matching message will be marked as spam without further checks. The configuration of the blacklist is the same as the whitelist, but instead of
blacklist_from and instead of
This filter performs a heuristic analysis. It defines a fixed set of rules (usually the presence of a word or phrase) that are checked for in emails. This set is fixed; it can only be changed manually by the administrator (with faculty-wide validity) or by the user (with validity for their address). Each rule is assigned a weight (a real number). A positive weight indicates phenomena that are characteristic of spam, a negative weight indicates phenomena that are characteristic of regular mail. The sum of the weights of all the rules that the mail satisfies is called the score. If the score is greater than a certain threshold, the mail is marked as spam and does not enter the dSpam checking process at all.
In a mail that has been processed by SpamAssassin, you will find the header
X-Spam-Status, from which you can read the results of the mail analysis.
X-Spam-Status: Yes, score=14.3 required=7.0 tests=FI_NOTFROMFI, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FORGED_RCVD_HELO, HTML_70_80,HTML_FONT_BIG,HTML_MESSAGE,INVALID_DATE,MIME_HTML_ONLY, NO_REAL_NAME,UNDISC_RECIPS autolearn=disabled version=3.1.9
- The mail has been marked as spam
- its score is 14.3
- the phenomena that contributed to the score are listed in the list
You can configure the behaviour of SpamAssassin to some extent in the file
~/.spamassassin/user_prefs. The configuration options are described in the documentation, see
Mail::SpamAssassin::Conf - you can define your own rules or change the scores of existing ones. Here we describe the option to modify the threshold score for spam detection:
Changing the minimum spam scoreBy default, any mail with a score equal to or greater than 7 is marked as spam. If you want to change this threshold, insert the following line in the configuration file (instead of
X, enter the desired real value):
required_hits XIncreasing the threshold score is relatively safe; it will likely increase the number of spam messages that will not be recognized. Lowering the threshold is not recommended.
The statistical Bayesian filter dSpam also recognizes text substrings (called phenomena) in emails, assigns a score to them, and determines whether or not the email under examination is spam based on a consideration of the overall score. However, the set of phenomena and their scores change without administrator or user intervention in the configuration. The filter defines/adjusts the phenomena and scores in the learning phase by examining the mails that the administrator or user determines to be spam or non-spam. The source of learning spam are:
- an initial set of training emails collected by the administrator
- emails arriving at a certain email address (called a honeypot) in the FI domain that does not belong to any user; and
- emails arriving at an address
The source of learning spam is:
- the initial set of training emails collected by the administrator
- emails arriving at the address
Each mail that is processed by dSpam is enriched with headers that indicate the verdict of dSpam's evaluation as well as the rationale for that verdict:
X-DSPAM-Result: Spam X-DSPAM-Factors: 15, liable+for, 0.00448, liable, 0.00673, shall+not, 0.00738, Offers+e, 0.99000, Offers+Microsoft, 0.99000, MSN+shall, 0.99000, mail+communications, 0.99000, WA+98052, 0.99000, target="_blank">More+Newsletters, 0.99000, This+shall, 0.99000, Feature+Offers, 0.99000, not+unsubscribe, 0.99000, content+nor, 0.99000, ©2008, 0.99000, Newsletters+|, 0.99000Mail with the following headers:
- did not pass the whitelist or the blacklist and was marked as non-spam by SpamAssassin.
- was flagged as spam by dSpam
- this verdict was determined based on finding the text patterns listed in the
Those patterns with a number greater than 0.5 in the header put the mail more on the spam side; other patterns on the non-spam side. The further away from 0.5 the number is, the more predictive value the pattern carries.
University-wide checking of incoming mail
Each incoming mail is scanned by an antivirus program on the
relay.muni.cz server and subjected to a thorough antispam routine (in particular, greylisting) before being allowed into the university network. If the result of the tests is negative, the mail is forwarded on to the university network with, among other things, the following headers added:
X-Muni-Spam-TestIP- IP address of the server from which
relay.muni.czreceived the mail;
X-Muni-Envelope-From- the email address of the sender specified in the envelope of the mail.
This information can be used, if handled sensitively, to additionally filter mail at the user level before it is delivered to the mailbox (e.g., via email).