At 17:24 2000-09-07 -0500, Mike McNally wrote:
I have mail from bob, a user on my system, and mail from everyone else.
I want to sort these two types of incoming mail into seperate
containers.
Yea, I picked up on that -- but WHERE are these mailboxes supposed to be
located?
I have reviewed 6 .procmailrc's (3 of which came with the
procmail package) and all of them use lines like the ones you strongly
object to, to do just this.
Hey, *I'm* not the one with the mail sorting problem... I've also got
other things I could be doing if you'd rather.
But let's do it your way, and let's
simplify the problem by ignoring the need to parse mail from bob.
Let's not - that alone would be an indicator that SOMETHING is working.
Here's the .procmailrc.
PATH=/usr/bin:/bin:/usr/local/bin:.
MAILDIR=/var/spool/mail
Uhm, you're now, as a user, trying to deliver messages into the
SPOOL? Won't be happening any time soon if this procmail is being run from
the user account and you try to write to any file other than THIS USER'S
mailspool file. Please refer to your original message, whence this was
specified as $HOME/Mail.
Changing MULTIPLE things in a blind attempt to get things working WILL NOT
solve the problem, and only goes towards screwing up those who wold spend
the time to lend a hand. How am I to assume that in the process of
changing the other things I recommended, you didn't ALSO change this, which
would obviously result in failure, reguardless of whether you implemented
the other suggested changes?
telnet/ssh in as the account which you're filtering for, and go to the
/var/spool/mail dir and see if you can create or modify any files there
other than your OWN mail spool. Procmail will suffer the same limitations.
DEFAULT=$MAILDIR/mikesmail
As I previously indicated, there should ne no need for you to redefine this
except in some circumstances - which is not defined as your present situation.
#LOCKFILE=$HOME/.lockmail commented out as you advised
Because, like, you never UNLOCKED by specifying an empty LOCKFILE
definition... But then, this is only needed in a few situations (I use it
for instance to wrap around a very large - and memory/cpu intensive - set
of rules, but nowhere else in my extensive rules do I use LOCKFILE explicitly).
#and if I comment out the default line in hopes of procmail just
creating the one
#dir, even that seems too much to ask for this program
procmail WILL NOT create directories, unless you're deliberatley calling
the shell to do so.
it doesn't work
Where, *EXACTLY* is it you want your messages? S.P.E.L.L. it out, because
right now, your EXACT objective is still fuzzy.
If necessary, use simple pseudo-code:
messages from bob go into $HOME/Mail/bob
messages from everybody else go into $HOME/Mail/mikesmail
Given your re-definition of MAILDIR above, I can't tell WHERE you want your
messages, but I CAN say that between the two posts, you're certainly not
trying to put them in the same place as you were before. Why?
By way of analogy, what I want to do is set one hat on the floor and
throw cards into it. You have asked me why I want to throw the cards
into a hat when I could just throw them on the floor and that would be
simpler.
Skip analogies -- it'd be much simpler if you actually said in what
directory the hat is actually located - spelled out fully, because the
terms you're using obviously aren't getting the point across to me. I'm
not telepathic.
Well, you can only simplify sorting so far and then you don't
have sorting. If I can't set up containers into which things can be
sorted, then I can't sort. To simplify the problem I just want one
container for now. So lend me a hat, please. ;)
Argh! For your .procmailrc, enter the following (between the hashes)
### Begin .procmailrc
# I'm assuming the path is valid for your system, though your current rules
# don't have a need for it anyway.
PATH=/bin:/usr/bin:/usr/local/bin:.
SHELL=/bin/bash
# this is a definition for YOU to use in the script to consistently define
# where messages should go. AFAIK, procmail doesn't internally use it by
# default for anything it does.
MAILDIR=$HOME/Mail
# This defines where procmail will log its events.
LOGFILE=$MAILDIR/log
# This turns on the logging at maximum verbosity. After putting this file
# into place, send some test messages through to the account, then change
# this to =off (you REALLY don't want to log max verbosity all the time -
# just when you're debugging). You can then examine the logfile (located as
# per LOGFILE definition above) for what procmail was doing.
VERBOSE=on
# Note the brackets contain a tab and space. The regexp after that is
# pretty darn vague - perhaps you should spell out the address...
# the trailing star, which I left in place, isn't likely what you want -
# this will match "bo", "bonnie", "bobafett", etc.
# Note also that a trailing colon was placed on the flags line - this
# ensures that the delivery will be protected by a lockfile (whos name
# is automatically generated. The mailbox name is preceeded by the
# maildir variable as well.
:0:
* ^From:[ ]*bob*
$MAILDIR/asap
# Default delivery into your mailbox (by the simple fact that this rule
# has no conditions limiting what goes into the mailbox, and because
# it appears LAST - anything not previously filtered will end up here).
:0:
$MAILDIR/mikesmail
### End .procmailrc
Put this file in your account home directory. You made earlier reference
to a .forward file, so I shall assume that it must have been working
properly, though perhaps that's a big assumption on my part.
After examining the output, CLEARLY define how this isn't doing what you want.
I am aware that I will have to instruct mutt into where to go to find
the directories I will be setting up with procmail but this is
Where to tell mutt where to go looking is less of an issue than your popd
(POP3 daemon) which gets the mail from your server -- in the spool -- for
POP3 mail clients when you're fetching mail from other computers. If
you're not fetching mail using a POP3 client, that's just fine - my mention
of relocating the mailbox from the spool directory was meant to head off
the inevitable "gee, it filters okay, but when I go to fetch mail with MS
LookOut, it claims there's no messages."
elementary, as should be the creation of containers for mail to be
sorted into. But it's getting to be a real headache.
You appear to be arbitrarily defining where the messages should go, without
any concern as to whether your account has such privledges to write where
you're telling it to. Users cannot (and should not be able to) write to
just anywhere on the system. That's what permissions are for. Certianly
you'd find it offensive if someone could install a utility that enabled
them to write messages into other people's mail spools?
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail