Re: sendmail.el bug or expected behavior?

[Ian Jackson]

Simon Josefsson writes ("Re: sendmail.el bug or expected behavior?"):
> Richard Stallman <address@hidden> writes:
> > I would expect people to design an MTAs not to wait very long
> > in the process that you created to send the mail.  If sendmail
> > does this badly, does that mean they all do?
> 
> I guess not.  But how do MTAs implement this, if they don't wait in
> the foreground?  Simply storing the e-mail in /var/spool/mqueue and
> hope that the system is polling the queue every hour or so might not
> be reliable.

When a user asks to send a mail, there is not time to do a delivery
attempt to remote systems.  Remote systems are allowed to be down
(TCP connection times), and they're allowed to make the SMTP client
wait for around 5 minutes _per SMTP response_, so a whole delivery can
(and sometimes does) take quite a while even if it's going to succeed.

If you think the system should try to do a delivery to another site on
the Internet when the user hits `send', what do you think it should do
when the delivery attempt takes longer than the user is reasonably
prepared to wait ?  (Personally I want mail sending to be nearly
instant - pratting about waiting for SMTP is what I have computers
for.)  MTAs are not typically designed to allow the delivery attempt
to be retrospectively made noninteractive, and the whole delivery
attempt might last longer than the lifetime of the MUA, so you can't
just remember you have it going and try to tell the user later.

The fact is that delivery to remote sites, queue management, retry,
timeouts, etc. are the _functions_ of an Internet MTA !  Without those
functions being implemented somewhere you can't send mail to the
Internet (or at least, not reliably).  Ie, without a queue, and a
queue runner (somewhere), your mail is already broken.

Now, traditionally, UN*X used to have the model that every host was
its own site.  So every host has to take responsibility for
maintaining a mail queue.  In this model you should install a
full-scale Internet MTA on your system, and when the user hits `send'
the local full MTA should accept responsibility for it - putting it in
the queue, and delivering/retrying as necessary.

Nowadays people often prefer to have simpler `client' systems, many of
which run some kind of UN*X.  In this situation you may indeed not
want to try to support and maintain a full MTA on such a client
machine; instead, you have your some simpler (or more simply
configured) software locally which attempts delivery to a mail hub,
and the mail hub performs the necessary queueing etc.  In this model
when the user hits `send' the local mail software should immediately
attempt to pass the message to the mail hub and report success only
if and when the mail hub says `OK'.  When the mail hub is down no-one
can send mail, and attempts to do so can hang unpleasantly.

Both of these are sensible models.  Moreover, they have _identical_
requirements for the functionality and semantics of /usr/lib/sendmail:
in all cases, the calling program _must_ wait for sendmail to exit and
check the exit status (since on a modern UN*X, and many older ones,
system resource problems can always cause failures).  When the local
/usr/lib/sendmail exits nonzero it has taken responsibility for the
delivery of the message.  What this means in the two models is
different: with the full MTA it means that the message has been
queued; with client-and-hub it means that the message has been
transferred to the mail hub (possibly by SMTP) and the mail hub has
accepted it.

What this shows is that this is a matter of _system configuration_,
not a matter of _MUA configuration_.  Emacs shouldn't need to know
which model is in use.

Now let us consider options to /usr/lib/sendmail.  The option set was
designed for the traditional full MTA model.  With queueless client
passing mail by SMTP to a hub, most of these options don't make any
sense.

The SMTP spec says that the hub should say `OK' as soon as it has
received the message, without performing a delivery attempt, and there
is no way for a client to request specific error behaviour; if
delivery fails later the hub is supposed to generate a bounce.  So an
SMTP client implicitly gets (from the hub) the behaviour equivalent to
-odq with a mixture of reporting error codes now or bouncing later
depending on when the hub detects the error.

>From the point of view of a MUA on the client, a MUA passing `-odq'
couldn't possibly mean putting the mail in the local queue, since
there isn't one.  If the system is supposed not to have a local queue,
but passing -odb or -odq overrides this and puts the message in it,
then this is a configuration problem.

>  This approach also has the disadvantage that any errors
> that CAN be detected (and reported to the user) immediately, probably
> won't be, since /usr/lib/sendmail will always just push the message on
> the queue, without doing any error checking or simple delivery
> attempts.

Errors which depend on information from the global Internet, or
dependent on the outcome of local delivery attempts, can't in general
be detected during the time which it's reasonable to wait when sending
mail.  Simple local addressing errors can easily be detected anyway
when the mail is queued.

Of course the current Emacs default is that any errors which are
detected by the MTA are not reported anywhere.  For example, if you
make a mistake while editing the headers of your mail, and commit a
syntax error, your mail will silently vanish (depending on local MTA
and configuration).

Ian.