На деревню логистам (а также дедушкам и всем остальным).

Полезный лайфхак по организации рассылок по электронной почте

После некоторого перерыва – продолжение нашей условной рубрики «Хозяйкам на заметку». Ранее мы рассказывали о нюансах работы с грузами на путях необщего пользования. А в этой статье поговорим – внезапно – об организации рассылок по электронной почте. Разумеется, прямого отношения эта тема к транспортной логистике не имеет, хотя термин «транспорт» еще встретится. Зато она непосредственно связана как с взаимодействием внутри логистического отрасли, так с конечными грузовладельцами.

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

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

Один раз – не..спамер

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

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

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

Но совсем иначе ситуация выглядит на транспортном уровне, на уровне «физической» доступности того или иного почтового ящика. Здесь вступает в силу объективная машинная логика: если по каким-либо причинам отправляемые письма просто не могут дойти куда следует, то их отправитель выглядит, скажем так, несколько подозрительно. А если таких писем много, и рассылаются они с завидной регулярностью и упорством, то очевидно, что их отправляет либо бездушный робот либо тот, кто и так все заранее просчитал. И не будет сильно удивлен, если однажды окажется в черном списке у почтовых провайдеров. Именно по этой причине надежность адресов (или доступность почтовых ящиков) является ключевым условием эффективных почтовых рассылок.

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

Собственно, проверка как таковая состоит из двух этапов: проверки домена и проверки сервера.

Проверяем домен

В дальнейшем мы будем исходить из того, что большинство наших читателей пользуются Windows. Для почитателей Linux и MacOs инструменты будут иными, и о них здесь упоминаться не будет.

Проверка домена (или хоста), как правило, необходима в том случае, если интересующий адрес имеет корпоративный домен, то есть, после всем известной «собаки» @ (которая официально называется «коммерческое at») идет некоторое фирменное наименование: как вариант, адрес сайта и т.д.

Цель этого этапа – в определении того, какой именно почтовый сервер (наименование, реже IP адрес) обслуживает конкретный домен. Кстати, если выяснится, что никакой, то ко второму этапу переходить не надо.

Основной инструмент здесь – небольшая программа (утилита), которая уже имеется в операционной системе Windows - nslookup. Эта утилита в некотором смысле имитирует работу браузера: она отправляет запрос DNS-серверу, на котором и содержится информация о домене. Это не только IP-адрес, но еще и имя (или IP-адрес) обслуживающего этот домен почтового сервера. И в качестве ответа этот DNS-сервер сообщает запрошенную информацию.

Nslookup доступна прямо из командной строки (она же консоль):

1.Запустить командую строку можно, нажав Win (кнопка с плитками слева от Пробела) + R (это запускает диспетчер задач), а затем вписать в строке: cmd

2. В командной строке набрать nslookup пробел -type=mx пробел <вписать доменное имя сайта без www: site.com>

В результате – и в оптимальном случае - ниже запроса появится сообщение, где после mail exchanger и знака «равно» появится имя почтового сервера. Очень часто это всем известные российские почтовые сервисы типа Яндекса или Мэйл.ру. А иногда – имя какого-нибудь доморощенного (собственного) почтового сервера.

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

Или даже просто IP-адрес, проще говоря, комбинация цифр. На худой конец, информация о том, что хост не найден.

Дабы не усложнять себе задачу, имеет смысл далее проверять адреса, ответ от которых содержит запись mail exchanger=<наименование почтового сервера>, как на первом рисунке.

Общаемся с сервером

Смысл этого этапа – отправить почтовому серверу некое проверочное сообщение, дабы окончательно убедиться в доступности ящика получателя. Несколько парадоксально, мы намереваемся отправить по сути электронное письмо, но без использования обычной почтовой программы (которую часто называют «почтовым клиентом»). И помогут в этом нелегком деле особенности протокола SMPT.

Минутка технологий. Протокол SMPT (Simple Mail Transfer Protocol) – это система правил, по которым обмениваются сообщениями две стороны: отправитель и получатель. Причем совершенно неважно, при помощи каких программ (или приложений) осуществляется этот обмен. Главное, чтобы эти программы «понимали» команды протокола и умели отправлять их адресату.

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

Здесь нужно выбрать тип соединения Telnet и указать порт 25 – именно он используется для доставки электронной почты. А затем в строке ввести имя того самого почтового сервера, которое мы узнали на первом этапе - в данном примере уже знакомый сервер Яндекса.

Если все хорошо, то появится диалоговое окно со следующим сообщением, которое обязательно будет содержать код 220 и, возможно, что-то еще:

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

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

Это либо команда helo, либо команда EHLO, после чего – через пробел – следует ввести домен, с которого вы отправите тестовое письмо: в нашем случае, это conttrans.com, но может быть и yandex.ru, и gmail.com.

По нашему опыту можем сказать, что одни серверы отвечают на helo, другие – на EHLO. Если приветствие неправильно оформлено, то ответ будет содержать код 500 - как в нашем случае. Как говорится, никаких проблем, просто попробуйте оставшийся вариант. Если все правильно, то ответ в любом случае будет содержать код 250. На скриншоте как раз и представлен весь процесс.

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

Приведем сначала «диалог» с использованием команд в строчных буквах.

mail пробел from:<вставить имя почтового ящика, с которого будет отправляться тестовое сообщение: user@domain.com>

В ответ сервер пришлет сообщение, которое обязательно содержит код 250 2.1.0 и, например, ok.

rcpt пробел to:<вставить имя почтового ящика получателя>

В ответ сервер пришлет сообщение с кодом 250 2.1.5

Data

В ответ сервер присылает приглашение на отправку собственно сообщения (имитации электронного письма). Теоретически оно может быть любым, но обычно достаточно слова test.

Сначала тема (заголовок)

Subject: <test>

Пустая строка

Текст сообщения, например, test

знак точки на новой строке и завершение ввода – нажатие Enter.

Диалог в заглавных буквах ниже, при этом ответы серверов те же самые

MAIL пробел FROM: адрес отправителя между <…> (это не технические символы, а элементы синтаксиса)

RCPT пробел TO:адрес получателя между <..>

DATA

Subject:что-то

Пустая строка

Что-то

Знак точки на новой строке и ввод нажатием Enter

Далее – теоретически-сервер должен принять письмо и прислать код 250 2.0.0. Однако на практике многие серверы (в том числе и Мэйл.ру, и Яндекс) присылают сообщение о том, что наше тестовое письмо отвергнуто как спам. Это не означает, что реальное письмо будет также проигнорировано. Дело в том, что спам-фильтры настраиваются на уровне приложений (конкретных) программ, а не транспортного протокола SMTP. Поэтому сам факт получения ответа на команды MAIL (mail), RCPT(rcpt), DATA свидетельствуют о том, что по крайней мере на транспортном уровне ящик получателя доступен.

Удачных всем рассылок!