procmail
[Top] [All Lists]

Re: is this procmail rant justified?

2002-01-31 13:45:46
"Marco Fioretti" <m(_dot_)fioretti(_at_)inwind(_dot_)it> writes:
I agree with your conclusion above. Most probably however,
the message was referring to some now really obsolete version.
I'd really like to have some confirmation/comment from the
authors, or anybody who really knows procmail internals.

I guess that means me.  First, let's go back a look at the orignal rant:


The control language is merely arcane.

(i.e., it's what's known as a "Domain Specific Language".  That's
considered a feature in many fields.)


The implementaion in C is abysmal and is just as unreliable and insecure
as you would expect of any C code that doesn't check return codes from
system and library calls and uses fixed size buffers with no bounds
checking.  (Core dumps?  Check.  CERT advisory?  Check.)

Procmail checks the return code of every system and library call with a
couple exception where the return code can't be trusted because of NFS.
In those cases it very carefully performs additional checks to find
the real status.  It is true that old versions didn't check for buffer
overflows and that it took several revisions to get right.  Then again,
_most_ programs that were first written in 1990 had buffer overflows.
It would be interesting to know what version of procmail he based his
comments on.

As for CERT advisories, I invite everyone to visit www.cert.org and search
their website for "procmail".  The only hits are advisories suggesting
that you use procmail to mitigate bugs in *other* programs!


He continues:
Aside from the execrable quality, the orginal author confuses mail
envelope addresses with mail header addresses, so procmail can't do basic
things such as forward mail without changing the envelope sender, causing
bounce messages to be misdirected and encouraging mail loops.

Let's see:
1) procmail delivers to the addresses specified on its command line, so
   that if it delivers to the wrong address it's the fault of the invoker.
   Procmail doesn't parse the header to extract address, so it can't be
   delivering to header addresses unless *you* write the recipes that do so.
   This is mostly a problem in broken virtual domain setups where the
   procmail _before_ procmail has lost the envelope recipient information,
   at which point there's nothing procmail can do to get it back.

2) Whether mail forwarded via '!' actions _should_ retain the original
   envelope sender is debatable.  There are good arguments for it to *not*
   do so and that is the default in procmail.  If you need to do so, you
   can extract the original envelope sender address from the Return-Path:
   field and pass it through to sendmail by putting the correct -f option
   in the ! action.

3) The code and comment style used by procmail is not my favorite and I
   think it has had the effect of keeping people away from the code.  I
   think that's unfortunate and have considered changing it, but I have
   more important things to do in life right now.


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