Date: Thu, 7 Dec 2017 17:19:49 +0100 From: Baptiste Daroussin <bapt@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: arch@freebsd.org, gshapiro@freebsd.org Subject: Re: RFC: Sendmail deprecation ? Message-ID: <20171207161949.sijvvsczlbgbhego@ivaldir.net> In-Reply-To: <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--kt6z523agi5okt63 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 07, 2017 at 08:05:08AM -0800, Rodney W. Grimes wrote: > > Hi all, > >=20 > > I would like to propose the deprecation then removal of sendmail in bas= e. > >=20 > > Deprecation will happen in the form of FreeBSD 12.0 being built WITHOUT= _SENDMAIL > > by default >=20 > Thats not proper by procedure, FreeBSD 12.0 needs to have a binary that > spits out a > "This program is depricated and well be removed in the next release", > that would include all programs that are part of sendmail. Except we are replacing the program with another, not entirely removed it, = so for end users installing freebsd and using it by default the functionnality would be the same. Otherwise, clang intoduction has been violating that rule as well for examp= le >=20 > >=20 > > removal would happen in FreeBSD 13.0 >=20 > if you set WITHOUT_SENDMAIL in 12.- it is removed from 12.0 release, > so if your intent is to "remove" it in 13 you need to change when > you set WITHOUT_SENDMAIL to 13.0 by removal I mean svn rm >=20 > >=20 > > sendmail in base it not really usable as a full featured mta due to the= fact it > > does not support anything an entreprised grade mta setup would require:= ldap > > support for example, check the number of options available in the sendm= ail port. >=20 > I suspect that less than 1% of FreeBSD users are "entreprised(sp) grade" = so the > argument that our users need ldap is just a strawman. The fact that you > use dma(8) to replace it only reinforces that fact. >=20 > It is bad that sendmail has way to many compile time options and that many > of those options need stuff not in base to make work, but that is the sta= te > of software spaghetti. Exactly my arguments and why we do not need a full featured MTA in base, but rather something like dma(8) which fits 99% of the usage of the users. >=20 > > Users for that use case would be better served by the port version of s= endmail. > Again, strawman, that use case is I am fairly sure a very small one. Which is what I'm saying >=20 > >=20 > > The other kind of users are the one using the default setup of sendmail: > > relaying emails externally and deliver locally. > >=20 > > We have dma(8) which is way smaller than sendmail(8) have a configurati= on file > > understandable by most users (yet that is subjecttive) and have the set= uid > > binary capsicumized. > >=20 > > dma(8) has been modified to fix issues reported by clusteradm preventin= g its > > usage in real life situations: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208263 >=20 > That bug is still open???? =20 Have you checked it? it is because I'm waiting for users to validate, I hav= en't closed it until I got the full feedback. >=20 > >=20 > > I think only providing dma(8) by default and let users choose a full fe= atured > > mta via packages is a good solution and better for both sendmail users = and non > > sendmail users. > >=20 > > If noone express a strong opinion by then, I will turn sendmail option = off by > > december 15th. >=20 > Strong opinion expressed, procedure is not being followed by this request, > hence I would say no to this request as worded. > Further more this request appears to be biased on the idea that our users > need ldap in sendmail and I just do not see that as a truth. =20 > And even further more it appears as if the proposed replacement has open > bugzilla reports that proclude it from even simple operation using > .forward files. If that is needed we can implement it > And my final point, the whole sendmail/dma issue goes to /dev/null if we > had pkg base working. So lets stop wasting time talking about culling > little parts of BSD out and get to spending that time on helping get > pkg base done. Said by someone not working on packaging base to someone actually working on packaging base... Bapt --kt6z523agi5okt63 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlopaiUACgkQY4mL3PG3 Plr0sxAA3kPS4Jm3zVrog115HiS4FVdvA562YVsgwOXRpudxG2Z5Dpdhb6BDEO51 uPaBo/f58mukX8GAiFkZmdyrTiZM80vNLQO3mAogGJqjiQQ+KLy0ih15aKvCKZcE QSyH90ruVr21F8J0gU6SUbpINfh0IxG8MziFmWBAjpSR6jkxDqr3D1lpYK950C3o 7S3CyggpNEo+GTPslEfKsB7Ovh/SX5AqYPGsdFylRITvUecmajGEmPdaZE1kPhmN vTNwy6wIHpQ5if1b5fakxTuF3eUm+CgiYDB7p362dgIKDqlsOeu8eB0GRqMTL/HF fQHEoNZov0Fxr7JofrikO4O1diPf4fC+JT2DdEi36lvvQQiSDLsnwNiHZjQUDaCX zlct1WOFP2BXMazEhoAUXgGvsSJt7am9gkndY+7lNUf1JRHWo75cSCPBiMq76MFS qXqehML1wEYIFfEeUcHSjVtkvMbF5jiHzmgv+p5gi++odLtSnkEObvbxE3scjuev ePLjryWSLA+m9mTx4ewK7/2cktByNUTVPj69QgTlEyJDN6+hz7He3iwPAyRadG44 8oxrVk/qXVK5BXx7NEw/pQV43f4vD6s4Ix2AY3A1oLPRxO1yttcL8uWr8JbmK+wi DGnSSdf759fRmTGQ6iUAfoDxBqzqtlZDFh25fqWtgYVugwvGRDg= =t7n8 -----END PGP SIGNATURE----- --kt6z523agi5okt63--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171207161949.sijvvsczlbgbhego>