Простой протокол передачи почты
Набор интернет-протоколов |
---|
Прикладной уровень |
Транспортный уровень |
Интернет-слой |
Слой связи |
Простой протокол передачи почты ( SMTP ) — это Интернета стандартный протокол связи для передачи электронной почты . Почтовые серверы и другие агенты передачи сообщений используют SMTP для отправки и получения почтовых сообщений. уровня пользователя Почтовые клиенты обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции и обычно отправляют исходящую электронную почту на почтовый сервер через порт 587 или 465 на каждый. RFC 8314 . Для получения сообщений стандартом является IMAP (который заменил старый POP3 ), но проприетарные серверы также часто реализуют проприетарные протоколы, например Exchange ActiveSync .
Истоки SMTP начались в 1980 году и основывались на концепциях, реализованных в ARPANET с 1971 года. Он неоднократно обновлялся, изменялся и расширялся. Широко используемая сегодня версия протокола имеет расширяемую структуру с различными расширениями для аутентификации , шифрования , передачи двоичных данных и интернационализированных адресов электронной почты . Серверы SMTP обычно используют протокол управления передачей на портах 25 (между серверами) и 587 (для отправки от аутентифицированных клиентов), как с шифрованием, так и без него.
История
[ редактировать ]Предшественники SMTP
[ редактировать ]различные формы индивидуального электронного обмена сообщениями В 1960-х годах использовались . Пользователи общались с помощью систем, разработанных для конкретных мейнфреймов . правительства США Поскольку все больше компьютеров были соединены между собой, особенно в сети ARPANET , были разработаны стандарты, позволяющие обмениваться сообщениями между различными операционными системами.
Почта в ARPANET берет свое начало в 1971 году: протокол почтового ящика, который не был реализован, [ 1 ] но обсуждается в RFC 196 ; и программу SNDMSG , которую в том же году Рэй Томлинсон из BBN адаптировал для отправки сообщений на два компьютера в сети ARPANET. [ 2 ] [ 3 ] [ 4 ] Дальнейшее предложение по почтовому протоколу было сделано в RFC 524 в июне 1973 года. [ 5 ] что не было реализовано. [ 6 ]
Использование протокола передачи файлов (FTP) для «сетевой почты» в ARPANET было предложено в RFC 469 в марте 1973 года. [ 7 ] Через RFC 561, RFC 680, RFC 724 и, наконец, RFC 733 в ноябре 1977 года была разработана стандартизированная структура «электронной почты» с использованием почтовых серверов FTP. [ 8 ] [ 9 ]
SMTP вырос из этих стандартов, разработанных в 1970-х годах. Рэй Томлинсон обсуждал сетевую почту в Международной сетевой рабочей группе в примечании к протоколу 2 INWG , написанном в сентябре 1974 года. [ 10 ] INWG обсуждала протоколы электронной почты в 1979 году. [ 11 ] на который ссылался Джон Постел в своей ранней работе по электронной почте в Интернете. Постел впервые предложил протокол интернет-сообщений в 1979 году в рамках серии заметок об экспериментах в Интернете (IEN). [ 12 ] [ 13 ] [ 14 ]
Оригинальный SMTP
[ редактировать ]In 1980, Postel and Suzanne Sluizer published 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, [ 15 ] UUCP как почтовый транспорт практически исчез [ 16 ] наряду с « путями взрыва » он использовался в качестве заголовков маршрутизации сообщений. [ 17 ]
Sendmail , выпущенный вместе с версией 4.1cBSD в 1983 году, был одним из первых агентов передачи почты, реализовавших SMTP. [ 18 ] Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал самым распространенным MTA (агентом передачи почты). [ 19 ]
Исходный протокол SMTP поддерживал только неаутентифицированную незашифрованную 7-битную текстовую связь ASCII, уязвимую для тривиальной атаки «человек посередине» , спуфинг и спам , а также требующую кодирования любых двоичных данных в читаемый текст перед передачей. Из-за отсутствия надлежащего механизма аутентификации каждый SMTP-сервер по своей конструкции представлял собой открытый ретранслятор почты . Консорциум Интернет-почты (IMC) сообщил, что в 1998 году 55% почтовых серверов были открытыми ретрансляторами. [ 20 ] но менее 1% в 2002 г. [ 21 ] Из-за проблем со спамом большинство провайдеров электронной почты блокируют открытые ретрансляторы, [ 22 ] что делает оригинальный 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, среди них Джон Постел , Эрик Оллман , Дэйв Крокер, Нед Фрид , Рэндалл Гелленс, Джон Кленсин и Кейт Мур .
Модель обработки почты
[ редактировать ]Электронная почта отправляется почтовым клиентом ( агент пользователя почты , 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 состоит из трех последовательностей команд/ответов:
- Команда MAIL для установки обратного адреса, также называемая обратным путем. [ 23 ] обратный путь, [ 24 ] адрес возврата , mfrom или отправитель конверта.
- Команда RCPT для установления получателя сообщения. Эту команду можно выполнить несколько раз, по одному для каждого получателя. Эти адреса также являются частью конверта.
- 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
команда, которая работает более безопасно, используя метод аутентификации , основанный на информации системы доменных имен . [ 25 ]
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 от своих клиентов. В основном в качестве меры защиты от спама, [ 26 ] но также и для того, чтобы компенсировать более высокие затраты, которые они несут, оставляя его открытым, возможно, за счет взимания большей платы с тех немногих клиентов, которые требуют, чтобы он был открыт.
Пример SMTP-транспорта
[ редактировать ]Типичный пример отправки сообщения по SMTP на два почтовых ящика ( alice и theboss ), расположенных в одном почтовом домене ( example.com ), воспроизводится в следующем сеансе обмена. (В этом примере части диалога имеют префикс S: и C: для сервера и клиента соответственно; эти метки не являются частью обмена.)
После того как отправитель сообщения (клиент SMTP) устанавливает надежный канал связи с получателем сообщения (сервером SMTP), сеанс открывается приветствием сервера, обычно содержащим его полное доменное имя (FQDN), в данном случае smtp.example. .com . Клиент инициирует диалог, отвечая HELO
команда, идентифицирующая себя в параметре команды с помощью своего полного доменного имени (или литерала адреса, если он недоступен). [ 27 ]
S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S: 250 Hello relay.example.org, I am glad to meet you C: MAIL FROM:<[email protected]> S: 250 Ok C: RCPT TO:<[email protected]> S: 250 Ok C: RCPT TO:<[email protected]> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C:From: "Bob Example" <[email protected]>
C:To: "Alice Example" <[email protected]>
C:Cc: [email protected]
C:Date: Tue, 15 Jan 2008 16:02:43 -0500
C:Subject: Test message
C: C: Hello Alice. C: This is a test message with 5 header fields and 4 lines in the message body. C: Your friend, C: Bob C: . S: 250 Ok: queued as 12345 C: QUIT S: 221 Bye {The server closes the connection}
Клиент уведомляет получателя об исходном адресе электронной почты сообщения в MAIL FROM
команда. Это также адрес возврата или возврата на случай, если сообщение не может быть доставлено. В этом примере сообщение электронной почты отправляется в два почтовых ящика на одном SMTP-сервере: по одному для каждого получателя, указанного в To:
и Cc:
поля заголовка. Соответствующая команда SMTP: RCPT TO
. Каждый успешный прием и выполнение команды подтверждается сервером кодом результата и ответным сообщением (например, 250 Ok
).
Передача тела почтового сообщения инициируется с помощью DATA
команда, после которой она передается дословно построчно и завершается последовательностью конца данных. Эта последовательность состоит из новой строки ( <CR><LF>
), одна точка ( .
), за которым следует еще одна новая строка ( <CR><LF>
). Поскольку тело сообщения может содержать строку только с точкой как часть текста, клиент отправляет две точки каждый раз, когда строка начинается с точки; соответственно, сервер заменяет каждую последовательность двух точек в начале строки на одну. Такой метод экранирования называется точечной загрузкой .
Положительный ответ сервера на сообщение об окончании данных, как показано на примере, подразумевает, что сервер взял на себя ответственность за доставку сообщения. Сообщение может быть дублировано, если в этот момент произошел сбой связи, например, из-за нехватки электроэнергии: до тех пор, пока отправитель не получит это сообщение. 250 Ok
ответа, он должен предположить, что сообщение не было доставлено. С другой стороны, после того как получатель решил принять сообщение, он должен предположить, что сообщение ему доставлено. Таким образом, в течение этого периода времени оба агента имеют активные копии сообщения, которое они попытаются доставить. [ 28 ] Вероятность того, что сбой связи произойдет именно на этом этапе, прямо пропорциональна объему фильтрации, которую сервер выполняет над телом сообщения, чаще всего в целях защиты от спама. Ограничение времени ожидания установлено равным 10 минутам. [ 29 ]
The QUIT
команда завершает сеанс. Если у электронного письма есть другие получатели, находящиеся в другом месте, клиент будет QUIT
и подключитесь к соответствующему SMTP-серверу для последующих получателей после того, как текущие адресаты были поставлены в очередь. Информация, которую клиент отправляет в HELO
и MAIL FROM
команды добавляются (не показаны в примере кода) в качестве дополнительных полей заголовка к сообщению принимающим сервером. Он добавляет Received
и Return-Path
поле заголовка соответственно.
В некоторых клиентах реализовано закрытие соединения после принятия сообщения ( 250 Ok: queued as 12345
), поэтому последние две строки могут быть опущены. Это вызывает ошибку на сервере при попытке отправить 221 Bye
отвечать.
SMTP-расширения
[ редактировать ]Механизм обнаружения расширений
[ редактировать ]Клиенты изучают поддерживаемые сервером параметры, используя EHLO
приветствие, как показано ниже, вместо оригинального HELO
. Клиенты возвращаются к HELO
только если сервер не поддерживает EHLO
приветствие. [ 30 ]
Современные клиенты могут использовать ключевое слово расширения ESMTP. SIZE
запросить у сервера максимальный размер сообщения, которое будет принято. Старые клиенты и серверы могут попытаться передать сообщения слишком большого размера, которые будут отклонены после потребления сетевых ресурсов, включая время подключения к сетевым каналам, которое оплачивается поминутно. [ 31 ]
Пользователи могут вручную заранее определить максимальный размер, принимаемый серверами ESMTP. Клиент заменяет HELO
команда с помощью EHLO
команда.
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP
Таким образом, smtp2.example.com заявляет, что он может принимать фиксированный максимальный размер сообщения, не превышающий 14 680 064 октетов (8-битных байтов).
В простейшем случае сервер ESMTP объявляет максимальную SIZE
сразу после получения EHLO
. В соответствии с RFC 1870 , однако числовой параметр для SIZE
расширение в EHLO
ответ не является обязательным. Вместо этого клиенты могут при выдаче MAIL FROM
В команду включают числовую оценку размера передаваемого сообщения, чтобы сервер мог отказаться от приема слишком больших сообщений.
Передача двоичных данных
[ редактировать ]Исходный SMTP поддерживает только одно тело текста ASCII, поэтому любые двоичные данные должны быть закодированы как текст в этом теле сообщения перед передачей, а затем декодированы получателем. двоичные кодировки текста , такие как uuencode и BinHex Обычно использовались .
Для решения этой проблемы была разработана команда 8BITMIME. Он был стандартизирован в 1994 году как РФК 1652 [ 32 ] Он облегчает прозрачный обмен сообщениями электронной почты , содержащими октеты за пределами семибитного набора символов ASCII , кодируя их как части содержимого MIME , обычно кодируемые с помощью Base64 .
Расширения механизма доставки почты
[ редактировать ]Ретрансляция почты по требованию
[ редактировать ]Ретрансляция почты по требованию ( ODMR ) — это расширение SMTP, стандартизированное в RFC 2645 , который позволяет периодически подключаемому SMTP-серверу получать электронную почту, поставленную в очередь, при его подключении.
Расширение интернационализации
[ редактировать ]Исходный SMTP поддерживает адреса электронной почты, состоящие только из символов ASCII , что неудобно для пользователей, чей собственный алфавит не основан на латинице или которые используют диакритические знаки, не входящие в набор символов ASCII. Это ограничение было устранено с помощью расширений, включающих UTF-8 в именах адресов. В RFC 5336 введены экспериментальные [ 31 ] UTF8SMTP
командование, а затем был заменен RFC 6531, который представил SMTPUTF8
команда. Эти расширения обеспечивают поддержку многобайтовых символов и символов, отличных от ASCII, в адресах электронной почты, например символов с диакритическими знаками и символов других языков, таких как греческий и китайский . [ 33 ]
Текущая поддержка ограничена, но существует большой интерес к широкому внедрению 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 6152ATRN
– АутентифицированныйTURN
для ретрансляции почты по требованию , РФК 2645AUTH
– Аутентифицированный SMTP, RFC 4954CHUNKING
- Дробление, РФК 3030DSN
– Уведомление о статусе доставки, RFC 3461 (см. путь возврата переменного конверта )ETRN
– Расширенная версия команды запуска удаленной очереди сообщений.TURN
, РФК 1985 г.HELP
- Предоставлять полезную информацию, RFC 821PIPELINING
– Конвейерная обработка команд, РФК 2920SIZE
– объявление размера сообщения, РФК 1870STARTTLS
– Безопасность транспортного уровня , RFC 3207 (2002 г.)SMTPUTF8
– Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC 6531UTF8SMTP
– Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC 5336 (устаревший) [ 34 ] )
Формат ESMTP был переформулирован в RFC 2821 (заменяющий RFC 821) и обновленный до последней версии определения. RFC 5321 в 2008 г. Поддержка EHLO
команда на серверах стала обязательной, и HELO
обозначен как необходимый запасной вариант.
Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются значком. EHLO
ключевое слово сообщения, начинающееся с буквы «X» и любые дополнительные параметры или глаголы, отмеченные аналогичным образом.
Команды SMTP нечувствительны к регистру. Они представлены здесь с заглавной буквы только для акцента. SMTP-сервер, требующий определенного метода капитализации, является нарушением стандарта. [ 35 ]
8БИТМИМ
[ редактировать ]По крайней мере, следующие серверы рекламируют расширение 8BITMIME:
- Апач Джеймс (начиная с версии 2.3.0a1) [ 36 ]
- Цитадель (с 7.30)
- Курьерский почтовый сервер
- Gmail [ 37 ]
- IceWarp
- IIS Служба SMTP
- Керио Коннект
- Лотос Домино
- Microsoft Exchange Server (начиная с Exchange Server 2000)
- Novell GroupWise
- ОпенСМТПД
- Сервер обмена сообщениями Oracle Communications
- Постфикс
- Отправить почту (с версии 6.57)
Следующие серверы можно настроить для объявления 8BITMIME, но не выполнять преобразование 8-битных данных в 7-битные при подключении к ретрансляторам, отличным от 8BITMIME:
- Exim и qmail не преобразуют восьмибитные сообщения в семибитные при попытке ретранслировать 8-битные данные узлам, не поддерживающим 8BITMIME, как того требует RFC. [ 38 ] На практике это не вызывает проблем, поскольку практически все современные почтовые ретрансляторы являются 8-битными . [ 39 ]
- Microsoft Exchange Server 2003 по умолчанию объявляет 8BITMIME, но ретрансляция на одноранговый узел, не поддерживающий 8BITMIME, приводит к возврату. Это разрешено разделом 3 RFC 6152 .
SMTP-АУТ
[ редактировать ]Расширение SMTP-AUTH обеспечивает механизм контроля доступа. Он состоит из этапа аутентификации , посредством которого клиент эффективно входит на почтовый сервер во время процесса отправки почты. Серверы, поддерживающие SMTP-AUTH, обычно можно настроить так, чтобы клиенты использовали это расширение, гарантируя, что истинная личность отправителя известна. Расширение SMTP-AUTH определено в РФК 4954 .
SMTP-AUTH можно использовать, чтобы разрешить законным пользователям ретранслировать почту, запрещая при этом услугу ретрансляции неавторизованным пользователям, например спамерам . Это не обязательно гарантирует подлинность отправителя конверта SMTP или Заголовок RFC 2822 «От:». Например, спуфинг , при котором один отправитель маскируется под кого-то другого, по-прежнему возможен с помощью SMTP-AUTH, если только сервер не настроен на ограничение исходящих сообщений адресами, для которых авторизован этот авторизованный пользователь.
Расширение SMTP-AUTH также позволяет одному почтовому серверу сообщать другому, что отправитель прошел проверку подлинности при ретрансляции почты. Обычно для этого требуется, чтобы сервер-получатель доверял серверу-отправителю, а это означает, что этот аспект SMTP-AUTH редко используется в Интернете. [ нужна ссылка ]
SMTPUTF8
[ редактировать ]Поддерживаемые серверы включают в себя:
- Постфикс (версия 3.0 и новее) [ 40 ]
- Импульс (версии 4.1 [ 41 ] и 3.6.5 и позже)
- Sendmail (экспериментальная поддержка в версии 8.17.1)
- Exim (экспериментальный на момент выпуска 4.86, вполне доработанный в версии 4.96)
- CommuniGate Pro начиная с версии 6.2.2 [ 42 ]
- Курьер-МТА начиная с версии 1.0 [ 43 ]
- Халон начиная с версии 4.0 [ 44 ]
- Microsoft Exchange Server начиная с версии протокола 14.0. [ 45 ]
- Харака и другие серверы. [ 46 ]
- Сервер сообщений Oracle Communications, начиная с версии 8.0.2. [ 47 ]
Расширения безопасности
[ редактировать ]Доставка почты может осуществляться как по простому тексту, так и по зашифрованным соединениям, однако взаимодействующие стороны могут не знать заранее о возможности другой стороны использовать безопасный канал.
STARTTLS или «оппортунистический TLS»
[ редактировать ]Расширения STARTTLS позволяют поддерживать SMTP-серверы для уведомления подключающихся клиентов о том, что они поддерживают зашифрованную связь TLS , и предлагают клиентам возможность обновить свое соединение, отправив команду STARTTLS. Серверы, поддерживающие расширение, по своей сути не получают никаких преимуществ в безопасности от его реализации, поскольку обновление до зашифрованного сеанса TLS зависит от подключающегося клиента, решившего использовать эту опцию, отсюда и термин «оппортунистический TLS» .
STARTTLS эффективен только против атак с пассивным наблюдением, поскольку согласование STARTTLS происходит в виде обычного текста, и активный злоумышленник может тривиально удалить команды STARTTLS. Этот тип атаки «человек посередине» иногда называют STRIPTLS , при которой информация о шифровании, отправленная с одного конца, никогда не достигает другого. В этом сценарии обе стороны воспринимают неверные или неожиданные ответы как признак того, что другая сторона не поддерживает должным образом STARTTLS и по умолчанию использует традиционную передачу почты в виде простого текста. [ 48 ] Обратите внимание, что STARTTLS также определен для IMAP и POP3 в других RFC, но эти протоколы служат разным целям: SMTP используется для связи между агентами передачи сообщений, а IMAP и POP3 — для конечных клиентов и агентов передачи сообщений.
В 2014 году Electronic Frontier Foundation запустил проект «STARTTLS Everywhere», который, как и список « HTTPS Everywhere », позволял доверяющим сторонам обнаруживать других, поддерживающих безопасную связь, без предварительного обмена данными. Проект прекратил прием заявок 29 апреля 2021 года, и EFF рекомендовал переключиться на DANE и MTA-STS для получения информации о поддержке TLS коллегами. [ 49 ]
RFC 8314 официально объявил простой текст устаревшим и рекомендует всегда использовать TLS для отправки и доступа к почте, добавляя порты с неявным TLS.
ДЕЙН для SMTP
[ редактировать ]В RFC 7672 появилась возможность для записей DNS декларировать возможности шифрования почтового сервера. Используя DNSSEC , операторы почтовых серверов могут публиковать хеш своего сертификата TLS, тем самым снижая вероятность незашифрованной связи. [ 50 ]
Microsoft планирует обеспечить полную поддержку SMTP DANE для клиентов Exchange Online к концу 2024 года. [ 51 ]
SMTP MTA Строгая транспортная безопасность
[ редактировать ]Новее 2018 года. RFC 8461 под названием «SMTP MTA Strict Transport Security (MTA-STS)» направлен на решение проблемы активных злоумышленников путем определения протокола, позволяющего почтовым серверам заявлять о своей способности использовать безопасные каналы в определенных файлах на сервере и определенных записях DNS TXT. Проверяющая сторона будет регулярно проверять существование такой записи и кэшировать ее на период времени, указанный в записи, и никогда не обмениваться данными по незащищенным каналам до истечения срока действия записи. [ 48 ] Обратите внимание, что записи MTA-STS применяются только к SMTP-трафику между почтовыми серверами, в то время как связь между клиентом пользователя и почтовым сервером защищена транспортным уровнем безопасности с SMTP/MSA, IMAP, POP3 или HTTPS в сочетании с организационной или технической политикой. По сути, MTA-STS — это средство распространения такой политики на третьи стороны.
В апреле 2019 года Google Mail объявила о поддержке MTA-STS. [ 52 ]
SMTP-отчетность TLS
[ редактировать ]Протоколы, предназначенные для безопасной доставки сообщений, могут выйти из строя из-за неправильной конфигурации или преднамеренного активного вмешательства, что приводит к недоставке сообщений или доставке по незашифрованным или неаутентифицированным каналам. RFC 8460 «Отчеты SMTP TLS» описывает механизм и формат отчетов для обмена статистикой и конкретной информацией о потенциальных сбоях с доменами получателей. Домены-получатели могут затем использовать эту информацию как для обнаружения потенциальных атак, так и для диагностики непреднамеренных неправильных конфигураций.
В апреле 2019 года Google Mail объявила о поддержке отчетов SMTP TLS. [ 52 ]
Спуфинг и спам
[ редактировать ]Первоначальная конструкция SMTP не предусматривала возможности аутентификации отправителей или проверки того, что серверы уполномочены отправлять сообщения от их имени, в результате чего подмена электронной почты возможна , которая обычно используется в спаме и фишинге по электронной почте .
Время от времени выдвигаются предложения существенно изменить SMTP или полностью заменить его. Одним из примеров этого является Internet Mail 2000 , но ни он, ни какой-либо другой не добился большого прогресса перед лицом сетевого эффекта огромной установленной базы классического SMTP.
Вместо этого почтовые серверы теперь используют ряд методов, таких как более строгое соблюдение стандартов, таких как РФК 5322 , [ 53 ] [ 54 ] Идентифицированная почта DomainKeys , структура политики отправителей и DMARC , DNSBL и серый список для отклонения или помещения в карантин подозрительных писем. [ 55 ]
Реализации
[ редактировать ]Связанные запросы на комментарии
[ редактировать ]- 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
Примечания
[ редактировать ]- ^ История электронной почты. Архивировано 2 декабря 2017 года в Wayback Machine , Том Ван Флек : « Неясно, был ли когда-либо реализован этот протокол ».
- ^ Первое сетевое электронное письмо , Рэй Томлинсон , BBN
- ^ Изображение « Первого компьютера электронной почты » Дэна Мерфи, PDP-10.
- ^ Документы Дэна Мерфи TENEX и TOPS-20, заархивированные 18 ноября 2007 г., в Wayback Machine.
- ^ RFC 524 – Предлагаемый почтовый протокол
- ^ Крокер, Дэвид Х. (декабрь 1977 г.). «Структура и функции системы персональных сообщений «МС»» (PDF) . Корпорация РЭНД . Архивировано (PDF) из оригинала 13 мая 2022 г. Проверено 17 апреля 2022 г.
- ^ RFC 469 – Сводка собрания сетевой почты
- ^ RFC 733, 21 ноября 1977 г., Стандарт формата текстового сообщения сети ARPA.
- ^ «История электронной почты: сотрудничество, инновации и рождение системы» . Вашингтон Пост . 20 мая 2023 г. ISSN 0190-8286 . Проверено 7 июля 2024 г.
- ^ Маккензи, Александр (2011). «INWG и концепция Интернета: рассказ очевидца». IEEE Анналы истории вычислений . 33 (1): 66–71. дои : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . S2CID 206443072 .
- ↑ Барбер Д. и Дж. Лоуз, «Базовая почтовая схема для EIN», INWG 192, февраль 1979 г.
- ^ ОДИН 85 .
- ^ ОДИН 113 .
- ^ «Указатель заметок об экспериментах в Интернете» . www.rfc-editor.org . Проверено 7 июля 2024 г.
- ^ «Тлдп.орг» . Архивировано из оригинала 17 августа 2007 года . Проверено 25 августа 2007 г.
- ^ Барбер, Стэн О. (19 декабря 2000 г.). «draft-barber-uucp-project-conclusion-05 — Заключение картографического проекта UUCP» . Архивировано из оригинала 13 октября 2007 года . Проверено 25 августа 2007 г.
- ^ Статья о переопределении отправителя содержит техническую информацию о ранней истории SMTP и исходной маршрутизации до РФК 1123 .
- ^ Эрик Оллман (1983), Sendmail - Межсетевой почтовый маршрутизатор (PDF) , набор документации BSD UNIX, Беркли: Калифорнийский университет, заархивировано (PDF) из оригинала 20 мая 2013 г. , получено 29 июня 2012 г.
- ^ Крейг Партридж (2008), Техническое развитие электронной почты в Интернете (PDF) , IEEE Annals of the History of Computing, vol. 30, IEEE Computer Society, стр. 3–29, doi : 10.1109/MAHC.2008.32 , S2CID 206442868 , заархивировано из оригинала (PDF) 12 мая 2011 г.
- ^ Пол Хоффман (1 февраля 1998 г.). «Разрешение ретрансляции в SMTP: опрос» . Консорциум Интернет-почты . Архивировано из оригинала 5 марта 2016 года . Проверено 30 мая 2010 г.
- ^ Пол Хоффман (август 2002 г.). «Разрешение ретрансляции в SMTP: серия опросов» . Консорциум Интернет-почты . Архивировано из оригинала 18 января 2007 года . Проверено 30 мая 2010 г.
- ^ «Что такое открытая ретрансляция почты в Unix? — База знаний» . 17 июня 2007 года. Архивировано из оригинала 17 июня 2007 года . Проверено 15 марта 2021 г.
- ^ «Глаголы MAIL, RCPT и DATA». Архивировано 22 февраля 2014 г., в Wayback Machine , [DJ Bernstein]
- ^ RFC 5321 , раздел 7.2
- ^ Системы, Сообщение. «Системы сообщений представляют новейшую версию Momentum с новыми возможностями, управляемыми через API» . www.prnewswire.com (пресс-релиз). Архивировано из оригинала 19 июля 2020 года . Проверено 19 июля 2020 г.
- ^ Кара Гарретсон (2005). «Интернет-провайдеры принимают участие в борьбе со спамом» . Мир ПК . Архивировано из оригинала 28 августа 2015 года . Проверено 18 января 2016 г.
В прошлом месяце Технический альянс по борьбе со спамом, созданный в прошлом году Yahoo, America Online, EarthLink и Microsoft, опубликовал список рекомендаций по борьбе со спамом, который включает фильтрацию порта 25.
- ^ RFC 5321 , Простой протокол передачи почты , Дж. Кленсин, The Internet Society (октябрь 2008 г.)
- ^ RFC 1047
- ^ Кленсин, Джон К. (октябрь 2008 г.). "rfc5321#section-4.5.3.2.6" . Архивировано из оригинала 16 января 2015 года . Проверено 7 июня 2010 г.
- ^ Джон Кленсин; Нед Фрид; Маршалл Т. Роуз; Эйнар А. Стефферуд; Дэйв Крокер (ноябрь 1995 г.). Расширения службы SMTP . IETF . дои : 10.17487/RFC1869 . РФК 1869 .
- ^ Jump up to: а б «Параметры ПОЧТЫ» . ИАНА. 14 февраля 2020 года. Архивировано из оригинала 28 мая 2019 года . Проверено 28 мая 2019 г.
- ^ Который был устаревшим в 2011 году RFC 6152, соответствующий новому стандарту STD 71.
- ^ Цзянькан Яо (19 декабря 2014 г.). «Китайский адрес электронной почты» . EAI (список рассылки). IETF . Архивировано из оригинала 2 октября 2015 года . Проверено 24 мая 2016 г.
- ^ «Параметры расширения службы SMTP» . ИАНА. Архивировано из оригинала 28 мая 2019 года . Проверено 5 ноября 2013 г.
- ^ Кленсин, Джон К. (октябрь 2008 г.). Простой протокол передачи почты (отчет). Рабочая группа по интернет-инжинирингу.
- ^ Сервер Джеймса — журнал изменений. Архивировано 20 февраля 2020 г. на Wayback Machine . James.apache.org. Проверено 17 июля 2013 г.
- ^ Служба 8BITMIME, рекламируемая в ответ на EHLO на порту 25 gmail-smtp-in.l.google.com, проверено 23 ноября 2011 г.
- ^ Ошибки и список пожеланий Qmail . Home.pages.de. Проверено 17 июля 2013 г.
- ↑ Расширение 8BITMIME. Архивировано 7 июня 2011 года в Wayback Machine . Кр.йп.то. Проверено 17 июля 2013 г.
- ^ « Поддержка Postfix SMTPUTF8 включена по умолчанию ». Архивировано 7 августа 2020 г., на Wayback Machine , 8 февраля 2015 г., postfix.org.
- ^ «Системы сообщений представляют новейшую версию Momentum с новыми возможностями на основе API» (пресс-релиз). Архивировано из оригинала 15 сентября 2020 года . Проверено 17 сентября 2020 г.
- ^ «История изменений версии 6.2» . CommuniGate.com . Архивировано из оригинала 29 октября 2020 года . Проверено 17 сентября 2020 г.
- ^ Сэм Варшавчик (18 сентября 2018 г.). «Новые выпуски курьерских пакетов» . курьер-объявление (список рассылки). Архивировано из оригинала 17 августа 2021 года . Проверено 17 сентября 2020 г.
- ^ «Журнал изменений галона MTA» . Гитхаб . 9 ноября 2021 года. Архивировано из оригинала 18 сентября 2020 года . Проверено 17 сентября 2020 г.
v4.0: новая поддержка SMTPUTF8.
Обновлено для новых версий. - ^ «MS-OXSMTP: расширения простого протокола передачи почты (SMTP)» . 24 июля 2018 года. Архивировано из оригинала 16 августа 2021 года . Проверено 17 сентября 2020 г.
- ^ «Готовность TLD к EAI» (PDF) . 12 февраля 2019 г. Архивировано (PDF) из оригинала 24 января 2021 г. . Проверено 17 сентября 2020 г.
- ^ «Примечания к выпуску сервера обмена сообщениями» . oracle.com . Октябрь 2017. Архивировано из оригинала 24 ноября 2020 года . Проверено 17 сентября 2020 г.
- ^ Jump up to: а б «Представляем строгую транспортную безопасность MTA (MTA-STS) | Блог Hardenize» . www.hardenize.com . Архивировано из оригинала 25 апреля 2019 года . Проверено 25 апреля 2019 г.
- ^ «СТАРТЛС Везде» . ЭФФ. Архивировано из оригинала 9 августа 2019 года . Проверено 4 декабря 2021 г.
- ^ в-матхавале (21 июля 2023 г.). «Как аутентификация именованных объектов на основе SMTP DNS (DANE) защищает электронную почту» . Learn.microsoft.com . Проверено 5 марта 2024 г.
- ^ «Реализация входящего SMTP DANE с DNSSEC для потока почты Exchange Online» . techcommunity.microsoft.com . Проверено 5 марта 2024 г.
- ^ Jump up to: а б Чимпану, Каталин. «Gmail становится первым крупным поставщиком электронной почты, поддерживающим отчеты MTA-STS и TLS» . ЗДНет . Архивировано из оригинала 29 апреля 2019 года . Проверено 25 апреля 2019 г.
- ^ «Сообщение не соответствует RFC 5322» . Архивировано из оригинала 17 января 2023 года . Проверено 20 января 2021 г.
- ^ «Не удалось доставить сообщение. Убедитесь, что сообщение соответствует RFC 5322» . Архивировано из оригинала 28 января 2021 года . Проверено 20 января 2021 г.
- ^ «Почему электронные письма, отправленные на учетную запись Microsoft, отклоняются по соображениям политики?» . Архивировано из оригинала 14 февраля 2021 года . Проверено 20 января 2021 г.
Ссылки
[ редактировать ]- Хьюз, Л. (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 .