Standard smtp port. What is an SMTP server and why use it? Restrict access by location

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 full Domain name 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 Extra options. 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 there is a local user on the mail server 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 - sends a message to the user's terminal if he is logged in and at the same time 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 of email messages 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 following error: This application failed to start...

(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 typically 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 messages to the mail server on port 587. Although legacy mail providers still allow the use 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 all actions on the Internet are made possible thanks to protocols - special network rules. software, which allow the computer to communicate with all networks so that users can shop, read 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 ( network computer, which 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 determine 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 necessary. 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 email servers now support Extended Simple Mail Transfer Protocol (ESMTP), which allows you to transfer multimedia files as email.

Story

In the 1960s, various forms of electronic messaging were used. Users communicated using systems built for specific mainframe computers. Because everything more computers became interconnected, there was a need to develop standards that would allow users different systems 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 through the 1970s until ARPANET became the modern Internet in 1980. Then Jon Postel proposed a protocol for transferring mail data.

SMTP began to be widely used in the early 1980s. At that time, this protocol was a Unix add-on for the Unix Copy Program mail program. SMTP is better generally works when the sending and receiving machines are connected to the Network, use a storage and sending 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 different settings on the same computer. Local processing can either be done on a single machine or shared across multiple machines. Mail agent processes on the same machine can exchange files, but if processing is running on multiple machines, they pass messages among themselves 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 sender of mail communicates with by postal 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. At normal use The mail is sent to the target mail server, such as the SMTP server of the mail port. 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 who 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 is critical to proper operation mail relay has been deleted.

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 ASCII character set, experienced difficulty requiring a Latin email address (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 multi-byte 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 this time, but there is great interest in widespread adoption of RFC 6531 and related RFCs in countries such as 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 the 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 alternative system, requiring 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 smtp ssl ports instead. 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 fully qualified 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 the SSRE keyword of the ESMTP extension to query the server for maximum size message that will be received. Old clients and servers may attempt to transmit oversized messages that will be rejected after use 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 email spam and phishing.

Special proposals are being made to change SMTPs or replace them completely. One example of this is Internet Mail 2000, 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.

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 distribution 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 your mail client to work on the IMAP or POP3 protocol.

What is it used for?

This is the standard mail protocol today. All mail programs and servers use it.

Shared hosting sites 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. At working session both the client and the server exchange the necessary parameters.

A protocol operation includes a combination consisting of the following sequences of 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 others work postal protocols.

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.

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

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

SMTP (Simple Mail Transfer Protocol) is a network protocol designed for transmitting email over TCP/IP networks. ESMTP (English Extended SMTP) is a scalable extension of the SMTP protocol. Currently, the “SMTP protocol” usually refers to ESMTP and its extensions. SMTP uses TCP Ports 25.

The SMTP protocol uses simple text commands in ASCII format and returns three-character encoded responses with text messages. The SMTP protocol is described in Internet Request For Comment (RFC) number 821, which was developed by the Internet Engineering Task Force (IETF) and published on August 21, 1982. Since then, it has undergone several modifications, but in general the basic commands of the protocol have not changed.

Basic SMTP Client Commands HELO Command

By definition, SMTP protocol commands are four characters long. The greeting sent by the client to the server is the HELO command. The command format is as follows:

HELO domain name

The purpose of the HELO command is to present the client to the SMTP server. Unfortunately, this access method was developed at the initial stage of the development of the Internet, when there was not yet so much large number attempts of unauthorized entry into computer systems. As you can see, the client can call himself by any name in command line. This has led to the fact that currently most SMTP servers use this command purely formally. If they do try to identify the client, then a reverse DNS lookup mechanism is activated to determine the client's actual Domain Name System host name from its IP address. Typically, for security reasons, SMTP servers will refuse connections to hosts whose IP address does not resolve to a corresponding hostname. Sending this command

, the client notifies the server that it wants to establish a connection with it. By responding to this command, the server, in turn, notifies that a new connection has been established with the client and is ready to accept subsequent commands from it.

When working with the SMTP protocol, you must distinguish between SMTP clients. Client users and client hosts are not the same thing.

When creating an email message, the user of the email system is also a client of his local host. Once the mail message is sent, it is no longer a client of the SMTP process. Now his local host computer handles the message delivery process and acts as an SMTP client itself. When a local host connects to a remote host to transmit a message using the SMTP protocol, it acts as a client of the SMTP process. The HELO command advertises the name of the local host as the client, not the actual user who sent the message. Quite often these concepts are confused, which makes it difficult to solve problems that arise in email systems.

AUTH command

Extending an SMTP conversation with the AUTH command is described in RFC 4954.

PLAIN (Uses Base64 encoding.)

GSSAPI (Generic Security Services Application Program Interface)

DIGEST-MD5 (Digest access authentication)

The only difference between PLAIN and LOGIN is that in the first option the login + password is transmitted in one line, and in the second option - first the login, then the password. But all of them are necessarily encoded in Base64. MAIL command The MAIL command is used to initiate an email session with the server after the HELO command has been sent. It indicates who it comes from

this message

The reverse-path argument not only specifies the sender of the message, but also specifies the route through which the message can be returned if it cannot be delivered. If the sender is the user on the client computer that initiated the SMTP session, then the command format will be as follows:

MAIL FROM: [email protected]

Note that the FROM field specifies the email address of the message sender, including full name client host computer. This information must be present in the FROM field of the mail message (but more on that later). If the mail message passed through several nodes on the way from the sender to the recipient, then each of them will add information about themselves in the field. This way the path of the message through the mail servers is documented. Quite often, email from private network clients must pass through several email servers before reaching the Internet. The information contained in the reverse-path field is often useful in troubleshooting problems in email systems or in identifying mail servers that are trying to hide their identity by sending messages through unknown SMTP servers.

Team RCPT

The RCPT command specifies the recipients of a message. Multiple users can receive the same message. Typically, each recipient is specified on a separate line with the RCPT command. The RCPT command format is as follows:

RCPT forward-path

The forward-path argument specifies where the email is forwarded. Typically this will include the full email address, but may also include the local SMTP server username. Consider for example the following command:

RCPT TO: haley

This command specifies that the message should be sent to user haley on the SMTP server that processes the messages. In the same way, you can send messages to users of other computers who are not users of the SMTP server to which the message is sent. Consider, for example, the following command:

RCPT TO: [email protected]

A command sent to an SMTP server named shardrach.smallorg.org forces the server to decide whether to deliver the message. Since the user is not registered on local server shardrach, then the server will have to determine what to do with the message next. In this case, there are three possible actions for the shardrach host. Let's take a closer look at them.

The shardrach host can forward the message to the recipient and return an affirmative response to the sender (OK). In this case, it adds its name to the MAIL command field so that it can be included in the message path when it needs to notify the sender.

The host shardrach is unable to forward the message and notifies the sender, while confirming that the host address meshach.smallorg.org is correct. So the sender can try to resend the message directly to meshach.smallorg.org.

The host shardrach cannot forward the message and sends a notification that this operation cannot be performed with this server. Then the reasons for what happened should be analyzed by the system administrator.

In the early days of the Internet, the practice was to send email messages blindly between computers around the world that used the original email messaging algorithm.

DATA command

This command is the main one in the SMTP protocol. After processing the MAIL and RCPT commands, the DATA command is used to transmit the information part of the message. The DATA command format is as follows:

Everything that follows this command is interpreted as a message to be transmitted. The SMTP server typically appends the message header with a timestamp and return-path information. The client program indicates the end of the message by passing a line followed by a single dot. The format of this line is as follows:

Having received this sequence, the SMTP server "understands" that the transmission of the message is complete and should return a response code that will notify the client that its message has been accepted.

SEND command

The SEND command is used to send mail messages directly to the terminal of the registered user of the system. This command is executed only when the user is logged in and is usually a pop-up message, similar to the write command in UNIX. This command has a serious drawback: with its help, an external user can easily determine who is currently logged in to the system. This “opportunity” has long been actively exploited by hackers to obtain Internet user IDs from unsuspecting victims logged into the system. Due to security concerns, most SMTP software packages today no longer contain this command.

RSET command

The RSET command is short for reset. If the client becomes confused about the responses it receives from the server, or decides that the connection has been lost, it can send an RSET command and return the session to its starting point - executing the HELO command. In this case, all previously sent commands - MAIL, RCPT and DATA will be canceled. Very often this command is used as a " last resort" when the client either lost the command sequence or received an unexpected response from the server.

VRFY

The VRFY command is short for verify. It can be used to determine whether a server can deliver mail to a specific recipient before executing the RCPT command. The format of this command is as follows:

VRFY username

Upon acceptance of this command, the SMTP server determines whether it has a user with the specified name on its local server. If such a user is found, the server will return a response with the full postal address user. If there is no such user on the local server, then the SMTP server can either return a negative response to the client or indicate that it will forward all messages to a remote user. This depends on whether the SMTP server will forward messages to the remote client.

The VRFY command may be effective tool when troubleshooting email problems. Quite often, when sending email messages, users misspell the destination or host name and then wonder why their messages were not received. Of course, the first thing they will do is complain to the email system administrator about the terrible performance of the email system. As an email system administrator, you can check the functionality of email addresses in two ways. First, using the DNS host command, which allows you to determine the correctness of the domain name and the presence of a mail server serving the domain. And secondly, you can telnet to port 25 of the mail server and then issue the VRFY command, which will determine the correct username. Listing 5.3 shows an example of using the VRFY command to validate usernames.

1 [riley@ shadrach riley] $ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is "^]" . 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/ 8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you 8 VRFY rich 9 250< rich@ shadrach,smallorg.org>10 VRFY prez@ mechach.smallorg.org 11 252< prez@ mechach.smallorg.org>12 VRFY jessica 13 550 jessica... User unknown 14 QUIT 15 221 shadrach.smallorg.org closing connection 16 Connection closed by -foreign host. 17 [riley@shadrach riley]$

Lines 8-13 show the output of the VRFY command. Line 8 attempts to perform a VRFY on the local user rich. The SMTP server response on line 9 confirms that a user with that name exists in the system, and the client's full email address is returned. Line 10 shows another option for specifying the VRFY command. Here the client is trying to issue a VRFY command to the user on remote computer. The response received on line 11 from the shadrach system is different from the result received on line 9. The Server Responses section discusses the meaning of the codes returned by the server in more detail. In our case, note that the shadrach system notifies the client that mail will be forwarded to the user prez on the remote server meshach.smallorg.org. Line 12 shows an attempt to check a non-existent name in the meshach system. The SMTP server's response on line 13 is self-explanatory.

Check user existence using bash and curl. $ echo -e "VRFY [email protected]\n QUIT" | curl telnet:// mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 username@ example.com 221 2.0.0 Bye

NOOP Team

The NOOP command is short for no operation. This command has no effect on the SMTP server except that the server returns a positive response code to it. It is used when testing a connection without forwarding a message.

QUIT command

The QUIT command does exactly what it says, i.e. informs the SMTP server that the client computer has finished current session and wants to close the connection. The SMTP server must respond to this command and then initiate and close the TCP connection. If the server accepts the QUIT command while transmitting mail, then all data transmitted during the session must be destroyed and will not reach the recipient.

Message format (EMail)

Standard header fields according to RFC 822

RFC 822 requires that a message be split into two parts. The first part is called the header. All data identifying the message is entered into it. The second part is called the body of the message. The header consists of data fields that are used as additional information is needed in the message. The header fields and body of the message must be separated by a blank line. There is no specific order for header fields, i.e. The header fields can be placed in any order. Additionally, header fields may be repeated within the same message. The figure shows general form mail message that meets the requirements of RFC 822.

Message format according to RFC 822

Received header field

The Received: header field format is as follows:

Received: from host name by host name via physical-path with protocol id message-id for final e-mail destination

The Received header field is used to identify the SMTP servers that were involved in the process of delivering the message from the sender to the recipient. Each server adds its own Received field to the mail message, indicating specific information about itself. The subfields in the Received field indicate the path, protocol, and computers that participated in the transmission of the message.

Return-Path header field

The format of this header field is as follows:

Return-Path: route

The last SMTP server in the forwarding chain adds a Return-Path field to the message. Its purpose is to determine the route through which the message reached the recipient. If the message was sent directly to the recipient's server, only one address will be displayed in this field. Otherwise, a complete list of servers through which the message passed to reach the recipient will be displayed here. May differ from MAIL FROM (that is, the return address may be specified different from the sender's address).

Originator header field

The Originator field indicates the address of the message sender. This information is very useful in situations where messages have been rejected several times by private networks before they reach the Internet. The format of this field is as follows:

Reply-To: address

The Originator field is just a small auxiliary field in the multi-colored header fields. It can be used as an easier path for small SMTP packets. This eliminates the need for more complex header fields that identify the sender.

Resent header field

The Resent header field identifies a mail message that for some reason had to be resent by the client. The format of this field is as follows:

Resent-Reply-To: address

Authentic header fields

The header field data identifies the sender of the email message. Authentic fields format:

From: user-name Sender: user-name

The From: field identifies the author of the message. Typically the From: and Sender: fields are the same user, so only one of these fields is actually required. In the case where the sender of the mail is not the author of the message, but it is only sent from his address, both fields must still be specified - this ensures that the message is returned to the sender if delivery to the addressee was impossible. Resent-authentic header fields

The Resent-authentic fields identify the sender of a message that was retransmitted by the client program for some reason. The format of these fields is as follows:

Resent-From: date-time Resent-Sender: date-time The Resent-From: and Resent-Sender: fields work similarly to the From: and Sender: fields. They only reflect that the message was retransmitted by the client for an unknown reason.

Dates header fields

Dates header fields are used to place a timestamp on the message when it is transmitted from the client to the server. The Dates fields have the following format:

Date: date-time Resent-Date: date-time The Date: field will forward the information in the message header exactly as the original message. This option can be useful when tracking the timing of responses, especially multiple responses.

Destination header fields

The Destination header fields indicate the email addresses of the message recipients. These fields are purely informational. The SMTP server will in any case not send a message to the user's mailbox until it receives the RCPT command issued for that user (see the section "Basic SMTP Client Commands"). The format of these fields is as follows:

To: address Resent-To: address CC: address Resent-CC: address BCC: address Resent-BCC: address

The To:, CC:, and BCC: fields set the standard email processing algorithm. Most email packages use this terminology to classify message recipients. CC field: Similar to a memo, and the recipients specified in it should receive a "copy" of the message. Another new concept introduced by email systems is BCC: or blind carbon copy. The "invisible copy" field also indicates the recipient of a copy of the message, but his address is not visible to outsiders (this is not entirely ethical). There has been some debate about this option regarding computer ethics, but today almost all e-mail programs support this feature.

Optional header fields

Optional fields are fields that identify the message in more detail to the SMTP server, but, according to RFC 822, may not be present in the message. However, these fields are now widespread and many of you will have to deal with them. The format of some of them is as follows:

Message-ID: message-id Resent-Message-ID: message-id In-Reply-To: message-id References: message-id Keywords: text - list Subject: text Comments: text Encrypted: word

The most useful and frequently used of this set is the Subject: field. Most email programs allow the sender to enter a one-line subject line that describes the contents of the message to the recipient. This line of text is quite often used by mail client programs when generating lists of received messages. Another optional field also helps identify the mail message. This field is Message-ID: (Message Identifier). This field assigns a unique message to the message. an identification number, which can then appear in the returned message. Special encryption field Encrypted: indicates whether the message has been encrypted for security purposes, and in Keywords: can be set keywords, which can be used when searching for specific text found in a message(s).

Binary data and MIME

The MIME encoding algorithm takes into account the type of binary file being converted and also provides additional information about the file to the decoder. The MIME algorithm allows binary data to be placed directly into a standard mail message, as specified by RFC 822. Five new header fields have been created to describe the binary data embedded in an RFC 822 format message. Mail programs that support the MIME standard must handle all of these new header types correctly.

MIME-Version header field

The first of the optional header fields contains the MIME version that the sender used when encoding the message. Currently this field is always 1.0.

Content-Transfer-Encoding field

The Content-Transfer-Encoding header field specifies how binary data is enclosed in an ASCII text message. There are currently seven different ways to encode binary data, but base64 encoding is the most common. This encoding method converts 6-bit blocks of binary data into 8-bit blocks that are read as ASCII text.

Content-ID field

This header field is used to identify MIME sessions by a specific ID code when the content is complex.

Content-Description field

The Content-Description header field is used to text description in ASCII format of data placed in the mail message. This is useful when sending documents created using a word processor or graphics that are no different if base64 encoded.

Content-Type header field

This title field is where the main action of our play takes place. This field identifies the data contained in the MIME message. There are currently seven main data classes identified in MIME. Each class has its own subclasses, which characterize in more detail the type of data contained in the message.

The text data type identifies ASCII data that should be read in its raw form. There are also two subclasses here - plain-text, i.e. unformatted ASCII text, and enriched text, which includes formatting elements similar to enriched text text format. Latest programs For working with email, they can even work with rich text format (RTF).

The message data type allows an email program to send simple messages in RFC 822 format. Subclasses of this type are: rfc822, which indicates that the attachment is a regular message that conforms to RFC 822; partial, which allows you to break long messages into multiple parts, and external-body, which allows you to place a pointer to an object that is not part of the message.

The image data type specifies the attachment of binary data to a message, which represents graphic image. There are currently two subclasses defined for this type - jpeg and gif.

The video data type, accordingly, specifies that the data attached to the message is video data. There is currently only one subclass defined for this type, the mpeg format.

The audio data type designates the message content as audio data ( sound files). Here, too, only one basic subclass has been defined so far, which corresponds to one ISDN channel with a sampling frequency of 8 KHz.

The application data type corresponds to binary data attached to a message that is an application (for example, electronic Microsoft tables Excel or documents created using a word processor Microsoft Word). To date, two subclasses of this type of data have been defined - postscript and octet-stream. Quite often the octet-stream subclass is used when attaching application data to a message, such as Microsoft Word documents or spreadsheets. Microsoft Excel.

The multipart data type identifies messages containing several different data types. This format is quite common in email programs that support message output in several ways, such as ASCII text. HTML text or audio file. A boundary identifier separates different types of data. At the same time, each data type is identified by a specific data type header field. The multipart data type has four subclasses.

The mixed subclass indicates that each part of the message is independent and should all be presented to the recipient in the order in which they were inserted by the sender. The parallel subclass indicates that each part of the message is independent and all of them can be presented to the recipient in any order. The following alternative subclass specifies that all parts of the message are the same data, but presented in in various forms. In this case, the recipient can choose the best means to view the received data. The digest subclass is similar in many ways to the mixed subclass, but specifies that the message body is always represented in RFC822 format.

1 $ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hello localhost, pleased to meet you 8 MAIL FROM:rich@localhost 9 250 rich@localhost... Sender ok 10 RCPT TO: rich 11 250 rich... Recipient ok 12 DATA 13 354 Enter mail, end with "." on a line by itself 14 From:"Rich Blum" 15 To:"rich" 16 Subject:Formatted text message test 17 MIME-Version: 1.0 18 Content-Type: multipart/alternative; boundary=bounds1 19 20 –bounds1 21 Content-Type: text/plain; charset=us-ascii 22 23 This is the plain text part of the message that can 24 be read by simple e-mail readers. 25 26 –-bounds1 27 Context-Type: text/enriched 28 29 This is the rich text version of the SAME message. 30 31 –-bounds1-- 32 . 33 250 MAA04305 Message accepted for delivery 34 QUIT 35 221 shadrach.smallorg.org closing connection 36 Connection closed by foreign host. 37 You have new mail in /var/spool/mail/rich 38 $

Listing 5.6. Example SMTP Session with Multiple MIME Attachments (html, txt) The example message shown in Listing 5.6 is a MIME message that has two parts. Line 18 shows the data type of the message. The multipart/alternative type indicates that the message contains different types of data that are separated by the bounds1 delimiter. The first type of data starts at line 21 and is simple ASCII text that can be read by almost any email program.

The second type of data starts at line 27 and is rich text using a rich text format.

Since the MIME type specified for the message is multipart/alternative, it is entirely up to the email program to determine which version of the attachment to display.

Enhanced SMTP Protocol

Since its introduction in 1982, the SMTP protocol has done an excellent job of sending messages between computers on the Internet. However, over time, the limitations inherent in the protocol became noticeable. Then, instead of replacing the standard protocol, which was widely used by that time, it was decided to improve some of the functions of the SMTP protocol. At the same time, it was decided to leave all SMTP specifications in their original form and only add new functions to them.

In 1995, RFC 1869 was released, which defined a method for extending the capabilities of the SMTP protocol, called Enhanced SMTP Services.

Extended SMTP is implemented as follows. At the beginning of an SMTP session, the HELO command has been replaced with an invitation command - EHLO. When the SMTP server receives such a command, it means that the client can send extended SMTP commands to it. Listing 5.7 shows an example session using EHLO as well as additional commands.

1 $ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 16:36:48 -050 6 EHLO localhost 7 250-shadrach.smallorg.org Hello localhost, pleased to meet you 8 250-EXPN 9 250-VERB 10 250-8BITMIME 11 250-SIZE 12 250-DSN 13 250-ONEX 14 250-ETRN 15 250-XUSR 16 250 HELP 17 HELP DSN 18 214-MAIL FROM: [ RET=( FULL || HDRS) ] [ ENVID= ] 19 214-RCPT TO: [ NOTIFY=(NEVER, SUCCESS,FAILURE,DELAY) ] 20 214- [ ORCPT= ] 21 214- SMTP Delivery Status Notifications. 22 214-Descriptions: 23 214- RET Return either the full message or only headers. 24 214- ENVID Sender"s "envelope identifier" for tracking. 25 214- NOTIFY When to send a DSN. Multiple options are OK, comma - 26 214- delimited. NEVER must appear by itself. 27 214- ORCPT Original recipient. 28 214 End of HELP info 29 HELP ETRN 30 214-ETRN [ | @ | # ] 31 214- Run the queue for the specified , or 32 214- all hosts within a given , or a specially-named 33 214- (implementation-specific ). 34 214 End of HELP info 35 QUIT 36 221 shadrach.smallorg.org closing connection 37 Connection closed by foreign host $38.

Line 6 specifies the SMTP command EHLO to connect to the SMTP server. Lines 7–16 display the server's response. Note that the server signals that more commands are available for use, i.e. The session takes place in "extended" mode. One of the new groups of commands is called Delivery Status Notification parameters. These parameters can be used with the MAIL and RCPT commands to display the delivery status of a specific email message. However, for us as administrators of the mail system, the ETRN command is of greatest interest.

The TURN command has already been mentioned earlier. This command is very effective, but unfortunately not safe. To compensate for this shortcoming, RFC 1985 defines a new implementation of the TURN command that provides greater security. The ETRN command allows an SMTP client to issue a request to an SMTP server in order to initiate another SMTP connection with the client to send messages to it. The only difference between the ETRN command and the TURN command is that the request is not to use an existing connection, but to open a new SMTP session. This way, the SMTP server can connect to the client computer using normal DNS name resolution algorithms. In this case, the opening of a new connection is based not on the name under which the client computer is registered on the server, but on the real host name of the client. In this case, if a hacker establishes an unauthorized SMTP connection and uses the ETRN command, the SMTP server will simply establish a new connection with the real client and forward the email to him. As a result, there were no casualties. The ETRN command format is as follows:

Here, the role of name can be either the host name or the domain name (if there is a request to receive mail for the entire domain). The ETRN team is a very good help for an email administrator. If your Internet provider stores mail for your mail server, then using this command you can notify it that it is ready to receive mail collected for you. There are several ways to implement such an algorithm. One of them is to use special program Perl, which comes with the sendmail program. Its work is precisely that after establishing a connection with the Internet provider, it issues the ETRN command with the name of your domain as an argument. Having received this command, the provider's SMTP server initiates another SMTP connection with your local SMTP server (over the same PPP connection) and sends all mail intended for your domain that it has in the queue for sending.

Chances are that most people reading this guide are already familiar with the most commonly used communication technology: email. But have you ever thought about how it actually works? In this article, we will learn how this service works and what POP3, SMTP and IMAP are.

POP3 (Post Office Protocol version 3) is often used to communicate with a remote email server and download messages to a local email client and then delete it on the server, for example Thunderbird. Windows Mail, etc. However, email clients usually offer a choice whether or not to leave copies of messages on the server. If you use multiple devices to send messages, it is recommended to leave this feature enabled, otherwise, on another device you will not have access to sent messages that were not saved on the remote server. It is also worth noting that POP3 is a one-way only protocol, which means that data is taken from a remote server and sent to the local client.

The default POP3 ports are:

Port 110 – port without encryption

Port 995 – SSL/TLS port, also known as POP3S

Step 2 - Differences between POP3 and IMAP, and what are the ports for IMAP?

IMAP (protocol application level to access email), just like POP3 is used to receive email messages on a local client, however, it has a significant difference - only the headers are downloaded emails, the text of the letter itself remains on the server. This communication protocol works in two directions; if changes occur on the local client, they are transmitted to the server. IMAP has become more popular recently as giant email service providers like Gmail have started recommending it instead of POP3.

The default IMAP ports are:

Port 143 – port without encryption
Port 993 – SSL/TLS port, also known as IMAPS

Step 3 - SMTP, the protocol for outgoing email communications

Simple Mail Transfer Protocol (SMTP) is used to communicate with a remote server and then send messages from the local client to the remote server, and ultimately to the message recipient's server. On your email server, this process is controlled by a special service (MTA). It's worth mentioning that SMTP is used solely for sending messages.

SMTP ports:

Port 25 – port without encryption
Port 465 – SSL/TLS port, also known as SMTPS

Conclusion

We hope that you now have a clear understanding of how email protocols work and what ports they use. In this tutorial, we learned what POP3, SMTP and IMAP are and what they are used for. For example, POP3 and IMAP are used for the same purposes, but they approach these tasks differently. IMAP leaves the content of the message on the server, and POP3 downloads it to your computer. Also, we found out what standard ports for SMTP, POP3 and IMAP.