positive exit code in case of error?

oops i'd posted this with reply to a previous reference thread.
Hi mailman developers. Another suggestion, apologies if this is already implemented in a newer version... if there is a permission error or other exception thrown which prevents posting, it would be helpful if the process could return a non-zero exit code.
When sendmail pipes to the list through /etc/aliases, if there is a permission problem (like on digest.mbox) the message just disappears without a trace - no post to the list, no bounce to the poster, no archive, nothing except the exception in /var/log/mailman/error and a 'SHUNTING' message. (I have some sysadmin scripts that manage permissions, and there was a bug.)
If a pipe process exits with a positive integer exit code in case of error, sendmail bounces with "554 Service Unavailable" and provides useful logging info. This would be a lot more informative than having the mail vanish into thin air.
Thanks!
Mark

Mark Hedges wrote:
Hi mailman developers. Another suggestion, apologies if this is already implemented in a newer version... if there is a permission error or other exception thrown which prevents posting, it would be helpful if the process could return a non-zero exit code.
When sendmail pipes to the list through /etc/aliases, if there is a permission problem (like on digest.mbox) the message just disappears without a trace - no post to the list, no bounce to the poster, no archive, nothing except the exception in /var/log/mailman/error and a 'SHUNTING' message. (I have some sysadmin scripts that manage permissions, and there was a bug.)
The problem is that sendmail (or other MTA) pipes the message to a wrapper which does nothing more than queue the message in one of Mailman's queues. If this wrapper or the simple script it invokes encounters an error, it will return an non-zero exit status, but the errors you are talking about occur later in processing by one of the qrunners.
If a pipe process exits with a positive integer exit code in case of error, sendmail bounces with "554 Service Unavailable" and provides useful logging info. This would be a lot more informative than having the mail vanish into thin air.
The mail doesn't vanish into thin air. As you note, the exception is logged in Mailman's error log and the message is shunted, and it can eventually be unshunted after the underlying problem is fixed.
The following comments from the 'post' script run by the wrapper for a post may be of interest
Immediately queue the message for the incoming qrunner to process. The advantage to this approach is that messages should never get lost -- some MTAs have a hard limit to the time a filter prog can run. Postfix is a good example; if the limit is hit, the proc is SIGKILL'd giving us no chance to save the message.
What you are asking is the the pipe invoked by the MTA run at least the entire IncomingRunner process before exiting back to the MTA. This is not feasable.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark Hedges
-
Mark Sapiro