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

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

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

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

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

Имя хоста верификатора HELOПОЧТА ОТ:<>RCPT TO:< адрес для проверки >ПОКИДАТЬ

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

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

Проверка обратного вызова является злоупотреблением ^[1] и может привести к блокировке сервера, домена или IP-адреса.

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

Документация как для postfix , так и для exim предостерегает от использования ^{[2] [3]} этой техники и упоминает множество ограничений для обратных вызовов SMTP. В частности, существует множество ситуаций, когда это либо неэффективно, либо вызывает проблемы в системах, которые получают обратные вызовы.

• Некоторые обычные почтовые обменники не дают полезных результатов при ответах на звонки:
  • Серверы, которые отклоняют все обратные сообщения (вопреки RFC 1123, части STD 3 ^[4] ). Чтобы обойти эту проблему, postfix, например, использует либо адрес локального почтмейстера , либо адрес «double-bounce» в части MAIL FROM вызова. Однако этот обходной путь имеет две проблемы: во-первых, он может вызвать цикл проверки; во-вторых, он не будет работать, если проверка тега адреса возврата используется для уменьшения обратного рассеивания . ^[1] Поэтому этот обходной путь не следует использовать. Проверка обратного вызова все еще может работать, если отклонение всех обратных сообщений происходит на этапе DATA вместо более раннего этапа MAIL FROM, в то время как отклонение недействительных адресов электронной почты остается на этапе RCPT TO вместо того, чтобы также перемещаться на этап DATA. ^{[2] [3]}
  • Серверы, которые принимают все адреса электронной почты на этапе RCPT TO, но отклоняют недействительные на этапе DATA. Обычно это делается для предотвращения атак с целью сбора каталогов и, по замыслу, не будет давать никакой информации о том, является ли адрес электронной почты действительным, и, таким образом, предотвратит работу проверки обратного вызова. ^{[2] [1]}
  • Серверы, которые принимают все письма во время диалога SMTP (и генерируют собственные отказы позже). ^[2] Эту проблему можно решить, проверив случайный несуществующий адрес, а также желаемый адрес (если тест пройден успешно, дальнейшая проверка бесполезна).
  • Серверы, реализующие функцию catch-all e-mail, по определению будут считать все адреса электронной почты действительными и принимать их. Как и системы, которые принимают-затем-возвращают, случайный несуществующий адрес может это обнаружить.
• Процесс обратного вызова может вызвать задержки в доставке, поскольку почтовый сервер, на котором проверяется адрес, может использовать медленные методы борьбы со спамом, включая «задержки приветствия» (вызывающие задержку соединения) и серый список (вызывающие задержку проверки). ^[2]
• Если вызываемая система использует грейлистинг, обратный вызов может не возвращать никакой полезной информации, пока не истечет время грейлистинга. Грейлистинг работает, возвращая «временный сбой» (код ответа 4xx), когда видит незнакомую пару адресов электронной почты MAIL FROM/RCPT TO. Система грейлистинга может не выдавать «постоянный сбой» (код ответа 5xx), когда указан недействительный адрес электронной почты для RCPT TO, и вместо этого может продолжать возвращать код ответа 4xx. ^[5]
• Некоторые электронные письма могут быть легитимными, но не иметь действительного адреса " convert from " из-за ошибки пользователя или просто неправильной настройки. Положительный аспект заключается в том, что процесс проверки обычно приводит к прямому отклонению, поэтому, если отправитель не был спамером, а реальным пользователем, он будет уведомлен о проблеме.
• Если сервер получает много спама, он может делать много обратных вызовов. Если эти адреса недействительны или spamtrap , сервер будет выглядеть очень похожим на спамера, который проводит атаку по словарю, чтобы собрать адреса. Это, в свою очередь, может привести к тому, что сервер будет занесен в черный список в другом месте. ^{[2] [1] [6]}
• Некоторые администраторы считают любую проверку обратного вызова нежелательной массовой рассылкой электронной почты (UBE) и могут заблокировать исходный SMTP-клиент, сообщить о нем как о спаме или добавить его в DNSBL , даже если объем рассылки невелик.
• Каждый обратный вызов накладывает непрошеную нагрузку на систему, к которой осуществляется обратный вызов, и у этой системы очень мало эффективных способов избежать этой нагрузки. В экстремальных случаях, если спамер злоупотребляет тем же адресом отправителя и использует его в достаточно разнообразном наборе принимающих MX, все из которых используют этот метод, они все могут попытаться выполнить обратный вызов, перегружая MX для поддельного адреса запросами (фактически атака Distributed Denial of Service ). ^[1]
• Проверка обратного вызова не имеет никакого эффекта, если спамеры подделывают реальные адреса электронной почты ^{[1] [7]} или используют нулевой адрес возврата.

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

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

• спам-ссылки: проверка отправителя ^{[узурпировано]}
• Проверка отправителя — Free Software Foundation