SMTP - Simple Mail Transfer Protocol

Within the Internet, E-Mail is delivered by having the source machine establish a TCP connection to port 25 of the destination machine. Listening to this port is an E-Mail daemon that "speaks" SMTP. This daemon accepts incoming connections and copies messages from them into the appropriate mailboxes. If a message cannot be delivered, an error report containing the first part of the undeliverable message is returned to the sender.

SMTP is a simple ASCII (text) protocol. After establishing the TCP connection to port 25, the sending machine, operating as the client, waits for the receiving machine, operating as the server, to talk first. The server starts by sending a line of text giving its identity and telling whether or not it is prepared to receive E-Mail. If it is not, the client releases the connection and tries again later. If the server is willing to accept E-Mail, the client announces whom the E-Mail is coming from and whom it is going to. If such a recipient exists at the destination, the server gives the client the go-ahead message. Then the client sends the message and the server acknowledges it. No checksums are generally needed because TCP provides a reliable byte stream. If there is more E-Mail, that is now sent. When all the E-Mail has been exchanged in both directions, the connection is released.

Even though the SMTP protocol is well defined (by RFC 821), a few problems can still arise.
One problem relates to message length. Some older implementations cannot handle messages exceeding 64KB.
Another problem relates to timeouts. If the client and server have different timeouts, one of them may give up while the other is still busy, unexpectedly terminating the connection.
Finally, in rare situations, infinite mailstorms can be triggered. For example, if host 1 holds mailing list A and host 2 holds mailing list B and each list contains an entry for the other one, then any message send to either list will generate a never-ending amount of E-Mail traffic.

To get around some of these problems, extended SMTP (ESMTP) has been defined in RFC 1425. Clients wanting to use it should send an EHLO message instead of HELO initially. If this is rejected, then the server is a regular SMTP server, and the client should proceed in the usual way. If the EHLO is accepted, then new commands and parameters are allowed. The standardization of these commands and parameters is an ongoing process.