At 14:14 2004-01-14 +1300, Adam Bogacki wrote:
Well, JFTR,
... sorry, that one escapes me.
Just For The Record.
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.
Folder: /usr/bin/formail -D 8192 .msgid.cache 395
[snip]
Folder: /usr/bin/formail -D 8192 .msgid.cache 385
[snip]
Folder: /usr/bin/formail -D 8192 .msgid.cache 397
If these are the ONLY folders you're seeing deliveries to, then all the
messages are being discarded, so far as procmail is indicating.
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'
That would be the mailhost, not the "Local Delivery Agent".
over the period when my problem arose. Mail filtering is done by 'Brightmail'.
I'm unfamiliar with it.
Any further questioning re. LDA or MTA met with a blank response.
That's reassuring, esp if they told you a hostname in response to the LDA
question.
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.
It would be most wise to move your current .procmailrc to a backup, then
produce an absolute baseline .procmailrc and work up from there. Since you
have logging, you know that procmail is being invoked - but how might it
work if you simply have a recipe to deposit the messages from the procmail
list into a folder - do nothing else, no dupe checks, etc.
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
uhm, uhm, uhm.... _you_ are invoking it as root. Is this the user with
the problem? Generally speaking, it's a good idea to have root's email
head to a different user, then you're not encouraged to log in as root any
more often than necessary (nor do you have a need to use a non-secure mail
retrieval protocol, dumping your login data in the clear - yea, you can
tunnel POP3, etc, but most people are too lazy).
From mention of adam below, it seems as if you su'd to root to invoke the
script, and from the lack of procmail files in the root home directory, it
certainly appears that root is not the user you're trying to filter email for.
FURTHER, if you have root on the system (AND the host doesn't have an
FQDN), then these questions about LDA and whatnot are directed at _YOU_,
not some chap at your ISP. Who manages the box you're running procmail on
- you or the ISP?
SHELL: /bin/bash
MAIL: /var/mail/adam
hostname: Tux (Tux)
FQDN: Tux
That's an indicator of an incomplete or kludged configuration - an FQDN
should be hostname.domain.tld, not just the hostname portion.
# sh info (intended to show whether sh is sh or a symlink to another shell)
Curious that nothing displayed for this.
# 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"
Well, that's informative - you're running exim as your MTA.
# 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
(nor does Sendmail appear to be the MTA, which is the only MTA for which
the diag script knows how to parse the config data for). If someone
familiar with non-sendmail MTAs could provide me with some information on
how to determine if procmail is configured as the LDA under them, I'd
appreciate it.
# file permissions and ownership:
NOTE: There is no /root/.procmailrc file.
Hrm, which implies that root isn't the user you're having a problem
with. Run the script AS THE USER WHICH YOU'RE RUNNING PROCMAIL FOR. Can't
very well check file permissions if we're not looking at the right set of
files...
0644 1 adam adam 3166 Sun Nov 9 14:53:59 2003 /etc/procmailrc
That's a bit disconcerting - the /etc/procmailrc file is owned by adam,
rather than root.
Ur, this isn't where you're doing the filtering, is it? It helps to be
clear that something is being run in the global procmailrc vs. the user
procmailrc.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail