Thanks, SBS, for your considered reply.
Well, JFTR,
... sorry, that one escapes me.
>VERBOSE=yes
>#MAILDIR=$HOME/Mail
>
>
>SENDMAIL=/usr/sbin/sendmail
>DEFAULT=$MAILDIR/INBOX
>LOGFILE=$MAILDIR/procmaillog
With VERBOSE and LOGFILE set, *EVERY* message being passed to procmail
should result in stuff being logged to your logfile. If you have messages
arriving in your inbox and there's no record of it in the procmaillog, you
need to check file permissions, and whether procmail is being invoked
or not.
I don't know about file permissions, but the following output in
/home/adam/Mail/procmaillog suggests that it being invoked - Jan 13,
2004 is the date I started writing this. But it is all still being
dumped into my inbox rather than folders.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
procmail: Unlocking "msgid.lock"
procmail: Notified comsat: "adam@:/usr/bin/formail -D 8192 .msgid.cache"
From root(_at_)Tux Tue Jan 13 08:22:06 2004
Subject: Daily AIDE report for Tux
Folder: /usr/bin/formail -D 8192 .msgid.cache 395
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
procmail: Assigning "FORMAIL=/usr/bin/formail"
procmail: Locking "msgid.lock"
procmail: Executing "/usr/bin/formail,-D,8192,.msgid.cache"
procmail: Assigning "LASTFOLDER=/usr/bin/formail -D 8192 .msgid.cache"
procmail: Unlocking "msgid.lock"
procmail: Notified comsat: "adam@:/usr/bin/formail -D 8192 .msgid.cache"
From root(_at_)Tux Tue Jan 13 08:27:24 2004
Subject: ndtpd daily log
Folder: /usr/bin/formail -D 8192 .msgid.cache 385
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
procmail: Assigning "FORMAIL=/usr/bin/formail"
procmail: Locking "msgid.lock"
procmail: Executing "/usr/bin/formail,-D,8192,.msgid.cache"
procmail: Assigning "LASTFOLDER=/usr/bin/formail -D 8192 .msgid.cache"
procmail: Unlocking "msgid.lock"
procmail: Notified comsat: "adam@:/usr/bin/formail -D 8192 .msgid.cache"
From root(_at_)Tux Tue Jan 13 08:27:27 2004
Subject: Anacron job 'cron.daily'
Folder: /usr/bin/formail -D 8192 .msgid.cache 397
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>LOGABSTRACT=all
>DROPPRIVS=yes
Unless you're running in a /etc/procmailrc file, DROPPRIVS is pretty much
useless - procmail isn't running as ROOT on your behalf.
Thanks, I've commented it out.
>#Nukes duplicate messages
>:0 Wh: msgid.lock
>| $FORMAIL -D 8192 .msgid.cache
Spiffy. read 'man procmailex' - note that if there are delivery problems
after the dupe has been checked for, when the message is requeued,
it'll be
considered a dupe. For this reason, you might consider using the revised
recipe which appears AFTER the warning.
Hmm ... 'man procmailex' has been much developed since I read it last.
Yep, I've done that.
Well, do you HAVE a ~/.forward file?
Tux:/# find -name .forward -print
Tux:/#
The answer seems to be 'NO'.
Ask yourself: do you KNOW that your ISP hasn't been changing their MTA
configuration, say toggling between having procmail configured to be LDA,
and then NOT having it configured?
According to my ISP, the LDA is 'pop3.paradise.net.nz', and has not changed
over the period when my problem arose. Mail filtering is done by
'Brightmail'.
Any further questioning re. LDA or MTA met with a blank response.
The key thing would seem to be that nothing has changed during the
period when my procmail recipes ceased working.
If you wish, I will post my complete .procmailrc to this list. It may be
wise to first see if
procmail recipes work with the creation of a ~/.forward file.
>Tux:/# find -name procmaillog -print
>./home/adam/Mail/procmaillog
>./home/adam/.themes/adam/Mail/procmaillog
>./home/adam/.themes/.themes/adam/Mail/procmaillog
>./home/adam/.themes/.themes/.themes/adam/Mail/procmaillog
Uhm, what's up with the .themes/.themes/.themes cruft? Looks rather like
the results of a hokey backup script.
Yeah, I wish I could answer that one. /home/adam/Mail/procmaillog works.
You might hit the link in my .sig and download (AND READ!) the procdiag
shell script. After reading the script, execute it and review the
output. You might have tripped on some file permissions (group or world
writeable on your .procmailrc file for instance).
Output of running './procdiag.sh' follows ... [cut & pasted from root
gnome-terminal
to mozilla-mail-compose]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tux:/home/adam# vi procdiag.sh
Tux:/home/adam# sh ./procdiag.sh
# procdiag v20031105.1723
# procdiag run at Wed Jan 14 13:51:13 NZDT 2004
# general account information:
USER: root (root)
GROUPS: root
SHELL: /bin/bash
MAIL: /var/mail/adam
hostname: Tux (Tux)
FQDN: Tux
HOME: /root
# user info from /etc/passwd (password is masked):
root:x:0:0:root:/root:/bin/bash
# system identifiers (if discernible):
OSTYPE: linux-gnu
MACHTYPE: i386-pc-linux-gnu
UNAME: Linux Tux 2.4.18-bf2.4 #1 Sam M?r 30 00:56:06 CET 2002 i686 GNU/Linux
# The current shell path is (not to be confused with the MTA-defined path):
PATH:
/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
# formail and procmail information (as per versions in the current path):
0755 1 root root 26260 Tue Nov 4 08:04:47 2003 /usr/bin/formail
formail v3.22 2001/09/10
6755 1 root mail 67496 Tue Nov 4 08:04:47 2003 /usr/bin/procmail
procmail v3.22 2001/09/10
Default rcfile: $HOME/.procmailrc
It may be writable by your primary group
Your system mailbox: /var/mail/root
# various procmail configuration elements:
ORGMAIL="/var/mail/root"
SENDMAIL="/usr/sbin/sendmail"
SENDMAILFLAGS="-oi"
HOST="Tux"
PROCMAIL_VERSION="3.22"
LINEBUF="2048"
PATH="/root/bin:/usr/local/bin:/usr/bin:/bin"
SHELL="/bin/bash"
SHELLMETAS="&|<>~;?*["
# usage banner from grep
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
# sed version or other identifier
0755 1 root root 36280 Mon Oct 27 14:54:41 2003 /bin/sed
GNU sed version 4.0.7
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.
# sh info (intended to show whether sh is sh or a symlink to another shell)
# sendmail program information (from procmail's $SENDMAIL):
4755 1 root root 733004 Sat Jan 10 02:08:18 2004 /usr/sbin/sendmail
exim: malformed debug_selector setting: + or - expected but found "0"
# Determining Mlocal via sendmail diagnostic invocation
exim: malformed debug_selector setting: + or - expected but found "0.15"
NOTE: procmail doesn't appear to be the LDA
# contents of /root/.forward (if it exists)
NOTE: no /root/.forward
# file permissions and ownership:
NOTE: There is no /root/.procmailrc file.
NOTE: There is no /root/.forward file.
0755 42 root root 2048 Wed Jan 14 13:50:48 2004 /root/
0644 1 adam adam 3166 Sun Nov 9 14:53:59 2003 /etc/procmailrc
NOTE: There is no /etc/procmailrcs file.
0700 2 root root 1024 Fri Nov 28 21:29:12 2003 /root/Mail/
NOTE: There is no /root/mail file.
NOTE: There is no /root/.procmail file.
0600 1 root mail 0 Fri Nov 28 21:28:25 2003 /var/mail/root
2775 2 root mail 4096 Fri Nov 28 21:28:25 2003 /var/mail/
# procdiag report end
Tux:/home/adam#
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also, inquire with your sysadm what the LDA is configured as -- if it
isn't
procmail, then you NEED a .forward file in order to invoke procmail (and
only if procmail isn't the LDA - it's redundant to have it configured as
the LDA and then invoke it from a .forward). If procmail isn't invoked,
your mail will simply be deposited into your user mailbox.
That seems to be what is happening.
I think I'll follow the directions in your 'disclaimer' on setting up a
.forward
file and see what happens. I'll get back to the list.
I'd appreciate your comments in case I am going up the wrong alley.
Adam Bogacki
afb(_at_)paradise(_dot_)net(_dot_)nz
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail