Re: Re: RFC: Making mail-transport-agent Priority: optional
Philipp Kern wrote:
> On 2011-10-15, Josh Triplett <firstname.lastname@example.org> wrote:
> > MTAs would need to advance quite a bit to get anywhere near as usable as
> > a MUA that speaks SMTP, not least of which in error reporting. (Most of
> > the people I know who run local MTAs have had at least one "all my mail
> > got stuck in a queue for one or more weeks" story.)
> Erhm, did you ever encounter a 5xx SMTP error message with, say, Icedove?
> You don't want to be in that situation, really. You want the MTA to accept
> everything from the client and sending him a bounce to his mailbox because the
> applications don't cope with it in a sane way neither.
Consider the case of incorrect SMTP AUTH credentials, either because the
user failed the initial setup, or because they changed their password
and haven't yet remembered to update their client. A MUA can give a
friendly error message, and point the user towards their username and
password. An MTA will likely queue the mail and then never manage to
Using something like ssmtp or equivalent that talks to SMTP while
sendmail runs (and doesn't return successfully unless the mail gets
queued by the SMTP server) would solve part of that problems, but then
your MUA ends up reporting a much less friendly error message straight
from sendmail, and doesn't necessarily know how to help the user resolve
Many other cases exist where the SMTP server knows it can't send the
mail, and can tell the client immediately.
- Josh Triplett