Re: sendmail.el bug or expected behavior?

[Rob Browning]

Rob Browning <address@hidden> writes:

> Emacs doesn't always check for a non-zero exit status from sendmail,
> which can lead to silent mail lossage.  For example:

Presuming I haven't misunderstood, where do we stand here?  From what
I gather everyone would be happy if we could do something that would
make emacs always wait for the MTA to quit (checking the exit code),
but only if that doesn't introduce "too much delay" when running on a
properly configured system.  (What would be "too much delay" in
situations where something wasn't actually wrong and was legitimately
causing the delay?)

Personally, I can't imagine it being OK to leave things with potential
for silent mail loss, especially not as the default, even if fixing it
might introduce a 5 minute delay.  If there is a 5 minute delay then
that just tells me that my MTA is broken (probably misconfigured), or
perhaps my hardware is bad, etc., and that I need to look in to it.
Of course even if I can't fix the delay, *and* I don't mind the extra
risk, I can always decide to set mail-interactive to nil.  This issue
could even be a FAQ.

At the very least, I'd submit that perhaps the documentation for
mail-interactive should be adjusted to provide more warning.
i.e.

  "Setting mail-interactive to nil may cause you to lose mail under
   any number of unpredictable conditions[1] without any warning.
   Emacs will *not* check to see if the mailer process failed."

([1] Where unpredictable conditions include but are not limited to
 your partition filling up, broken libraries during or left after an
 upgrade, mailer running out of memory, PATH altered improperly, etc.)

IMO if the common mailers (sendmail/postfix/exim/etc.) can be told to
queue the mail reasonably quickly these days, then I'd prefer to see
us figure out how to have emacs to do that by default while still
making it easy for people in special circumstances to arrange for
something faster, though perhaps less safe.

Also, I'm not sure it's relevant (or even feasible with emacs current
code), and I don't use any of these systems myself, but it seems like
a lot of other MUAs just queue up the outgoing mail themselves and
either send it via SMTP, either on-demand or in the background, and
they treat messages that haven't made it out yet in much the same way
that emacs treats unsaved buffers -- if you try to quit, they ask you
about them.  For people who have a properly configured
postfix/sendmail/exim/whatever queuing arrangement, this might not be
interesting, but for others, perhaps.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4