I've been using dma for some Linux servers in a simple 'smart host only' configuration (that is, all mail is forwarded to some central 'real' MTA), mostly in order to deliver mails from cron. As the commit message notes, DMA is not a full-featured MTA like sendmail or postfix, but rather a minimalistic MTA. Makes sense to have as the default one; those who have a need for a 'real' MTA can install and setup such a thing.
In hindsight, one can wonder why it's not the default behavior everywhere. After all, most systems need some form of mail, but only basic. The rest can install a fully-featured version easily. It's a win-win situation: increased security for those who don't need a fully-featured MTA and the rest doesn't lose anything.
> In hindsight, one can wonder why it's not the default behavior everywhere.
Nowadays most Linux distros don't install any MTA by default. Which I think is an entirely valid choice, considering home users, laptop warriors etc. that don't run any services (for the external world) on the machine, and setting up even a simple smarthost type configuration requires putting in some config data during the installation process.
To me the olden way of every server running some email daemon in the background always felt so weird; the only purpose seemed to be a black hole for a things like sudo and cron write their messages to, something surely a simple log file would have sufficed for.
Eh. I felt that way until I configured my MTA correctly on FreeBSD and I was suddenly receiving emails with package out-of-date notifications, summaries of failed cron jobs, etc that are more suited as “push” than “pull” unless it’s your job to monitor the logs on an hourly/daily basis.
There's a ton of basically-forgotten system-level functionality that's tossed aside in favor of complex aggregator services and SPA dashboards and new configuration systems and such.
You can get a hell of a lot of mileage out of knowing which parts of your system can be swapped out or configured in interesting ways, but these days you're more likely to treat your OS as a dumb binary-runner and let a dozen SaaS do all the interesting stuff instead.
Kinda like people who treat their DB as a dumb datastore and don't actually leverage any interesting or distinctive features of it. I guess it's nice that your system can be ported to almost any datastore without trouble, but... man you'd have saved yourself a lot of time, bugs, and money if you'd just actually leveraged your DB. Seems operating systems are getting the same treatment. Why learn to configure a forwarding log daemon when you can just ship to logstash? Why use email alerts when you have pagerduty and an uptime monitor and just auto-rebuild any instances that error? Why use full-featured filesystems like ZFS, and really take advantage of its capabilities to easily add features that'd otherwise be very difficult or to attain much greater server reliability/uptime if you're gonna store everything on S3 and your instances are ephemeral? But then one wonders, why run an actual full OS in the first place, then, if you're not going to use it at all? And indeed, I gather some are moving away from that, for precisely that reason (e.g. Firecracker, "serverless")
Me, I find myself digging deeper and deeper into letting the OS, system services, and mature daemons solve problems for me, rather than searching Github first thing for whatever half-baked Nodejs "webscale" solution there is, or DIYing something that treats the OS as nothing but a job-runner and socket-provider. But that seems to be dinosaur thinking these days.
I think you know this as you mention "olden way" - it's definitely the thread of history where most UNIX servers were multi-user systems: that's how I was first exposed to Unix, even though by late 80's/early 90's most of them were Linux or a *BSD. In those - presumably University mostly - environments, we mostly sent email to each other and that was often between servers on a campus or environment. It made sense then that each server sent email because you were specifically user@host.someplace.
When the distros started to expand, being a smarthost was the most common configuration. Today, I agree with you the only reason for any sort of SMTP daemon is for programs to send email - all the users are on Google/Slack.
That's exactly my problem today - I have some old PCs repurposed as homelab, and they require some cron jobs to keep them in check - like forcing modules, or keeping the fans from whining. Without any MTA, it's such a chore to learn why something is failing. In this age, the whole "cron only sends output logs through email" seems super anachronistic.
Guess it's some leftover from ye olde days when machines were multiuser things, lovingly cared for by sysadmins. In such a world, might make sense to have local mail delivery on each host.
I did look into a number of these minimal MTA's, reading a few blog posts etc. before deciding on dma. A couple of neat features:
- Reads aliases from /etc/aliases like the Flying Spaghetti Monster intended.
- Limited (very limited, but good enough for smarthost type usage) spooling support. So if there's a glitch at the moment you're trying to send mail, it's not lost (as DMA doesn't run any daemons, there's a cronjob which checks the outgoing spool and tries to deliver the email).
- Actively maintained, and available in the distro archives.
Interesting solution to the spool, not sure if I want it for my own stuff, but it is very minimalistic and nice. I get why you picked it. Seems like it tries to do the minimum possible to replace traditional sendmail with something still unixy.
Worked at a place with OpenVMS and a UUCP setup. Yep, I've used mail11. I've use to setup UUCP mailers. I've hand configured sendmail with fingertips scarred from thumbing through the bat book. I've worked with sendmail to route mail to Novell NetMail!
I use to be a Sendmail consultant.
I've seen things you people won't believe. Open SMTP relays with zero firewall protection. I've watched people use sendmail to get root without a password. I've seen volumes of email lost in time, like bits into /dev/null. Time to patch.
I ran UUCP well into the 2010s. Starting around 1999 I was running a small company and we all had laptops as our primary machines. Remember, back then Internet was fairly spotty: Still dial up, CDMA 9600bps cellular, Richochet, PCMCIA, BreezeNet...
UUCP with qmail and later Postfix was a great way to shove e-mail over these really unreliable connections. The g protocol worked amazingly well over these unreliable connections because it could pick up where it left off, so as long as you could get a few packets through, eventually your (sometimes large) e-mail messages could make it through, even if they had the spend the night trying.
The company kept that architecture well into the 2010s, even when we all had fairly speedy, reliable Internet connections, because it just worked really well. They eventually went to gmail years after I left.
I will always have a fondness for UUCP. I eventually moved to qmail (a bit hacked up to handle for some unusual requirements) for all the UUCP related stuff.
UUCP had it's issues, but it was (and still is) one of the best was to transfer stuff over really bad connections. We worked at a place where we had really remote locations and UUCP stuff worked without much work.
Plus, I learned a ton in writing something to do reports and monitoring of the UUCP connections. Fun times, but I am still scarred Sendmail. Some wounds are pretty deep.
Back circa 1994, I was getting e-mail by dialing in to the Boulder Internet Coop via UUCP. They were really experienced Unix folks (Trent Hein, Evi Nemeth RIP), running Sun. At one point, the uucp queue got big enough (I believe from machines that were connecting infrequently or maybe not at all), that the directory holding all those files couldn't be scanned in less than the UUCP timeout. All the while I was paying long distance rates (remember those) to sit on the line idling.
I had recommended they switch to using Taylor UUCP, because it splits the queue directory up into a hierarchy. They said Taylor wasn't mature enough, but I asked Ian Lance Taylor about it and he laughed and said "<THE major commercial UUCP provider> doesn't seem to agree." :-)
I've always heard that Kermit has really great protocols for handling horribly, horribly bad modem connections. I had at times wondered if a kermit UUCP protocol would have been useful.
Circa 1990, our site (mostly a Sun shop) had to mess with our email setup, which included a UUCP link with HQ addressed by the unqualified hostname of the site's mail server, public bang paths to site servers (and percents), but also domain names (probably SMTP served from HQ and forwarded), and delivered to Unix workstation users by dropping into an mbox file in NFS automounted homedirs, and to non-engineering people running PC NFS and Eudora I don't know how...
We did almost all sysadmin expertise in-house, but for this Sendmail, we brought in a consultant.
It was a name I recognized from Usenet, and knowingly meeting a "famous" person was pretty new to me at the time. Turns out he wasn't a Unix graybeard (closer to my young skinny nerd age), and he was working on a Neuroscience PhD, while building/fixing everyone's Sendmail setups.
I didn't know to ask him which discipline was more difficult.
Once I started hosting my own personal email seriously, I think Exim was probably available. Even Exim config for a simple setup could get a bit tricky (e.g., I made it drop `Received` headers of outgoing email it was relaying for me), but nothing like Sendmail.
I inherited one of these once. Someone had got half way through migrating it to Pegasus on NT and given up. Just as I got the whole damn thing in reasonable shape the bastards hired some Lotus consultants and replaced it with Lotus Notes.
All you really need to show is how Linus Åkesson made a Turtle animation[1] using Sendmail cf. That level of complexity should not exist in any configuration language.
Life is too short for software with its own, unique configuration language. I've spent months on learning Exim configuration gymnastics, trying to make it both efficient and useful and without breaking functionality used by a company/organization.
I remember I implemented some modifications my boss asked me and went on a business trip to Russia. It was early 2000s, no smartphones, and the only Internet on the phone was WAP. So my boss is calling me and telling me our mail server is sending out spam. Yes, I turned on open relay by accident...
I run to the nearest Internet cafe and discovered they're blocking SSH ports. It took quite some time to unblock it, make the changes (it took less than a minute) and pray nobody intercepted my access data and make a mess before I get back. I've never felt so ashamed about my lack of professionalism in my entire life. I literally hated myself for being forced to use a public Internet cafe to configure my server.
“Debugging mode has many features, including the ability to send a mail message with a program as the recipient (i.e. the program would run, with all of its input coming from the body of the message).“
I don’t know why that page follows that with “This is inappropriate” /s
I never did get used to running make on my config files.
Or the pain of somebody on the team routinely editing the output files without making the changes on the config files, and never knowing whether it'll work the same when you're done.
> I never did get used to running make on my config files.
I worked in a very Make oriented place. If you need to do any processing on files, which not only includes compiling them, but also pushing them to other servers, and loading them into memory on those servers, that should be done with Make. Because Make makes things :)
Now I'd rather write a Makefile than use whatever language's builder of the week. Make can make things, why do I need anything else?
Shudders. The LPIC exams I took back in 2005 made me think I would spend the next 20 years in vim manually configuring apache, sendmail, bind, openldap and a bunch of other stuff I haven't touched since the exam.
Maybe a coincidence, but Eric Allman is the developer of Sendmail [1] and the spouse of Marshall Kirk McKusick, one of the long-serving board members that left the FreeBSD Foundation this summer [2].
It's especially funny that Marshall said never tell anyone that your are good at writing drivers or sendmail-configuration because that will be your life's destination then ;)
Heh, similar to "never let your coworkers know you are good with Excel". Or, in non-tech offices, never let anyone know you understand technology at all.
I wonder if there's a name for that general sentiment, and how far back comments on that sort of thing go.
I interviewed somewhere without a resume, because of a referral, but the CEO asked me what I did, so I started at the beginning without thinking... 12 years before I started there, I had worked at a rinky-dink ISP, and before that I did IT at a school district as a student worker.... guess who got to configure mail and manage the domains and own the GSuite account. Bah
"The reward for a job well done is usually another job to do. Remember that if you're ever tempted to do a good job of something thankless and unpleasant."
McKusick is also known for the filesystem (FFS / UFS).
The use of sendmail in FreeBSD isn't exactly a coincidence -- it, too, was developed at Berkeley in the 70s and 80s. And it's probably unsurprising that people meet other people living and working in the same place (grad school).
Really happy to see this cross-pollination in BSD land.
Not just DragonFlyBSD getting packages via DeltaPorts, but FreeBSD also getting updates from DragonFly.
I respect sendmail. Obviously there are other MTAs like djb’s Q mail, postfix as well as newer ones written in Go and Rust. Sure sendmail has had its share of vulnerabilities. But it’s the falls it suffered that made every other MTA strong.
Let’s respect the software of the past. It’s the past’s software that built today’s software.
Agree. The hardest thing in the world (besides configuring sendmail) is to remember that other peoples' use cases are not necessarily my use case. The world of email was a whole lot different back when sendmail was created.
> The world of email was a whole lot different back when sendmail was created.
Sure, email in 80s was different than in the 90s. The problem with sendmail is that it didn't get replaced when it really wasn't a good fit anymore and instead it got dragged on for extra 30 years.
No. Let it die and stand over the grave to make sure it stays dead. Even 20 years ago there were better alternatives; Debian sensibly defaulted to Exim.
It's always been a horrendously difficult to configure monolith.
Sendmail wasn't really the first per se, but it was the first that worked well. In the early 80s there were a lot of competing email protocols and systems and implementations, and Sendmail could talk to all of them, in a "bug-compatible" way. This is also why sendmail.cf is so bewilderingly flexible and complex.
Later email systems like Postfix and qmail in the 90s had it much easier as they operated in a much simpler ecosystem.
At least MMDF was (a little) earlier. Maybe it lacked some features compared to sendmail? It ran at several university sites at least. It was an early adopter of least-privilege architecture, predating qmail by a lot.
I remember trying to setup sendmail 15-20 years ago, and it was a horrendous experience.
Seeing this news reminds me of an old quote (which I cannot find a direct reference to at this point):
"There is nothing in human experience when compared to setting up a sendmail config-file which can be considered hard."
Based on this move, I guess this means sendmail haven't really improved much in that regard since, and most people just avoiding it for that reason?
I guess... Good riddance, then?
I'm more surprised they still used sendmail, most of the other distros moved away from that... abomination in every respect decades ago. I still remember fun of setting it up then migrating to qmail (which was also ...interesting to setup)
The "real" sendmail hasn't been the base system one for ages. The sendmail in the base system ist only a fairly minimal configuration used for local mail delivery (cron, sudo, etc.). The reason it took so long is that there was no consensus on what should succeed sendmail as the default mailer. There are several mail transfer agents just one pkg install away (Postfix, exim, OpenSMTPd, (newer) DMA, ssmtp, msmtp, etc.).
I'm a fan of msmtp for this sort of "lightweight" mail sender, since I really only need it for cron notifications and a few hacky scripts. Maybe I'll give dma a spin.
Of course I can, I can even compile it from source codes, which I sometimes do. :)
I use FreeBSD for decades and sendmail was my number one and the only choice of MTA all that time. Not only mine, but all others FreeBSD users I know too. I don't get why would something that works excellent should be changed to something that, well, is just a dummy ? I love sendmail. I think I can cook it quite well, and I don't get why I should change my habits. Not changing habits is one of the major reasons I use FreeBSD these days. Otherwise I would switch to Linux long time ago. Now FreeBSD made one more step towards its death.
If someone has prejudice against sendmail adding sendmail_enable="NONE" in rc.conf is easy.
Sendmail was developed in the early 80s to be bug-compatible with crappy bespoke email systems of the time, as well as long-dead protocols like decmail and whatnot. It made a lot of decisions in that context that were sensible at the time, but that have become a lot less sensible as the world and ecosystem has changed over the last 40 years.
Sendmail is not dead, but its glory days are over. 30 years ago the entire world was running on Sendmail, but this already started shifting 20 years ago, and today Sendmail operates a tiny minority of the world's email servers.
If you want to keep running Sendmail: great! Go for it! But it's just not a sensible default any more. The art of picking defaults is choosing something that will work for most people with a minimal surface for footguns. And Sendmail is clearly not it. I appreciate you don't want to "change your habits" – I usually don't want to either – but FreeBSD does not revolve around you.
There are many more people who dislike sendmail than people who like it. It's like several orders of magnitude. And it's objectively hard to configure securely. Sorry. If you want to keep using it, nothing is stopping you, but the rest of the world wants sensible defaults.
Git is so recent comparing to Sendmail. I began using Git for my projects just a couple of years ago. I was die-hard CVS user, switching to Git was a pain for me. Now with Git I've had to employ Linux best practice - update everything once a month or so, which often leads to compatibility problems that have to be resolved. This all eats quite a lot of time, unfortunately.
