SPASTIC and MUAs (Mail User Agents)

OVERVIEW 

To avoid having SPASTIC (Procmail) insert e-mails directly to
the inbox and spam box, the procmailrc file is designed to add
a header to a spam mail so it can be separated later from good
mail by either a procmail recipe at the end (for MUAs that do not
provide filtering) or by a filter rule in the MUA.

Some MUAs (including Evolution, Kmail, Pine and others) have additional
auxiliary files which control the fate of messages which have already
been read, messages which have been deleted and certain other user
preferences. On a good day, the MUA receives e-mail, adds them to its
Inbox folder and updates the auxiliary files to reflect the new status
of the inbox.

With such MUAs, configuring SPASTIC and Procmail to simply insert e-mail
directly to the inbox - without updating the auxiliary files - may
create unexpected results. 


INTRODUCTION 

Some mail programs have a built in filtering ability and others do not. The
SPASTIC design has evolved to work well with both types of mail programs. In
verions prior to 2.4, there were two .procmailrc files, one set up for each
kind of program. However, as SPASTIC evolved, the differences between the
two .procmailrc files became minimal. Now, the only difference is one recipe
at the end of file.

SPASTIC works like other popular spam filters by adding a special mail
header to the suspected spam.  The spam can then be easily filtered out.

In a typical Linux/BSD mail system, mail is sent to /var/mail/$user). Your
MUA will receive all e-mails - including spam - as usual. You must then set
your MUA's filtering rules to allow the MUA to sort the Spam mail into the
Spam box of your designation.

DEFAULT SPASTIC BEHAVIOR

MTA-> .forward ->SPASTIC-> System Inbox <-MUA-> MUA's filter -+->Inbox
                           (/var/mail/$USER)                  |
                                                              +-->Spam box

Using this method, you do not risk messing up your MUA's auxiliary control
files because from the MUA's perspective, e-mail (Spam and all) comes from
the place from where your MUA expects it.


HOW IT WORKS

Once the mail has been retrieved by your MUA, it must identify the
incoming mail and decide those messages which are valid and those which
are Spam. To assist in this process, SPASTIC adds a new header to
any e-mail message it has identified as Spam. The new header given to
Spam is "X-Spam-Status" and it always begins with the string: 

"X-Spam-Status: Yes, Reason:"

You must create a rule within your MUA, based on the X-Spam-Status field, to
move to the Spam mailbox of your designation all e-mail with such a Spam
flag. You may, of course, alternatively set your MUA's filters to change the
color or priority of the message, or delete it, or any other action you
want). In all cases, be sure to set the filter for 'X-Spam-Status Includes
"Yes, Reason:"' as opposed to 'X-Spam-Status line Equals "Yes, Reason:"'!

The Spam-flagging header which SPASTIC creates includes the reason
why each particular message was flagged as Spam.  Thus, X-Spam-Status
lines of Spam-flagged mail will read, for example:

Yes, Reason: Rejected by body
Yes, Reason: Null subject
Yes, Reason: address is not in the To:, Cc: or Bcc: fields
Yes, Reason: Senders address in a bad format

In the future, other reasons will appear as new rules are added to
SPASTIC's filters. (This additional information could be useful to fix a
broken rule, which results in a valid e-mail getting incorrently flagged
as Spam.)