Evidently by making it necessary to learn yet another _script_ing language to configure it.  Other than personal profit I cannot see why people are clinging like grim death to something this fubar.  Really, let's go past this one more time: Sure, sendmail.cf is hard to work with so the solution is you learn m4! Did you look at the _link_ he offered?  How helpful is that? Beside which, m4 is a PORT.  So if sendmail is not configurable without a port, why isn't it a port? Can we go back to our regular hacking, please?  m4 is not a port:  $ which m4  /usr/bin/m4 I wonder how that happened, Too much alcohol? Really? See /usr/src/usr.bin/m4/Makefile

Evidently by making it necessary to learn yet another _script_ing language to configure it.  Other than personal profit I cannot see why people are clinging like grim death to something this fubar. Really, let's go past this one more time: Sure, sendmail.cf is hard to work with so the solution is you learn m4! Did you look at the _link_ he offered?  How helpful is that? Beside which, m4 is a PORT.  So if sendmail is not configurable without a port, why isn't it a port? Can we go back to our regular hacking, please?  m4 is not a port:  $ which m4  /usr/bin/m4 Evidently my package data_base_ is corrupt in some way, because it shows m4 as an installed port.  I wonder how that happened, how to fix it, and if it will bite if I leave it alone. Some ports need the GNU version of `m4'.  So they install a second copy of m4 in `/usr/local'.  You should be able to see the ports that depend on GNU m4 with pkg_info.  On my system this shows: : $ pkg_info -R m4* : Information for m4-1.4.13,1: : : Required by: : automake-1.5_5,1 : automake-1.6.3_1 : automake-1.9.6_3 : bison-2.4.1,1 : autoconf-2.62 : automake-1.10.1

Saying that, it would be neat if it was taken out of _base_ and replaced with something minimal that could cope with the demands of cron and not much else. Then the user is expected to install a MTA of their choice out of ports. That would mean less code in _base_ and fewer security advisories. OpenSMTPD looks promising.  If it turns out to be as nice as it seems it will, I wouldn't be opposed to making it part of _base_ instead of Sendmail, but of course it's entirely possible that I've overlooked some potential problems.  The licensing is right, too (unlike, perhaps, that of Postfix).

////jerry Best Regards Gonzalo Nemmi

////jerry Best Regards Gonzalo Nemmi Regards,

FreeBSD: ? I can't think of a good reason why FreeBSD should get rid of it. Saying that, it would be neat if it was taken out of _base_ and replaced with something minimal that could cope with the demands of cron and not much else. Then the user is expected to install a MTA of their choice out of ports. That would mean less code in _base_ and fewer security advisories. yea i like where you are going with this frank - perhaps when opensmtpd is done we'll be in the position to import this into the freebsd tree?  it sounds like it might fit the bill But, do we actually need an MTA in the _base_? The only arguments I have seen in this thread are: - because it's been there since the beginning of history - because cron requires it to send the daily reports For the first, that may be so, but what was a good idea at the beginning of history may not be so today. The argument is invalid. For the benefit of the project, it should continuously be considered if legacy code can be removed and offered as an optional component for those relying on it. For the second, honestly: If cron is the only application that requires an MTA then maybe it should be considered if that is a good solution. I think it is a very heavy requirement for what is otherwise very simple. If you deploy a SOHO network with FBSD at home, you may not use your own mailservice but depend on some other service. Then you likely don't read local mail regularly and it suffices for you to keep the output of cron in a plain text file in /var/log. Or you may have cron send mails to your mailservice. In either case, there is no need for an MTA like sendmail, you only need a simple client. If you deploy FBSD in larger networks, then you may opt for some other MTA. Let's face it, sendmail isn't exactly easy to setup for advanced features. And, you don't need an MTA on all systems, only on the mail gateway, other systems just need a mail client for cron - if you don't use some more advanced monitoring system, having a dedicated syslog server for example. It appears to me that having an MTA in _base_ is obsolete. A simple client would do if anything at all. Further, if keeping an MTA costs resources in patching and testing for every new release, then it goes from being a remnant from history to slow down progress for the project. BR, Erik