[ mailman-Bugs-1519881 ] lost messages risk with contrib/mm-handler

SourceForge.net noreply at sourceforge.net
Mon Jul 10 12:53:11 CEST 2006

Bugs item #1519881, was opened at 2006-07-10 10:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Barrett (ppsys)
Assigned to: Nobody/Anonymous (nobody)
Summary: lost messages risk with contrib/mm-handler

Initial Comment:
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 ($_);

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 <dgc at uchicago.edu>, 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:


such as:
		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.


You can respond by visiting: 

More information about the Mailman-coders mailing list