Це хороша практика чи занадто драконічне відхилення пошти від поштових серверів без RDNS

Нещодавно я відмовився від SpamAssassin, і тепер я базую відмову від спаму на DNSRBL, сірий список та інші основні тести, і мені цікаво, чи варто також блокувати хости, які не мають дійсного RDNS, що відповідає EHLO?

Якщо я це зроблю, чи не заважаю на законну пошту та засмучувати своїх клієнтів? Я чув, як люди схоплюються, що AOL це робить, і це змушує мене думати, що це, можливо, занадто рідко для мене.

Мені також цікаво, чи можу я йти на компроміс, перевіряючи, що RDNS принаймні щось встановлено, але не намагаюся відповідати його EHLO. Чи можливо це за допомогою Postfix (і чи корисно це)?

Я спробував декілька підходів, перевіряючи HELO / EHLO з досить пристойним клієнтським набором серед 100k-200k користувачів, і в кінцевому підсумку вирішував таке:

• Перевірте, чи 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

Вкрай звичайно блокувати SMTP-сервери, які не мають цих основ:

1. Ім'я хосту в HELO вперед переноситься на IP-з'єднання, похідне від.
2. IP-адреса з'єднання повертається до імені хоста, заявленого в HELO.
3. Якщо існують політики SPF, DKIM або DMARC, перевірте це.

Кожен, хто захоплюється заблокованістю через одну з них, повинен бути відбитим і пернатим.
Людям, які опиняються заблокованими з інших причин, особливо ситуацій, які покладаються на відповідність RFC у "ненормальних" ситуаціях, я буду співчувати цьому. Спам - це така проблема, що немає просто приводу для пропуску основ.

Я би очікував, що надсилання MTA матиме дійсні RDNS, але наполягати на відповідності EHLO буде залежати від того, хто такі "клієнти". Деякі цікаві вказівки ви можете знайти в RFC5321 :

2.3.5.

(...) Ім'я домену, вказане в команді EHLO, ОБОВ'ЯЗКОВО бути або основним іменем хоста (ім'я домену, яке вирішує адресу RR), або, якщо у хоста немає імені, адресною (буквально) (...)

4.1.4.

(...) SMTP-сервер МОЖЕ перевірити, чи аргумент доменного імені в команді EHLO насправді відповідає IP-адресі клієнта. Однак якщо перевірка не вдається, сервер НЕ МОЖЕ відмовляти приймати повідомлення на цій основі.

але тоді в 7,9.

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

Зворотний пошук не обов'язково вказує на ім'я хоста, вказане в HELO. Іноді на одному і тому ж хості розміщено декілька доменів, і всі вони мають однакову IP-адресу. Але коли ви спробуєте зробити зворотний пошук, ви отримаєте ім'я, яке було розміщено в записі PTR. Очевидно, що обидва FQDN будуть різними - і це цілком прийнятно.

Єдина обставина, яка дозволяє скинути повідомлення, - це невдалий зворотний пошук. Будь-який успішний пошук означає, що хост дійсний. Імена не повинні збігатися.

Мені цікаво, чи слід також блокувати хости, які не мають дійсного RDNS, що відповідає EHLO?

Ні, ви не повинні. Блокує цілу електронну пошту лише за одним критерієм, це погана практика.

Якщо я це зроблю, чи не заважаю на законну пошту та засмучувати своїх клієнтів?

з більшою ймовірністю ви втратите законну пошту

Мені також цікаво, чи можу я йти на компроміс, перевіряючи, що RDNS принаймні щось встановлено, але не намагаюся відповідати його EHLO. Чи можливо це за допомогою Postfix (і чи корисно це)?

так, можливо. Ви можете використовувати reject_unknown_reverse_client_hostname замість reject_unknown_client_hostname

На жаль, постфікс не має гнучких варіантів "складного рішення". У 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, ви можете відхилити пошту. Насправді ви можете отримати таку поведінку, але вам потрібно написати власну службу політики