Великий поштовий сервер на Ubuntu Server

Переклад та редагування,

збір інформації в одне ціле:

Рудюк Сергій Анатолійович

Email: rs@corp2.net

Viber: +38 (067) 901-63-22

Використовувані терміни: Postfix, POP3, SMTP, IMAP, MariaDB, Ubuntu, PostfixAdmin, Dovecot, Roundcube

У цій інструкції налаштовано повноцінний поштовий сервер на Linux Ubuntu Server (протестовано на версії 20.04). Список усіх особливостей та можливостей:

  • Підтримка шифрування;
  • Зберігання пошти на сервері;
  • Захист від СПАМу та вірусів;
  • Поштова система з урахуванням Postru
  • fix;
  • Підтримка віртуальних доменів;
  • Зберігання частини налаштувань у MariaDB;
  • Доступ до пошти за допомогою веб-інтерфейсу (Roundcube);
  • Підключення до поштових скриньок за POP3 та IMAP (Dovecot);
  • Можливість керування поштовими скриньками за допомогою PostfixAdmin.

Зміст

1. Передналаштування системи
2. Налаштування веб-сервера: NGINX + PHP + MariaDB
3. Встановлення та налаштування PostfixAdmin
4. Налаштування Postfix
5. Налаштування Dovecot
6. Перевірка роботи сервера
7. Налаштування Roundcube Webmail
8. Захист від вірусів та СПАМу
Clamav + Amavisd
Налаштування Postfix
Оновлення антиспаму
Перевірка налаштування
Пересилання СПАМу та вірусів на іншу скриньку
Антиспам засобами Postfix
Навчання антиспаму
9. Надсилання пошти без влучення в СПАМ
10. Налаштування DKIM
11. Налаштування дискових квот
12. Автоматичне налаштування поштових клієнтів
13. Відображення папок IMAP в Outlook українською
14. Додаткові налаштування
Налаштування лімітів
Зміна email
15. Можливі проблеми

І так, ця інструкція написана під Linux Ubuntu Server. Попередньо виконаємо наступні дії.


Загальні налаштування

Оновлюємо систему:

Задаємо правильне ім’я серверу – це важливий крок, оскільки більшість антиспам систем виконують перевірки, звертаючись до сервера на ім’я в очікуванні відповіді:

* необхідно вказати FQDN-ім’я, яке буде доступне з глобальної мережі. У цьому прикладі вказано relay.corp2.eu. Встановлюємо пакет для синхронізації часу:

Задаємо тимчасову зону (у цьому прикладі київський час):

* Щоб отримати список всіх можливих зон, вводимо timedatectl list-timezones. Дозволяємо сервіс для оновлення часу:

Налаштування безпеки

Заздалегідь відкриваємо порти на брандмауері за допомогою iptables:

* де ми відкриємо такі порти:

  • 25 – стандартний SMTP через STARTTLS;
  • 110 – стандартний POP3 через STARTTLS;
  • 143 – стандартний IMAP через STARTTLS;
  • 465 – захищений SMTP через SSL/TLS;
  • 587 – захищений SMTP через STARTTLS;
  • 993 – захищений IMAP через SSL/TLS;
  • 995 – захищений POP3 через SSL/TLS.
  • 80 – HTTP для порталів Postfixadmin і Roundcube;
  • 443 – захищений HTTPS для порталів Postfixadmin та Roundcube;

Для збереження правил встановимо пакет:

І виконуємо команду:

2. Налаштування веб-сервера: NGINX + PHP + MariaDB

Система керування PostfixAdmin працює як веб-додаток, розроблений на PHP, а інформацію зберігає у базі даних. У нашому прикладі використовуватиметься веб-сервер на NGINX, а база даних — MariaDB.
Установка NGINX

Встановлюємо nginx командою:

Дозволяємо автозапуск сервісу:

Перевіряємо працездатність веб-сервера, звернувшись до нього у браузері за адресою http://<IP-адреса сервера>. Якщо бачимо заголовок “Welcome to nginx!”, NGINX налаштовано правильно.

PHP + PHP-FPM + NGINX

Встановлюємо php та php-fpm:

Налаштовуємо NGINX:

У розділах http – server вказуємо, щоб першим індексним файлом був index.php, а також додаємо налаштування для обробки запитів php (location):

* де /var/www/html – каталог для розміщення даних nginx за замовчуванням; /run/php/php7.4-fpm.sock – шлях до сокет-файлу php-fpm (зверніть увагу, що точне значення залежить від використовуваної вервії php).

Дозволяємо автозапуск php-fpm:

* де php7.4-fpm залежить від версії php, яку можна подивитися командою php -v.

Перезапускаємо nginx:

Для перевірки, створюємо індексний файл у директорії сайту з таким вмістом:

MariaDB

Встановлюємо сервер баз даних наступною командою:

Включаем автозапуск сервиса баз данных:

Задаємо пароль для користувача sql root:

3. Встановлення та налаштування PostfixAdmin

Встановлюємо додаткові компоненти для PHP:

Для застосування встановлених пакетів перезапускаємо обробник скриптів:

Завантажуємо PostfixAdmin:

У директорії сайтів nginx створюємо каталог для postfixadmin та розпаковуємо в нього архів:

Створюємо каталог templates_c усередині папки порталу (без нього не запуститься установка):

* в іншому випадку, при спробі зайти в панель керування після її встановлення ми отримаємо помилку ERROR: the templates_c directory не існує або не задано для веб-сервера.

Задаємо права на каталог:

* незважаючи на те, що ми використовуємо веб-сервер nginx, php-fpm за замовчуванням, запускається від користувача www-data.

Створюємо базу даних postfix та обліковий запис mariadb:

* де postfix – ім’я бази.

* де postfix – ім’я облікового запису; postfix123 – пароль; localhost дозволяє підключення лише з локального сервера.

Виходимо з командної оболонки MariaDB:

Створюємо файл конфігурації postfixadmin:

* У попередніх версіях використовувався файл config.inc.php. У нових версіях його не рекомендується редагувати, а використовувати config.local.php, який перевизначає налаштування.

І додаємо наступне:

* де configured говорить програмі, що адміністратор закінчив його конфігурування; default_language — мова, що використовується за замовчуванням; database_password – пароль для бази даних, який ми задали на попередньому кроці; emailcheck_resolve_domain – задає необхідність перевірки домену при створенні ящиків та псевдонімів.

Запускаємо браузер і вводимо адресу http://<IP-адреса сервера>/postfixadmin/public/setup.php — відкриється сторінка для встановлення PostfixAdmin.

Задаємо двічі пароль установки і генеруємо хеш, клацнувши Generate setup_password hash:

Після копіюємо хеш, який з’явиться під кнопкою:

Відкриваємо конфігураційний файл:

І додаємо рядок:

* де ‘$2y$10$D…R32’ — скопійований хеш.

Перезавантажуємо сторінку http://<IP-адреса сервера>/postfixadmin/public/setup.php — тепер у нас з’явиться форма для введення нашого пароля, створеного на попередньому етапі. Вводимо його та клацаємо по Login with setup_password:

 

Буде виконано встановлення PostfixAdmin.

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

Після встановлення в нижній частині сторінки має бути форма додавання суперкористувача – вводимо дані:

* де Setup password – пароль, який ми ввели на попередній сторінці; Адмін — обліковий запис для входу до панелі керування PostfixAdmin; Пароль — новий пароль для облікового запису, що створюється.

Встановлення завершено. Переходимо в браузері на сторінку http://<IP-адреса сервера>/postfixadmin/public/login.php

Вводимо логін та пароль для створеного користувача. Ми повинні увійти до postfix.admin.

Однак, в моєму випадку, користувач не створювався при установці системи і необхідно було створити адміністратора вручну. Якщо це потрібно, в консолі сервера підключаємося до СУБД:

Переходимо до використання бази postfix:

Додаємо адміністратора запитом:

Виходимо з sql-оболонки:

Тепер переходимо на сторінку http://<IP-адреса сервера>/postfixadmin/public/login.php вводимо логін root@corp2.eu та пароль qwe12345 — ми повинні опинитися в системі керування поштою. Перш за все, переходимо в Список адмінів – Новий адмін:

Створюємо свого користувача. Після чого можна видалити те, що створили через командний рядок.


4. Встановлення та налаштування Postfix

 

Установка Postfix в Ubuntu виконується командою:

* крім самого postfix, ми також встановимо postfix-mysql для роботи з СУБД.

У процесі установки має з’явитися вікно Postfix Configuration — залишаємо Internet Site:

У наступному вікні залишаємо ім’я сервера та натискаємо Enter.

Після встановлення пакетів створюємо обліковий запис, від якого ми будемо працювати з каталогом віртуальних поштових скриньок:

* спочатку ми створюємо групу vmail і guid 1024, після – користувача vmail з uid 1024 та домашньою директорією /home/mail – у ній у нас буде зберігатися пошта. Зверніть увагу, що в деяких системах ідентифікатор групи та користувача 1024 може бути зайнятий. У такому випадку необхідно створити інший, а в даній інструкції нижче замінити всі 1024 альтернативний.

Якщо директорія для пошти раніше вже була створена, необхідно задати як власника нашого створеного користувача:

Відкриваємо на редагування конфігураційний файл поштового сервера:

І редагуємо наступні рядки:

* де:

  • mydestination – вказуємо, для яких доменів приймаємо вхідну пошту.
  • inet_protocols – цей параметр задасть протокол для роботи postfix. У цьому прикладі на ipv4 — якщо в нашій системі не використовується IPv6, можуть виникнути проблеми з маршрутизацією пошти. Також можна встановити значення all або ipv6.
  • smtpd_tls_cert_file – повний шлях до публічного сертифікату.
  • smtpd_tls_key_file – повний шлях до приватного сертифікату.

Якщо ім’я сервера відрізняється від імені, за яким сервер буде зареєстровано в DNS, задаємо опцію:

Тепер до кінця конфігураційного файлу допишемо наступне:

 

* де:

– virtual_mailbox_base – базовий шлях зберігання поштових скриньок у системі UNIX.

– virtual_alias_maps — формат та шлях зберігання аліасів для віртуальних користувачів.
– virtual_mailbox_domains — формат та шлях зберігання доменів віртуальних користувачів.
– virtual_mailbox_maps — формат та шлях зберігання поштових скриньок для віртуальних користувачів.
– virtual_minimum_uid — з якого номера надавати ідентифікатори користувачам.
– virtual_uid_maps — це ідентифікатор користувача, від якого записуються повідомлення.
– virtual_gid_maps — це ідентифікатор групи, від якої записуються повідомлення.
– virtual_transport — задає постачальника повідомлень.
– dovecot_destination_recipient_limit — передача повідомлень від Postfix до Dovecot виконується за заданою кількістю (у нашому прикладі, по 1 шт.).
– smtpd_sasl_auth_enable – дозволяє sasl автентифікацію.
– smtpd_sasl_exceptions_networks – виключення мереж від використання шифрування.
– smtpd_sasl_security_options — додаткові опції sasl.
– broken_sasl_auth_clients – цю опцію прописуємо для клієнтів MS Outlook.
– smtpd_sasl_type – вказує тип автентифікації.
– smtpd_sasl_path – шлях до тимчасових файлів обміну інформацією з Dovecot. Вказується або абсолютний шлях або відносний queue_directory (за замовчуванням /var/spool/postfix). Отже, повний шлях – /var/spool/postfix/private/auth.
– smtp_use_tls — по можливості використовувати шифроване з’єднання для підключення до іншого сервера SMTP при надсиланні листа.
– smtpd_use_tls – вказує клієнтам на наявність підтримки TLS.
– smtpd_tls_auth_only – використовувати тільки TLS.
– smtpd_helo_required – вимагати розпочинати сесію з вітання.

Створюємо файл із налаштуваннями звернення до бази з аліасами:

* де user і password – логін та пароль для підключення до MySQL; hosts – ім’я сервера баз даних (у разі, локальний сервер); dbname – ім’я бази даних; query — шаблон запиту даних.

Створюємо файл з інструкцією отримання даних щодо віртуальних доменів:

І файл із поштовими скриньками:

Відкриваємо файл master.cf і дописуємо до кінця:

* необхідно переконатися, що вміст файлу немає інших розкоментованих опцій для submission, smtps і dovecot (за замовчуванням, їх немає). В даному випадку, ми настроїли роботу postfix на портах 25, 465 та 587. У файлі master.cf ми налаштовуємо роботу допоміжних сервісів Postfix. Опис кожного сервісу починається з нового рядка без відступу. Потім йдуть налаштування для сервісу та параметри запуску. Наприклад, розглянемо перший доданий рядок. submission inet n – n – – smtpd:

  • submission – Ім’я сервісу. Можливе використання заздалегідь визначених у postfix служб або створення своїх. У даному прикладі submission для підключення MUA порту 587 при відправці пошти.
  • inet – тип обслуговування. Можливі варіанти inet (сокет TCP/IP), unix (потоковий сокет), unix-dgram (сокет дейтаграми), fifo (іменований канал черги), pass (потоковий сокет UNIX-домена).
  • перший “n” – чи є сервіс приватним і має бути обмеженим. Можливі варіанти y чи n. Для типу обслуговування inet може бути лише n.
  • перший “-“ – чи працює служба з правами root. Можливі варіанти y, n та -. Прочерк означає непридатність даного параметра до конкретного сервісу.
  • другий “n” – чи повинна служба працювати в оточенні chroot. Можливі варіанти y чи n.
  • другий “-“ – через який час у секундах розбудити службу, якщо вона неактивна.
  • третій “-“ — максимальна кількість процесів, що одночасно виконуються, які може запустити даний сервіс.
  • smtpd – команда, що виконується.

* Після команди йдуть аргументи її запуску. Вони можуть перевизначати параметри, задані main.cf. Кожен аргумент записується з нового рядка і починається з двох прогалин. У цьому прикладі ми використовуємо такі аргументи:

  • smtpd_tls_security_level – задає рівень безпеки із застосуванням TLS. У цьому прикладі may говорить про можливість його використання.
  • smtpd_sasl_auth_enable – дозволяє sasl автентифікацію.
  • smtpd_sasl_type – вказує тип автентифікації.
  • smtpd_sasl_path — шлях до тимчасових файлів обміну інформацією із сервером зберігання пошти (у нашому випадку Dovecot). Вказується або абсолютний шлях або відносний queue_directory.
  • smtpd_sasl_security_options — додаткові опції sasl.
  • smtpd_sasl_local_domain — додати домен для користувачів, які проходять автентифікацію smtp.
  • syslog_name — префікс назви служби під час занесення її до системного журналу.
  • smtpd_tls_wrappermode — чи запускати службу в нестандартному режимі (для підтримки TLS).
  • smtpd_client_restrictions — Налаштування обмеження з’єднання клієнта. У цьому прикладі дозволити лише авторизованих.

Генеруємо сертифікати безпеки. Для цього створюємо каталог, в якому їх розмістимо:

І згенеруємо їх наступною командою:

* сертифікат згенерований на 1461 день, ключі subj можуть бути довільними, CN необхідно вказати відповідно до імені сервера, яким ми будемо підключатися до пошти.
* якщо ми хочемо використовувати сертифікат, який проходитиме всі перевірки безпеки, його потрібно купити або запросити у Let’s Encrypt.

Дозволяємо запуск postfix:

Перезапускаємо його:

 

5. Налаштування Dovecot

 

Встановлюємо Dovecot із компонентом для роботи з СУБД:

Налаштовуємо спосіб зберігання повідомлень:

* у даному прикладі повідомлення зберігатимуться у просунутому форматі maildir у каталозі /home/mail/<поштовий домен>/<логін користувача>.

Налаштовуємо слухача для автентифікації:

* в даному прикладі ми налаштовуємо сервіс для аутентифікації і створюємо два прослуховувачі: /var/spool/postfix/private/auth – для можливості постфіксом використовувати авторизацію через Dovecot (звертаємо увагу, що /var/spool/postfix/private/auth – це той а private/auth, який був прописаний нами в postfix); auth-userdb – сокет для авторизації через dovecot-lda. Опція mode визначає права на сокет, наприклад, 666 дозволить будь-якому користувачеві до нього підключитися; user та group задає користувача та групу власників на сокет.

А також у цьому файлі додамо рядки:

* в іншому випадку, ми побачимо в лозі помилку error net_connect_unix(/var/run/dovecot/stats-writer) failed permission denied, так як у користувача vmail не буде правий.

Налаштовуємо автентифікацію в Dovecot:

* в даному випадку ми просто коментуємо звичайну автентифікацію та знімаємо коментар для використання SQL-аутентифікації.

Налаштовуємо використання шифрування:

* ssl = required вкаже dovecot вимагати від клієнтів використання шифрування; ssl_cert – шлях до відкритого сертифікату (також нами вказувався у postfix); ssl_key – шлях до закритого ключа.

Налаштуємо автоматичне створення каталогів при першому підключенні користувача до скриньки:

Налаштовуємо підключення до нашої бази даних:

* у цьому прикладі ми вказали на файл, в якому будуть знаходитись налаштування для отримання користувачів та паролів з бази даних. Це налаштування за замовчуванням і, в більшості випадків, не потрібно змінювати його без необхідності вказати свій шлях.

Відкриємо на редагування файл з налаштуваннями роботи з mysql:

У самий низ додамо:

* у цьому прикладі ми налаштували запит отримання даних з бази mysql (mariadb). password_query – запит на отримання пароля з таблиці mailbox; user_query — запит на отримання даних користувача (домашня поштова директорія, ідентифікатор 1024 (ідентифікатор створеного раніше користувача vmail).

І, насамкінець, налаштовуємо інтерфейс, на якому буде слухати dovecot:

* за замовчуванням, dovecot слухає також ipv6 (listen = *, ::). Якщо на сервері не використовується 6-а версія протоколу TCP/IP, у логах dovecot з’являться помилки:
master: Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
master: Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol

Дозволяємо запуск dovecot:

Перезапускаємо dovecot:

 

6. Створюємо першу поштову скриньку та перевіряємо роботу сервера

 

У браузері вводимо в адресному рядку шлях до Postfixadmin – http://<IP-адреса сервера>/postfixadmin/public/.

Вводимо логін та пароль від адміністративного облікового запису, який ми створили на кроці 3. Перед нами з’явиться сторінка керування обліковими записами.

Переходимо до Список доменів – Новий домен:

Заповнюємо форми і натискаємо Додати домен:

Тепер переходимо в Огляд – Створити скриньку:

Вводимо дані нового користувача і натискаємо на Створити скриньку:

Тепер можна підключитися до сервера за допомогою будь-якої поштової програми, наприклад Mozilla Thunderbird.

Параметри для підключення:

  • Сервер: ім’я сервера або його IP-адреса (не бажано, тому що сертифікат видається за доменним ім’ям).
  • IMAP: 143 STARTTLS або 993 SSL/TLS
  • POP3: 110 STARTTLS або 995 SSL/TLS
  • SMTP: 25 STARTTLS або 465 SSL/TLS або 587 STARTTLS

* для коректної роботи сервера на портах 993, 995, 465 (SSL/TLS) потрібен правильний сертифікат (для нашого домену та випущений довіреним центром сертифікації).

7. Встановлюємо та налаштовуємо Roundcube Webmail

 

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

На офіційному сайті заходимо на сторінку завантаження Roundcube. Дивимось посилання на версію продукту з тривалою підтримкою (LTS):

Використовуємо посилання, щоб завантажити архів програми:

Створюємо каталог, де розміщуватимуться файли порталу:

І розпаковуємо завантажений архів:

Копіюємо шаблон конфігу:

І відкриваємо його на редагування:

* Перший рядок ми редагуємо, а другий додаємо. У першому рядку roundcube:roundcube123 — логін та пароль для доступу до бази даних; localhost – сервер бази даних; roundcubemail – ім’я бази даних. Другий рядок дозволяє установку порталу.

Також дописуємо до конфігураційного файлу наступне:

* Налаштування $config[‘create_default_folders’] = true створює папки за промовчанням, якщо їх немає:

  • Drafts – Чернівці.
  • Junk – СПАМ.
  • Sent – Надіслані.
  • Trash – Кошик.

* Без налаштування, якщо не створювалися папки іншим клієнтом, веб-клієнт буде видавати помилки при переміщенні листів, наприклад, при їх видаленні.

Задаємо власника apache на папку порталу:

Создаем в MariaDB базу для roundcubemail:

І завантажуємо у створену базу дані:

Встановлюємо компоненти, необхідні для роботи Roundcube:

У Ubuntu немає можливості встановити компонент mcrypt з репозиторію – для початку встановимо пакети, необхідні для збирання його вихідних джерел:

Виконуємо команди:

Створимо файл із налаштуванням нового модуля:

Налаштуємо php:

* в даному прикладі ми задаємо московський час і можливість завантажувати файл розміром 30 Мб (це буде максимальним обсягом вкладень, які можна відправляти через веб-інтерфейс).

Перезавантажуємо php-fpm:

Налаштуємо nginx:

Додамо рядок до розділу http:

* даною установкою ми також дозволимо завантаження файлів розміром 30 Мб.

Перезапустимо nginx для застосування налаштування:

Тепер відкриваємо браузер і переходимо на адресу http://<IP-адреса сервера>/webmail/installer/. У самому низу натискаємо на кнопку Next. Якщо кнопка буде неактивною, перевіряємо, що немає помилок (NOT OK).

На наступній сторінці перевіряємо, що всі пункти перебувають у стані OK. Встановлення виконано.

Відкриваємо конфігураційний файл roundcube:

Забороняємо встановлення порталу:

Після видаляємо папку з настановними скриптами:

І заходимо в браузері за адресою http://<IP-адреса сервера>/webmail/. Вводимо як логін адресу пошти створеного користувача та його пароль.

 

8. Захищаємось від вірусів та СПАМу

 

Антивірус потребує багато ресурсів. Будьте готові, що після запуску сервер почне працювати повільніше і знадобиться додати ресурси.

Встановлення та налаштування Clamav + Amavisd

Встановлюємо необхідні для роботи антивірусу та антиспаму компоненти:

Додаємо користувача clamav до групи amavis:

Відкриваємо конфігураційний файл amavis:

Знімаємо коментарі для рядків:

* за замовчуванням amavis не виконуємо жодних перевірок – для включення сканування на віруси знімаємо коментар з bypass_virus_checks_maps, а для сканування на СПАМ – bypass_spam_checks_maps.

Потім відкриваємо на редагування:

Додамо рядки:

* Дані опції дозволять програмі Outlook без помилок відправляти тестове повідомлення.

Дозволяємо запуск антивірусу та amavis:

Перезапускаємо послуги:

Налаштування Postfix

Додаємо до postfix:

* де content_filter вказує на програму, яка буде сканувати повідомлення;

Тепер редагуємо master.cf:

Дописуємо наступне:

 

 

* Отже, даним налаштуванням ми створимо два допоміжні сервіси scan і 127.0.0.1:10025 (сервіс без імені, він просто слухатиме на порту 10025 – це порт за замовчуванням, на який відправляє повідомлення amavis після виконання перевірки). Також, ми використовуємо такі опції:

  • smtp_send_xforward_command — щоб надсилати повідомлення зі вихідним ім’ям клієнта та IP-адресою. У цьому прикладі, так.
  • smtp_enforce_tls – чи вимагати TLS.
  • content_filter — програма для сканування. У цьому прикладі сканування вимкнено.
  • receive_override_options перевизначає опції в main.cf. У нашому випадку no_unknown_recipient_checks відключає спроби з’ясувати, чи є одержувач невідомим; no_header_body_checks відключає перевірки заголовків та тала листів.
  • порожні значення для smtpd_helo_restrictions, smtpd_client_restrictions, smtpd_sender_restrictions відключають обмеження для цих опцій.
  • smtpd_recipient_restrictions — контролює відповідь Postfix на команду SMTP RCPT TO. Тут ми дозволяємо лише з’єднання від вузлів, перерахованих у моїх мережах.
  • mynetworks_style=host вказує postfix, що він повинен надсилати пошту тільки з локального комп’ютера.
  • smtpd_authorized_xforward_hosts вкаже, які віддалені клієнти можуть використовувати XFORWARD. У разі локальний комп’ютер.

Перезапускаємо postfix:

Налаштування оновлень антиспаму

Для оновлення бази антиспаму виконуємо команду:

Для налаштування автоматичного оновлення редагуємо cron:

* в даному прикладі, щодня о 03:30 запускатиметься процес оновлення антиспаму.


Перевірка

Для перевірки антивірусу надсилаємо повідомлення з таким вмістом:

Більшість поштових систем екранінують вірусну послідовність і лист нормально пройде повз наш антивірус. Щоб зробити коректний тест, необхідно надіслати листа командами SMTP.

Лист не повинен дійти, а в лозі (/var/log/maillog) ми побачимо рядок:

Для перевірки роботи контентного антиспаму надсилаємо листа з наступним вмістом:

У результаті лист не повинен прийти, а в логах ми побачимо:

 

Пересилання СПАМу та вірусів на іншу скриньку

Всі листи зі спамом та вірусами переміщатимуться до карантину. Якщо ми хочемо перенаправляти всі подібні повідомлення на спеціальну скриньку, необхідно налаштувати amavis.

Відкриваємо конфігураційний файл:

Додаємо такі опції:

* де $spam_quarantine_to вказуємо на адресу для перенаправлення СПАМ-листів; $virus_quarantine_to — пошта для листів із виявленими вірусами.

Після перезавантажимо amavis:

Пробуємо надіслати повідомлення з тестовими сигнатурами на СПАМ та вірус – листи мають бути перенаправлені на вказані адреси.


Антиспам засобами Postfix

 

У MTA Postfix вбудований механізм перевірки заголовків вхідних повідомлень. Правила розміщуються у 7 секцій, обробка яких виконується в наступному порядку:

client -> helo -> sender -> relay -> recipient -> data -> end_of_data

Щоб краще зрозуміти принцип, ми повинні знати SMTP-команди під час надсилання пошти. І так порядок, наступний:

  1. З’єднання із сервером.
  2. Команда HELO. Привітання, в якому відправник називає своє ім’я, за яким можна перевірити, чи воно відповідає правилам іменування і своїй IP-адресі.
  3. MAIL FROM – вказує адресу відправника. Виконується для sender та relay.
  4. RCPT TO – кому надсилаємо листа.
  5. DATA — команда повідомляє про готовність надіслати лист із заголовками та текстом.
  6. END-OF-DATA — надсилання листа.

Отже, для налаштування антиспаму відкриваємо конфігураційний файл main.cf:

Коментуємо рядок:

І додаємо:

 

 

* де параметри:
  1. smtpd_client_restrictions — Налаштування обмежень під час здійснення клієнтських з’єднань із поштовим сервером.
  2. smtpd_helo_restrictions – обмеження у контексті клієнтської команди HELO.
  3. smtpd_sender_restrictions – обмеження будуть застосовуватися під час виконання клієнтської команди MAIL FROM.
  4. smtpd_relay_restrictions — обмеження надсилання пошти в контексті клієнтської команди RCPT TO.
  5. smtpd_recipient_restrictions – обмеження в контексті клієнтської команди RCPT TO після пересилання (smtpd_relay_restrictions).
  6. smtpd_data_restrictions – обмеження будуть застосовуватися під час виконання команди DATA.
  7. smtpd_end_of_data_restrictions — обмеження для виконання команди END-OF-DATA.
… і значення для них:
  • permit_mynetworks – дозволяє всі адреси, перелічені в налаштуванні mynetworks.
  • permit_sasl_authenticated – дозволяє запити всіх успішно авторизованих клієнтів.
  • reject_unauth_pipelining — забороняє надсилання листів, які надсилаються заздалегідь (пропускаючи правильний ланцюжок сесії SMTP). reject_non_fqdn_sender — відхилити з’єднання, якщо адреса відправника вказана неправильно (відповідно до RFC).
  • reject_unknown_sender_domain — забороняє запит, якщо Postfix не є кінцевим пунктом призначення для адреси відправника, а домен MAIL FROM не має: довжини.
  • reject_non_fqdn_recipient — заборонити з’єднання, якщо адреса одержувача вказана неправильно (відповідно до RFC).
  • reject_unauth_destination — відхилити з’єднання, якщо лист не надсилається згідно з правилом relay_domains або сервер не є адресою призначення. Іншими словами, забороняє використання нашого сервера як Open relay.
  • reject_unknown_recipient_domain — відхилити запит, якщо Postfix не є кінцевим пунктом призначення для домену одержувача, а домен RCPT TO не має 1) DNS-запису MX та DNS-запису A або 2) невірно сформованого MX-запису, такого як запис з ім’ям хоста MX довжини.
  • reject_unverified_recipient — відхилити запит, якщо відомо, що пошта на адресу RCPT TO відхиляється або коли адреса одержувача недоступна.
  • permit – дозволяє з’єднання. Ставимо на кінець кожного блоку обмежень (якщо обмеження не спрацювали, то дозволяємо).
  * це більш менш м’які правила. Їх можна використовувати спочатку, поки тестуємо сервер. Для посилення захисту додаємо:

* де:

  • reject_unknown_client_hostname – перевіряє наявність PRT-запису відправника та наявність робочого А-запису у відповідність PTR.
  • reject_invalid_helo_hostname – перевіряє синтаксис HELO-вітання.
  • reject_non_fqdn_helo_hostname – вимагає правильного FQDN-імені під час HELO-вітання.
  • reject_unknown_helo_hostname – забороняє представлятися іменами, для яких немає запису А або MX.
  • reject_rbl_client – перевіряє наявність відправника у чорних списках.

* Докладніший опис опцій для захисту можна знайти на сторінці postfix.org/postconf.5.html.

Після внесення всіх правок, необхідне перезавантаження Postfix:

Навчання антиспаму

Ми встановили amavis, котрий перевіряє пошту на СПАМ засобами spamassassin. Останній без навчання, практично, марний. Синтаксис команди для навчання наступний:

Таким чином, перша команда вкаже spamassassin які листи є небажаними, а друга — не несуть рекламного характеру.

Хорошою практикою буде домовитися з користувачами про ручне розміщення небажаної пошти з СПАМ, що входять до папки. Тоді ми зможемо пройтися скриптом по всіх ящиках на сервері та навчати антиспам. Наприклад, такою командою:

* у даному прикладі ми сказали spamassassin знайти в каталогах користувачів папки Спам, Spam, Junk, Junk E-mail (дані каталоги є типовими для приміщення СПАМу) та провести навчання.

Щоб мінімізувати кількість помилкових спрацьовувань, необхідно проводити навчання із ключем –ham. У нашому прикладі ми надсилаємо всі небажані листи на скриньку spam. У такому разі необхідно вручну знаходити помилкові спрацьовування та переносити їх у спеціальну папку, наприклад Ham. Тоді команда для навчання буде такою:

Статистику навчання можна переглянути командою:

 

9. Надсилання пошти назовні

 

Для надсилання пошти на інші поштові сервери необхідно правильно налаштувати сервер, щоб листи не потрапляли до СПАМу. Щоб це зробити, виконуємо інструкції нижче.


Установки DNS для сервера

 

Багато поштових серверів роблять запити в систему доменних імен для перевірки легітимності поштового сервера, що надсилає пошту. При налаштуванні MTA дуже важливо правильно додати необхідні записи до DNS.

1. rDNS. Зворотна зона використовується для перевірки відповідності імені сервера у привітанні з ім’ям, яке повертає сервер NS при запиті по PTR-запису.

І так, для створення запису в зворотній зоні, необхідно написати листа Інтернет провайдеру, до мережі якого підключений сервер або хостеру, якщо поштовий сервер налаштований на VPS. IP-адреса нашого сервера повинна вести на ім’я, яким вітається наша postfix — можна подивитися командою:

Якщо ми отримаємо порожню відповідь, то вводимо:

Якщо і цей варіант не поверне відповідь, вводимо:

2. А-запис. Також необхідно, щоб ім’я сервера, яким представляється поштовий сервер, дозволялося в IP-адресу.

Для цього заходимо в консоль управління зоною нашого домену і створюємо запис типу А для зіставлення імені сервера з IP-адресою, на якій слухає запити на цей сервер.


Установки DNS для домену

 

Для кожного домену, для якого надсилатимемо пошту створюємо записи:

  1. SPF.
  2. DMARC.
  3. DKIM

Для перевірки коректності налаштування сервера скористаємося ресурсами:

https://www.mail-tester.com
https://spamtest.smtp.bz

 

10. Налаштування DKIM

 

Підпис листів не є обов’язковим, але допомагає не потрапляти до СПАМу. DKIM налаштовується для кожного домену, а також має створюватися спеціальний запис DNS. Розглянемо створення та налаштування DKIM в amavisd.

Створюємо каталог для зберігання ключів:

Генеруємо послідовність для нашого домену:

* де corp2.eu – домен, для якого ми згенеруємо підпис dkim.
 
Задаємо права на створений файл:
 

Відкриваємо конфігураційний файл amavisd:

Редагуємо запис:

* у цьому прикладі ми закоментували перший рядок і розкоментували другий. Це вкаже amavis, що він повинен запускатися та працювати на двох портах.
 
А також додамо:
 

Відкриваємо файл:

Додаємо записи:

* де corp2.eu – домен, для якого ми налаштовуємо dkim; /var/lib/dkim/corp2.eu.pem – шлях до згенерованого файлу з послідовністю.
 
Перезапускаємо amavis:
 

Подивитися послідовність DKIM для нового домену можна командою:

Ми повинні побачити щось на кшталт:

Тепер нам потрібно на основі цього висновку створити DNS запис TXT. У цьому прикладі, потрібно створити запис з іменем dkim._domainkey в зоні corp2.eu і значенням “v=DKIM1; p=MIGfMA0SD…wIDAQAB”.
 
Перевірити коректність налаштування DKIM можна за допомогою команди:
 
Переходимо до налаштування Postfix. Ми повинні додати відправку всіх вихідних листів на перевірку в amavis на порт 10026 та приймати назад листи на порт 10027.
 
Відкриваємо файл:
 

Відредагуємо submission та smtps, додавши content_filter:

І додамо:

Перезапускаємо postfix:
 

Налаштовуємо Roundcube:

 

Знаходимо рядки:

… і міняємо її на:

* у цьому прикладі ми вказали, що з’єднання для надсилання пошти має бути захищеним. Це важливо для нашої установки DKIM.
 
Пробуємо надіслати листа — у заголовках ми маємо побачити:
 

11. Налаштування квот

 
У PostfixAdmin у нас є можливість задати квоти на поштові скриньки, але вони не працюватимуть, оскільки про них нічого не знає Dovecot.
 
Процес налаштування не складний та описаний окремо у статті Налаштування квот у Dovecot + PostfixAdmin.
 
Після застосування квот ми зможемо спостерігати в поштовому клієнті Roundcube інформацію про дисковий простір, що залишився:

… або у Webmail Lite:

12. Автоматичне налаштування поштових клієнтів

 
Для автоматичного конфігурування поштових клієнтів потрібно настроїти сервіс autodiscover. Для цього налаштовуємо веб-сервер, який повертатиме поштові налаштування для домену.
 
Докладніше про процес налаштування описано у статті Налаштування Autodiscover для свого поштового сервера.
 

13. Папки російською в Outlook

 
За замовчуванням, всі поштові клієнти, крім Outlook, розпізнають службові папки IMAP:
 
  • Drafts – чернетки.
  • Junk – СПАМ.
  • Sent – надіслані.
  • Trash – віддалені.
Дані каталоги перекладаються російською мовою та коректно відображаються в клієнті. В Outlook ці папки відображаються як є англійською мовою.
 
Для вирішення проблеми ми маємо відкрити файл:
 

Знайти блок налаштувань namespace inbox. Для кожного зі службового каталогу налаштувати таке:

* і так, ми задали кілька варіантів службових каталогів:
 
  • Чернетки — на сервері можуть бути папки Чернетки та Drafts. За замовчуванням відображається та створюється Чернетки.
  • Спам – на сервері Спам, Junk, Spam, Junk E-mail.
  • Видалені — на сервері Видалені, Trash, Deleted Messages.
  • Надіслані — на сервері Надіслані, Sent, Sent Messages, Sent Items.
Для застосування налаштувань перезапускаємо dovecot:
 

14. Різне

 
Розглянемо додаткові параметри для нашого сервера.
 

Налаштування обмежень

 
Також важливо налаштувати деякі обмеження, наприклад:
 
максимальний розмір вкладення.
кількість повідомлень, яку можна надіслати за певний період часу.
налаштування черги (час зберігання листів).
таймаути відправлення.
Докладніше, інформацію можна знайти у статті Ліміти у Postfix.
 

Зміна email адреси

 
Припустимо, ми зробили помилку в написанні адреси електронної пошти, але не хочемо видаляти обліковий запис та створювати його за новою. Розглянемо зміну email-адреси з прикладу sekretar@corp2.eu -> secretar@corp2.eu.
 
Нам потрібно внести зміни до бази даних — для цього заходимо в оболонку sql:
 
Вводимо пароль, який створювали після встановлення СУБД.
 
Використовуємо базу postfix:
 

Редагуємо аліаси командою:

Редагуємо поштову скриньку:

І квоту:

З базою даних закінчили – виходимо з SQL:

Переходимо в каталог із поштовими скриньками користувачів для нашого домену:

Переміщуємо папку з поштою старої скриньки до нової:

Перевіряємо роботу через веб-інтерфейс. Якщо використовуємо поштового клієнта, змінюємо налаштування для використання нової email-адреси.
 

15. Можливі проблеми

 
Не підключатися до сервера IMAP в Outlook на старих системах Windows
При спробі підключення до сервера ми можемо побачити помилку «Неможливо встановити безпечне з’єднання з сервером IMAP».
 
Причина: у старих системах використовується за замовчуванням TLS 1.0, підтримка якого відсутня.
 
Рішення: необхідно виконати 3 дії.
 
1. Встановлюємо оновлення KB3140245.
 
2. Створюємо дві гілки реєстру:
 
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client
 
Це можна виконати вручну в утиліті regedit або ввести команди:
 

У створених гілках створюємо параметр DisabledByDefault з типом DWORD (32 біти) та значенням 0. Це можна виконати командами:

 

3. Перезавантажуємо комп’ютер.

 

Що таке SPF-запис

спеціальний TXT-запис у DNS, в якому зазначено з яких поштових серверів може бути надіслано пошту для домену. З її допомогою можна знизити загальну кількість СПАМу, зменшити ймовірність того, що домен буде скомпрометований та захиститись від СПАМу, який використовує поле зворотної адреси. Розшифровується як Sender Policy Framework чи інфраструктура політики відправника.
 
Синтаксис SPF-запису приблизно такий:
 
* де corp2.eu – домен, для якого налаштовується запис; v = spf1 – покажчик на те, що цей TXT-запис є SPF версії 1; a дозволяє або забороняє відправлення від IP-адреси, якій відповідає А-запис самого домену (у даному прикладі corp2.eu); mx дозволяє чи ні відправлення від IP-адрес записів MX для нашого домену; -all забороняє надсилання листів для всіх, хто не пройшов перевірку (якщо записати ~all дозволяти надсилання чи ні буде на вибір поштової системи). знак «+» дозволяє (може бути втрачений під час запису); знак “-” вказує на заборону.
 
Ще один приклад запису:
 
* тут ми прямо вказали IP-адресу, з якої можна надсилати пошту (ip4), а також все, що включено до запису _spf.mailsystem.net.
 
Також можна додавати підмережі:
 

А ось приклад з IPv6:

І конструкція з перенапрямком (Redirect):

* у цьому прикладі, ми використовуємо чужі налаштування, перенаправивши запити на _spf.mailsystem.net.
 
Перевірити правильність установки просто – потрібно надіслати повідомлення собі на пошту mail.ru, yandex.ru або gmail.com. Відкрити лист та подивитися заголовки: якщо бачимо Received-SPF: pass — SPF налаштована правильно.
 
SPF-запис не є єдиним засобом, що підтверджує легітимність поштового домену. Читайте також про DKIM і PTR, щоб мати уявлення про додаткові способи захисту доменів.
 

Що таке DMARC

 
політика обробки поштових повідомлень на основі SPF та DKIM. За допомогою неї адміністратор пошти може самостійно визначати, що робити із листами, які не пройшли доменну перевірку на чужих серверах. Таким чином, не поштова система робить вибір, як вчинити з «поганими» повідомленнями, а власник домену. Налаштовується шляхом створення запису TXT в DNS. Розшифровується як Domain-based Message Authentication, Reporting and Conformance.
 
Працює це так: лист перевіряється за SPF та DKIM. Якщо воно не проходить за одним із критеріїв перевірки, застосовується політика DMARC.
 
Схема роботи DMARC від Mail RU Group
 
Приклад простої політики DMARC наступний:
 
  • _dmarc.corp.eu – dmarc запис для домену corp2.eu.
  • v=DMARC1 йде як позначення, що запис txt відноситься до DMARC.
  • p – політика на домен. Приймаються такі варіанти: none – нічого не робити; quarantine – надіслати листа до СПАМу; reject – відкинути листа.
  • sp – політика на субдомени домену. Має такі самі значення, як і p.
  • pct – який відсоток повідомлень піде під правила.
  • fo — у яких випадках надсилати звіт. 0 – завжди якщо не пройдено жодного критерію перевірки; 1 – якщо не пройдено хоча б один критерій; d – не пройдено перевірку DKIM; s – не пройдено SPF.
  • rua – поштова адреса для звітів.
Оскільки налаштування виконується лише на сервері NS, немає значення, для якого поштового сервера її налаштовувати. DMARC працює для Postfix, Exim, Exchange та багатьох інших поштових систем. Безкоштовні поштові сервіси від Mail RU Group, Яндекс, Google і так далі підтримують політики DMARC, обробляючи повідомлення відповідно до настройок.
 
Докладніша інструкція щодо роботи з DMARC на datatracker.ietf.org. Для перевірки правильності налаштування політики можна скористатися сторонніми сервісами, наприклад, mxtoolbox.com.
 

Налаштування квот у Dovecot + PostfixAdmin

 

При установці поштового сервера на базі Postfix + Dovecot та використанні панелі керування поштовими скриньками PostfixAdmin, за замовчуванням, квотування не налаштоване – його можна задавати в останній, але квоти працювати не будуть. Потрібне додаткове налаштування…
 
Налаштовуємо квоти у Dovecot
Перевіряємо, що квоти працюють
Надсилаємо повідомлення користувачам
 

Налаштування Dovecot

 
Відкриваємо конфігураційний файл10-mail.conf:
 

Знаходимо рядок з mail_plugins і наводимо його до вигляду:

 
* Цей рядок підключає до плагінів додатково плагін для управління квотами (quota). Якщо опція закоментована, знімаємо коментар.
 
Відкриваємо конфігураційний файл 20-imap.conf:
 
* Опція mail_plugins може бути коментована. Якщо це так, то коментар знімаємо.
 
Відкриваємо конфігураційний файл 10-master.conf:
 

Знаходимо опцію service dict, в ній unix_listener dict і наводимо її до вигляду:

Відкриваємо файл 90-quota.conf:

Додаємо:

* або знімаємо коментар з відповідного рядка quota = dict:User quota::proxy::quota.
 
Відкриваємо основний конфігураційний файл для dovecot:
 

Знаходимо розділ dict і знімаємо коментар або додаємо:

Тепер створюємо файл для налаштування вивантаження квот:

* де host – сервер mysql, до якого будемо підключатися; dbname – ім’я бази даних, у якій знаходяться користувачі postfix; user – користувач, під яким ми підключаємось до бази; password – пароль для підключення до бази. У цьому прикладі ми підключимося до СУБД, яка знаходиться на тому ж сервері (localhost) до бази postfix під користувачем postfix з паролем postfix123.
 
Відкриємо наш файл, в якому ми описуємо налаштування вибірки даних з користувачів з бази даних:
 

Знаходимо запит user_query і дописуємо в SELECT CONCAT(‘*:bytes=’, quota) AS quota_rule – у мене вийшло:

* якщо в файлі запитів є кілька рядків user_query, то необхідно дописати запит для останньої.
 
Перевіряємо конфігураційний файл dovecot:
 

… і якщо команда не поверне помилку, перезапускаємо його:

Перевірка роботи квот


Для початку в командному рядку вводимо:

* user@domain.net – поштовий користувач, для якого потрібно показати квоту.
 
Ця команда відображає квоту для користувача, наприклад:
 
* У цьому прикладі поштова скринька займає близько 16 Мб, а квота близько 50 Мб – скриньку заповнений на 32%.
 
Тепер відкриваємо PostfixAdmin – заходимо в налаштування поштової скриньки та ставимо невеликий ліміт, наприклад, у 5 Мб:
Тепер обсяг ящика перевищує ліміт:
 
* Обсяг перевищений, майже, втричі.
 
Деякі поштові клієнти покажуть перевищення ліміту, наприклад Thunderbird:
 

Оповіщення при перевищенні квоти


Відкриваємо конфігураційний файл 90-quota.conf:
 

Знімаємо коментар або додаємо дані рядки:

* У цьому прикладі ми вказуємо на необхідність робити 2 попередження – перше при досягненні обсягу ящика в 80%, друге – 95%. Сервіс dovecot, який це забезпечуватиме, називається quota-warning.
 
Тепер знаходимо розділ service quota-warning і наводимо його до вигляду:
 
* ми створили сервіс quota-warning, який запускатиме прихований /usr/local/bin/quota-warning.sh.
 
Створюємо сам скрипт quota-warning.sh:
 
* де postmaster@corp2.eu – адміністративний поштовий ящик. Сам текст повідомлення можна перетворити, щоб воно було більш презентабельним.
 
Задаємо права на виконання скрипту:
 

Перевіряємо, що нам надходять повідомлення, запустивши скрипт:

* де user@domain.net — наша поштова скринька, на яку має відправитися повідомлення.
 
Перезапускаємо службу dovecot:
 

 

Налаштування Autodiscover для свого поштового сервера

 

Розберемо процес створення інфраструктури для автоматичного настроювання поштових клієнтів. Для коректної роботи Autodiscover потрібен комплексний підхід, оскільки різні поштові клієнти мають свої вимоги.
 
Для MS Outlook
Для Mozilla Thunderbird
Через SRV DNS
 

1. Microsoft Outlook

 
Для автоматичного налаштування поштового клієнта йде https POST-запит до документа autodiscover.xml. При цьому, Outlook спочатку спробує знайти сервер запису в DNS autodiscover.server.domain, потім просто до домену server.domain і потім – до SRV-запису _autodiscover._tcp.server.domain. Таким чином, необхідно настроїти DNS та веб-сервер.
 

DNS

 
З DNS все просто – створюємо А-(або CNAME-) та SRV-записи. Приклад таких записів у bind:
 

* де 111.111.111.111 — IP-адреса на наш веб-сервер, який повертатиме документ XML.

 
* де autodiscover.corp2.eu – наш запис autodiscover в домені corp2.eu.
 

Веб-сервер

 
Як приклад, налаштування виконаємо на веб-сервері NGINX, який працює на Linux. Якщо він не встановлений, виконуємо інсталяцію.
 
а) якщо сервер під CentOS/Red Hat:
 

б) якщо сервер під Debian/Ubuntu:

Після дозволяємо автозапуск і стартуємо сервіс:

Потім створюємо віртуальний домен:

* дане налаштування дозволить нашому серверу nginx приймати запити на 443 порту (https); як домашня директорія ми будемо використовувати каталог /usr/share/nginx/html/autodiscover, куди і помістимо потрібний нам XML; /etc/letsencrypt/live/corp2.eu/cert.pem та /etc/letsencrypt/live/corp2.eu/privkey.pem — шляхи до сертифікатів (у даному прикладі я використав сертифікати від Let’s encrypt — щоб їх отримати, читайте статтю Отримання безкоштовного SSL-сертифіката Let’s Encrypt). Оскільки NGINX забороняє POST-запити до статичних файлів, повертаючи помилку 405, ми її ігноруватимемо, замінюючи кодом 200.
 
Перевіряємо коректність налаштування:
 

Якщо помилок немає, перечитуємо конфіг:

Створюємо каталог, у якому буде наш XML:

Створимо сам XML:

* де з основних параметрів на потрібні:
 
  • Type — тип протоколу, використовуючи який ми будемо підключатися до поштової системи.
  • Server – сервер для підключення. Для кожного типу протоколу може бути заданий свій сервер або той самий.
  • Port – порт, на якому слухає сервіс. Як правило, для
    • IMAP: 143, 993.
    • POP: 110, 995.
    • SMTP: 25, 465, 587.
  • LoginName — це логін, який використовується для авторизації. Зазвичай відповідає адресі електронної пошти.
  • AuthRequired — вимога автентифікації користувача для підключення до сервісу.
  • DomainRequired – вимога використання домену для логіну авторизації. Необхідно, якщо сервер обслуговує мультидоменну систему.
  • SPA – безпечна перевірка пароля.
  • SSL — Використання SSL. Для портів 465, 993, 995.
  • Encryption – тип шифрування: SSL або TLS.
Відкриваємо браузер і переходимо за адресою https://autodiscover.corp2.eu/autodiscover/autodiscover.xml, де замість corp2.eu має бути Ваш домен. Ми маємо побачити наш XML.
 
Тепер відкриваємо MS Outlook та отримуємо автоматично налаштування для info@corp2.eu.
 

Всі адреси

 
Наш конфігураційний файл розрахований лише на налаштування однієї адреси. Тепер потрібно налаштувати його обслуговування будь-якого email. Для цього необхідно написати скрипт, наприклад, на php і трохи доналаштувати сервер.
 
PHP та php-fpm
Встановимо php і php-fpm, потім дозволяємо автозапуск php-fpm і стартуємо його:
 
а) якщо сервер під CentOS/Red Hat:
 

б) якщо сервер під Debian/Ubuntu:

* де 7.2 – версія встановленої php (перевіряється командою php -v).
 
Налаштуємо php-fpm
а) якщо сервер під CentOS/Red Hat:
 

б) якщо сервер під Debian/Ubuntu:

NGINX

Внесемо налаштування до нашого віртуального домену:

* ми додали обробку скриптів php за допомогою php-fpm.
 
Перезапускаємо наш сервер:
 

Готуємо скрипт
Створимо скрипт php:

Відкриваємо браузер і переходимо на адресу https://autodiscover.corp2.eu/autodiscover/autodiscover.php — повинен завантажитися XML-документ. У тегах LoginName має бути порожнім.
 

Переадресація з xml на php

 
Тепер налаштуємо, щоб наш веб-сервер перекладав запити xml на скрипт php. Відкриваємо налаштування нашого віртуального домену:
 

… і додамо:

Перезапускаємо nginx:

Відкриваємо браузер і переходимо на адресу https://autodiscover.dmosk.ru/autodiscover/autodiscover.xml – повинен завантажитися XML-документ. У тегах LoginName має бути порожнім. Значить, перенапрямок спрацював.
 
Тепер можна відкривати Outlook та перевіряти автонастройку для інших поштових скриньок.
 

2. Mozilla Thunderbird

 
Механізм автоналаштування від Mozilla схожий на Microsoft. Необхідні налаштування повинні бути надані веб-сервером у вигляді XML-документа. Однак запит не є https, а http; і не POST, а GET. Також звернення йде спочатку у форматі server.domain/mail/config-v1.1.xml?emailaddress=user@server.domain, і якщо відповіді не буде отримано — autoconfig.server.domain/mail/config-v1.1.xml ?emailaddress=user@server.domain.
 
Також, як із Outlook, необхідно налаштувати DNS та веб-сервер.
 

DNS

 
створюємо А-запис (або CNAME). Приклад bind:
 
* де 111.111.111.111 — IP-адреса на наш веб-сервер, який повертатиме документ XML.
 
Веб-сервер
Настроюючи autodiscovery для Microsoft, ми вже налаштували веб-сервер NGINX. Тепер потрібно додати віртуальний домен та створити відповідний документ.
 
Відкриємо вже створений файл конфігурації:
 

… і додамо до нього:

Створюємо каталог для зберігання XML:

Створюємо документ: