I am getting my mail from my isp via its pop3 server.

I have set up fetchmail to pass all messages to maildrop, pass on any cooker mailing messages directly to my mailbox in /var/spool/mail/ and send the rest though spamassassin and then send messages having spamassassin hits of 10 or more to /dev/null and pass the rest to /var/dev/null. The mail application (kmail) is responsible for sending lower level spam to a spam folder.

I am trying to keep the system as simple as possible.

I am using /var/spool/mail/(username) instead of a maildir because one of the users in my home uses thunderbird instead of kmail and thunderbird seems only able to move messages from the system mailbox unless I use a local imap server, For that reason, local filtering such as moving mailing list files or tagged messages to folders is being handled by thunderbird or kmail

The fiollowing is my .mailfilter file:

HOME=/home/chd QUOTE{

DEFAULT=/var/spool/mail/chd logfile "$HOME/.maillog"

if(/^List-Id:.*mandrivalinux\.org>/) { to $DEFAULT }

xfilter "/usr/bin/spamassassin"

if(/^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*/) { EXITCODE = 0 exit }

}END QUOTE

I have set EXITCODE=0 to ensure that I pass a known return code back to fetchmail to avoid the risk of fetchmail holding the message or, worse, bouncing it.

The setup appears to work fine and seems to do its intended job, but the .maillog file gives no clue as to what is happenning to high value spam and fetchmail behaves as if the mail had been accepted (which is what I would expect with an exitcode of zero.

My question is whether I ought to be using EXITCODE=553 instead. The fetchmail man page seems to suggest that a return value of 553 would cause fetchmail to drop the message without bouncing it and that action ought to appear in the listing when I test the system using "fetchmail -v", thereby confirming that maildrop is working as intended.