Как работает протокол smtp. Самое интересное про SMTP, POP3 и IMAP. Что такое POP3

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

Что такое SMTP?

Сокращение SMTP происходит от английского словосочетания , что в переводе означает «простой протокол отправки почты». В основном область его применения ограничивается сетями на основе TCP/IP и пользовательским уровнем.

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

Нужна ли настройка сервера при отправке письма с почтового сервиса?

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

Сами же сервисы для входа в собственный почтовый ящик требуют от пользователя только ввода логина и пароля, указанных при регистрации, и настраивать, например, SMTP-сервер Mail.Ru не требуется всего лишь по той причине, что в самом сервисе все это было сделано изначально (без этого служба просто не работала бы). Но что делать, если пользователь интернет-ресурсами по какой-то причине не пользуется, а предпочитает стандартные клиенты вроде майкрософтовских Outlook Express и Outlook или сторонние программные продукты, имея при этом зарегистрированный ящик именно в интернет-сервисе?

Настраиваем сервер SMTP (Mail.Ru - почтовый сервис, где зарегистрирован ящик)

Посмотрим на стандартные параметры, которые следует применить к данному сервису. Вне зависимости от используемого почтового клиента абсолютно все настройки будут идентичными.

Итак, для того чтобы правильно сконфигурировать SMTP-сервер Mail.Ru, следует задать следующие параметры:

• сервер исходящей корреспонденции - smtp.mail.ru;
• имя юзера - полное название зарегистрированного в сервисе адреса электронной почты;
• пароль - текущее кодовое сочетание литер, цифр и символов, используемое для входа в ящик;
• порт при выборе протокола шифрования SSL/TLS - 465.

После вступления в силу этих настроек почту можно будет принимать непосредственно в используемой пользовательской программе. Как видим, порт SMTP-сервера отличается от стандартного (25), но это связано уже с протоколами TCP/IP.

Настраиваем сервер SMTP на Yandex

Не менее популярным является и сервис Yandex.Ru. SMTP-сервер для него настраивается полностью аналогичным образом.

Однако для сервера исходящих сообщений применяется адрес smtp.yandex.ru, для порта указывается значение 465, но в настройках защиты устанавливается исключительно TLS.

Устанавливаем SMTP-сервер для рассылки

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

В первом случае, если приобретается «белый» сервер, это потребует весомых затрат, а также соблюдения всех условий разработчика или продавца. Можно, конечно, приобрести «серый» сервер, однако здесь нет гарантии, что он не будет внесен в спам-базы поисковых систем. Чревато это только тем, что тот же Yandex при поступлении писем с указанных источников будет просто фильтровать их и отправлять в раздел спама, а Mail.Ru и Google помечают корреспонденцию соответствующим индексом «спамности». Настройка же SMTP-сервера вручную выглядит и более надежной, и более экономной в плане финансовых затрат.

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

Далее нужно установить панель Vesta. В качестве примера используем утилиту PuTTY, которую нужно скачать, установить и запустить. В настройках сразу прописываем IP-адрес сервера, далее жмем кнопку Open и прописываем логин root и пароль, предоставленный при покупке VPS-сервера.

Теперь последовательно вводим следующие команды:

curl -O http://vestacp.com/pub/vst-install.sh

bash vst-install.sh

Если возникает ошибка, решаем ее при помощи сочетания:

bash vst-install-rhel.sh —force

После этого вводим действительный адрес электронного ящика и название хоста. Через 5-10 минут панель установится.

https://IP сервера:8083

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

На следующем этапе регистрируем домен и переходим в панель параметров DNS, где меняем местами и A.

Ждем, пока произойдет обновление DNS-зон, и переходим на вкладку WEB в панели Vesta, где добавляем зарегистрированный домен.

После этого регистрируем аккаунты SMTP в разделе Mail. Для проверки в том же разделе используем вкладку Open Webmail. В появившемся окне EXIM-сервера вводим параметры созданного SMTP и отправляем пробное письмо. Если все нормально, можно себя поздравить.

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

Вместо послесловия

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

S imple M ail T ransfer P rotocol ) – протокол передачи сообщений с компьютера на почтовый сервер для доставки конечному получателю. Этот протокол обеспечивает перенаправление почтовых сообщений (с помощью записей MX, или записей программы обмена электронной почтой, и записей А, или записей хоста в системе DNS), форматирование почтовых сообщений и установление сеансов между почтовыми клиентами и почтовыми серверами. В протоколе SMTP в качестве транспортного протокола обычно используется TCP , но могут применяться и другие протоколы, как определено в документе RFC 821 .

История

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

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

Принцип работы

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

Но в спецификации SMTP определен формат электронной почты и указано, какие наборы символов могут применяться в сообщениях электронной почты. Первоначально в спецификации SMTP было определено использование только 7-битовых символов ASCII . Но с появлением ] и превращением Internet во всемирную сеть было предложено включить в дополнительные спецификации другие наборы символов. Благодаря этому в настоящее время электронное письмо может быть отправлено практически на любом национальном языке, а к письму могут прилагаться в закодированном виде данные почти любого типа, даже такие как изображения или исполняемые файлы. После внедрения всех этих дополнений протокол SMTP стал более сложным, но вместе с тем и более гибким.

Задачи

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры Mail Forwarding, проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней - его закрытие.

Команды SMTP указывают серверу, какую операцию хочет произвести клиент. Команды состоят из ключевых слов, за которыми следует один или более параметров. Ключевое слово состоит из 4-х символов и разделено от аргумента одним или несколькими пробелами. Каждая командная строка заканчивается символами CRLF. Вот синтаксис всех команд протокола SMTP (SP - пробел):

HELO MAIL FROM: RCPT TO: DATA RSET SEND FROM: SOML FROM: SAML FROM: VRFY EXPN HELP NOOP QUIT

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

Команды

Каждая команда SMTP начинается с ключевого слова – названия команды. За ним могут следовать параметры, отделенные пробелом.

Регистр символов, используемых во всех названиях команд и, за редким исключением, в параметрах базового протокола SMTP, не имеет значения. Однако в некоторых элементах расширений строчные и прописные символы могут различаться. Необходимо также учитывать, что левая часть почтового адреса, до символа @, может быть регистрозависимой.

В командах допускается использование только кодировки us - ascii, то есть символов, кодируемых семью битами. Это цифры, латинские буквы, и знаки препинания. Если информация передается восьмибитными блоками (октетами), старший бит должен быть равен нулю. Корректная интерпретация символов, старший, восьмой бит которых равен единице, например, русских букв, не гарантируется, использовать такие символы не следует.

Конец строк в протоколе SMTP обозначается последовательностью символов "возврат каретки" (шестнадцатеричный код 0 D) и "перевод строки" (шестнадцатеричный код 0А). Эта последовательность обозначается CRLF. Сервер начинает выполнение команды только получив от клиента строку, завершающуюся последовательностью CRLF.

Сервера SMTP должны принимать командные строки длинной до 512 символов. Это значение может быть увеличено по желанию разработчиков. Для серверов, поддерживающих расширения ESMTP, требующие дополнительных параметров, максимально допустимая длина командной строки увеличивается. Соответствующие требования приведены в RFC, описывающих эти расширения.

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

Рассмотрим команды SMTP, необходимые для отправки сообщения.

EHLO (Расширенное HELO)

Формат команды:

EHLO полное_доменное_имя_клиента CRLF

EHLO адрес_отправителя CRLF

Диалог клиента и сервера, как правило, начинается с приветствия. В RFC 821 в качестве приветствия предлагалась команда HELO. Однако с введением расширений ESMTP, эта команда была заменена на EHLO. Использование расширений ESMTP возможно только после выполнения команды EHLO.

Передача почты возможна только после выполнения одной из двух названых команд. Другие команды, не связанные с передачей почты (NOOP, HELP, EXPN, VRFY, RSET и QUIT), в принципе могут быть исполнены и без приветствия.

В качестве аргумента клиент передает серверу свое полное доменное имя, если таковое имеется. Если клиент не имеет доменного имени, например, если в качестве клиента выступает MUA, установленный на компьютере, получающем адрес динамически, то в качестве аргумента передается адрес электронной почты отправителя. Желательно, чтоб полученная от клиента информация была исчерпывающей для его идентификации.

Сервер проверяет соответствие указанного клиентом в приветствии доменного имени его адресу IP . Результат проверки добавляется к заголовку письма, но диалог продолжается независимо от достоверности полученного сервером идентификатора.

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

Если устаревшее программное обеспечение сервера не поддерживает команду EHLO, то выдается сообщение об ошибке. В этом случае клиент должен попытаться повторить приветствие, используя команду HELO. Естественно, расширениями ESMTP уже не удастся воспользоваться.

HELO (Приветствие)

Формат команды:

HЕLO полное_доменное_имя_клиента CRLF

HЕLO адрес_отправителя CRLF

Сегодня мы подробно расскажем про наиболее используемые в сети интернет протоколы – POP3, IMAP и SMTP. Каждый из указанных протоколов имеет определенное назначение и функциональные возможности. Давайте попробуем разобраться.

Протокол POP3 и его порты

Post Office Protocol 3 (POP3) это стандартный протокол почты созданные для получения электронных писем с удаленного сервера на e-mail клиент.POP3 позволяет вам сохранить почтовое сообщение на ваш компьютер и даже прочесть его, в случае, если вы находитесь не в сети. Важно отметить, что если вы решили использовать POP3 для подключения к учетной записи почты, письма, которые уже скачаны на компьютер, будут удалены с почтового сервера. Как пример, если вы используете несколько компьютеров для подключения к одному почтовому аккаунту, то протокол POP3 может быть не лучшим выбором в данной ситуации. С другой стороны, так как почта хранится локально, на ПК конкретного пользователя, это позволяет оптимизировать дисковое пространство на стороне почтового сервера.

По умолчанию, протокол POP3 использует следующие порты:

• Порт 110 – это порт протокола POP3 по умолчанию. Не является безопасным.
• Порт 995 – этот порт следует использовать в том случае, если вы хотите установить безопасное соединение.

Протокол IMAP и порты

Internet Message Access Protocol (IMAP) – это почтовый протокол, созданный для доступа к почте с локального почтового клиента. IMAP и POP3 – наиболее популярные в сети интернет протоколы, используемые для получения e-mail. Оба этих протокола поддерживается всеми современными почтовыми клиентами (MUA - Mail User Agent) и WEB – серверами.

В то время как POP3 позволяет доступ к почте только с одного приложения, IMAP позволяет доступ из множества клиентов. По этой причине, IMAP наиболее адаптивен в тех случаях, когда доступ к одному почтовому аккаунту необходим для нескольких пользователей.

По умолчанию, протокол IMAP использует следующие порты:

• Порт 143 – порт по умолчанию. Не безопасен.
• Порт 993 – порт для безопасного соединения.

Протокол SMTP и его порты

Simple Mail Transfer Protocol (SMTP) – это стандартный протокол для отправки почтовых сообщений по сети интернет.

Данный протокол описан в RFC 821 и RFC 822, впервые опубликованных в августе 1982 года. В рамках данных RFC, формат адреса должен быть в формате имя_пользователя@доменное_имя . Доставка почты, аналогична работе обычной почтовой службы: например, письмо на адрес [email protected], будет интерпретирован так: ivan_ivanov – адрес, а merionet.ru – почтовый индекс. Если доменное имя получателя отличается от доменного имени отправителя, то MSA (Mail Submission Agent) отправит письмо через Mail Transfer Agent (MTA). Главная идея MTA в том, чтобы перенаправлять письма в другую доменную зону, по аналогии, как традиционная почты отправляет письма в другой город или область. MTA так же получает почту от других MTA.

Протокол SMTP использует следующие порты.

Для обмена информации между компьютерами были разработаны стандарты передачи и обработки информации, которые назвали сетевыми протоколами. Наиболее распространены протоколы IP, ICMP, TCP, UDP, SMTP, POP/POP3, IMAP, HTTP/HTTPS и FTP, но существуют и другие, менее известные, такие как SSH, TELNET и другие.

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

IP, ICMP, TCP и UDP

IP (Internet Protocol – интернет протокол) и TCP (Transmission Control Protocol – протокол управления передачей) - это два совершенно различных протокола, которые обычно связывают друг с другом. Часто употребляются комбинации сразу нескольких протоколов, так как функции различных протоколов могут быть совмещены таким образом, чтобы получить решение поставленной задачи. В комбинации каждый протокол выполняет операции на своем уровне.

При передачи информации по интернету, её разбивают на мелкие части – интернет пакеты, которые передаются независимо друг от друга. Это существенно ускоряет передачу информации за счет того, что различные части могут передаваться по разным маршрутам, после чего вновь собираются на месте получения в единое целое. Это также мера предотвращения потери информации в процессе передачи. Протокол TCP отвечает за создание интернет пакетов и из обратную сборку в нужном порядке в месте получения, а также проверяет целостность информации. Если часть пакетов утеряна в процессе передачи, они передаются повторно.

Интернет протокол (IP) используется для доставки информации по нужному адресу. Каждый компьютер, который имеет подключение к интернету имеет свой уникальный адрес – . Каждый отправленный пакет содержит адрес доставки. Интернет пакет может пройти через много маршрутизаторов прежде, чем достигнет своего места назначения. Интернет протокол отвечает за маршрутизацию пакета к указанному компьютеру. IP не создает физических подключений между компьютерами. Он может быть использован совместно с другими протоколами, которые создают подключения.

Для передачи малых кусков информации можно использовать протокол UDP (User Datagram Protocol – протокол пользовательских дейтаграмм). Он также используется совместно с интернет протоколом, но намного проще чем TCP. В отличии от TCP, UDP не гарантирует доставку пакетов в нужной последовательности и не дублирует передачу утерянных пакетов, соответственно он потребляет меньше системных ресурсов, а скорость передачи существенно выше. Он применяется в приложениях которым, требуется большая пропускная способность линий связи, либо малое время доставки данных, например для аудио или видео связи.

Существует и совершенно иной протокол низкого уровня – ICMP (Internet Control Message Protocol – протокол межсетевых управляющих сообщений). В основном он используется в диагностических или сервисных целях, таких как передача сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают.

Почтовые протоколы – SMTP, POP, IMAP

Для передачи и получения электронной почты требуются свои собственные протоколы. Почту обычно отправляют по протоколу SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты). Его также используют для передачи почты между почтовыми серверами. При настройке почтовых клиентов (например, Outlook Express) требуется указывать адрес SMTP сервера. Для получения почты с сервера почтового ящика почтовые клиенты обычно используют протокол POP (Post Office Protocol – протокол почтового отделения). На текущий момент действует его третья редакция (версия), которая называется POP3 (Post Office Protocol Version 3 – протокол почтового отделения, версия 3). Для возможности получения почты при настройке в почтовом клиенте необходимо указать адрес POP3 сервера. Адреса SMTP и POP3 серверов могут совпадать, а могут и не совпадать, их следует уточнить у почтового провайдера. Протоколы SMTP и POP3 работают совместно с TCP протоколом для передачи и доставки почты через интернет.

Существует и более функциональный, но менее известный протокол для чтения электронной почты – IMAP (Internet Message Access Protocol – протокол доступа к электронной почте интернета). Данный протокол позволяет получить доступ к письмам хранящимся в почтовом ящике на сервере без необходимости загрузки её на локальный компьютер. Это очень удобно, когда требуется доступ к письмам почтового ящика с нескольких компьютеров. IMAP также работает совместно с протоколом TCP.

Протоколы HTTP и HTTPS

Веб страницы используют язык разметки гипертекста (HTML – HyperText Markup Language). HTML страницы передаются через интернет по стандарту, который называется протокол передачи гипертекста (HTTP – HyperText Transfer Protocol). Основой HTTP является технология «клиент-сервер», то есть пользователь инициирует соединение к серверу для запроса информации, а сервер ожидает соединения для получения запроса, обрабатывает запрос и возвращают обратно сообщение с результатом. HTTP работает совместно с протоколом TCP. Адреса использующие HTTP протокол начинаются с „http:”.

С протоколом HTTP связан протокол HTTPS (HTTP over TLS – HTTP по TLS). Он обеспечивает шифрование при передачи данных для защиты конфиденциальной информации. Адреса URL использующие HTTP протокол начинаются с „https:”.

Протокол передачи файлов – FTP

Протокол передачи файлов (FTP – File Transfer Protocol) предназначен для передачи файлов в компьютерных сетях с одного компьютера на другой. Он обеспечивает возможность простого управления файлами на удаленном компьютере. Это достаточно старый протокол, который был введен в эксплуатацию до всемирной паутины (WWW – World Wide Web). В настоящее время он используется в основном для загрузки файлов на веб сервера, однако существуют и файловые хранилища, работающие по протоколу FTP. Он работает совместно с протоколом TCP. Адреса URL использующие FTP протокол начинаются с „ftp:”.

Для одновременной работы серверов по протоколам SMTP , POP , IMAP , HTTP , HTTPS , FTP и др. вовсе не требуются отдельные компьютеры или ip-адреса. Все эти сервера можно установить на один компьютер с одним ip-адресом. Это достигается за счет то, что каждый из протоколов использует свой .

И другие агенты пересылки сообщений используют SMTP для отправки и получения почтовых сообщений, работающие на пользовательском уровне клиентские почтовые приложения обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо POP (англ. Post Office Protocol - протокол почтового отделения), либо IMAP (англ. Internet Message Access Protocol ), либо патентованные системы (такие как Microsoft Exchange и Lotus Notes /Domino) для доступа к учетной записи своего почтового ящика на сервере.

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• MAIL FROM - устанавливает обратный адрес (т. е. Return-Path, 53121.From, mfrom). Это адрес для возвращённых писем .

• RCPT TO - устанавливает получателя данного сообщения. Эта команда может быть дана несколько раз, по одному на каждого получателя. Эти адреса также являются частью оболочки.

• DATA - для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделенных пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо.

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

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

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

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

SMTP и извлечение сообщений

SMTP - всего лишь протокол доставки. Он не может по требованию взять сообщения с удаленного сервера. Для извлечения почты и управления почтовым ящиком разработаны другие протоколы, такие как POP и IMAP. Тем не менее, SMTP предоставляет возможность начать на удаленном сервере обработку очереди сообщений, при которой запрашивающая система может получать все направленные ей сообщения (см. Remote Message Queue Starting ниже). POP и IMAP предпочтительны, когда компьютер пользователя включен не постоянно, или же временно подключен к Интернету.

Remote Message Queue Starting

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

On-Demand Mail Relay

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

Интернационализация

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

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

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

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

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

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

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

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

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

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

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

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

Открытый релей

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

Порты

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

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

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

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

Пример простейшей SMTP-сессии

C: - клиент, S: - сервер

S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM: S:250 [email protected] sender accepted C:RCPT TO: S:250 [email protected] ok C:RCPT TO: S:550 [email protected] unknown user account C:DATA S:354 Enter mail, end with "." on a line by itself C:from: [email protected] //чтобы письмо C:to: [email protected] //не было добавлено C:subject: tema //в категорию спам C: // C:Hi! C:. S:250 769947 message accepted for delivery C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP closing connection S: (закрывает соединение)

В результате такой сессии письмо будет доставлено адресату [email protected], но не будет доставлено адресату [email protected], потому что такого адреса не существует.

Дополнительные расширения

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

S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP

smtp2.example.com объявляет,что он примет сообщение размером не больше чем 14,680,064 октетов (8-битных байтов). В зависимости от фактического использования сервера, он может на данный момент не принять сообщение такой величины. В простейшем случае, ESMTP-сервер объявит максимальный SIZE только при взаимодействии с пользователем через EHLO .

Безопасность SMTP и спам

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

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

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

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

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

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

Расширения ESMTP

RFC 1869 предписывает начинать сессию не командой HELO , а командой EHLO . В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.

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

Ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 EHLO

Стандарты RFC

• RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
• RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
• RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
• RFC 4954 SMTP Service Extension for Authentication (заменяет RFC 2554)
• RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
• RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
• RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
• RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
• RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
• RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
• RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
• RFC 3552 Guidelines for Writing RFC Text on Security Considerations
• RFC 3834 Recommendations for Automatic Responses to Electronic Mail
• RFC 4409 Message Submission for Mail (заменяет RFC 2476)
• RFC 5321 Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974 , RFC 1869 , RFC 2821)
• RFC 5336 SMTP Extension for Internationalized Email Addresses
• Перевод RFC 2505 - Рекомендации по предотвращению спама для SMTP MTA
• Перевод RFC 2554 - Расширение сервиса SMTP для аутентификации
• Перевод RFC 5321 - Простой протокол передачи электронной почты (SMTP)

Литература

• Hughes L Internet e-mail Protocols, Standards and Implementation. - Artech House Publishers, 1998. - ISBN 0-89006-939-5
• Hunt C sendmail Cookbook. - O"Reilly Media, 2003. - ISBN 0-596-00471-0
• Johnson K Internet Email Protocols: A Developer"s Guide. - Addison-Wesley Professional, 2000. - ISBN 0-201-43288-9
• Loshin P Essential Email Standards: RFCs and Protocols Made Practical. - John Wiley & Sons, 1999. - ISBN 0-471-34597-0
• Rhoton J Programmer"s Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. - Elsevier, 1999. -