Простой протокол передачи почты

«SMTP» перенаправляется сюда. Информацию о компании по доставке электронной почты см. в разделе SMTP (компания) . Информацию о протоколе передачи коротких сообщений см. в GSM 03.40 .

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

Истоки SMTP начались в 1980 году и основывались на концепциях, реализованных в ARPANET с 1971 года. Он неоднократно обновлялся, изменялся и расширялся. Широко используемая сегодня версия протокола имеет расширяемую структуру с различными расширениями для аутентификации , шифрования , передачи двоичных данных и интернационализированных адресов электронной почты . Серверы SMTP обычно используют протокол управления передачей через порты 25 (для открытого текста) и 587 (для зашифрованной связи).

История

Дополнительная информация: История электронной почты.

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

различные формы индивидуального электронного обмена сообщениями В 1960-х годах использовались . Пользователи общались с помощью систем, разработанных для конкретных мейнфреймов . правительства США Поскольку все больше компьютеров были соединены между собой, особенно в сети ARPANET , были разработаны стандарты, позволяющие обмениваться сообщениями между различными операционными системами.

Почта в ARPANET берет свое начало в 1971 году: протокол почтового ящика, который не был реализован, но обсуждается в RFC   196 ; и программу SNDMSG , которую в том же году Рэй Томлинсон из BBN адаптировал для отправки сообщений на два компьютера в сети ARPANET. Дальнейшее предложение по почтовому протоколу было сделано в RFC 524 в июне 1973 года. что не было реализовано.

Использование протокола передачи файлов (FTP) для «сетевой почты» в ARPANET было предложено в RFC 469 в марте 1973 года. Через RFC 561, RFC 680, RFC 724 и, наконец, RFC 733 в ноябре 1977 года была разработана стандартизированная структура «электронной почты» с использованием почтовых серверов FTP.

SMTP вырос из этих стандартов, разработанных в 1970-х годах.

Исходный SMTP

В 1980 году Джон Постел и Сюзанна Слейзер опубликовали RFC   772 , в котором предлагается протокол передачи почты в качестве замены использования FTP для почты. RFC   780 от мая 1981 года удалил все ссылки на FTP и выделил порт 57 для TCP и UDP . распределение, которое с тех пор было удалено IANA . В ноябре 1981 года Постель опубликовал RFC   788 «Простой протокол передачи почты».

Стандарт SMTP был разработан примерно в то же время, что и Usenet , сеть связи «один ко многим», имеющая некоторые сходства.

SMTP стал широко использоваться в начале 1980-х годов. В то время это было дополнением к программе копирования Unix в Unix (UUCP), которая лучше подходила для обработки передачи электронной почты между компьютерами, которые периодически подключались. SMTP, с другой стороны, работает лучше всего, когда и отправляющая, и принимающая машины постоянно подключены к сети. Оба использовали механизм хранения и пересылки и являются примерами технологии push . Usenet Хотя группы новостей по-прежнему распространялись между серверами с помощью UUCP, UUCP как почтовый транспорт практически исчез наряду с « путями взрыва » он использовался в качестве заголовков маршрутизации сообщений.

Sendmail , выпущенный вместе с версией 4.1cBSD в 1983 году, был одним из первых агентов передачи почты, реализовавших SMTP. Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал самым распространенным MTA (агентом передачи почты).

Исходный протокол SMTP поддерживал только неаутентифицированную незашифрованную 7-битную текстовую связь ASCII, уязвимую для тривиальной атаки «человек посередине» , подделку и спам , а также требующую кодирования любых двоичных данных в читаемый текст перед передачей. Из-за отсутствия надлежащего механизма аутентификации каждый SMTP-сервер по своей конструкции представлял собой открытый ретранслятор почты . Консорциум Интернет-почты (IMC) сообщил, что в 1998 году 55% ​​почтовых серверов были открытыми ретрансляторами. но менее 1% в 2002 г. Из-за проблем со спамом большинство провайдеров электронной почты блокируют открытые ретрансляторы, что делает оригинальный SMTP практически непрактичным для общего использования в Интернете.

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

В ноябре 1995 года RFC   1869 определил расширенный простой протокол передачи почты (ESMTP), который установил общую структуру для всех существующих и будущих расширений, целью которых было добавление функций, отсутствующих в исходном SMTP. ESMTP определяет согласованные и управляемые средства, с помощью которых можно идентифицировать клиентов и серверы ESMTP, а серверы могут указывать поддерживаемые расширения.

Отправка сообщения ( RFC   2476 ) и SMTP-AUTH ( RFC   2554 ) были представлены в 1998 и 1999 годах, оба описывают новые тенденции в доставке электронной почты. Первоначально SMTP-серверы обычно были внутренними по отношению к организации, получали почту для организации извне и ретранслировали сообщения из организации во внешнюю среду . Но со временем SMTP-серверы (агенты передачи почты) на практике расширили свою роль и стали агентами отправки сообщений для почтовых пользовательских агентов , некоторые из которых теперь ретранслировали почту из-за пределов организации. (например, руководитель компании хочет отправить электронную почту во время поездки, используя корпоративный SMTP-сервер.) Эта проблема, возникшая вследствие быстрого расширения и популярности Всемирной паутины , означала, что SMTP должен был включать определенные правила и методы для ретрансляции почты. и аутентификацию пользователей для предотвращения злоупотреблений, таких как пересылка нежелательной электронной почты ( спама ). Работа над отправкой сообщений ( RFC   2476 ) изначально был запущен потому, что популярные почтовые серверы часто переписывали почту, пытаясь исправить в ней проблемы, например, добавляя доменное имя к неквалифицированному адресу. Такое поведение полезно, когда исправляемое сообщение является первоначальной отправкой, но опасно и вредно, когда сообщение исходит из другого места и ретранслируется. Четкое разделение почты на отправку и ретрансляцию рассматривалось как способ разрешить и поощрять переписывание отправок, одновременно запрещая переписывание ретрансляции. Поскольку спам стал более распространенным, его также стали рассматривать как способ авторизации почты, отправляемой из организации, а также отслеживаемости. Такое разделение ретрансляции и отправки быстро стало основой современных методов обеспечения безопасности электронной почты.

Поскольку этот протокол изначально был основан исключительно на тексте ASCII , он плохо справлялся с двоичными файлами или символами многих языков, отличных от английского. Такие стандарты, как многоцелевые расширения почты Интернета ( MIME ), были разработаны для кодирования двоичных файлов для передачи через SMTP. Агенты передачи почты (MTA), разработанные после Sendmail, также имели тенденцию реализовывать 8-битную чистоту , так что альтернативную стратегию «просто отправить восемь» можно было использовать для передачи произвольных текстовых данных (в любой 8-битной кодировке символов, подобной ASCII) через SMTP. Mojibake по-прежнему оставался проблемой из-за различий в сопоставлении наборов символов у разных поставщиков, хотя сами адреса электронной почты по-прежнему допускали использование только ASCII . Сегодня 8-битные MTA, как правило, поддерживают расширение 8BITMIME, что позволяет передавать некоторые двоичные файлы почти так же легко, как обычный текст (ограничения на длину строки и разрешенные значения октетов все еще применяются, поэтому кодирование MIME необходимо для большинства нетекстовых файлов). данные и некоторые текстовые форматы). В 2012 году SMTPUTF8 Расширение было создано для поддержки UTF-8 текста , что позволяет использовать международный контент и адреса, написанные нелатиницей, например кириллицей или китайским шрифтом .

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

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

Синие стрелки показывают реализацию вариантов SMTP.

Электронная почта отправляется почтовым клиентом ( агент пользователя почты , MUA) на почтовый сервер ( агент отправки почты , MSA) с использованием SMTP через TCP- порт 587. Большинство поставщиков почтовых ящиков по-прежнему разрешают отправку через традиционный порт 25. MSA доставляет почту на свой адрес. агент передачи почты (MTA). Зачастую эти два агента представляют собой экземпляры одного и того же программного обеспечения, запущенного с разными опциями на одном компьютере. Локальная обработка может выполняться либо на одной машине, либо распределяться между несколькими машинами; Процессы почтового агента на одной машине могут совместно использовать файлы, но если обработка происходит на нескольких машинах, они передают сообщения между собой с помощью SMTP, где каждая машина настроена на использование следующей машины в качестве смарт-хоста . Каждый процесс сам по себе является MTA (SMTP-сервером).

Граничный MTA использует DNS для поиска записи MX (почтового обменника) для домена получателя (часть адреса электронной почты справа от @). Запись MX содержит имя целевого MTA. На основе целевого хоста и других факторов отправляющий MTA выбирает сервер-получатель и подключается к нему для завершения обмена почтой.

Передача сообщений может происходить в одном соединении между двумя MTA или в серии переходов через промежуточные системы. Получающий SMTP-сервер может быть конечным пунктом назначения, промежуточным «ретранслятором» (то есть он хранит и пересылает сообщение) или «шлюзом» (то есть он может пересылать сообщение, используя какой-либо протокол, отличный от SMTP). Пер В разделе 2.1 RFC   5321 каждый переход представляет собой формальную передачу ответственности за сообщение, при этом принимающий сервер должен либо доставить сообщение, либо должным образом сообщить о неспособности сделать это.

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

После доставки на локальный почтовый сервер почта сохраняется для пакетного получения аутентифицированными почтовыми клиентами (MUA). Почта извлекается приложениями конечных пользователей, называемыми почтовыми клиентами, с использованием протокола доступа к сообщениям в Интернете (IMAP), протокола, который одновременно облегчает доступ к почте и управляет сохраненной почтой, или протокола почтового отделения (POP), который обычно использует традиционную mbox. почту формат файла или собственная система, такая как Microsoft Exchange/Outlook или Lotus Notes / Domino . Клиенты веб-почты могут использовать любой метод, но протокол получения часто не является формальным стандартом.

SMTP определяет транспорт сообщений , а не их содержимое . Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта , но не заголовок (кроме информации трассировки ) и не тело самого сообщения. ЗППП 10 и RFC   5321 определяет SMTP (конверт), а STD 11 и RFC   5322 определяет сообщение (заголовок и тело), ​​формально называемое форматом интернет-сообщения .

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

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

1. Команда MAIL для установки обратного адреса, также называемая обратным путем. обратный путь, адрес возврата , mfrom или отправитель конверта.
2. Команда RCPT для установления получателя сообщения. Эту команду можно выполнить несколько раз, по одному для каждого получателя. Эти адреса также являются частью конверта.
3. DATA для обозначения начала текста сообщения ; содержание сообщения, а не его конверт. Он состоит из заголовка сообщения и тела сообщения , разделенных пустой строкой. ДАННЫЕ на самом деле представляют собой группу команд, и сервер отвечает дважды: один раз на саму команду ДАННЫЕ , чтобы подтвердить, что он готов получить текст, и второй раз после последовательности конца данных, чтобы либо принять, либо отклонить. все сообщение.

Помимо промежуточного ответа для DATA, ответ каждого сервера может быть как положительным (коды ответа 2xx), так и отрицательным. Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx). Отклонение . — это постоянный сбой, и клиент должен отправить сообщение о возврате на сервер, с которого он его получил Удаление . — это положительный ответ, за которым следует отбрасывание сообщения, а не его доставка

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

MUA знает SMTP-сервер исходящей почты из своей конфигурации. Сервер ретрансляции обычно определяет, к какому серверу подключиться, просматривая -запись ресурса MX (Mail eXchange) DNS каждого получателя для доменного имени . Если запись MX не найдена, соответствующий сервер ретрансляции (не все) вместо этого ищет запись A. Серверы ретрансляции также можно настроить на использование смарт-хоста . Сервер ретрансляции инициирует TCP- соединение с сервером через « общеизвестный порт » для SMTP: порт 25 или для подключения к MSA, порт 587. Основное различие между MTA и MSA заключается в том, что для подключения к MSA требуется SMTP-аутентификация .

SMTP

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

сообщений

Запуск удаленной очереди сообщений позволяет удаленному хосту начать обработку почтовой очереди на сервере, чтобы он мог получать предназначенные ему сообщения, отправив соответствующую команду. Оригинал TURN командование было сочтено небезопасным и было продлено в RFC   1985 года с ETRN команда, которая работает более безопасно, используя метод аутентификации , основанный на информации системы доменных имен .

SMTP-сервер исходящей почты

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

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

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

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

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

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

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

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

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

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

Порты

Для связи между почтовыми серверами обычно используется стандартный TCP- порт 25, предназначенный для SMTP.

Однако почтовые клиенты обычно этого не используют, вместо этого используют определенные порты «отправки». Почтовые службы обычно принимают электронные письма от клиентов по одному из:

• 587 (Представление), как это закреплено в RFC   6409 (ранее RFC   2476 )
• 465 Этот порт устарел после RFC   2487 , до момента выпуска RFC   8314 .

Порт 2525 и другие могут использоваться некоторыми отдельными провайдерами, но никогда официально не поддерживались.

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

Пример SMTP-транспорта

Типичный пример отправки сообщения по SMTP на два почтовых ящика ( alice и theboss ), расположенных в одном почтовом домене ( example.com ), воспроизводится в следующем сеансе обмена. (В этом примере части диалога имеют префикс S: и C: для сервера и клиента соответственно; эти метки не являются частью обмена.)

После того как отправитель сообщения (клиент SMTP) устанавливает надежный канал связи с получателем сообщения (сервером SMTP), сеанс открывается приветствием сервера, обычно содержащим его полное доменное имя (FQDN), в данном случае smtp.example. .com . Клиент инициирует диалог, отвечая HELO команда, идентифицирующая себя в параметре команды с помощью своего полного доменного имени (или литерала адреса, если он недоступен).

S:   220 smtp.example.com ESMTP Postfix 
 C:  HELO реле.example.org 
  S:   250 Здравствуйте,lay.example.org, рад познакомиться 
 C:  ПОЧТА ОТ:<[email protected]> 
  S:   250 Хорошо 
 C:  RCPT TO:<[email protected]> 
  S:   250 Хорошо 
 C:  RCPT TO:<[email protected]> 
  С:   250 Ок 
 С:  ДАННЫЕ 
  S:   354 Завершение данных с помощью <CR><LF>.<CR><LF> 
 C:  From: "Bob Example" <[email protected]>
С:  To: "Alice Example" <[email protected]>
С:  Cc: [email protected]
С:  Date: Tue, 15 Jan 2008 16:02:43 -0500
С:  Subject: Test message
C: 
 C:  Привет, Алиса. 
  C:  Это тестовое сообщение с 5 полями заголовка и 4 строками в теле сообщения. 
  С:  Твой друг, 
  С:  Боб 
  С:  . 
  S:   250 Хорошо: в очереди под номером 12345 
 C:  ВЫХОД 
  S:   221 Пока 
 {Сервер закрывает соединение} 

Клиент уведомляет получателя об исходном адресе электронной почты сообщения в MAIL FROMкоманда. Это также адрес возврата или возврата на случай, если сообщение не может быть доставлено. В этом примере сообщение электронной почты отправляется в два почтовых ящика на одном SMTP-сервере: по одному для каждого получателя, указанного в To: и Cc:поля заголовка. Соответствующая команда SMTP: RCPT TO. Каждый успешный прием и выполнение команды подтверждается сервером кодом результата и ответным сообщением (например, 250 Ok).

Передача тела почтового сообщения инициируется с помощью DATAкоманда, после которой она передается дословно построчно и завершается последовательностью конца данных. Эта последовательность состоит из новой строки ( <CR><LF>), одна точка ( .), за которым следует еще одна новая строка ( <CR><LF>). Поскольку тело сообщения может содержать строку только с точкой как часть текста, клиент отправляет две точки каждый раз, когда строка начинается с точки; соответственно, сервер заменяет каждую последовательность двух точек в начале строки на одну. Такой метод экранирования называется точечной загрузкой .

Положительный ответ сервера на сообщение об окончании данных, как показано на примере, подразумевает, что сервер взял на себя ответственность за доставку сообщения. Сообщение может дублироваться, если в этот момент произошел сбой связи, например, из-за нехватки электроэнергии: до тех пор, пока отправитель не получит это сообщение. 250 Okответа, он должен предположить, что сообщение не было доставлено. С другой стороны, после того как получатель решил принять сообщение, он должен предположить, что сообщение ему доставлено. Таким образом, в течение этого периода времени оба агента имеют активные копии сообщения, которое они попытаются доставить. Вероятность того, что сбой связи произойдет именно на этом этапе, прямо пропорциональна объему фильтрации, которую сервер выполняет над телом сообщения, чаще всего в целях защиты от спама. Ограничение времени ожидания установлено равным 10 минутам.

The QUITкоманда завершает сеанс. Если у электронного письма есть другие получатели, находящиеся в другом месте, клиент будет QUITи подключитесь к соответствующему SMTP-серверу для последующих получателей после того, как текущие адресаты были поставлены в очередь. Информация, которую клиент отправляет в HELO и MAIL FROMкоманды добавляются (не показаны в примере кода) в качестве дополнительных полей заголовка к сообщению принимающим сервером. Он добавляет Received и Return-Path поле заголовка соответственно.

В некоторых клиентах реализовано закрытие соединения после принятия сообщения ( 250 Ok: queued as 12345), поэтому последние две строки могут быть опущены. Это вызывает ошибку на сервере при попытке отправить 221 Bye отвечать.

SMTP-расширения

Механизм обнаружения расширений

Клиенты изучают поддерживаемые сервером параметры, используя EHLO приветствие, как показано ниже, вместо оригинального HELO. Клиенты возвращаются к HELO только если сервер не поддерживает EHLO приветствие.

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

Пользователи могут заранее вручную определить максимальный размер, принимаемый серверами ESMTP. Клиент заменяет HELO команда с помощью EHLO команда.

S:   220 smtp2.example.com ESMTP Postfix 
 C:  EHLO bob.example.org 
  S:   250-smtp2.example.com Привет, bob.example.org [192.0.2.201] 
 S:   250-SIZE 14680064 
 S:   250-PIPELINING 
 S:   250 ПОМОЩЬ 

Таким образом, smtp2.example.com заявляет, что он может принимать фиксированный максимальный размер сообщения, не превышающий 14 680 064 октетов (8-битных байтов).

В простейшем случае сервер ESMTP объявляет максимальную SIZE сразу после получения EHLO. В соответствии с RFC   1870 , однако числовой параметр для SIZE расширение в EHLOответ не является обязательным. Вместо этого клиенты могут при выдаче MAIL FROM В команду включают числовую оценку размера передаваемого сообщения, чтобы сервер мог отказаться от приема слишком больших сообщений.

Передача двоичных данных

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

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

требованию

Основная статья: Ретрансляция почты по требованию

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

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

Основная статья: Международная электронная почта

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

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

Расширения

Как и SMTP, ESMTP — это протокол, используемый для передачи почты Интернета. Он используется как межсерверный транспортный протокол, так и (с ограниченным поведением) как протокол отправки почты.

Основной функцией идентификации для клиентов ESMTP является открытие передачи командой EHLO (Расширенный HELLO), а не HELO (Привет, оригинал стандарт RFC   821 ). Сервер ответит успешно (код 250), сбоем (код 550) или ошибкой (код 500, 501, 502, 504 или 421), в зависимости от его конфигурации. Сервер ESMTP возвращает код 250 OK в многострочном ответе со своим доменом и списком ключевых слов для обозначения поддерживаемых расширений. Сервер, соответствующий RFC 821, возвращает код ошибки 500, что позволяет клиентам ESMTP попробовать либо HELO или QUIT.

Каждое расширение услуги определяется в утвержденном формате в последующих RFC и регистрируется в Управлении по присвоению номеров Интернета (IANA). Первыми определениями были дополнительные услуги RFC 821: SEND, SOML (Отправить или по почте), SAML (Отправка и почта), EXPN, HELP, и TURN. Был установлен формат дополнительных команд SMTP, а для новых параметров в MAIL и RCPT.

Некоторые относительно распространенные ключевые слова (не все из них соответствуют командам), используемые сегодня:

• 8BITMIME – 8-битная передача данных, RFC   6152
• ATRN – Аутентифицированный TURN для ретрансляции почты по требованию , РФК   2645
• AUTH – Аутентифицированный SMTP, RFC   4954
• CHUNKING - Дробление, РФК   3030
• DSN - Уведомление о состоянии доставки, RFC   3461 (см. путь возврата переменного конверта )
• ETRN – Расширенная версия команды запуска удаленной очереди сообщений. TURN, РФК   1985 г.
• HELP - Предоставлять полезную информацию, RFC   821
• PIPELINING – Конвейерная обработка команд, РФК   2920
• SIZE – объявление размера сообщения, РФК   1870
• STARTTLS – Безопасность транспортного уровня , RFC   3207 (2002 г.)
• SMTPUTF8 – Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC   6531
• UTF8SMTP – Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC   5336 (устаревший) )

Формат ESMTP был переформулирован в RFC   2821 (заменяющий RFC 821) и обновленный до последней версии определения. RFC   5321 в 2008 г. Поддержка EHLO команда на серверах стала обязательной, и HELO обозначен как необходимый запасной вариант.

Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются значком. EHLO Ключевое слово сообщения, начинающееся с буквы «X», и любые дополнительные параметры или глаголы, отмеченные аналогичным образом.

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

8БИТМИМ

По крайней мере, следующие серверы рекламируют расширение 8BITMIME:

• Апач Джеймс (начиная с версии 2.3.0a1)
• Цитадель (с 7.30)
• Курьерский почтовый сервер
• Gmail
• IceWarp
• IIS Служба SMTP
• Керио Коннект
• Лотос Домино
• Microsoft Exchange Server (начиная с Exchange Server 2000)
• Novell GroupWise
• ОпенСМТПД
• Сервер обмена сообщениями Oracle Communications
• Постфикс
• Отправить почту (с версии 6.57)

Следующие серверы можно настроить для объявления 8BITMIME, но не выполнять преобразование 8-битных данных в 7-битные при подключении к ретрансляторам, отличным от 8BITMIME:

• Exim и qmail не преобразуют восьмибитные сообщения в семибитные при попытке ретранслировать 8-битные данные узлам, не поддерживающим 8BITMIME, как того требует RFC. На практике это не вызывает проблем, поскольку практически все современные почтовые ретрансляторы являются 8-битными .
• Microsoft Exchange Server 2003 по умолчанию объявляет 8BITMIME, но ретрансляция на одноранговый узел, не поддерживающий 8BITMIME, приводит к возврату. Это разрешено разделом 3 RFC 6152 .

SMTP-AUTH

Основная статья: SMTP-аутентификация

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

SMTP-AUTH можно использовать, чтобы разрешить законным пользователям ретранслировать почту, запрещая при этом услугу ретрансляции неавторизованным пользователям, например спамерам . Это не обязательно гарантирует подлинность отправителя конверта SMTP или Заголовок RFC   2822 «От:». Например, спуфинг , при котором один отправитель маскируется под кого-то другого, по-прежнему возможен с помощью SMTP-AUTH, если только сервер не настроен на ограничение исходящих сообщений адресами, для которых авторизован этот авторизованный пользователь.

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

SMTPUTF8

Поддерживаемые серверы включают в себя:

• Постфикс (версия 3.0 и новее)
• Импульс (версии 4.1 и 3.6.5 и позже)
• Sendmail (экспериментальная поддержка в версии 8.17.1)
• Exim (экспериментальный на момент выпуска 4.86, вполне доработанный в версии 4.96)
• CommuniGate Pro начиная с версии 6.2.2
• Курьер-МТА начиная с версии 1.0
• Халон начиная с версии 4.0
• Microsoft Exchange Server начиная с версии протокола 14.0.
• Харака и другие серверы.
• Сервер сообщений Oracle Communications, начиная с версии 8.0.2.

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

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

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

Основные статьи: Оппортунистический 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 коллегами.

RFC   8314 официально объявил простой текст устаревшим и рекомендует всегда использовать TLS для отправки почты и доступа к ней, добавляя порты с неявным TLS.

DANE для SMTP

В RFC   7672 появилась возможность для записей DNS декларировать возможности шифрования почтового сервера. Используя DNSSEC , операторы почтовых серверов могут публиковать хеш своего сертификата TLS, тем самым снижая вероятность незашифрованной связи.

Microsoft планирует обеспечить полную поддержку SMTP DANE для клиентов Exchange Online к концу 2024 года.

SMTP MTA Strict Transport Security

Новее 2018 года. RFC   8461 под названием «SMTP MTA Strict Transport Security (MTA-STS)» направлен на решение проблемы активных злоумышленников путем определения протокола, позволяющего почтовым серверам заявлять о своей способности использовать безопасные каналы в определенных файлах на сервере и определенных DNS записях TXT. Проверяющая сторона будет регулярно проверять существование такой записи и кэшировать ее на период времени, указанный в записи, и никогда не обмениваться данными по незащищенным каналам до истечения срока действия записи. Обратите внимание, что записи MTA-STS применяются только к SMTP-трафику между почтовыми серверами, в то время как связь между клиентом пользователя и почтовым сервером защищена транспортным уровнем безопасности с SMTP/MSA, IMAP, POP3 или HTTPS в сочетании с организационной или технической политикой. По сути, MTA-STS — это средство распространения такой политики на третьи стороны.

В апреле 2019 года Google Mail объявила о поддержке MTA-STS.

Отчеты SMTP TLS

Протоколы, предназначенные для безопасной доставки сообщений, могут выйти из строя из-за неправильной конфигурации или преднамеренного активного вмешательства, что приводит к недоставке сообщений или доставке по незашифрованным или неаутентифицированным каналам. RFC   8460 «Отчеты SMTP TLS» описывает механизм и формат отчетов для обмена статистикой и конкретной информацией о потенциальных сбоях с доменами получателей. Домены-получатели могут затем использовать эту информацию как для обнаружения потенциальных атак, так и для диагностики непреднамеренных неправильных конфигураций.

В апреле 2019 года Google Mail объявила о поддержке отчетов SMTP TLS.

Спуфинг и спам

Основные статьи: Методы защиты от спама и аутентификация электронной почты.

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

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

Вместо этого почтовые серверы теперь используют ряд методов, таких как более строгое соблюдение стандартов, таких как РФК   5322 , Идентифицированная почта DomainKeys , структура политики отправителей и DMARC , DNSBL и серый список для отклонения или помещения в карантин подозрительных писем.

Реализации

Основные статьи: Список программного обеспечения почтовых серверов и Сравнение почтовых серверов.

Связанные запросы на комментарии

• RFC   1123 – Требования к интернет-хостам – применение и поддержка (STD 3)
• RFC   1870 – Расширение службы SMTP для объявления размера сообщения (устарело: RFC   1653 )
• RFC   2505 – Рекомендации по защите от спама для SMTP MTA (BCP 30)
• RFC   2821 – Простой протокол передачи почты
• RFC   2920 - Расширение службы SMTP для конвейерной обработки команд (STD 60)
• RFC   3030 - Расширения службы SMTP для передачи больших и двоичных сообщений MIME
• RFC   3207 – Расширение службы SMTP для защиты SMTP через безопасность транспортного уровня (устарело). RFC   2487 )
• RFC   3461 – Расширение службы SMTP для уведомлений о статусе доставки (устарело). РФК   1891 )
• RFC   3463 – расширенные коды состояния для SMTP (устарело). RFC   1893 , обновленный RFC   5248 )
• RFC   3464 — расширяемый формат сообщений для уведомлений о статусе доставки (устаревший). РФК   1894 )
• RFC   3798 – Уведомление о размещении сообщения (обновления RFC   3461 )
• RFC   3834 – Рекомендации по автоматическим ответам на электронную почту
• RFC   3974 – Опыт работы SMTP в смешанных средах IPv4/v6
• RFC   4952 – Обзор и структура интернационализированной электронной почты (обновлено RFC   5336 )
• RFC   4954 – Расширение службы SMTP для аутентификации (устарело). RFC   2554 , обновления RFC   3463 , обновленный RFC   5248 )
• RFC   5068 – Операции по отправке электронной почты: требования к доступу и подотчетности (BCP 134)
• RFC   5248 — Реестр кодов состояния расширенной почтовой системы SMTP (BCP 138) (обновления RFC   3463 )
• RFC   5321 – Простой протокол передачи почты (устаревший). RFC   821 , он же STD 10, РФК   974 , РФК   1869 , RFC   2821 , обновления RFC   1123 )
• RFC   5322 – Формат Интернет-сообщений (устаревший). RFC   822, также известный как STD 11, и RFC   2822 )
• RFC   5504 – Механизм понижения версии для интернационализации адресов электронной почты
• RFC   6409 – Отправка сообщений по почте (STD 72) (устарело). RFC   4409 , RFC   2476 )
• RFC   6522 – Тип контента Multipart/Report для отчетов об административных сообщениях почтовой системы (устаревший RFC   3462 и, в свою очередь, РФК   1892 )
• RFC   6531 – Расширение SMTP для интернационализированных адресов электронной почты (обновления РФК   2821 , РФК   2822 , RFC   4952 и RFC   5336 )
• RFC   8314 – Открытый текст считается устаревшим: использование безопасности транспортного уровня (TLS) для отправки электронной почты и доступа к ней

См. также

• Адрес возврата
• CRAM-MD5 (механизм SASL для ESMTPA) РФК   2195
• Электронная почта
  • Шифрование электронной почты
• ДКИМ
• Идентификатор
• Список программного обеспечения почтового сервера
• Список кодов возврата SMTP-сервера
• POP перед SMTP/SMTP после POP
• протокола доступа к сообщениям Интернета Расширение двоичного содержимого RFC   3516
• Структура политики отправителей (SPF)
• Простой уровень аутентификации и безопасности (SASL) RFC   4422
• SMTP-аутентификация
• Переменный путь возврата конверта
• Сравнение почтовых клиентов для получения информации о поддержке SMTP

Ссылки

• Хьюз, Л. (1998). Электронная почта Интернета: протоколы, стандарты и реализация . Издательство «Артех Хаус». ISBN  978-0-89006-939-4 .
• Хант, К. (2003). Поваренная книга sendmail . О'Рейли Медиа. ISBN  978-0-596-00471-2 .
• Джонсон, К. (2000). Протоколы электронной почты Интернета: Руководство разработчика . Аддисон-Уэсли Профессионал. ISBN  978-0-201-43288-6 .
• Лошин, П (1999). Основные стандарты электронной почты: RFC и протоколы стали практичными . Джон Уайли и сыновья. ISBN  978-0-471-34597-8 .
• Ротон, Дж (1999). Руководство программиста по электронной почте в Интернете: SMTP, POP, IMAP и LDAP . Эльзевир. ISBN  978-1-55558-212-8 .
• Вуд, Д. (1999). Программирование Интернет-почты . О'Рейли. ISBN  978-1-56592-479-6 .

Внешние ссылки

• RFC   1869 Расширения службы SMTP
• RFC   5321 Простой протокол передачи почты
• RFC   4954 Расширение службы SMTP для аутентификации (устарело). RFC   2554 )
• RFC   3848 Регистрация типов передачи SMTP и LMTP (с ESMTPA)
• RFC   6409 Отправка сообщений по почте (устарело) RFC   4409 , который устарел. RFC   2476 )