To deliver electronic mail (email), applications shall support the interface provided by /usr/sbin/sendmail (described here). The /usr/sbin/sendmail interface shall be the default delivery method for applications.
This program sends an email message to one or more recipients, routing the message as necessary. This program is not intended as a user interface routine.
With no flags, sendmail reads its standard input up to an end-of-file or a line consisting only of a single dot and sends a copy of the message found there to all of the addresses listed. It determines the network(s) to use based on the syntax and contents of the addresses.
It is recommended that applications use as few flags as necessary, none if possible.
Some agents allow aliasing on the local system to be prevented by preceding the address with a backslash.
The of messages must be as defined in RFC 2822.
Read mail from standard input and deliver to the recipient addresses. This is the default mode of operation.
List information about messages currently in the input mail queue.
Use the SMTP protocol as described in RFC 2821. (Read SMTP commands on standard input and write SMTP responses on standard output.)
Note that RFC 2821 specifies \r\n (CR-LF) be used at the end of each line, but Unix pipes almost always use \n (LF) instead. To deal with this, agents will accept both \r\n and \n at the end of each line. When accepting \r\n, the \r before the \n is silently discarded.
Explicitly set the full name of the sender for incoming mail unless the message already contains a From: message header.
If the user running sendmail is not sufficiently trusted, then the actual sender may be indicated in the message, depending on the behavior of the agent.
Explicitly set the envelope sender address for incoming mail. If there is no From: header, the address specified in the From: header will also be set.
If the user running sendmail is not sufficiently trusted, then the actual sender will be indicated in the message.
Ignore dots alone on lines by themselves in incoming messages. This option is ignored when -bs is used.
If supported, deliver any mail in background. Otherwise, this option is ignored.
If supported, deliver any mail in foreground. Otherwise, this option is ignored.
Mail errors back to the sender (default).
Write errors to the standard error output.
Do not send notification of errors to the sender. This only works for mail delivered locally.
Write errors to the sender's terminal using the write(1) command, if he is logged in. Otherwise, mail errors back to the sender. If not supported, report errors in the same manner as -oem.
Same as -i.
This option means 'me too', indicating that the sender of a message should receive a copy of the message if the sender appears in an alias expansion. Ignored if aliases are not supported.
Read the message to obtain recipients from the To:, Cc:, and Bcc: headers in the message instead of from the command arguments. If a Bcc: header is present, it is removed from the message unless there is no To: or Cc: header, in which case a Bcc: header with no data is created, in accordance with RFC 2822.
If there are any arguments, they specify addresses to which the message is not to be delivered. That is, the argument addresses are removed from the recipients list obtained from the headers. Note: some agents implement this behavior in reverse, adding addresses instead of removing them. Others may disallow addresses in argument list. Therefore, applications should not put addresses in the argument list if -t is used.
This option is sometimes ignored when not in -bm mode (the default).
Be more verbose. Additional -v options may make the software increasingly verbose.
Successful completion on all addresses. This does not indicate successful delivery.
There was an error.
This page is believed to reflect functionality provided by smail, exim and other implementations, just not the sendmail implementation.
There has been a suggestion to remove -oew, -ew, -om, -t, and -v. Also to disallow -i when -bs is specified. Most of this strikes me as a good idea, but it might want further discussion. Seems to me that the text "Some agents allow aliasing on the local system to be prevented by preceding the address with a backslash" needs to remain, if the behavior of different implementations really does vary.