HELO sendinghostname - Hello
This command initiates the SMTP conversation. The host connecting to the remote SMTP server identifies itself by its fully qualified domain name.
EHLO sendinghostname - Extended Hello
An alternative command for starting the conversation. This states that the sending server wants to use the extended SMTP (ESMTP) protocol.
RCPT To:<destination e-mail address> - Recipient to
This identifies the recipient of the e-mail message. This command can be repeated multiple times for a given message in order to deliver a single message to multiple recipients.
DATA - Mail Data
The software considers all succeeding lines up to but not including the end of mail data indicator to be the message text. When the end of text is successfully received and stored the SMTP-receiver sends a 250 OK reply.
Since the mail data is sent on the transmission channel, the end of mail data must be indicated so that the command and reply dialog can be resumed. SMTP indicates the end of the mail data by sending a line containing only a ".".
BDAT - Binary Data
The BDAT verb takes two arguments. The first argument indicates the length, in octets, of the binary data chunk. The second optional argument indicates that this data chunk is the last.
Servers that offer the BDAT extension MUST continue to support the regular SMTP DATA command.
After all MAIL and RCPT responses are collected and processed, the message is sent using a series of BDAT commands. The BDAT command takes one required argument, the exact length of the data segment in octets. The message data is sent immediately after the trailing <CR> <LF> of the BDAT command line. Once the receiver-SMTP receives the specified number of octets, it will return a 250 reply code.
The optional LAST parameter on the BDAT command indicates that this is the last chunk of message data to be sent. The last BDAT command may have a byte-count of zero indicating there is no additional data to be sent. Any BDAT command sent after the BDAT LAST is illegal and MUST be replied to with a 503 "Bad sequence of commands" reply code. The state resulting from this error is indeterminate. A RSET command MUST be sent to clear the transaction before continuing.
DATA and BDAT commands cannot be used in the same transaction. If a DATA statement is issued after a BDAT for the current transaction, a 503 "Bad sequence of commands" MUST be issued.
QUIT
This terminates an SMTP connection. Multiple e-mail messages can be transferred during a single TCP/IP connection. This allows for more efficient transfer of e-mail. To start another e-mail message in the same session, simply issue another "MAIL" command
VRFY username - Verify
This command will request that the receiving SMTP server verify that a given e-mail username is valid. The SMTP server will reply with the login name of the user. This feature can be turned off in Sendmail because allowing it can be a security hole. VRFY commands can be used to probe for login names on a system.
EXPN aliasname - Expand mailing lists
EXPN - is similar to VRFY, except that when used with a distribution list, it will list all users on that list. This can be a bigger problem than the "VRFY" command since sites often have an alias such as "all".
AUTH mechanism [initial-response] - Authenticate
The AUTH command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTH command with a 504 reply.
This command is used to initiate a mail transaction in which the mail data is delivered to an SMTP server which may, in turn, deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument field contains a reverse-path and may contain optional parameters.
RSET - RESET
This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments.
HELP
This command causes the server to send helpful information to the client. The command may take an argument (any command name) and return more specific information as a response.
NOOP - No Operation
This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver sends an OK reply.
TURN
The TURN command may be used to reverse the roles of the two programs communicating over the transmission channel.
If program A is currently the sender SMTP and it sends the TURN command and receives an ok reply (250) then program A becomes the receiver SMTP.
If program B is currently the receiver SMTP and it receives the TURN command and sends an ok reply (250) then program B becomes the sender SMTP.
ETRN
As it stands, the TURN command will reverse the direction of the SMTP connection and assume that the remote host is being honest about what its name is. The security loophole is that there is no documented stipulation for checking the authenticity of the remote host name, as given in the HELO or EHLO command. As such, most SMTP and ESMTP implementations do not implement the TURN command to avoid this security loophole.
This has been addressed in the design of the ETRN command. This extended turn command was written to address this shortcoming. The security loophole is avoided by asking the server to start a new connection aimed at the specified client.
In this manner, the server has a lot more certainty that it is talking to the correct SMTP client. This mechanism can just be seen as a more immediate version of the retry queues that appear in most SMTP implementations. In addition, as this command will take a single parameter, the name of the remote host to start the queues for, the server can decide whether it wishes to respect the request or deny it for any local administrative reasons.
ATRN - Authenticated Turn
On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. Port 366 is reserved for On-Demand Mail Relay. The initial client and server roles are short-lived, as the point is to allow the intermittently connected host to request mail held for it by a service provider.
The provider has an On-Demand Mail Relay process listening for connections on the ODMR port. This process does not need to be a full SMTP server. It does need to be an SMTP client with access to the outgoing mail queues, and as a server implement the EHLO, AUTH, ATRN, and QUIT commands.
An MTA normally has a mail client component which processes the outgoing mail queues, attempting to send mail for particular domains, based on time or event (such as new mail being placed in the queue, or receipt of an ETRN command by the SMTP server component). The On-Demand Mail Relay service processes the outgoing queue not on a timer or new mail creation, but on request.
The On-Demand Mail Relay service has three states: an initial state, an authenticated state, and a reversed state. (Note that in the reversed state, commands are sent by the provider, not the customer.)
In the initial state, the provider is the server and the customer is the client. Three commands are valid: EHLO, AUTH, and QUIT.
The AUTH command is specified in [AUTH]. The AUTH command uses a [SASL] mechanism to authenticate the session. The session is not considered authenticated until a success response to AUTH has been sent.
For interoperability, implementations MUST support the CRAM-MD5 mechanism [CRAM]. Other SASL mechanisms may be supported. A site may disable CRAM-MD5 support if it uses more secure methods. The EXTERNAL mechanism [SASL] might be useful in some cases, for example, if the provider has already authenticated the client, such as during a PPP connection.
The authenticated state is entered after a successful AUTH command. Two commands are valid in the authenticated state: ATRN and QUIT.
Unlike the TURN command in [SMTP], the ATRN command optionally takes one or more domain names as a parameter. The ATRN command MUST be rejected if the session has not been authenticated. Response code 530 [AUTH] is used for this.
The timeout for this command MUST be at least 10 minutes to allow the provider time to process its mail queue.
An ATRN command sent with no domains is equivalent to an ATRN command specifying all domains to which the customer has access.
After the provider has sent a success reply to the ATRN command, the roles reverse, and the customer becomes the server, and the provider becomes the client.
After receiving the success response to ATRN, the customer sends a standard SMTP initial greeting line. At this point normal SMTP [SMTP, ESMTP] commands are used. Typically the provider sends EHLO after seeing the customer's greeting, to be followed by MAIL FROM and so on.
Because access to the On-Demand Mail Relay server is only useful with a prior arrangement between the parties (so the provider is the target of MX records for the customer's domains and thus has mail to relay), it may be useful for the provider to restrict access to the On-Demand Mail Relay port. For example, the ODMR server could be configurable, or a TCP wrapper or firewall could be used, to block access to port 366 except within the provider's network.
STARTTLS - Start Transport Layer Security
The STARTTLS keyword is used to tell the SMTP client that the SMTP server is currently able to negotiate the use of TLS. It takes no parameters.
After the client gives the STARTTLS command, the server responds with one of the following reply codes:
220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason
If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.
A publicly referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.
After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection.
All that is required to enter the commands listed above is a telnet connection to your e-mail server.
There are restrictions on the order in which these commands may be used.
A session that will contain mail transactions MUST first be initialized by the use of the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization.
An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued.
The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client.
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time during a session, or without previously initializing a session. SMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands.
The MAIL command begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted by the RSET (or a new EHLO) command. There may be zero or more transactions in a session. MAIL MUST NOT be sent if a mail transaction is already open, e.g., it should be sent only if no mail transaction had been started in the session, or if the previous one successfully concluded with a successful DATA command, or if the previous one was aborted with a RSET.
If the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state. If the commands in a transaction are out of order to the degree that they cannot be processed by the server, a 503 failure reply MUST be returned and the SMTP server MUST stay in the same state.
The last command in a session MUST be the QUIT command. The QUIT command cannot be used at any other time in a session, but SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted.
The following paragraphs on LMTP, Ph, Pipelining, and DSN may help you with the concepts behind these features.
LMTP
The common practice of invoking a delivery agent with the envelope address(es) as command-line arguments, then having the delivery agent communicate status with an exit code has three serious problems: the agent can only return one exit code to be applied to all recipients, it is difficult to extend the interface to deal with ESMTP extensions such as DSN [DSN] and ENHANCEDSTATUSCODES, and exits performed by system libraries due to temporary conditions frequently get interpreted as permanent errors.
The LMTP protocol causes the server to return, after the final "." of the DATA command, one reply for each recipient. Therefore, if the queue manager is configured to use LMTP instead of SMTP when transferring messages to the delivery agents, then the delivery agents may attempt delivery to each recipient after the final "." and individually report the status for each recipient.
In the LMTP protocol, there is one additional restriction placed on the DATA command, and one change to how replies to the final "." are sent.
The additional restriction is that when there have been no successful RCPT commands in the mail transaction, the DATA command MUST fail with a 503 reply code.
The change is that after the final ".", the server returns one reply for each previously successful RCPT command in the mail transaction, in the order that the RCPT commands were issued. Even if there were multiple successful RCPT commands giving the same forward-path, there must be one reply for each successful RCPT command.
Ph Nameserver
The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. The Ph service is built around an information model, a client command language and the server responses.
At its simplest the Ph database can be thought of as a computer-resident "phone book". However, it can be used to collect arbitrary information about people, and in response to a query about an object named in the database, return information about that entity. It is in short a nameserver for people and objects. It was designed to keep a relatively small amount of arbitrary information about a relatively large number of people or things, and provide access to that information over the Internet. In order to structure the information the manager of the database has to decide which views to present of the real-world objects that are to be represented in the database. Each view is then composed of a number of fields and their values. To support this concept Ph has the notion of named information, e.g., categorizing information into what are called fields and assigning descriptive names to those fields.
Pipelining
Once the client SMTP has confirmed that support exists for the pipelining extension, the client SMTP may then elect to transmit groups of SMTP commands in batches without waiting for a response to each individual command. The EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP commands can only appear as the last command in a group since their success or failure produces a change of state which the client SMTP must accommodate. (NOOP is included in this group so it can be used as a synchronization point.)
Additional commands added by other SMTP extensions may only appear as the last command in a group unless otherwise specified by the extensions that define the commands.
The actual transfer of message content is explicitly allowed to be the first "command" in a group. That is, a RSET/MAIL FROM sequence used to initiate a new message transaction can be placed in the same group as the final transfer of the headers and body of the previous message.
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group. For example, if none of the RCPT TO recipient addresses were accepted the client must then check the response to the DATA command -- the client cannot assume that the DATA command will be rejected just because none of the RCPT TO commands worked. If the DATA command was properly rejected the client SMTP can just issue RSET, but if the DATA command was accepted the client SMTP should send a single dot.
DSN
An SMTP client wishing to request a DSN for a message may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword DSN, then the Delivery Status Notification extension is supported.
Ordinarily, when an SMTP server returns a positive (2xx) reply code in response to a RCPT command, it agrees to accept responsibility for either delivering the message to the named recipient, or sending a notification to the sender of the message indicating that delivery has failed. However, an extended SMTP (ESMTP) server which implements this service extension will accept an optional NOTIFY parameter with the RCPT command. If present, the NOTIFY parameter alters the conditions for generation of Delivery Status Notifications. The ESMTP client may also request whether the entire contents of the original message should be returned (as opposed to just the headers of that message), along with the DSN.
In general, an ESMTP server which implements this service extension will propagate Delivery Status Notification requests when relaying mail to other SMTP-based MTAs which also support this extension, and make a "best effort" to ensure that such requests are honored when messages are passed into other environments.
Information for these web pages came from:
Sendmail Installation and Operations Guide
Sendmail Source tarball - Readme's and man pages
Sendmail book by O'reilly
docs.sun.com
Relevant RFC's
Hands on Experience