I wish FreeBSD would follow suit. They dropped BIND in favor of Unbound for 10.0-RELEASE, so the precedent is there. Sendmail wouldn't be so bad if it weren't so damned arcane and broken. Like, something as simple as getting TLS to work with older Exchange servers is impossible. Forums are filled with people complaining about this problem for the last ten years. It's so frustrating, especially when the workaround in other mailers is so simple (e.g., Postfix, where one can force TLSv1 in the SMTP client TLS policy map).
I'd be just as happy seeing freebsd drop having an SMTP server in the base system entirely. Having an LDA->SMTP client in base makes sense, but an entire mailserver in the base system?
What percentage of freebsd installs are for dedicated mailservers? If that's even less than 80% (and I presume it's below 1%), having "install it from Ports" being the first step still makes sense.
But then I feel the same way about BIND (and now unbound)
Makes sense, since OpenSMTPd is easier to deploy and MUCH easier to configure + OSMTPd is an OpenBSD software... so If it ever was going to ship pre-installed with an OS that would be definitely OBSD.
Looks very simple, but I don't see things like DKIM/SPF or milters (or some equivalent way to hook in spamassassin, for instance). Am I just missing it, or is it deliberately missing those features?
This can be done by relaying to dkimproxy, and have it relay back on a differet port, tagging the returned (signed) message. Check the list archives for examples.
If you need a simple drop-in sendmail clone for relaying email through Gmail or countless email service providers, don't forget msmtp -- couldn't be easier. Just one file to configure and nothing extra you don't need. Optionally, installing msmtp-mta creates a sendmail alias to msmtp or just ln it yourself. Examples at: https://wiki.archlinux.org/index.php/msmtp (pretty much the same on Ubuntu, etc.)
Sendmail 9 is the worst, most un-Unixlike piece of software.
Want to send UUCP mail? x400 mail? Need other non-SMTP mail support? No, because it's 2014 and most people will never, ever use these? Too bad, the code's installed and running waiting for more exploits.
Want to configure it, in 'human readable plain text' too bad, here's a macro language which no other daemon uses.
Sendmail 9 is rank and the authors know it - Sendmail X (/10) looks far similar to postfix or other modular mail servers than sendmail 9 does.
We still have a UUCP feed from a legacy DOS (!) financial system. Dials us up every day and pumps us data in a message body.
We inherited it during a buy out. It dialled into a SPARCstation 2 originally but that died with a PROM failure (after nearly 18 years of 24/7 service in 2008!). It still had SunOS 4 on it. It was replaced overnight with a hacked up .Net app that receives the message from an old Hayes modem plugged into a USB<>serial adapter from Maplin (bought that evening), parses it terribly naively, translates it to a SOAP message and calls a WCF service on our back end rather than is picked up from a mail spool forwarding.
Think of this story every time you whinge about a REST API problem :)
> Want to send UUCP mail? x400 mail? Need other non-SMTP mail support? No, because it's 2014 and most people will never, ever use these? Too bad, the code's installed and running waiting for more exploits.
Agreed. Fork that into something else if people still need it.
> Want to configure it, in 'human readable plain text' too bad, here's a macro language which no other daemon uses.
Here I disagree. Not that the language isn't bad (though I do still use home-grown m4 in some old Apache configs), but the overall configuration of Sendmail is roughly equivalent to Postfix, Exim, or any other fully featured SMTP server:
1. look at the online manual, reading the descriptions of every single individual config option.
2. copy and paste as appropriate.
Having set up all three of those, I can say that getting a correctly functioning Postfix or Exim takes just as long as getting a correctly functioning Sendmail. All of them have a lot of arcane options.
I'm mainly arguing that the language is bad, so we agree there too.
> The overall configuration of Sendmail is roughly equivalent to Postfix, Exim, or any other fully featured SMTP server...
Default install of Postfix to a working SMTP server: read /etc/postfix/main.cf, uncomment the line which makes postfix listen on all interfaces, restart the service. Way less research, and for more sensible defaults, than sendmail.
> Having set up all three of those, I can say that getting a correctly functioning Postfix or Exim takes just as long as getting a correctly functioning Sendmail. All of them have a lot of arcane options.
You are either a genius at sendmail, or incompetent at Exim and Sendmail.
I keep wondering if some clever person will re-use the UUCP code over Tor to build a simple email system that doesn't traverse the 'regular' channels. Sure SMTP over Tor has this property but UUCP over Tor would let you be much more clever.
I'm blown away by the comment that the Fedora maintainers didn't configure sendmail to deliver into the canonical user mailboxes. On FreeBSD sendmail forwards all mail for local services like cron, daily/weekly/monthly status/security reports, or whatever to root, kind of like logwatch. This built-in monitoring one of my favorite parts of the default install and something I usually have to enable separately on my Linux and Windows servers. Sure, at scale one would dump the relevant logs/reports to a SEIM, but it's still nice to have some kind of basic monitoring built into the O/S.
Unless I'm mistaken, Fedora did what you describe- it configured sendmail to send to user mailboxes in /var/spool/mail. The argument for removing it was that on most installs nobody checks those mailboxes, making it the equivalent of /dev/null with the downside of potentially using all your disk space.
That proposal wasn't just to remove sendmail; it was to install no MTA by default. OpenBSD, on the other hand, has a replacement for sendmail in OpenSMTPd.
I was going to make this same comment as a joke, but if you read his reply to the decision, it's totally accurate. He would totally implement email in systemd if it meant Fedora would boot faster. He just decided that getting rid of email altogether would be even faster than that, and falling short of his campaign to "modernize" the distro, decided he'd find new ways around the body that makes these decisions.
You mean a single-user host? Mainly just reporting critical issues to the user.
Mail is a store-and-forward reliable messaging service that individuals and services can take advantage of. The primary way Ubuntu, RedHat, etc have used it for years is to allow the user to receive notifications of critical incidents in a way that they will see regularly. Things like disk usage reports, hacker attacks, packages upgraded/installed, cron job errors, etc.
The problem is everyone stopped using native e-mail clients years ago and now everyone uses webmail. So nobody ever checks their mailbox to find out the problems going on in their own host.
--
This is different than logging, by the way. Logs are intended to provide an archival record of events that the applications think you might need to know about. They do nothing to report to the user what is going on right now. Ideally you will get both a log and an e-mail when something bad happens, so you can delete the e-mail and keep the log.
This could all be solved by a very thin application that pops up when a new message arrives in the mail spool, highlighted in bold if it came from the local host. The user could be notified of critical issues in real time and have a built-in system to manage the reports (export/forward, sort, search, etc).
As far as it filling up your disk, mail spools don't get rotated, for obvious reasons. The simple compromise would be to either compress or rotate mail spools rather than get rid of them entirely - but that's too sensible a compromise for most :-)
Right now in one server I work on there are 9,961 messages in root's mail spool. You know how many of those message subjects are unique? 10. Do you know what they all have in common? They're all cron jobs that had some minor error that could have been corrected by me the first time I saw it. But I never saw it, because I don't log in as root, and as they pile up i'm less interested in digging through them.
A smart e-mail client could solve duplicate messages and console alerts. Some process optimization on the part of the distros could fix this whole mess. Removing the mail just buries it.
> You mean a single-user host? Mainly just reporting critical issues to the user.
(Yes, I read the rest of your comment :))
This is exactly what syslogs are supposed to do. Logs are just so insanely much simpler to get right as implementation artifacts. The key is no not log to a dozen different files scattered across /var/log, but to do it in a centralized manner (syslog, journal, whatever you want to call it).
It would be trivial (heck, someone's probably alread done it) to just listen for anything reported at "CRITICAL" level to the syslog and report that in a UI. Why on earth would you implement something as complicated as SMTP just to do that?
If you're concerned about monitoring X number of machines, having them send e-mail is decidedly not the way to do it. You'd use something like syslog forwarding (see rfc5424) and central aggregation/metrics.
EDIT: If there were a standard format for "syslog-over-email" then I could at least partially understand, but as it is you're going to get arbitrarily formatted messages from arbitrary programs. Not very useful.
You mentioned about 6 different topics in response to a need for telling a user about critical events on a single host. You might be over-thinking this :) The user just needs a user-friendly reminder that something needs to be addressed. The multiple machine thing is a separate issue.
Just preempting usual comebacks that I tend to see :). I argue too much about technology on the interwebs.
I don't think "a user-friendly reminder" == email these days. It might have been in the days of centralized servers and *NIX mainframes, but it that doesn't work any more.
A daemon is not necessary. You only need a binary called sendmail and a configuration file saying where emails should go (i.e., local files or submitted to some external mail server).
It's not a bad idea to have an (outbound only) daemon for the sake of reliability. If the remote server is down at the moment your "command | mail user@remote" job runs, you want it to queue locally for later delivery so that the mail command can return immediately.
If you're after reliability, the default config is probably not what you want. For the default config though, it may be preferable to keep things simple. Note that a cron setup could still work without an MTA daemon.
You're right, a daemon isn't necessary. It's just an artifact of the design of SMTP. The MTA is designed for both sending and receiving messages over a network. A daemon is the only way to meet all those requirements.
For the single-user host you just need a suid-root MDA that can change users to deliver mail into different spools. The daemon is doing the same thing, except it's an MTA that calls an MDA and it uses IPC. The IPC method is technically superior for many reasons, but as you say, not necessary.
A good part of my early career was built on knowing how to configure Sendmail, so I think do owe an honest thanks. But I haven't touched a sendmail.cf in a long time, and I can't say I miss it.
Because unlike sendmail, CVS hasn't been effectively broken for even one decade, let alone two.
Also, because CVS meshes better with their development philosophy (something about the fact that everything's in one repo, and CVS allows checking out portions of a repo, whereas Git only lets you check out the whole repo).
Just because it isn't as trendy or hip as Git doesn't mean it's automatically broken or obsolete.
I've had an intensive use of CVS for years, followed by an intensive use of SVN for years.
During my CVS years, I never ran into an issue. ever. We can all agree it lacks many useful features but it's also as easy as it can get and it does not corrupt repositories. Calling it "broken" is far from truth.
During my SVN years, I can recall two repository corruptions which no matter how they occurred, just should not have. I think one was related to a bug in the db(3) backend, the other I dunno as I was not in charge of the repository. So... "superior" is debatable.
Nowadays I mostly use Git and CVS, both for different purposes and both making sense in their own purpose. I would not be so affirmative about technologies because you only know so much from your experience and use-cases ;-)
