I have a website with some PHP based CMS on which I'm the only user. This website has a simple contact form (name, email, phone and body) by which I get mail from non registered users.

I'd like to transfer emails from that form directly to my email account (I have no problem they'll go to spam dir as I would put the IP of the site's machine in a goodlist); hence I prefer not to set any DNS records because I have no problem with spam dir at least once.

I understand there are basically three ways for me to use SMTP on any Linux system (by the PHP mail() function in this case):

1. Installing and configuring an email server (like postfix).


2. Installing and configuring an email proxy program (like ssmtp) which will also include "showing to possible hackers" a dedicated email account and its password in the ssmtp conf file, so the program could use that account as proxy.


3. 
   Per this answer, a third way, that might be named sendmail binary.

Is there such a concept as a sendmail binary and if so, how it differs from the first two options?

Once upon a time, there was an SMTP server called sendmail. (In fact, the SMTP server does still exist.) It was riddled with root exploits - one after another after another after another for a long time. Other SMTP servers arose to replace the problematic SMTP server - such as postfix, qmail, etc. At one point, sendmail was so bad that one could place any command in a ~/.forward file, send mail to the account with the ~/.forward file, and execute all of the commands in the ~/.forward file as the root user. There were many, many, many more simple exploits. Until the sendmail SMTP server became so wildly insecure, it was ubiquitous; thus, lots of software grew to depend on the existence of sendmail.

Today, SMTP servers provide a sendmail binary of their own making to operate with other programs that depend on its existence. For example, after installing the Postfix SMTP server, the manual's first declaration is as follows: "sendmail - Postfix to Sendmail compatibility interface." In context of your question, it means that one might simply utilize the sendmail binary from PHP both to simplify the PHP code and to leverage an existing well-configured SMTP server. For your question, sendmail means a binary program that acts like a wrapper around an existing SMTP server installation that is not the sendmail SMTP server. In other words, you still need an SMTP server to utilize the sendmail binary.

The DNS portion is simple: one merely needs an MX record and a TXT record with SPF. The MX record is the Mail eXchange record. It's not official, but everyone uses it. It specifies a numbered priority in the event that more than one SMTP server exists for the domain. This is the value, 10, below. The lowest number has the greatest priority.

SPF is the Sender Policy Framework. This record publishes a list of addresses or subnets authorized to send mail on behalf of the domain. This reduces spam and fraud by making it much harder for malicious senders to disguise their identity. Almost all other SMTP servers won't communicate via SMTP with a domain that doesn't implement the SPF record.

Type Host Value

MX   @    10 full.host.name

TXT  @    v=spf1 mx a -all

Actually, as noted in a comment, by @RubberStamp, DMARC records are also now in use. So this technology should be implemented proactively. That is, why wait to break when the right thing to do is to keep services running smoothly? I don't have an example of records like that because I just realized that I had missed the train, evidentially, having no issues with SMTP reported anywhere. But I'll come back later to post.

After these records exist, one might continue to install and configure an SMTP server, such as Postfix, qmail, exim, et al. After configuring, use open-relay test tools to make sure that spammers cannot abuse your new SMTP server.

The program, ssmtp, is a send-only program. It's not a mail server. It connects to mail server using credentials to authenticate before sending mail. Nothing short of a root compromise would have to occur before anyone could read credentials from a file storing them for ssmtp.

It's not a third way.

It's the first of two ways:

1. running a well-known program and giving it the envelope and message as inputs, or


2. 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/ucb/sendmail (or /usr/libexec/sendmail, or /usr/lib/sendmail, or /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.

• This was particularly the case for qmail.


• Most notably it was not the case for Exim, which still does everything all in one giant program and even adds a whole bunch of further -bx modes, some of which Sendmail has accrued too in the years since, including an extra mode that speaks SMTP Submission over standard I/O.


• Zmailer's sendmail supported a whole bunch of modes, too, but farmed the work out to multiple native programs under the covers.


• MMDF was one of the few that did not provide a sendmail shim, but required that users employ the aforementioned MUA configuration settings to point to its submit program. The MMDF doco gives an example of how to configure Mutt:

  set sendmail='/usr/mmdf/bin/submit -mlnre'

  
  

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 at jobs.

The replacement 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.

Further reading

• 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.