Sophie

Sophie

distrib > Mandriva > 2010.0 > i586 > media > contrib-release > by-pkgid > 43bb1dd9140ac2a3090c0de3bad20e81 > files > 7

spamprobe-1.4d-7mdv2010.0.i586.rpm

filename: README-mta-mda-mua.txt
author: Anto Veldre <anto@xyz.ee>
ver 002, section 1.5 completely rewritten, minor clean-ups.

====================================================


What follows is some background information on
MUAs, MDAs and MTAs (mail user, delivery and transfer agents)

See also what opinion wiki has about the matter:
http://twiki.org/cgi-bin/view/Wikilearn/EmailServerTerminology
------------------------------------------------------


1.1 Admin domain versus user domain
===================================

The good news is that unlike with some virus scanners,
spamprobe installation avoids fiddling with sophisticated
system toys (like mail queues, MTA configurations files and
similar), which traditionally belong to UNIX administrator
domain.

All what spamprobe needs to attempt, is done in user space.
This means you could implement spamprobe without neccessarily
consulting your system administrator (which could be a problem at
universities and other over-managed sites).

But ... procmail is a prerequisite nevertheless.


1.2 sendmail + procmail
=======================

Chances are that procmail is already installed on your
system, because of sendmail needs it for local delivery.

Historically, sendmail is the King of MTAs
(http://www.sendmail.org). Provided your system is
sufficiently modern, both sendmail and procmail should be
installed. Sendmail decides whether or not should the message
be delivered to a _local_ user and if the answer
is YES, it hands the message over to procmail, which
is responsible for the actual delivery (appending the message
to the users mailbox somewhere at /var/spool/$user).

Commanding "grep procmail /etc/sendmail.conf" is usually
sufficient to estimate whether you have sendmail+procmail
preinstalled. You also can check the precence of procmail by
directly launching "procmail" (CTRL-D helps you out of there)
or checking the precence by "which procmail".

Another good news is that once procmail is installed
(and somehow implemented into your mail delivery process),
you do not have to configure it otherwise than via
normal rc (run-command) file which is ~/.procmailrc .

Visit http://www.procmail.org. "Interesting and Useful Links"
is the most valuable section there.


1.3 Other MTA's
===============

What to do if your system isn't sendmail based?
To use spamprobe, you have to work out some method
how MTA hands mail over to procmail. Other MTAs
are compatible with procmail to lesser or
greater extent.

For Qmail (http://www.qmail.org), procmail
is a normal satellite.

For Postfix (http://www.postix.org), procmail should be
specifically described as the local delivery agent
(in /etc/postfic/mai.cf).

For Exim (http://www.exim.org), a user only could pipe
messages to procmail via ~/.forward file (if not
prohibited by admin).

But expect trouble with outdated smail or an old MMDF
(SCO UNIX leftover). I hope no such bestia left on the
planet but nevertheless...

Any actual used experience is welcome to this section.



1.4 Bypassing the system-wide mail delivery system
==================================================

Generally, an admin-controlled MTA could be easily
substituted or bypassed by user space tools. This fact
itself is not good or bad, it simply is an option
for the user.

Various POP3 or IMAP clients allow you to collect
your messages from remote. Moreover - you could IMAP
or POP3 to _localhost_, this way the retrieved
messages (by default) are automatically erased from
your system mailbox.

Programs like fetchmail
(http://www.tuxedo.org/~esr/fetchmail/) could be used
to fully automate the mail collection process.

Mail readers generally are widely  configurable,
so you could point to your actual mailbox.

But be beware - graphical mail clients may
distort (sorry, enrich) the classical mailbox
structure used by mail, mailx, elm and pine.
Once read into, it isn't easy way out of an proprietary
mailbox.


1.5 My personal setup
=====================

The ~/.procmailrc file I use looks like:


	MAILDIR=/home/$me/INCOMING-MAIL
	:0 c
	saved
	:0
	SCORE=| /usr/local/bin/spamprobe receive
	:0 wf					
	| formail -I "X-SpamProbe: $SCORE"
	:0 a:
	*^X-SpamProbe: SPAM
	dirty
	:0 a:
	*^X-SpamProbe: GOOD
	cleaned


Now all incoming mail is stored at $MAILDIR/saved.
In addition to this, spamprobe will use two
self-explainingly named mailboxes as $MAILDIR/cleaned
and $MAILDIR/dirty.

The result is that my previous incoming mailbox
at /var/spool/mail/me will no more be used by
the procmail.  Why?  Because of after applying two mutually
excluding rules (store SPAM at dirty and GOOD at goodies)
no messages will be left for procmail to store at my previous
inbox (at /var/spool/mail/$me).

In excellent setups, $MAILDIR/saved file should be linked
to an NFS share (probability two HD's will synchronously 
fail outweights NFS reliability problems). In excellent
setups some cron script should periodically archive
what is stored in saved file (e.g. my-mail-pre-2002-12-27.gz).

Oh yeah, I almost forgot it - I am an elm addict for 10
years. Graphical MUAs may use a different paradigm and
accordingly these may prefer fetching mail directly by POP3/IMAP.


1.6 Bayesian technology
=======================

Seems like famous article by Paul Grahams inspired many
spam-fighters and a lot of more than 1 programmer started
to konqueror evil's territory with  statistical methods.
Searching for "bayesian" at http://www.freshmeat.net or
http://www.sourceforge.net will indicate the popularity
of the technology.


1.7 Security topics
===================

Generally, be cautious when playing with .procmailrc.
It is rather easy to create systemwide security blackholes
via "vacation" program 
(http://www.ayradyss.org/programs/current.html#vacation)
or piping the messages to programs (via ~/.forward file)

1.8 Cartago delenda est
=======================

I still think MUAs should obtain a "SPAM" button beside
"DELETE" one. Junk will be deleted in both cases, the difference
is that "SPAM" knob will first analyse it and only then delete.
Spamprobe is a good candidate to do the dirty work behind
"SPAM" button.

anto@xyz.ee
ES1LAU