Проверка обратного звонка

Для другого использования см. Обратный вызов (телекоммуникации) § Безопасность модема .

Проверка обратного вызова , также известная как проверка вызова или проверка адреса отправителя , представляет собой метод, используемый программным обеспечением SMTP для проверки адресов электронной почты . Наиболее частым объектом проверки является адрес отправителя из конверта сообщения (адрес, указанный в SMTP-диалоге как « MAIL FROM »). Чаще всего используется в качестве меры защиты от спама .

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

Цель

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

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

Процесс

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

HELO verifier host name
MAIL FROM:<>
RCPT TO:<the address to be tested>
QUIT

Аналогично, команды MAIL FROM и RCPT TO могут быть заменены командой VRFY, однако поддержка команды VRFY не требуется и обычно отключена в современных MTA.

Оба эти метода технически совместимы с соответствующими SMTP RFC (RFC 5321), однако RFC 2505 ( лучшая текущая практика ) рекомендует по умолчанию отключать команду VRFY для предотвращения атак сбора каталогов . (Одна из широко распространенных интерпретаций подразумевает, что пара команд MAIL FROM/RCPT TO также должна реагировать таким же образом, но в RFC это не указано.)

Недостатки

Проверка обратного вызова является оскорбительной и может привести к блокировке сервера, домена или IP-адреса.

Если администратор почтового сервера отключил VRFY, то использование RCPT TO как способ обойти это является несанкционированным доступом и попыткой обойти контроль доступа. Таким образом, оператор может быть подвергнут гражданскому или уголовному преследованию, в зависимости от юрисдикции.

Ограничения

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

• Некоторые обычные почтовые обменники не дают полезных результатов при обратных вызовах:
  • Серверы, которые отклоняют все возвращенные письма (вопреки RFC 1123, части STD 3). ). Чтобы обойти эту проблему, postfix, например, использует либо локальный адрес почтмейстера , либо адрес «двойного возврата» в части MAIL FROM выноски. Однако у этого обходного пути есть две проблемы: во-первых, он может вызвать цикл проверки; во-вторых, это не удастся, если проверка тега адреса возврата используется для уменьшения обратного рассеяния . Таким образом, этот обходной путь не следует использовать. Проверка обратного вызова все еще может работать, если отклонение всех возвратов происходит на этапе DATA вместо более раннего этапа MAIL FROM, а отклонение недействительных адресов электронной почты остается на этапе RCPT TO, а не перемещается на этап DATA.
  • Серверы, которые принимают все адреса электронной почты на этапе RCPT TO, но отклоняют недействительные на этапе DATA. Обычно это делается для предотвращения атак со сбором каталогов и по своей конструкции не дает никакой информации о том, действителен ли адрес электронной почты, и, таким образом, предотвращает работу проверки обратного вызова.
  • Серверы, которые принимают всю почту во время диалога SMTP (и позже генерируют свои собственные возвраты). Эту проблему можно облегчить, проверив случайный несуществующий адрес, а также желаемый адрес (если тест успешен, дальнейшая проверка бесполезна).
  • Серверы, реализующие всеобъемлющую электронную почту, по определению будут считать все адреса электронной почты действительными и принимать их. Подобно системам, которые принимают, а затем возвращают, случайный несуществующий адрес может обнаружить это.
• Процесс обратного вызова может вызвать задержки в доставке, поскольку почтовый сервер, на котором проверяется адрес, может использовать медленные методы защиты от спама, включая «задержки приветствия» (вызывающие задержку соединения) и занесение в серый список (вызывающий отсрочку проверки).
• Если вызываемая система использует серый список, обратный вызов может не возвращать никакой полезной информации, пока не истечет время серого списка. Грейлистинг работает, возвращая «временный сбой» (код ответа 4xx), когда он видит незнакомую пару адресов электронной почты MAIL FROM/RCPT TO. Система серых списков не может выдавать «постоянный сбой» (код ответа 5xx) при предоставлении недействительного адреса электронной почты для RCPT TO, а может вместо этого продолжать возвращать код ответа 4xx.
• Некоторые электронные письма могут быть законными, но не иметь действительного адреса « конверта от » из-за ошибки пользователя или просто неправильной конфигурации. Положительным моментом является то, что процесс проверки обычно приводит к полному отказу, поэтому, если отправитель был не спамером, а реальным пользователем, он будет уведомлен о проблеме.
• Если сервер получает много спама, он может выполнять много обратных вызовов. Если эти адреса недействительны или являются спам-ловушкой , сервер будет очень похож на спамера, который проводит атаку по словарю для сбора адресов. Это, в свою очередь, может привести к тому, что сервер будет занесен в черный список в другом месте.
• Некоторые администраторы считают любую проверку обратного вызова нежелательной массовой рассылкой по электронной почте (UBE) и могут заблокировать исходный SMTP-клиент, сообщить о нем как о спаме или добавить его в DNSBL , даже если обратное рассеяние имеет небольшой объем.
• Каждый обратный вызов налагает нежелательную нагрузку на вызываемую систему, и у этой системы очень мало эффективных способов избежать этой нагрузки. В крайних случаях, если спамер злоупотребляет одним и тем же адресом отправителя и использует его в достаточно разнообразном наборе получающих MX, все из которых используют этот метод, все они могут попробовать обратный вызов, перегружая MX для поддельного адреса запросами (фактически Распределенная атака типа «отказ в обслуживании»).
• Проверка обратного вызова не имеет никакого эффекта, если спамеры подделывают реальные адреса электронной почты. или используйте нулевой адрес возврата.

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

Некоторые из вышеперечисленных проблем решаются за счет кэширования результатов проверки. В частности, системы, которые не предоставляют никакой полезной информации (не отклоняют во время RCPT TO, имеют всеобъемлющую электронную почту и т. д.), могут быть запомнены, и в будущем не потребуется выполнять обратные вызовы к этим системам. Кроме того, можно запомнить результаты (положительные или отрицательные) для конкретных адресов электронной почты. MTA, такие как Exim, имеют встроенное кэширование.

Внешние ссылки

• спам-ссылки: проверка вызова отправителя
• Проверка отправителя — Фонд свободного программного обеспечения