The Internet Engineering Task Force provides RFC2821, which is an excellent reference for understanding the details of email transport protocols.  In order for email administrators to know what they are up against, in thwarting spammers, RFC2821 should “the” primer to ingest.  I’m sure spammers have this document memorized, before embarking on their spamming offensives.  To know the enemy, we must read what they read.

RFC2821 provides a rudimentary diagram, which powerfully explains the SMTP Model.  A simple explanation sets the stage for a basic SMTP understanding.  Once an Administrator grasps the basic concepts, then more of the details become easier to follow.

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server

“When an SMTP client has a message to transmit, it establishes a two-way transmission channel to an SMTP server.  The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.

The means by which a mail message is presented to an SMTP client, and how that client determines the domain name(s) to which mail messages are to be transferred is a local matter, and is not addressed by this document.  In some cases, the domain name(s) transferred to, or determined by, an SMTP client will identify the final destination(s) of the mail message.  In other cases, common with SMTP clients associated with implementations of the POP [3, 26] or IMAP [6] protocols, or when the SMTP client is inside an isolated transport service environment, the domain name determined will identify an intermediate destination through which all mail messages are to be relayed.

SMTP clients that transfer all traffic, regardless of the target domain names associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable.  Fully-capable SMTP implementations, including the relays used by these less capable ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification. ”

RFC2821 should be read in its entirety.