On Mon, Dec 31, 2001 at 05:50:22PM -0500, Derek Broughton wrote:
> > Here's the problem. A MUA should not be dealing with SMTP -- an MTA
> > should. mutt (and, AFAIK, elm and pine) do not do SMTP at all.
> > Instead they pipe the message to the system's MTA and let it take
> > responsibility for delivering it.
> That hair needs an electron microscope to split. :-)
Not at all. There is a huge difference. Do you, for example, always have
an X/Window display available. The reasoning is very similar.
> I can't imagine any good reason why an MUA shouldn't deal with SMTP. In
How many MUAs do you know which are able to spool messages if the
receiver SMTP doesn't want to accept them just yet?
> fact, as configured, SMTP on localhost is usually your MTA. It makes
No it's not. Please read up on /usr/{lib,sbin}/sendmail -bs which should
be the canonical submission form for an MUA.
> much more sense for every MUA to assume it has access to an SMTP port on
> _some_ host than to assume that it will have access to an MTA program.
Huh? have you never had a network outage?
> I don't think I want just anybody able to execute sendmail or exim.
Ummm....
The reason that one should use the program and deliver stuff via a pipe
on the local machine is that SMTP requires ability to cope with network
outages and the transfer of responsibility. These are both complicated
to deal with, because you need to have a spool of messages, thus it is
the MTA's job.
Consider, for example, the case where a daemon has stopped or been
stopped, you get a "Connection Refused" error back again. An MUA that is
trying to do direct SMTP will have to say "do you want to postpone this
message", one that does SMTP by invoking /usr/{lib,sbin}/sendmail will
just work. The queuing system will just deal, and the message will get
delivered at some point when network connectivity happens. This is the
main reason.
However, there are other reasons - verifying a network connection can be
complicated, and a TCP stream requires significantly more in the way of
kernel resources than a pipe. A large number of SMTP implementations are
buggy in some respect, it appears to be quite a difficult thing to get
right, whereas a pipe will work sanely.
Leave the job of queuing and accepting responsibility to the system which
can deal with it.
Happy New Year
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/