Сервер Postfix SMTP приймає пошту з мережі і схильний до дії з боку спамерів і вірусів. Даний документ описує вбудовані і зовнішні методи Postfix, які вказують, яку SMTP пошту він повинен приймати. Також ви дізнаєтеся, яких помилок слід уникати і як тестувати свою конфігурацію.
Теми, охоплені в документі:
Більшість можливостей по управлінню доступом до SMTP сервера Postfix спрямовані на боротьбу зі спамом.
Орієнтовані на чорні списки. Деякі засоби управління доступом до SMTP сервера опитують чорні списки (blacklists), в яких зберігається інформація про "поганих" сайтах таких, як відкриті релеі (open mail relays), відкриті WEB-проксі сервера, скомпрометовані домашні комп'ютери, які віддалено керовані криміналітетом. Ефективність чорних списків залежить від їх повноти та актуальності (сучасності) інформації (up to date).
На жаль, всі засоби боротьби зі спамом можуть помилятися, відкидаючи легітимні листи. Це може бути серйозною проблемою для сервера, який займається обробкою пошту для великої кількості користувачів. Для одних користувачів неприйнятно отримання хоч одного листа спаму, в той час як для інших одне помилково відкинуте легітимне повідомлення може обернутися трагедією. Так як немає певної політики, яка б удовлітворяла побажанням усіх без винятку користувачів, Postfix підтримує різні обмеження щодо доступу до SMTP сервера для різних користувачів. Ця можливість описана в документі RESTRICTION_CLASS_README.
Крім обмежень, які можуть бути налаштовані для окремих клієнтів або користувачів, в Postfix реалізовані кілька обмежень, які впливають на всю SMTP пошту.
Вбудовані обмеження по вмісту header_checks (перевірки заголовка) і body_checks (перевірки вмісту листа), які описані в документі BUILTIN_FILTER_README. Ці перевірки проводяться під час прийому пошти, до приміщення листи в чергу вхідних повідомлень (incoming queue).
Зовнішня (за допомогою сторонніх програм) перевірка вмісту до приміщення в чергу, яка описана в документі SMTPD_PROXY_README. Ця перевірка виконується під час прийому пошти, до приміщення листи в чергу вхідних повідомлень (incoming queue).
Вимога до клієнтів відсилати команду HELO або EHLO перед використанням команди MAIL FROM або ETRN. Це може викликати проблеми при роботі з "доморощеними" поштовими клієнтами. З цієї причини обмеження відключено за замовчуванням ( "smtpd_helo_required = no").
Заборона некоректного синтаксису в командах MAIL FROM або RCPT TO. Це може викликати проблеми при роботі з "доморощеними" або древніми поштовими клієнтами. З цієї причини вимога відключено за замовчуванням ( "strict_rfc821_envelopes = no").
Postfix дозволяє задавати списки обмежень для кожного етапу SMTP діалогу. Окремі обмеження описані на сторінці документації postconf (5).
Приклади простих списків обмежень:
Кожен список обмежень обробляється зліва направо до тих пір, поки будь-яке обмеження не видасть результат PERMIT (дозволити), REJECT (відхилити) або DEFER (відкласти для подальшої повторної спроби). Досягнення кінця списку еквівалентно отриманню результату PERMIT. Вказуючи обмеження PERMIT перед обмеженням REJECT, ви можете робити виняток для певних клієнтів або користувачів (т.зв. білі списки, whitelisting). Приклад нижче дозволяє відправляти пошту локальним клієнтам, але іншим клієнтам відсилання пошти для довільних одержувачів заборонена.
Нижче показана таблиця, яка пояснює призначення всіх списків обмежень доступу до SMTP. Синтаксис написання списків однаковий, вони відрізняються лише часом застосування і ефектом, який породжують результати REJECT або DEFER.
Назва списку обмежень
Ефект результату REJECT або DEFER
Відхиляти команду ETRN
Ранні версії Postfix виконували дії, передбачені списками обмежень доступу до SMTP, настільки рано, наскільки це можливо. Список обмеження клієнтів (client restriction list) перевірявся перед тим, як Postfix відсилав вітання "220 $ myhostname." SMTP клієнту. Список smtpd_helo_restrictions оброблявся перед тим, як Postfix відповідав на команду HELO (EHLO). Список smtpd_sender_restrictions оброблявся перед відповіддю на команду MAIL FROM. І так далі. Ця практика була дуже складною в застосуванні.
Поточні версії Postfix відкладають обробку списків обмеження для клієнтів, відправників і HELO до отримання команди RCPT TO або ETRN. Це поведінка контролюється параметром smtpd_delay_reject. Списки обмежень обробляються в правильному порядку (client, helo, etrn) або (client, helo, sender, recipient, data, end-of-data). Коли список обмежень (наприклад, client) видає результат REJECT або DEFER, обробка наступних списків (приклад: helo, sender, і т.д.) не виконується.
У той час як був доданий параметр smtpd_delay_reject. в Postfix також була введена підтримка змішаних списків обмежень, які комбінують інформацію про клієнта, відправника, одержувача та інформацію команд helo, etrn.
Переваги відкладеної обробки списків обмежень і змішаних списків:
Деякі SMTP клієнти не очікують негативних відповідей на ранніх етапах SMTP сесії. Коли погані новини відкладаються до відповіді на RCPT TO, клієнт йде, що і потрібно, а не висить до розриву з'єднання по таймаут, або, гірше того, входить в нескінченний цикл з'єднання-відмова-з'єднання.
Тепер читач може запитати, навіщо потрібні списки обмежень client, helo або sender, якщо їх обробка відкладається до команди RCPT TO або ETRN. Деякі люди рекомендують поміщати ВСЕ обмеження в список smtpd_recipient_restrictions. На жаль, це може привести до дуже довірливому поведінки SMTP сервера Postfix. Як це можливо?
Ось приклад, який ілюструє вищезгадану ситуацію:
Проблема цієї конфігурації в тому, що список smtpd_recipient_restrictions видає результат PERMIT для БУДЬ-ЯКОГО хоста, який анонсує себе, як "localhost.localdomain". В результаті, Postfix стає відкритим релеем (open relay) для всіх таких машин.
У Postfix є кілька можливостей, які допомагають тестувати правила доступу до SMTP:
Це засіб замінює дії SMTP сервера REJECT на DEFER (спробувати пізніше). Це дозволяє залишати повідомлення в черзі, які в іншому випадку були б повернуті відправнику. Вкажіть "soft_bounce = yes" в файлі main.cf, щоб запобігти постійне відхилення пошти SMTP сервером Postfix. З цією метою Postfix замінить всі коди відповідей 5xx на 4xx.
Ця можливість дозволяє замінити дії SMTP сервірують REJRCT на зауваження (warnings). Замість відхилення команди клієнта Postfix реєструє, що він збирався відкинути. Вкажіть "warn_if_reject" в списку обмежень доступу до SMTP перед тим обмеженням, яке ви хочете протестувати без реального відхилення пошти.