Sendmail removed from OpenBSD base
undeadly.org
undeadly.org
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)
If you want/need a full mail server, you get your pick from ports.
-crosses fingers-
Which is exactly what I already do. This is good news as far as I'm concerned.
we have recently finished an API for implementing filters and we're working on stabilizing the interface before making it public.
https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
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.
(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.
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.
about alerting, I use the simple (and old but has all you need) logsentry also sometimes called logcheck.
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.
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.
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.
You are either a genius at sendmail, or incompetent at Exim and Sendmail.
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.
Super, so I can finally replace Postfix with something which is like postfix, but not quite, and hasn't been as proven in the field.
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 :)
So you'd say UUCP support is the reason for sendmail being 'un-Unixlike'? Isn't UUCP, you know, like the historic essence of Unix?
The Unixlike solution would be to have multiple servers, each speaking one protocol (or thereabouts), and then you'd only install what you need.
Or are we talking about the sendmail api?
Though I haven't touched a Sendmail.cf in well over a decade.
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.
Well, it was publicly released in 1986, so it's been broken for almost 30 years in the same sense that Sendmail has been broken for decades.
It's had a reasonable alternative (SVN) since 2000, well over a decade ago, which itself has had a superior alternative for years now.
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 ;-)