It's not a third way.
It's the first of two ways:
- running a well-known program and giving it the envelope and message as inputs, or
- making a TCP connection to a remote/local SMTP Submission server and speaking the SMTP Submission protocol.
(A third way would be speaking the Old-Fashioned Mail Injection Protocol to a local/remote server, but I like to think that two decades on the world has embraced proper SMTP Submission, distinct from SMTP Relay, by now.)
The old BSD Sendmail program in the 1980s, once but no longer a very popular mail subsystem, allowed Mail User Agents, the mail readers and news readers of the time as well as the various subsystems that reported stuff via mail, to submit mail by running the program with the message envelope as command-line arguments and the message content (headers and body) as the program's standard input. MUAs such as Berkeley
Mail and AT&T
mailx did not, like their forerunners, directly inject mail into user mailboxes. Instead they forked a child process running Sendmail with the relevant command-line arguments and sent the message content to that child process via a pipe.
The program was generally not on the shell's command search path, but rather had a well-known pathname that was used in full to run it. MUAs often had configurable options to allow users to override the compiled-in pathname, but in the absence of that MUAs would be running a program in a file named
/usr/sbin/sendmail, or some other similar filename, varying from operating system to operating system).
This binary program image file comprising the Sendmail program became the de facto scheme for mail submission. Replacement Mail Transport Systems that superseded BSD Sendmail ended up providing a program of their own, still called
sendmail because that was the name hardwired in to the MUAs, that would interoperate with their various different systems.
The original program was of course BSD Sendmail itself, a single program that vainly wore all of the hats at once, doing all of the jobs of the MTS. This could be operated in various different modes, selectable with the several
-bx options. Submission was just one of the modes,
-bm, which happened to be the default mode.
Many replacement MTSes did not work this way at all, and the functionality of their replacement
sendmail programs is limited to just mail submission.
Windows NT never really had anything similar, which is why you'll find cross-platform softwares talking in generalities about different behaviours. It also lacks the tradition of simply expecting every host to be mail-capable in some form or another. (To this day, for example, various parts of FreeBSD expect to be able to send mail to users and to the system administrator as a matter of routine.)
(OS/2 did not have the tradition either, and was not even multi-user. However, it too came with a port of BSD Sendmail. I once wrote a replacement MTS for OS/2 with a shim for the IBM-supplied
sendmail.exe. Similar to Zmailer's
sendmail, it farmed things out to native programs under the covers.)
On Unices, however, the presence of a mail system is taken as read. Furthermore, this sort of mechanism was the norm, for more than just mail, before the idea of servers listening on TCP sockets became widespread. One ran a set-GID/set-UID program and gave it command-line arguments and standard input data to submit print jobs, to schedule UUCP jobs, and to schedule
sendmail programs generally are not set-UID/set-GID like the BSD Sendmail program was. (Sometimes, as in the case of mini-qmail and other systems that just push all mail over to a queue on another host, there's no need for any set-ID programs at all. Othertimes, the set-ID program is the MTS's native program that the
sendmail program wraps.) And they generally only support submission. But this remains one of the two ways of submitting mail to this day.
- Philip Hazel (2018). "Receiving mail". Exim specification.
- Rayan Zachariassen (2003-08-28).
sendmail. Zmailer manual. zmailer.org.
submit. System Administrator's Manual. SCO.
sendmail. Maintenance Commands. 2017-05-13. Illumos.