Re: problem with procmail

At 11:28 PM 3/28/2003 -0800, Professional Software Engineering wrote:
> 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.
packages? well this isnt a linux distro.
it's solaris, as I mentioned several times
its the one you get when you hit download off the procmail.org website.

> Pedantic?  You bet - this stuff is significant for some problems.
perhaps. but even more significant is actually reading the email, which you 
didn't do.
> You must be referring to a different procmail package.
>
>         man procmail | grep -A10 -i suspicious
nope. doesn't apply. I already told you, the file permissions were correct.

> 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:
I did check the permissions. they were the same as they were the LAST dozen 
times I copied the files.
there's no reason a simple "cp" would change the permissions. (cp 
forwardnew .forward) gimme a break.
and I checked after I got that message, heck I check BEFORE I got that 
message too, just to be sure.
nothing ever changed in that regard.

> 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.
because it didn't help.
I copied them after your message too.
I copied the files at least a dozen times.
before reading the man pages,
before getting the errors.
after the man pages
after the errors
after your email

made no difference.

then about an hour later, yet again I copied them, except that time 
everything worked.
and you're telling me it was a permissions thing
dont think so.

> 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.
well they were correct.

> 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?
then why didnt it work the other 11 times or so I did this?
and even the time just after getting your email and rechecking everything 
when I did it then as well?
> 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).
unless procmail was getting stuck and unable to deliver, in which case it'd 
be procmail's job to log it.
which it finally did, twice. as I mentioned.

> 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:
> 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.
thats nice. maybe the forward wasn't failing. maybe it was procmail hung up 
somehow.
> 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.
yes you do know, I told you, postfix. several times.
perhaps if you actually read the message.
if it attempts to deliver and procmail hangs, don't know what condition it 
gets into.
> 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.
delete .forward does a pretty good job of this

> 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.
prexactly.
but deleting and recopying, then deleting and recopying, then deleting and 
recopying
seems to have fixed it.

> iWth no specific correlation between the results - say, the existance of 
> the error in the logfile, or differences in the queue or bounce.
yes a specific correlation between the results. did you not read again?
no logs, no errors, no messages. no bounces. no differences in queue (that 
I could detect)
> 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.
oh please. there wasn't enough difference to be worth mentioning.

> 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.
exactly. nothing is working, so try every possible combination. process of 
elimination.
maybe you've heard of that.

> 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.
yes of course I did. and as I mentioned, it made no difference.

> 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.
I'm not hostile. In retrospect I provided more than enough info.

>         Version? whatever is on the download link at procmail.org
>         Perms? default when creating any new file
>         Ownership? duhhh
>         Path validity? yes
>         MTA logs? none, until recently
>         MTA reactions? no messages, no delivery, as mentioned
> 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.
they do it all the time.
maybe they're just not as obtuse as you,
and maybe they actually read. hrm.

> 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.
Yes I did, more than once. learn to read.

> 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?
BS

> 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 didn't actually. but never mind that.

> 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.
I did everything humanly possible. many times.
it just "started working" with no changes in what I did or how.

> 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.
go stuff yerself. no. really.
and drink those 6 bud's you need them.

Dan. 


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail