An interaction between an SMTP client and an SMTP server is what is known as an SMTP session. The client communicates by issuing commands made up of alphabetic characters. In its answers, the server uses numerical codes. We'll go in-depth about this today. You'll learn which SMTP instructions are still in use and which are no longer. We'll also clarify which answer codes go with each command.

Essential SMTP instructions in possible usage order

SMTP is an internet protocol for sending messages between servers. Each SMTP command specifies a specific action to be taken during the three steps that make up an SMTP session:

  • TCP connection establishment using a handshake.
  • Email manipulations include email transfers.
  • The act of terminating a TCP connection.

We decided to list the SMTP commands under this flow as a result.

HELO/EHLO

The SMTP session dialogue is started with the HELO command. The client introduces itself and thanks the server. HELO is often assigned with an argument that contains the IP address or domain name of the SMTP client.

For instance,

For servers that support the SMTP service extensions, EHLO is an alternate to HELO (ESMTP). The server will respond with an error message if ESMTP is not supported.

For instance,

In any situation, the SMTP client MUST issue the instruction HELO or EHLO before starting a mail transfer.

MAIL FROM

A mail transfer is started with the MAIL FROM command. MAIL FROM contains a sender mailbox as proof (reverse-path). The reverse path may be null for some reporting message kinds, such as non-delivery notifications. Additionally, optional options may be supplied.

MAIL FROM "test@client.net" is an example.

RCPT TO

The receiver is specified by the RCPT TO instruction. RCPT TO has a destination mailbox as proof (forward-path). If there are several recipients, RCPT TO will be used to identify each individual.

RCPT TO "user@recipient.net" for instance.

DATA

The client requests authorization from the server to transfer the mail data using the DATA command. The client starts delivering the email's contents line by line after receiving the response code 354, which indicates consent. The date, from the header, and topic line, to the header, attachments, and body content are all included in this.

The mail data transfer is finished when there is a period (".") at the end of the line. The last line is answered by the server.

Example:

NOOP

The primary purpose of the NOOP command is to see if the server can respond. I received a "250 OK" response.

Example:

HELP

The client can ask the server for a list of commands it can execute by using the HELP command. HELP can be paired with a defense (a specific command). If the server can accommodate this, it will respond to the request by providing the data.

Example:

EXPN and VRFY

A mailbox in the argument is checked to see if it exists on the local host using VRFY. The user's mailbox and maybe their entire name are included in the server response.

Example:

A mailing list in the input is checked to see if it exists on the local host using EXPN. The members of the receivers will be specified in the affirmative response.

Example:

The user's mailbox and the numerical code are separated by a hyphen (-), signifying that the response continues on the following line.

SMTP authentication is implemented via VRFY and EXPN. They help do an internal audit of the server. However, these commands are viewed as a security risk. Spammers can use them to gather reliable email addresses from the server. As a result, message systems either implement the necessary safeguards or turn off the directives.

RSET

The SMTP connection is restored to its initial state via the RSET command. All of the state tables and buffers are deleted (both sender and recipient). Only the server's positive response (250) is returned to RSET. The SMTP connection is open and available for a fresh mail transaction at the same moment.

Example:

QUIT

The QUIT command sends the SMTP session's termination request. The client ends the SMTP connection after the server returns a response code of 221. This instruction terminates the broadcast channel after specifying that the receiver MUST respond with "221 OK."

Instance:

Some SMTP servers may handle extended SMTP commands

STARTTLS

The TLS handshake for a secure SMTP session is initiated with the STARTTLS command. The SMTP protocol is restarted with STARTTLS. The SMTP client should send HELO or EHLO to start the session after receiving response 220 from the server. The client must determine whether to continue the SMTP session in the event of a negative response (503 5.5 2 send hello first, 454 tls not available).

Example:

AUTH

To authenticate the client to the server, use the AUTH command. It makes use of an argument that specifies the login methods and security levels PLAIN, LOGIN, and CRAM-MD5. Once the server has given an affirmative response, the session is deemed authenticated. Read the SMTP authentication blog post for more information on this.

Example:

ATRN

The TURN command was superseded by the ATRN command. The connection between the internal and external SMTP servers was reversed using it (sender and receiver). TURN was deprecated because it lacked authentication. This issue is not present with ATRN. Additionally, it supports IP addresses that are assigned dynamically.

Example:

BDAT

To submit mail contents, use the BDAT command. It might serve as a replacement for the DATA command. The BDAT makes two defenses. The first one specifies the data chunk's size in octets. The second one signifies the end of the data piece. As it is in the DATA command, there is no need for a period to end the mail transfer. A lot of Microsoft Exchange Server users BDAT. DATA is necessary to support commands for all servers at the same time.

Example:

ETRN

The ETRN command is used to initiate the processing of an SMTP queue for a particular server host.

Example:

Private-use SMTP instructions

Through a bilateral agreement, the client and server can employ private-use SMTP commands. These extensions should begin with "X" and are for proprietary services. They cannot be standardized or registered. Here are a few examples:

  • XADR: releases channel status when an address is matched (how an address is routed internally)
  • XCIR: updates the circuit checking facility's status.
  • Released by XSTA is the status of the number of messages in channel queues.
  • If a compiled configuration and character set is being used, XGEN reports the state.

Expiring SMTP commands

There are numerous outdated places online where you can find out-of-date SMTP commands. Here is a list of the commands you can no longer use so that you don't spend your time with invalid options:

  • SEND
  • SOML
  • SAML
  • RELAY
  • TLS
  • TURN

Response codes for SMTP

A three-digit code is used by the SMTP server to respond to the client. Each digit has a unique meaning:

  • First (2 to 5) - indicates whether the request has been accepted, is incomplete, or has been declined.

  • Second (from 0 to 5) - indicates the type of error (syntax, information, connections, mail system, or unspecified (two options)).

  • Third (0 to 5) - provides the most detailed description (together with textual explanation)

The numerical code is followed by text intended for a human user to understand. Different servers can use a different textual description of the response, but the numerical code remains constant. So, here's what your SMTP server can say in response:

101

Server connection error (wrong server name or connection port)

211

System status (response to HELP)

214

Help message (response to HELP)

220

The server is ready (response to the client’s attempt to establish a TCP connection)

221

The server closes the transmission channel

235

Authentication successful (response to AUTH)

250

The requested command is completed. As a rule, the code is followed by OK

251

User is not local, but the server will forward the message to

252

The server cannot verify the user (response to VRFY). The message will be accepted and attempted for delivery

334

Response to the AUTH command when the requested security mechanism is accepted

354

The server confirms mail content transfer (response to DATA). After that, the client starts sending the mail. Terminated with a period ( “.”)

421

The server is not unavailable because it closes the transmission channel

422

The recipient’s mailbox has exceeded its storage limit

431

File overload (too many messages sent to a particular domain)

441

No response from the recipient’s server

442

Connection dropped

446

internal loops has occurred

450

Mailbox unavailable (busy or temporarily blocked). Requested action aborted

451

The server aborted the command due to a local error

452

The server aborted the command due to insufficient system storage

454

TLS not available due to a temporary reason (response to STARTTLS)

455

Parameters cannot be accommodated

471

Mail server error due to the local spam filter

500

Syntax error (also a command line may be too long). The server cannot recognize the command

501

Syntax error in parameters or arguments

502

The server has not implemented the command

503

Improper sequences of commands (503 5.5 2 send hello first)

504

The server has not implemented a command parameter

510

Invalid email address

512

A DNS error (recheck the address of your recipients)

523

The total size of your mailing exceeds the recipient server limits

530

Authentication problem that mostly requires the STARTTLS command to run

535

Authentication failed

538

Encryption required for a requested authentication mechanism

541

Messages rejected by the spam filter

550

Mailbox is unavailable. The server aborted the command because the mailbox was not found or for policy reasons. Alternatively: Authentication is required for relay

551

Users not local. The will be specified

552

The server aborted the command because the mailbox is full

553

Syntactically incorrect mail address

554

The transaction failed due to an unknown error or No SMTP service here as a response to the client’s attempts to establish a connection

555

Parameters not recognized/ not implemented (response to MAIL FROM or RCPT TO)

Command-response

Some codes are command-specific, as you may have noted above. Only three of them---numbers 500, 501, and 421---can actually constitute a response to any SMTP command. Others can be divided into positive and bad categories (code 354 can be considered as an intermediate response). Let's check the commands they can use as references.

SMTP handshake (establishing a connection)

Positive:

  • 220 Negative:
  • 554

STARTTLS

Positive:

  • 220

EHLO or HELO

Postive:

  • 250 Negative:
  • 502 (response to EHLO for old-time servers)
  • 504
  • 550

AUTH

Positive:

  • 235
  • 334 Negative:
  • 530
  • 535
  • 538

MAIL FROM

Positive:

  • 250 Negative:
  • 451
  • 452
  • 455
  • 503
  • 550
  • 552
  • 553
  • 555

RCPT TO

Positive:

  • 250
  • 251 Negative:
  • 450
  • 451
  • 452
  • 455
  • 503
  • 550
  • 551
  • 552
  • 553
  • 555

DATA

Positive:

  • 250
  • 354 (intermediate response) Negative:
  • 450
  • 451
  • 452
  • 503
  • 550 (rejection for policy reasons)
  • 552
  • 554

RSET

Positive:

  • 250

VRFY

Positive:

  • 250
  • 251
  • 252 Negative:
  • 502
  • 504
  • 550
  • 551
  • 553

EXPN

Positive:

  • 250
  • 252 Negative:
  • 502
  • 504
  • 550

HELP

Positive:

  • 211
  • 214 Negative:
  • 502
  • 504

NOOP

Positive:

  • 250

QUIT

Positive:

  • 221

The list of common answer codes looks like this. It should be noted that some SMTP servers can provide additional three-digit codes. The initial digit, which must be within the range of 2 to 5 inclusive, must be interpreted by the SMTP client in this situation. It indicates the core of the reply (successful or not).

Illustration of an SMTP session

Let's now see an illustration of an SMTP session flow. Both a successful and unsuccessful transaction will be shown to you.

A successful transaction with verification

In this instance, the client got the 550 error code informing them that one of the receivers was unavailable. Nevertheless, unlike in the example below, the transaction was not abandoned.

Terminated transaction

Here is a terminated transaction example:

Advantages of employing a bogus SMTP server

An email is still at the beginning of its trip once it has reached the sender's SMTP server. The email must get to the recipient's SMTP server, which then forwards it to the IMAP/POP3 server, before arriving in the recipient's mailbox. And before letting the email through, each server implements authentication. It is better to cut twice this manner while testing email sending. And for this reason, development teams choose a phony SMTP server.

MailSlurp makes sending emails a lot simpler and lets you evaluate how your application distributes messages. It is a tool to send test emails using SMTP, not to test SMTP servers. Additionally, it is a crucial item on the email testing checklist.

Here's how it appears in actual use.

Step 1

The sender's email client authenticates with the SMTP server of MailSlurp (mx.mailslurp.com)

The required credentials, including the port and authentication mechanism, are all readily available. For the majority of popular programming languages and web frameworks, integrations are also available and ready to use. To use these, simply copy and paste the codes into your app.

Step 2

The message is sent from the SMTP server to the POP3 server

No problems with incorrect configuration, authentication, or any kind of spamming of actual people are anticipated.

Step 3

Access your Demo inbox, where the message is immediately visible (if your app functions properly, of course).

Therefore, the primary advantage of a bogus or dummy SMTP server is that it does not respond negatively to any SMTP command from the client. Read the MailSlurp getting started guide for additional information on this.