Просмотр кода страницы SMTP

{{стиль статьи|дата=2023-12-14}}
{{Карточка протокола
|Аббр = SMTP
|Название = Simple Mail Transfer Protocol
|Уровень = Прикладной
|Семейство = TCP/IP
|Порт = 25/TCP, 587/TCP<br>465/TCP (SMTP over SSL)
|Назначение = Отправка электронной почты
|Клиенты = MUA ([[The Bat!]], [[Microsoft Outlook|MS Outlook]], [[MS Outlook Express]], [[Mozilla Thunderbird]], [[Claws Mail]] и др.)
|Серверы = MTA ([[sendmail]], [[postfix]], [[OpenSMTPD]], [[qmail]], [[exim]],  [[Microsoft Exchange Server]], [[Maddy]], [[MDaemon]])
|Спецификация = RFC 5321
|Расширяемость = Доп. команды (RFC 2449)
}}
'''SMTP''' ({{lang-en|Simple Mail Transfer Protocol}} — простой протокол передачи почты) — это широко используемый [[IP|сетевой протокол]], предназначенный для передачи [[Электронная почта|электронной почты]] в сетях [[TCP/IP|TCP]]/[[IP]].

SMTP впервые был описан в RFC 821 (1982 год), последнее обновление в RFC 5321 (2008) включает масштабируемое расширение — '''ESMTP''' ({{lang-en| Extended SMTP}}). В настоящее время под «протоколом SMTP» подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием [[Порт (TCP/IP)|порта]] [[TCP]] 25.

В то время как электронные [[Почтовый сервер|почтовые серверы]] и другие агенты пересылки сообщений используют SMTP для отправки и получения почтовых сообщений, работающие на пользовательском уровне клиентские почтовые приложения обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо [[POP3|POP]] ({{lang-en|Post Office Protocol}} — протокол почтового отделения), либо [[IMAP]] ({{lang-en|Internet Message Access Protocol}}), либо патентованные системы (такие как Microsoft [[Microsoft Exchange Server|Exchange]] и [[IBM Lotus Notes|Lotus Notes]]/[[Lotus Domino|Domino]]) для доступа к учётной записи своего почтового ящика на сервере.

== История ==
В 1960-х годах использовались различные виды электронной связи. Люди общались друг с другом с помощью систем, разработанных для определенных [[мэйнфрейм]]ов. По мере того как все больше и больше [[компьютер]]ов соединялись между собой, особенно в правительственной сети [[Соединённые Штаты Америки|США]] [[ARPANET]], были разработаны стандарты, позволяющие пользователям разных систем писать друг другу [[Электронная почта|электронные сообщения]]. Эти стандарты, разработанные в 1970-х годах, стали основой для SMTP.

Корни SMTP можно проследить в двух описанных в 1971 г. реализациях — Mail Box Protocol и SNDMSG, который был «изобретён» [[Томлинсон, Рэй|Рэем Томлинсоном]] из BBN Technologies для TOPS-20/TENEX-компьютеров, посылающих сообщения по [[ARPANET]] (в то время к ней были подсоединены менее 50 [[хост]]ов).

Дальнейшие реализации включают [[FTP]] Mail и Mail Protocol, разработанные в 1973 году. Развитие продолжалось в течение 1970-х годов, пока в 1980 году [[ARPANET]] не превратилась в современный [[Интернет]]. В том же году [[Постел, Джонатан Брюс|Джон Постел]] предложил протокол Mail Transport Protocol, благодаря которому FTP перестал быть основой для передачи почты. SMTP опубликован в RFC 821 (также написанном Постелом) в августе 1982 г.

Стандарт SMTP был разработан примерно в то же время, что и [[Usenet]], сеть передачи данных, имеющая некоторое сходство с SMTP. SMTP стал широко использоваться в начале 1980-х годов. В то время он был дополнением к почтовой программе Unix to Unix CoPy (UUCP), которая больше подходила для передачи электронных сообщений между периодически подключаемыми устройствами. SMTP, с другой стороны, отлично работает, когда устройства отправки и получения постоянно связаны в сети. Оба устройства используют механизм хранения и пересылки и являются примерами технологии push. Хотя группы новостей Usenet все еще распространяются между серверами с помощью UUCP, почта UUCP фактически исчезла вместе с маршрутом "bang path" (последовательность хост-машин в сети, через которые сообщение должно достичь места назначения), который использовался в качестве заголовков маршрутизации. В статье о перезаписи отправителя содержится техническая справочная информация об истории раннего SMTP и маршрутизации от источника до RFC 1123.

Sendmail был одним из первых (если не первым) агентом обмена сообщениями, реализовавшим SMTP. Среди других популярных серверных программ, поддерживающих SMTP, - Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server и Sun Java System Messaging Server.

Message Submission, как определено в RFC 2476, и SMTP-AUTH, как описано в RFC 2554. Эти новаторские концепции были представлены в 1998 и 1999 годах, соответственно, и с тех пор произвели революцию в способах передачи электронных сообщений.

На раннем этапе развития SMTP-серверы преимущественно функционировали в пределах локальных сетей организаций. Их основной задачей было обеспечение шлюзового взаимодействия: получение входящих сообщений от внешних отправителей и передача исходящей корреспонденции организации. В процессе эволюции данные серверы, традиционно называемые агентами пересылки сообщений (MTA), значительно расширили свой функционал. Постепенно они трансформировались в полноценные агенты доставки сообщений (MDA), интегрируясь со специализированными почтовыми приложениями.

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

Данный вопрос, являясь следствием быстрого развития и популярности [[Всемирная паутина|Всемирной паутины]], означает, что SMTP должен был включать в себя особые правила и методы для ретрансляции сообщений и авторизации пользователей для предотвращения таких злоупотреблений, как ретрансляция нежелательной почты ([[спам]]).

Поскольку этот протокол сначала был с текстовым ([[ASCII]]) интерфейсом, то он плохо работал с бинарными файлами и символами многих неанглийских языков. Такие стандарты, как Multipurpose Internet Mail Extensions ([[MIME]]), были разработаны для кодирования двоичных файлов для передачи через SMTP. Разработанные после Sendmail агенты пересылки, как правило, также осуществляли опцию чистых 8 бит, так что альтернативная стратегия «просто посылай восемь» может быть использована для передачи произвольных текстовых данных (в любой восьмибитной ASCII-подобной кодировке символов) через SMTP. Однако все ещё оставалась проблема разного отображения наборов символов у производителей, хотя сами почтовые адреса все ещё позволяли использовать исключительно ASCII. Сегодня агенты пересылки, работающие с чистыми 8 битами, как правило, поддерживают расширение 8BITMIME, позволяющее передавать бинарные файлы почти так же легко, как обычный текст. Недавно было создано расширение SMTPUTF8 для поддержки текста в кодировке [[UTF-8]], благодаря чему стало возможным включать международное содержимое и адреса с использованием таких алфавитов, как кириллица или китайский.

Многие выдающиеся люди внесли свой вклад в спецификацию основного SMTP, среди них [[Постел, Джонатан Брюс|Джон Постел]], [[Оллман, Эрик|Эрик Оллман]], Дэйв Крокер, Нед Фрид, Рэндалл Джелленс, Джон Кленсин и Кейт Мур.

== Модель обработки почты ==
[[Файл:SMTP-transfer-model.svg|thumb|right|300px|Синие стрелки могут быть реализованы с использованием различных версий SMTP]]

Электронная почта представлена почтовым клиентом (MUA, [[Почтовая программа|Mail User Agent]] — пользовательский почтовый агент) для почтового сервера (MSA, mail submission agent — агент отправки электронной почты) с помощью SMTP по [[TCP]]-порту 587. Оттуда MSA доставляет почту своим агентам передачи сообщений (MTA, [[Почтовый сервер|mail transfer agent]]). Часто эти два агента являются просто различными образцами одного и того же программного обеспечения, запущенного с разными параметрами на одном устройстве. Локальная обработка может быть проведена как на отдельной машине, так и разделена между различными устройствами; в первом случае вовлечённые процессы имеют общий доступ к файлам, во втором случае SMTP используется для пересылки сообщения внутренне, причём каждый хост настроен на использование следующего устройства в качестве [[Smart host|промежуточного хоста]]. Каждый процесс — сам по себе MTA, то есть — SMTP-сервер.

Граничный MTA должен найти целевой хост. Он использует систему доменных имен ([[DNS]]) для поиска записей почтового обменника (mail exchanger — MX) домена получателя (часть [[Адрес электронной почты|адреса]], находящаяся справа от символа @). Возвращаемая [[Запись MX|запись почтового MX]] содержит имя целевого хоста. Затем MTA подключается к серверу обмена в качестве SMTP-клиента.

Как только цель MX принимает входящее сообщение, она передаёт его агенту доставки почты (mail delivery agent — [[Mail delivery agent|MDA]]) для локальной доставки сообщения. MDA предусматривает возможность сохранять сообщения в соответствующем формате почтового ящика. Приём почты, опять же, может быть проведён как несколькими, так и одним компьютером — изображение показывает два ближайших ящика для каждого случая. MDA может доставлять сообщения прямо на хранение или передавать их по сети с помощью SMTP или любых других средств, в том числе протокола локальной пересылки почты (Local Mail Transfer Protocol — [[LMTP]]) — производного от SMTP, предназначенного для этой цели.

После доставки на локальный почтовый сервер сообщение хранится для пакетного поиска по аутентифицированным почтовым клиентам (MUA). Сообщение извлекается приложениями конечного пользователя (почтовыми клиентами) с использованием протокола [[IMAP]] (Internet Message Access Protocol), который облегчает доступ к сообщениям и управляет хранящейся почтой, или с помощью протокола [[POP3|POP]] (Post Office Protocol), который обычно использует традиционный mbox-формат файлов, или фирменными системами вроде Microsoft Exchange/Outlook или Lotus Notes/Domino. Клиенты сетевой почты могут использовать любой метод, но протокол поиска часто не соответствует официальным стандартам.

SMTP определяет передачу сообщения, а не его содержание. Таким образом, он задаёт оболочку сообщения и её параметры (такие, как отправитель оболочки), но не заголовок либо тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (оболочку), в то время как STD 11 и RFC 5322 — сообщение (заголовок и тело), официально называемый форматом почтового сообщения (Internet Message Format).

== Обзор протокола ==
SMTP — требующий соединения текстовый протокол, по которому отправитель сообщения связывается с получателем посредством выдачи командных строк и получения необходимых данных через надёжный канал, в роли которого обычно выступает TCP-соединение (Transmission Control Protocol — протокол управления передачей). SMTP-сессия состоит из команд, посылаемых SMTP-[[Клиент (информатика)|клиентом]], и соответствующих ответов SMTP-[[Сервер (аппаратное обеспечение)|сервера]]. Когда сессия открыта, сервер и клиент обмениваются её параметрами. Сессия может включать ноль и более SMTP-операций (транзакций).

SMTP-операция состоит из трёх последовательностей команда/ответ (см. пример ниже). Описание последовательностей:

* '''MAIL FROM''' — устанавливает обратный адрес (то есть Return-Path, 5321.From, mfrom). Это адрес для [[Возвращённое письмо|возвращённых писем]];
* '''RCPT TO''' — устанавливает получателя данного сообщения. Эта команда может быть дана несколько раз, по одной на каждого получателя. Эти адреса также являются частью оболочки;
* '''DATA''' — для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделённых пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо.

Помимо промежуточных ответов для DATA-команды, каждый ответ сервера может быть положительным (код ответа 2хх) или отрицательным. Последний, в свою очередь, может быть постоянным (код 5хх) либо временным (код 4хх). Отказ SMTP-сервера в передаче сообщения — постоянная ошибка; в этом случае клиент должен отправить возвращённое письмо. После сброса — положительного ответа, сообщение скорее всего будет отклонено. Также сервер может сообщить о том, что ожидаются дополнительные данные от клиента (код 3xx).

Изначальным хостом (SMTP-клиентом) может быть как почтовый клиент конечного пользователя (функционально определяемый как почтовый агент — MUA), так и агент пересылки сообщений (MTA) на сервере, то есть сервер действует как клиент в соответствующей сессии для ретрансляции сообщения. Полностью функциональные серверы поддерживают очереди сообщений для повторной передачи сообщения в случае ошибок.

MUA знает SMTP-сервер для исходящей почты из своих настроек. SMTP-сервер, действующий как клиент, то есть пересылающий сообщения, определяет, к какому серверу подключиться, просмотром ресурса [[Запись MX|записей MX]] (Mail eXchange) DNS для [[Доменное имя|домена]] каждого получателя. В случае, если запись MX не найдена, совместимые MTA (не все) возвращаются к простой [[Ресурсные записи DNS|А-записи]]. Пересылающие серверы также могут быть настроены на использование Smart host.

SMTP-сервер, действующий как клиент, устанавливает TCP-соединение с сервером по [[Список портов TCP и UDP|разработанному для SMTP порту]] 25. MUA должен использовать порт 587 для подключения к агенту предоставления сообщений (MSA). Основное различие между MTA и MSA заключается в том, что SMTP-аутентификация обязательна только для последнего.

=== SMTP и извлечение сообщений ===
SMTP (Simple Mail Transfer Protocol) является исключительно протоколом отправки почты. В отличие от протоколов получения сообщений, он не поддерживает механизм запроса и загрузки почты с удалённого сервера. Для этих целей были специально разработаны протоколы POP3 (Post Office Protocol) и IMAP (Internet Message Access Protocol), обеспечивающие управление почтовым ящиком и загрузку сообщений.

Важной особенностью SMTP является функция инициализации обработки почтовой очереди (Remote Message Queue Starting), позволяющая запрашивающей системе получать все адресованные ей сообщения с удалённого сервера. Однако для большинства конечных пользователей, особенно работающих с непостоянным интернет-подключением, предпочтительнее использование именно POP3 или IMAP, так как эти протоколы оптимизированы для периодического доступа к почтовому ящику.

=== Remote Message Queue Starting ===
Remote Message Queue Starting (запуск удалённой очереди сообщений) — особенность SMTP, позволяющая удалённому хосту начать обработку очереди сообщений на сервере так, что он может получать предназначенные ему сообщения с помощью команды TURN. Однако эта особенность считалась небезопасной и была расширена в RFC 1985 командой ETRN, которая работает надёжнее благодаря основанному на информации DNS методу [[Аутентификация|аутентификации]].

=== On-Demand Mail Relay ===
ODMR (On-Demand Mail Relay — ретрансляция почты по требованию) — стандартизированное в RFC 2645 SMTP-расширение, позволяющее проводить ретрансляцию сообщения аутентифицированному пользователю.

=== Интернационализация ===
Многие пользователи, чей набор символов отличается от латиницы, сталкиваются с требованием адреса электронной почты на латинице.
Для решения этой проблемы был создан RFC 6531, предоставляющий возможности для интернационализации для SMTP — расширение SMTPUTF8. RFC 6531 предоставляет поддержку многобайтных и не-ASCII символов в почтовом адресе, например: δοκιμή@παράδειγμα.δοκιμή или 测试@测试.测试. Текущая поддержка ограничена, но есть большой интерес в широком распространении RFC 6531 и связанных с ним RFC в странах с обширной базой пользователей, для которых латиница не является родным алфавитом.

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

=== Ограничения доступа к серверу исходящей почты ===
Администраторам сервера необходимо контролировать то, какие клиенты могут использовать сервер. Это позволяет им бороться с такими злоупотреблениями, как спам. Обычно используются два решения:
* В прошлом многие системы вводили ограничения по местоположению клиента, допуская к использованию лишь тех, чей IP-адрес был среди подконтрольных администраторам;
* Современные серверы обычно предлагают альтернативную систему, требующую аутентификацию клиентов для получения доступа.

=== Ограничение доступа по местоположению ===
В этом случае SMTP-сервер [[интернет-провайдер]]а не разрешит допуск пользователям «за пределами» сети провайдера. Точнее, сервер может допустить лишь тех пользователей, чей IP-адрес предоставлен данным провайдером, что эквивалентно требованию соединения с Интернетом с помощью этого провайдера. Мобильный пользователь часто может оказаться в сети, отличной от сети своего провайдера, и потому сообщения не будут отправляться.

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

Благодаря ограничению доступа определённым адресам, администраторы сервера могут легко определить адрес любого злоумышленника.
Если пользователь может использовать различных провайдеров для соединения с Интернетом, этот вид ограничения становится нецелесообразным, а изменение настроенного адреса SMTP-сервера исходящей почты непрактично. Крайне желательно иметь возможность использовать такую информацию о настройках клиента, которая не нуждается в изменении.

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

=== Открытый релей ===
Сервер, доступный для широкой сети и не предоставляющий эти виды ограничения доступа, называют [[Открытый релей|открытым релеем]]. Сейчас такие серверы считаются дурным тоном.

=== Порты ===
Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты — 25 или 587. Спецификации и многие серверы поддерживают и тот, и другой порты. Хотя некоторые серверы поддерживают порт 465 для безопасного SMTP, но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищённая сессия между клиентом и сервером.

Некоторые серверы настроены на отклонение всех ретрансляций по порту 25, но пользователям, прошедшим аутентификацию по порту 587, позволено перенаправлять сообщения на любой действительный адрес.

Некоторые провайдеры перехватывают порт 25, перенаправляя трафик на свой собственный SMTP-сервер вне зависимости от адреса назначения. Таким образом, их пользователи не могут получить доступ к серверу за пределами провайдерской сети по порту 25.

Некоторые серверы поддерживают аутентифицированный доступ по дополнительному, отличному от 25, порту, позволяя пользователям соединяться с ними, даже если порт 25 заблокирован.

== Пример простейшей SMTP-сессии ==
C: — клиент, S: — серверы
 
 <font color=blue>S: (ожидает соединения)</font>
 C: (Подключается к порту 25 сервера)
 <font color=blue>S:220 mail.company.tld ESMTP is glad to see you!</font>
 C:HELO
 <font color=blue>S:250 domain name should be qualified</font>
 C:MAIL FROM: <someusername@somecompany.ru>
 <font color=blue>S:250 someusername@somecompany.ru sender accepted</font>
 C:RCPT TO: <user1@company.tld>
 <font color=blue>S:250 user1@company.tld ok</font>
 C:RCPT TO: <user2@company.tld>
 <font color=blue>S:550 user2@company.tld unknown user account</font>
 C:DATA
 <font color=blue>S:354 Enter mail, end with "." on a line by itself</font>
 C:From: Some User <someusername@somecompany.ru>
 C:To: User1 <user1@company.tld>
 C:Subject: tema
 C:Content-Type: text/plain
 C:
 C:Hi!
 C:.
 <font color=blue>S:250 769947 message accepted for delivery</font>
 C:QUIT
 <font color=blue>S:221 mail.company.tld CommuniGate Pro SMTP closing connection</font>
 <font color=blue>S: (закрывает соединение)</font>

В результате такой сессии письмо будет доставлено адресату user1@company.tld, но не будет доставлено адресату user2@company.tld, потому что такого адреса не существует.

== Дополнительные расширения ==
Многие клиенты запрашивают расширения SMTP, поддерживаемые сервером, с помощью команды <code>EHLO</code> из спецификации расширенного SMTP (RFC 1870). <code>HELO</code> используется только в том случае, если сервер не ответил на <code>EHLO</code>. Современные клиенты могут использовать ключ SIZE расширения ESMTP для запроса максимального размера сообщения, которое будет принято. Более старые клиенты и серверы могут попытаться передать чрезмерно большие сообщения, которые будут отклонены после потребления сетевых ресурсов, включая время соединения. Пользователи могут вручную заранее определить максимальный размер, принимаемый ESMTP-серверами. Клиент заменяет команду <code>HELO</code> на EHLO.

 <span style="color: blue">S: 220 smtp2.example.com ESMTP Postfix</span>
 C: EHLO bob.example.org
 <span style="color: blue">S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]</span>
 <span style="color: blue">S: 250-SIZE 14680064</span>
 <span style="color: blue">S: 250-PIPELINING</span>
 <span style="color: blue">S: 250 HELP</span>

smtp2.example.com объявляет, что он примет сообщение размером не больше чем {{num|14680064}} [[Октет (информатика)|октетов]] (8-битных байтов). В зависимости от фактического использования сервера, он может на данный момент не принять сообщение такой величины. В простейшем случае ESMTP-сервер объявит максимальный SIZE только при взаимодействии с пользователем через <code>HELO</code>.

== Расширенный SMTP-протокол ==
Расширенный SMTP (ESMTP) (иногда называемый Enhanced SMTP) — это определение расширений протокола для стандарта SMTP. ESMTP был определен в ноябре 1995 года в публикации IETF <nowiki>RFC 1869</nowiki>, которая установила общую структуру для всех существующих и будущих расширений. ESMTP определяет согласованные и управляемые средства, с помощью которых могут быть идентифицированы клиенты и серверы ESMTP, а серверы могут указывать поддерживаемые расширения. Исходный протокол SMTP поддерживал только неаутентифицированные незашифрованные текстовые сообщения ASCII, восприимчивые к атакам типа «злоумышленник в середине», спуфингу и рассылке спама, и требуя, чтобы любые двоичные данные перед передачей кодировались в читаемый текст. В ряде дополнительных расширений указаны различные механизмы решения этих проблем.

=== Обнаружение дополнительных расширений ===
Клиенты изучают поддерживаемые сервером параметры, используя приветствие EHLO вместо исходного HELO. Клиенты возвращаются к HELO, только если сервер не поддерживает расширения SMTP. Современные клиенты могут использовать ключевое слово SIZE расширения ESMTP, чтобы запросить у сервера максимальный размер сообщения, которое будет принято. Старые клиенты и серверы могут пытаться передать сообщения слишком большого размера, которые будут отклонены после использования сетевых ресурсов, включая время подключения к сетевым ссылкам, которое оплачивается поминутно. Пользователи могут заранее вручную определить максимальный размер, допустимый для серверов ESMTP. Клиент заменяет команду HELO командой EHLO.

=== Передача двоичных данных ===
Исходный SMTP поддерживает только одно тело текста ASCII, поэтому любые двоичные данные должны быть закодированы как текст в этом теле сообщения перед передачей, а затем декодированы получателем. Обычно использовались двоичные кодировки текста, такие как uuencode и BinHex.

Для решения этой проблемы была разработана команда 8BITMIME. Он был стандартизирован в 1994 году как <nowiki>RFC 1652</nowiki>. Он упрощает прозрачный обмен сообщениями электронной почты, содержащими октеты вне семибитного набора символов ASCII, путем кодирования их как частей содержимого MIME, обычно кодируемых с помощью Base64.

=== Расширения механизма доставки почты ===
Ретранслятор почты по требованию (ODMR) — это расширение SMTP, стандартизованное в <nowiki>RFC 2645</nowiki>, которое позволяет периодически подключенному SMTP-серверу получать электронную почту, помещенную в очередь для него, когда он подключен.

=== Расширение интернационализации ===
Исходный SMTP поддерживает адреса электронной почты, состоящие только из символов ASCII, что неудобно для пользователей, чей собственный сценарий не основан на латинице или которые используют диакритические знаки вне набора символов ASCII. Это ограничение было снято с помощью расширений, позволяющих использовать UTF-8 в именах адресов. <nowiki>RFC 5336</nowiki> представил экспериментальную команду UTF8SMTP, а позже был заменен <nowiki>RFC 6531</nowiki>, в котором была представлена команда SMTPUTF8. Эти расширения обеспечивают поддержку многобайтовых символов и символов, отличных от ASCII, в адресах электронной почты, например, с диакритическими знаками и другими языковыми символами, такими как греческий и китайский. Текущая поддержка ограничена, но существует большой интерес к широкому принятию <nowiki>RFC 6531</nowiki> и связанных с ним RFC в таких странах, как Китай, с большой пользовательской базой, где латинский (ASCII) является иностранным алфавитом.

=== Расширения ===
Как и SMTP, ESMTP — это протокол, используемый для передачи почты Интернета. Он используется как межсерверный транспортный протокол и (с принудительным ограниченным поведением) как протокол отправки почты. Основная функция идентификации для клиентов ESMTP — открыть передачу с помощью команды EHLO (Extended HELLO), а не HELO (Hello, оригинальный стандарт <nowiki>RFC 821</nowiki>). Сервер ответит успешно (код 250), отказом (код 550) или ошибкой (код 500, 501, 502, 504 или 421), в зависимости от его конфигурации. Сервер ESMTP возвращает код 250 OK в многострочном ответе со своим доменом и списком ключевых слов для обозначения поддерживаемых расширений. Сервер, соответствующий <nowiki>RFC 821</nowiki>, возвращает код ошибки 500, позволяя клиентам ESMTP попробовать либо HELO, либо QUIT. Каждое расширение услуги определяется в утвержденном формате в последующих RFC и регистрируется в Internet Assigned Numbers Authority (IANA). Первыми определениями были дополнительные услуги <nowiki>RFC 821</nowiki>: SEND, SOML (отправка или почта), SAML (отправка и почта), EXPN, HELP и TURN. Был установлен формат дополнительных SMTP-глаголов и для новых параметров в MAIL и RCPT. Некоторые относительно распространенные ключевые слова (не все из которых соответствуют командам), используемые сегодня:

* <code>'''8BITMIME''' - 8-битная передача данных, <nowiki>RFC 6152</nowiki>;</code>
* <code>'''ATRN''' - TURN с проверкой подлинности для ретрансляции почты по требованию, <nowiki>RFC 2645</nowiki>;</code>
* <code>'''AUTH''' - аутентифицированный SMTP, <nowiki>RFC 4954</nowiki>;</code>
* <code>'''CHUNKING''' - Разделение на части, <nowiki>RFC 3030</nowiki>;</code>
* <code>'''DSN''' - уведомление о состоянии доставки, <nowiki>RFC 3461</nowiki>;</code>
* <code>'''ETRN''' - Расширенная версия команды запуска удаленной очереди сообщений TURN, <nowiki>RFC 1985</nowiki>;</code>
* <code>'''HELP''' - Предоставьте полезную информацию, <nowiki>RFC 821</nowiki>;</code>
* <code>'''PIPELINING''' - конвейерная обработка команд, <nowiki>RFC 2920</nowiki>;</code>
* <code>'''SIZE''' - Объявление размера сообщения, <nowiki>RFC 1870</nowiki>;</code>
* <code>'''STARTTLS''' - Безопасность транспортного уровня, <nowiki>RFC 3207</nowiki> (2002);</code>
* <code>'''SMTPUTF8''' - разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, <nowiki>RFC 6531</nowiki>.</code>

Формат ESMTP был переформулирован в <nowiki>RFC 2821</nowiki> (заменяющий <nowiki>RFC 821</nowiki>) и обновлен до последнего определения в <nowiki>RFC 5321</nowiki> в 2008 году. Поддержка команды EHLO на серверах стала обязательной, а HELO обозначил обязательный откат. Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются ключевым словом сообщения EHLO, начинающимся с «X», и с любыми дополнительными параметрами или глаголами, отмеченными аналогичным образом. Команды SMTP не чувствительны к регистру. Они представлены здесь с заглавной буквы только для акцента. SMTP-сервер, для которого требуется особый метод использования заглавных букв, является нарушением стандарта.

== Безопасность SMTP и спам ==
Изначальная спецификация SMTP не включала средств для аутентификации отправителей. Впоследствии, в RFC 2554, было введено расширение. Расширение SMTP (ESMTP) предоставляет почтовым клиентам возможности задания механизма обеспечения безопасности для сервера, аутентификации и профиля безопасности [[Simple Authentication and Security Layer|SASL]] (Simple Authentication and Security Layer) для последующих передач сообщений.

Продукты Microsoft реализуют собственный протокол — SPA (Secure Password Authentication) с помощью расширения SMTP-AUTH.

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

Обширное изменение SMTP, так же как и полная его замена, считаются непрактичными из-за огромной инсталлированной базы SMTP. Internet Mail 2000 был одним из претендентов для такой замены.

Спам функционирует благодаря различным факторам, в том числе не соответствующие стандартам реализации MTA, уязвимости в защите операционных систем (усугубляемые постоянным широкополосным подключением), что позволяет спамерам удалённо контролировать компьютер конечного пользователя и посылать с него спам.

Существует несколько предложений для побочных протоколов, помогающих работе SMTP. Исследовательская группа Anti-Spam (The Anti-Spam Research Group — ASRG) — подразделение Исследовательской группы Интернет-технологий работает над почтовой аутентификацией и другими предложениями для предоставления простой аутентификации, которая будет гибкой, легковесной и масштабируемой. Недавняя деятельность [[Инженерный совет Интернета|Инженерного совета Интернета]] (IETF) включает в себя MARID (2004), приведший к двум утверждённым IETF-экспериментам в 2005, и [[DomainKeys Identified Mail]] в 2006.

== Расширения ESMTP ==
[[STARTTLS]] в RFC 1869 предписывает начинать сессию не командой <code>HELO</code>, а командой <code>EHLO</code>. В случае, если сервер не поддерживает расширений, то он ответит на <code>EHLO</code> ошибкой, в этом случае клиент должен послать команду <code>HELO</code> и не использовать расширения протокола.

Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:

 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 HELO

== Стандарты RFC ==
* RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет 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 (заменяет RFC 2554)
* RFC 2822 Internet Message Format (заменяет 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 (заменяет RFC 2487)
* RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
* RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
* RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
* RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет 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 (заменяет RFC 2476)
* RFC 5321 Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821)
* RFC 5336 SMTP Extension for Internationalized Email Addresses
* [https://www.protocols.ru/WP/rfc2505/ Перевод RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA]
* [http://rfc2.ru/2554.rfc Перевод RFC 2554 — Расширение сервиса SMTP для аутентификации]
* [https://www.protocols.ru/WP/rfc5321/ Перевод RFC 5321 — Простой протокол передачи электронной почты (SMTP)]

== См. также ==
* [[LMTP]] — производный от SMTP протокол, ориентированный на работу без очереди сообщений.
* [[POP3]]
* [[IMAP]]
* [[TCP]]
* [[Sender Policy Framework]]
* [[Sender ID]]
* [[X.400]]
* [[Предотвращение утечек|Предотвращение утечек информации через SMTP]]

== Литература ==
* {{книга |заглавие=Internet e-mail Protocols, Standards and Implementation |ссылка=https://archive.org/details/internetemailpro0000hugh |издательство={{Нп3|Artech House|Artech House Publishers|en|Artech House}} |год=1998 |isbn=0-89006-939-5 |ref=Hughes |язык=en |автор=Hughes, L.}}
* {{книга |заглавие=sendmail Cookbook |ссылка=https://archive.org/details/sendmailcookbook0000hunt |издательство=[[O’Reilly|O’Reilly Media]] |год=2003 |isbn=0-596-00471-0 |ref=Hunt |язык= |автор=Hunt, C.}}
* {{книга |заглавие=Internet Email Protocols: A Developer's Guide |ссылка=https://archive.org/details/internetemailpro0000john |издательство=[[Addison-Wesley|Addison-Wesley Professional]] |год=2000 |isbn=0-201-43288-9 |ref=Johnson |язык=en |автор=Johnson, K.}}
* {{книга |заглавие=Essential Email Standards: RFCs and Protocols Made Practical |издательство=[[John Wiley & Sons]] |год=1999 |isbn=0-471-34597-0 |ref=Loshin |язык= |автор=Loshin, P.}}
* {{книга |заглавие=Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP |издательство=[[Elsevier]] |год=1999 |isbn=1-55558-212-5 |ref=Rhoton |язык=en |автор=Rhoton, J.}}
* {{книга |заглавие=Programming Internet Mail |издательство=O'Reilly |год=1999 |isbn=1-56592-479-7 |ref=Wood |язык= |автор=Wood, D.}}

{{URI scheme}}
{{IPstack|nocat=1}}

[[Категория:Электронная почта]]
[[Категория:Протоколы прикладного уровня]]