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

Информацию о программном обеспечении "проверки обратного вызова", когда-то широко используемом системами удаленного доступа, см. Обратный звонок (телекоммуникации) # Безопасность модема.

Проверка обратного звонка, также известный как проверка выноски или же Проверка адреса отправителя, это метод, используемый SMTP программное обеспечение для проверки адрес электронной почты. Наиболее распространенной целью проверки является адрес отправителя из конверта сообщения (адрес, указанный в диалоге SMTP как "ПОЧТА ОТ "). Он в основном используется как антиспам мера.

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

Цель

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

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

Процесс

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

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

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

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

Ограничения

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

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

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

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

Рекомендации

  1. ^ а б c d е ж Как проверить постфиксный адрес
  2. ^ а б c Проверка Exim Callout
  3. ^ RFC 1123, 5.2.9 Синтаксис команд
  4. ^ а б c d е Джон Левин - Проверка адреса отправителя: все еще плохая идея
  5. ^ Следующий шаг в войне за контроль спама: серые списки
  6. ^ [1] backscatterer.org дает указания отправителя как повод для включения в их DNSBL.
  7. ^ Джастин Мейсон - проверка адреса отправителя считается вредной

внешняя ссылка