Michael Below <mbelow(_at_)HRZ(_dot_)Uni-Bielefeld(_dot_)DE> writes:
- I'm trying to get procmail to sort out the messages from a mailinglist.
I've set up a simple recipe for doing this (I'll add that below), but:
procmail always escapes the first line of all messages following the first
one with a >. This line contains something like "From user(_at_)host Tue May 28
15:10:53 MES 1996". I think the fact that this line is escaped causes elm
(and mailx, too) not to recognize the start of a new message, so all messages
are shown as a part of the first one.
So how do I get procmail to behave less intelligent?
- I'm running procmail from a background job, piping the contents of
/usr/mail/mbelow into it with cat. But procmail even then wants to modify
the access rights of my /usr/mail/mbelow from 660 to 600 or something like
that (640?).
That makes the mail daemon not able to deliver new mail -- I guess that's
it why I didn't managed to subscribe to this list...
Again, how do I get procmail to behave less intelligent?
Procmail expects to see one (1) message on its stdin. If you want to
filter a mailbox then you'll need to split it using formail's -s flag:
formail -s procmail < mbelow
As for the second, I can't remember where this is documented in the
manpages (I cheated and looked at the source), but if you sent the
permissions on your mailbox to include any of (it only takes one):
00100 (user execute)
04000 (set user id)
02000 (set group id)
01000 (sticky bit)
then procmail won't touch the permissions. Beware: some of these mean
special things on other systems. For example, under SunOS and Solaris
the setgid bit turns on mandatory file locking if the file isn't
executable, while the sticky bit tells the kernel to not keep the
mtime/ctime/atime up to date, neither of which is something you want to
do. User execute is probably the safest of the four.
chmod 760 /usr/mail/mbelow
If strange things start happening, try the sgid bit (perms 2660).
Philip Guenther