Antispam protection

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).

If your mail is forwarded using the file .forward, there is no antispam checking. If you want to forward your mail and check it at the same time, use a program procmail.

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:

1. whitelist/blacklist
2. SpamAssassin
3. dSpam

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

The settings made by this application are stored in the file ~/.procmail.setup.

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 spam@fi.muni.czand notspam@fi.muni.cz.

Redirecting the message

You can also re-learn the statistical filter by redirecting (redirect, bounce) messages to spam@fi.muni.czand notspam@fi.muni.cz. You can do this in muttwith the 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 ~/.spamassassin/user_prefs file:

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 ~/.spamassassin directory to " x" for the user spamd:

  setfacl -m u:spamd:x ~ ~/.spamassassin

• assign the right " r" to the file ~/.spamassassin/user_prefs for 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:

whitelist_subject WhitelistovanyRetezec

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 whitelist_from write blacklist_from and instead of whitelist_subjectwrite blacklist_subject.

SpamAssassin

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 tests

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 score

By 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 X

Increasing 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.

dSpam

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 spam@fi.muni.cz

The source of learning spam is:

• the initial set of training emails collected by the administrator
• emails arriving at the address notspam@fi.muni.cz

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.99000

Mail 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 X-DSPAM-Factorsheader

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.cz received 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).