RFC: Sendmail deprecation ?

Warner Losh imp at bsdimp.com
Thu Dec 7 16:49:33 UTC 2017


On Thu, Dec 7, 2017 at 9:05 AM, Rodney W. Grimes <
freebsd-rwg at pdx.rh.cn85.dnsmgr.net> 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.
>

OK. We've never actually implemented this policy in the past. You keep
saying it's the policy, but can you point to any program we've ever done
this with? Ever? And for sendmail this is especially stupid because it runs
hundreds or thousands of times a day on any given server with its output
directed no place useful. This is a stupid thing to ask.


> >
> > 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


It's still buildable. And this is saying, effectively, with our long
release cycles we can't deorbit anything in less than 5 years, which is
also insane. That's a stupid policy and one that will, in reality, be
ignored and you'll send angry emails about rather than one that would be
helpful to our project or our users. It's also something project has never
ever been able to achieve in the past. To this day, we're not printing a
warning that gcc is deprecated on every invocation (which would be F****ing
stupid), and we absolutely are going to remove it before 12.


> > 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.


It's bad that sendmail is such a security nightmare too. We should likely
have turned it off years ago, so I applaud this move.


>
> > 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.


Actually, they likely would... Better to have a small, secure, simple
mailer in the base, and those with enterprise needs install the sendmail
port. This would be a better state than the current state of affairs that
expose more users to sendmail's security holes. So, yes, our users would be
better off with sendmail as a port. Not really a strawman at all since part
of the argument is that all users are better off w/o sendmail, or with
sendmail as a port.


> > 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????
>
> >
> > 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.
> 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.


Except it doesn't go to /dev/null. We have a higher security officer burden
with it in the base than as a port-based package.

Warner


More information about the freebsd-arch mailing list