7 ms·

Last years fight in Fedora to do something similar: http://lwn.net/Articles/561494/ http://lwn.net/Articles/561494/

by krakensden 12y ago

angersock 12y ago
I think Poettering pushed for it just so there would be an excuse to allow systemd to handle email too. :(
- peterwwillis 12y ago
  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. https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/dToG1PGNc1Q https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
  - lomnakkus 12y ago
    I'm just curious, what exactly is the use case for a mail daemon on a single free-standing machine? (I'm not trolling here, btw.)
    - peterwwillis 12y ago
      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.
      - lomnakkus 12y ago
        > 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.
        peterwwillis 12y ago
        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.
        lomnakkus 12y ago
        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.
      - slasaus 12y ago
        one of the first things I do on a new box is setting up /etc/aliases to send all mail to root to my e-mail address. about alerting, I use the simple (and old but has all you need) logsentry also sometimes called logcheck.
    - andreasvc 12y ago
      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).
      - kstrauser 12y ago
        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.
        andreasvc 12y ago
        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.
      - peterwwillis 12y ago
        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.
nailer 12y ago
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.
- vidarh 12y ago
  Sendmail was awful and archaic already when I first used it in 1995. It's amazing that anyone has still been using it for the last decade.
  - jfb 12y ago
    I'm waiting with bated breath for the knee-jerk contrarian "sendmail survived therefore it is great" comment.
  - Natsu 12y ago
    ... let alone the past two decades.
  - zorked 12y ago
    Ah, sendmail in the 90's. So many buffer overruns you might just as well enable telnet and change your root password to "hackme".
- ChuckMcM 12y ago
  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.
- __david__ 12y ago
  > 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.
agwa 12y ago
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.
ck2 12y ago
Isn't postfix the default in CentOS 7? It's not in Fedora? Or are we talking about the sendmail api?
xenophonf 12y ago
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.
- sciurus 12y ago
  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.

Last years fight in Fedora to do something similar: http://lwn.net/Articles/561494/ http://lwn.net/Articles/561494/

angersock 12y ago

I think Poettering pushed for it just so there would be an excuse to allow systemd to handle email too. :(

peterwwillis 12y ago
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. https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/dToG1PGNc1Q https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
- lomnakkus 12y ago
  I'm just curious, what exactly is the use case for a mail daemon on a single free-standing machine? (I'm not trolling here, btw.)
  - peterwwillis 12y ago
    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.
    - lomnakkus 12y ago
      > 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.
      - peterwwillis 12y ago
        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.
        lomnakkus 12y ago
        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.
    - slasaus 12y ago
      one of the first things I do on a new box is setting up /etc/aliases to send all mail to root to my e-mail address. about alerting, I use the simple (and old but has all you need) logsentry also sometimes called logcheck.
  - andreasvc 12y ago
    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).
    - kstrauser 12y ago
      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.
      - andreasvc 12y ago
        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.
    - peterwwillis 12y ago
      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.

nailer 12y ago

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.

vidarh 12y ago
Sendmail was awful and archaic already when I first used it in 1995. It's amazing that anyone has still been using it for the last decade.
- jfb 12y ago
  I'm waiting with bated breath for the knee-jerk contrarian "sendmail survived therefore it is great" comment.
- Natsu 12y ago
  ... let alone the past two decades.
- zorked 12y ago
  Ah, sendmail in the 90's. So many buffer overruns you might just as well enable telnet and change your root password to "hackme".
ChuckMcM 12y ago
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.
__david__ 12y ago
> 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.

agwa 12y ago

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.

ck2 12y ago

Isn't postfix the default in CentOS 7? It's not in Fedora? Or are we talking about the sendmail api?

xenophonf 12y ago

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.

sciurus 12y ago
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.