Re: sendmail.el bug or expected behavior?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> properly configured system.  (What would be "too much delay" in
> situations where something wasn't actually wrong and was legitimately
> causing the delay?)

If sendmail is called with -oeq, it should only cause delay if there's
a problem such as "your hub is down or slow".  But if you access your hub
through a 56K connection and send a 50MB attachment, then you'll suffer
a serious legitimate delay (unless you use a local queue of course).

> 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.

I agree.  But right now the mail-interactive setting of t implies a slower
delivery than -oeq (it might try to contact the destination which will
sooner or later be unavailable).  I.e. right now you can choose between
"fast and dangerous" or "very slow and safer".
I'd like the default to be inbetween (i.e. -oeq).


        Stefan