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

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

> Am 2011-10-13 13:06:49, hacktest Du folgendes herunter:
> > On Thu, Oct 13, 2011 at 12:02:11PM +0200, Luca Capello wrote:
> > > On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> > > >   For most users, these questions will duplicate the process
> > > >   they later go through to configure their MUA.
> > > . o O (simply because these MUAs do not use the local sendmail)
> > Few MUAs even have that option.  And why should they, when they can talk
> > directly to the user's mail server rather than to a local MTA acting as
> > intermediary and passing mails to the user's mail server?  More
> > importantly, MUAs assume (correctly) that most local MTAs don't
> > necessarily know how to send external mail, if they exist at all.
> But if you do not use the local MTA, you have to configure  EACH  client
> manualy...  and if you have more then one ISP or Smarthosts,  it  become
> worse!  Most MUA which support SMTP can not route correctly.

Few users use more than one MUA, so they only need to configure any
given SMTP server once (usually at the same time as configuring IMAP or
POP).  And several MUAs have some extra smarts to very quickly configure
all of those for a given ISP based on a database of ISPs, as well as
various other helpers to make configuration simpler.

(Unrelated to the current discussion about MTA priority, but in response
to your point: most of the graphical MUAs I've seen have options to
choose different SMTP servers for different email addresses.  But most
of the mail servers I've seen tend to just require SMTP AUTH, and then
let you use any From address you want, so you can send all of your mail
with one SMTP server.)

> > "other things are worse" is not an argument against dropping
> > exim4-daemon-light from standard. :)
> Right, we should use "courier-mta" instead!  ;-)


> > That's a problem, not a feature.  logrotate exists to make sure the disk
> > doesn't fill with logs; no such mechanism exists to make sure the disk
> > doesn't fill with mails.  One of many reasons to log rather than sending
> > mail.  And having two independent logging mechanisms seems suboptimal at
> > best.
> Normaly mail to <root> are forwarded to the <user> of the system.
> Or do you wan to say, that exim does not forward the mail to the user?
> If I am right, all MTAs ask, to which user the <root> mails  schould  be
> forwarded.  If you disable forwarding of mail you have broken the system
> yourself.

It doesn't matter what local user system mail gets forwarded to (and d-i
arranges to have that mail forwarded to the user created at install
time).  Users don't check the local mail for their user account, either.

> > Would you object less if cron had an option to log to syslog instead of
> > sending mail, and used that option automatically if it didn't find a
> > sendmail?
> Ehm?  Cron is loging since more then 12 years to syslog...

Cron logs the start and end of jobs, and various other status messages,
but as far as I know it can't log the output of cron jobs; it only knows
how to mail that.  I was suggesting that if capturing the output of cron
remains a sticking point for making an MTA optional, it doesn't seem
that difficult to have it send the output to syslog instead.  Cron seems
like the primary blocker, since anything *not* in standard could just
depend on an MTA for now.

For that matter, it seems easy enough to write a very short shell script
which just uses logger (from bsdutils) to log the command-line arguments
and stdin, and install that shell script as sendmail.  Call the whole
thing "mta-syslogger", and use it as the default MTA in standard. :)  I
don't know if doing that makes sense, or if it would make more sense to
just fix programs like cron to also talk to syslog; I'd lean towards the

Either way, I'm happy to address that or any other issues that block
making an MTA optional.

- Josh Triplett

Reply to: