Build the SMTP envelope

Once EHLO is done, the client builds the envelope. Two commands do it: MAIL FROM and RCPT TO.

MAIL FROM sets the reverse path. That’s the address that receives bounces if delivery fails later. One special case: a bounce message itself uses an empty reverse path, written <>. Otherwise two broken mailboxes could bounce at each other forever.

Each RCPT TO adds one recipient. Sending to three people means three RCPT TO commands.

C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 Accepted

Every command gets its own reply. The client waits for each 250 before moving on.

The envelope is not the header

I’ll say this often in this course because it causes so much confusion. The From and To you see in a mail app are inside the message. The envelope is what we just built with SMTP commands.

When the question is “where did the server try to deliver this?”, look at the SMTP transaction or the delivery logs. Never at the visible headers.

Each recipient is decided alone

The server can accept one recipient and reject another, before it has seen a single byte of the message:

C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Sender accepted
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Recipient accepted
C: RCPT TO:<[email protected]>
S: 550 5.1.1 Mailbox does not exist

Marco left the company. The client can still continue with DATA and the message reaches Sara. But it must remember that Marco was rejected. He is not in the accepted set, and the sender should tell me about it.

If every recipient is rejected, there’s nothing to send. The client should not issue DATA at all.

Extension parameters

MAIL FROM can carry extra parameters, like SIZE=2381 to declare the message size up front, or SMTPUTF8 for international addresses. RCPT TO can carry recipient-specific options.

The rule from the previous lesson applies: only send parameters the server advertised in its EHLO reply.

Accepted is not delivered

A 250 to RCPT TO means “I’ll take mail for this address”. It doesn’t mean the message is in the mailbox.

The server can still reject the content after DATA, because it’s too big or looks like spam. Or it can accept it and hit a problem later, then send a bounce to the reverse path. That’s why the reverse path has to be a real, monitored address.

Try extending the second transcript with DATA, a three-line message, and the final 250. Then list exactly which recipients the server accepted responsibility for.