Re: Re: RFC: Making mail-transport-agent Priority: optional
Don Armstrong wrote:
> On Sat, 15 Oct 2011, Ben Hutchings wrote:
> > If I want to send mail from my personal address I should send it
> > through my own smarthost. If I want to send mail from my work
> > address I *must* send it through the work smarthost (thanks to SPF).
> > I could possibly configure this at the MTA level, but no other user
> > should be allowed to use my credentials to send mail through the
> > work smarthost.
>
> Right, so what would be ideal is if a transport-only MTA knew enough
> to read ~/.config/mail to figure out that if it was executed as your
> user, and you were sending with From: ben@work.org,[1] it should use
> smtp.work.org with your specific configuration. Then, if you happened
> to be sending using mailx to work, or needed to switch MUAs, it would
> all "just work" correctly, without needing to manually configure
> things again.
That sounds like an interesting solution to make MTAs handle
configurations that MUAs currently handle just fine.
Alternative proposal: create a standard for storing SMTP (and IMAP)
server information in ~/.config/mail , and have MUAs standardize on that
location for storing email configuration (or at least have the option to
import/export that configuration). MTAs could choose to read that
information too, if they have support for per-user configuration.
(Also note that some people want to use different MUAs for *different*
uses; at one point I used evolution for work mail and mutt for personal
mail. So, teaching the system MTA about both doesn't help; it just
makes the configuration more complex.)
Either way, I don't think either of those proposals relates to whether
an MTA should appear in the default install.
You're suggesting that we should make MTAs capable of handling
configurations that MUAs currently handle just fine, *and* convince
users to use MTAs that way rather than configuring their MUA as usual,
and then keep MTAs in the default install in the hopes that users will
use them.
I'm suggesting that we should recognize that most users use
configurations that involve MUAs talking SMTP, without using MTAs, and
change our default install accordingly.
Debian Policy tries to be descriptive of current practice, rather than
prescriptively determining current practice. Shouldn't standard operate
similarly, particularly given that we define it based on user
expectations?
> > For my own systems there is a reasonable system default of using my
> > own smarthost, but I wouldn't expect most households to have that.
> > Other people could use their ISP's smarthost. But in general, each
> > member of a household might use a different mail service. Then what
> > would be the system default?
>
> Presumably, one would select one of them to be the system default,
> which would also be the user default.
And what if no sensible default exists, because none of them make sense
as the system default? The configuration you describe either requires
allowing the system to send mail as one of the users, or giving the
system an email account of its own. Neither one seems appealing. I'd
argue that the system should not be sending external mail by default.
On a related note, consider that some users intentionally don't store
their email passwords, and instead type them every time their MUA
prompts for them (perhaps allowing it to remember them for the session
but not store them on disk). That configuration works with MUAs, but
not with MTAs. (Again, fixable, but already working with MUAs.)
- Josh Triplett
Reply to: