Understanding sendmail binary
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):
- Installing and configuring an email server (like
postfix
). - 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 thessmtp
conf file, so the program could use that account as proxy.
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?
dns postfix sendmail smtp ssmtp
|
show 2 more comments
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):
- Installing and configuring an email server (like
postfix
). - 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 thessmtp
conf file, so the program could use that account as proxy.
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?
dns postfix sendmail smtp ssmtp
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
1
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago
|
show 2 more comments
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):
- Installing and configuring an email server (like
postfix
). - 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 thessmtp
conf file, so the program could use that account as proxy.
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?
dns postfix sendmail smtp ssmtp
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):
- Installing and configuring an email server (like
postfix
). - 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 thessmtp
conf file, so the program could use that account as proxy.
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?
dns postfix sendmail smtp ssmtp
dns postfix sendmail smtp ssmtp
edited 10 hours ago
JohnDoea
asked 14 hours ago
JohnDoeaJohnDoea
891133
891133
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
1
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago
|
show 2 more comments
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
1
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
1
1
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago
|
show 2 more comments
2 Answers
2
active
oldest
votes
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
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
.
add a comment |
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/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 itssubmit
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.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499757%2funderstanding-sendmail-binary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
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
.
add a comment |
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
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
.
add a comment |
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
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
.
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
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
.
answered 10 hours ago
ChristopherChristopher
10.4k33148
10.4k33148
add a comment |
add a comment |
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/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 itssubmit
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.
add a comment |
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/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 itssubmit
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.
add a comment |
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/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 itssubmit
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.
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/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 itssubmit
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.
answered 10 hours ago
JdeBPJdeBP
34.8k470163
34.8k470163
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499757%2funderstanding-sendmail-binary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
There is a another way, that is talking with an email server directly outside of the frontend server (e,g. basically there are two main diverging email APIs/methods). However, talking about programming APIs seems more of the SO domain than here. Alas, it is not 3 ways, the sendmail binary emulation mode works in conjunction with what you call 1) and 2), which are the same method, but different implementations of email transport. Why not testing stuff first and then writing a more informed question? Most of your doubts will probably disappear after you try it.
– Rui F Ribeiro
14 hours ago
Btw, a question mentioning "all ways" is TOO broad by definition.
– Rui F Ribeiro
14 hours ago
1
The title for the actual question being asked is What is a "sendmail binary"?.
– JdeBP
13 hours ago
@JdeBP Now that you talk about it, it simplifies the question a lot....
– Rui F Ribeiro
13 hours ago
If not using authenticated SMTP relay, then you must modify DNS for the SPF TXT record or else other SMTP servers will refuse to speak to your SMTP server. You may as well throw in an MX record at the same time. The sendmail binary is a historical "wrapper" these days to keep compatibility and functionality the same as it was long ago. It uses the local SMTP service anyway. So I guess the question becomes, "How do I use authenticated SMTP relay in conjunction with the sendmail binary?" Right?
– Christopher
12 hours ago