I take it you are describing policy rather than capability. What I was getting at is that email is kind of built in by default with Unix like systems. It is actually quite hard to install a Linux or BSD box without the capability to send email. SMTP is at heart, very, very simple and can be conducted via telnet if necessary although doing TLS via telnet by hand might be a bit tricky.
I have deployed many Ubuntu boxes and sometimes been surprised to receive emails - cron (logwatch) usually. Our central SMTP daemon has me as an alias for root, postmaster etc. Don't know why I'm surprised - I set the bloody things up to work - perhaps I'm going a bit senior.
No -- sending external mail is very difficult and requires setting up at least DKIM. "Email" is built in and a LAN of *nix servers can usually send messages to each other but they are not set up as a state of the art public mail server would be. Even the LAN sending is being phased out, if you get a message it may be local delivery only.
If the messages are going out they probably use an MTA and are logging in to a hosted service, which is something that needs to be set up.
You are having a laugh - SMTP is not hard (for a given value of hard.) I've run Unix SMTP daemons and Exchange (and GroupWise and L Notes) for over 20 years. My weapon of choice is Exim with rspamd these days but I know Postfix, Qmail and sendmail and of course Spamassassin with extras.
DKIM is the second of the trifecta, SPF first and then DMARC after DKIM. DMARC is when things start to go horribly wrong or wrongerer than normal in the world of email. Mailing lists get funky shortly after you proudly publish a TXT record starting "v=DMARC1; and p=<unwise choice>.
I'm not sure that state of the art is appropriate when describing SMTP. It is what it is and no more, nor less. It transfers a huge amount of data daily, without fuss or comment. Perhaps that is the state of the art - it is in my world: I like stable and boring and just works.
I'm (nearly) a Civil Engineer and I think of SMTP as an odd analogy for concrete. It's fundamental and very boring but can be surprisingly complicated and interesting if you get it wrong. Conc. can burn or get tricky in all sorts of ways if poured in excessive amounts - setting is an exothermic reaction and will work under water as well. Conc can suffer from concrete cancer which is where sea air and a few other factors causes "map cracking" and potentially failure. SMTP is another function that is dumped into the background, forgotten about and relied upon to just work until the wheels fall off.
Yes, yes, I've set up a working mail server also. All my point is is that any SMTP daemons in a Linux installation are not really in a usable state by default and require a lot of reasonably tedious actions to set up. Every distro I have used in recent memory has not been able to do anything but local delivery, and even then sometimes an SMTP daemon is missing.
Every distro I have used in recent memory has only ever had local delivery working by default, and sometimes not even that. So the GP (or GGP) post about cron not having a failure detection mechanism is mostly true.
The only major distro like that is Debian. RHEL, SuSE, Alpine, even the default AWS images are configured to send outgoing mail by default. All four BSDs are too.
Local-only (outside of Debian) is generally only found on desktop- or hobby-oriented Linux things like Fedora and Arch -- which aren't really germane here.
Yes but from memory that outbound mail is only able to be received by machines configured to receive it with no authenticity checking, i.e. your other servers you set up. The usecase I usually see for this is you set up one server as an MTA that forwards to GMail, etc, and all other servers send mail to that MTA.
But that local MTA you have is not typically something you log in to check your mail, and all of these things are not set up by default.
... that the functionality people here seem to expect is not set up by default. Some of the people commenting don't seem to know what needs to be set up, thus the explanation for their benefit, and also an explanation of what exactly is not set up.
Your objection is that the computer does not magically precog the admin's delivery address? Or what? It works fine without DKIM or SPF or any of that stuff; at best you must whitelist the message sender.s
I'm having a hard time understanding you because you refuse to specify "what needs to be set up" and when you have you've been mistaken.
LAN sending is not being "phased out". Email is not being "phased out". Nothing has changed with email policies on any of these distros for the better part of a decade.
I have deployed many Ubuntu boxes and sometimes been surprised to receive emails - cron (logwatch) usually. Our central SMTP daemon has me as an alias for root, postmaster etc. Don't know why I'm surprised - I set the bloody things up to work - perhaps I'm going a bit senior.