Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Wed, 17 May 2006, Goswin von Brederlow wrote:
> You mean connection from random user ports to destination port 25?
Yes.
> If you are at a place where that is the case then you should have an
> IT team or admin that will tell you what smtp host to use or even
> install your system.
We do. So does every user in a proper ISP (not all of them block outgoing
port 25, but many do these days. And all of them tell you which smtp server
to use), and corporate network.
It is still not a good default (as in "safe if the user doesn't know it is
there or what it does"), which is the whole point.
> > Sometimes I feel we are abandoning the true spirit of an Unix system. If
> > Debian made sure to always have a local MTA that is properly configured to
> > send email (and it can be a simple SMTP with no queue thing, too. It can
> > work just as well and can be as safe as a full-blown MTA, the drawback is
> > that the user has to wait for the email to be delivered to a queueing MTA
> > before the sendmail command returns), everything could be made to just work.
>
> And how would that be any simpler than setting an smtp server for
> reportbug? Setting up a fully usable MTA is more difficult than having
> reportbug connect directly to bugs.d.o.
You do it only *once* for the entire system. I am quite amused I even have
to answer such a question.
> > What exactly is the problem with making a local MTA absolutely mandatory,
> > (as in anything that sends email either recommends or depends on
> > mail-transport-agent)?
> >
> > Of course, at the same time we would have to make sure stuff like nbsmtp,
> > nullmailer, esmtp-run or ssmtp is trivially easy to install, and point our
> > users to those packages so that they know the possiblity exists. IMHO we
> > really ought to leverage d-i to bluntly ask the user if he wants a
> > full-blown MTA or just a SMTP relay (obviously by using easier terms, like a
> > "Advanced outgoing mail service" (i.e. exim) task, which if not selected,
> > gives you nullmailer or somesuch.
>
> That would mean another service on the system that might get
> compromised or misused. I'm perfectly fine with having mail only
Well, a MSA (mail sending agent, a proper name for a queue-less MTA IMHO)
never listens to anything or needs any other priviledge apart from "open a
inet socket to a remote machine": it just connects to somewhere over SMTP
and delivers its standard input to the SMTP server on the other side. It is
not a daemon, or anything like that. It is as vulnerable to compromise as
perl's smtp client code is.
As for misused, well, the real question is how easy is to misuse such a
thing by accident.
> delivered internaly or not at all for my chroots but I still want to
> be able to report bugs with the right dependency informations. If you
> force the use of an MTA then I would have to save the bug reports to a
> file and mail them manualy from outside the chroot every time I get a
> bug. Much less usable.
Override the default to use SMTP directly, then. Are you seriously
advocating your "chroot with a mail-less setup" as a good reason to define
the *default* method of mail delivery for the distro? That ain't a common
user case, you know.
It is *not* much less usable, at all. We are talking about the *default*
behaviour.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: