[lsb-discuss] [Fwd: Re: Possible to get rid of /usr/bin/sendmail requirement in LSB 4.1?]

Theodore Tso tytso at mit.edu
Sat Jun 13 09:11:23 PDT 2009


On Sat, Jun 13, 2009 at 04:13:47PM +0100, Alan Cox wrote:
> 
> The standard behaviour is well documented elsewhere so could be
> referenced quite easily. The return codes are all precisely defined

I agree that a distribution that did this for /usr/sbin/sendmail

#!/bin/sh
echo "This distribution is too lazy to figure out how to make sendmail work"
exit 69	   # EX_UNAVAILABLE

would be legal within the LSB specification.

It then becomes a quality of implementation issue for the
distribution; there are a lot of current and historical Linux and Unix
programs that assume that /usr/{lib,sbin}/sendmail works.  Wishing
that they go away because it is inconenient to make them work reliably
for users using ISP-mandated mailhubs, and so are hard to configure
automatically does not change the reality.

Again, I believe the right long-term answer is some kind of mail
configuration wizard that can autodetect the mailhub, perhaps using
DNS Service Discovery if the ISP was enlightened enough to provide the
appropriate DNS-SD/Bonjour records, or by detecting the local ISP in
use and lookup up the ISP in a publically maintained database with
mail submission configuration information.  There are MTA's that can
handle SMTP authentication, and defer sending e-mail in the mail
submission queue until the user logs in and provides the appropriate
credentials for SMTP authentication to work.  Providing the glue
between the MTA and the desktop login (perhaps using PAM) is either
(a) a great opportunity for someone looking to "stake some ground" in
terms of a potential open source project, or (b) the opportunity for
distribution differentiation.

If Ubuntu were to do something like provide a shell script which
always exited with error code 69, I predict it wouldn't be long before
the mocking on Slashdot would begin, since I suspect most people would
agree with me that this would be majorly lame.

							- Ted


More information about the lsb-discuss mailing list