Reasons and goals for creating the smtp protocol. Email protocols: IMAP, POP3, SMTP and HTTP

4085/2, Sorokin D. S. Mail protocols. Methods of combating spam

SMTP

SMTP (Simple Mail Transfer Protocol) is a widely used network protocol designed to transfer Email on TCP/IP networks.

SMTP transactions

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).

SMTP commands

An SMTP operation consists of three command/response 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 notify

readiness to accept the 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 failure to transmit a message is a 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 with the server as designed for SMTP port 25. MUA should use port 587 to connect to

Message Submission Agent (MSA). The main difference between MTA and MSA is that SMTP authentication is only required for the latter.

SMTPS

SMTPS refers to SMTP transport layer security methods. It is designed to ensure party authentication, data integrity and confidentiality. SMTPS is not a proprietary protocol or extension to SMTP, it is just a way to secure SMTP at the transport layer.

The client and server use regular SMTP at the application level, but the connection is secured by SSL or TLS. This occurs after a connection has been established before any mail data is sent.

SMTPS uses port 465.

POP3 (Post Office Protocol Version 3) is a standard Internet application protocol used by email clients to retrieve an email message from a remote server over a TCP/IP connection. POP and IMAP (Internet Message Access Protocol) are the most common Internet protocols for retrieving mail. Almost all modern email clients and servers support both standards. The POP protocol has been developed in several versions, with the third version (POP3) being the current standard. Most email service providers (such as Hotmail, Gmail and Yahoo! Mail) also support IMAP and POP3. Previous versions of the protocol (POP, POP2) are obsolete.

POP supports simple download-and-delete requirements for accessing remote mailboxes. Although most POP clients provide the ability to leave mail on the server after downloading, clients using POP typically connect, retrieve all messages, save them on the user's computer as new messages, delete them from the server, and then disconnect.

The POP3 server listens on the well-known port 110. Communication encryption for POP3 is requested after the protocol has started, using either the STLS command (if supported) or POP3S, which connects to the server using TLS or SSL on TCP port 995.

POP3 commands

		Arguments	Restrictions	Possible answers
			Her support is not	* +OK maildrop has n message
		[Name]		* -ERR password suplied for
			mandatory
				[name] is incorrect
				* +OK name is a valid mailbox
				* -ERR never heard of mailbox
				* +OK maildrop locked and
			Works after successful transfer
				* -ERR invalid password
			mailbox name
				* -ERR unable to lock

		[message]	Available after successful	* +OK message deleted
			identification	* -ERR no such message
		[message]	Available after successful	* +OK scan listing follows
			identification	* -ERR no such message
			Available after successful
			identification
		[message]	Available after successful	* +OK message follows
			identification	* -ERR no such message
			Available after successful
			identification
			Available after successful
			identification
		[message]	Available after successful
		[quantity
			identification	* -ERR no such message

IMAP

An alternative protocol for collecting messages from a mail server is IMAP. IMAP (Internet Message Access Protocol) is an application-level protocol for accessing email.

Based on the TCP transport protocol and uses port 143.

POP3 has a number of disadvantages, and the most serious of them is the lack of capabilities to control the movement and storage of messages on the server. Messages, as a rule, are downloaded from the mail server all at once, after which they are deleted from the server, that is, there is no ability to select messages to receive.

To address the problems associated with this feature of POP3, the University of Washington developed a new protocol that allows users to receive e-mail from the same mailbox from multiple locations without the messages being distributed among the receiving points. The user is given the opportunity to manage messages in his mailbox and additional functions for servicing mailboxes on the server.

Benefits of IMAP

When using POP3, the client connects to the server only for the period of time necessary to download new messages. When using IMAP, the connection does not break until user interface active and messages are downloaded only when requested by the client. This allows you to reduce response time for users whose mailboxes contain many large messages.

The POP protocol requires that the current client be the only one connected to the mailbox. IMAP allows multiple clients to access a mailbox at the same time and provides the client with the ability to monitor changes made by other clients connected at the same time.

Thanks to the flag system defined in IMAP4, the client can track the status of a message (read, reply sent, deleted, etc.); flag data is stored on the server.

IMAP4 clients can create, rename, and delete mailboxes and move messages between mailboxes. You can also use the IMAP4 Access Control List (ACL) Extension (RFC 4314) to control mailbox access rights.

Searching for messages occurs on the server side. IMAP4 has an explicit extension mechanism.

Anti-spam methods

Modern spam mailings are distributed in hundreds of thousands of copies in just a few tens of minutes. Most often, spam comes through infected malware user computers- zombie networks. What can be countered to this onslaught? The modern IT security industry offers many solutions, and anti-spammers have various technologies in their arsenal. However, no existing technology is a magic “silver bullet” against spam. Universal solution simply doesn't exist. Most modern products use multiple technologies, otherwise the effectiveness of the product will not be high.

DNSBL

DNSBL - DNS blacklist or DNS blocklist - lists of hosts stored using the DNS architecture system. Typically used to combat spam. The mail server accesses the DNSBL and checks it for the IP address of the client from which it is receiving the message. If the answer is positive, it is considered that an attempt is being made to receive a spam message. The sending server receives an error 5xx ( fatal error) and the message is not accepted. The sender's mail server creates a "bounce receipt" to the sender indicating that the mail was not delivered.

There are 2 methods of using this technology.

1. Unambiguous blocking - rejection of messages that came from an IP address located in the DNSBL

2. A balanced approach. With this approach, a message coming from an IP address

located in the DNSBL is not blocked, but this fact is taken into account when classifying the “spam” of the letter.

When using the first approach, all letters from IP addresses included in the DNSBL are clearly rejected. Regardless of whether the IP address was blacklisted deservedly or by mistake (which is becoming more and more common in practice). The use of the second approach is perfectly illustrated by the opensource spam filter spamassassin. When a weighted approach is used to classify a message, that is, analysis based on multiple criteria. In this case, the presence of the sender's IP address in the blacklist is not the only and resulting factor that influences the decision on message classification, which in turn means a reduction in the number of false filter positives in cases where the sender's IP address was blacklisted by an absurd accident .

Mass control

The technology involves identifying mass messages in the mail flow that are absolutely identical or differ only slightly. To build a working “mass” analyzer, huge mail flows are required, so this technology is offered large manufacturers, having significant volumes of mail that they can analyze.

Pros: If the technology worked, it is guaranteed to detect mass mailings.

Disadvantages: Firstly, a “large” mailing may not be spam, but quite legitimate mail (for example, Ozon.ru, Subscribe.ru send out thousands of almost identical messages, but this is not spam). Secondly, spammers know how to “break through” such protection using intelligent technologies. They use software that generates different content- text, graphics, etc. - in every spam

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. To receive messages client applications usually use either POP Post Office Protocol- post office protocol), or IMAP (eng. Internet Message Access Protocol), or proprietary systems (such as Microsoft Exchange and Lotus Notes/Domino) to access account your mailbox 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 to the Unix-based mail program Unix Copy Program (UUCP), which was better suited to handling transmissions emails between periodically 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) have been developed to encode binary files for transfer via 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 instances of the same software running with different settings 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 file sharing, 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 the mail exchanger (MX) records of the recipient's domain (the part of the address 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 receives an incoming message, it passes it to a mail delivery agent (MDA) to deliver the message locally. 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. An MDA can deliver messages directly to storage or transmit them over a network using SMTP or any other means, including the Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed 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 end-user applications (mail clients) using the Internet Message Access Protocol (IMAP, which facilitates access to messages and manages stored mail), or using the 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 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 failure to transmit a message is a 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 securely due to the DNS information-based 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 alternative system, requiring client authentication 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 the 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 and operating system security vulnerabilities (exacerbated by persistent broadband connections) that 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 TCP/IP standard networks. 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. By this protocol the computer settings of the user trying to send messages are verified, and then delivery is made if all settings were 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.

Most modern email services already have servers configured for sending messages. If you don't use third-party software to send emails, you will be able to send an email without having to write additional settings on the service website where you have registered 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 is used to block the possibility of sending spam using simple SMTP protocols. Previously, the SMTP protocol used the unique IP address of the sender for identification.

SMTP (Simple Message Transfer Protocol), or literally translated as a simple message transfer protocol, was born in the UNIX environment and was intended exclusively for mail servers communicating with each other. In terms of the model OSI protocol SMTP is at the application level.

SMTP has now become the de facto standard. To a large extent, this popularity is explained by the comparative ease of implementation and wide extensibility without compromising backward compatibility with existing versions postal systems. An important factor is also the wide availability of specifications and the absence of the need to pay funds for their use.

SMTP systems for Lately actively developed in the following directions:

extension of the server-server communication protocol (SMTP itself);

creation and improvement of the client-server communication protocol (POP3, IMAP4);

introduction and expansion of a new message format (MIME).

The initial version of the SMTP protocol supported a limited set of commands and services for receiving and sending messages. Recently, its extended version (Extended or ESMTP) has been developed, providing a standard possibility for further expansion and support for such functions as delivery notification (Delivery Notification Request or DNR), negotiation of the maximum allowable size of messages transmitted between servers and forced initiation of the transfer of accumulated mail ( dequeue). However, one of the weaknesses of SMTP at the moment has been and continues to be the lack of ability to authenticate incoming connections, encrypt dialogue and data flow between servers.

The lack of incoming connection authentication prevented the use of SMTP for client access. The classic SMTP mail system requires the client to have file access to his mailbox to receive and work with messages. To implement work in client-server mode, a post office service protocol (Post Office Protocol or POP) was created. The most successful version was POP3, widely used in modern SMTP systems. The most advanced implementations support authentication with username and password encryption and Secure Socket Layer (SSL) traffic encryption. However, when using POP protocol 3 there is no possibility of viewing the characteristics of a message without first downloading it to the client station. To solve the problem of viewing and manipulating the properties of an email message directly on the server, as well as to overcome a number of other functional limitations, the IMAP4 protocol was developed; its support in most commercial systems is expected in the near future. It should be noted that both when using a classic client (mail command) and when using POP3 or IMAP4, sending messages prepared by the client requires an SMTP server. Figure 1.6 shows a diagram of a typical SMTP system using both the traditional UNIX file-based mailbox access method and access via the POP3 and IMAP4 protocols.

Initially, SMTP systems were designed to transmit information exclusively in text form and were not focused on transmitting characters from national alphabets, i.e. used a 7-bit character set. To solve the problem of transferring binary files, the UUENCODE standard was developed, which allows you to embed arbitrary data, previously converted from binary to text form, directly into the text of the message. However, comprehensive this approach it was difficult to name, because in the general case, the receiving party had no information about the nature of the attachment (the type of data being transferred and the application that generated it). As it expands Internet networks, increasing software complexity and the active introduction of multimedia, there is a need to create a universal format for typing and representing binary data and text containing national characters. Multifunctional extensions have become such a universal format. Internet mail(Multipurpose Internet Mail Extensions or MIME). The MIME format turned out to be extremely successful, since it included the possibility of unlimited expansion of both supported data types and national encodings.

Diagram of a typical SMTP system with POP3 and IMAP4 support

An SMTP message, like an X.400 message, uses the concepts of an envelope and a content, which in turn has a header and a body. Their functional purpose is completely identical. The composition of the fields in the header is determined by the format of the message body (UUENCODE or MIME). No field is required, but fields typically include To:, From:, and Subject. If the MIME format is used, the header must contain the line "MIME-Version: 1.0". A complete list of possible fields in the SMTP message header is contained in RFC 2076.

A distinctive feature of SMTP systems is that, as a rule, they ensure that the transmission process is virtually independent of the content format. Only the client program (mail reader) should be responsible for interpreting the content. However, the cost of compatibility at the MTA level in this case is the inefficiency of transmitting any non-text data or messages using characters of national alphabets due to the preliminary translation of information into a text representation. Depending on the conversion algorithm used, the size of the actual data transferred may increase by 30-100%.

An important problem when transmitting data via SMTP systems is ensuring confidentiality. Since messages are transmitted in text form, they can be easily intercepted and arbitrarily modified. To solve problems with information security, a standard was created for encrypting the message body, the so-called secure multifunctional mail extensions (Secure MIME or S/MIME). However, this protocol is not able to protect message headers from interception.

Simple Mail Transfer Protocol is independent of the transport medium and can be used to deliver mail over networks with protocols other than TCP/IP and X.25. This is achieved through the concept of IPCE (InterProcess Communication Environment). IPCE allows processes that support SMTP to communicate in an interactive mode rather than in a "STOP-GO" mode.

Protocol model. Interaction within SMTP is based on the principle of two-way communication, which is established between the sender and recipient of an email message. In this case, the sender initiates the connection and sends requests for service, and the recipient responds to these requests. In fact, the sender acts as a client, and the recipient acts as a server.

SMTP protocol interaction scheme

The communication channel is established directly between the sender and recipient of the message. With this interaction, mail reaches the subscriber within a few seconds after sending.

Commands are text strings ending in a sequence. A command, as such, is a string of letters (usually 4 letters) terminated by a space (if parameters are present) or. SMTP recipients are advised to be tolerant of spaces before the trailing sequence.

List of SMTP protocol commands:

Commands directly specified in RFC 5321:

• EHLO (or standard - HELO) Opens an invitation from the client. These commands are used to present the SMTP client to the SMTP server. The arguments field contains the fully qualified domain name of the SMTP client, if such a name is available. In cases where the SMTP client does not have a meaningful domain name (for example, when addresses are dynamically allocated and reverse translation is not available), clients SHOULD pass the full address. Although servers must respond to both of these commands, it is better to use the EHLO command, since servers that do not support advanced SMTP services will always return an error message in response to EHLO.

Example:
HELO orsi1.rsmc.ru

• MAIL - Identifies the sender of the message. The arguments field contains the return path and may include additional parameters. Actually, this command specifies the sender of the letter (MAIL FROM)

Example:
MAIL FROM:

• RCPT - Specifies message recipients. Multiple users can receive the same message. Typically, each recipient is specified on a separate line with the RCPT command.

Example:
RCPT TO: root@site

• DATA - Identifies the beginning of the message. Does not support parameters. After processing the MAIL and RCPT commands, the DATA command is used to transmit the information part of the message. Everything that follows this command is interpreted as a message to be transmitted. Here it is, our letter! 

Example:
DATA

• RSET - Reset SMTP connection pa. Does not support parameters. Returns the session to the moment after the HELO (EHLO) command was issued, with all previously sent MAIL, RCPT and DATA commands considered invalid.
• VRFY - Verifies the system username. If on mail server there is a local user with given name, then the server will return its full mailing address. If such local user no, then an error message will be returned, or a message stating that the server will forward the letters further. If the name given in the example is used, we will most likely receive an error message.

Example:
VRFY kyrych

• EXPN - Requests a list of mailing lists and mail aliases.

Example:
EXPN mail-list

• HELP - Requests a list of commands supported by the server. If you specify a command name as a parameter, the server returns help on the syntax of this command

Example:
HELP VRFY

• NOOP - No operation - Do nothing.

Example:
NOOP

• QUIT - End the SMTP session. Does not support parameters.

Example:
QUIT

Other commands:

• SEND - Sends a message to the registered user's terminal. This command is only executed if the user is logged in and usually appears as a pop-up message. Not the most popular team.
• SOML - If the recipients of the message are connected to the system, then SOML works like the SEND command. If not connected, then as the MAIL command. Due to the insecurity of this command, it is rarely implemented on the server.
• SAML - transmits a message to the user's terminal if he is logged in and simultaneously puts this message in his mailbox.
• TURN - Role reversal in SMTP (client becomes server). Typically, SMTP only forwards messages in one direction over a single TCP connection. The purpose of the TURN command is to organize a two-way exchange by mail between two computers over an existing TCP connection. Due to the popularity of this command among attackers, its implementation can not often be found on the server.
• AUTH - Shows the server the authentication mechanism. RFC 4954 (replaced RFC 2554).

• Forward

Add a comment

• Telemetry in Windows 10. Disable it, don’t disable it, you’ll still get the best solution
• Go. The computer was able to beat the champion of the three-time European champion in the game Go
• New "gifts" from Microsoft - "stability" and "privacy"

New articles

• Network discovery does not turn on in Windows 7/8/2008/2012
• Error: This application failed to start because it could not find or load the Qt platform plugin "windows".

  So, after installation by directly copying an application written in C++ using the Qt library, we get the following error: This application failed to start...