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

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

Эта статья может быть несбалансированной по отношению к определенным точкам зрения . Пожалуйста, улучшите статью , добавив информацию о игнорируемых точках зрения, или обсудите проблему на странице обсуждения . ( Декабрь 2010 г. )

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

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

Цель [ править ]

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

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

Процесс [ править ]

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

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

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

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

Ограничения [ править ]

Документация для postfix и 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]

Ссылки [ править ]

Внешние ссылки [ править ]

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