At 21:57 2005-01-11 +0200, Aaron wrote:
The story is like this. I set up procmail to sort mail to various
folders, but the mail all arrives in the Inbox.
my first problem is conceptual:
Your first problem should be whether you're actually invoking procmail
properly.
I write a recipe in procmail an email arrives and goes to where?
That rather depends upon what MTA you have, what it's set up to deliver to
for the local delivery, and if you're using a .forward file to invoke procmail.
in my old email client (evolution), it arrived in my inbox I right clicked
on the email and choose create a filer from the mail then I choose for list
or from or cc or whatever and viola I had a filter,so;
conceptually the manner of filtering (in my mind) is that the mail
first comes to the inbox and then evolution moves it to the place I
want.
Evolution is a mail client. I would suppose that it RETRIEVES the mail,
then sorts it into some mailbox. Procmail is a tool that should normally
be invoked during the local delivery of the message, before your MUA has
anything to do with the message. You could for example forward email
messages to an account somewhere else and *NEVER* actually log into the
mail account here with an MUA, and procmail would manage forwarding it off
as each message arrives.
think that with procmail the idea is that the mail is taken from the
server and run through procmail/spamassasin
procmail is unaffiliated with spamassassin. If your host has SA installed,
it is quite possible that there's a hardcoded delivery following that which
may bypass your local .procmailrc file.
maybe the problem is that procmail isn't being accessed? how do I
check this (running debian)
well, a LOGFILE would help. Hit the link in my .sig and read a few of the
things there, and retrieve the procdiag script.
Running a procmail rcfile standalone BEFORE making it a live procmailrc is
a really good idea -- that would allow you to see it working BEFORE
subjecting all your actual email to it.
SHELL=/bin/bash
Unnecessary to set unless you don't HAVE a shell (which is unlikely if
you're able to log in), or if you're working on an /etc/procmailrc file
which may process mail for other users who do not have shells.
PATH=/bin:/usr/bin:/usr/local/bin:/usr/sbin:
PATH generally doesn't need to be set, unless you're adding stuff not
normally available to your default shell.
VERBOSE=off
this is wrong setting if you're trying to figure out what is wrong.
MAILDIR=$HOME/Mail
LOGFILE=$HOME/Mail/procmaillog
Does $HOME/Mail _exist_? Is it writeable?
DEFAULT=$HOME/Mail/Inbox
This is different from "inbox" in the sense of the default system mailbox
(in the mail spool). If your mail is in fact arriving in this mailbox
file, then procmail must surely be receiving it.
# Nuke duplicate messages
:0 Wh: msgid.lock
| $FORMAIL -D 8192 msgid.cache
does this msgid.cache file exist? If so, this recipe must be getting invoked.
:0 c
backup
does the backup mailbox exist? BTW, you should have a lock flag on the
flags line...
:0:
^TO(_dot_)emacs-nxml-mode(_at_)yahoogroups(_dot_)com
nxml
The condition line here lacks an asterisk, plus a dot all by itself is a
SINGLE ANY character - you should also escape the dot you want interpreted
as an actual dot.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail