Re: RFC: Making mail-transport-agent Priority: optional
On Fri, 14 Oct 2011 at 16:02:09 -0700, Don Armstrong wrote:
> On Wed, 12 Oct 2011, Josh Triplett wrote:
> > End-user systems (desktops, laptops) typically handle mail via one
> > or more smarthosts elsewhere, driven by MUAs that know how to talk
> > SMTP.
> While this definitely is the current state, it's not optimal.
What's bad about it? What's better about sending through an MTA,
particularly on a machine that basically only has one user?
On a personal desktop or (particularly) laptop, there's often no practical
difference between configuring mail once per machine or once per user,
because the machine only has one user anyway; but configuring for the
machine requires root authentication and configuring for the user
doesn't, so for a naive user, the MUA is better.
Credentials for authenticated SMTP are typically per-real-person anyway,
so ideally you want per-user configuration. (My mailserver has ended up
with user accounts representing machines too, solely so they can have
system-wide mail submission...)
Sending through an MTA does let you press "send" without connectivity
and have the mail server submit the mail eventually, but without any
particularly useful feedback to the user (who can't easily distinguish
between "mail got sent", "mail is still queued", and "an error
occurred, the mail will never arrive"). Many GUI MUAs will retry mail
delivery or have a "work offline" mode, and a GUI MUA can give the
user useful feedback; so for a naive user, the MUA is better.
I concede that using an MTA may be better for Mutt users, but I would
imagine that anyone who's taught themselves to use Mutt is quite capable
of installing an MTA to go with it. My Mutt configuration currently
uses a local postfix installation for personal/Debian mail, but speaks
SMTP directly for my work mail; I'm honestly not sure what I gain from
the local postfix installation, except the local-mail-receiving side
(cron jobs etc.), which is orthogonal to whether I use the MTA for