Що поставимо
Необхідно підняти поштовий сервер, на якому буде крутитися зв'язка Postfix + Dovecot. Віртуальні поштові домени з індивідуальними (або домен) квотами. З адекватною перевіркою на віруси та спам (застіблення postgrey + на рівні SMTP-сесії + spamassassin). Також організуємо доступ користувачів через веб-інтерфейс та управління користувачами так само через вебморду.
Що поставимо
Postifx, Dovecot, postgrey, amavis, spamassassin, roundcube, postfixadmin.
Що нам потрібно
Встановлення та налаштування apache2 + mysql-server у цій статті я розмотувати не буду.
Поставимо всі необхідні пакети
У /etc/hostname має бути ім'я сервера без доменної частини. А в / etc / mailname навпаки - ім'я fqdn.
Зауваження: досвідченим шляхом перевірено, що hostname може бути будь-яким, головне щоб у mailname було прописано доменне ім'я, яке написане в MX-записі домену для якого робимо пошту (Наприклад: mail.example.com)
Створимо користувача від імені якого буде працювати postfix та dovecot.
Необхідно створити сертифікати для роботи поштового сервера. (для підключення користувачів за допомогою SSL)
Звичайно, замінивши значення на свої.
Тепер власне згенеруємо самі сертифікати
Видалимо файл налаштувань
Перейдемо на налаштування postfix.
Наведемо main.cf до такого виду
додамо в master.cf підтримку submission (це дозволить працювати postfix по 587 порту). Додаємо відразу після smtp.
так само додамо, що dovecot буде займатися доставкою листів по ящиках. Додамо до кінця файлу.
так само додамо підтримку amavis і postgrey
Додамо файли із запитами, для роботи віртуальних доменів, користувачів, аліасів.
Примітка: використовуйте в DB замістьlocalhost, 127.0.0.1. Інакше не злетить!
Наведемо порядок із правами на створені файли
Створимо файл білих списків для одержувачів та відправників
Записи у цих файлах мають виглядати таким чином
Перейдемо до налаштування Dovecot. Приступимо до редагування його конфігів /etc/dovecot/conf.d
example.com замініть свій домен, який Ви прописували в /etc/mailname
Тепер повернемося до /etc/dovecot
уconnectзамініть
тут також замінити у двох місцях
Створимо скрипт оповіщення користувачів про перевищення квоти
Налаштування антиспам
Розкоментуємо рядки в
Підправимо порогові значення для визначення спаму, а так само зробимо, щоб листи зі спамом не відсікалися, а пропускалися. Потім налаштуємо, щоб вони складалися користувачеві в папку спам.
Бажано додати віртуальні домени в whitelist, для того щоб вони точно не розпізнавались як спам
Так як у нас встановлений тільки ClamAV, залишимо лише його як основний сканер на віруси. Наведемо конфіг до такого виду.
Для того щоб не було проблем з правами доступу, змінюємо у файлі
додаємо користувача amavis до групи clamav і навпаки, потім міняємо власника папки /var/log/clamav/
у файл /etc/default/spamassassin
Файл повинен належати користувачеві vmail.
підправимо на останок налаштування spamassassin і справа в капелюсі
У конфізі вище whitelist_from *@example.com замініть example.com на свій домен
Перезапускаємо демони, щоб зміни набули чинності
Перші два-три тижні spamassassin треба буде навчати, а потім разом з postgrey вони будуть пропускати приблизно один спам на день. Даного набору цілком достатньо для ефективної боротьби зі спамом.Особливо хочу висловити свою громадянську позицію щодо спамхауса: у системних адміністраторів, які використовують спамхаус, бабусі працювали вахтерами на заводських прохідних!
У зв'язку з базовістю налаштувань postifx'a довелося сильно його допиляти на додаткові перевірки на відсікання спаму. Щоб знизити навантаження на сервер (amavis жере нормально так), ми перевірятимемо засобами postfix вхідні листи на відповідність RFC.
Варіанти фільтрів
Зворотний запис DNS (PTR запис). Вважається правилом гарного тону, коли адміністратор призначає кожному зворотному хосту (PTR) запис. Крім того, вважається таким же добрим тоном, коли зворотний запис запис збігається з прямим (А) записом.
Відсутність зворотного запису сервера відправника побічно вказує на те, що повідомлення є спамом. Ви не знайдете жодного сервера gmail, yahoo, mail.ru, yandex.ru і т.д., які не мали б зворотного запису. І, хоча, теоретично відсутність зворотного запису не може бути критерієм для оцінки спамності листа, але як показує практика в 99% випадків зворотний запис відсутня саме у хостів розсилають спам, тому по відсутності зворотного запису у відправника цілком можна відсіювати спам, а зіштовхуючись з залишком 1% - заносити їх до списку винятків. Відповідні директиви у конфізі postfix: reject_unknown_client .
HELO/EHLO. RFC прямо не зобов'язує, але рекомендує відправникам розпочинати SMTP сесію з HELO, в якому зазначено повноцінне доменне ім'я (fully qualified domain name або скорочено FQDN, наприклад “smtp.example.com”). І, хоча, немає прямого зобов'язання це робити, але як і у випадку зі зворотним записом, передача в HELO неповноцінного доменного імені (наприклад “example”) або передача неіснуючого доменного іменіде-факто стали непрямими покажчиками те що, що лист є спамом. Відповідні директиви в конфізі postfix: reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_hostname.
N.B. При налаштуванні свого поштового сервера постарайтеся, щоб у HELO Ваш сервер віддавав те, що прописано в PTR запису ... Адже матеріал вище Ви читали уважно і PTR запис і А запис у Вас вже збігаються, чи не так? ;)
Greylisting. Сірий список. Робота грейлістингу полягає в тому, що поведінка клієнтів розсилає спам відрізняється від поведінки чесних поштових серверів. Під час SMTP сесії грейліст віддає клієнту помилку з кодом (4xx), який означає “тимчасова помилка, спробуйте повторити пізніше”. Чесний поштовий сервер через час обов'язково спробує повторну доставку, оскільки вміє тримати чергу поштових повідомлень. Спамери ж у свою чергу черги не тримають, це продиктовано величезними обсягами розсилок, для них тримати чергу повідомлень просто недоцільно. У результаті виходить так, що чесний лист трохи затримується (зазвичай 15-30 хв), потім відправник заноситься в білий список як чесний відправник і після повідомлення від нього приходять без затримок. Спамери ж відсіваються, не роблячи спроби повторної доставки. Відповідні директиви у конфізі postfix: check_policy_service.
Контент-фільтри. До цього ми розглядали варіанти фільтрації, коли фільтри оперують даними початкових стадій SMTP сесії. Контент фільтри в свою чергу аналізують тіло листа. Приклади контент-фільтрів: ClamAV, Spamassassin, DSPAM.
Як правильно фільтрувати?
Перед усіма фільтрами варто додати свій білий список. У цей список Ви заноситимете чесні сервери, якінеправильно налаштовані та через це відфільтровуються. Їх буде дуже мало, але вони будуть.
Для того щоб перевірити роботу антиспаму та антивіруса, просто відправте на віртуальний домен з іншої скриньки листа з таким текстом:
антивірус
антиспам
Postfixadmin
І наостанок налаштуємо управління віртуальними доменами та їх поштовими скриньками через вебморду.
Завантажуємо останню версію на сайті
Копіювання та налаштування віртуального домену під postfixadmin залишаю за вами. Тут я тільки опишу налаштування самого postfixadmin.
Ще момент
За замовчуванням postfixadmin не фізично видаляє ящики після видалення з бази. У config.inc.php є опції, передбачені для виправлення такої ситуації, але це буде працювати тільки якщо postfixadmin встановлений на тому ж сервері, де і вся поштова система. У мене рознесена архітектура, тому для мене такий варіант не підходить, тому на просторах інтернету було знайдено скрипт, який за cron'ом запускається щоночі і шукає ящики яких немає в базі, але які є на сервері. Після такої звірки він "підчищає" після postfixadmin'a сліди. Спільно встановити скрипт можна ось так:
У самому скрипті потрібно виправити підключення до бази даних postfixadmin за аналогією як ми робили раніше.