|
Re: problem with procmail
2003-03-29 00:36:57
At 23:23 2003-03-28 -0500, Dan Gahlinger did say:
the latest one off of procmail.org, i figured that would be obvious.
Nothing is a given. People obtain programs from far too many sources to
expect that they're ever using anything _current_ (even "current" *nix
distros which include packages don't always include the "current"
version). Furthermore "the current version" or the "latest version" isn't
as concise as a simple version number. 3.22 is recognized as the current
non-devel release version. There's an even "more current version", but
that's not the same.
Pedantic? You bet - this stuff is significant for some problems.
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.
You must be referring to a different procmail package.
man procmail | grep -A10 -i suspicious
and your reference to the man page doesn't help me at all.
suspicious procmailrc in the manpage says, and I quote:
Yup. Your post sure made it sound like you had no idea what that error
message was about, which implied you hadn't read that portion of the
manpage at all - for instance, you didn't follow up with the mention of the
error with anything resembling "I checked the perms on .forward, and
they're r--r--r--, while the .procmail is rw-------". Nope, just:
the only thing I've gotten recently is in /var/adm/messages which says
"suspicious rcfile" pointing to my .procmailrc - why ?
And you're calling _me_ obtuse? Gimme a break - your message rather
clearly gave the impression that you had no idea what the error meant or
why you'd be getting it. Enter the reference to the manpage. Don't get
angry at me for suggesting that you search the manpage for a reference to
the error message.
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.
Your original message made no reference to having confirmed the perms or
ownership on the file. Actually reporting what the perms and ownership
are, rather than reporting "they're all correct" is far better form in any
event - remember, you're the one who is experiencing mail problems, so
apparently SOMETHING isn't right, and all things being equal, it's probably
somehting _you_ did, or you'd have found gobs of references to "solaris &
procmail" in a search of the list archives. Perhaps you're sitting too
close to your monitor to see it, or making incorrect assumptions about
things. It happens, even to experienced developers.
No doubt, deleting the files and restoring them from backups created them
with a fresh, un-fscked-up set of permissions, and that's why you're
suddenly able to process mail successfully. Of course, having never
declared what the original perms and ownerships were, nobody can make a
comparison, can they?
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.
It may be time to switch MTAs or do something like set your MTA up to
actually log delivery information, because when the MTA hands off to the
local delivery agent, if there's an error, the MTA should be logging it
(and that's aside from procmail being invoked from your .forward).
FTR, earlier, I simulated a few bodged .forward file configs (and also the
absence of a .procmailrc in conjunction with a valid .forward), in an
attempt to reproduce the sort of vague "absolutely nothing's being logged"
condition you reported, and the following was logged *BY THE MTA*, as a
function of failing to take successful action on the .forward file:
Mar 28 15:50:27 wargames sm-mta[32422]: h2SNoQZe032421: to="|IFS=' ' &&
exec /usr/local/bin/procmail -f- || exit 75 #someuser",
ctladdr=<someuser(_at_)test(_dot_)domain(_dot_)tld> (1001/100), delay=00:00:00,
xdelay=00:00:00, mailer=prog, pri=31186, dsn=5.3.0, stat=unknown mailer
error 126
Mar 28 15:51:52 wargames sm-mta[32433]: h2SNppZe032432: to="|IFS=' ' &&
exec /usr/bin/procmail -f- || exit 75 #someuser",
ctladdr=<someuser(_at_)test(_dot_)domain(_dot_)tld> (1001/100), delay=00:00:00,
xdelay=00:00:00, mailer=prog, pri=31186, dsn=2.0.0, stat=Sent
Mar 28 16:24:27 wargames sm-mta[32537]: h2T0OQZe032536: to="|IFS=' ' &&
p=/usr/local/bin/procmail && test -x $p && exec $p -Yf- || exit 75
#someuser", ctladdr=<someuser(_at_)test(_dot_)domain(_dot_)tld> (1001/100), delay=00:00:00,
xdelay=00:00:00, mailer=prog, pri=31186, dsn=4.0.0, stat=Deferred: prog
mailer (/bin/sh) exited with EX_TEMPFAIL
If your host doesn't log something similar - even for the now successful
deliveries - you need to spend some time in the other "utterly useles"
manpages and resources for your MTA and *nix system.
the mail is NOT bouncing. how's that for a clue? it's just sitting there
in the queue.
Heh. Check my disclaimer page, way down near the bottom. To summarize: if
your original .forward was bodged, sendmail (your MTA, not procmail) will
have STORED that bodged syntax into the queue file, and won't give a flying
hoot about whether you change the contents of the .forward, remove the
.forward, or even restart the MTA. Now, I don't know what you're running
for an MTA, and at this point, I really don't care - but there's a good
chance that it similarly "optimizes" the resolution of the local delivery
and caches its initial resolution for the delivery, and that's it until it
delivers or times out.
it eventually gets delivered if I turn procmail off.
I'll avoid being obtuse and assume you did this with the built-in on/off
switch, since there's easily over 1/2 dozen different methods one could go
about "turning procmail off" depending upon how you're invoking it.
there are no EX_TEMPFAIL messages in ANY logs.
do you have another theory you want to test?
No, I provided several pointers to sources of information to you, despite
an inadequate picture of your complete problem, and they didn't pan out for
you, including apparently, running the diagnostic script.
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.
With no specific correlation between the results - say, the existance of
the error in the logfile, or differences in the queue or bounce.
and with three different .forwards.
The details of two of which you did not provide in your original message,
BTW. The variety of .forward syntaxes is large, as is the variety of ways
in which someone can bodge the syntax, which CAN lead to ongoing delivery
problem with queued messages.
and the third (ahem) is with -f- and -Yf- using the long obtuse examples,
Your third example then is completely redundant. -Yf- rather clearly
includes f-. I don't know why anyone would think that would fix anything,
but hey, if I were in an airplane in a nosedive, I'd probably just start
toggling switches too, hoping that something would change.
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.
Q: did you ever confirm the actual path of procmail on your system? Yea,
that "excess crap" tells us you're using a specific path. Which, JFTR, the
procdiag script would report, and you could easily confirm it against.
so here's an overview just because you like being obtuse:
You want to get hostile because I pointed out that your original message
lacked any connections between SPECIFIC invocations and SPECIFIC results
and warning messages? C'mon, don't blame me if you didn't provide
sufficient data in your original post to diagnose _anything_ about your
problem.
Version?
Perms?
Ownership?
Path validity?
MTA logs?
MTA reactions?
I challenge you to try and get a mechanic to properly diagnose your car
when you provide him as much information as you provided in your original
post. Also, if you respond in a like fashion to the mechanic when he asks
you to check and report that information, don't be surprised if he hangs up
on you and returns to his paying customers.
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.
Ah, 'zactly - you reported a problem, but didn't correlate the symptoms to
any of your specific tests, just dumped out a jumble of miscellaneous
characteristics, and one of your .forward formats, which wasn't necessarily
correlated to the one error message you reported from your system log.
Surely, if you think about it for a bit, you'll realize that nobody can
help you if there's inadequate description of tests and their individual
results on your part?
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.
I wrote the script specifically to avoid playing 20 questions with people
who for some reason choose to avoid answering the questions completely when
they're the ones experiencing problems. If after you've reviewed the file,
you're satisified that it won't delete the contents of your account,
overwrite your kernel, or forward sensitive files to leet crackers in a
third world nation, you might consider RUNNING the script and reviewing the
output.
Not surprisingly, a number of people have downloaded it and a short while
later, their problems mysteriously went away, apparently without any
connection to the various diagnostics output by the script, such as rc file
perms/ownership, which is a common gotcha for procmail newbies.
I've been a regular contributor on this for approaching ten years, and in
that time, the number of times people have omitted or outright jumbled
significant diagnostic information in the quest to avoid revealing too much
about their configuration defies quantification because it's happened so
many times. Whenever possible, you should _DIRECTLY_QUOTE_ logged errors,
_DIRECTLY_QUOTE_ .forward and pertinent portions of rcfiles,
_DIRECTLY_QUOTE_ permissions and ownerships, right from the output of 'ls
-al'. Indirectly summarizing such things, or rewriting portions of scripts
on the fly when posting them in an email, often conceals the real problem
because such methods are imprecise and prone to operator fsckups.
Next time, don't take it like a personal assault when someone points out
that you didn't provide sufficient information for a diagnosis, and they
ask for clarification.
---
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
|
|