[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Making mail-transport-agent Priority: optional



On Sat, 2011-10-15 at 09:53 -0700, Steve Langasek wrote:
> On Fri, Oct 14, 2011 at 04:02:09PM -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. It would
> > be ideal to have an MTA like esmtp or similar,[1] which was easily
> > configured and could then be used by all things that need to send
> > outgoing mail without configuring them directly. [Possibly with
> > unified user configuration in .config/mail or similar which overrode
> > the system configuration and could be written and read by any of the
> > existing MUAs we have.]
> 
> > Instead of band-aiding over this problem, lets actually fix it.
> 
> Hear, hear.  "How do I deliver mail?" is a per-system setting, not a
> per-application setting,

It's not per-system, or even per-user.

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.

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?

> and the move towards having MUAs talking SMTP
> directly to send mail is a flawed model picked up on the Linux desktop from
> certain other OSes.

While I agree that MUAs tend to have lousy SMTP implementations, this is
a necessary option.

> The right solution here is to fix the MTAs to be
> configurable from the desktop, and fix the MUAs to use the MTA - *not* to
> get rid of the MTA.

The MTA has to be able to get error reports back to the MUA, so we need
the MUA to support local mail too.  Now the user has an MTA and two
accounts in the MUA, when all he wanted was a single account.  How much
complexity should we foist on users for the sake of doing it 'right'?

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: