Protocol for Simple Mail Transfer

The Simple Mail Transfer Protocol (in English: Simple Mail Transfer Protocol or SMTP) is a network protocol used for exchange of email messages between computers or other devices (PDAs, mobile phones, printers, etc.). It is found in the application layer of the OSI model, the last of this model, in which the interface between the communication applications and the network that transmits the messages is arranged. It was initially defined in August 1982 by RFC 821 (for transfer) and RFC 822 (for message), two official Internet standards that were respectively superseded by RFC 2821 and RFC 2822, later superseded by RFC standards. 5321 and RFC 5322.

The operation of this protocol occurs online, so it operates in email services. However, it has some limitations regarding the reception of messages on the destination server (received message queue), so it normally runs in relation to others, such as POP3 or IMAP, giving SMTP the specific task of sending emails. and delegating that of receiving them to the aforementioned protocols.

History

In 1982, the first system based on SMTP was designed to exchange emails on the ARPANET, defined in the request for comments RFC 821 and RFC 822. The first one defines this protocol and the second one defines it. form of the message that this protocol should carry.

The structure of SMTP is based on the client-server model, where a client sends a message to one or more servers to receive a response. The communication between the client and the server consists entirely of lines of text made up of Unicode characters, although originally it was limited to ASCII characters. The maximum size allowed for these lines is 1000 characters.

Server responses consist of a three-digit numeric code, followed by explanatory text. The number is intended for automatic processing of the response, while the text allows a human to interpret the response.

In the SMTP protocol, all orders, replicas or data are lines of text, they are delimited by the CRLF character. All replicas have a numerical code at the beginning of the center line.

Mail processing model

Mail processing model.

Email is submitted by a mail client (MUA, mail user agent) to a mail server (MSA, mail submission agent) using SMTP over port 587. Most mail providers still allow sending over port 25. From there, the MSA delivers the mail to its mail transfer agent, better known as the MTA (Mail Transfer Agent). Mail Transfer Agent). On some occasions, these two agents are different cases, although it should be noted that they come from the same software from which they were launched, only that they present different options within the same machine.

The local processing that occurs can be performed on a single machine or split between several applications; in this second case, the processes involved can share files; here SMTP is used for the transfer of messages internally, with each of the hosts configured to use the next application as a fancy host. In order to achieve the location of the target server, the split MTA has to use the Domain Name System (DNS) to achieve the lookup of the internal mail exchange record known as the MX record for the recipient domain (the part of the address to the right). It is at this point that the returned MX record contains the name of the target host.^{[citation needed]}

The MTA then joins the exchange server as an SMTP client. Once MX accepts the incoming message, it in turn gives it to a mail delivery agent (MDA) to then be taken to local mail delivery. The MDA, in addition to delivering messages is also capable of saving messages in a mailbox format, and mail reception can be performed using many computers. There are two ways an MDA can deliver messages: either by sending them directly to storage, or by forwarding them over a network using SMTP. Once delivered to the local mail server, said mail is stored for batch retrieval. Its retrieval is achieved through end-user applications, known as email clients, using the Internet Message Access Protocol (IMAP), this protocol that facilitates both access to send and handling of stored mail.

Ports

Server administrators can choose whether clients use TCP port 25 (SMTP) or port 587 (Presentation) to relay outgoing mail to an initial mail server. The specifications and many servers support both. Although some servers support port 465 for legacy secure SMTP in violation of the specifications, it is preferable to use the standard ports and standard SMTP commands in accordance with RFC 3207, if a secure session is to be used between the client and the server.

Some servers are configured to deny all relaying on port 25, but valid users authenticating on port 587 can relay mail to any valid address.^{[citation required]} Some Internet Service Providers intercept port 25, redirecting traffic to their own SMTP server, regardless of the destination address. This means that it is not possible for your users to access an SMTP server outside of the ISP's network through port 25.

Some SMTP servers support authenticated access on port other than 587 or 25 to allow users to connect to them even if port 25 is blocked, but 587 is the standard port and widely supported by users to send mail new. Microsoft Exchange Server 2013 SMTP can listen on ports 25, 587, 465, 475, and 2525, depending on the server and if the roles are combined on a single server.^{[citation required]} Ports 25 and 587 are used to provide client connectivity to the transport service on the front end of the Client Access Server (CAS) role. Ports 25, 465, and 475 are used by the Mailbox Transport service. However, when the mailbox role is combined with the CAS role on a single server, port 2525 is used by the SMTP mailbox role from the CAS front-end transport service, CAS, while it continues to use Port 25. Port 465 is used by the Mailbox Transport service to receive proxy client connections from the CAS role. Port 475 is used by the Mailbox role to communicate directly with other Mailbox roles, transferring mail between the Mailbox Transport Submission Service and the Mailbox Transport Delivery Service.

Protocol Description

SMTP. An SMTP transaction is made up of three command/response sequences (see example below).

They are:

• MAIL FROM: command to set the return address, also known as Return-Path, sender or envelope. This is the address for farewell messages.
• RCPT TO: command, to set a recipient of this message. This mandate can be issued several times, one for each recipient. These addresses are also part of the envelope.
• DATA: to send the text message. This is the content of the message, rather than its wrapping. It consists of a message header and the body of the message separated by a blank line. DATA is actually a command group, and the server responds twice: once for the proper data command, to recognize that it is ready to receive the text, and the second time after the final sequence of the data, to accept or reject the entire message.

Simple summary of how the SMTP protocol works

• When a customer establishes a connection to the SMTP server, wait for the SMTP server to send a message “220 Service ready” or “421 Service non available”.
• Send a HEL from the client. With this the server is identified. This can be used to check whether it was connected to the correct SMTP server.
• The customer starts the mail transaction with the order MAIL FROM. As an argument of this order you can pass the email address to which the server will notify any error in sending the mail (for example, MAIL FROM: prescription@host0). Then if the server checks that the origin is valid, the server responds “OK250”.
• We've already told the server that we want to send an e-mail, now we have to tell who. The order for this is RCPT TO: backwards. You can send as many RCPT orders as email recipients we want. For each recipient, the server will answer “OK250” or “550 No such user here”if you don't find the recipient.
• Once all the CPTs are sent, the customer sends an order DATA to indicate that the contents of the message are then sent. The server responds “354 Start mail input, end with θCRLF. ≤2 This indicates to the customer how to notify the end of the message.
• Now the client sends the body of the message, line to line. Once finished, it is finished with a ≥CRLF-give. (the last line will be a point), to which the server will answer “OK250”or an appropriate error message.
• After shipping, the customer, if you do not have to send more mails, with the order QUIT Cut the connection. You can also use the order TURN, so the client becomes the server, and the server becomes a client. Finally, if you have more messages to send, repeat the process until you complete them.

The SMTP server may support the extensions defined in RFC 1651, in this case the HELO command can be replaced by the EHLO command, whereupon the server will reply with a list of supported extensions. If the server does not support the extensions, it will reply with a "500 Syntax error, command unrecognized" message.

Commands

• HELO, to open a session with the server
• EHLO, to open a session, in case the server supports extensions defined in the RFC 1651
• MAIL FROM, to indicate who sends the message
• RCPT TO, to indicate the recipient of the message
• DATA, to indicate the beginning of the message, will end when there is a line only with a point.
• QUIT, to close the session
• RSET Aborts the ongoing transaction and erases all records.
• SEND Starts a transaction in which the message is delivered to a terminal.
• SOML The message is delivered to a terminal or mailbox.
• SAML The message is delivered to a terminal and mailbox.
• VRFY Requests the server to verify an entire argument.
• EXPN Requests the server to confirm the argument.
• HELP Allows to request information about a command.
• NOOP Not to say anything, it is used to keep the session open
• TURN Request the server to exchange the papers.

Of the three digits of the numerical code, the first indicates the category of the response, the following categories being defined:

• 2XX, the operation requested by the previous command has been successfully completed
• 3XX, the order has been accepted, but the server is waiting for the client to send you new data to complete the operation
• 4XX, for an error response, but is expected to repeat the instruction
• 5XX, to indicate a condition of permanent error, so the order should not be repeated

Once the server receives the message ended with a period, it can store it if it is for a recipient belonging to its domain, or retransmit it to another server so that it finally reaches a server in the recipient's domain.

Example of SMTP communication

First, a connection must be established between the sender (client) and the receiver (server). This can be done automatically with a mail client program or through a telnet client.

The following example shows a typical connection. The client is named with the letter C and the server with S.

S: 220 SMTP server
C: HELO miequipo.midominio.com
S: 250 Hello, please to meet you
C: MAIL FROM: yo@midominio.com
S: 250 Ok
C: RCPT TO: ≤2
S: 250 Ok
C: DATA
S: 354 End data with ≥CR tax excl. ≤2
C: Subject: Subject field
C: From: yo@midominio.com
C: To: recipient@sudominio.com
C:
C: Hi.
C: This is a test.
C: See you later.
C:
C:
C: ≤C; ≤2
S: 250 Ok: queued as 12345
C: quit
S: 221

Message format

As shown in the example above, the message is sent by the client after it sends the DATA command to the server. The message is made up of two parts:

• Head: in the example the first three lines of the message are the header. They use keywords to define the fields of the message. These fields help mail customers organize and show them. The most typical are subject (assumption) from (emissor) and to (receptor). These last two fields should not be confused with MAIL FROM and RCPT TO, which belong to the protocol, but not the format of the message.
• Message body: it is the message itself. In the basic SMTP it is composed only of text, and finished with a line in which the only character is a point.

SMTP vs Mail Retrieval

Simple Mail Transfer Protocol (SMTP) is only responsible for delivering the message. As soon as they are received, the messages are sent to the destination mail server or the next hop mail server. Mail is routed based on the destination server, not the addresses of individual users. Other protocols such as Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) are structured for individual users, message retrieval, mailbox management. SMTP uses a feature, remote server mail queue processing, that allows an intermittently connected mail server to send messages from a remote server. IMAP and POP are unsuitable protocols for relaying mail from intermittently-connected machines, but are instead designed to work after final delivery.

Remote start of queued message

It is a feature of SMTP that allows a remote host to initiate mail queue processing on the server so that it can receive messages destined for it by sending the TURN command. This feature is considered insecure but using the ETRN command in the RFC 1985 extension works more securely.

On Demand Mail Forwarding Request (ODMR)

On-Demand Mail Relay (ODMR) is an extension of SMTP standardized in RFC 2645 that allows email to be transmitted to the recipient after it has been approved. It uses the ATRN extended SMTP command, available for dynamic IP addresses. The client publishes EHLO and AUTH commands of ODMR mail services, ODMR starts acting as a SMTP client and starts sending all messages addressed to a client using the SMTP protocol, when logging in the firewall or server can block the session incoming due to dynamic IPs. Only the ODMR server, the service provider, should listen for SMTP sessions on a fixed IP address.

Internationalization

Many users whose base language is not Latin have had difficulties with the email requirement in America. RFC 6531 was created to solve that problem by providing SMTP internationalization features, the SMTPUTF8 extension. RFC 6531 provides support for multi-byte characters and not ASCII in email addresses. Internationalization support is currently limited but there is a lot of interest in extending RFC 6531. RFC in countries like China, which has a large user base in America.

Outgoing mail with SMTP

An email client has to know the IP address of its initial SMTP server and this has to be given as part of its configuration (usually given as a DNS name). This server will send outgoing messages on behalf of the user.

Restriction of access and exit to the mail server

In a server environment, administrators must take control measures over where servers are available to clients. This allows you to implement security against possible threats. Previously, most systems imposed usage restrictions based on the client's location, allowing use only by those clients whose IP address is one of those controlled by server administrators. Modern SMTP servers are characterized by offering an alternative system, which requires authentication by clients by means of credentials before allowing access.

Restrict access by location

With this system, the SMTP server relative to the ISP will not allow access by users who are outside the ISP's network. Specifically, the server can only allow access to those users whose IP address was provided by the ISP, which is equivalent to requiring that they be connected to the Internet through the same ISP. A mobile user is often on a different network than his or her ISP's normal network, and then finds that sending email fails because the choice of the configured SMTP server is no longer accessible. This system has several variations, for example, the organization's SMTP server can only provide service to users on the same network, this is enforced by firewalls to block general user access via the Internet. Or the service might perform scope checks on the client's IP address. These methods are typically used by companies and institutions such as universities that provide an SMTP server for outgoing mail only for internal use within the organization. However, most of these agencies now use client authentication methods, as described below. By restricting access to certain IP addresses, server administrators can easily recognize the IP address of any attacker. As this represents a significant address for them, administrators can deal with the suspicious machine or user. When a user is mobile, and can use different providers to connect to the Internet, this type of usage restriction is costly, and altering the settings pertaining to the outgoing SMTP server email address is impractical. It is highly desirable to be able to use email client configuration information that you do not need to change.

Security and spam

One of the limitations of the original SMTP is that it does not provide authentication methods to senders, so the extension SMTP-AUTH was defined in RFC 2554.

Despite this, spam is still the biggest problem. Extensions are not believed to be a practical way to prevent this. Internet Mail 2000 is one of the proposals to replace it.^{[citation needed]}

Different methodologies have appeared to combat spam. These include DKIM, Sender Policy Framework (SPF) and since 2012 Domain-based Message Authentication, Reporting and Conformance (DMARC).

The associated RFCs

• RFC 1123 – Requirements for Internet Hosts—Application and Support (STD 3)
• RFC 1870 – SMTP Service Extension for Message Size Declaration (let RFC 1653)
• RFC 2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
• RFC 2920 – SMTP Service Extension for Command Pipelining (STD 60)
• RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (leaves RFC 2487)
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications (let RFC 1891)
• RFC 3463 – Enhanced Status Codes for SMTP (let RFC 1893)
• RFC 3464 – An Extensible Message Format for Status Delivery Notifications (let RFC 1894)
• RFC 3798 – Message Disposition Notification
• RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
• RFC 4952 – Overview and Framework for Internationalized E-mail
• RFC 4954 – SMTP Service Extension for Authentication (deja оbsoleto a RFC 2554)
• RFC 5068 – E-mail Submission Operations: Access and Accountability Requirements (BCP 134)
• RFC 5321 – The Simple Mail Transfer Protocol (leaves оbsolete to RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821)
• RFC 5322 – Internet Message Format (let RFC 822 aka STD 11, and RFC 2822)
• RFC 5336 – SMTP Extension for Internationalized Email Addresses (updates RFC 2821, RFC 2822 and RFC 4952)
• RFC 5504 – Downgrading Mechanism for Email Address Internationalization
• RFC 6409 – Message Submission for Mail (let RFC 4409, RFC 2476)
• RFC 6522 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (he leaves RFC 3462, and in turn RFC 1892)