On Sun, Jan 02, 2005 at 09:40:37PM +1100, Adam Bogacki wrote:
Thanks .. Dallman & Ruud.
I've rewritten /etc/procmailrc and $HOME/.procmailrc using Ruud's
example - which I appreciate due to uncluttered layout - but (not
having rebooted) - it's still not filtering.
What do your logs say?
"It's ... not filtering" is not very helpful diagnostically.
We need to determine if procmail is running, and, if so, where
it is failing to do what you think it should do, etc. This is
what logs are for, and why we spent so much time and effort finding
your logs. So now that you have a new /etc/procmailrc with
a log that you should be able to find: what does the log say?
(Turn on VERBOSE for a while and see.)
Could the cause be something outside procmail ?
What do the logs say? (Do I hear an echo?)
[Ruud: I don't understand why Mailman has 2 spaces around the '.*' in
the Subject-header.]
#--> should be writable by the user
LOGFILE = "$MAILDIR/etc-procmail.log"
Is it writable by the user?
NL = '
' # contains only a literal newline
That is not something that contains only a newline. I see
lots and lots of whitespace. You need to fix that.
TAB = ' ' # contains only a literal tab
Is it really a tab on your system? Because what you show us
here is no tab, but a series of spaces.
pid($$) rc($_) user($LOGNAME)
home($HOME)
maildir($MAILDIR)
default($DEFAULT)
formail($FORMAIL)
sendmail($SENDMAIL)
path($PATH)
In case it isn't obvious: Ruud suggested that for when you look
to (drum-roll) what the logs say. So what do they say?
# Work around procmail bug: any output on stderr will cause the "F" in
# "From"
# to be dropped. This will re-add it.
# NOTE: This is probably NOT needed in recent versions of procmail
:0 fhw
* ^^rom( )
| sed -e '1s/^/F/'
:0A
{ LOG = "--> inserted F at the start.$NL" }
I left this quoted part in for reasons that will be made known
further below.
#Mailman reminders
#--> Has 2 spaces around the '.*' in the Subject-header.
#--> Is that OK?
:0:
* ^From: .*mailman-owner@
* ^Subject: .* mailing list memberships reminder
Trash
A space in a condition is a space. There's no magic.
This condition looks for a header-line starting with
"Subject:" followed by a space, followed by anything
at all or nothing, followed by a space, followed by
the rest of the text shown. If that is what you want to
match, then fine.
#Creates a backup cache of 200 most recent messages.
#--> Make sure that $HOME/Mail/backup/ exists!
:0 c
backup
:0 i
|cd backup && rm -f dummy 'ls -t msg.* | sed -e 1,200d'
#--> I suppose that those quotes need to be `strong` ones.
You had this same problem on about 9 December when this all
started. You can't have an mbox file named "backup" in
the same dir where you think you have a subdir called "backup".
One of these simply does not exist. What do your logs say?!
#Regenerates "From" lines to make sure they are valid.
:0 fhw
* ! ^^From( )
|formail -I "From " -a "From "
:0A
{ LOG = "--> regenerated From-line.$NL" }
Refer to the earlier rendition of the same recipe, which
I left quoted up above. You have the same thing in twice.
It's probably not even necessary once. But it's certainly
not necessary twice!
(2) ~/.procmailrc
# This is the user's ~/.procmailrc
# It is run (automatically) after the /etc/procmailrc.
VERBOSE = 'no'
Since you say "it doesn't filter," why don't you try turning
that ON and looking at what the logs say? Have I not made
clear the idea that the logs are your first, best diagnostic
tool?
SHELL = 'bin/sh'
MAILDIR = "$HOME/Mail"
DEFAULT = "$MAILDIR/.Inbox/"
You do not need to recreate DEFAULT if it was properly
set either at compile time or in the /etc/procmailrc.
NL = '
' # contains only a literal newline
Same comment as above.
But more, you do not need to keep reasserting the same
definitions. They were set in /etc/procmailrc.
The only reason you'd want to do this is if you don't always
run /etc/procmailrc first (not true in your case based on what
you have revealed in the last several weeks here), or if you
don't control what's in /etc/procmailrc and don't want to
be left hanging if it gets changed without your knowledge. But
since this is your own computer and you are writing both files,
that is also not an issue.
# sendmail program information (from procmail's $SENDMAIL):
4755 1 root root 644472 Wed Dec 8 00:01:21 2004
/usr/sbin/sendmail
exim: malformed debug_selector setting: + or - expected but found "0"
So are you ever going to fix this?
/var/mail/adam
CAUTION: /var/mail/adam perms exceed 7755: curb back to 0640
2775 2 root mail 4096 Sun Dec 26 22:08:51 2004 /var/mail/
So are you ever going to fix this?
--
dman
____________________________________________________________
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