Postfix reject_unknown_reverse_client_hostname: замініть невідомий_client_reject_code (450) на 550. Чому / коли я не повинен?

У щоденній битві проти СПАМу вже кілька разів траплялося, коли я спокусився жорстко виконувати вимоги DNS від клієнтів, що підключаються з дикого Інтернету.

Більш детально, я б додав reject_unknown_reverse_client_hostname установки в моєму smtpd_client_restrictions секції, як показано нижче :

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

У всякому разі, я зазначив, що при натисканні на таке обмеження поведінка Postfix є досить "м'якою", оскільки значення за замовчуванням для unknown_client_reject_code450 становить. Отже, клієнту пропонується продовжувати повторну спробу.

Досліджуючи відповідь 550, я зустріла наступне твердження в офіційній документації Postfix :

Я абсолютно не експерт по всьому RFC 5321 , але, як хтось досить старий, щоб знати RFC 821 , я дійсно не розумію, чому відповідь 550 замість 450 може вплинути на мій екземпляр Postfix на максимальному рівні SMTP ( порушення вимог RFC), особливо враховуючи, що у випадку тимчасових помилок Postfix буде дотримуватися 450, незалежно від явних налаштувань.

Отже, чи може хтось допомогти мені зрозуміти, у чому проблема такої заміни?

PS: тим часом я закінчився "розслабленим" обмеженням:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

Почну з двох практичних відповідей

1. Перша і найбільш очевидна відповідь полягає в тому, що у випадку тимчасової помилки DNS тимчасовий відмов дозволить поштовому серверу відправника спробувати ще раз, поки помилка DNS не буде виправлена. У цьому випадку постійний відмов буде блокувати фактичну пошту шинки від вас.

2. Друга відповідь полягає в тому, що велика кількість спаму надсилається через ботнетні скриньки, які не мають жодної форми фактичних функціональних програм для відправки пошти. Вони розпорошуватимуть свої сміття лише один раз, і не намагатимуться повторно надсилати повідомлення, чи отримано це повідомлення тимчасовою чи постійною помилкою. Отже, використовуючи тимчасову помилку, ви назавжди блокуєте великий відсоток спаму, але ви все одно дозволяєте шинці спробувати ще раз. (Це, до речі, саме тому грайлістинг все ще працює і все ще ловить багато спаму.)

Крім цих, є також відповідь, який більше відповідає теорії та RFC

Про це йдеться в розділі 4.2.1. що:

Основне правило для визначення того, чи відповідає відповідь категорії 4yz або 5yz (див. Нижче), - це відповіді 4yz, якщо вони можуть бути успішними, якщо повторитись без будь-якої зміни форми команди або властивостей відправника або отримувача (тобто , команда повторюється однаково, і приймач не висуває нову реалізацію).

У разі відмови зворотного пошуку, повідомлення може бути прийнятним без будь-яких змін у самому повідомленні, за умови лише виправлення помилки DNS. Тому це має бути тимчасовою помилкою.

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

Звичайно, ви все одно завжди маєте права відхиляти будь-яку електронну пошту з будь-якої причини.