ePochta SMTP

Теория различных аспектов по организации массовых рассылок

И так, начнем с теории.  Для того чтобы легче было усваивать информацию, построим логическую цепочку отправки электронного письма на примере общепринятого в мире протокола SMTP.

1. Существует тот кто отправляет письмо (отправитель) и тот кто получает письмо (получатель).
2. Для отправки и получения почты у отправителя и получателя на компьютере установлены специальное программное обеспечение под названием почтовый клиент.
3. Когда отправитель набрал сообщение и нажал отправить, то почтовый клиент связывается с почтовым сервером, используя специальный протокол SMTP.
4. Далее почтовый сервер отправителя взаимодействует с почтовым сервером получателя, тем самым происходит передача данных на почтовый ящик получателя.
5. На финальной стадии с помощью специального протокола POP3 или IMAP, сообщение доставляется от почтового сервера получателя к его почтовому клиенту и в результате получатель видит на экране ваше сообщение.

Вкратце весь процесс показан на схемке ниже:

Теперь залезем во «внутренности» передаваемых нами данных. Структура письма включает в себя некоторую информацию:

• поле «HELO» — имя отправляющего узла или имя сервера;
• поле «MAIL FROM» — адрес с которого осуществляется отправка письма;
• поле «RCPT TO» — куда отсылается письмо.

Стоит заметить, что качественная рассылка начинается с этих банальных мелочей.  Что бы не попасть в DNSBL (черные списки, в которых оказываются те, кто рассылает спам) возьмите на вооружение  несколько советов:

• HELO даёт всему начало! SMTP-клиент передаёт значение поля HELO, указывая имя своего компьютера в качестве аргумента. Другими словами, он сообщает: «Привет, я — 192.168.0.3.». Если попытать произвести массовую рассылку не указав явно данное поле, то вероятность попадания в DNSBL увеличивается.
• «MAIL FROM» как было сказано, несет адрес отправителя. Следите за тем что бы он был реальным и существовал. Например «pypkinmyplin@yandex.ru» может оказаться несуществующим и тогда при первичной проверки на спам вероятность попадания в DNSBL возрастает.

При настройке почтового сервера (не важно это Exim, Postfix, Sendmail  и тп) важно грамотно прописать некоторые его параметры, а именно:

PTR запись. В ней в обратном порядке записывается IP адрес хоста, с которого рассылается почта. По этой записи почтовики распознают имя хоста по его IP. Например, если  IP вашего почтового сервера 111.45.47.96. Открываем наш NS сервер (или, что чаще настройки провайдера сервера или хостера) и добавляем следующую DNS запись (IP при этом «разворачиваем»):

• DKIM (DomainKeys Identified Mail) — своеобразный метод email аутентификации. Данная технология повышает качество классификации и идентификации электронной почты, используя методы антиспама и антифишинга. Метод DKIM добавляет на стороне получателя специальную электронную цифровую подпись, которая непосредственно связана с доменом организации от которой было выслано письмо. В результате определяется репутация отправителя и попадание его в доверенную зону, либо в  DNSBL. Все нюансы генерирования ключей можете прочитать в соответствующей литературе, наш же обзор носит другой характер.
• Грейлистинг. Зачастую при отправке письма возникает ситуация перегруженности почтовых серверов. В этом случае они «ответят» ошибкой на данный запрос и «попросят» попробовать позже. В подобной ситуации разработчик должен позаботиться о том, чтобы письмо обязательно было доставлено получателю, если не с первого раза, то как минимум со второго (напротив, отправитель предпримет попытки доставить письмо позже, поставив его в свою очередь на отправку).  Эта технология называется Greylisting. Использовать её в современных реалиях просто необходимо.

Команда SEND

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

Правильная DNS

При получении сообщения удаленный SMTP-сервер анализирует прежде всего его заголовок. Почтовая программа отправляет только From, To, Date, Subject и X-Mailer. Они в общем понятны и просто указывают, от кого и куда слать. Остальной заголовок формируется как SMTP-сервером, так и приложением, его отправляющим. Это, кстати, тоже нужно учитывать, потому что письма, отправляемые через Telnet, могут уходить, а с Roundcube — нет, просто потому, что у них разный заголовок. Roundcube, например, подставляет свой HELO/EHLO на основании переменной server_name или localhost, если она не определена. Поэтому иногда нужно просто задать его явно:

То же касается и самописных PHP-скриптов.

При передаче письмо будет проходить минимум через два SMTP-сервера, каждый из которых тоже добавляет что-то от себя в заголовок. В первую очередь каждый сервер добавляет свой Received: from. Читать их лучше снизу вверх. Самое нижнее сообщение — это сервер отправителя, самый верхний — сервер получателя. Хотя на самом деле серверов может быть больше, особенно это актуально при работе с крупными провайдерами услуг, которые, приняв письмо, перебрасывают его дальше, или при использовании на пути SMTP-прокси. Для анализа пути сообщения можно использовать сервис от , который покажет в понятной форме все SMTP-серверы, время прохождения и тесты SPF, DKIM и DMARC (о них дальше).

Путь письма

Заголовки Received отличаются, хотя есть общие правила. Типичный выглядит так:

Здесь сообщение было получено с сервера, который называется server.example.org, имеет IP 1.2.3.4, в приветствии helo было использовано это же имя, получил его Exim 4.80.1 сервера st15.provider.com. Сообщение отправлено с mail@example.org. Приняв такой заголовок, SMTP-сервер начинает проверять данные. Пробивает домен и IP по базам DNSBL. Проверяет наличие MX-записи у домена. MX изначально используется для поиска почтовых серверов, обслуживающих данный домен, ее наличие подтверждает, что домен отправляет почту.

Дальше он производит обратное разрешение имени по IP через обратный DNS-запрос c помощью PTR-записи. То есть он узнает, сервер с каким именем должен быть по адресу, с которого пришло сообщение. Такое поведение было заложено в RFC 2505 от февраля 1999 года Anti-Spam Recommendations for SMTP MTAs. И хотя давно признано, что обратные зоны не являются достаточным условием для однозначного опознавания отправителя и часто приводят к ошибкам и задержкам, они все же поддерживаются. Поэтому они должны совпасть, иначе сообщение как минимум получит минус в рейтинге, а в худшем случае будет отброшено.

В нашем примере за IP 1.2.3.4 должен быть закреплен server.example.org. DNS-запись выглядит так:

Для IPv6 используется ip6.arpa. В принципе, знать об особенностях PTR необязательно, так как PTR, за редким исключением, настраивает только хостинг-провайдер. И если оно не устраивает, то нужно просто обратиться в поддержку. Проверить PTR можно при помощи запроса:

По факту PTR-запись после развертывания VDS может указывать на технический домен, представленный провайдером, вроде , в шаблоне VDS hostname вписан как Ubuntu1604 (меняется в ), в HELO/EHLO SMTP-сервер пишет вообще , а письмо идет от домена example.org. Вероятность доставки письма при таких условиях будет стремительно приближаться к нулю. Хотя некоторые сервисы отмечают подобные несоответствия как ошибку и проводят полную проверку.

Особо хочется обратить внимание, что VDS обычно имеет два IPv4 и v6. Поэтому все сказанное касается обеих версий, так как письмо к одному серверу может идти по IPv4 и доставляться, а другой предпочитает использовать IPv6, и письмо может не доходить до получателя

При этом очень много провайдеров, предоставляя IPv6, абсолютно не утруждают себя настройкой PTR-записи, и ее проверка возвращает ошибку. Но Google, например, предпочитает IPv6 и сразу отбрасывает письмо, если PTR не совпадает с именем сервера. В ответном сообщении сервиса это выглядит так:

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Актуализируйте адресную базу

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

• Удалите невалидные, неактивные адреса и спам-ловушки — это повысит уровень открытия рассылки. Почтовые сервисы и специализированные сервисы по борьбе со спамом используют адреса-ловушки, чтобы вычислить спамеров и заблокировать домены и IP-адреса отправителей рассылок.
• Сегментируйте адресную базу по принципу активности. Разбейте ее на группы клиентов, которые не открывали ваши письма в течение одного, двух, трех и более месяцев.
• Попросите клиентов самостоятельно выбрать приемлемую частоту рассылок, чтобы не слать слишком часто или слишком редко и тем самым не ухудшить уровень открытий.

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

VRFY

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

VRFY username

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

Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты. Как администратор почтовой системы вы, можете проверить работоспособность адресов электронной почты двумя путями. Во-первых, с помощью команды DNS host, которая позволяет определить правильность доменного имени и наличие почтового сервера, обслуживающего домен. И во-вторых, можно зайти с помощью telnet на порт 25 почтового сервера и затем задать команду VRFY, которая определит правильность имени пользователя. В листинге 5.3 показан пример использования команды VRFY для проверки имен пользователей.

1 riley@shadrach riley$ 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.38.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 prez@mechach.smallorg.org
11 252 <prez@mechach.smallorg.org>
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 в пояснениях не нуждается.

Проверить существования пользователя используя bash и curl.$ echo -e «VRFY username@example.com\n QUIT» | curl telnet://mail.example.com:25
220 mail.1-talk.com ESMTP Postfix
252 2.0.0 username@example.com
221 2.0.0 Bye

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

Синие стрелки могут быть реализованы с использованием различных версий SMTP.

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

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

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

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

Telnet и HTTP: получение HEAD

Telnet и получение HEAD HTTP запрос запроса протокола Методы и структура протокола HTTP.

Проверка Кода Состояния HTTP с помощью Telnet.

$ telnet СЕРВЕР ПОРТ
Trying xxx.xxx.xxx.xxx...
Connected to СЕРВЕР.
Escape character is '^]'.
HEAD ВЕБ-СТРАНИЦА HTTP1.1
HOST: СЕРВЕР
<Нажмите ENTER>

Например:

telnet> open websl.biz 80
Trying 65.52.137.176...
Connected to websl.biz.
Escape character is '^]'.
HEAD  HTTP1.1
HOST: websl.biz
 
HTTP1.1 200 OK
Cache-Control: private
Content-Length: 5825
Content-Type: texthtml; charset=utf-8
Server: Microsoft-IIS7.5
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 28 Jan 2013 21:25:15 GMT

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

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

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

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

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

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

Fixing mail server HELO configuration problems

If you are running Linux, and/or you’re using certain Perl SMTP modules,
and/or using fetchmail,
there is a good probability that this is a simple
configuration problem — the HELO is often «localhost» or «localhost.domain»
or «smtp». In these cases, please pay special attention to the remaining
paragraphs in order to prevent the IP listing again:

With Linux, the problem often appears to be due to the odd way
that sendmail determines its own name and an interaction with how
the /etc/hosts file is created by the system install procedures.
The most straightforward way to fix this is to set the Dw or Dj
macros in sendmail.cf (or sendmail.m4).
Read this for detailed instructions
on how to do this.

It is also reported that removing
the «localhost.localdomain» string from the «127.0.0.1» line in /etc/hosts
will fix this too, but this is untested.

With Net::SMTP or any module using it, you’ll want to insert a «hello»
setting in the new().

my %conf = (
    ## General
    "programName"          => $0,              ## The name of this program
    "version"              => '1.54',          ## The version of this program
    "authorName"           => 'Brandon Zehm',  ## Author's Name
    "authorEmail"          => '', ## Author's Email Address
    "timezone"             => '+0000 (GMT)',   ## We always use +0000 for the time zone
    "hostname"             => 'localhost',     ## Used in printmsg() for all output, and in SMTP EHLO.

The PHP Net_SMTP class will also default to using a
HELO of ‘localhost’ unless a different value is passed to the constructor.

If you’re using fetchmail: older versions of fetchmail (eg: 6.2.5) almost always
use «localhost». The latest version (as of 2006/02/22 is 6.3.2) will
use «localhost» if the gethostname() function fails. You should upgrade
to the latest version, and make sure that gethostname() returns the
fully qualified domain name of your machine — which will probably
involve mucking about with /etc/hosts and sethostname/setdomainname.
If all else fails, hack the source, recompile and reinstall.

Apparently the «MXLookup» plugin for SpamPal helos as localhost.
Turn it off until you can get a fixed version. It is unknown
as yet whether a fixed version is available.

After making corrections to your mail server configuration,
retest it by following the «Testing HELO configuration»
instructions above.

If this IP address is a NAT or PAT firewall or gateway, you should
also follow the configuration recommendations described
here

If the IP relists after fixing this problem, you ALSO have
a spam proxy or similar malware problem to track down.

Аспекты организации собственной массовой рассылки

• Единичные сообщения. Сюда можно отнести все уведомления, которые получает пользователь при обращение с сайтом (например регистрация, подписка, покупка и тп). Во всех случаях автоматически ему приходят оповещения о тех или иных действиях, которые он совершил.
• Массовые сообщения. Сюда относим всяческие массовые рассылки и системы массовых оповещений.
• Списки рассылки (mailing list). Это способ организации массовой рассылки, разделяющий все сообщения на определенные заданные тематики. Имя списка рассылки представляет собой виртуальный коллективный почтовый адрес. То есть сообщения, направленные по этому адресу, доставляются всем членам списка. Выделяют два вида списков рассылки: модерируемые или немодерируемые. Модерируемые списки рассылки – это списки, в которых все сообщения, подлежащие массовой рассылке, проходят модерацию. То есть проверку содержания. В результате этой проверки могут быть отброшены сообщения, не относящиеся к тематике списка, содержащие рекламу, ненормативную лексику, противоречащие законодательным актам и т.п. Такая проверка может осуществляться специальными людьми, называемыми модераторами, или автоматически, например, по определенным ключевым словам.

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

Для выполнения первой задачи вам с легкостью подойдут штатные методы языка, который вы использовали при написании системы. Для примера покажу как это дело обстоит на Parser — скриптовом языке, который используется в нашей студии и на котором построена ClickON/CMS (система управления сайтами наших клиентов).

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

^mail:send
	$.to
	$.subject
	$.text
]

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

Переходим ко второй задачи, а именно массовой рассылке. Допустим вам нужно разослать порядка 1500 сообщений зарегистрированным пользователям о расширении ассортимента. Для того, что бы ее реализовать, вам не подойдет решение из первой задачи. Почему, спросите вы? Да потому что, если вы пройдете  циклично по всем адресам и каждому кинете письмо, то возникает вероятность того, что вы рано или поздно окажетесь в  DNSBL.  То есть так делать нежелательно:

^for(1;1500){ 
	^mail:send 
		$.to 
		$.subject 
		$.text 
	] 		
}

В бан мы попадем или нет по нескольким причинам:

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

Вообщем все, о чем мы говорили в разделе «Теория».

Отсюда возникает вполне резонный вопрос? Как же поступить в данной ситуации и как это реализовано у других пользователей?

Выделяю два решения:

1. Использование стороннего сервиса
2. Вручную писать велосипед