Простой протокол передачи почты (SMTP): история и применение.

Введение

Простой протокол передачи почты (SMTP) — это стандартный коммуникационный протокол Интернета для передачи электронной почты. Почтовые серверы и другие агенты передачи сообщений используют SMTP для отправки и получения почтовых сообщений. Пользовательские почтовые клиенты обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции, и обычно отправляют исходящую электронную почту на почтовый сервер на порту 587 или 465. Для получения сообщений стандартным является IMAP (который заменил более старый POP3), но проприетарные серверы также часто реализуют собственные протоколы, например, Exchange ActiveSync. История SMTP началась в 1980 году, опираясь на концепции, реализованные в ARPANET с 1971 года. Протокол многократно обновлялся, изменялся и расширялся. Современная версия протокола имеет расширяемую структуру с различными расширениями для аутентификации, шифрования, передачи бинарных данных и интернационализированных адресов электронной почты. SMTP-серверы обычно используют протокол управления передачей (TCP) на порту 25 (для незашифрованного текста) и 587 (для зашифрованной связи).

Предшественники SMTP

Различные формы электронной переписки один на один использовались в 1960-х годах. Пользователи общались, используя системы, разработанные для конкретных мэйнфреймов. По мере подключения все большего числа компьютеров, особенно в сети ARPANET, созданной правительством США, были разработаны стандарты, обеспечивающие обмен сообщениями между разными операционными системами. История электронной почты в ARPANET начинается в 1971 году: протокол почтовых ящиков, который не был реализован, но обсуждался в [источнике]; и программа SNDMSG, которую Рэй Томлинсон из BBN в том же году адаптировал для отправки сообщений между двумя компьютерами в ARPANET. В июне 1973 года в RFC 524 было предложено еще одно решение для почтового протокола, которое также не было реализовано. В RFC 469 от марта 1973 года было предложено использовать протокол передачи файлов (FTP) для "сетевой почты" в ARPANET. Благодаря RFC 561, RFC 680, RFC 724 и, наконец, RFC 733 от ноября 1977 года, была разработана стандартизированная структура для "электронной почты" с использованием FTP-серверов. SMTP развился на основе этих стандартов, разработанных в 1970-х годах.

Оригинальный SMTP

В 1980 году Джон Постел и Сюзанна Слуйзер опубликовали работу, в которой предлагалось использовать протокол передачи почты (Mail Transfer Protocol) вместо FTP для отправки почты. В мае 1981 года все упоминания FTP были удалены, а порту 57 были выделены TCP и UDP, что впоследствии было отменено IANA. В ноябре 1981 года Постел опубликовал "Простой протокол передачи почты" (Simple Mail Transfer Protocol). Стандарт SMTP разрабатывался примерно в то же время, что и Usenet – сеть для коммуникации "один ко многим", имеющая некоторые сходства. SMTP получил широкое распространение в начале 1980-х годов. В то время он дополнял программу Unix to Unix Copy Program (UUCP), которая лучше подходила для передачи электронной почты между машинами с периодическим подключением. SMTP, напротив, наиболее эффективен, когда и отправляющая, и принимающая машины постоянно подключены к сети. Оба использовали механизм "храни и пересылай" и являются примерами технологии push. Хотя новостные группы Usenet все еще распространялись через UUCP между серверами, UUCP как транспорт почты практически исчез вместе с "bang paths", которые он использовал в качестве заголовков маршрутизации сообщений. Sendmail, выпущенный вместе с 4.1cBSD в 1983 году, был одним из первых агентов передачи почты (mail transfer agent), реализовавших SMTP. Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал наиболее распространенным MTA. Изначальный протокол SMTP поддерживал только неаутентифицированную, незашифрованную 7-битную текстовую коммуникацию в формате ASCII, уязвимую для простых атак типа "человек посередине", спуфинга и спама, и требовал кодирования любых двоичных данных в читаемый текст перед передачей. Из-за отсутствия надлежащего механизма аутентификации, по замыслу, каждый SMTP-сервер был открытым ретранслятором почты. Internet Mail Consortium (IMC) сообщил, что в 1998 году 55% почтовых серверов были открытыми ретрансляторами, а в 2002 году – менее 1%. Из-за проблем со спамом большинство провайдеров электронной почты блокируют открытые ретрансляторы, что делает оригинальный SMTP практически непригодным для общего использования в Интернете.

Современный SMTP

В ноябре 1995 года был определён расширенный протокол простой передачи почты (ESMTP), который установил общую структуру для всех существующих и будущих расширений, направленных на добавление функций, отсутствующих в оригинальном SMTP. ESMTP определяет последовательные и управляемые средства, с помощью которых клиенты и серверы ESMTP могут быть идентифицированы, а серверы могут указывать поддерживаемые расширения. В 1998 и 1999 годах были введены механизмы отправки сообщений и SMTP AUTH, оба из которых описывают новые тенденции в доставке электронной почты. Изначально SMTP-серверы обычно были внутренними для организации, принимая почту извне и пересылая сообщения от организации наружу. Но со временем SMTP-серверы (агенты передачи почты) на практике расширяли свои роли, становясь агентами подачи сообщений для почтовых клиентских программ, некоторые из которых теперь пересылали почту из-за пределов организации (например, руководитель компании хочет отправлять электронную почту во время поездки, используя корпоративный SMTP-сервер). Эта проблема, ставшая следствием быстрого расширения и популярности Всемирной паутины, означала, что SMTP должен был включать в себя конкретные правила и методы для пересылки почты и аутентификации пользователей, чтобы предотвратить злоупотребления, такие как рассылка нежелательной почты (спама). Работа над механизмом отправки сообщений началась из-за того, что популярные почтовые серверы часто переписывали почту в попытке исправить в ней ошибки, например, добавляя доменное имя к некорректному адресу. Такое поведение полезно при первоначальной подаче сообщения, но опасно и вредно, когда сообщение поступило из другого источника и пересылается. Чёткое разделение подачи и пересылки рассматривалось как способ разрешить и поощрить переписывание при подаче, запрещая переписывание при пересылке. По мере распространения спама это также рассматривалось как способ обеспечить авторизацию отправки почты из организации и обеспечить её отслеживаемость. Это разделение пересылки и подачи быстро стало основой современных практик безопасности электронной почты. Поскольку протокол изначально был основан исключительно на ASCII-тексте, он плохо обрабатывал бинарные файлы и символы многих неанглийских языков. Стандарты, такие как многоцелевые расширения интернет-почты (MIME), были разработаны для кодирования бинарных файлов для передачи через SMTP. Агенты передачи почты (MTA), разработанные после Sendmail, также, как правило, реализовывались с поддержкой 8-битной кодировки, что позволяло использовать альтернативную стратегию "просто отправь 8 бит" для передачи произвольных текстовых данных (в любой 8-битной кодировке, подобной ASCII) через SMTP. Проблема искажения символов (Mojibake) всё ещё существовала из-за различных таблиц кодировки символов у разных производителей, хотя сами адреса электронной почты по-прежнему допускались только в ASCII. Современные MTA с поддержкой 8-битной кодировки обычно поддерживают расширение 8BITMIME, позволяющее передавать некоторые бинарные файлы почти так же легко, как обычный текст (ограничения на длину строки и допустимые значения октетов всё ещё действуют, поэтому кодирование MIME необходимо для большинства нетекстовых данных и некоторых текстовых форматов). В 2012 году было создано расширение SMTPUTF8 для поддержки текста в кодировке UTF-8, что позволило использовать международный контент и адреса на языках, использующих нелатинские шрифты, таких как кириллица или китайский. Многие люди внесли вклад в разработку основных спецификаций SMTP, среди них Джон Постел, Эрик Оллман, Дэйв Крокер, Нед Фрид, Рэндалл Гелленс, Джон Кленсин и Кит Мур.

In November 1995, defined Extended Simple Mail Transfer Protocol (ESMTP), which established a general structure for all existing and future extensions which aimed to add in the features missing from the original SMTP. ESMTP defines consistent and manageable means by which ESMTP clients and servers can be identified and servers can indicate supported extensions. Message submission and SMTP AUTH were introduced in 1998 and 1999, both describing new trends in email delivery. Originally, SMTP servers were typically internal to an organization, receiving mail for the organization from the outside, and relaying messages from the organization to the outside. But as time went on, SMTP servers (mail transfer agents), in practice, were expanding their roles to become message submission agents for mail user agents, some of which were now relaying mail from the outside of an organization. (e. g. a company executive wishes to send email while on a trip using the corporate SMTP server.) This issue, a consequence of the rapid expansion and popularity of the World Wide Web, meant that SMTP had to include specific rules and methods for relaying mail and authenticating users to prevent abuses such as relaying of unsolicited email (spam). Work on message submission was originally started because popular mail servers would often rewrite mail in an attempt to fix problems in it, for example, adding a domain name to an unqualified address. This behavior is helpful when the message being fixed is an initial submission, but dangerous and harmful when the message originated elsewhere and is being relayed. Cleanly separating mail into submission and relay was seen as a way to permit and encourage rewriting submissions while prohibiting rewriting relay. As spam became more prevalent, it was also seen as a way to provide authorization for mail being sent out from an organization, as well as traceability. This separation of relay and submission quickly became a foundation for modern email security practices. As this protocol started out purely ASCII text based, it did not deal well with binary files, or characters in many non English languages. Standards such as Multipurpose Internet Mail Extensions (MIME) were developed to encode binary files for transfer through SMTP. Mail transfer agents (MTAs) developed after Sendmail also tended to be implemented 8 bit clean, so that the alternate "just send eight" strategy could be used to transmit arbitrary text data (in any 8 bit ASCII like character encoding) via SMTP. Mojibake was still a problem due to differing character set mappings between vendors, although the email addresses themselves still allowed only ASCII. 8 bit clean MTAs today tend to support the 8BITMIME extension, permitting some binary files to be transmitted almost as easily as plain text (limits on line length and permitted octet values still apply, so that MIME encoding is needed for most non text data and some text formats). In 2012, the SMTPUTF8 extension was created to support UTF 8 text, allowing international content and addresses in non Latin scripts like Cyrillic or Chinese. Many people contributed to the core SMTP specifications, among them Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.

Модель обработки почты

Электронная почта отправляется почтовым клиентом (почтовым пользовательским агентом, MUA) на почтовый сервер (почтовый агент отправки, MSA) с использованием SMTP на TCP-порту 587. Большинство поставщиков почтовых ящиков по-прежнему разрешают отправку на традиционном порту 25. MSA доставляет почту своему агенту передачи почты (MTA). Часто эти два агента являются экземплярами одного и того же программного обеспечения, запущенного с разными опциями на одной и той же машине. Локальная обработка может выполняться либо на одной машине, либо распределяться между несколькими машинами; процессы почтового агента на одной машине могут обмениваться файлами, но если обработка выполняется на нескольких машинах, они передают сообщения друг другу с помощью SMTP, где каждая машина настроена на использование следующей машины в качестве смарт-хоста. Каждый процесс является MTA (SMTP-сервером) по сути. Граничная MTA использует DNS для поиска записи MX (почтовый обменник) для домена получателя (части адреса электронной почты справа от символа @). Запись MX содержит имя целевой MTA. На основе целевого хоста и других факторов отправляющая MTA выбирает сервер получателя и подключается к нему для завершения обмена почтой. Передача сообщений может происходить в виде одного соединения между двумя MTA или в виде серии переходов через промежуточные системы. Принимающий SMTP-сервер может быть конечным пунктом назначения, промежуточным "реле" (то есть он хранит и пересылает сообщение) или "шлюзом" (то есть он может пересылать сообщение с использованием протокола, отличного от SMTP). Согласно разделу 2.1, каждый переход является формальной передачей ответственности за сообщение, при этом принимающий сервер должен либо доставить сообщение, либо должным образом сообщить о неудаче. После того как последний переход принимает входящее сообщение, он передает его агенту доставки почты (MDA) для локальной доставки. MDA сохраняет сообщения в соответствующем формате почтового ящика. Как и при отправке, этот прием может выполняться с использованием одного или нескольких компьютеров, но на диаграмме выше MDA изображен в виде одного блока рядом с блоком почтового обменника. MDA может доставлять сообщения непосредственно в хранилище или пересылать их по сети с использованием SMTP или другого протокола, такого как локальный протокол передачи почты (LMTP), производного от SMTP, разработанного для этой цели. После доставки на локальный почтовый сервер почта хранится для пакетного извлечения аутентифицированными почтовыми клиентами (MUA). Почта извлекается приложениями конечного пользователя, называемыми почтовыми клиентами, с использованием протокола доступа к сообщениям в Интернете (IMAP), протокола, который облегчает доступ к почте и управляет хранимой почтой, или протокола почтовой службы (POP), который обычно использует традиционный формат почтового файла mbox или проприетарную систему, такую как Microsoft Exchange/Outlook или Lotus Notes/Domino. Веб-клиенты почты могут использовать любой из этих методов, но протокол извлечения часто не является формальным стандартом. SMTP определяет транспортировку сообщений, а не их содержимое. Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта, но не заголовок (за исключением информации о трассировке) и не тело самого сообщения. STD 10 и определяет SMTP (конверт), в то время как STD 11 и определяет сообщение (заголовок и тело), формально называемое форматом сообщений в Интернете.

Email is submitted by a mail client (mail user agent, MUA) to a mail server (mail submission agent, MSA) using SMTP on TCP port 587. Most mailbox providers still allow submission on traditional port 25. The MSA delivers the mail to its mail transfer agent (MTA). Often, these two agents are instances of the same software launched with different options on the same machine. Local processing can be done either on a single machine, or split among multiple machines; mail agent processes on one machine can share files, but if processing is on multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a smart host. Each process is an MTA (an SMTP server) in its own right. The boundary MTA uses DNS to look up the MX (mail exchanger) record for the recipient's domain (the part of the email address on the right of @). The MX record contains the name of the target MTA. Based on the target host and other factors, the sending MTA selects a recipient server and connects to it to complete the mail exchange. Message transfer can occur in a single connection between two MTAs, or in a series of hops through intermediary systems. A receiving SMTP server may be the ultimate destination, an intermediate "relay" (that is, it stores and forwards the message) or a "gateway" (that is, it may forward the message using some protocol other than SMTP). Per section 2.1, each hop is a formal handoff of responsibility for the message, whereby the receiving server must either deliver the message or properly report the failure to do so. Once the final hop accepts the incoming message, it hands it to a mail delivery agent (MDA) for local delivery. An MDA saves messages in the relevant mailbox format. As with sending, this reception can be done using one or multiple computers, but in the diagram above the MDA is depicted as one box near the mail exchanger box. An MDA may deliver messages directly to storage, or forward them over a network using SMTP or other protocol such as Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed for this purpose. Once delivered to the local mail server, the mail is stored for batch retrieval by authenticated mail clients (MUAs). Mail is retrieved by end user applications, called email clients, using Internet Message Access Protocol (IMAP), a protocol that both facilitates access to mail and manages stored mail, or the Post Office Protocol (POP) which typically uses the traditional mbox mail file format or a proprietary system such as Microsoft Exchange/Outlook or Lotus Notes/Domino. Webmail clients may use either method, but the retrieval protocol is often not a formal standard. SMTP defines message transport, not the message content. Thus, it defines the mail envelope and its parameters, such as the envelope sender, but not the header (except trace information) nor the body of the message itself. STD 10 and define SMTP (the envelope), while STD 11 and define the message (header and body), formally referred to as the Internet Message Format.

Обзор протокола

SMTP – это протокол, ориентированный на установление соединения и основанный на текстовых командах, в котором отправитель почты взаимодействует с получателем, отправляя команды в виде строк и передавая необходимые данные по надежному, упорядоченному каналу передачи данных, обычно по соединению протокола управления передачей (TCP). SMTP-сессия состоит из команд, инициированных SMTP-клиентом (инициатор, отправитель или передатчик), и соответствующих ответов от SMTP-сервера (слушатель или получатель), в результате чего сессия открывается и происходит обмен параметрами сессии. Сессия может включать в себя ноль или более SMTP-транзакций. SMTP-транзакция состоит из трех последовательностей команд/ответов: команда MAIL для указания обратного адреса, также называемого обратным путем, адресом для уведомлений о недоставке, mfrom или отправителем конверта; команда RCPT для указания получателя сообщения. Эта команда может быть отправлена несколько раз, по одному разу для каждого получателя. Эти адреса также являются частью конверта. Команда DATA сигнализирует о начале текста сообщения; содержимое сообщения, в отличие от его конверта. Она состоит из заголовка сообщения и тела сообщения, разделенных пустой строкой. DATA фактически представляет собой группу команд, и сервер отвечает дважды: один раз на саму команду DATA, чтобы подтвердить готовность к приему текста, и второй раз после завершения последовательности данных, чтобы принять или отклонить сообщение целиком. Помимо промежуточного ответа на DATA, ответ каждого сервера может быть положительным (коды ответа 2xx) или отрицательным. Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx). Отклонение – это необратимая ошибка, и клиент должен отправить сообщение о недоставке на сервер, от которого он его получил. Отказ – это положительный ответ, за которым следует удаление сообщения без доставки. Инициирующий хост, SMTP-клиент, может быть либо почтовым клиентом конечного пользователя, функционально идентифицируемым как почтовый агент пользователя (MUA), либо агентом передачи почты ретрансляционного сервера (MTA), то есть SMTP-сервером, действующим как SMTP-клиент в данной сессии для пересылки почты. Полностью функциональные SMTP-серверы поддерживают очереди сообщений для повторных попыток передачи сообщений, завершившихся временными сбоями. MUA узнает исходящий SMTP-сервер из своей конфигурации. Релейный сервер обычно определяет, к какому серверу подключиться, путем поиска DNS-записи MX (Mail eXchange) для доменного имени каждого получателя. Если запись MX не найдена, соответствующий релейный сервер (не все такие) вместо этого ищет запись A. Релейные серверы также могут быть настроены на использование смарт-хоста. Релейный сервер инициирует TCP-соединение с сервером на "известном порту" для SMTP: порт 25 или для подключения к MSA, порт 587. Основное различие между MTA и MSA заключается в том, что для подключения к MSA требуется SMTP-аутентификация.

SMTP is a connection oriented, text based protocol in which a mail sender communicates with a mail receiver by issuing command strings and supplying necessary data over a reliable ordered data stream channel, typically a Transmission Control Protocol (TCP) connection. An SMTP session consists of commands originated by an SMTP client (the initiating agent, sender, or transmitter) and corresponding responses from the SMTP server (the listening agent, or receiver) so that the session is opened, and session parameters are exchanged. A session may include zero or more SMTP transactions. An SMTP transaction consists of three command/reply sequences:

MAIL command, to establish the return address, also called return path, reverse path, bounce address, mfrom, or envelope sender. RCPT command, to establish a recipient of the message. This command can be issued multiple times, one for each recipient. These addresses are also part of the envelope. DATA to signal the beginning of the message text; the content of the message, as opposed to its envelope. It consists of a message header and a message body separated by an empty line. DATA is actually a group of commands, and the server replies twice: once to the DATA command itself, to acknowledge that it is ready to receive the text, and the second time after the end of data sequence, to either accept or reject the entire message. Besides the intermediate reply for DATA, each server's reply can be either positive (2xx reply codes) or negative. Negative replies can be permanent (5xx codes) or transient (4xx codes). A reject is a permanent failure and the client should send a bounce message to the server it received it from. A drop is a positive response followed by message discard rather than delivery. The initiating host, the SMTP client, can be either an end user's email client, functionally identified as a mail user agent (MUA), or a relay server's mail transfer agent (MTA), that is an SMTP server acting as an SMTP client, in the relevant session, in order to relay mail. Fully capable SMTP servers maintain queues of messages for retrying message transmissions that resulted in transient failures. A MUA knows the outgoing mail SMTP server from its configuration. A relay server typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name. If no MX record is found, a conformant relaying server (not all are) instead looks up the A record. Relay servers can also be configured to use a smart host. A relay server initiates a TCP connection to the server on the "well known port" for SMTP: port 25, or for connecting to an MSA, port 587. The main difference between an MTA and an MSA is that connecting to an MSA requires SMTP Authentication.

SMTP против поиска почты

SMTP — это протокол только для доставки. В обычном режиме почта "отправляется" на почтовый сервер назначения (или на следующий почтовый сервер по пути) по мере поступления. Маршрутизация почты осуществляется на основе сервера назначения, а не отдельных пользователей, которым она адресована. Другие протоколы, такие как протокол POP (Post Office Protocol) и протокол IMAP (Internet Message Access Protocol), специально разработаны для использования отдельными пользователями для получения сообщений и управления почтовыми ящиками. Чтобы разрешить периодически подключающемуся почтовому серверу запрашивать и получать сообщения с удаленного сервера, SMTP имеет функцию инициирования обработки очереди сообщений на удаленном сервере (см. раздел «Запуск очереди удаленных сообщений» ниже). Протоколы POP и IMAP не подходят для ретрансляции почты периодически подключающимися устройствами, поскольку они предназначены для работы после окончательной доставки, когда информация, критически важная для корректной работы ретрансляции почты ("почтовый конверт"), уже удалена.

Начало очереди удаленных сообщений

Remote Message Queue Starting позволяет удаленному хосту инициировать обработку почтовой очереди на сервере, чтобы получать сообщения, адресованные ему, путем отправки соответствующей команды. Изначальная команда TURN была признана небезопасной и была расширена командой ETRN, которая работает более надежно, используя метод аутентификации на основе информации из Domain Name System.

Отправка почты через SMTP-сервер

Клиент электронной почты должен знать IP-адрес своего начального SMTP-сервера, который необходимо указать в его конфигурации (обычно это указывается как DNS-имя). Этот сервер будет отправлять исходящие сообщения от имени пользователя.

Ограничения доступа к исходящему почтовому серверу

Администраторам сервера необходимо установить определенный контроль над тем, какие клиенты могут использовать сервер. Это позволяет им бороться со злоупотреблениями, например, спамом. Два решения широко применялись:

В прошлом многие системы накладывали ограничения на использование, основываясь на местоположении клиента, разрешая доступ только клиентам, IP-адреса которых контролируются администраторами сервера. Доступ с любых других IP-адресов клиентов запрещался. Современные SMTP-серверы обычно предлагают альтернативную систему, требующую аутентификации клиентов с использованием учетных данных перед предоставлением доступа.

Ограничение доступа по месту

В рамках этой системы SMTP-сервер провайдера не разрешает доступ пользователям, находящимся вне сети провайдера. Точнее, сервер может разрешать доступ только пользователям с IP-адресом, выданным провайдером, что равносильно требованию подключения к Интернету через этого же провайдера. Мобильный пользователь часто может находиться в сети, отличной от сети его основного провайдера, и в этом случае обнаружит, что отправка электронной почты невозможна, поскольку выбранный SMTP-сервер стал недоступен. Эта система имеет несколько разновидностей. Например, SMTP-сервер организации может предоставлять услуги только пользователям в пределах одной сети, обеспечивая это с помощью межсетевого экрана, блокирующего доступ из внешнего Интернета. Или сервер может проверять диапазон IP-адресов клиентов. Эти методы обычно использовались корпорациями и учреждениями, такими как университеты, которые предоставляли SMTP-сервер для исходящей почты, предназначенной исключительно для внутреннего использования. Однако большинство из них теперь используют методы аутентификации клиентов, как описано ниже. Для мобильных пользователей, которые могут использовать разных провайдеров для подключения к Интернету, такое ограничение неудобно, а изменение настроек исходящего SMTP-сервера непрактично. Крайне желательно иметь возможность использовать параметры конфигурации почтового клиента, которые не требуют изменений.

Аутентификация клиента

Современные SMTP-серверы обычно требуют аутентификации клиентов с использованием учетных данных перед предоставлением доступа, в отличие от ограничения доступа по местоположению, как было описано ранее. Эта более гибкая система удобна для мобильных пользователей и позволяет им иметь постоянный выбор настроенного исходящего SMTP-сервера. SMTP-аутентификация, часто сокращенно SMTP AUTH, — это расширение протокола SMTP, позволяющее выполнять вход в систему с помощью механизма аутентификации.

Бинарная передача данных

Оригинальный SMTP поддерживает только одно текстовое тело в кодировке ASCII, поэтому любые двоичные данные необходимо кодировать в текст и включать в это тело сообщения перед отправкой, а затем декодировать на стороне получателя. Для этого обычно использовались кодировки, преобразующие двоичные данные в текст, такие как uuencode и BinHex. Команда 8BITMIME была разработана для решения этой проблемы. Она была стандартизирована в 1994 году и обеспечивает прозрачный обмен электронными сообщениями, содержащими октеты, выходящие за пределы семибитного набора символов ASCII, путем кодирования их как частей содержимого MIME, как правило, с использованием кодировки Base64.

Передача почты по запросу

On Demand Mail Relay (ODMR) — это расширение SMTP, стандартизированное в 2003 году, которое позволяет SMTP-серверу с непостоянным подключением получать электронную почту, поставленную в очередь для него, при установлении соединения.

Расширение интернационализации

Оригинальный SMTP поддерживает адреса электронной почты, состоящие только из символов ASCII, что неудобно для пользователей, чьи родные системы письма не основаны на латинице, или которые используют диакритические знаки, отсутствующие в наборе символов ASCII. Это ограничение было смягчено благодаря расширениям, позволяющим использовать UTF-8 в именах адресов. Текущая поддержка ограничена, но существует значительный интерес к широкому внедрению и связанных с ними RFC в таких странах, как Китай, где большая пользовательская база использует системы письма, отличные от латинской (ASCII).

SMTP-AUTH

Расширение SMTP AUTH предоставляет механизм контроля доступа. Оно состоит из этапа аутентификации, в ходе которого клиент фактически авторизуется на почтовом сервере в процессе отправки почты. Серверы, поддерживающие SMTP AUTH, как правило, могут быть настроены на обязательное использование этого расширения клиентами, что обеспечивает установление подлинной личности отправителя. Расширение SMTP AUTH определено в RFC 2554. SMTP AUTH может использоваться для разрешения авторизованным пользователям ретранслировать почту, при этом неавторизованным пользователям, таким как спамеры, в этой услуге будет отказано. Оно не гарантирует подлинность ни отправителя SMTP-конверта, ни заголовка "From:". Например, спуфинг, когда один отправитель выдает себя за другого, все еще возможен при использовании SMTP AUTH, если сервер не настроен на ограничение адресов отправителей сообщения адресами, для которых данный авторизованный пользователь имеет соответствующие права. Расширение SMTP AUTH также позволяет одному почтовому серверу сообщать другому, что отправитель был аутентифицирован при ретрансляции почты. Как правило, это требует доверия получающего сервера к отправляющему, что означает, что данная функция SMTP AUTH редко используется в Интернете.

Расширения безопасности

Доставка почты может осуществляться как в открытом виде, так и по зашифрованным каналам связи, однако стороны, обменивающиеся сообщениями, могут заранее не знать о возможности другой стороны использовать защищенное соединение.

STARTTLS или "Оппортунистический TLS"

Расширение STARTTLS позволяет SMTP-серверам, поддерживающим его, уведомлять подключающихся клиентов о поддержке зашифрованной связи по протоколу TLS и предоставляет клиентам возможность повысить безопасность соединения, отправив команду STARTTLS. Серверы, поддерживающие это расширение, сами по себе не получают никаких дополнительных преимуществ в плане безопасности, поскольку переход к зашифрованной сессии TLS зависит от решения подключающегося клиента воспользоваться этой возможностью, отсюда и термин «оппортунистический TLS». STARTTLS эффективен только против атак пассивного перехвата, поскольку процесс согласования STARTTLS происходит в незашифрованном виде, и злоумышленник может легко удалить команды STARTTLS. Этот тип атаки типа «человек посередине» иногда называют STRIPTLS, когда информация о согласовании шифрования, отправленная с одной стороны, не достигает другой. В этом сценарии обе стороны интерпретируют неверные или неожиданные ответы как признак того, что другая сторона не поддерживает STARTTLS должным образом, и переходят к традиционной передаче почты в незашифрованном виде. Следует отметить, что STARTTLS также определен для протоколов IMAP и POP3 в других RFC, однако эти протоколы служат для разных целей: SMTP используется для связи между агентами передачи сообщений, а IMAP и POP3 – для взаимодействия конечных пользователей и агентов передачи сообщений. В 2014 году Фонд электронных рубежей (Electronic Frontier Foundation) запустил проект «STARTTLS Everywhere», который, подобно списку «HTTPS Everywhere», позволял сторонам находить других участников, поддерживающих безопасную связь, без предварительной координации. Проект прекратил прием новых записей 29 апреля 2021 года, и EFF рекомендовал использовать DANE и MTA STS для получения информации о поддержке TLS у других участников. Официально незашифрованный текст был признан устаревшим, и рекомендуется всегда использовать TLS для отправки и получения почты, включая порты с неявным TLS.

DANE для SMTP

Внедрена возможность для DNS-записей указывать возможности шифрования почтового сервера. Используя DNSSEC, операторы почтовых серверов могут публиковать хеш своего TLS-сертификата, тем самым снижая вероятность незашифрованной связи. Microsoft планирует включить полную поддержку SMTP DANE для клиентов Exchange Online к концу 2024 года.

SMTP MTA строгая безопасность транспорта

Новый стандарт 2018 года под названием "SMTP MTA Strict Transport Security (MTA STS)" призван решить проблему активных злоумышленников, определяя протокол, позволяющий почтовым серверам заявлять о своей способности использовать защищенные каналы связи, публикуя информацию в определенных файлах на сервере и специальных DNS TXT записях. Доверяющая сторона должна регулярно проверять наличие такой записи и кэшировать ее на время, указанное в записи, не осуществляя связь по незащищенным каналам до истечения срока действия записи.

Отчетность SMTP TLS

Протоколы, предназначенные для безопасной доставки сообщений, могут давать сбои из-за неправильной конфигурации или преднамеренных активных помех, что приводит к недоставке сообщений или доставке по незашифрованным или неаутентифицированным каналам. "Отчетность SMTP TLS" описывает механизм и формат для обмена статистикой и конкретной информацией о потенциальных сбоях с доменами-получателями. Домены-получатели могут использовать эту информацию для обнаружения потенциальных атак и диагностики непреднамеренных ошибок конфигурации. В апреле 2019 года Google Mail объявила о поддержке отчетов SMTP TLS. DomainKeys Identified Mail, Sender Policy Framework и DMARC, DNSBL и грейлистинг используются для отклонения или помещения в карантин подозрительных электронных писем.