lost messages risk with contrib/mm-handler

[Ppsys]

As far as I am aware, this bug is present in all versions of the
contributed sendmail mailer contrib/mm-handler

The Perl code in subversion /trunk/mailman/contrib/mm-handler
contains the following fragment:

  $wrapper = new FileHandle "|$MMWRAPPER $cmd $list";
  if (!defined($wrapper)) {
   ## Defer?
   print STDERR "$0: cannot exec ",
    "\"$MMWRAPPER $cmd $list\": deferring\n";
   exit (-1);
  }

  # Don't need these without the "n" flag on the mailer def....
  #$date = &mboxdate(time);
  #$wrapper->print ("From $sender $date\n");

  # ...because we use these instead.
  $from_ = <STDIN>;
  $wrapper->print ($from_);

  $wrapper->print ("X-Mailman-Handler: $VERSION\n");
  while (<STDIN>) {
   $wrapper->print ($_);
  }
  close($wrapper);

This is the code that actually hands off the message from sendmail to
the mailman wrapper.

I note that it still has the problem which the original author, David
Champion <email address hidden>, was made aware some years ago.

The Perl code fails to check the value returned by the close($wrapper).
As the FileHandle being closed is a pipe, the close operation returns
the status value returned by the Mailman wrapper at the far end of the
pipe. This value should be checked.

Not checking this status value means that if the mailman wrapper fails
to successfully enqueue the message for any reason this is not
detected by the sendmail mailer. Meanwhile, the mailer blithely tells
sendmail that the message was successfully delivered.

The likely consequence is that the message will be silently lost.

Adding a test after:

  close($wrapper);

such as:
  close($wrapper);
  die "Mailman delivery wrapper failed" if $?;

nods in the direction of correcting the problem.

I leave aside suggestions that more appropriate, mail related, return
code values might sensibly be used by this sendmail mailer, amongst
other things.

btw: this risk is not theoretical. Some years ago it caused the only loss
of messages by our Mailman system that we have experienced. We
initially fixed, then replaced with a python implementation and finally
ceased all use of this type of sendmail mailer.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1519881&group_id=103&atid=100103]