Re: Anybody working on removing sendmail from base?

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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...
>
> Needed:
> 	* /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 
choose one.

> 	* /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
> 		detail.
> 		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 
discussion>
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 
less significant...


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.

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/cpmsY30jZzkECLcRAgtCAJ4rtlexyk65efQo4CZs1qcR9KD15wCfTBCe
xrJhbWGB4HmnhhJw+92YwWY=
=cH85
-----END PGP SIGNATURE-----