Протокол smtp: Что такое SMTP-протокол и как он устроен?

Что такое SMTP-протокол и как он устроен?

SMTP (Simple Mail Transfer Protocol) — протокол передачи почты. Он был представлен еще в 1982 году, но не теряет актуальности до сих пор. В статье разбираемся, какие задачи решает протокол и как он работает.

Для чего используется SMTP

У протокола две главные задачи:

• Проверка корректности настроек системы и предоставление «разрешения» на отправку email-сообщения для определенного устройства.
• Отправка исходящего сообщения на заданный адрес электронной почты и подтверждение успешной доставки. Если сообщение доставить не удается, отправитель получает соответствующее извещение.

SMTP и его место в стеке TCP/IP

Теоретически SMTP умеет работать с практически любыми протоколами так называемого транспортного уровня, включая TCP, UDP и другие. Еще на заре развития протокола за ним закрепили два номера порта:

• Первый — это порт 25, посредством которого почта передается между почтовыми серверами.
• Второй — порт 587, благодаря которому почта передается от почтового клиента на сервер.

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

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

Электронное письмо и его формат

Сообщение электронной почты всегда состоит из трех элементов:

• Так называемый конверт.
• Заголовок.
• Тело письма.

Конверт применяется для передачи сообщений электронной почты от клиенту к серверу и обратно. При этом как клиент, так и сервер взаимодействуют друг с другом в обычном формате «запрос-ответ». В ходе взаимодействия между ними передаются текстовые строки.

Что касается заголовка и тела письма, то их параметры прописаны в отдельном документе — RFC2822.

Формат поля заголовка Received:

Received:
From host
by host
via physical-path
with protocol
id message-id
for final e-mail destination

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

Return-Path — поле возврата, которое используется для определения маршрута, по которому прошло сообщение. Если оно было отправлено прямо на сервер получателя, то в поле отображается один адрес. Если же серверов несколько, они будут отображаться списком.

Команды и ответы SMTP

Команды

Все они состоят из четырех символов. Сакрального замысла здесь нет, просто в самом начале разработчики договорились, что длина будет именно такой. Ниже — основные команды SMPT. Есть и другие, но они используются реже.

• Команда Helo применяется для установки соединения. Эта операция будет выполнена только в том случае, если клиент указал свой домен и собственный почтовый адрес.
• Команда Mail применяется для задания адреса отправителя.
• Команда RCPT используется исключительно для того, чтобы прописать адрес получателя. Электронное сообщение можно передать сразу нескольким получателям, для чего требуется использовать команду RCPT несколько раз подряд.
• Команда DATA нужна для уведомления принимающего сервера о завершении конверта, после чего идет само письмо.
• Команда QUIT применяется для разрыва соединения с сервером сразу после завершения приема сообщения.

Ответы SMTP

Здесь все одновременно и проще, и сложнее. Ответы в случае SMTP состоят из двух частей:

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

Коды сообщений начинаются на 2, 3, 5. Если сообщение начинается на 2, это значит, что предыдущая команда успешно завершена. «Тройка» в коде означает успешную отправку с необходимостью предоставить дополнительные данные.

Если сообщение начинается на 5, это означает технический сбой. Так, ошибка 502 — индикатор нереализованной команды, а 503 сообщает о неправильной последовательности команд.

Как работает SMTP — простыми словами

Давайте представим, что вы установили и настроили собственный SMTP-сервер. Далее вы планируете отправить письмо. Работает отправка по определенному алгоритму:

• Указывается адрес отправителя, после чего система пользователя соединяется, к примеру, с SMTP почтового клиента Gmail.
• Система передает серверу данные, включая email отправителя и получателя, тему письма, его содержимое.
• Сразу после этого система начинает поиск SMTP-сервера получателя электронного сообщения.
• Если этот сервер не найден или он не отвечает, SMTP-сервер пытается предпринять еще несколько попыток связи. Если ничего не получается, то система выдает ошибку отправки. При этом протокол сообщит, почему письмо не будет доставлено. Так, проблема может быть в несуществующем адресе или в блокировке сообщений.

Если все хорошо, то далее в работу вступают уже другие протоколы — POP и IMAP, но о них мы поговорим в другой статье.

Пример работы SMTP

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

Здесь мы видим подключение к почтовому серверу по 25 порту. Говоря техническим языком, подключение выполнено по адресу 220 smtp.example.ru ESMTP Postfix на 25 порт. Начало подключения — использование команды HELO, которая нужна для указания собственного домена. После этого вступает в работу сервер, который возвращает статус 250. Что это такое? Все просто: соединение установилось без проблем. После этого сервер еще раз пишет доменное имя в текстовом сообщении.

Теперь наступает очередь использования команды Mail FROM, которая нужна для отображения адреса отправителя сообщения. Если все хорошо, то сервер снова отвечает сообщением со статусом 250. Мы видим, что с текстовой частью все хорошо, команда выполнена, проблем не возникло.

Наступает следующий этап — использование команды RCPT TO для того, чтобы указать адрес получателя. Если сервер возвращает статус 250, то мы уже знаем, что это означает. Все удалось, теперь нужно выполнить команду DATA для ввода самого письма. В этом случае сервер отвечает уже не статусом 250, а другим — 354. После этого можно начинать вводить текст письма. Важный нюанс: заканчиваться все это должно отдельной строкой, которая содержит всего одну точку.

Сообщение всегда состоит из двух частей. Первая — заголовок, вторая — тело сообщения. Последнее необходимо отделять от заголовка пустой строкой. В этом случае требуется использовать заголовок FROM, это адрес пользователя, отправившего сообщение. Указывать нужно не только сам адрес, но и имя. А еще требуется заголовок, который дает получателю понять, в чем заключается основной посыл сообщения. Что касается пустой строки, то она отделяет заголовки от тела письма.

Возьмем самое простое сообщение, которое состоит из двух строчек текста: это «Hello, email world!» и «Hello, SMTP!». Заканчивается письмо строкой, которая содержит всего одну точку. Но эта строчка не будет видна получателю, она чисто техническая и будет обязательно убрана в ходе передачи. Если же точка нужна, то нужно указать сразу две точки, из которых одна будет удалена.

Наконец, если есть точка, то сервер видит, что письмо полностью завершено, выдавая статус сообщения 250 2.0.0 Ok: queued as 7FD9DC2E0060. Все это означает, что письмо уже находится в очереди ожидания. Для завершения сеанса нужно ввести всего одну команду — QUIT. Сервер ответит сообщением со статусом 221, что означает «пока».

Нужен ли собственный сервер SMTP?

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

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

Достоинство SMTP в том, что его достаточно просто внедрить, для этого протокола есть обширная документация и развитое комьюнити.

Немного о безопасности и спаме

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

Кроме того, у SMTP по дефолту не используется шифрование, так что любые письма, передаваемые разными компаниями, могут быть прочитаны — было бы желание и соответствующие инструменты. Но это относится к SMTP первой версии. В улучшенном варианте разработчики добавили шифрование. Для того, чтобы его задействовать, нужно использовать специальную команду STARTTLS.

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

Большинство почтовых серверов для безопасности настраиваются на работу лишь с локальными юзерами. То есть это те пользователи, у которых есть ящики с адресом из пула домена, который они и обслуживают. Здесь встречаются и новые термины. Так, серверы, которые работают в ином режиме, позволяя передавать почту абсолютно на все адреса, называются «открытые релеи». Они нужны обычным пользователям, но активнее всего их используют злоумышленники. Зачем? Чтобы рассылать спам, конечно же. Поэтому за режимом работы корпоративных серверов нужно следить. Если при проверке сети окажется, что сервер работает в режиме открытого релея, стоит поговорить с администратором сервера.

А еще можно проверить адрес отправителя посредством цифровой подписи, о чем мы уже упоминали выше.

Например, есть возможность проверки email отправителя, воспользовавшись цифровой подписью. С этой целью используется, например, взаимодействие с системой DNS. В ней хранится открытый ключ электронной подписи для конкретного домена. И этот ключ как раз можно использовать для проверки.

В сухом остатке

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

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

Для того чтобы все реализовать, лучше использовать специализированный сервис, владельцы которого развернули необходимые услуги. В этом случае разработчики требуются лишь для того, чтобы добавить сервис к CRM-системе.

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

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

SMTP: как работает, для чего нужен и подходит ли для массовых рассылок

Идеи

Выбираем софт для отправки писем

SMTP (Simple Mail Transfer Protocol) — сетевой протокол, предназначенный для передачи электронной почты. Он используется каждый раз, когда мы отправляем письмо через веб-сервисы (Gmail, Mail.ru), десктопные программы (Outlook, Thunderbird, TheBat) или сервисы рассылок (UniSender).

GMail, Mail.Ru, Yandex и других провайдеров электронной почты можно сравнить с почтовым отделением в вашем районе. Вы приходите туда, указываете на конверте, куда отправлять письмо и отдаёте его почтальону.

SMTP — это всё, что происходит в почтовом отделении, когда вы передали письмо. Например, на почте наклеят марки, проверят посылку на вес, организуют логистику и доставят письмо до адресата.

Тут возникает вопрос: если SMTP такой универсальный, почему нельзя отправлять письма напрямую через него? Можно, но есть несколько «но», о которых я расскажу дальше.

А пока немного теории.

Матчасть: как работает SMTP

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

220 mailserver at example.com greets you. Make love not war! — подключение удалось.

 

HELO test.com

250 example.com — поприветствовали друг друга с помощью команды HELO, сервер получателя ответил командой 250, что значит, что возможно дальнейшее «общение».

 

MAIL FROM: <[email protected]> — мы говорим, от кого хотим отправить письмо.

250 2.1.0 Ok — сервер отвечает, что готов принять письмо от этого адресата (бывают ситуации, когда адрес внесен в блэклист на стороне получателя, и тогда уже здесь начнутся ошибки.

 

RCPT TO: <[email protected]> — мы говорим, кому хотим отправить письмо.

250 2.1.5 Ok — сервер отвечает, что готов принять письмо для этого получателя (если адреса не существует, то здесь сервер может сказать что-то вроде 550 No such user here.

 

DATA — сообщаем серверу, что начинаем передавать письмо.

354 End data with <CR><LF>.<CR><LF> — сервер отвечает, в каком виде он хочет видеть конец письма.

 

FROM: [email protected] — начинаем передавать письмо вместе с техническими заголовками.

TO: [email protected]

SUBJECT: test mail from test subject

 

test body

 

. — показываем, что мы закончили передачу письма.

 

250 2.0.0 Ok: queued as 1CF5FC0AAE — сервер отвечает, что принял письмо для доставки и назначил ему id 1CF5FC0AAE (по нему, в случае недоставки, системный администратор принимающего сервера сможет найти, что стало с письмом.

QUIT — сообщаем, что сеанс связи закончен.

221 2.0.0 Bye — сервер прощается с нами.

Connection closed by foreign host. — соединение обрывается.

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

Кажется, что мешает подробно изучить документацию по SMTP и отправлять массовые рассылки через своё SMTP-решение? С этим есть проблема.

Предлагаю посмотреть на разные способы отправки массовых рассылок и оценить их по 3 параметрам: необходимость в доработках, доставляемость писем и цена.

Ящик на бесплатной почте (Mail.ru, Gmail)

Почта интернет-провайдера

Хостинг

Собственное SMTP-решение

Сервис транзакционных рассылок (например, UniOne)

Сервис рассылок (например, UniSender)

Ящик на бесплатной почте

Доработки от разработчиков: ⭐️

Доставляемость массовых рассылок: ⭐️

Цена: бесплатно

Почти все почтовые провайдеры (Gmail, Mail.ru) предоставляют доступ к ящику по SMTP. Тем не менее, отправлять массовые рассылки с бесплатной почты не получится.

Преимущества

Ящики на Gmail, Mail.ru или Яндексе бесплатные. На этом преимущества для отправки массовых писем заканчиваются.

Недостатки 

Пока вы отправляете небольшое количество писем, вас может устраивать бесплатная почта. Но если подписчиков много, вы столкнётесь с ограничениями по количеству писем:

Почтовый провайдер	Ограничение
Mail.ru	1 письмо в минуту
Yandex.ru	150 писем в сутки
Gmail.com	500 писем в сутки
Rambler.ru	200 писем в час
Ukr.net	250 писем в сутки
Meta.ua	200 писем в сутки

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

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

Вывод: не подходит для массовых рассылок.

Почта интернет-провайдера

Доработки от разработчиков: ⭐️

Доставляемость массовых рассылок: ⭐️

Цена: ⭐️

Многие интернет-провайдеры дают пользователям почту на своём домене. Например, у провайдера TENET почта будет иметь вид [email protected].

Этот способ похож на предыдущий: почта интернет-провайдера подходит для личной переписки, но не для массовых рассылок. Отправка писем идёт через IP-адреса провайдера — они не могут допустить, чтобы через них проходил спам. Поэтому на большинстве таких ящиков тоже стоит ограничение на количество писем в сутки.

Вывод: не подходит для массовых рассылок.

Хостинг

Доработки от разработчиков: ⭐️

Доставляемость массовых рассылок: ⭐️⭐️

Цена: ⭐️

Преимущества

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

Недостатки

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

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

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

Собственное SMTP-решение

Доработки от разработчиков: ⭐️⭐️⭐️

Доставляемость массовых рассылок: ⭐️⭐️⭐️ (при правильной настройке)

Цена: ⭐️⭐️

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

Преимущества

Простота. SMTP — простой протокол: его легко протестировать и внедрить (особенно, если у вас уже было SMTP-решение до этого). 

Вот, что говорит CTO UniSender Александр Брычук:

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

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

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

Подробный отчёт об ошибках. Используя SMTP, вы сразу получаете ответ о доставке или ошибке доставки сообщения. Многие сервисы не дают развернутый ответ о причинах недоставки. Если письмо не дошло, то чаще всего они просто выведут причину: несуществующий адрес, блокировка сообщения как спама. 

SMTP-сессия покажет, на каком именно этапе возникла ошибка доставки. Иногда это полезно.

Например, если ошибка возникла на этапе передачи данных MAIL FROM (смотрите пример SMTP-сессии), то ваш обратный адрес не нравится серверу получателя.

Недостатки

Грейлистинг. Протокол SMTP требует постоянного общения сервера отправителя и получателя. Недостаточно отправить один запрос на отправку письма. Сначала серверы должны «поздороваться», потом отправитель должен сообщить, от кого письмо, потом предоставить содержание письма. На каждый из этих этапов мы ждём ответ сервера получателя. Когда отправляется одно письмо, трудностей не возникает.

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

Необходимость глубокой доработки. Чтобы настроить полноценный email-маркетинг на своём SMTP-сервере, нужно много доработок. Например, чтобы следить за открытиями и переходами из писем, нужны специальные заголовки или трек-пиксели. И так с каждым инструментом — чтобы его сделать, нужно звать разработчиков.

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

Вывод: подходит для массовых рассылок, но нужна глубокая доработка со стороны разработчиков.

Сервис транзакционных рассылок

Доработки от разработчиков: ⭐️⭐️

Доставляемость массовых рассылок: ⭐️⭐️⭐️

Цена: ⭐️⭐️

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

Преимущества

Продолжим цитировать Александра Брычука, СТО UniSender:

Как только начинается история о том, что нужно что-то отдельно выделять и программировать, будет легче воспользоваться просто Web API. Он работает по HTTP-протоколу: вы можете обратиться к API точно так  же, как открываете сайты через браузер. Например, если вы пользователь UniSender, то обратиться к API можно, отправляя запросы на https://api.unisender.com/ru/api.

Ещё нюанс в том, что не везде удобно / разрешено использовать SMTP. Многие провайдеры и даже хостинг провайдеры запрещают это как раз для противодействия спаму. Web API — обычный HTTP, который в большинстве случаев разрешен.

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

Из главных преимуществ такого подхода:

• Дополнительный уровень защиты данных в виде API ключей. Вы общаетесь с сервисом через API-ключ, что снижает риск воровства логина и пароля. Мошенники не смогут отправить спам или провести фишинговую атаку от вашего имени. Это дополнительный «слой» защиты, которого нет при прямой работе с SMTP.
• В случае с Web API вам не нужно общаться с SMTP-сервером. За вас это делает сервис. Вы лишь даёте задание отправить письмо — один запрос.
• Использование Web API значительно упрощает отправку письма и автоматизацию этого процесса через ваше приложение.
• Готовые инструменты для получения статистики.
• Использование API через HTTP практически всегда возможно — файрволы обычно не блокируют HTTP-протокол в отличие от SMTP.

Недостатки

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

Также API намного больше подвержены изменениям. Если SMTP не меняется, API методы могут поменяться, что потребует изменения кода на вашей стороне.

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

Сервис рассылок

Доработки от разработчиков: ⭐️

Доставляемость массовых рассылок: ⭐️⭐️⭐️

Цена: ⭐️⭐️⭐️

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

Преимущества

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

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

Недостатки

Из недостатков сервиса рассылок можно выделить меньшую скорость работы по сравнению с сервисами транзакционных писем — сервис рассылок обрабатывает меньше писем за единицу времени.

Но если в вашей базе не сотни тысяч подписчиков, и вам не нужно доставлять письма в течение нескольких секунд после отправки (что необходимо для транзакционных писем), то вы не заметите разницы.

Данные о ваших подписчиках будут храниться на серверах сервиса рассылки. Если вы используете CRM-систему, её нужно будет интегрировать с базой контактов в сервисе рассылки. В UniSender для этого есть готовые решения.

Вывод: через сервис рассылок можно отправлять массовые рассылки без дополнительных доработок. Разработчиков зовут в редких случаях: например, если нужно настроить сложные сценарии автоматизации или привязать другой сервис по API.

Что в итоге

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

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

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

Другие материалы по теме

Поделиться

СВЕЖИЕ СТАТЬИ

Другие материалы из этой рубрики

Не пропускайте новые статьи

Подписывайтесь на соцсети

Делимся новостями и свежими статьями, рассказываем о новинках сервиса

Статьи почтой

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

Оставляя свой email, я принимаю Политику конфиденциальности

Наш юрист будет ругаться, если вы не примете 🙁

Как запустить email-маркетинг с нуля?

В бесплатном курсе «Rock-email» мы за 15 писем расскажем, как настроить email-маркетинг в компании. В конце каждого письма даем отбитые татуировки об email ⚡️

*Вместе с курсом вы будете получать рассылку блога Unisender

Оставляя свой email, я принимаю Политику конфиденциальности

Наш юрист будет ругаться, если вы не примете 🙁

SMTP — простой протокол передачи почты [АйТи бубен]

SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения. SMTP использует порт Порты TCP 25.

Протокол SMTP использует простые текстовые команды в формате ASCII и возвращает трехзначные кодированные ответы с текстовыми сообщениями. Протокол SMTP описывается документом Internet Request For Comment (RFC) номер 821, который был разработан группой Internet Engineering Task Force (IETF) и опубликован 21 августа 1982 года. С тех пор он претерпел несколько модификаций, но в целом основные команды протокола не изменились.

Читайте также: Тестирование отправки электронной почты

Основные команды клиента SMTP

Формат команд в SMTP прост: command [parameter], где command — четырехсимвольная команда протокола SMTP, а parameter — необязательный параметр, определяющий тип данных в команде.

• EHLO(устаревшая — HELO) Открывает приглашение от клиента

• MAIL — Определяет отправителя сообщения

• RCPT — Определяет получателей сообщения

• DATA — Определяет начало сообщения

• SEND — Посылает сообщение на терминал

• SOML — Send-or-Mail

• SAML — Send-and-Mail

• RSET — Сброс SMTP-соединения

• VRFY — Проверяет имя пользователя системы

• EXPN — Запрашивает список псевдонимов

• HELP — Запрашивает список команд

• NOOP — No operation — Ничего не делать

• QUIT — Остановить сеанс SMTP

• TURN — Реверс ролей в SMTP (клиент становится сервером)

• AUTH — Показывает серверу механизм аутентификации. RFC 4954 (заменил RFC 2554).

Команда HELO

По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:

HELO domain name

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

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

Команда AUTH

Расширение диалога SMTP командой AUTH описывается в RFC 4954.

Возможные механизмы аутентификации:

• PLAIN (Uses Base64 encoding.)

• LOGIN (Uses Base64 encoding.)

• GSSAPI (Generic Security Services Application Program Interface)

• DIGEST-MD5 (Digest access authentication)

• Алгоритм MD5

• CRAM-MD5

• NTLM

Разница между PLAIN и LOGIN только в том, что в первом варианте передается логин+пароль одной строкой, а во втором варианте — сначала логин, затем пароль. Но все они кодируются обязательно в Base64.

Команда MAIL

Команда MAIL используется для организации сеанса обмена электронной почтой с сервером после того, как была послана команда HELO. Она указывает, от кого исходит данное сообщение. Формат команды MAIL следующий:

MAIL reverse-path

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

MAIL FROM: [email protected]

Заметьте, что в поле FROM указывается адрес электронной почты отправителя сообщения, включая полное имя клиентского хост-компьютера. Эта информация должна присутствовать в поле FROM почтового сообщения (но об этом позже). Если почтовое сообщение проходило на пути от отправителя к получателю через несколько узлов, то каждый из них будет добавлять сведения о себе в поле <reverse-path>. Таким образом документируется путь прохождения сообщения через почтовые серверы. Довольно часто электронная почта от клиентов частных сетей должна проходить через несколько серверов электронной почты, прежде чем попасть в сеть Internet. Информация, которая содержится в поле reverse-path часто полезна при разрешении проблем в системах электронной почты или для обнаружения почтовых серверов, которые пытаются скрыть свою принадлежность, посылая сообщения через неизвестные серверы SMTP.

Команда RCPT

Команда RCPT определяет получателей сообщения. Одно и то же сообщение могут получать несколько пользователей. Обычно каждый получатель указывается отдельной строкой с командой RCPT. Формат команды RCPT следующий:

RCPT forward-path

Аргумент forward-path определяет, куда направляется электронная почта. Как правило, здесь указывается полный адрес электронной почты, но может также указываться и имя пользователя локального сервера SMTP. Рассмотрим для примера следующую команду:

RCPT TO: haley

С помощью этой команды указывается, что сообщение должно быть направлено пользователю haley на сервер SMTP, который обрабатывает сообщения. Таким же образом можно посылать сообщения и пользователям других компьютеров, которые не являются пользователями сервера SMTP, куда направлено сообщение. Рассмотрим, например, следующую команду:

RCPT TO: [email protected]

Команда, направленная серверу SMTP с именем shardrach.smallorg.org, вынуждает принять решение о доставке сообщения именно этот сервер. Так как пользователь не зарегистрирован на локальном сервере shardrach, то серверу придется определить, что делать с сообщением дальше. В этом случае возможны три варианта действий хоста shardrach. Давайте остановимся на них подробнее.

• Хост shardrach может переслать сообщение получателю и возвратить утвердительный ответ отправителю (OK). В этом случае он добавляет свое имя в поле <reverse-path> команды MAIL, чтобы включить его в маршрут прохождения сообщения при необходимости уведомить отправителя.

• Хост shardrach не может переслать сообщение и уведомляет об этом отправителя, подтверждая в то же время правильность адреса хоста meshach.smallorg.org. Таким образом, отправитель может попытаться повторно отправить сообщение прямо на meshach. smallorg.org.

• Хост shardrach не может переслать сообщение и посылает уведомление о том, что эту операцию невозможно осуществить с данным сервером. Тогда причины случившегося следует проанализировать системному администратору.

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

Команда DATA

Эта команда является основной в протоколе SMTP. После обработки команд MAIL и RCPT команда DATA используется для передачи информационной части сообщения. Формат команды DATA следующий:

DATA

Все, что следует за этой командой, интерпретируется как сообщение для передачи. Сервер SMTP, как правило, дополняет заголовок сообщения меткой времени и информацией об обратном маршруте return-path. Программа-клиент обозначает конец сообщения посредством передачи строки с одной точкой. Формат этой строки следующий:

<CR><LF>. <CR><LF>

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

Команда SEND

Команда SEND используется для передачи почтовых сообщений непосредственно на терминал зарегистрированного пользователя системы. Эта команда выполняется только в том случае, когда пользователь находится в системе, и обычно представляет собой всплывающее сообщение, подобно команде write в ОС UNIX. У этой команды имеется серьезный недостаток: с ее помощью внешний пользователь может легко определить, кто в данный момент находится в системе. Эта «возможность» давно и активно эксплуатируется хакерами для получения идентификаторов пользователя в сети Internet у ничего не подозревающих жертв, находящихся в системе. Из-за угрозы безопасности в настоящее время большинство программных пакетов для работы с SMTP уже не содержат эту команду.

Команда RSET

Команда RSET — сокращение от reset (англ. сброс — Прим. пер.). Если клиент запутался в ответах, получаемых от сервера, или решил, что соединение потеряно, он может послать команду RSET и вернуть сеанс к его начальной точке — выполнению команды HELO. При этом все ранее посланные команды — MAIL, RCPT и DATA будут аннулированы. Очень часто к этой команде прибегают в качестве «последнего средства», когда клиент либо потерял последовательность команд, либо получил неожиданный ответ от сервера.

VRFY

Команда VRFY является сокращением от verify (англ. проверить — Прим. пер.). Ее можно использовать для определения возможности доставки сервером почты определенному получателю перед выполнением команды RCPT. Формат этой команды следующий:

VRFY username

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

Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты. Как администратор почтовой системы вы, можете проверить работоспособность адресов электронной почты двумя путями. Во-первых, с помощью команды DNS host, которая позволяет определить правильность доменного имени и наличие почтового сервера, обслуживающего домен. И во-вторых, можно зайти с помощью telnet на порт 25 почтового сервера и затем задать команду VRFY, которая определит правильность имени пользователя. В листинге 5.3 показан пример использования команды VRFY для проверки имен пользователей. ]’. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you 8 VRFY rich 9 250 <rich@shadrach,smallorg.org> 10 VRFY [email protected] 11 252 <[email protected]> 12 VRFY jessica 13 550 jessica… User unknown 14 QUIT 15 221 shadrach.smallorg.org closing connection 16 Connection closed by -foreign host. 17 [riley@shadrach riley]$

В строках 8–13 представлены результаты выполнения команды VRFY. В строке 8 делается попытка выполнить VRFY для локального пользователя rich. Ответ SMTP- сервера в строке 9 подтверждает, что пользователь с таким именем имеется в системе, и клиенту возвращается его полный адрес электронной почты. В строке 10 показан еще один вариант задания команды VRFY. Здесь клиент пытается выполнить команду VRFY для пользователя на удаленном компьютере. Ответ, полученный в строке 11 от системы shadrach, отличается от результата, полученного в строке 9. В разделе «Ответы сервера» значения кодов, возвращаемых сервером, обсуждаются более детально. В нашем случае отметим, что система shadrach уведомляет клиента о том, что почта будет пересылаться пользователю prez на удаленном сервере meshach.smallorg.org. Строка 12 отображает попытку проверить несуществующее имя в системе meshach. Ответ SMTP-сервера в строке 13 в пояснениях не нуждается.

Команда NOOP

Команда NOOP — сокращение от no operation (англ. нет операции — Прим. пер.). Эта команда не оказывает никакого воздействия на SMTP-сервер, за исключением того, что сервер возвращает на нее позитивный код ответа. Она используется при тестировании соединения без пересылки сообщения.

Команда QUIT

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

Формат сообщений интернет EMail описывается в RFC2822, который заменил более старый RFC822.

Стандартные поля заголовка, согласно RFC 822

Документом RFC 822 предусматривается разбиение сообщения на две части. Первая часть называется заголовком. В нее вносятся все данные, идентифицирующие сообщение. Вторая часть называется телом сообщения. Заголовок состоит из полей данных, которые используются по мере необходимости внесения дополнительной информации в сообщение. Поля заголовка и тело сообщения должны разделяться пустой строкой. Для полей заголовка не существует определенного порядка следования, т.е. поля заголовка могут располагаться в произвольном порядке. Кроме того, в одном сообщении поля заголовка могут повторяться. На рисунке представлен общий вид почтового сообщения, соответствующего требованиям RFC 822.

Формат сообщения, согласно RFC 822

Формат поля заголовка Received: (Принято:) следующий:

Received:
from host name
by host name
via physical-path
with protocol
id message-id
for final e-mail destination

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

Формат этого поля заголовка следующий:

Return-Path: route

Последний SMTP-сервер в цепочке пересылки добавляет к сообщению поле возврата (Return-Path). Его цель — определение маршрута, посредством которого сообщение достигло получателя. Если сообщение было послано напрямую на сервер получателя, то в этом поле будет отображаться только один адрес. В противном случае здесь будет отображаться полный список серверов, через которые прошло сообщение, чтобы достичь адресата. Может отличаться от MAIL FROM (то есть обратный адрес может быть указан отличным от адреса отправителя).

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

Reply-To: address

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

Поле заголовка Resent идентифицирует почтовое сообщение, которое по какой-либо причине должно было повторно посылаться клиентом. Формат этого поля следующий:

Resent-Reply-To:
address

Данные поля заголовка идентифицируют отправителя электронного сообщения. Формат полей Authentic:

From: user-name
Sender: user-name

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

Поля Resent-authentic определяют отправителя сообщения, которое по какой-либо причине повторно передавалось программой-клиентом. Формат этих полей следующий:

Resent-From: date-time Resent-Sender: date-time Поля Resent-From: и Resent-Sender: работают подобно полям From: и Sender:. Они лишь отражают, что сообщение было повторно передано клиентом по неизвестной причине.

Поля заголовка Dates

Поля заголовка Dates используются для помещения метки времени в сообщение при передаче его от клиента серверу. Формат полей Dates следующий:

Date: date-time Resent-Date: date-time Поле Date: (Дата) будет пересылать информацию в заголовке сообщения в точном соответствии с оригиналом сообщения. Этот параметр может оказаться полезным при отслеживании времени получения ответов, в особенности — множественных ответов.

В полях заголовка Destination указываются адреса электронной почты получателей сообщения. Эти поля являются чисто информационными. Сервер SMTP в любом случае не будет посылать сообщение в почтовый ящик пользователя, пока на получит команду RCPT, выданную для данного пользователя (см. раздел «Основные команды клиента SMTP»). Формат этих полей следующий:

To: address
Resent-To: address
CC: address
Resent-CC: address
BCC: address
Resent-BCC: address

Поля To:, CC: и BCC: устанавливают стандартный алгоритм обработки электронной почты. Большинство пакетов для работы с электронной почтой используют именно эту терминологию для классификации получателей сообщения. Поле CC: сходно с памяткой, и указанные в нем получатели должны получить «копию» сообщения. Еще одно новое понятие, введенное системами электронной почты, — BCC: или «невидимая копия» (blind carbon copy). В поле «невидимой копии» также указывается получатель копии сообщения, но его адрес не виден посторонним (это не совсем этично). В связи с этой опцией обсуждалась вопросы компьютерной этики, но на сегодняшний день практически все программы для работы с электронной почтой поддерживают эту возможность.

Необязательными являются поля, которые более подробно идентифицируют сообщение для сервера SMTP, но, согласно RFC 822, могут и не присутствовать в сообщении. Тем не менее эти поля в настоящее время широко распространены, и многим из вас придется столкнуться с ними. Формат некоторых из них следующий:

Message-ID: message-id
Resent-Message-ID: message-id
In-Reply-To: message-id
References: message-id
Keywords: text - list
Subject: text
Comments: text
Encrypted: word

Наиболее полезным и часто используемым из этого набора является поле Subject: (Тема). Большинство программ для работы с электронной почтой допускает ввод отправителем темы сообщения в одну строку, которая описывает для получателя содержание сообщения. Эта строка текста довольно часто используется почтовой программой-клиентом при формировании списков полученных сообщений. Еще одно необязательное поле также помогает идентифицировать почтовое сообщение. Это поле Message-ID: (Идентификатор сообщения). В этом поле сообщению присваивается уникальный идентификационный номер, который может затем отображаться в возвращенном сообщении. Специальное поле шифрования Encrypted: указывает, было ли сообщение в целях безопасности подвергнуто шифрованию, а в Keywords: можно задать ключевые слова, которые можно использовать при поиске определенного текста, встречающегося в сообщении (сообщениях).

В алгоритме кодирования MIME учитывается тип двоичного файла, подвергающегося преобразованию, а также передается дополнительная информация о файле для декодера. Алгоритм MIME позволяет помещать двоичные данные напрямую в стандартное почтовое сообщение, согласно RFC 822. Для описания двоичных данных, вкладываемых в сообщение формата RFC 822, были созданы пять новых полей заголовка. Программы для работы с почтой, которые поддерживают стандарт MIME, должны правильно обрабатывать все эти новые типы заголовков.

Первое из дополнительных полей заголовка содержит версию MIME, которую использовал отправитель при кодировании сообщения. В настоящее время в этом поле всегда 1.0.

В поле заголовка Content-Transfer-Encoding указывается способ помещения двоичных данных в сообщение текстового формата ASCII. На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII.

• Поле Content-ID

Это поле заголовка используется для идентификации сеансов MIME по определенному идентификационному коду, когда содержимое имеет сложную структуру.

Поле заголовка Content-Description используется для текстового описания в формате ASCII данных, помещенных в почтовое сообщение. Это удобно при пересылке документов, созданных при помощи текстового процессора или графики, которые ничем не отличаются, будучи закодированными base64.

Поле заголовка Content-Type

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

Тип данных text идентифицирует данные в формате ASCII, которые должны читаться в исходном виде. Здесь существует также два подкласса — plain-текст, т.е. неформатированный ASCII-текст, и enriched-текст, который включает в себя элементы форматирования, схожие с обогащенным текстовым форматом. Новейшие программы для работы с электронной почтой могут работать даже с обогащенным текстовым форматом (RTF).

Тип данных message позволяет почтовой программе отсылать простые сообщения в формате RFC 822. Подклассы этого типа: rfc822, который указывает на то, что вложением является обычное сообщение, соответствующее RFC 822; partial, который позволяет разбивать длинные сообщения на несколько частей, и external-body, который позволяет помещать указатель на объект, не являющийся частью сообщения.

Тип данных image определяет вложение в сообщение двоичных данных, которые представляют собой графическое изображение. В настоящее время для этого типа определено два подкласса — jpeg и gif.

Тип данных video, соответственно, определяет, что вложенные в сообщение данные представляют собой видеоданные. В настоящее время для этого типа определен только один подкласс — формат mpeg.

Тип данных audio обозначает содержимое сообщения как аудиоданные (звуковые файлы). Здесь также пока определен только один подкласс basic, который соответствует одному каналу ISDN с частотой дискретизации 8 Кгц.

Тип данных application соответствует двоичным данным, вложенным в сообщение, которые являются приложением (например, электронные таблицы Microsoft Excel или документы, созданные с помощью текстового процессора Microsoft Word). На сегодняшний день определено два подкласса такого рода данных — postscript и octet-stream. Довольно часто подкласс octet-stream используется при вложении в сообщение прикладных данных, таких как документы Microsoft Word или электронные таблицы Microsoft Excel.

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

Подкласс mixed указывает на то, что каждая из частей сообщения является независимой и все они должны быть представлены получателю в том порядке, в каком они были вложены отправителем. Подкласс parallel указывает то, что каждая из частей сообщения является независимой и все они могут быть представлены получателю в любом порядке. Следующий подкласс alternative указывает, что все части сообщения представляют собой одни и те же данные, но представленные в различном виде. При этом получатель может выбрать наилучшее средство для просмотра полученных данных. ]’. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you 8 MAIL FROM:rich@localhost 9 250 rich@localhost… Sender ok 10 RCPT TO:rich 11 250 rich… Recipient ok 12 DATA 13 354 Enter mail, end with «.» on a line by itself 14 From:»Rich Blum» <rich@localhost> 15 To:»rich»<rich©localhost> 16 Subject:Formatted text message test 17 MIME-Version: 1.0 18 Content-Type: multipart/alternative; boundary=bounds1 19 20 –bounds1 21 Content-Type: text/plain; charset=us-ascii 22 23 This is the plain text part of the message that can 24 be read by simple e-mail readers. 25 26 –-bounds1 27 Context-Type: text/enriched 28 29 This is the <bold>rich text</bold> version of the <bigger>SAME</bigger> message. 30 31 –-bounds1— 32 . 33 250 MAA04305 Message accepted for delivery 34 QUIT 35 221 shadrach.smallorg.org closing connection 36 Connection closed by foreign host. 37 You have new mail in /var/spool/mail/rich 38 [rich@shadrach rich]$

Листинг 5.6. Пример сеанса SMTP с несколькими вложениями MIME (html, txt) Пример сообщения, представленный в листинге 5.6, является сообщением MIME, которое состоит из двух частей. В строке 18 показан тип данных сообщения. Тип multipart/alternative указывает на то, что в сообщении имеются различные типы данных, которые отделены граничным разделителем bounds1. Данные первого типа начинаются со строки 21 и представляют собой простой ASCII-текст, который может прочесть практически любая почтовая программа.

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

Так как тип MIME, указанный для сообщения, — multipart/alternative, то определение того, какую версию вложения отобразить, всецело зависит от почтовой программы.

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

В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался «Расширенные службы SMTP».

Расширенный SMTP (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды. В листинге 5.7 показан пример сеанса с использованием EHLO , а также дополнительных команд.

1 [katie@shadrach katie]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'. 
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 16:36:48 -050
6 EHLO localhost
7 250-shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you
8 250-EXPN
9 250-VERB
10 250-8BITMIME
11 250-SIZE
12 250-DSN
13 250-ONEX
14 250-ETRN
15 250-XUSR
16 250 HELP
17 HELP DSN
18 214-MAIL FROM: <sender> [ RET={ FULL || HDRS} ] [ ENVID=<envid> ]
19 214-RCPT TO: <recipient> [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
20 214- [ ORCPT=<recipient> ]
21 214- SMTP Delivery Status Notifications.
22 214-Descriptions:
23 214- RET Return either the full message or only headers.
24 214- ENVID Sender's "envelope identifier" for tracking.
25 214- NOTIFY When to send a DSN. Multiple options are OK, comma -
26 214- delimited. NEVER must appear by itself.
27 214- ORCPT Original recipient.
28 214 End of HELP info
29 HELP ETRN
30 214-ETRN [ <hostname> | @<domain> | #<queuename> ]
31 214- Run the queue for the specified <hostname>, or
32 214- all hosts within a given <domain>, or a specially-named
33 214- <queuename> (implementation-specific). 
34 214 End of HELP info
35 QUIT
36 221 shadrach.smallorg.org closing connection
37 Connection closed by foreign host.
38 [katie@shadrach katie]$

В строке 6 задана SMTP-команда EHLO для подключения к серверу SMTP. Строки 7–16 отображают ответ сервера. Заметьте, сервер сигнализирует о том, что для использования доступно больше команд, т.е. сеанс происходит в «расширенном» режиме. Одна из новых групп команд называется параметрами уведомления о доставке сообщения (Delivery Status Notification). Эти параметры могут использоваться с командами MAIL и RCPT для отображения состояния доставки определенного сообщения электронной почты. Однако для нас как администраторов почтовой системы наибольший интерес представляет команда ETRN.

Команда TURN уже упоминалась ранее. Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:

• ETRN name

Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.

Все, что вам нужно знать о SMTP (Simple Mail Transfer Protocol)

Мы постоянно отправляем друг другу электронные письма — каждый день отправляется и принимается колоссальное количество электронных писем — 306,4 миллиарда. Это один из самых распространенных способов связи как для компаний, так и для частных лиц, но вы когда-нибудь останавливались и задавались вопросом, что происходит после того, как вы нажимаете «отправить»? Как ваше сообщение идет от вас к вашим получателям?

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

Что такое SMTP? #

SMTP, что означает Simple Mail Transfer Protocol, представляет собой протокол электронной почты, используемый для отправки сообщений электронной почты с одной учетной записи электронной почты на другую через Интернет.

Протоколы электронной почты — это наборы правил, которые позволяют различным почтовым клиентам и учетным записям легко обмениваться информацией, и SMTP является одним из наиболее распространенных наряду с POP и IMAP. Это также единственный выделенный протокол для отправки электронных писем. Большинство почтовых клиентов, включая Outlook, Apple Mail, Gmail и Yahoo Mail, полагаются на SMTP для «проталкивания» или отправки сообщений от отправителя получателю.

Что такое SMTP-сервер? #

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

Вы можете думать о серверах как о своих реальных почтовых отделениях. Когда вы отправляете письмо из города А в город Б, оно сначала достигает местного почтового отделения в городе А; здесь он обрабатывается и отправляется в почтовое отделение в городе Б, которое отвечает за его доставку в конечный пункт назначения.

То же самое происходит с SMTP-серверами, хотя процесс занимает не несколько дней, а максимум несколько минут.

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

Как работает SMTP? #

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

После установки SMTP-сервера почтовые клиенты могут подключаться к нему и взаимодействовать с ним. Когда пользователь нажимает «отправить» в сообщении электронной почты, почтовый клиент открывает SMTP-соединение с сервером, чтобы он мог отправить его. (Соединение SMTP построено на так называемом соединении TCP, что означает протокол управления передачей.)

Оттуда клиент SMTP использует команды, чтобы сообщить серверу, что делать, и передать данные, такие как адрес электронной почты отправителя, адрес получателя. адрес электронной почты и содержание письма. Агент передачи почты или агент передачи сообщений (MTA) проверяет, принадлежат ли оба адреса электронной почты одному домену электронной почты, например gmail.com:

• Если они есть, он сразу отправляет электронное письмо
• Если нет, сервер использует систему доменных имен (DNS) для идентификации домена получателя, а затем отправляет его на нужный сервер.

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

Узнать больше →

Основные SMTP-команды #

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

• HELO или EHLO (Hello): Это важная команда для начала всего процесса отправки электронной почты. Почтовый клиент идентифицирует себя на SMTP-сервере. Это начало диалога, и обычно сервер отправляет команду HELO вместе со своим доменным именем/IP-адресом.

• ПОЧТА ОТ: После команды идентификации отправитель поделится кодом, указывающим, от кого отправлено письмо. Это обрисовывает в общих чертах адрес электронной почты и сообщает SMTP-серверу, что новая транзакция вот-вот начнется. Отсюда сервер сбрасывает все и готов принять адрес электронной почты. После принятия он ответит кодом ответа 250 OK.

• RCPT TO (получатель): Следующая команда следует за кодом ответа 250 OK, определяющим, кому отправляется электронное письмо. Опять же, SMTP-сервер отвечает тем же кодом, после чего можно отправить другую команду RCPT TO с другим адресом электронной почты получателя. Это может повторяться столько раз, сколько потребуется, в зависимости от того, сколько людей получит электронное письмо.

• ДАННЫЕ: Инициирует передачу данных между клиентом и сервером. Все содержимое сообщения будет перемещено на SMTP-сервер, который ответит кодом ответа 345. Содержимое сообщений передается на сервер, где одна точка отправляется в строке сама по себе, чтобы сигнализировать об окончании сообщения. Если он принят и готов к доставке, сервер отправляет еще один код 250 OK. В этот момент сообщение находится на пути к получателям.

• ВЫХОД: Когда электронное письмо отправлено, клиент отправляет на сервер команду ВЫХОД, разрывая соединение. Если он был успешно закрыт, сервер ответит кодом 221.

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

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

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

Понимание кодов ошибок SMTP #

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

Например, вот две группы часто возникающих ошибок SMTP:

• 4.X.X Постоянный переходный сбой: Эти коды ошибок начинаются с цифры «4», за которой следуют две другие цифры. Обычно они означают, что произошел временный сбой почтового сервера. Повторение команды может устранить ошибку, но эти коды часто используются серверами для защиты от ненадежных отправителей.
  

• 5.X.X Постоянная ошибка: Эти коды ошибок начинаются с цифры «5», за которой следуют две цифры. Обычно они означают, что соединение SMTP разорвано. Если вы попытаетесь отправить электронное письмо повторно, это, скорее всего, приведет к той же ошибке.

PS: если вам интересно узнать больше об ошибках SMTP, здесь, в Postmark, мы начали общедоступное Полевое руководство по SMTP, чтобы задокументировать коды ошибок, которые мы видим чаще всего. Проверьте это! Вы даже можете добавить свои собственные записи, если заметили ошибку SMTP, с которой мы раньше не сталкивались.

Чем SMTP отличается от других протоколов электронной почты? #

Вспомните определение SMTP, и вы вспомните, что мы говорили, что это один из многих протоколов электронной почты. POP и IMAP — два других наиболее распространенных протокола электронной почты.

Основное различие между этими протоколами заключается в том, что SMTP является единственным протоколом для отправки или «проталкивания» электронной почты с одного неизвестного почтового сервера на другой. POP и IMAP — это протоколы для получения или «вытягивания» почты для получателя с их собственного почтового сервера. Итак, POP и IMAP ограничивают передачу почты только проверенным почтовым серверам. Их нельзя использовать для связи за пределами вашей собственной сети.

Различные протоколы в процессе отправки: SMTP используется для отправки электронной почты, POP и IMAP для получения почты

Ниже мы более подробно объясним, как работают протоколы POP и IMAP и чем они отличаются от SMTP.

POP #

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

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

Чем отличаются протоколы POP и SMTP?

• SMTP — это протокол передачи сообщений, а POP — протокол доступа к сообщениям. Другими словами, SMTP используется для отправки почты от одного пользователя другому, а POP — для получения электронной почты.

• SMTP используется дважды: один раз при установлении соединения и отправке информации между отправителем и почтовым сервером и второй раз при отправке информации и соединении с получателем. POP используется только один раз между получателем и его почтовым сервером.

IMAP #

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

Если вы когда-либо устанавливали свой собственный почтовый клиент, вы, вероятно, сталкивались с IMAP в интерфейсе, подобном этому:

Чем отличаются IMAP и SMTP?

• SMTP — это протокол передачи сообщений, а IMAP — это протокол доступа к сообщениям (например, POP). Таким образом, в то время как SMTP отправляет сообщения и обрабатывает исходящую электронную почту, IMAP только извлекает сообщения и обрабатывает входящую электронную почту.

Запуск собственного SMTP-сервера или использование стороннего почтового сервиса: что лучше? #

Когда дело доходит до настройки и использования SMTP-сервера, есть два основных варианта:

• Запустить самостоятельно
• Воспользоваться сторонней службой

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

Запуск собственного SMTP-сервера: плюсы и минусы #

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

• Pro: Нет ограничений на объем отправки. Многие провайдеры услуг электронной почты и интернет-провайдеры (ISP) ограничивают ваши ежедневные электронные письма, как и некоторые веб-хостинги. Если у вас есть собственный выделенный SMTP, вы можете отправлять столько писем, сколько вам нужно, ежечасно или ежедневно.
• Pro: полностью контролировать доставку электронной почты. Независимо от того, что произойдет с вашей электронной почтой после того, как вы нажмете кнопку «Отправить», вы получите полезную информацию о доставке. Вы можете увидеть, были ли ваши сообщения отправлены получателю, и изучить коды ошибок.
• Pro: Ваш список адресов электронной почты является закрытым. Еще одним преимуществом использования собственного SMTP является то, что вам не нужно ни с кем делиться информацией из списка адресов электронной почты, что обеспечивает конфиденциальность данных вашей компании и ваших клиентов.
• Против: может потребоваться больше времени, денег и усилий. Для запуска SMTP-сервера требуется много ресурсов: вам нужно будет постоянно следить за тем, чтобы все работало и работало, и, возможно, даже потребуется нанять специального специалиста или команду — и это после того, как вы настроите сам сервер, который является совсем другая история. Для многих предприятий это просто слишком дорого.
• Против: это локально. Еще одним недостатком использования собственного SMTP-сервера является то, что он является локальным, поэтому он будет уязвим для отключения электроэнергии или проблем с подключением к Интернету в вашем регионе. Вы можете настроить серверы резервного копирования и отказоустойчивую защиту, но опять же, для этого требуются технические ноу-хау.
  
• Против: у вас могут возникнуть проблемы с доставкой и безопасностью . Если вы не отправляете сообщения определенным/ограниченным получателям, потребуется время, чтобы обеспечить правильную доставку, особенно когда объем вашей электронной почты меняется. Кроме того, вам придется защищать свой сервер электронной почты от несанкционированного доступа и спама, а это может стать настоящей проблемой. В этом большое преимущество использования стороннего сервиса: они уже разобрались со всем этим и имеют специальные процессы для определения необходимости корректировок.
  

Говоря об этом…

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

• Pro: Значительно меньше хлопот для вас. Использование стороннего поставщика услуг электронной почты позаботится обо всем за вас. Вам не нужно обладать значительными техническими знаниями или тратить время на обслуживание и мониторинг вашего почтового сервера, и вы часто можете обратиться в службу технической поддержки, чтобы помочь с любыми проблемами.
• Pro: более безопасный. Большинство сторонних провайдеров предлагают несколько вариантов резервного копирования, чтобы сохранить вашу электронную почту в безопасности, если один из серверов выйдет из строя. Они также поддерживают свою безопасность в соответствии с последними отраслевыми стандартами, обеспечивая постоянную безопасность ваших данных.
• Pro: экономичнее. Плата за услугу, которой вы будете пользоваться постоянно, означает, что вам никогда не придется иметь дело с почтовыми серверами самостоятельно. Это может сэкономить время и деньги вашего бизнеса, поскольку вам не нужно будет нанимать кого-либо для мониторинга и обслуживания вашего сервера или тратить деньги на устранение проблем с доставкой и безопасностью.
• Pro: Более надежная доставка. Сторонние службы имеют давние отношения с интернет-провайдерами и поставщиками почтовых ящиков, имеют опыт решения проблем и адаптации к уникальным требованиям различных получателей, имеют все процессы мониторинга и исключения из списка и, конечно же, имеют множество экспертов по доставляемости в штате, поэтому вам не нужно ни о чем беспокоиться.
• Против: Зависимость от других. Один из недостатков использования сторонней установки SMTP заключается в том, что вам придется полагаться на другую компанию, если у вас возникнут проблемы с вашим почтовым сервером. Поэтому, если вы пойдете по этому пути, убедитесь, что выбрали службу и команду с большим опытом в предметной области, и которые делают качественную поддержку клиентов своим приоритетом.

Совет для профессионалов: вы можете проверить репутацию своего провайдера на сайтах с обзорами, таких как G2, или просматривая разговоры в Twitter и других социальных сетях. Реальные отзывы от реальных пользователей продукта могут дать вам хорошее представление о том, чего ожидать.

Ой. Спасибо Вал. 💛

• Минусы: работа со сторонними условиями. Наконец, вам придется соблюдать условия обслуживания провайдера (TOS), которые могут включать ограничения на количество электронных писем, которые вы можете отправить. Тем не менее, редко можно найти TOS, который значительно сократит или повлияет на ваш объем отправки, будь то транзакционная электронная почта или рекламная электронная почта.

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

Выберите службу электронной почты, на которую вы можете положиться #

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

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

Лучшие провайдеры SMTP: параллельное сравнение #

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

Вы ищете параллельное сравнение лучших провайдеров SMTP? Вот разбивка.

Готовы начать отправку?

Зарегистрируйтесь в Postmark сегодня и получите бесплатную пробную версию.

Начать бесплатную пробную версию → Кредитная карта не требуется

Узнайте больше об отправке SMTP с помощью почтового штемпеля:

• Руководство пользователя почтового штемпеля: Отправка электронной почты с помощью SMTP
• Как отправлять сообщения из Outlook с помощью SMTP

Какой порт SMTP следует использовать? Общие сведения о портах 25, 465 и 587

Прежде чем отправиться в путешествие по истории, уточним некоторые основные определения.

SMTP расшифровывается как Simple Mail Transfer Protocol — проще говоря, это процесс, с помощью которого электронные письма отправляются через Интернет. Компьютерные порты — это то, как отдельные компьютеры подключаются к сети и выполняют электронные процессы. Порт SMTP представляет собой комбинацию обоих: порт, предназначенный для отправки электронной почты по сети и ее получателю.

Конечно, так же, как существует несколько компьютерных портов, можно использовать множество SMTP-портов. Давайте посмотрим на их развитие.

В 1982 году Университет Южной Калифорнии представил проект Инженерной группе Интернета (IETF). Был опубликован запрос комментариев (RFC) 821 , в котором порт 25 был установлен в качестве канала передачи по умолчанию для электронной почты в Интернете. 40 лет спустя мы все еще используем порт 25 в качестве основного средства передачи электронной почты между двумя почтовыми серверами. Несколько RFC устарели изначальный SMTP RFC. Однако основа для SMTP-соединений остается такой же или похожей.

В декабре 1998 г. Р. Гелленс и Дж. Кленсин представили документ RFC 2476 в поддержку добавления новой спецификации для электронной почты в Интернете. RFC предложил разделение традиционной концепции отправки сообщений и ретрансляции сообщений. В RFC определено, что отправка сообщений должна осуществляться через порт 587, чтобы новая политика и требования безопасности не мешали традиционному ретрансляционному трафику через порт ретрансляции сообщений 25. Платформа.

Интересно, что порт 465 никогда не публиковался IETF в качестве официального канала передачи или отправки SMTP. Вместо этого Управление по присвоению номеров в Интернете (IANA), которое поддерживает большую часть базовой интернет-инфраструктуры, зарегистрировало порт 465 для SMTPS. Цель состояла в том, чтобы установить порт для работы SMTP с использованием Secure Sockets Layer (SSL). SSL обычно используется для шифрования сообщений в Интернете.

Порт был назначен примерно на год, после чего он был отозван для поддержки защиты SMTP-соединений с использованием Transport Layer Security (TLS). Гвоздем в гроб стала новая протокольная команда STARTTLS, представленная в RFC 9.0273 2487 . Эта команда позволяет SMTP-серверам обмениваться данными через существующие порты, сообщая, поддерживает ли конечный сервер шифрование TLS. Если это так, отправляющий сервер может обновить соединение с помощью SMTP-команды «STARTTLS».

Mailgun поддерживает соединения TLS, что можно проверить, подключившись и выполнив «ehlo» из интерфейса командной строки. Результирующее значение «250 STARTTLS» подтверждает, что конечная точка принимает запросы на подключение TLS.

Вы можете проверить, используя одну и ту же последовательность команд на любом SMTP-сервере. Попробуйте Gmail или Yahoo, «telnet gmail-smtp-in.l.google.com 25» или «telnet mta7.am0.yahoodns.net 25».

Что насчет сегодняшнего дня? Чем отличаются эти стандартные порты? Есть ли устарели с течением времени?

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

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

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

Однако, поскольку IANA когда-то признала его действительным, могут существовать устаревшие системы, способные использовать только этот метод подключения. Как правило, вы будете использовать этот порт только в том случае, если это требуется вашему приложению. Быстрый поиск в Google, и вы найдете множество статей от поставщиков услуг входящих сообщений (ISP), в которых в качестве рекомендуемой настройки предлагается использовать порт 465. Однако мы не рекомендуем его, так как он не соответствует RFC.

Этот порт не одобрен ни IETF, ни IANA.  Вместо этого Mailgun предоставляет его в качестве альтернативного порта, отражающего порт 587, на случай, если вышеуказанные порты заблокированы. Поскольку 2525 — это нетрадиционный высокий номер порта, он обычно разрешен для интернет-провайдеров-потребителей и провайдеров облачного хостинга, таких как Google Compute Engine. Если вы пробовали указанные выше порты, но у вас возникли проблемы с подключением, попробуйте порт 2525. Этот порт также поддерживает шифрование TLS.

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

Порт 587 в сочетании с шифрованием TLS обеспечивает безопасную отправку электронной почты и соблюдение рекомендаций, установленных IETF.

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

POP (протокол почтового отделения, последней версией которого является POP3) и IMAP (протокол доступа к интернет-сообщениям) — два из самых первых протоколов, разработанных в потребительском Интернете, которые позволили почтовым клиентам, таким как Outlook, Thunderbird и другим, получать почту с почтового сервера.

Для POP обычно используются порты TCP 110 и 995, а для IMAP — порты TCP 143 и 993 для небезопасных и безопасных сеансов соответственно. Каждый из них умел делать разные вещи, например, отражать состояние электронной почты обратно на сервер (было ли оно прочитано, помечено или помечено как нежелательное) или сохранять копию сообщения на локальном компьютере для легкого доступа в автономном режиме. . Последняя версия POP, POP3, может использоваться как с SMTP, так и без него.

Это не влияет на то, какой порт вы можете использовать с Mailgun. Mailgun не размещает почтовые ящики, поэтому мы не поддерживаем эти протоколы.

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

Мы, конечно же, понимаем, что существует некоторая степень привязки к поставщику, связанная с созданием API. Однако SMTP чрезвычайно «болтливый» и может привести к менее эффективной отправке почты в Mailgun.

Например, рассмотрим типичный обмен почтой TLS между моим компьютером и конечной точкой SMTP Mailgun:

Как видите, вышеописанное общение довольно громоздкое, с большим количеством обменов между отправителем и получателем. Мы открываем соединение с SMTP-сервером, запускаем команду EHLO, аутентифицируемся, устанавливаем MAIL FROM, устанавливаем команду RCPT TO, DATA, отправляем данные, точку для закрытия и, наконец, получаем подтверждение того, что сообщение поставлено в очередь.

Сравните это с полезной нагрузкой HTTP:

Здесь мы инициируем соединение, передаем полезную нагрузку HTTP POST и получаем 200 OK от конечной точки API. Нам не нужно выдавать последовательность команд и ждать ответа от сервера после каждой команды.

Таким образом, если требуется производительность, Mailgun рекомендует использовать нашу конечную точку API . Количество «болтовни» туда и обратно намного меньше. А с нашими API SDK подключиться довольно просто. Если вы не заинтересованы в подключении через API, наши конечные точки SMTP готовы для вашей почты . Только не забывайте — , порт 587 — это место, где вечеринка находится на вершине безопасности SMTP!

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

Зарегистрироваться

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

Типы, компоненты и принцип работы

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

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

В этом руководстве рассматривается, что такое SMTP и как он работает в среде электронного маркетинга.

Содержание

• Что такое протокол?

• Что такое SMTP?

• Как работает SMTP?

  • Команда HELO/EHLO
  • ПОЧТОВАЯ команда
  • RCPT-команда
  • ДАННЫЕ

• Разница между SMTP, IMAP и POP3

• Какие компоненты SMTP?

  • Агент пользователя (UA)
  • Агент пересылки почты (MTA)

• Какие существуют типы SMTP?

  • 1. Сквозной SMTP
  • 2. SMTP с промежуточным хранением

• Как сообщения электронной почты отправляются с помощью SMTP?

  • 1. Состав
  • 2. Представление
  • 3. Доставка почтой
  • 4. Получение и обработка
  • 5. Доступ и извлечение

• SMTP для Gmail и Outlook

  • SMTP для Gmail
  • SMTP для Outlook

• Происхождение SMTP и популярных SMTP

• Заключение

Что такое протокол?

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

Международная организация по стандартизации создала Open Systems Interconnection (OSI). Один из таких широко используемых Интернет-протоколов устанавливает стандарт для связи в различных сетях. Модель делит процесс передачи данных на серию из семи уровней.

Важными интернет-протоколами являются TCP/IP, HTTPS, DNS и SMTP.

Что такое SMTP?

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

Как работает SMTP?

Протокол управления передачей (TCP) является основным соединением для связи между отправителем и получателем почты. В SMTP отправитель почты отправляет данные в командных строках по этому надежному упорядоченному каналу потока данных.

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

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

Команда HELO/EHLO

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

ПОЧТОВАЯ команда

Устанавливает адрес возврата/обратный адрес, определяя обратный или обратный пути.

RCPT-команда

Указывает получателя сообщения. Конверт отправителя содержит адреса получателей, которым команда RCPT может быть выдана несколько раз для каждого получателя.

ДАННЫЕ

Показывает, где начинается содержимое сообщения, а не его конверт. Пустая строка разделяет заголовок и тело сообщения в тексте сообщения.

ДАННЫЕ — это не одна команда, а группа команд, на которые сервер должен ответить дважды.

• Сначала сервер подтверждает сообщение и отвечает готовностью принять сообщение.

• Затем, после завершения последовательности конца данных, он либо принимает, либо отклоняет все сообщение.

Помимо ответа на команду DATA, сервер может ответить положительным образом (коды ответа 2xx) или отрицательным образом.

Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx).

Если сервер отправляет «отклонить», , то это постоянный сбой, и клиенту необходимо отправить сообщение о возврате на соответствующий сервер. С другой стороны, «дроп» — это положительный ответ, в котором сообщение отбрасывается, а не доставляется.

Связанное руководство: Все о жестком и мягком отскоке

Разница между SMTP, IMAP и POP3

Хотя эти три протокола используются для доставки электронной почты, они все же имеют несколько ключевых отличий.

SMTP — это протокол электронной почты, используемый почтовыми серверами для отправки электронной почты через Интернет. Он устанавливает правила обработки ошибок для других почтовых серверов. Почтовые гиганты, такие как Gmail и Outlook, используют протокол SMTP для ежедневной доставки миллиардов электронных писем. Недостатком этого протокола является отсутствие встроенного механизма аутентификации отправителя, что делает пользователей уязвимыми для спуфинговых атак. Вот почему вы должны настроить записи SPF, DKIM и DMARC, которые помогают почтовым серверам аутентифицировать ваши электронные письма.

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

Наконец, POP3 — это протокол электронной почты, который также используется для получения электронных писем. Но он отличается от IMAP своей способностью загружать электронные письма с почтовых серверов на ваш локальный компьютер. Единственный нюанс — письмо будет удалено с почтового сервера и останется доступным на скачанной локальной машине.

Связанное руководство: POP3 или IMAP: какой из них следует использовать

Каковы компоненты SMTP?

Существует два основных компонента SMTP-клиента и SMTP-сервера:

1. Пользователь-агент (UA)

2. Агент по пересылке почты (MTA)

Агент пользователя (UA)

Пользователь-агент (UA) отвечает за подготовку, создание и помещение сообщения в виде конверта для передачи.

Агент пересылки почты (MTA)

Агент пересылки почты (MTA) затем передает это сообщение получателю через Интернет.

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

Кроме того, эта система ретрансляции SMTP может использовать почтовые шлюзы и при необходимости работать без протоколов TCP/IP.

Какие существуют типы SMTP?

Различные типы SMTP:

1. Сквозной SMTP

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

2. SMTP с промежуточным хранением

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

После прямого обращения к хосту получателя SMTP-сервер хранит почту при себе до тех пор, пока SMTP получателя не получит копию сообщения электронной почты.

Процесс отправки писем через SMTP-порт состоит из следующих последовательных шагов:

1. Состав

С помощью программы Mail Transfer Agent (MUA) пользователь отправляет электронное письмо. Содержимое письма состоит из двух частей: заголовка и тела письма.

Заголовок — это тема сообщения, а тело — основное содержимое. Адрес отправителя и получателя также входит в часть заголовка. Заголовок действует как конверт с письмом (сообщением).

2. Представление

Почтовый клиент (почтовый пользовательский агент, MUA) отправляет электронное письмо на почтовый сервер (известный как агент отправки почты, MSA) с использованием SMTP через TCP-порт 587 или традиционный порт 25. MSA далее доставляет почту своему почтовому серверу агент, МТА.

3. Доставка почтой

Две части адреса электронной почты — это имя пользователя получателя и доменное имя.

Например, [email protected], «Mayank» — это имя пользователя, а «gmail.com» — это домен.

Если доменное имя адреса электронной почты получателя не совпадает с доменным именем отправителя, агент отправки почты (MSA) отправит письмо на (MTA). MTA будет искать конкретный домен для ретрансляции почты. Это происходит в два этапа:

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

Такая передача электронной почты с одного SMTP-сервера на другой называется ретрансляцией SMTP. А чтобы ваша электронная почта доставлялась бесперебойно и с высокой доставляемостью, вам могут понадобиться службы ретрансляции SMTP. В отличие от других почтовых клиентов, таких как Gmail и Outlook, службы ретрансляции SMTP гарантируют доставку ваших электронных писем, даже если они имеют большой объем.

Связанное руководство: Ретрансляция SMTP: что это такое и как это работает

4. Получение и обработка

После получения входящего сообщения сервер обмена доставляет его агенту доставки почты. Затем он сохраняет электронную почту и ожидает ее получения пользователем.

5. Доступ и извлечение

Пользователь может получить доступ к MUA с помощью логина и пароля. Кроме того, MUA помогает получить сохраненную электронную почту от MDA.

SMTP для Gmail и Outlook

Вот шаги для доступа к вашим электронным письмам Gmail и Outlook в любых почтовых клиентах, использующих SMTP.

SMTP для Gmail

Gmail упрощает доступ к электронной почте из других почтовых клиентов, таких как Microsoft Outlook и Apple Mail. Вот шаги, которые необходимо выполнить, чтобы получить доступ к электронной почте Gmail из любого почтового клиента.

1. В правом верхнем углу выберите «Настройки» > «Просмотреть все настройки».

2. Перейдите на вкладку Пересылка и POP/IMAP.

3. В разделе «Доступ к IMAP» выберите Включить IMAP.

4. Нажмите «Сохранить изменения».

5. Введите необходимую информацию в свой почтовый клиент в соответствии с таблицей ниже, чтобы получить доступ к электронной почте Gmail.

Свойство конфигурации	Значение
Сервер входящей почты (IMAP)	imap.gmail.com
Требуется SSL	Да
Порт	993
Сервер исходящей почты (SMTP)	smtp.gmail.com
Требуется SSL	Да
Требуется TLS	Да (при наличии)
Требуется аутентификация	Да
Порт для SSL	465
Порт для TLS/STARTTLS	587
Полное имя или отображаемое имя	Ваше имя
Имя учетной записи, имя пользователя или адрес электронной почты	Ваш полный адрес электронной почты
Пароль	Ваш пароль Gmail

SMTP для Outlook

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

1. Выберите «Настройки» > «Просмотреть все настройки Outlook» > «Почта» > «Синхронизировать электронную почту».

2. В разделе POP и IMAP выберите Да в разделе Разрешить устройствам и приложениям использовать POP.

3. Нажмите Сохранить.

4. Введите необходимую информацию в свой почтовый клиент в соответствии с таблицей ниже, чтобы получить доступ к электронной почте Gmail.

Свойство конфигурации	Значение
Имя сервера IMAP	Outlook.office365.com
Порт IMAP	993
Метод шифрования IMAP	TLS
Имя POP-сервера	Outlook.office365.com
POP-порт	995
Метод шифрования POP	TLS
Имя SMTP-сервера	smtp-mail.outlook.com
SMTP-порт	587
Метод шифрования SMTP	СТАРТЛС

Происхождение SMTP и популярных SMTP

В 1982 году был выпущен Sendmail с 4. 1cBSD, один из первых MTA, реализующих Simple Mail Transfer Protocol. Со временем он стал широко используемым агентом передачи почты.

Некоторые другие программы SMTP-сервера, которые стали популярными, включают:

1. Постфикс

2. Qmail

3. Novell GroupWise

4. Эксим

5. Novell NetMail

6. Сервер Microsoft Exchange

7. Сервер обмена сообщениями Oracle Communications

В 1998 и 1999 годах появились новые тенденции в доставке электронной почты и введение отправки сообщений (RFC 2476) и SMTP-AUTH (RFC 2554) соответственно.

Некоторые из самых популярных SMTP-серверов включают Amazon SES, Sendgrid, Mailgun и т. д.

Заключение

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