Smtp syntax. Basic SMTP client commands. Managed File Transfers and Network Solutions

For several decades, Internet users have been using email to exchange messages and letters. Until the early 90s of the last century, electronic messages were used, as a rule, by employees of large organizations. With extensive computerization and the spread of the World Wide Web, emails have become a part of the lives of ordinary users.

The development of Internet technologies has led to the emergence of so-called mail protocols used for network correspondence. They make it possible to process large letters, providing users with all kinds of services.

It is not constrained by any specific data transmission subsystems. Its operation requires only a reliable channel for the flow of their transmission while maintaining order.

SMTP is used mainly for sending letters and user requests to the server, after which mail is sent to recipients. In order to receive letters, you need the mail client to work on IMAP protocol or POP3.

What is it used for?

Today this is typical postal protocol. All mail programs and servers use it.

Virtual website hosting for popular CMS:

The principle of operation of the protocol.

SMTP is a text protocol; its operating principle requires a connection over which the user sending email, contacts its recipient using a specific command line. And data is received through the use of a reliable communication channel. Typically, this communication channel is a TCP connection.

A working protocol session consists of a number of commands sent by the SMTP mail client and the server's responses to them. During a work session, both the client and the server exchange the necessary parameters.

The protocol operation includes a combination consisting of following sequences commands and responses:

MAIL FROM command - indicates the return email address;
RCPT TO command - determines the recipient of a specific letter;
DATA is the command responsible for sending the text of an email message. This is the body of the letter, which includes the header and body of the letter, separated from each other empty line.

The initial SMTP client may well be the recipient's email client, or a mail transfer agent on the server.

How other mail protocols work.

SMTP is just a protocol for delivering correspondence on the network. He cannot, on command, take an email message from a remote server or somehow manage an email box.

There are other protocols for this, such as IMAP and POP. Their use is preferable when connecting to a network temporarily or when the PC is turned on periodically.

POP.

Post Office Protocol is simple network protocol, which includes three varieties: POP, POP2 and POP3. They are designed to deliver correspondence to the user from a central mail server, to delete mail from the server, and to identify the user. A combination of login and password is used for identification. It is worth noting that all three protocols are not interchangeable.

The protocol includes SMTP, which is used to transmit outgoing mail.

In accordance with POP3, letters arriving at a specific e-mail are stored on the server until they are downloaded to the PC during the next session. Once the download has occurred, it becomes possible to read the messages while disconnecting from the network. POP3 is considered to be the fastest mail protocol.

IMAP.

WITH using the Internet Message Access Protocol makes it possible to store messages in file directories on the server and search for any message strings directly there.

This protocol is suitable for those users whose computers use a continuous connection to the Internet. It differs from POP in that when new messages are scanned, only their headers are downloaded.

And other message forwarding agents use SMTP to send and receive mail messages; running at the user level, client mail applications typically use SMTP only to send messages to the mail server for relaying. Client applications typically use either POP to receive messages. Post Office Protocol- protocol post office), or IMAP (eng. Internet Message Access Protocol ), or proprietary systems (such as Microsoft Exchange and Lotus Notes / Domino) to access your mailbox account on the server.

Story

In the 1960s they used different kinds electronic communications. People communicated with each other using systems designed for specific mainframe computers. When all more computers became interconnected, especially on the US Government network, ARPANET, standards were developed so that users on different systems could write electronic messages to each other. These standards, developed in the 1970s, became the basis for SMTP.

The roots of SMTP can be traced back to two implementations described in 1971 - Mail Box Protocol and SNDMSG, which was "invented" by Ray Tomlinson of BBN Technologies for TOPS-20/TENEX computers sending messages over the ARPANET (at that time they were connected to less than 50 hosts).

Further implementations include FTP Mail and Mail Protocol, developed in 1973. Development continued throughout the 1970s until the ARPANET evolved into the modern Internet around 1980. That same year, Jon Postel proposed the Mail Transport Protocol. , thanks to which FTP ceased to be the basis for sending mail. SMTP was published in RFC 821 (also written by Postel) in August 1982.

The SMTP standard was developed around the same time as Usenet, a data network with some similarities to SMTP. SMTP came into widespread use in the early 1980s. At the time, it was an add-on for running Unix mail program Unix Copy Program (UUCP), which was more suitable for handling the transfer of electronic messages between periodic connected devices. On the other hand, SMTP works great when both the sending and receiving devices are constantly connected on the network. Both devices use a store-and-forward mechanism and are examples of push technology. Although Usenet newsgroups are still distributed between servers using UUCP, UUCP mail has effectively disappeared along with the "bang path" (the sequence of hosts on the network that a message should take to reach its destination), which were used as routing headers. The Sender Rewrite article contains technical information. reference Information about the history of early SMTP and source routing through RFC 1123.

Since this protocol initially had a text (ASCII) interface, it did not work well with binary files and characters from many non-English languages. Standards such as Multipurpose Internet Mail Extensions (MIME) were developed to encode binary files for transmission over SMTP. Forward agents developed after Sendmail typically also implemented a pure 8-bit option, so an alternative "just send eight" strategy could be used to transfer arbitrary text data (in any eight-bit ASCII-like character encoding) via SMTP. However, there was still the problem of krakozyabr, caused by different displays of character sets among manufacturers, although the postal addresses themselves still allowed the use of ASCII exclusively. Today, pure 8-bit forwarders typically support the 8BITMIME extension, allowing binary files to be transferred almost as easily as plain text. Recently, the SMTPUTF8 extension was created to support UTF-8 encoded text, making it possible to include international content and addresses using alphabets such as Cyrillic or Chinese.

Many prominent people contributed to the core SMTP specification, including Jon Postel, Eric Allman, Dave Crocker, Ned Fried, Randall Jellens, Jon Klensin, and Keith Moore.

Mail processing model

Email is submitted by a mail client (MUA, mail user agent) to a mail server (MSA, mail submission agent) using SMTP on TCP port 587. From there, the MSA delivers mail to its message transfer agents (MTAs). , mail transfer agent). Often these two agents are simply different examples of the same thing software, launched with different parameters on the same device. Local processing can be carried out either on a separate machine or divided between various devices; in the first case, the processes involved have general access to files, in the second case SMTP is used to forward the message internally, with each host configured to use next device as an intermediate host. Each process is an MTA in itself, i.e. an SMTP server.

The edge MTA must find the target host. It uses the Domain Name System (DNS) to look up mail exchanger records ( mail exchanger- MX) of the recipient's domain (the part of the address located to the right of the @ symbol). The returned mail MX record contains the target host name. The MTA then connects to the exchange server as an SMTP client.

Once the MX target accepts incoming message, it passes it to the mail delivery agent (MDA) for local delivery of the message. MDA provides the ability to save messages in the appropriate mailbox format. Reception of mail, again, can be carried out either by several or by one computer - the image shows the two closest mailboxes for each case. MDA can deliver messages directly to storage or transmit them over a network using SMTP or any other means, including Local Mail Transfer Protocol- LMTP) - a derivative of SMTP, intended for this purpose.

Once delivered to the local mail server, the message is stored for batch searching against authenticated mail clients (MUAs). The message is retrieved by applications end user(mail clients) using the Internet Message Access Protocol (IMAP, which facilitates access to messages and manages stored mail), or with using Post Office Protocol (POP), which typically uses the traditional mbox file format, or proprietary systems like Miscrosoft Exchange/Outlook or Lotus Notes/Domino. Network mail clients can use either method, but the search protocol often does not conform to official standards.

SMTP determines the transmission of a message, not its content. Thus, it specifies the message wrapper and its parameters (such as the sender of the wrapper), but not the header or body of the message itself. STD 10 and RFC 5321 define SMTP (wrapper), while STD 11 and RFC 5322 define the message (header and body), officially called the format mail message(Internet Message Format).

Protocol Overview

SMTP is a connection-based text protocol in which the sender of a message communicates with the recipient by issuing command lines and receiving the necessary data through a reliable channel, which is usually a TCP (Transmission Control Protocol) connection. An SMTP session consists of commands sent by the SMTP client and corresponding responses from the SMTP server. When a session is open, the server and client exchange its parameters. A session can include zero or more SMTP operations (transactions).

An SMTP operation consists of three command/response sequences (see example below). Description of sequences:

MAIL FROM- sets the return address (i.e. Return-Path, 53121.From, mfrom). This is the address for returned letters.

RCPT TO- sets the recipient of this message. This command can be given multiple times, once for each recipient. These addresses are also part of the shell.

DATA- to send the text of the message. This is the content of the letter itself, as opposed to its envelope. It consists of a message header and a message body separated by a blank line. DATA is essentially a group of commands, and the server responds twice: first to the DATA command itself, to indicate that it is ready to accept text; and a second time after the end of the data sequence to accept or reject the entire letter.

In addition to intermediate responses for the DATA command, each server response can be positive (response code 2xx) or negative. The latter, in turn, can be permanent (code 5xx) or temporary (code 4xx). SMTP server refuses to send a message - permanent error; in this case the client must send a return letter. After a reset - a positive response, the message will most likely be rejected. The server may also indicate that additional data is expected from the client (code 3xx).

The initial host (SMTP client) can be either the end user's mail client (functionally defined as a mail agent - MUA) or a message transfer agent (MTA) on the server, i.e. the server acts as a client in the appropriate session to relay the message. Fully functional servers support message queues to retransmit messages in case of errors.

MUA knows the SMTP server for outgoing mail from its settings. The SMTP server, acting as a client, i.e. forwarding messages, determines which server to connect to by looking at the resource MX (Mail eXchange) DNS records for each recipient's domain. In case the MX record is not found, compatible MTAs (not all) fall back to a simple A record. Forwarding servers can also be configured to use a Smart host.

The SMTP server, acting as a client, establishes a TCP connection to the server on the SMTP-designed port 25. The MUA must use port 587 to connect to the message provisioning agent (MSA). The main difference between MTA and MSA is that SMTP authentication is only required for the latter.

SMTP and message retrieval

SMTP is just a delivery protocol. It cannot retrieve messages from a remote server on demand. Other protocols such as POP and IMAP have been developed for mail retrieval and mailbox management. However, SMTP does provide the ability to start message queuing on a remote server so that the requesting system can receive all messages directed to it (see Remote Message Queue Starting below). POP and IMAP are preferred when the user's computer is not constantly on, or is temporarily connected to the Internet.

Remote Message Queue Starting

Remote Message Queue Starting is a feature of SMTP that allows a remote host to begin processing a message queue on the server so that it can receive messages destined for it using the TURN command. However, this feature was considered insecure and was extended in RFC 1985 by the ETRN command, which works more reliably due to the fact that it is based on DNS information authentication method.

On-Demand Mail Relay

ODMR (On-Demand Mail Relay) is an SMTP extension standardized in RFC 2645 that allows message relay to an authenticated user.

Internationalization

Many users whose character set differs from the Latin alphabet are faced with the requirement for an email address in Latin. To solve this problem, RFC 6531 was created, providing internationalization capabilities for SMTP - an extension to SMTPUTF8. RFC 6531 provides support for multibyte and non-ASCII characters in a mail address, for example: δοκιμή@παράδειγμα.δοκιμή or 测试@测试.测试. Current support is limited, but there is great interest in widespread adoption of RFC 6531 and related RFCs in countries with large user bases for which Latin is not a native alphabet.

Outgoing mail SMTP server

The mail client must know the IP address of the SMTP server, which is set as part of the configuration (usually in the form of a DNS name). The server will deliver outgoing messages on behalf of the user.

Restrictions on access to the outgoing mail server

Server administrators need to control which clients can use the server. This allows them to combat abuses such as spam. Two solutions are commonly used:

In the past, many systems imposed restrictions on the location of the client, allowing use only by those whose IP address was among those controlled by administrators.
Modern servers usually offer an alternative system that requires clients to authenticate to gain access.

Restrict access by location

In this case, the ISP's SMTP server will not allow access to users "outside" the provider's network. More precisely, the server can only admit those users whose IP address is provided by a given ISP, which is equivalent to requiring an Internet connection through that ISP. A mobile user may often find themselves on a different network than their provider, and therefore messages will not be sent.

This system has several varieties. For example, an organization's SMTP server might allow access only to users on the same network, blocking other users. The server can also perform a number of checks on the client's IP address. These methods were commonly used by organizations and institutions, such as universities, for internal server use. However, most of them now use the authentication methods described below.

By restricting access to certain addresses, server administrators can easily determine the address of any attacker. If a user may use different ISPs to connect to the Internet, this type of restriction becomes impractical, and changing the configured outgoing mail SMTP server address is impractical. It is highly desirable to be able to use client configuration information that does not need to be changed.

Client Authentication

Instead of the location restriction described earlier, modern SMTP servers typically require user authentication before gaining access. This system, being more flexible, supports mobile users and gives them a fixed choice of configured outgoing mail server.

Open rayleigh

A server that is accessible to a wide network and does not provide these types of access restrictions is called an open relay. Now such servers are considered bad form.

Ports

Server administrators choose which port clients will use to relay outgoing mail - 25 or 587. The specifications and many servers support both ports. Although some servers support port 465 for secure SMTP, it is preferable to use standard ports and ESMTP commands if a secure session between client and server is needed.

Some servers are configured to reject all relays on port 25, but users authenticated on port 587 are allowed to forward messages to any valid address.

Some ISPs intercept port 25, redirecting traffic to their own SMTP server, regardless of the destination address. Thus, their users cannot access the server outside the provider's network on port 25.

Some servers support authenticated access on an additional port other than 25, allowing users to connect to them even if port 25 is blocked.

An example of a simple SMTP session

C: - client, S: - server

S: (waiting for connection) C: (Connects to server port 25) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM: S:250 [email protected] sender accepted C:RCPT TO: S:250 [email protected] ok C:RCPT TO: S:550 [email protected] unknown user account C:DATA S:354 Enter mail, end with "." on a line by itself C:from: [email protected]//to letter C:to: [email protected]//was not added C:subject: tema //to the spam category C: //C:Hi! C:. S:250 769947 message accepted for delivery C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP closing connection S: (closes connection)

As a result of such a session, the letter will be delivered to the addressee [email protected], but will not be delivered to the recipient [email protected], because such an address does not exist.

Additional extensions

Many clients request SMTP extensions supported by the server using the EHLO command from the Enhanced SMTP specification (RFC 1870). HELO is only used if the server did not respond to EHLO. Modern clients can use the ESMTP extension key SIZE to request the maximum message size that will be accepted. Older clients and servers may attempt to transmit excessively large messages, which will be rejected after consuming network resources, including connection time. Users can manually pre-define the maximum size accepted by ESMTP servers. The client replaces the HELO command with EHLO.

S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP

smtp2.example.com declares that it will accept a message no larger than 14,680,064 octets (8-bit bytes). Depending on the actual usage of the server, it may this moment do not accept a message of this magnitude. In the simplest case, the ESMTP server will only advertise the maximum SIZE when interacting with the user via EHLO.

SMTP Security and Spam

The original SMTP specification did not include any means to authenticate senders. Subsequently, an extension was introduced in RFC 2554. The SMTP extension (ESMTP) provides a mechanism for email clients to specify a security mechanism for the server, authentication, and SASL (Simple Authentication and Security Layer) security profile for subsequent message transmissions.

Microsoft products implement their own protocol - SPA (Secure Password Authentication) using the SMTP-AUTH extension.

However, the impracticality of widespread implementation and management of SMTP-AUTH means that the spam problem cannot be solved with it.

Extensive modification of SMTP, as well as complete replacement, are considered impractical due to the huge installed base of SMTP. Internet Mail 2000 was one of the candidates for such a replacement.

Spam operates due to various factors, including non-standard MTA implementations, operating system security vulnerabilities (exacerbated by persistent broadband connections), which allow spammers to remotely control the end user's computer and send spam from it.

There are several proposals for side protocols to help SMTP work. The Anti-Spam Research Group (ASRG), a division of the Internet Technology Research Group, is working on mail authentication and other proposals to provide simple authentication that is flexible, lightweight, and scalable. Recent Internet Engineering Task Force (IETF) work includes MARID (2004), which led to two IETF-approved experiments in 2005, and DomainKeys Identified Mail in 2006.

ESMTP extensions

RFC 1869 requires that the session be started with the EHLO command rather than with the HELO command. If the server does not support extensions, it will respond to EHLO with an error; in this case, the client must send the HELO command and not use protocol extensions.

If the server supports ESMTP, then in addition to the greeting it will provide a list of supported SMTP protocol extensions, for example:

Ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 EHLO

RFC Standards

RFC 1870 SMTP Service Extension for Message Size Declaration (supersedes RFC 1653)
RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
RFC 4954 SMTP Service Extension for Authentication (replaces RFC 2554)
RFC 2822 Internet Message Format (replaces RFC 822 aka STD 11)
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 (supersedes RFC 2487)
RFC 3461 SMTP Service Extension for Delivery Status Notifications (supersedes RFC 1891)
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (supersedes RFC 1892)
RFC 3463 Enhanced Status Codes for SMTP (replaces RFC 1893)
RFC 3464 An Extensible Message Format for Delivery Status Notifications (supersedes RFC 1894)
RFC 3552 Guidelines for Writing RFC Text on Security Considerations
RFC 3834 Recommendations for Automatic Responses to Electronic Mail
RFC 4409 Message Submission for Mail (replaces RFC 2476)
RFC 5321 Simple Mail Transfer Protocol (supersedes RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821)
RFC 5336 SMTP Extension for Internationalized Email Addresses
Translation of RFC 2505 - Spam Prevention Guidelines for SMTP MTAs
Translation of RFC 2554 - SMTP Service Extension for Authentication
Translation of RFC 5321 - Simple Mail Transfer Protocol (SMTP)

Literature

Hughes L Internet e-mail Protocols, Standards and Implementation. - Artech House Publishers, 1998. - ISBN 0-89006-939-5
Hunt C sendmail Cookbook. - O"Reilly Media, 2003. - ISBN 0-596-00471-0
Johnson K Internet Email Protocols: A Developer's Guide. - Addison-Wesley Professional, 2000. - ISBN 0-201-43288-9
Loshin P Essential Email Standards: RFCs and Protocols Made Practical. - John Wiley & Sons, 1999. - ISBN 0-471-34597-0
Rhoton J Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. - Elsevier, 1999. -

SMTP is implemented in modern networks TCP/IP standard. Information about the use of the protocol first appeared back in 1982. Despite the fact that the SMTP server can also be used to receive messages, today most email clients use it only for sending, preferring other technologies (for example, POP or IMAP) for receiving information. The protocol is one of the most popular and is used by the overwhelming number of mail programs and servers.

The function of SMTP is to check that the settings and parameters for sending a letter are specified correctly. This protocol verifies the settings of the user’s computer trying to send messages, and then delivers them if all settings have been made correctly. After this, the SMTP work does not end and the server waits for a message about successful data delivery. If a message cannot be delivered for some reason, a corresponding message is sent to the sender.

SMTP setup

Setting up SMTP involves installing the necessary software and determining the server address used for sending. To send from the user side, you need to install a client program that can send letters and communicate with the SMTP server using the TCP/IP protocol. After this, the program is launched and configured to work with the service for sending and receiving mail by specifying the necessary settings. The user then tries to send a message. If the setting is correct, the letter will be delivered to the recipient.

Majority modern services emails already have servers configured to send messages. If you do not use third-party software to send letters, you can send a letter without making additional settings on the service website where you have an account.

Modern SMTP server administrators require users to authenticate before they can send their message. The user must first indicate his login and password on the server, and only then proceed to sending. This protection used to block the possibility of sending spam using simple SMTP protocols. Previously, for identification in SMTP protocol the sender's unique IP address was used.

Dear blog readers, I haven’t written new articles for a long time, but there are objective reasons for this. I am very glad that you continue to comment on my previous articles and remain readers of our blog. I will try to catch up with you in the near future and please you with a lot of interesting and useful articles. Today’s article will be devoted to SMTP servers, which are indispensable in email newsletters messages.

SMTP is a protocol that is responsible for receiving messages originating from the user and transmitting them to a specific recipient. Messages always pass through multiple servers to reach their destination, and SMTP simplifies this procedure.

Let's say you are sending a message to a specific recipient. Your e-mail ID, for example, “user” and you have an account registered at “mail.ru” – “ [email protected]" Address of the recipient - " [email protected]».

When you created an account on the mail.ru mail service, your mail client (for example, Microsoft Outlook) automatically saved account settings. What happens next:

The mail client communicates with your Mail.ru mail server via port 25.
The mail client communicates with the mail server's SMTP server, providing it with the sender and recipient addresses, and the text of the message.
The SMTP server splits the recipient's address into two parts: the recipient's name/login (recipient) and the domain name (gmail.com).
The SMTP server “talks” with DNS server (Domain Name Server) and receives information about the IP address of the recipient's SMTP server gmail.com. DNS responds by sending one or more IP addresses SMTP servers, which gmail.com uses.
The SMTP server on mail.ru contacts the SMTP server gmail.com via port 25 and sends a message to it. The gmail.com SMTP server determines that the domain name for "recipient" exists on gmail.com and passes the POP3 message to the gmail.com server, which places the message in the recipient's mailbox.
If for some reason the SMTP server mail.ru cannot contact the SMTP server gmail.com, then the message is put in the sending queue. SMTP servers often use message senders to resend messages that are in a queue. The message sender will periodically try to send a message that is in the queue. Attempts will be repeated at certain intervals (for example, 15 minutes). After four hours of waiting and trying to send, the program usually sends the sender a letter informing about sending errors. After five days, most sending programs stop trying and return the email to the sender as unsent.

In the case when the source SMTP server (mail.ru) cannot communicate directly with the SMTP server gmail.com, it transmits the message through one or more intermediate relay SMTP servers. In turn, the relay server receives the original message and then sends it to the destination server, or redirects it to another relay server. The process is repeated until the message is delivered, or until the specified time and number of retries have passed to wait for a response from the server.

The SMTP server understands simple text commands. The standard ones are:

HELO – session start

EHLO - start of a session and request for extended mode - ESMTP (If the server does not support extensions, it will respond to EHLO with an error, in this case the client must send the HELO command and not use protocol extensions.)

MAIL FROM: — sender's address

RCPT TO: - recipient address

DATA – data transfer (letters). The “To”, “From” and “Subject” fields should occupy the first three lines

RSET – session reset

QUIT – disconnection

HELP – help (additional information)

VRFY – checking an address for its existence

EXPN – extended address

(SMTP) is a standard for e-mail. Originally documented in RFC 821 (1982), it was last updated in 2008 with expanded additions of SMTP to RFC 5321 (a widely used protocol today).

Although mail servers and other mail agents use SMTP to send and receive e-mail correspondence, user-class software, as a rule, uses SMTP ports only to send data to the server for relaying. Client applications typically use either IMAP or POP3 to receive messages. These protocols are the most convenient and in demand for these purposes: they have advanced functionality and a wide range of capabilities.

Characteristics

SMTP communication between mail servers uses TCP port 25. Mail clients often send outgoing emails to the mail server on port 587. Although legacy mail providers still allow the use of the non-standard port 465 for this purpose.

SMTP connections protected by TLS, known as SMTPS, can be made using STARTTLS technology.

Proprietary and email systems use their own non-standard protocols to access mailboxes on their email servers - all companies use SMTP server ports when sending or receiving email occurs outside of their own systems.

SMTP destination

Almost everything on the Internet is made possible by protocols—special network software rules that allow a computer to communicate with all networks so users can shop, read the news, and send email. Protocols are vital to day-to-day networking—they're built into networking software and used by default.

The SMTP port protocol provides a set of codes that facilitate the exchange of email messages between servers (a networked computer that processes incoming and outgoing email). This is a kind of shorthand that allows the server to break down the different parts of the message into categories that another server can understand. When a user sends a message, it turns into lines of text separated by code words (or numbers) that define the purpose of each section.

Technical terminology

SMTP is a TCP/IP protocol used for working with e-mail. However, since it is limited to the ability to send messages to a queue on the receiving end, it is typically used with either POP3 or IMAP, which allows data to be stored on a server and downloaded when needed. In other words, they usually use an application that selects SMTP for sending e-mail and POP3 or IMAP for receiving correspondence. On Unix-based systems, sendmail is the most widely used SMTP server for email. The commercial Sendmail package includes a POP3 server. Microsoft Exchange includes an SMTP server and can also be configured to support POP3.

SMTP is typically used to operate over Internet port 25. An alternative to SMTP that is widely used in Europe is X.400. Many mail servers now support Extended Simple Mail Transfer Protocol (ESMTP), which allows you to transfer multimedia files in the form of email.

Story

In the 1960s they used different shapes exchange of electronic messages. Users communicated using systems built for specific mainframe computers. As more and more computers became interconnected, there was a need to develop standards to allow users of different systems to send email to each other. SMTP evolved from these standards developed in the 1970s.

Further implementations include the FTP Mail Protocol, starting in 1973. Development work continued into the 1970s until ARPANET became modern Internet in 1980. Then Jon Postel proposed a protocol for transferring mail data.

SMTP began to be widely used in the early 1980s. While this protocol was a Unix add-on for the Unix Copy Program mail program. SMTP works best when the sending and receiving machines are connected to the Internet, use a store and send mechanism, and are examples of push technology.

Mail processing model

E-mail is sent by an email client (Mail User Agent, MUA) to a mail server (Mail Submission Agent, MSA) using SMTP on TCP port 587. Most mailbox providers still allow sending to traditional port 25. MSA delivers mail to your mail agent (mail transfer agent, MTA). Often these agents are instances of generic software activated with various parameters on one computer. Local processing can either be done on a single machine or shared across multiple machines. Processes postal agent one machine can exchange files, but if processing is done on multiple machines, they pass messages between each other using an SMTP port, where each machine is configured to use the next machine as the smart host.

Protocol Overview

SMTP is a text-based, connection-oriented protocol in which the mail sender communicates with the mail recipient by issuing command lines and providing the required data over a reliable, orderly data flow channel. An SMTP session consists of commands issued by the SMTP client (initiating agent, sender, or transmitter) and corresponding responses from the SMTP server (listening agent or recipient). A session may include zero or more SMTP transactions, which consist of three command/response sequences:

In addition to the intermediate response for DATA, the response from each server can be either positive or negative (code 2xx). Negative responses can be permanent (codes 5xx) or temporary (codes 4xx). A rejection is a permanent failure and the client must send a rejection message to the server where it received it. A fall is a positive response followed by a rejection of the message.

Mail SMTP ports and their meaning

SMTP is a delivery protocol only. In normal use, mail is sent to the target mail server, such as the mail port SMTP server. Data is routed based on the destination server rather than the individual users it is addressed to. Other protocols (POP or IMAP) are specifically designed for use by individual users, which receive messages and manage mailboxes. SMTP, POP, and IMAP are not acceptable protocols for relaying mail over computers with intermittent connections. They are designed to operate after final delivery, when information critical to the proper operation of the mail relay has been removed.

Starting an empty message queue

Remote Message Queue Starting is an SMTP feature that allows a remote host to start mail processing on the server so that it can receive messages intended for it by sending the TURN command. However, this feature posed a potential data security risk and was extended in RFC 1985 by the ETRN command, which operates more securely using an authentication method based on Domain Name System information.

International email address

Users whose script is not Latin, or who use diacritics not in the set ASCII characters, experienced difficulties with the requirement for an email address in the Latin alphabet (mail.ru SMTP port). RFC 6531 was created to address this issue by providing internationalization capabilities for SMTP, an extension to SMTPUTF8, and support for multibyte and non-ASCII characters in email addresses. Examples: diacritics and other language symbols (Greek and Chinese). Also relevant for Yandex SMTP port.

Current support for this document is limited at the moment, but there is great interest in widespread implementation RFC 6531 and corresponding RFCs in countries like China that have a large user base where Latin (ASCII) is a foreign script.

Outgoing mail from SMTP server

The email client must know the IP address of its original SMTP server. This must be specified as part of its configuration (usually DNS name). This server will provide outgoing messages on behalf of the user.

Restrictions on access to the outgoing mail server

Server administrators need to impose certain controls on those clients who can use the server. This helps combat abuse and spam. Similar solutions were widely used:

Previously, many systems imposed restrictions on the use of client location, allowing only use by clients whose IP address was one of the server administrators. Use from any other client IP address is prohibited.

Modern SMTP servers usually offer an alternative system that requires clients to authenticate with credentials before allowing access.

SMTP - what port is used?

Communication between mail servers usually always uses the default TCP port value of 25, which is assigned to SMTP. However, email clients usually use specific ports smtp ssl port. Most Internet service providers now block all outgoing port traffic from their customers as an anti-spam measure. For the same reason, businesses typically configure their firewall to allow outgoing ports from designated mail servers.

SMTP transport example

A typical example of sending a message via SMTP to two mailboxes(alice and theboss) located in the same mail domain (example.com or localhost.com) is reproduced in the next exchange session. After the message sender (SMTP client) establishes a reliable communication channel to the message receiver (SMTP server), a session is opened with a server typically containing its fully qualified domain name (FQDN), in this case smtp, example, or com. The client initiates its dialog box by responding with a HELO command identifying itself in the command parameter with its full domain name(or an address literal if not available).

Additional extensions

Clients learn which options the server supports by using the EHLO greeting instead of the original HELO. Clients only fall back to HELO if the server does not support SMTP extensions.

Modern clients can use keyword The ESMTP extension SSRE is for querying the server for the maximum message size that will be accepted. Legacy clients and servers may attempt to transmit oversized messages that will be rejected after using up network resources, including connection time to network links.

Anti-spam methods and email authentication

The original design of SMTP had no way to identify senders or check whether servers were allowed to send on their behalf. As a result, email spoofing is possible, which is commonly used in mail spam and phishing.

Produced Special offers to change SMTP or replace them completely. Internet Mail 2000 is one example of this, but neither it nor any other achieved much success before the network effect of classic SMTP's huge installed base. Instead, mail servers now use whole line methods including DomainKeys, DomainKeys Identified Mail, Policy Framework and DMARC, DNSBLs and greylisting to reject or quarantine suspicious emails.