How SMTP and Internet Email Systems Work

Internet E-mail is transferred between systems using a protocol known as SMTP, or the Simple Mail Transfer Protocol. The basic functionality of SMTP is described in RFC 821. Additional functionality has been added over the years, but in essence, RFC 821 describes what happens for most E-mail transfers.

SMTP is what is known as a client-server protocol. A system sending E-mail is an SMTP client. A system receiving E-mail is an SMTP server. Some software implements both the client and server functionality in one package. These are generally full-featured MTAs, or Mail Transfer Agents. Some software implements only SMTP client functionality. These systems are generally end-user MUAs or Mail User Agents with the ability to send mail to an MTA for handling.

When an SMTP client wishes to send E-mail to an SMTP server, it usually follows these steps:

• decides where to send the mail. An MTA will generally look at the destination E-mail address, select the domain portion (after the @), consult the Domain Name System (DNS) to discover which system is responsible for receiving mail for that domain, and then will open a TCP socket connection to port 25 on the server. An MUA on the other hand is normally configured with the name of a single MTA to which it forwards all E-mail. It will just open a TCP socket connection to that server, usually on port 25. A TCP socket is just a 2-way communication channel that systems use to transmit information over TCP/IP networks like the Internet.
• tells the server it’s name. This information is not checked by the server, normally.
• tells the server the E-mail address of the sender. This information is not checked by the server, normally.
• tells the server, one at a time, the E-mail addresses the message is going to. In the case of an MTA/MTA conversation, the client will only send the addresses this particular server is responsible for. An MTA may open many connections to many different servers to deliver the same message if recipients are on different servers.
• finally, sends the actual E-mail. This includes all the headers, including To: and From:, that you see in your mail client. The server makes no use of this information and normally doesn’t even “look” at it – the message is simply the payload. All sender and recipient information is exchanged outside the message itself, and is often referred to as the “envelope”.
• informs the server that the message is complete
• waits for confirmation that the server has committed the message to disk
• closes the TCP socket and considers the message to be Sent

The receiving SMTP server then processes the message by doing the following:

• adds a new Received: header to the top of the message containing the server name, the date and time, and usually some information about the remote system. The only information in this header that can be trusted is the TCP/IP address of the SMTP client system, and that can only be trusted by users who trust this particular SMTP server. They may also trust the date and time if that information is known to be kept accurate on the SMTP server (most servers actually add this while receiving the message, but you get the idea).
• add some other headers, at the discretion of the server. Some servers generate missing Message-ID:, From:, To:, Apparently-To:, or other headers to make the message a more valid RFC 822 message. Some don’t.
• decides what to do with the E-mail. This may involve forwarding it on to other SMTP servers, or performing delivery to a local mail store. “Local delivery” in this context may also include forwarding the message to one or more different E-mail addresses, or injecting the message into a mailing list exploder which sends a new message back to the MTA with the full list of mailing list recipients.

IMPORTANT POINTS

• the contents of an E-mail message, including the To: and From: headers, are not used by Internet E-mail servers and are not necessarily the addresses the mail came from or was sent to
• the entire contents of an E-mail message, except portions of the Received: header your own SMTP server added to it, can be forged. Some information in the Received: header your own SMTP server adds can be forged, since it relies on what the SMTP client system tells it.
• the envelope sender address, which is where bounces get delivered, is often not authenticated and can be easily forged
• the envelope recipient addresses of a message are the sole information used for deliverying E-mail. These addresses are rarely added to the contents of any message header by any intermediate system and can only be determined by where the E-mail ends up, or by examining the debugging logs generated on intermediate mail servers