TLDR
By default on most Linux distributions:
- There is
sendmail functionality available
- Access to
sendmail is NOT restricted
And in theory any user and any application/daemon/process/script can send e-mails.
Therefor creating a conclusive list with [useful] applications that can [optionally be configured to] send e-mail is impossible.
You can check your MTA’s log files and the contents of your mail spool directory for evidence of installed applications that currently (attempt to) send email.
The ability and the associated command line utilities to send mail still are and have always been a core function that must be present on a Linux system according to for example the Linux Standard Base. These include a mail command (currently mailx) and a sendmail ( usually both as a /usr/lib/sendmail interface and a [/usr]/[s]bin/sendmail command in the default $PATH) which are commonly offered by one of the many different SMTP implementations and no longer the canonical Sendmail MTA.
The idea is/was that any application can use the mail interface to notify a [local] user or an administrator (the root user). Unless otherwise configured the expected behaviour is to deliver such e-mail messages to a local mailbox. Local mail traditionally gets stored in /var/spool/mail/[login] and typically a new mail notification gets displayed any time a user or administrator initiates an interactive login session (e.g. over SSH). More advanced configuration is/was to forward those messages to a central mail server (via aliases and/or the configuration of a mail relay), rather than the local mail spool.
As far as I know the default mail daemon configuration on most Linux distributions won't accept incoming SMTP e-mail other than messages generated on the system itself (in other words the system only accepts mail from localhost), but will allow the sending of outgoing internet e-mail. Due to spam and spam prevention setting up reliable e-mail delivery is not a trivial exercise anymore and nowadays you should not expect that internet e-mails from your Linux systems will be accepted automatically and/or will reach internet recipients without a lot of additional tuning. (See for example these Q&A's Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User? - Prevent mail being marked as spam - How to send emails and avoid them being classified as spam?)
Who still reads e-mail alerts/reports
Hopefully you're part of a team and your job consists of maintaining more than a single server. In that case, and almost always regardless, relying on systems and individual daemons to send you e-mails is probably not what you should be doing.
You should aim that anything that requires follow up by a human ends up in your monitoring and alerting system and/or results in a ticket.
And although many ticketing systems can ingest e-mails, often the resulting ticket is not immediately actionable, so I'd recommend that approach. See for more: https://web.archive.org/web/20240809031552/https://www.opsreportcard.com/section/18
