Это хорошая практика или слишком суровый, чтобы отклонять почту с почтовых серверов без RDNS


20

Я недавно удалил SpamAssassin и теперь основываю отклонение спама на DNSRBL, сером списке и других базовых тестах, и мне интересно, должен ли я также блокировать хосты, у которых нет действительного RDNS, соответствующего EHLO?

Если я сделаю это, я собираюсь доставить неприятности за много законной почты и расстроить моих клиентов? Я слышал, как люди говорят, что AOL делают это, и это заставляет меня думать, что это слишком необычно для меня.

Мне также интересно, могу ли я пойти на компромисс, проверив, что RDNS по крайней мере настроен на что-то, но не попытаться сопоставить его с EHLO. Возможно ли это с Postfix (и полезно ли это)?


4
Да, это обычно делается, даже если с этим сталкивается очень небольшое количество людей. См. Борьба со спамом - Что я могу сделать как: администратор электронной почты, владелец домена или пользователь? для дальнейшего обсуждения.
Майкл Хэмптон


Много месяцев назад обратный просмотр новой установки sendmail в Red Hat был по умолчанию ... Я думаю, что rDNS, хотя и не является формальным стандартом для почтовых серверов, в значительной степени является стандартом де-факто. Он переворачивает людей на динамических IP-адресах (то есть домах с подключениями интернет-провайдеров потребительского уровня), но раньше было так, что большая часть этих динамических IP-адресов с подключениями была ботнетами ... не знаю о сегодняшних днях.
Эйвери Пэйн

Ответы:


10

Я испробовал несколько подходов с проверкой HELO / EHLO с довольно приличной клиентской базой от 100 до 200 тыс. Пользователей, и в итоге выбрал решение, которое выполняет следующее:

  • Убедитесь, что HELO / EHLO содержит доменное имя. - Это в основном сводится к тому, что в названии есть точка. Проверка DNS на имени привела к МНОГИМ отказавшим серверам, поскольку весьма обычно, чтобы сервер представил внутреннее имя или что-то, что вы не можете разрешить должным образом.
  • Убедитесь, что IP-адрес имеет обратную запись DNS. - Опять же, это слабая настройка, поскольку мы не сравниваем ее с HELO / EHLO. Проверка на HELO / EHLO создала так много билетов, что эта настройка не продлилась ни одного дня.
  • Проверьте правильность имени домена отправителей. - Это базовая проверка, чтобы удостовериться, что если нам действительно нужно отослать сообщение, найдется хотя бы какой-нибудь способ найти сервер для него.

Вот блок Postfix, который мы используем для этих проверок:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

1
Также хорошим дополнительным подходом является проверка имени хоста по списку регулярных выражений, которые соответствуют различным именам, динамически назначаемым ISP, например xxxx.dynamic.yyy.comили 12-34-56-78.dsl.zzz.com. Все такие хосты должны отправлять свою почту через ретранслятор интернет-провайдера, а не напрямую на MX получателя. В основном такими хостами являются узлы ботнетов и их сообщения, которые я использую для изучения своих байесов.
Кондыбас

Похоже, это может быть решением для меня. Есть ли способ запустить SpamAssassin и позволить его обойти всем, кроме тех писем, которые не смогли HELO сопоставить с RDNS, тогда мы отбрасываем только те, у которых выше определенного балла? Другие письма продолжают полностью обходить этот шаг.
Питер Сноу

С exim MTA я сделал это последовательно: аддер / хост отправителя проверяется по белому списку. Если совпадает - принимается немедленно, иначе проверяется по черному списку. Если совпало - переменная пометка подняла "Gotcha!" и сообщение также принято. Если сообщение было пропущено через списки - оно передается в SA, который действует как демон. Если возвращаемое значение достаточно высокое, флаг "Gotcha!" поднял и сообщение также принято. Затем сообщение передается маршрутизаторам.
Кондыбас

1
Если флаг не установлен, сообщение доставляется как обычно. В противном случае производится слепая копия. Исходное сообщение снова доставляется как обычно, в то время как BC передается на специальный маршрутизатор, который имеет sa-learn в качестве транспорта. Такая схема позволяет разделить почтовый поток на определенно спам-ветку, которая изучает SA-байес, и подозрительно относится к остальным, проверенным SA-байесами. Сообщения с поднятым флагом также имеют дополнительный заголовок, позволяющий отсортировать их в «Хлам»
Kondybas

Я проверил эти правила в своем почтовом ящике, и есть электронные письма, которые были бы отклонены из-за отсутствия домена HELO или отсутствия обратной записи DNS. По общему признанию их очень мало (всего несколько отправителей в почтовом ящике с 40 000 электронных писем), но там есть важные вещи. В частности, если бы я использовал reject_unknown_reverse_client_hostname, электронное письмо с результатами моего заявления на визу в конкретную страну Юго-Восточной Азии не было бы получено. Я бы посоветовал не использовать reject_invalid_helo_hostnameи reject_unknown_reverse_client_hostname.
Микау

12

Крайне распространено блокировать SMTP-серверы, у которых нет этих основ:

  1. Имя хоста в HELO forward преобразуется в IP-соединение, возникшее из.
  2. Исходный IP-адрес подключения обращается к имени хоста, указанному в HELO.
  3. Если существуют политики SPF, DKIM или DMARC, проверьте.

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


2
Обратное имя не обязательно должно совпадать с HELO. Хост может управлять множеством доменов, в то время как обратный поиск возвращает только одно основное имя.
Кондыбас

1
Конечно, вы можете делать все, что хотите. Ваш 511 Your rDNS doesn't match your HELOсервер будет получать от моих серверов, а также от многих других. Спам является серьезной проблемой, с которой разработчикам SMTP RFC не приходилось сталкиваться. Реалистичные требования заметно отличаются от RFC в незначительном смысле.
Крис С

Спам не является проблемой, если MTA правильно настроен. Мой опыт показывает, что (с ошибкой rDNS, с которой ORсопоставлены короткие локальные совпадения с регулярными выражениями OR) обнаружено 99,99% спама. Нет DNSBL, нет серых списков, нет DKIM, нет SPF. 200k + входящие сообщения ежемесячно. 1-2 ложных-р, 10-20 ложных-н в месяц.
Кондыбас

5

Я ожидаю, что отправка MTA будет иметь действительный RDNS, но настаивать на сопоставлении EHLO будет зависеть от того, кто «клиенты». Вы можете найти некоторые интересные рекомендации в RFC5321 :

2.3.5.

(...) Доменное имя, указанное в команде EHLO, ДОЛЖНО быть либо основным именем хоста (доменное имя, которое разрешается в адрес RR), либо, если у хоста нет имени, адресным литералом (...)

4.1.4.

(...) SMTP-сервер МОЖЕТ проверить, что аргумент имени домена в команде EHLO действительно соответствует IP-адресу клиента. Однако, если проверка не удалась, сервер НЕ ДОЛЖЕН отказать в приеме сообщения на этой основе.

но потом в 7,9.

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


1
Это, вероятно, запрещено, потому что в реальном мире строка, отправляемая с помощью EHLO, часто не соответствует RFC. Я видел внутренние имена хостов localhostи много других неправильных вещей, отправленных сюда, даже с совершенно законной почтой.
Майкл Хэмптон

3

Обратный поиск не обязательно указывает на имя хоста, указанное в HELO. Иногда несколько доменов размещаются на одном хосте, и все они имеют одинаковый IP-адрес. Но когда вы попытаетесь выполнить обратный поиск, вы получите имя, которое было помещено в PTR-запись. Очевидно, что оба FQDN будут разными - и это полностью приемлемо.

Единственное обстоятельство, которое позволяет отбросить сообщение - неудачный обратный поиск. Любой успешный поиск означает, что хост действителен. Имена не должны совпадать.


1
«Очевидно, что оба FQDN будут разными - и это вполне приемлемо». Нет. Вы можете настроить только одну запись PTR, и ваш почтовый сервер может объявить только одно имя хоста в HELO. Так что должно быть очевидно, что оба могут совпадать.
Крис С

2

Мне интересно, должен ли я также блокировать хосты, у которых нет действительного RDNS, соответствующего EHLO?

Нет, ты не должен Блокирует всю электронную почту только по одному критерию, это плохая практика.

Если я сделаю это, я собираюсь доставить неприятности за много законной почты и расстроить моих клиентов?

Скорее всего, вы потеряете законную почту

Мне также интересно, могу ли я пойти на компромисс, проверив, что RDNS по крайней мере настроен на что-то, но не попытаться сопоставить его с EHLO. Возможно ли это с Postfix (и полезно ли это)?

да, это возможно. Вы можете использовать reject_unknown_reverse_client_hostname вместо reject_unknown_client_hostname

К сожалению, у postfix нет гибких опций для «сложного решения». В exim вы можете добавить несколько пунктов для таких писем, например:

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

И так далее. После того, как все проверки будут завершены, и если у вас есть Счет> 100, вы можете отклонить почту. На самом деле вы можете получить такое поведение, но вам нужно будет написать свой собственный сервис политики

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.