RFC: Sendmail deprecation ?

[Baptiste Daroussin]

On Thu, Dec 07, 2017 at 08:05:08AM -0800, Rodney W. Grimes wrote:
> > Hi all,
> > 
> > I would like to propose the deprecation then removal of sendmail in base.
> > 
> > Deprecation will happen in the form of FreeBSD 12.0 being built WITHOUT_SENDMAIL
> > by default
> 
> 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 example
> 
> > 
> > removal would happen in FreeBSD 13.0
> 
> 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
> 
> > 
> > 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 sendmail port.
> 
> 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.
> 
> 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 state
> 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.

> 
> > Users for that use case would be better served by the port version of sendmail.
> Again, strawman, that use case is I am fairly sure a very small one.

Which is what I'm saying
> 
> > 
> > The other kind of users are the one using the default setup of sendmail:
> > relaying emails externally and deliver locally.
> > 
> > We have dma(8) which is way smaller than sendmail(8) have a configuration file
> > understandable by most users (yet that is subjecttive) and have the setuid
> > binary capsicumized.
> > 
> > dma(8) has been modified to fix issues reported by clusteradm preventing its
> > usage in real life situations:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263
> 
> That bug is still open????  

Have you checked it? it is because I'm waiting for users to validate, I haven't
closed it until I got the full feedback.
> 
> > 
> > I think only providing dma(8) by default and let users choose a full featured
> > mta via packages is a good solution and better for both sendmail users and non
> > sendmail users.
> > 
> > If noone express a strong opinion by then, I will turn sendmail option off by
> > december 15th.
> 
> 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.  
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20171207/9a7cbbdb/attachment.sig>