Re: problem with procmail

Food for thought:

Please review your two initial posts on this matter and consider that the 
procmail path in the .forward which you provided in your original message 
was /usr/bin/procmail, whereas in reply to my inquiry about the other two 
forms of .forward which you had employed, you provided a .forward syntax 
specifying /usr/local/bin/procmail, insisting that it was "a lot of excess 
crap," when in fact, the path difference IS rather significant, even if you 
wish to brush it away as unimportant.
This difference could be due to transcription error (instead of importing 
the actual content of the file, you winged it), or perhaps you actually did 
have separate path specs, which, IMNSHO, underscores the point of my asking 
for the clarification on actual .forward syntaxes used, whether you 
believed the request to be, as you put it, "obtuse".  In either case, it of 
course compounds the diagnostic process, since the following possibilities 
would have existed due to just this ONE difference between the two syntaxes 
which you provided (discounting the expansion of the problem matrix due to 
various other possible errors such as file permissions and ownership):
        1. You only have ONE binary, in ONE of the two paths.  Therefore, one
                of the two pathspecs would cause an error condition, forcing
                a requeue (exit 75) as long as that .forward was in place, or
                if your MTA caches the content of the .forward, until the
                messages were purged from the queue.

        2. You have a binary in one path, and a symlink in the other.  Either
                pathspec syntax would therefore work.

        3. You have SEPARATE binaries in each path, which may or may
                not be the same version of procmail or even compiled with
                the same options.  This can lead to different results
                depending upon which binary happens to be invoked.  Depending
                upon which one appears in your path, you might believe you're
                running THAT version (invoke 'procmail -v' at your shell to
                obtain version information for instance), when in fact your
                .forward is making reference to a different version located in
                a different (explicit) path.

        4. Neither path contains a procmail, thus neither pathspec form
                would successfully deliver.  This however, is unlikely.

        5. You transcribed the paths errantly, and as used, they were actually
                identical, though the reader is left wondering which is
                correct, and whether you actually have a procmail binary there.

A few, more escoteric fault conditions could also have resulted, but the 
above should highlight the chief ones which would have led to differing 
results between your various .forward forms.
Oh, and yea, if you had a .forward with valid syntax which invoked a bad 
.procmailrc, then subsequently copied that .forward off someplace, created 
a different one, and while bodging around, FIXED the .procmailrc problem, 
but it wasn't being used because the bodged .forward, and THEN you copied 
the original .forward back, yea, things would magically work.
---
 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