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

Simple Mail Transfer Protocol ( SMTP ) является протоколом связи для электронной почты передачи. В качестве стандарта Интернета SMTP был впервые определен в 1982 году в RFC  821 и обновлен в 2008 году в RFC 5321 до дополнений Extended SMTP, который является разновидностью протоколов, широко используемых сегодня. Почтовые серверы и другие агенты передачи сообщений используют SMTP для отправки и получения почтовых сообщений. SMTP-серверы обычно используют протокол управления передачей на порту 25. 

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

История [ править ]

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

SMTP уходит своими корнями в две реализации, описанные в 1971 году: протокол почтового ящика, реализация которого оспаривается ^[1], но обсуждается в RFC 196 и других RFC, и программа SNDMSG, которая, согласно RFC 2235 , Рэй Томлинсон из BBN изобрела компьютеры TENEX для отправки почтовых сообщений через ARPANET. ^{[2] [3] [4]} На данный момент к ARPANET было подключено менее 50 хостов. ^[5]  

Дальнейшие реализации включают FTP Mail ^[6] и Mail Protocol, оба с 1973 года. ^[7] Разработка продолжалась в 1970-х годах, пока ARPANET не перешла в современный Интернет примерно в 1980 году. Затем Джон Постел предложил протокол передачи почты в 1980 году, который начал применяться. убрать зависимость почты от FTP . ^[8] SMTP был опубликован как RFC 788 в ноябре 1981 года, также Postel. 

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

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

Sendmail , выпущенный вместе с 4.1cBSD в 1982 году, вскоре после публикации RFC 788 в ноябре 1981 года, был одним из первых агентов передачи почты, реализовавших SMTP. ^[12] Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал наиболее распространенным агентом передачи почты ( MTA ). ^[13] Некоторые другие популярные программы SMTP-серверов включают Postfix , qmail , Novell GroupWise , Exim , Novell NetMail , Microsoft Exchange Server и Oracle Communications Messaging Server . 

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

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

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

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

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

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

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

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

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

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

Обзор протокола [ править ]

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

1. Команда MAIL , чтобы установить адрес возврата, также называемый обратным путем, ^[15] обратным путем, ^[16] адресом возврата, mfrom или отправителем конверта.
2. Команда RCPT , чтобы установить получателя сообщения. Эту команду можно вводить несколько раз, по одной для каждого получателя. Эти адреса также являются частью конверта.
3. ДАННЫЕ для обозначения начала текста сообщения ; содержание сообщения, а не его конверт. Он состоит из заголовка сообщения и тела сообщения , разделенных пустой строкой. 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 против получения почты [ править ]

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

Запуск удаленной очереди сообщений [ править ]

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

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 своих клиентов в качестве меры защиты от спама. ^[19] По той же причине предприятия обычно настраивают свой брандмауэр так, чтобы разрешать исходящий трафик порта 25 только со своих назначенных почтовых серверов.

Пример транспорта SMTP [ править ]

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

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

S: 220 smtp.example.com ESMTP PostfixC: HELO relay.example.comS: 250 smtp.example.com, рад знакомствуC: ПОЧТА ОТ: <[email protected]>S: 250 ХорошоC: RCPT Кому: <[email protected]>S: 250 ХорошоC: RCPT Кому: <[email protected]>S: 250 ХорошоC: ДАННЫЕS: 354 Завершите данные с помощью <CR><LF>.<CR> <LF>C: От: "Пример Боба" <[email protected]>C: Кому: Алисе Пример <[email protected]>C: Копия: [email protected]C: Дата: Вт, 15 января 2008 г., 16:02:43 -0500C: Тема: Тестовое сообщениеC: C: Привет, Алиса.C: Это тестовое сообщение с 5 полями заголовка и 4 строками в теле сообщения.C: Ваш друг,C: БобC:.S: 250 Ok: в очереди как 12345C: ВЫЙТИS: 221 Пока{Сервер закрывает соединение}

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

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

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

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

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

Расширенный простой протокол передачи почты [ править ]

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

Обнаружение дополнительных расширений [ править ]

Клиенты изучают поддерживаемые сервером параметры, используя EHLOприветствие, как показано ниже, вместо оригинала HELO(пример выше). Клиенты отключаются HELOтолько в том случае, если сервер не поддерживает расширения SMTP. ^[23]

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

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

S: 220 smtp2.example.com ESMTP PostfixC: EHLO bob.example.comS: 250-smtp2.example.com Здравствуйте, bob.example.org [192.0.2.201] S: РАЗМЕР 250 14680064 S: 250-ТРУБОПРОВОД S: 250 ПОМОЩЬ

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

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

Передача двоичных данных [ править ]

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

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

Расширения механизма доставки почты [ править ]

Ретранслятор почты по требованию [ править ]

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

Расширение интернационализации [ править ]

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

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

Расширения [ править ]

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

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

Каждое расширение услуги определяется в утвержденном формате в последующих RFC и регистрируется в Internet Assigned Numbers Authority (IANA). Первые определения были RFC 821 дополнительные услуги: SEND, SOML(Send или Mail), SAML(Send и Mail), EXPN, HELPи TURN. Был установлен формат дополнительных SMTP-глаголов и для новых параметров в MAILи RCPT.

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

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

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

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

Команды SMTP не чувствительны к регистру. Они представлены здесь с заглавной буквы только для акцента. SMTP-сервер, для которого требуется особый метод использования заглавных букв, является нарушением стандарта. ^{[ необходима цитата ]}

8BITMIME [ править ]

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

• Apache James (начиная с 2.3.0a1) ^[29]
• Цитадель (с 7.30)
• Курьерский почтовый сервер
• Gmail ^[30]
• IceWarp
• Служба IIS SMTP
• Kerio Connect
• Lotus Domino
• Microsoft Exchange Server (начиная с Exchange Server 2000)
• Novell GroupWise
• OpenSMTPD
• Сервер обмена сообщениями Oracle Communications
• Постфикс
• Sendmail (с 6.57)

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

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

SMTP-AUTH [ править ]

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

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

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

SMTPUTF8 [ править ]

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

• Postfix (версия 3.0 и новее) ^[33]
• Momentum (версии 4.1 ^[34] и 3.6.5, и более поздние)
• Sendmail (в разработке)
• Exim (экспериментальный, начиная с версии 4.86)
• CommuniGate Pro, начиная с версии 6.2.2 ^[35]
• Courier-MTA с версии 1.0 ^[36]
• Галон, начиная с версии 4.0 ^[37]
• Сервер Microsoft Exchange с версией протокола 14.0 ^[38]
• Харака и другие серверы. ^[39]
• Oracle Communications Messaging Server, начиная с версии 8.0.2. ^[40]

Расширения безопасности [ править ]

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

SMTP-аутентификация [ править ]

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

STARTTLS или «Оппортунистический TLS» [ править ]

Расширения SMTP описывают команду STARTTLS, которая позволяет серверу сообщить клиенту, что он поддерживает шифрованную связь, а клиенту - запросить обновление до безопасного канала. STARTTLS эффективен только против атак с пассивным наблюдением, поскольку согласование STARTTLS происходит в виде обычного текста, и активный злоумышленник может тривиально удалить команду STARTTLS, такая атака иногда называется STRIPTLS (клиент может подумать, что сервер не отправил заголовок STARTTLS, поэтому не поддерживает STARTTLS, в то время как сервер может подумать, что клиент не ответил на заголовок STARTTLS и, следовательно, не поддерживает STARTTLS). ^[41] Обратите внимание, что STARTTLS также определен для IMAP и POP3. в других RFC, но эти протоколы служат другим целям: SMTP используется для связи между агентами передачи сообщений, а IMAP и POP3 - для конечных клиентов и агентов передачи сообщений.

Electronic Frontier Foundation ведет список «STARTTLS Everywhere», который, как и список « HTTPS Everywhere », позволяет доверяющим сторонам обнаруживать других, поддерживающих безопасную связь, без предварительного взаимодействия. ^[42]

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

SMTP MTA Strict Transport Security [ править ]

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

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

Отчеты SMTP TLS [ править ]

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

В апреле 2019 года Google Mail объявила о поддержке SMTP TLS Reporting. ^[43]

Спуфинг и рассылка спама [ править ]

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

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

Вместо почтовых серверов теперь используют ряд методов, таких , как строгое соблюдение стандартов , таких как RFC 5322 , ^{[44] [45]} DomainKeys Выявленные почта , Sender Рамочные политики и DMARC , DNSBLs и Грейлистинг отклонить или карантин подозрительные сообщения. ^[46] 

Реализации [ править ]

Также существует реализация прокси SMTP, например nginx . ^[47]

Похожие запросы на комментарии [ править ]

• RFC  1123 - Требования к Интернет-хостам - приложение и поддержка (STD 3)
• RFC  1870 - расширение службы SMTP для объявления размера сообщения (устарело: RFC 1653 ) 
• RFC  2505 - Рекомендации по защите от спама для MTA SMTP (BCP 30)
• RFC  2821 - Простой протокол передачи почты
• RFC  2920 - расширение службы SMTP для конвейерной обработки команд (STD 60)
• RFC  3030 - Расширения службы SMTP для передачи больших и двоичных сообщений MIME
• RFC  3207 - Расширение службы SMTP для безопасного SMTP через безопасность транспортного уровня (устаревший RFC 2487 ) 
• RFC  3461 - расширение службы SMTP для уведомлений о состоянии доставки ( RFC 1891 устарел ) 
• RFC  3463 - расширенные коды состояния для SMTP (устаревший RFC 1893 , обновленный RFC 5248 )  
• RFC  3464 - расширяемый формат сообщений для уведомлений о состоянии доставки ( RFC 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, RFC 974 , RFC 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 и, в свою очередь, RFC 1892 )  
• RFC  6531 - расширение SMTP для интернационализированных адресов электронной почты (обновляет RFC 2821 , RFC 2822 , RFC 4952 и RFC 5336 )    
• RFC  8314 - Открытый текст считается устаревшим: использование безопасности транспортного уровня (TLS) для отправки электронной почты и доступа

Список поддерживаемых серверов [ править ]

• IceWarp
• Postfix  - патчи для RFC 6531 .. RFC 6533 не требуются .
• Sendmail  - патч исходного кода, необходимый для поддержки SMTPUTF8
• HMailServer  - бесплатный почтовый сервер для Windows
• Exim
• MailEnable - поддержка только в Enterprise Edition
• MagicMail - объединение конвейеров намеренно не поддерживается

Список поддерживающих клиентов [ править ]

• nmh (с версии 1.7)
• Mozilla Thunderbird (начиная с версии 82.0) ^[48]

Список поддерживаемых фильтров содержимого [ править ]

• Amavis (SMTP и LMTP), начиная с версии 2.10.0 ^[49]

См. Также [ править ]

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

Заметки [ править ]

Ссылки [ править ]

• Хьюз, Л. (1998). Электронная почта в Интернете: протоколы, стандарты и реализация . Издательство Artech House. ISBN 978-0-89006-939-4.
• Хант, C (2003). sendmail Кулинарная книга . O'Reilly Media. 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.

Внешние ссылки [ править ]

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