RFC: Sendmail deprecation ?

[Baptiste Daroussin]

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

removal would happen in FreeBSD 13.0

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.

Users for that use case would be better served by the port version of sendmail.

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

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.

Best regards,
Bapt

[Jamie Landeg-Jones]

Post by Baptiste Daroussin
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

I use sendmail, but as for reasons you cite, I use sendmail from ports, and
have been building WITHOUT_SENDMAIL for as long as I can remember.

It therefore seems perfectly reasonable to me, for what it's worth.

cheers

[Bjoern A. Zeeb]

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0

I don’t see the point of keeping the source and possible support for
it in base for another 5-ish years if it’s not build by default.
If this should go through then just don’t ship it at all anymore in
12.0-RELEASE please.

/bz

[Cy Schubert]

In message <***@ivaldir.net>, Baptiste
Daroussin wr

--huu3o22uzx2iwrhs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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_SENDM
AIL
by default
removal would happen in FreeBSD 13.0
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 po
rt.
Users for that use case would be better served by the port version of sendmai
l.
relaying emails externally and deliver locally.
We have dma(8) which is way smaller than sendmail(8) have a configuration fil
e
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263
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 no
n
sendmail users.

Deprecate sendmail but no dma please. If anything, a small shell script to
invoke dialog to allow the user to select their MTA package of choice. This
could run at first boot -- which covers bsdinstall users and users who
install from source.

Please no dma.

[Conrad Meyer]

Post by Cy Schubert
Deprecate sendmail but no dma please. If anything, a small shell script to
invoke dialog to allow the user to select their MTA package of choice. This
could run at first boot -- which covers bsdinstall users and users who
install from source.
Please no dma.

Please elaborate beyond "no dma."

Thanks,
Conrad

[Baptiste Daroussin]

Post by Cy Schubert
Daroussin wr

--huu3o22uzx2iwrhs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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_SENDM
AIL
by default
removal would happen in FreeBSD 13.0
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 po
rt.
Users for that use case would be better served by the port version of sendmai
l.
relaying emails externally and deliver locally.
We have dma(8) which is way smaller than sendmail(8) have a configuration fil
e
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263
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 no
n
sendmail users.

Deprecate sendmail but no dma please. If anything, a small shell script to
invoke dialog to allow the user to select their MTA package of choice. This
could run at first boot -- which covers bsdinstall users and users who
install from source.
Please no dma.

Can you elaborate on the no dma?

dma is already there, and meets the needs for most setup, relaying mails or
deliver them locally. mailer.conf will remain meaning people will be able to
chose whatever is their favorite mta.

Best regards,
Bapt

[Cy Schubert]

In message <CAG6CVpVP7F080tVXEWNh9c-PucB-***@mail.gmail.c
om>

Post by Conrad Meyer

Post by Cy Schubert
Deprecate sendmail but no dma please. If anything, a small shell script to
invoke dialog to allow the user to select their MTA package of choice. This
could run at first boot -- which covers bsdinstall users and users who
install from source.
Please no dma.

Please elaborate beyond "no dma."

Replace sendmail with a dialog that installs the user's MTA of choice,
which ports/pkgs has many to choose from. IMO we are replacing one bloat
with other.

At the very least there should be a knob not to build/install dma.

P.S. Not related to this discussion, my choice of MTA BTW is one package
for exterior facing servers and another for internal boxes.

[Pokala, Ravi]

So less "no dma(8)", and more "no default MTA at all; make them select one"?

-Ravi

-----Original Message-----
From: <owner-freebsd-***@freebsd.org> on behalf of Cy Schubert <***@komquats.com>
Reply-To: Cy Schubert <***@komquats.com>
Date: 2017-12-06, Wednesday at 18:22
To: <***@freebsd.org>
Cc: "freebsd-***@freebsd.org" <***@freebsd.org>
Subject: Re: RFC: Sendmail deprecation ?

In message <CAG6CVpVP7F080tVXEWNh9c-PucB-***@mail.gmail.c
om>

Post by Conrad Meyer

Post by Cy Schubert
Deprecate sendmail but no dma please. If anything, a small shell script to
invoke dialog to allow the user to select their MTA package of choice. This
could run at first boot -- which covers bsdinstall users and users who
install from source.
Please no dma.

Please elaborate beyond "no dma."

Replace sendmail with a dialog that installs the user's MTA of choice,
which ports/pkgs has many to choose from. IMO we are replacing one bloat
with other.

At the very least there should be a knob not to build/install dma.

P.S. Not related to this discussion, my choice of MTA BTW is one package
for exterior facing servers and another for internal boxes.
--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Cy Schubert]

In message <B16088FF-FDE1-4EDF-AB76-***@panasas.com>, "Pokala,
Ravi" w

Post by Pokala, Ravi
So less "no dma(8)", and more "no default MTA at all; make them select one"?

Yes.

[Don Lewis]

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.
Users for that use case would be better served by the port version of sendmail.
relaying emails externally and deliver locally.

I've found that sendmail in base meets my needs. I haven't had the need
for any of the features that are only available in the port.

It doesn't looks like dma(8) would be useful for me on my primary
machines since I basically need its inverse. It would only be useful
on my headless machines to forward cron-generated mail to my mail
server. I don't do any local delivery of mail to mbox files. My mail
server delivers all mail to cyrus-imapd via lmtp, which is a fairly
simple tweak to the sendmail.mc file. I also have a couple of mail
relays that do some smart routing and spam filtering.

One thing that is comes with sendmail in base but is missing from the
sendmail port is all the handy stuff in /etc/mail, such as the
freebsd.mc template, the aliases file, and the Makefile which makes
maintaining the config files and the .db files much easier. Without
this stuff, setting up the sendmail port would be much more
intimidating.

[Baptiste Daroussin]

Post by Don Lewis

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.
Users for that use case would be better served by the port version of sendmail.
relaying emails externally and deliver locally.

I've found that sendmail in base meets my needs. I haven't had the need
for any of the features that are only available in the port.
It doesn't looks like dma(8) would be useful for me on my primary
machines since I basically need its inverse. It would only be useful
on my headless machines to forward cron-generated mail to my mail
server. I don't do any local delivery of mail to mbox files. My mail
server delivers all mail to cyrus-imapd via lmtp, which is a fairly
simple tweak to the sendmail.mc file. I also have a couple of mail
relays that do some smart routing and spam filtering.
One thing that is comes with sendmail in base but is missing from the
sendmail port is all the handy stuff in /etc/mail, such as the
freebsd.mc template, the aliases file, and the Makefile which makes
maintaining the config files and the .db files much easier. Without
this stuff, setting up the sendmail port would be much more
intimidating.

Yup, It would be a good idea to merge them in the port probably, somone needs to
talk to the port maintainer.

Best regards,
Bapt

[Julian Elischer]

Post by Don Lewis

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.
Users for that use case would be better served by the port version of sendmail.
relaying emails externally and deliver locally.

I've found that sendmail in base meets my needs. I haven't had the need
for any of the features that are only available in the port.

"me too".
How about you just leave it there until we have pkgbase by default and
then just swap it.
I have enough scripts and configs around that I don't want to revisit
to fix all this.
I hardly remember how they work.. They've been untouched except for
upgrades
for about a decade.

Post by Don Lewis
It doesn't looks like dma(8) would be useful for me on my primary
machines since I basically need its inverse. It would only be useful
on my headless machines to forward cron-generated mail to my mail
server. I don't do any local delivery of mail to mbox files. My mail
server delivers all mail to cyrus-imapd via lmtp, which is a fairly
simple tweak to the sendmail.mc file. I also have a couple of mail
relays that do some smart routing and spam filtering.
One thing that is comes with sendmail in base but is missing from the
sendmail port is all the handy stuff in /etc/mail, such as the
freebsd.mc template, the aliases file, and the Makefile which makes
maintaining the config files and the .db files much easier. Without
this stuff, setting up the sendmail port would be much more
intimidating.

amen
a sendmail-freebsd port maybe?

Post by Don Lewis
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[f***@clogic.com.ua]

Post by Julian Elischer

Post by Don Lewis

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.
Users for that use case would be better served by the port version of sendmail.
relaying emails externally and deliver locally.

I've found that sendmail in base meets my needs. I haven't had the need
for any of the features that are only available in the port.

"me too".
How about you just leave it there until we have pkgbase by default and
then just swap it.
I have enough scripts and configs around that I don't want to revisit
to fix all this.
I hardly remember how they work.. They've been untouched except for
upgrades
for about a decade.

Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

Post by Julian Elischer

Post by Don Lewis
It doesn't looks like dma(8) would be useful for me on my primary
machines since I basically need its inverse. It would only be useful
on my headless machines to forward cron-generated mail to my mail
server. I don't do any local delivery of mail to mbox files. My mail
server delivers all mail to cyrus-imapd via lmtp, which is a fairly
simple tweak to the sendmail.mc file. I also have a couple of mail
relays that do some smart routing and spam filtering.
One thing that is comes with sendmail in base but is missing from the
sendmail port is all the handy stuff in /etc/mail, such as the
freebsd.mc template, the aliases file, and the Makefile which makes
maintaining the config files and the .db files much easier. Without
this stuff, setting up the sendmail port would be much more
intimidating.

amen
a sendmail-freebsd port maybe?

Best regards.

[Jamie Landeg-Jones]

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm afraid
that isn't one of them.

Many things aren't used by "most users" - Most don't use bhyve, for example,
and I bet a high proportion don't even use clang, or many of the other
installed utilities.

As for dma, it's already installed by default - but as most people don't
use it, by your logic, it shouldn't be! :-)

cheers,
jamie

[f***@clogic.com.ua]

Post by Jamie Landeg-Jones

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm afraid
that isn't one of them.

This is counterargument for people who use sendmail from base because
they do this many years before and have configs. And I not only don't
use sendmail, I need disable it any time as install new instance of
FreeBSD. And I am not alone in this.

Post by Jamie Landeg-Jones
Many things aren't used by "most users" - Most don't use bhyve, for example,
and I bet a high proportion don't even use clang, or many of the other
installed utilities.
As for dma, it's already installed by default - but as most people don't
use it, by your logic, it shouldn't be! :-)
cheers,
jamie

There is no suitable bhyve(or clang) alternatives on FreeBSD, so we use
better ones.

1. Sendmail not suitable for modern mail system and not actively
developed anymore.
2. We have modern lightweight alternatives like dma or opensmtpd.
3. FreeBSD is OS for general use, not for mail server systems. If anyone
need fully functional mail server he can install it from ports.

P.S. Sendmail was removed from default install in almost all Linux
distributions and from base system in DragonflyBSD, OpenBSD and NetBSD.

Best regards.

[K. Macy]

Post by Jamie Landeg-Jones

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm afraid
that isn't one of them.

That's not really the question. The question is "why won't 'pkg
install sendmail' work for users that need it?" There are two
technical reasons for why a component is in base and two emotional /
political.

The two technical reasons are:
1) The system won't work without it (e.g. rc files, kill, rm, etc)
2) The component is tightly coupled to the kernel (e.g. bhyve)

There are of course plenty of things which fall in to both buckets:
libc, ifconfig, etc.

The two emotional reasons are:
1) Emotional attachment (e.g. fortune)
2) Inertia (rcs, sendmail, etc)

Thanks to bapt and friends pkg "just works" for most people for most
cases. In conclusion, further discussion needs to either a) make a
compelling case for why either my technical points are insufficient or
the emotional drivers are critical; or b) explain why "pkg install
sendmail" won't work.

Cheers.
-M

[Nathan Whitehorn]

Post by K. Macy

Post by Jamie Landeg-Jones

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm afraid
that isn't one of them.

That's not really the question. The question is "why won't 'pkg
install sendmail' work for users that need it?" There are two
technical reasons for why a component is in base and two emotional /
political.
1) The system won't work without it (e.g. rc files, kill, rm, etc)

As a sub-point, we do want the base system to be a reliable and
consistent set of things such that scripts and instructions can
reference them; one of FreeBSD's strong points is that I can write a
script targeting "FreeBSD" and know that a reasonably complete system is
going to be present and that I won't find out that, say, ping or telnet
are not installed. This expands the set of important tools much beyond
"kill" and "rm" and means we should tread very, very carefully in terms
of moving things out of the base system -- this is one of my major
general reservations about the proposed implemention of pkgbase.

That said, sendmail is *definitely* not in that category so long as some
basic MTA is there that makes reports from periodic etc. work. The
important thing is that mail(1) work, not that it be sendmail. So I'm
100% in favor of dropping sendmail.
-Nathan

Post by K. Macy
2) The component is tightly coupled to the kernel (e.g. bhyve)
libc, ifconfig, etc.
1) Emotional attachment (e.g. fortune)
2) Inertia (rcs, sendmail, etc)
Thanks to bapt and friends pkg "just works" for most people for most
cases. In conclusion, further discussion needs to either a) make a
compelling case for why either my technical points are insufficient or
the emotional drivers are critical; or b) explain why "pkg install
sendmail" won't work.
Cheers.
-M
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[f***@clogic.com.ua]

Post by Nathan Whitehorn

Post by K. Macy

Post by Jamie Landeg-Jones

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always disable
sendmail and install dma for local use or postfix for mail servers. So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm afraid
that isn't one of them.

That's not really the question. The question is "why won't 'pkg
install sendmail' work for users that need it?" There are two
technical reasons for why a component is in base and two emotional /
political.
1) The system won't work without it (e.g. rc files, kill, rm, etc)

As a sub-point, we do want the base system to be a reliable and
consistent set of things such that scripts and instructions can
reference them; one of FreeBSD's strong points is that I can write a
script targeting "FreeBSD" and know that a reasonably complete system
is going to be present and that I won't find out that, say, ping or
telnet are not installed. This expands the set of important tools much
beyond "kill" and "rm" and means we should tread very, very carefully
in terms of moving things out of the base system -- this is one of my
major general reservations about the proposed implemention of pkgbase.
That said, sendmail is *definitely* not in that category so long as
some basic MTA is there that makes reports from periodic etc. work.
The important thing is that mail(1) work, not that it be sendmail. So
I'm 100% in favor of dropping sendmail.
-Nathan

I think the situation is similar to the one that was when bind replaced
with unbound/ldns. A fully featured authoritative DNS server was removed
from the base system and replaced with small and secure DNS resolver.

Post by Nathan Whitehorn

Post by K. Macy
2) The component is tightly coupled to the kernel (e.g. bhyve)
libc, ifconfig, etc.
1) Emotional attachment (e.g. fortune)
2) Inertia (rcs, sendmail, etc)
Thanks to bapt and friends pkg "just works" for most people for most
cases. In conclusion, further discussion needs to either a) make a
compelling case for why either my technical points are insufficient or
the emotional drivers are critical; or b) explain why "pkg install
sendmail" won't work.
Cheers.
-M

[Vitaly Magerya]

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
[...]
If noone express a strong opinion by then, I will turn sendmail option off by
december 15th.

While I mildly welcome the replacement of sendmail with dma in base,
what I really want to thank Baptiste and everyone involved for is the
proper organization of this change: first a clear transition path
(sendmail->dma), then a build knob to test the switch, then an advance
announcement with a period for discussion, then a deprecation in the
next major release, and then a complete removal after one major release.
This is how it should be done. Thanks, Baptiste. It seems that too often
we take this procedure for granted.

[Rodney W. Grimes]

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin
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

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263

That bug is still open????

Post by Baptiste Daroussin
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.

[Baptiste Daroussin]

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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.

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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
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.

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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

Post by Rodney W. Grimes
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

[Warner Losh]

On Thu, Dec 7, 2017 at 9:05 AM, Rodney W. Grimes <

Post by Baptiste Daroussin

Post by Baptiste Daroussin
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

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin

Post by Baptiste Daroussin
sendmail in base it not really usable as a full featured mta due to the

fact it
ldap

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin

Post by Baptiste Daroussin
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.

Post by Baptiste Daroussin

Post by Baptiste Daroussin
relaying emails externally and deliver locally.
We have dma(8) which is way smaller than sendmail(8) have a

configuration file

Post by Baptiste Daroussin
understandable by most users (yet that is subjecttive) and have the

setuid

Post by Baptiste Daroussin
binary capsicumized.
dma(8) has been modified to fix issues reported by clusteradm preventing

its

Post by Baptiste Daroussin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263

That bug is still open????

Post by Baptiste Daroussin
I think only providing dma(8) by default and let users choose a full

featured

Post by Baptiste Daroussin
mta via packages is a good solution and better for both sendmail users

and non

Post by Baptiste Daroussin
sendmail users.
If noone express a strong opinion by then, I will turn sendmail option

off by

Post by Baptiste Daroussin
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

[Xin LI]

Just picking a random message from the thread.

Post by Warner Losh
It's bad that sendmail is such a security nightmare too. We should likely

I don't think there is fact that backs this claim (I don't personally
have strong opinion on Sendmail removal though). Sendmail might well
be a nightmare a decade ago but not anymore.

The last security advisory for sendmail was in 2014 for a CVSS 1.9
issue, and before that the last major issue was in 2010.

Also count me in the "no dma" campaign too: it worked poorly for the
cluster during our dogfood and there were multiple RFC violations the
last time we tried it. I might be wrong, but I think it also does not
support SSL/TLS properly (e.g. no validation of server certificate,
etc.), by the way, and I don't think it have implemented proper queue
either.

Cheers,

[Rich Kulawiec]

Post by Xin LI

Post by Warner Losh
It's bad that sendmail is such a security nightmare too. We should likely

I don't think there is fact that backs this claim (I don't personally
have strong opinion on Sendmail removal though). Sendmail might well
be a nightmare a decade ago but not anymore.

I've been running sendmail since it existed, in all kinds of environments.
(And let me note that I've spent substantial time with the common
open-source alternatives to it as well, so I have a great deal of
direct experience to draw on for comparisons.)

It is most emphatically NOT a security nightmare. It's had its issues,
but no serious ones in years. [1] And over the past decade, it's had a number
of features slowly/carefully added that have gradually hardened it against
attacks and abuse. (greet_pause, for one.) There have also been
similarly-gradual improvements in its configuration: almost nobody
edits .cf files any more. (Instead, they build them from .mc files.
A substantial library of these is supplied and many more are just
an Internet search away.)

We are not at the point where it's a trivial install-configure-run
piece of software. But we are NOT going to be at that point with
sendmail or any other MTA in the forseeable future because not
only are the basic operational requirements of an MTA complex,
the contemporary environment it has to run in is best described
as "constant attacks and abuse interrupted sporadically by actual
real live mail". Anyone who doesn't have at least a modest working
knowledge of all this shouldn't be running an Internet-facing MTA,
whether it's sendmail or postfix or exim or anything else. (It's
fine to run simple instances that forward or are internal-only. That's
a much lower bar to clear in terms of the required knowledge.)

Sendmail is actively supported (by its developers and by the community).
And if you read the release notes that are issued with source updates,
you'll find that they tend to eschew many releases in favor of a few.
That is, they bundle many ports, fixes, updates, features, etc., into
each release. This works out well for two reasons: first, they're
really good at it. Second, it alleviates the need to upgrade production
systems on a frequent basis. So don't be misled by the infrequency
of version updates.

One of the other very handy things about sendmail is that it ships
with a sensible default configuration. This in turn tends to forestall
a lot of bad things that could happen but probably won't. Note that
this configuration isn't optimized or customized: but that's the point.
(Note also, as I recently pointed out to someone, that when you
attempt to optimize your MTA you need to be careful that you're not
also optimizing it for your adversaries.)

My recommendation is to (1) leave sendmail in place (2) track, as much
as possible, the default configuration published by its authors and
(3) consider making it clear at installation time what a smarthost
is and why someone might want to use it. (Briefly, a "smarthost"
is one with an MTA that is fully configured, knows how to deliver
amil across the Internet, etc. Non-smarthosts have a barebones
configuration that renders them unable to do anything other than
(a) accept mail and (b) throw it at the smarthost. This is the
preferred arranagement for a lot of end-user systems, and for many
server environments: if you have N systems, configure N-1 to throw
all the system-generated mail at the smarthost, and then configure
the smarthost to do something useful with it.)

---rsk

[1] Let me also observe that our collective perception of what a
"serious issue" encompasses has shifted over time. Some of the
issues that would have caused an entire IT operation to immediately
shut down are now accepted as routine. And some of the issues that
we once ignored as trivial are now considered show-stoppers. So it's
useful when, let's say, looking at the sendmail bug exploited by
the Morris worm and assessing its severity, to consider the context.

[John Baldwin]

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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.

Post by Rodney W. Grimes

Post by Baptiste Daroussin
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.

Post by Rodney W. Grimes
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.

Post by Rodney W. Grimes
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.

[Kevin Lo]

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.

Hmm, dma(8) says:

dma is not intended as a replacement for real, big MTAs like sendmail(8)
or postfix(1).

I seriously don't think dma(8) is a full featured mta. I would recommend
OpenSMTPD. OpenSMTPD makes smtp easier to implement and manage and more
secure.

Post by Baptiste Daroussin
Users for that use case would be better served by the port version 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263
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.

Why not vice versa?

Post by Baptiste Daroussin
If noone express a strong opinion by then, I will turn sendmail option off by
december 15th.
Best regards,
Bapt

Kevin

[Baptiste Daroussin]

Post by Kevin Lo

Post by Baptiste Daroussin
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
removal would happen in FreeBSD 13.0
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.

dma is not intended as a replacement for real, big MTAs like sendmail(8)
or postfix(1).
I seriously don't think dma(8) is a full featured mta. I would recommend
OpenSMTPD. OpenSMTPD makes smtp easier to implement and manage and more
secure.

It is not and that is the main point of it, what is really required in base it
delivering mails to /var/mail and relay them to a real mail server. when one
needs a full featured mta then he can install opensmtpd, postfix, exim, sendmail
from ports

Best regards,
Bapt

[Rich Kulawiec]

Post by Kevin Lo
I seriously don't think dma(8) is a full featured mta. I would recommend
OpenSMTPD. OpenSMTPD makes smtp easier to implement and manage and more
secure.

There is little evidence supporting these claims. OpenSMTPD is an
interesting experiment and it shows some promise, but it's far from a
professional MTA suitable for deployment in production environments.
(And any claims about its security compared to other MTAs are wildly
premature.) It's also missing quite a few features that are must-haves
for anyone who is serious about running an Internet-facing MTA.

Maybe in 3 or 5 or 10 years it will have those features, and maybe it
will have undergone the kind of rigorous real-world vetting (perhaps
"beating" would be more apropos) that postfix and sendmail and others
have, but it's not there yet. At this time, I can only recommend it
for small (in terms of volume, users, traffic) environments that have
limited defensive requirements and do not require ready integration with
other mail-related software. (Note: I'm using it in one that meets that
description, as a long-running experiment in its side-by-side performance
compared to that of postfix.)

So should it be offered as an alternative? Yes. Should people with very
limited operational requirements consider it? Yes. Should people who
are willing to test it/experiment with it do so? Yes. But until it's
far more thoroughly vetted, it's not suitable to be the default.

---rsk

[Julian Elischer]

Hi all,
I would like to propose the deprecation then removal of the BSD kernel
in base.
Deprecation will happen in the form of FreeBSD 12.0 being built
WITHOUT_KERNEL
by default
removal would happen in FreeBSD 13.0
The kernel in base it not really usable as a full featured OS due to
the fact it
does not support anything an entreprised grade Linux setup would
require: Linux
resource sharing support for example, check the number of options
available in a Linux kernel config.

Users for that use case would be better served by the redhat version
of the kernel.

The other kind of users are the one using the default setup of the OS:
running Posix system calls.

We have Ubuntu for average users with a configuration file
understandable by most users (yet that is subjecttive)

I think only providing a copy of Ubuntu by default and let users
choose a full featured
kernel is a good solution and better for both FreeBSD users and non
FreeBSD users.

If noone express a strong opinion by then, I will turn BSD kernle
option off by
december 15th.

Best regards,
Julian

[Mark Linimon]

Post by Julian Elischer
I would like to propose the deprecation then removal of the BSD kernel
in base. Deprecation will happen in the form of FreeBSD 12.0 being built
WITHOUT_KERNEL by default removal would happen in FreeBSD 13.0

Thank you helping to turn this mailing list into one more thing that
demotivates as well. (ports@ had already achieved that status.)

Merry Christmas and plonk.

mcl

[Rodney W. Grimes]

Post by f***@clogic.com.ua

Post by Nathan Whitehorn

Post by K. Macy

Post by Jamie Landeg-Jones

Post by f***@clogic.com.ua
Most users don't need a sandmail in base. As example, I always
disable
sendmail and install dma for local use or postfix for mail servers.
So I
can't understand, why I need do this every time as I install new
instance of FreeBSD in 2017?

There are many valid arguments for and against removal, but I'm
afraid
that isn't one of them.

That's not really the question. The question is "why won't 'pkg
install sendmail' work for users that need it?" There are two
technical reasons for why a component is in base and two emotional /
political.
1) The system won't work without it (e.g. rc files, kill, rm, etc)

As a sub-point, we do want the base system to be a reliable and
consistent set of things such that scripts and instructions can
reference them; one of FreeBSD's strong points is that I can write a
script targeting "FreeBSD" and know that a reasonably complete system
is going to be present and that I won't find out that, say, ping or
telnet are not installed. This expands the set of important tools much
beyond "kill" and "rm" and means we should tread very, very carefully
in terms of moving things out of the base system -- this is one of my
major general reservations about the proposed implemention of pkgbase.
That said, sendmail is *definitely* not in that category so long as
some basic MTA is there that makes reports from periodic etc. work.
The important thing is that mail(1) work, not that it be sendmail. So
I'm 100% in favor of dropping sendmail.
-Nathan

I think the situation is similar to the one that was when bind replaced
with unbound/ldns. A fully featured authoritative DNS server was removed
from the base system and replaced with small and secure DNS resolver.

It is very different, bind had decided to recode in a new language
which would of required stuff not in base to build it, that made bind
very unattractive. Also no one has made any proof what so ever that
DMA is more secure than sendmail, infact the opposite is actually
more likely simply due to useage exposure.

Post by f***@clogic.com.ua

Post by Nathan Whitehorn

Post by K. Macy
2) The component is tightly coupled to the kernel (e.g. bhyve)
libc, ifconfig, etc.
1) Emotional attachment (e.g. fortune)
2) Inertia (rcs, sendmail, etc)
Thanks to bapt and friends pkg "just works" for most people for most
cases. In conclusion, further discussion needs to either a) make a
compelling case for why either my technical points are insufficient or
the emotional drivers are critical; or b) explain why "pkg install
sendmail" won't work.
Cheers.
-M

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Sean Chittenden]

That's not really the question. The question is "why won't 'pkg install
sendmail' work for users that need it?" There are two technical reasons for
why a component is in base and two emotional / political.

There's also a workflow issue. Receiving feedback from systems via email
messages is quaint (albeit convenient for low numbers of systems). It's only
has value for administrators who have a process setup that lets them consume
this information or use the information as an audit log (??!!??). If someone
has opted into this style of workflow, they're going to drop something off in
sendmail.cf or whatever their MDA config file happens to be.

+1 for deprecating this from base and giving people the choice to `pkg install
sendmail`. For everyone else deploying large numbers of systems, this is
tedious to rip out and yet-another-thing to explain as a requirement when
operationalizing FreeBSD for production workloads.

-sc

[Daniel Eischen]

Post by Sean Chittenden
+1 for deprecating this from base and giving people the choice to `pkg install
sendmail`. For everyone else deploying large numbers of systems, this is
tedious to rip out and yet-another-thing to explain as a requirement when
operationalizing FreeBSD for production workloads.

I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a chance to 'pkg install' or 'pkg remove' sendmail or anything else regardless of whether it is in -base or -ports. The question should be, where do we want to maintain it? (There's also the history that exists in base that gets disconnected when it's in ports.)

-base is a set of packages that we deem more important than ports. Does sendmail, as it is exists and configured in -base, pass muster for being something that we consider important enough to warrant being in base? I think this is more of the question to ask than "why can't they install it from ports?" Consensus seems to indicate no, but that we need some mail delivery agent.

I also think it should be incumbent on whomever removes something from -base to make a port of it. I don't think we should just throw it over the fence and expect the ports team to do the work, unless they volunteer for it.

--
DE

[Conrad Meyer]

Post by Daniel Eischen
I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a chance to 'pkg install' or 'pkg remove' sendmail or anything else regardless of whether it is in -base or -ports.

pkg-base is totally orthogonal to the selection of what components we
want to have in base. Base is really about defaults, and "what makes
a FreeBSD system." There's no reason to block this change on pkgbase,
or vice versa. People can remove the sendmail component on their
system today, but it isn't the default.

Post by Daniel Eischen
The question should be, where do we want to maintain it? (There's also the history that exists in base that gets disconnected when it's in ports.)
-base is a set of packages that we deem more important than ports. Does sendmail, as it is exists and configured in -base, pass muster for being something that we consider important enough to warrant being in base? I think this is more of the question to ask than "why can't they install it from ports?" Consensus seems to indicate no, but that we need some mail delivery agent.
I also think it should be incumbent on whomever removes something from -base to make a port of it.

I disagree with that idea in general. The burden lands on people who
actually want to maintain the component, which may or may not overlap
with the person removing it from base. Removing a component is not
volunteering to maintain a port of that component, and shouldn't be.
(Also, having people who are willing to maintain a component is not by
itself sufficient justification for a component to remain in base.)

Post by Daniel Eischen
I don't think we should just throw it over the fence and expect the ports team to do the work, unless they volunteer for it.

mail/sendmail has been available as a port since 2000.

Best,
Conrad

[Daniel Eischen]

Post by Conrad Meyer

Post by Daniel Eischen
I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a chance to 'pkg install' or 'pkg remove' sendmail or anything else regardless of whether it is in -base or -ports.

pkg-base is totally orthogonal to the selection of what components we
want to have in base.

That's sort of my point, in reverse. Don't use "if you want softwareX, just 'pkg install softwareX'" as a reason to remove softwareX from base.

Post by Conrad Meyer
Base is really about defaults, and "what makes
a FreeBSD system." There's no reason to block this change on pkgbase,
or vice versa. People can remove the sendmail component on their
system today, but it isn't the default.

How do they remove sendmail once it's installed ('rm' is so quaint ;-))?. They can't pkg remove it. And when upgrading from media again, it gets reinstalled? When base is pkg-ized, once it's pkg removed it is never reinstalled when upgrading. It is also easier to turn off the installation defaults with pkg base, so that some software is never installed by default. Sure, when building and installing world it, you have the WITHOUT knobs, but that doesn't help other common installation methods.

Post by Conrad Meyer

Post by Daniel Eischen
The question should be, where do we want to maintain it? (There's also the history that exists in base that gets disconnected when it's in ports.)
-base is a set of packages that we deem more important than ports. Does sendmail, as it is exists and configured in -base, pass muster for being something that we consider important enough to warrant being in base? I think this is more of the question to ask than "why can't they install it from ports?" Consensus seems to indicate no, but that we need some mail delivery agent.
I also think it should be incumbent on whomever removes something from -base to make a port of it.

I disagree with that idea in general. The burden lands on people who
actually want to maintain the component, which may or may not overlap
with the person removing it from base. Removing a component is not
volunteering to maintain a port of that component, and shouldn't be.
(Also, having people who are willing to maintain a component is not by
itself sufficient justification for a component to remain in base.)

Post by Daniel Eischen
I don't think we should just throw it over the fence and expect the ports team to do the work, unless they volunteer for it.

mail/sendmail has been available as a port since 2000.

But that port reportedly doesn't have the FreeBSD configuration files that we have in base. You'd be pushing the burden of maintaining them onto the ports maintainer, making sure they work on all supported branches; they may not want that responsibility.

--
DE

[Don Lewis]

Post by Daniel Eischen

Post by Conrad Meyer
mail/sendmail has been available as a port since 2000.

But that port reportedly doesn't have the FreeBSD configuration files
that we have in base. You'd be pushing the burden of maintaining them
onto the ports maintainer, making sure they work on all supported
branches; they may not want that responsibility.

I haven't played with the port, but it may well be looking for the
existing config files in /etc and not look in ${LOCALBASE}/etc at all.
If that is the case, then if you modify the port to look in
${LOCALBASE}/etc, you'll break things for everybody who currently uses
the port. If you try to limit that problem by having the port look at
${LOCALBASE}/etc only for FreeBSD versions where sendmail is removed
from base, it complicates the port and the transition will still be
messy for anyone who is using the binary packages that we distribute.

[Matthew Seaman]

Post by Don Lewis

Post by Daniel Eischen

Post by Conrad Meyer
mail/sendmail has been available as a port since 2000.

But that port reportedly doesn't have the FreeBSD configuration files
that we have in base. You'd be pushing the burden of maintaining them
onto the ports maintainer, making sure they work on all supported
branches; they may not want that responsibility.

I haven't played with the port, but it may well be looking for the
existing config files in /etc and not look in ${LOCALBASE}/etc at all.
If that is the case, then if you modify the port to look in
${LOCALBASE}/etc, you'll break things for everybody who currently uses
the port. If you try to limit that problem by having the port look at
${LOCALBASE}/etc only for FreeBSD versions where sendmail is removed
from base, it complicates the port and the transition will still be
messy for anyone who is using the binary packages that we distribute.

I don't use sendmail for my principle MTA any more, but I used to run
the ports version of sendmail with the standard FreeBSD sendmail config
bits in /etc/mail and the rc scripts from /etc/rc.d, since those aren't
in the ports version yet.

As I recall, it took about two variables in /etc/rc.conf to make that
setup use the .mc library files installed by the port to build the
sendmail config. To run everything out of ${LOCALBASE}/etc/mail, the
port basically needs to take four files from the base system:
/etc/rc.d/sendmail, /etc/mail/freebsd.mc, /etc/mail/freebsd.submit.mc
and /etc/mail/Makefile. These can be copied into the port with minor
changes, plus possibly with the addition one or two sample database
files. All that can be installed conditionally on FreeBSD versions
where the base sendmail has been removed, something that's quite common
in the ports, and will not add much in the way of complexity to what is
already a very complex port.

All in all, not really an impediment to removing sendmail from base.

Cheers,

Matthew

[Mike Karels]

It is clear that there isn't a consensus on a single choice of MTA,
and that is fine. Here is a summary of my take on current options
after reading the discussion to this point:

First, we seem to agree that the target for a default setup is not
that of an Internet-facing MTA, which requires some thought and
configuration. Instead, the target is an originate-only system
that does either on-box mail delivery or outbound delivery. At the
very least, it can deliver the sysadmin emails configured by default.

The options that have been presented:

o Use dma. That would apparently suffice for some systems, and is already
in base. However, in my opinion, it is missing some capabilities that
some sites (including mine) may require:
- .forward processing
- Its masqerade configuration seems to be too simplistic, e.g.
masquerade all or nothing, rather then exempting root and other
specified system users.
- Some mail clients, e.g. perl packages that we use at $JOB, connect
to localhost:25 (or SMTP on some other host) rather than invoking
"sendmail" directly. dma will not support these.
In addition, it is not as well integrated into the system. It wasn't
immediately obvious to me how to enable it, until I followed the
"See Also" to mailwrapper; I guess I knew that at one time. It also
requires manual configuration of TLS and a certificate if you want to
use TLS.

o Use the sendmail in base, configured for submission only. This is
completely integrated and works out of the box. It has none of the
limitations listed for dma. IIRC, a certificate is generated automatically
so that TLS could work with no additional configuration. Presumably this
could be done for dma as well, but it has not been done.

o Use the sendmail in ports. This is apparently more full-featured, but not
as nicely integrated with FreeBSD. No one has volunteered to resolve this
so far. Or maybe it isn't that hard. But it wouldn't work "out of the
box;" the system woudln't have this MTA available until manually installed.

o Use some other MTA, e.g. OpenSMTPD. Of course there are Postfix, Exim
and probably others, mostly aimed at full-service MTAs. I know little
about these, but they are not pre-configured. (OK, I once configured
an Exim system and got it to do what was required for a test, but I've
blocked it from my mind.)

Another issue that has been brought up:

o It's a bother to remove sendmail to replace it with something else if it
is not a package. I don't understand; isn't it just a matter of putting
sendmail_submit_enable="NO" into /etc/rc.conf to be ready to configure
something else? Or are people so short of disk space that they need to
remove the binary, config files, etc?

It seems to me that the option that is best-integrated, and which serves
the needs of the greatest number of systems, is the sendmail in base. I still
favor a configuration step that selects one of a small number of MTA choices
and configures it, but we don't seem to have a framework for doing that now
if we want something to be working out-of-the box. Thus, I think that
removing sendmail from base now would make the system less flexible and
usable.

Mike

[Mark Linimon]

Post by Mike Karels
It seems to me that the option that is best-integrated, and which serves
the needs of the greatest number of systems, is the sendmail in base.

I will submit the following from one of my boards:

# uname -a
FreeBSD orangepiplus2e 12.0-CURRENT FreeBSD 12.0-CURRENT #10 r326497M: Sun Dec 3 22:14:12 UTC 2017 ***@burner12.lonesome.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
# whereis sendmail
sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail

i.e. we are installing sendmail, by default, on single-board systems
that may have less than or equal to 512M of RAM.

I think this is silly.

mcl

[Don Lewis]

Post by Mark Linimon

Post by Mike Karels
It seems to me that the option that is best-integrated, and which serves
the needs of the greatest number of systems, is the sendmail in base.

# uname -a
# whereis sendmail
sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail
i.e. we are installing sendmail, by default, on single-board systems
that may have less than or equal to 512M of RAM.
I think this is silly.

Not really silly. This machine runs sendmail as one of its primary
jobs:

FreeBSD 11.1-STABLE #0 r325913: Fri Nov 17 04:13:36 UTC 2017
***@mousie.catspoiler.org:/usr/obj/i386.i386/usr/src/sys/GW i386
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn)
VT(vga): resolution 640x480
CPU: VIA Nehemiah (1000.06-MHz 686-class CPU)
Origin="CentaurHauls" Id=0x698 Family=0x6 Model=0x9 Stepping=8
Features=0x381b93f<FPU,VME,DE,PSE,TSC,MSR,CX8,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE>
VIA Padlock Features=0xdd<RNG,AES>
real memory = 268435456 (256 MB)
avail memory = 245055488 (233 MB)


I used to run a corporate mail relay with sendmail on a Pentium machine
with 128 MB of RAM.

[Mark Linimon]

Post by Don Lewis
Not really silly.

It's silly to be in the default install on an arm board IMHO.

mcl

[Bruce Evans]

Post by Don Lewis

Post by Mark Linimon

Post by Mike Karels
It seems to me that the option that is best-integrated, and which serves
the needs of the greatest number of systems, is the sendmail in base.

# uname -a
# whereis sendmail
sendmail: /usr/sbin/sendmail /usr/share/man/man8/sendmail.8.gz /usr/ports/mail/sendmail
i.e. we are installing sendmail, by default, on single-board systems
that may have less than or equal to 512M of RAM.
I think this is silly.

Not really silly. This machine runs sendmail as one of its primary
...
real memory = 268435456 (256 MB)
avail memory = 245055488 (233 MB)
I used to run a corporate mail relay with sendmail on a Pentium machine
with 128 MB of RAM.

512 MB is enormous. 128 MB is also large. Sendmail just worked for light
use on a 486 with 16 MB. An i386 with 8 MB was more challenging. I only had
32 MB on a Pentium-1 machine. 32 MB still needed swapping, but I turned off
swapping when 64 MB RAM became affordable (and used). The 32MB system ran
netscape will no obvious problem except that it needed swapping for not much
more than netscape.

Bruce

[Julian Elischer]

Post by Mike Karels
It is clear that there isn't a consensus on a single choice of MTA,
and that is fine. Here is a summary of my take on current options
First, we seem to agree that the target for a default setup is not
that of an Internet-facing MTA, which requires some thought and
configuration. Instead, the target is an originate-only system
that does either on-box mail delivery or outbound delivery. At the
very least, it can deliver the sysadmin emails configured by default.
o Use dma. That would apparently suffice for some systems, and is already
in base. However, in my opinion, it is missing some capabilities that
- .forward processing
- Its masqerade configuration seems to be too simplistic, e.g.
masquerade all or nothing, rather then exempting root and other
specified system users.
- Some mail clients, e.g. perl packages that we use at $JOB, connect
to localhost:25 (or SMTP on some other host) rather than invoking
"sendmail" directly. dma will not support these.
In addition, it is not as well integrated into the system. It wasn't
immediately obvious to me how to enable it, until I followed the
"See Also" to mailwrapper; I guess I knew that at one time. It also
requires manual configuration of TLS and a certificate if you want to
use TLS.
o Use the sendmail in base, configured for submission only. This is
completely integrated and works out of the box. It has none of the
limitations listed for dma. IIRC, a certificate is generated automatically
so that TLS could work with no additional configuration. Presumably this
could be done for dma as well, but it has not been done.
o Use the sendmail in ports. This is apparently more full-featured, but not
as nicely integrated with FreeBSD. No one has volunteered to resolve this
so far. Or maybe it isn't that hard. But it wouldn't work "out of the
box;" the system woudln't have this MTA available until manually installed.
o Use some other MTA, e.g. OpenSMTPD. Of course there are Postfix, Exim
and probably others, mostly aimed at full-service MTAs. I know little
about these, but they are not pre-configured. (OK, I once configured
an Exim system and got it to do what was required for a test, but I've
blocked it from my mind.)
o It's a bother to remove sendmail to replace it with something else if it
is not a package. I don't understand; isn't it just a matter of putting
sendmail_submit_enable="NO" into /etc/rc.conf to be ready to configure
something else? Or are people so short of disk space that they need to
remove the binary, config files, etc?
It seems to me that the option that is best-integrated, and which serves
the needs of the greatest number of systems, is the sendmail in base. I still
favor a configuration step that selects one of a small number of MTA choices
and configures it, but we don't seem to have a framework for doing that now
if we want something to be working out-of-the box. Thus, I think that
removing sendmail from base now would make the system less flexible and
usable.

This is close to my thinking..
I see no real reason to remove it..
the binary isn't exactly huge by today's standards..
-r-xr-sr-x  1 root  smmsp  696880 Aug 24 03:56 sendmail
[***@porridge ~/p4/build_inv_10x]$ ls -l `which vim`
-rwxr-xr-x  1 root  wheel  2389560 Aug 11 21:23 /usr/local/bin/vim
[***@porridge ~/p4/build_inv_10x]$ ls -l /lib/libc.so.7
-r--r--r--  1 root  wheel  1654264 Aug 24 03:54 /lib/libc.so.7

Currently  it is the most integrated and I've found it reliable.
if it has SSL built in by default we'd be golden.

Post by Mike Karels
Mike
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Mike Karels]

Post by Mark Linimon

Post by Don Lewis
Not really silly.

It's silly to be in the default install on an arm board IMHO.
mcl

Presumably dealing with this issue is one of the goals of turning base
into packages, and hopefully there can be different defaults for
different architectures or profiles. Removing just sendmail won't get
you much space back (especially if you just remove /usr/sbin/sendmail,
which is just a symlink to mailwrapper). A small arm board is more
likely to be single-purpose, but it's hard to guess what that purpose
might be. I certainly wouldn't rule out the possibility of such a board
originating mail, though.

Mike

[Ben Woods]

Post by Mike Karels

Post by Mark Linimon

Post by Don Lewis
Not really silly.

It's silly to be in the default install on an arm board IMHO.
mcl

Presumably dealing with this issue is one of the goals of turning base
into packages, and hopefully there can be different defaults for
different architectures or profiles.

I personally think that pkgbase doesn’t answer 2 questions:
1. What mail agent(s) do FreeBSD developers want to maintain the source for
in the base tree?
2. What mail agent do we want installed and running on FreeBSD systems by
default (without having answered any questions or made any changes... e.g.
quickly provisioning 100 jails with a stock install).

Sure people can remove packages, but to me that shouldn’t get in the way of
making changes to match the general consensus answer to these 2 questions
(whatever that may be).

My vote is for dma, because it is small and simple. If a few features need
to be added to dma to make it work for more people, suggest they should be
added first (with the status of the necessary steps to progress towards
removing sendmail being tracked on a wiki page).

I think I am seeing the majority of people are for this, but there are a
number of the people in the community and developers who are not. If there
is not a clear consensus, perhaps this should be submitted as a FreeBSD
Community Proposal (FCP).

https://github.com/freebsd/fcp

Regards,
Ben

Post by Mike Karels
--

--
From: Benjamin Woods
***@gmail.com

[Cy Schubert]

Post by Mike Karels

Post by Mark Linimon

Post by Don Lewis
Not really silly.

It's silly to be in the default install on an arm board IMHO.
mcl

Presumably dealing with this issue is one of the goals of turning base
into packages, and hopefully there can be different defaults for
different architectures or profiles. Removing just sendmail won't get
you much space back (especially if you just remove /usr/sbin/sendmail,
which is just a symlink to mailwrapper). A small arm board is more
likely to be single-purpose, but it's hard to guess what that purpose
might be. I certainly wouldn't rule out the possibility of such a board
originating mail, though.

Especially with meta-packages for desktop, mail server, FAMP (FreeBSD,
Apache, MySQL, PHP), network infrastructure, and other general server, or
whatever else. What comes to mind are RPM groupings Red Hat has.

At $JOB we use HPSA. Packaged base would allow us to play better in this
space too.

[Roger Marquis]

Post by Mike Karels
Use dma. That would apparently suffice for some systems, and is already
in base. However, in my opinion, it is missing some capabilities ...
it is not as well integrated into the system. It wasn't
immediately obvious to me how to enable it, until I followed the
"See Also" to mailwrapper

DMA has the best KIS, however, as you note it lacks key feature/s. IMO,
it should be moved to ports. Mailwrapper should be moved as well
(following the example of javavmwrapper). We've had so many issues with
mailwrapper that it now is deleted on install, as well as **/etc/mail.

Post by Mike Karels
Use the sendmail in ports.

When even sendmail's author recommends against it?

Post by Mike Karels
Use some other MTA

Until Postfix has a BSD-compatible license my vote goes to OpenSMTPD
configured not to listen to port 25 (for KIS and to keep it from being
shared with jail localhosts).

Roger

[Cy Schubert]

In message <CAG6CVpU3qe10UUY6B-***@mail.gma
il.com>

On the Linux xfs development list there is an RFC to remove IRIX,
Darwin, and FreeBSD support from xfsprogs, the userspace program used
to create/interact with XFS filesystems. Just wanted to poke and check
to ensure that FreeBSD is not interested in XFS, if this is incorrect
now would be the good time to chime into the list and discussion.

redhat.com
Hi Luis,
FreeBSD 11+ can mount XFS filesystems read and write via a FUSE port
incorporating LKL[0] (sysutils/fusefs-lkl). I would appreciate
xfsprogs retaining FreeBSD support at least for creating or modifying
offline XFS filesystems, if it isn't too painful for you.

fusefs-lkl is flagged broken as of r465272.

[Conrad Meyer]

Yeah, someone broke the build recently via a base toolchain change or
a ports framework/compiler change. I don't think that changes
anything.

Post by Cy Schubert
il.com>

On the Linux xfs development list there is an RFC to remove IRIX,
Darwin, and FreeBSD support from xfsprogs, the userspace program used
to create/interact with XFS filesystems. Just wanted to poke and check
to ensure that FreeBSD is not interested in XFS, if this is incorrect
now would be the good time to chime into the list and discussion.

redhat.com
Hi Luis,
FreeBSD 11+ can mount XFS filesystems read and write via a FUSE port
incorporating LKL[0] (sysutils/fusefs-lkl). I would appreciate
xfsprogs retaining FreeBSD support at least for creating or modifying
offline XFS filesystems, if it isn't too painful for you.

fusefs-lkl is flagged broken as of r465272.
--
Cheers,
The need of the many outweighs the greed of the few.

[Darrick J. Wong]

[cc the xfsprogs maintainer]
[cc xfs list]

Post by Conrad Meyer
Yeah, someone broke the build recently via a base toolchain change or
a ports framework/compiler change. I don't think that changes
anything.

Post by Cy Schubert
il.com>

On the Linux xfs development list there is an RFC to remove IRIX,
Darwin, and FreeBSD support from xfsprogs, the userspace program used
to create/interact with XFS filesystems. Just wanted to poke and check
to ensure that FreeBSD is not interested in XFS, if this is incorrect
now would be the good time to chime into the list and discussion.

redhat.com
Hi Luis,
FreeBSD 11+ can mount XFS filesystems read and write via a FUSE port
incorporating LKL[0] (sysutils/fusefs-lkl). I would appreciate

Yikes. I'm curious, how many people use fusefs-lkl?

Eric will have more to say about this, but is your xfsprogs port still
on 3.2.4 because ./configure can't find libblkid?

--D

Post by Conrad Meyer

Post by Cy Schubert

xfsprogs retaining FreeBSD support at least for creating or modifying
offline XFS filesystems, if it isn't too painful for you.

fusefs-lkl is flagged broken as of r465272.
--
Cheers,
The need of the many outweighs the greed of the few.

[Eric Sandeen]

Post by Darrick J. Wong
[cc the xfsprogs maintainer]
[cc xfs list]

Yes, thanks.

Post by Darrick J. Wong

Post by Conrad Meyer
Yeah, someone broke the build recently via a base toolchain change or
a ports framework/compiler change. I don't think that changes
anything.

Post by Cy Schubert
il.com>

On the Linux xfs development list there is an RFC to remove IRIX,
Darwin, and FreeBSD support from xfsprogs, the userspace program used
to create/interact with XFS filesystems. Just wanted to poke and check
to ensure that FreeBSD is not interested in XFS, if this is incorrect
now would be the good time to chime into the list and discussion.

redhat.com
Hi Luis,
FreeBSD 11+ can mount XFS filesystems read and write via a FUSE port
incorporating LKL[0] (sysutils/fusefs-lkl). I would appreciate

Yikes. I'm curious, how many people use fusefs-lkl?
Eric will have more to say about this, but is your xfsprogs port still
on 3.2.4 because ./configure can't find libblkid?

So: At this point, it seems like if you're still on a 4 year old xfsprogs
release with custom patches due to build problems we've never heard about,
there doesn't seem to be a very strong effort to keep XFS on FreeBSD thriving.

And, given that you're stuck on 3.2.4, removing support from 4.16.0 won't
change your situation anyway.

Are people using this? Is anyone dedicated to maintaining it, or is it
just kind of floating along at this point?

I'd rather not keep non-building freebsd code around just in case; I'd like
to either see someone take ownership to get freebsd properly building upstream,
or just drop it and let FreeBSD keep patching on the side as you've been doing
for a few years anyway.

Thoughts?

Thanks,
-Eric

[Dave Chinner]

Post by Eric Sandeen

Post by Darrick J. Wong
[cc the xfsprogs maintainer]
[cc xfs list]

Yes, thanks.

Post by Darrick J. Wong

Post by Conrad Meyer
Yeah, someone broke the build recently via a base toolchain change or
a ports framework/compiler change. I don't think that changes
anything.

Post by Cy Schubert
il.com>

On the Linux xfs development list there is an RFC to remove IRIX,
Darwin, and FreeBSD support from xfsprogs, the userspace program used
to create/interact with XFS filesystems. Just wanted to poke and check
to ensure that FreeBSD is not interested in XFS, if this is incorrect
now would be the good time to chime into the list and discussion.

redhat.com
Hi Luis,
FreeBSD 11+ can mount XFS filesystems read and write via a FUSE port
incorporating LKL[0] (sysutils/fusefs-lkl). I would appreciate

Yikes. I'm curious, how many people use fusefs-lkl?
Eric will have more to say about this, but is your xfsprogs port still
on 3.2.4 because ./configure can't find libblkid?

So: At this point, it seems like if you're still on a 4 year old xfsprogs
release with custom patches due to build problems we've never heard about,
there doesn't seem to be a very strong effort to keep XFS on FreeBSD thriving.
And, given that you're stuck on 3.2.4, removing support from 4.16.0 won't
change your situation anyway.
Are people using this? Is anyone dedicated to maintaining it, or is it
just kind of floating along at this point?
I'd rather not keep non-building freebsd code around just in case; I'd like
to either see someone take ownership to get freebsd properly building upstream,
or just drop it and let FreeBSD keep patching on the side as you've been doing
for a few years anyway.
Thoughts?

We don't support fuse-lkl XFS filesystems on Linux, so I'm not sure
that using it on some other platform compels us to maintain a
current userspace tool port to those platforms...

Cheers,

Dave.

[Christoph Hellwig]

Post by Dave Chinner
We don't support fuse-lkl XFS filesystems on Linux, so I'm not sure
that using it on some other platform compels us to maintain a
current userspace tool port to those platforms...

IFF we have someone signing up to maintain the FreeBSD port it seems
like a whortwhile exercise. But that is a big IFF.

For now I'd say give it a grace period of another release or two to
see if someone is going to maintain it properly and if not drop it.

[Eric Sandeen]

Post by Christoph Hellwig

Post by Dave Chinner
We don't support fuse-lkl XFS filesystems on Linux, so I'm not sure
that using it on some other platform compels us to maintain a
current userspace tool port to those platforms...

IFF we have someone signing up to maintain the FreeBSD port it seems
like a whortwhile exercise. But that is a big IFF.
For now I'd say give it a grace period of another release or two to
see if someone is going to maintain it properly and if not drop it.

Just to keep it on this thread - I'm going to commit this to 4.16:

+#warning "FreeBSD support is deprecated and planned for removal in July 2018"
+#warning "Contact linux-***@vger.kernel.org if you'd like to maintain this port"
+#error "Remove this line if you'd like to continue the build"

for to FreeBSD & the other platforms we're talking about deprecating.

That should get the attention of anyone who cares, I think. If someone wants
to step up and maintain it, let us know on the list.

Thanks,
-Eric