An SMTP conversation, step by step

In the previous post, we mapped the journey of our welcome email to reader@example.net. Our application handed it to SES through the HTTPS API. SES then connected to the recipient’s mail server using SMTP.

Let’s zoom into that SMTP connection. What do the sending and receiving mail servers actually say to each other?

We’ll follow the same welcome email. On this connection, SES takes the sending role and the recipient’s mail system takes the receiving role. Our application’s API call is already behind us.

The exchanges below are illustrative, not a capture of SES traffic. We’ll call the sending server outgoing.example.org and the receiving server incoming.example.net. Both names are fictional. S: labels what the sending server says; R: labels the receiving server’s replies. These labels are annotations, not part of SMTP. Some message headers and protocol extensions are omitted to keep the exchange easy to follow.

Who speaks first?

The sending server opens the connection, but the receiving server speaks first:

R: 220 incoming.example.net ready

In plain English: “You’ve reached the receiving mail server. We can begin.”

The number is the reply code. The text after it is a human-readable explanation; different servers can phrase it differently.

Who is connecting?

The sending server introduces itself:

S: EHLO outgoing.example.org
R: 250 incoming.example.net hello

EHLO says: “Hello, I’m outgoing.example.org. What SMTP extensions do you support?” The 250 reply says this greeting succeeded. A real reply can also list supported extensions; we’ll leave that list in the optional notes below.

The greeting identifies the sending server. It hasn’t supplied an email address or sent the welcome message yet.

Who is this email for?

First, the sending server starts a mail transaction and supplies the address for delivery-failure notifications:

S: MAIL FROM:<bounces@example.org>
R: 250 Sender accepted

MAIL FROM says: “For this message, send delivery failures to bounces@example.org.” The receiver accepts that return address for the transaction.

Then comes the recipient:

S: RCPT TO:<reader@example.net>
R: 250 Recipient accepted

RCPT TO says: “This message is for reader@example.net.” The receiver agrees to accept that recipient for this transaction.

Here’s the interesting part: the receiver has accepted the recipient without seeing the subject or body. So far, it has only the delivery instructions. The welcome email itself is still on the sending side.

When does the actual message arrive?

The sender asks to send the message:

S: DATA
R: 354 Send message, end with a line containing only a dot

DATA says: “I’m ready to send the message itself.” The 354 reply means “Go ahead.” It invites the sender to continue; it does not accept the completed message.

Now the sender supplies the headers and body:

S: From: Welcome <hello@example.org>
S: To: reader@example.net
S: Subject: Welcome
S:
S: Welcome to the application.
S: .

The blank line separates the headers from the body. The line containing only a dot tells the receiver: “That’s the end of the message.” The dot is a protocol marker, not part of the reader’s email.

Notice that MAIL FROM used bounces@example.org, while the message’s From: header uses hello@example.org. One belongs to the delivery instructions; the other is part of the message the reader sees. The next post explores why email has these two layers of addressing.

What does the final acceptance mean?

Only after that terminating dot does the receiver answer for the complete message:

R: 250 Message accepted

In plain English: “I’ve accepted the message and taken responsibility for delivering it or passing it onward.”

Compare the two important replies: the earlier 250 after RCPT TO accepted a recipient; this 250 after the message data accepts the message itself. The receiver could still have rejected the message at this final step, even after accepting its recipient.

As we saw in the previous post, acceptance doesn’t prove inbox placement or reading. It tells us this SMTP handoff succeeded.

The sender can then close the conversation:

S: QUIT
R: 221 Closing connection

QUIT says: “We’re finished with this connection.”

What if the receiver rejects the recipient?

Suppose the same transaction gets a different answer to RCPT TO:

S: RCPT TO:<reader@example.net>
R: 550 No such mailbox

In this illustrative failure, the receiver refuses the recipient. The sender cannot proceed to send the message for that rejected recipient. If this was the only recipient, there is no accepted recipient to continue with DATA.

The reply’s position tells us where the conversation stopped: the subject and body haven’t been sent. That’s why an SMTP reply is most useful when we know which step it answers.

Optional: look closer or try it locally

You now have the basic conversation. The sections below are for readers who want to inspect its wire format or send a message to a local capture server.

R: 250-incoming.example.net
R: 250 SIZE 1048576

docker run --rm --name smtp-capture \
  -p 127.0.0.1:1025:1025 -p 127.0.0.1:8025:8025 \
  axllent/mailpit:v1.20.3

require 'socket'
require 'time'

def reply(socket, expected)
  loop do
    line = socket.gets or raise 'Connection closed'
    puts line
    raise "Unexpected reply: #{line}" unless line.start_with?(expected)
    break unless line[3] == '-'
  end
end

def command(socket, text, expected)
  socket.write(text + "\r\n")
  reply(socket, expected)
end

socket = TCPSocket.new('127.0.0.1', 1025)
begin
  reply(socket, '220')
  command(socket, 'EHLO outgoing.example.org', '250')
  command(socket, 'MAIL FROM:<bounces@example.org>', '250')
  command(socket, 'RCPT TO:<reader@example.net>', '250')
  command(socket, 'DATA', '354')

  headers = [
    "Date: #{Time.now.rfc2822}",
    'From: Welcome <hello@example.org>',
    'To: reader@example.net',
    'Subject: Welcome'
  ]
  socket.write(headers.join("\r\n") +
               "\r\n\r\nWelcome to the application.\r\n.\r\n")
  reply(socket, '250')
  command(socket, 'QUIT', '221')
ensure
  socket.close
end

command(socket, 'RCPT TO:broken', '501')

References

• RFC 5321, sections 3.3, 4.1, 4.2 and 4.5.2 — mail transactions, commands, replies and dot-stuffing.
• RFC 1870 — the SIZE extension.
• RFC 5322, sections 2.1 and 3.6 — message structure and headers.
• Mailpit documentation and v1.20.3 source — local capture and SMTP implementation.