RFC: Sendmail deprecation ?

[John Baldwin]

On 12/7/17 11:05 AM, 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.

It would be sufficient to emit a warning from rc.sendmail during boot if sendmail
is enabled.  It is not required that /usr/bin/sendmail issue a warning, just
that "use of the feature".  Also, the deprecation policy are guidelines, not hard
rules.  For some programs it would break the program's functionality to alter a
program's output.

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

Pragmatically, we aren't going to maintain sendmail in base for another 10 years.
We can also merge the deprecation notices to 11 which will then ship in releases
for a year before 12.0 is released.

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

Actually, the point is most FreeBSD users don't need an actual mail server, just
mail forwarding for which dma(8) is fine.  It is very analagous to unbound vs
bind.

> Strong opinion expressed, procedure is not being followed by this request,
> hence I would say no to this request as worded.

I think this is open to interpretation.  Your interpretation in general seems to
be tighter than the view of most other developers (including those who drafted
the existing policy).  In part, the wording in the committer's guide is actually
rather old and dates from a time when we as a Project did not have as much
experience with removing things that are stale and no longer maintained (at least
in base.  ports has a more-regularly-enforced policy).  The policy in the
committer's guide should probably be revisisted and possibly adjusted.

-- 
John Baldwin