At 05:43 PM 3/28/2003 -0800, Professional Software Engineering wrote:
Now we know your OS version (sorta), what's your Procmail version? Of the
two things you mention above, it'd be a lot more useful if you declared
the procmail version.
the latest one off of procmail.org, i figured that would be obvious.
non-cvs version btw.
The latter is wholly unnecessary given the nature of the error, as you'll
find when you run 'man procmail'.
read the man pages, didn't help.
procmail man page is utterly useless.
It might come as a major revelation, but the error messages ARE documented
in the manpages. Pretty much all of them in fact. Have you tried looking
there?
oh really? well first of all, this is the FIRST time I'm getting ANY errors
at all logged ANYWHERE.
so, I didn't have ANY errors to look up. hrm, go figure. can't look up what
you don't have.
it was only AFTER recompiling/make/etc with config.h modified AND using
verbose=on that I got
anything logging at all.
and your reference to the man page doesn't help me at all.
suspicious procmailrc in the manpage says, and I quote:
Suspicious rcfile "x" The owner of the rcfile was not the
recipient or root, the file was world
writable, or the directory that con-
tained it was world writable, or this
was the default rcfile
($HOME/.procmailrc) and either it was
group writable or the directory that
contained it was group writable (the
rcfile was not used)
which is incorrect. the owner IS me, and the mail IS to me. so, you tell me
and it is NOT group writeable, neither the file nor the directory.
and is not world writeable, either the file nor the directory.
Well, your mail log should reveal what action your MTA took when the
message was rejected by procmail. Surely, there's an explanation as to
why your email is bouncing (since, if it isn't heading into your mail
spool, it is bouncing, or being requeued, as in EX_TEMPFAIL - the "exit
75" bit in the .forward).
it doesn't. sorry to burst your bubble. nothing in the log.
the mail is NOT bouncing. how's that for a clue? it's just sitting there in
the queue.
it eventually gets delivered if I turn procmail off. there are no
EX_TEMPFAIL messages in ANY logs.
do you have another theory you want to test?
I see only one, and have no idea whether this is the one which relates to
the symptoms you're describing as sometimes happening. Is there a
.procmailrc file when you're using this one, does it cause the above log
entries, etc?
oh please. don't be so obtuse. can't you read? ok, I'll type it again:
"I've tried it with and without a .procmailrc file"
ok, so that's at least 2 combinations.
and with three different .forwards.
one is with -f-
one is with -Yf-
and the third (ahem) is with -f- and -Yf- using the long obtuse examples,
here: "|IFS=' ' && p=/usr/local/bin/procmail && test -f $p && exec $p -Yf-
|| exit 75 #YOUR_LOGIN_NAME"
which is a lot of excess crap.
so here's an overview just because you like being obtuse:
test 1 - the one I showed in my mail without a procmailrc file (used -f-)
test 2 - test 1 with an empty procmailrc file
test 3 - test 1 with logging/verbose procmailrc
test 4 - test 1 with -Yf-
test 5 - test 2 with -Yf-
test 6 - test 3 with -Yf-
test 7 - with recompiled procmail, and redid test 1
test 8 - with recompiled procmail, test 2
test 9 - with recompiled procmail, test 3
test 10 - with recompiled procmail, test 4
test 11 - with recompiled procmail, test 5
and finally
test 12 - with recompiled procmail, test 6
I realize you're probably absolutely frustrated as you try to get this
program running without reading the manual, but you're not providing a
single diagram of _one_complete_test_scenario_ along with the results of
that specific scenario. Instead, you're providing fragmented bits of
information about various things you've tried, and some characteristics of
some of the problems you've had - no lines drawn between any two items to
correlate them.
well I just correlated
all tests resulted in the same thing execpt the final test (or 2) showed
the suspicious procmailrc file error, no other errors.
and as I said, I just checked that, and permissions and ownership as well
as the address of the email is correct.
When, some day, you get stuck having to resolve this sort of stuff by
yourself in the dead of night, perhaps with an isolated network
connection, the importance of keeping track of the cause and effect
relationships will become clear to you. You should get an early start on
tracking those relationships whenever diagnosing a problem, or asking
others to diagnose your problems, so that it's an automatic reflex for you
later on. Much like reading manpages (which, I've been guilty of not
checking very closely from time to time as well).
yer too funny.
i read the man page, I tried every comibination available to me
did I miss something?
I suspect when you have _no_ .procmailrc, the /var/adm/messages error
isn't the same. This interrelates with that _one_complete_test_scenario_
bit I just mentioned.
without a procmailrc file I get nothing in the logs. or at least I did in
my tests.
Certainly you mean one of the THREE forwards. Is there a ~/.procmailrc
when you use this? What other syntaxes have you used? Is the procmail
path itself VALID?
shown above. nuf said.
Trying to run procmail via a .forward, without actually having a
~/.procmailrc would cause procmail to deliver normally.
nope.
no mail delivered.
no messages in the logs
nada.
at least, last time I tested.
Have you tried, from another account, sending mail to this account you're
bodging away on, to see what the sender gets in response to their sent mail?
yes. no response at all. nothing. nada.
The solution is in the manpages. Also, check out:
<http://www.professional.org/procmail/procdiag.sh>
Download it, carefully *READ* it, then invoke it. It should point out
some of the more common user-induced faults.
read it. tell me what I missed. I read it several times actually.
eyes started to glaze over, so I stopped.
Dan.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail