DragonFly kernel List (threaded) for 2003-09
Re: Anybody working on removing sendmail from base?
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 24 September 2003 10:27 pm, Timothy Cava wrote:
> (Let's not bikeshed.)
> Anybody working on this in their repository? I'm willing to try, myself,
> but I'd like to know whether Matt would accept it, and what's really
> necessary. I suppose I could check the mailing lists, but I had trouble
> finding useful information last time. It was mostly flamage. I'm
> basically just a user/sysadmin/c programmer, not a FreeBSD/DragonFlyBSD
> internals expert, so...
> * /etc/rc.mail, or an equivalent
> * /etc/rc.conf glue
> Or is sendmail_enable=NO mta_start_script="..."
> already good enough?
with an rc.mail, sendmail_enable=NO should be enough.
if you use mta_start_script=, you wouldn't need an rc.mail.
Nor sure how it fits in with the RCng stuff, but I would prefer to have an
rc.mail, and put a mailer= line in rc.conf. That way the "glue" is all in
rc.mail, and simple for someone to go in and look at the various options and
> * /etc/defaults/rc.conf defaults
> Do we break clean and provide a small mailer for
> localnet mail? Or just default to sendmail,
> which kind of defeats the purpose, but there is
> POLA. I suppose we could have NO_SENDMAIL
> mean more, like don't use it for defaults (we
> don't have the binaries, whatever)
> * Other things:
> make release? I don't know the build system in
> What else? I must be missing things, otherwise
> I feel like this would have been done by -somebody-
> out there.
<pardon me, I'm just brainstorming here, trying to get some ideas out for
If there is serious discussion about removal of other parts (ie, perl) from
the "base" system (a philosphy I basically agree with, but will prove
difficult to implement), then certainly sendmail fits in. For this to work
correctly, we have to be able to specify some things, though. In FBSD, perl
is a necessary part of system builds (that's why its part of the base
system). This also entails some problems for ports and the like that work
with older versions of perl (or gcc, for that matter) but break with new
versions, although it greatly simplifies things that need the newer versions.
(doesn't gcc fit into this category as well? I know that's a whole other can
o' worms, but at least *part* of the idea behind removing such things from
the base is to make it easier to upgrade, right?
Likewise, sendmail, although not strictly necessary, there really needs to be
a SOME mta on the system as part of the base package, even if it is a "dumb"
interface that can only handle local traffic, unless there is a way to
redirect "local" smtp traffic to an off-host server? Most modern mail
clients don't have to read mail locally, and even those that do, there are
programs such as fetchmail that can handle incoming mail; a similar mechanism
could be implemented for outgoing mail, someting like an SMTP echo server
that bounces any smtp request to some configured host...*that* host, of
course would need to be properly set up to handle incoming mail for your
users, but for a "simple" solution to the need for a mail transport, it might
be workable. It would seriously screw up mail to "root" of course, but if we
change "mail" to "log" in /etc/periodic (as suggested elsewhere) that becomes
To attempt to make this less bikesheddy(tm), I am willing to experiment/help
test/whatever. My programming skills aren't that great, but as long as I
have a system that runs, I can take some time and play with things. I don't
actually USE any mta in my configuration, except where required, and just
have sendmail becuase it happens to be there, and not require an additional
configuration on my part, and you can't have a unix-like system with an mta,
right? If we can get something similar for other mailers, I'm all for it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----