Для почтового сервера будем использовать связку Postfix и Dovecot.
Их будем настраивать как в составе пакета iRedmail, так и самостоятельно(to do)
Проверка того, что порты 25, 465 не закрыты провайдером
telnet smtp.yandex.ru 25
telnet smtp.yandex.ru 465
Установка имени хоста почтового сервера
sudo hostnamectl set-hostname mail-server.domain.com
либо можно отредактировать файл /etc/hostname, вписав в него значение mail-server.domain.com
Также редактируем файл /etc/hosts, внося в него строчку:
127.0.0.1 mail-server.domain.com localhost
Проверим имя сервера командой hostname -f
Установка статического адреса для почтового сервера
При перезагрузке наша виртуальная машина Debian 10 получет почему-то адрес по DHCP при явном задании статического адреса чере wicd, что создавало проблему. Удаляем данный пакет и зададим явно статический IP-адрес нашему серверу:
auto eth0
iface eth0 inet static
address 7.7.7.7
netmask 255.255.255.0
network 7.7.7.0
broadcast 7.7.7.255
dns-nameservers x.x.x.x y.y.y.y
в файле /etc/network/interfaces
После чего выполняем команду /etc/init.d/networking restart
Получение и установка почтового сервера iRedmail
Воспользуемся детальным описанием отсюда: https://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server (iRedmail)
wget https://github.com/iredmail/iRedMail/archive/1.4.0.tar.gz
tar xvf 1.4.0.tar.gz
cd iRedMail-1.4.0/
chmod +x iRedMail.sh
sudo bash iRedMail.sh
sudo shutdown -r now
После установки административный интерфейс почты доступен по адресу:
https://mail-server.domain.com/iredadmin/
postmaster@domain.com - логин администратора, который задается в процессе установки.
Установка Let’s Encrypt TLS-сертификата для nginx
Чтобы при входе через веб-интерфейс пользователи не видели предупреждения, нужно установить сертификат для веб-сервера
sudo apt install certbot
sudo certbot certonly --webroot --agree-tos --email you@example.com -d mail-server.com -w /var/www/html/
В процессе установки отвечаем n на предложение отдать почтовый адрес в некую общую базу.
Важно! Если наш почтовый сервер находится за NAT-ом, то необходимо сделать netmap для портов 80 и 443 одновременно, чтобы вышеуказанная команда завершилась успешно. После получения сертификата закрываем ненужный 80-ый порт.
Далее необходимо установить полученный сертификат
Открываем файл под правами администратора
/etc/nginx/templates/ssl.tmpl
и комментируем в нем 2 строчки:
#ssl_certificate /etc/ssl/certs/iRedMail.crt;
#ssl_certificate_key /etc/ssl/private/iRedMail.key;
вставляя вместо них следующие от letsencrypt
ssl_certificate /etc/letsencrypt/live/mail-server.domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mail-server.domain.com/privkey.pem;
sudo nginx -t -тестируем конфигурацию nginx
/etc/init.d/nginx restart
Установка TLS-сертификата в Postfix и Dovecot
Также нам необходимо сконфигурировать Postfix SMTP сервер и Dovecot IMAP сервер для использования выданных сертификатов Let’s Encrypt, чтобы десктопные клиентские программы не выдавали предупреждений безопасности. Для этого отредактируем конфигурационный файл Postfix:
/etc/postfix/main.cf
Находим следующие 3 строки(номер строки - 95, 96, 97)
smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
smtpd_tls_cert_file = /etc/ssl/certs/iRedMail.crt
smtpd_tls_CAfile = /etc/ssl/certs/iRedMail.crt
и заменяем их на
smtpd_tls_key_file = /etc/letsencrypt/live/mail-server.domain.com/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/mail-server.domain.com/cert.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/mail-server.domain.com/chain.pem
Сохраняем файл и перезагружаем Postfix
sudo systemctl reload postfix
Далее редактируем главный конфигурационный файл Dovecot:
/etc/dovecot/dovecot.conf
Находим в нем следующих 2 строки(line 47, 48):
ssl_cert = </etc/ssl/certs/iRedMail.crt
ssl_key = </etc/ssl/private/iRedMail.key
и заменяем их на
ssl_cert = </etc/letsencrypt/live/mail.your-domain.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.your-domain.com/privkey.pem
Сохраняем файл и перезагружаем Dovecot.
sudo systemctl reload dovecot
C этого момента клиенты в классических приложениях не будут видеть предупреждения о безопасности.
Отключение Greylisting-а
По умолчанию iRedMail имеет включенный greylisting. Это улучшает фильтрацию спама, но вносит задержку в получение писем от новых серверов-отправителей.
В файле /opt/iredapd/settings.py file находим следующую линию
plugins = ["reject_null_sender", "wblist_rdns", "reject_sender_login_mismatch", "greylisting", "throttle", "amavisd_wblist", "sql_alias_access_policy"]
и удаляем "greylisting" из списка, сохраняем файл, и делаем рестарт iredapd.
sudo systemctl restart iredapd
Включение порта 465
Некоторые дубовые клиенты вынуждают нас использовать не рекомендованный способ аутентификации SMTPS по 465 порту, что по умолчанию выключено в Postfix. Включение порта описано ниже.
https://www.linuxbabe.com/mail-server/enable-smtps-port-465-postfix
https://docs.iredmail.org/enable.smtps.html#how-to-enable-smtps
Чтобы решить данную проблему, в конце файла /etc/postfix/master.cf добавляем строки:
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026
Важно!!!
Вносим строчку в файл /etc/nftables.conf
tcp dport 465 accept
Далее делаем рестарт системы, iptables, как видим, в данном случае не задействован.
Чтобы сторонние сервисы не трактовали вашу почту как спам, следует задать записи MX, PTR, SPF, DKIM и DMARC
https://toolbox.googleapps.com/apps/dig/ - проверка DNS-записей
https://powerdmarc.com/power-dmarc-toolbox/ - инструмент для проверки записей
MX-запись
MX-запись - имя почтового сервера, обслуживающего домен (например: mail-server.domain.com) для домена domain.com. Для mail-server.domain.com также нужно сделать A-запись, по которой будет определяться IP-адрес(недопустимо вместо A-записи использовать CNAME). Одним из параметров записи является приоритет, он имеет значение, когда домен обслуживают несколько почтовых серверов и установка соединения с почтовыми серверами домена осуществляется в соответствии с ним. При отправке почты сервер-отправитель запрашивает у DNS MX-записи домена-получателя, В итоге запроса возвращается список имён хостов почтовых серверов, принимающих входящую почту для данного домена. Далее сервер-отправитель пытается установить ESMTP-соединение с этими хостами с учетом приоритета для отправки почты.
Просмотр MX-записи в Linux и Windows:
host -t mx google.com.
nslookup -type=mx google.com
Примечание.
Имя почтового сервера необязательно должно быть поддоменом для нашего почтового домена. Доменные имена почтового сервера и почтового домена могут быть совершенно разными.
PTR-запись
В PTR-записи фигурирует доменное имя почтового сервера, указанное в mx записи нашего домена.
Например, на если наш почтовый сервер доступен по адресу 7.7.7.7, то для данного IP адреса в PTR-прописывается имя mail-server.domain.com.
У
SPF-запись
(С) https://ru.wikipedia.org/wiki/Sender_Policy_Framework
domain.com. IN TXT "v=spf1 +a +mx -all"
"+" является квалификатором по умолчанию, поэтому его можно не указывать:
domain.com. IN TXT "v=spf1 a mx -all"
"a" разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для domain.com;
"mx" разрешает приём писем, если отправляющий узел указан в одной из MX-записей для domain.com, например, с узла mail-server.domain.com. Таким образом, часто употребляемое +a +mx = разрешению принятия писем с IP-адресов узлов domain.com и mail-server.domain.com, которые, естественно, могут различаться.
Строка завершается "-all" - указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов(а или mx), следует отвергать(HardFail). Также может использоваться "~all" — в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).
DKIM-запись
DKIM - DomainKeys Identified Mail - один из механизмов борьбы со спамом. Почтовому сообщению присваивается ЭЦП, которая подтверждает отправителя и гарантирует, что подписанная часть не была изменена. DKIM-ключ генерируется для определенного домена в виде пары ключей - открытого и закрытого. При помощи закрытого ключа SMTP-сервер формирует ЭЦП для сообщения, эта ЭЦП передается в заголовке "DKIM-Signature" и содержит в себе информацию о домене отправителя. Открытый ключ вносится в txt-поле DNS-записи. При проверке заголовка сообщения "DKIM-Signature" извлекается домен, хранящийся в теге "d=", далее получается значение открытого ключа для указанного домена и производится проверка ЭЦП.
При установке iRedMail автоматически конфигурируется механизм DKIM для почтового сервера. Единственное, что остается - это внести публичный ключ DKIM в соответствующую TXT-запись DNS. Чтобы получить публичный ключ запустим следующую команду:
# amavisd-new showkeys
Публичный ключ DKIM заключен в кавычки. Нужно скопировать его в одну строку, удалив символы переноса и двойные кавычки. Далее в DNS редакторе нужно создать TXT-запись, где в поле "имя" ввести значение dkim._domainkey, а в поле "значение" - наш публичный ключ со строкой "v=DKIM1;p=" перед ним:
v=DKIM1;p=QUF12312phQzF5YzJFQWEW213213FCQUFBQWdRQ0pYK3YyVUp1cHJ6MUJydWx1ZittOGlDY1l2bUEyNG5pdHUxWXJPa1phNUJiWExpd1NQVEFSUzRROHpZNDl3OFRuL3l6WmVie
Для домена второго уровня(текущего домена) в редакторе DNS в поле "имя"("домен") вносится dkim._domainkey
Для домена третего уровня(поддомена) 3level.domain.com в поле "имя"("домен") вносится запись dkim._domainkey.3level
После внесения DKIM-записи в DNS можно проверить корректность её внесения:
# amavisd-new testkeys
DMARC-запись
https://ru.wikipedia.org/wiki/DMARC
DMARC - Domain-based Message Authentication, Reporting and Conformance - аутентификация сообщений, отчетность и соответствие на основе доменного имени. DMARC устанавливает стандарт для идентификации электронных сообщений принимающими узлами с использованием механизмов SPF и DKIM. DMARC предусматривает механизм для обмена информацией между отправителем и получателем о качестве фильтрации спама и фишинговых атаках. Если вы представляете домен-отправитель почты и публикуете DMARC-запись с запросом информации, то вы можете получать от всех доменов-получателей, которые тоже поддерживают DMARC, статистику обо всех почтовых письмах, которые приходят с обратным адресом от вашего домена. Политика DMARC позволяет владельцу домена указывать, что электронные письма из его / ее домена защищены SPF и DKIM, а также, что делать с письмами, которые не прошли проверки SPF/DKIM. Пример DMARC-записи.
v=DMARC1; p=none; pct=100; rua=mailto:dmarc@domain.com
v = MARC1: версия протокола - DMARC1.
p = none: политика для домена.
pct = 100: процент писем из вашего домена, к которому применяется политика DMARC.
rua - URI отчета для сводного отчета. Адрес электронной почты используется для указания получающих почтовых серверов, куда следует отправлять отчет. Указанный почтовый ящик должен существовать на почтовом сервере.
Три политики DMARC:
none: указывает получающим почтовым серверам не делать ничего особенного в случае сбоя проверки DMARC.
quarantine: указывает принимающему почтовому серверу, чтобы он поместил письмо в папку для спама, если проверка DMARC не удалась.
reject: указывает получающим почтовым серверам отклонять электронное письмо, если проверка DMARC не удалась.
Чтобы создать запись DMARC, DNS и необходимо добавить запись TXT.
Для домена второго уровня(текущего домена) в редакторе DNS в поле "имя"("домен") вносится _dmarc.
Для домена третего уровня(поддомена) 3level.domain.com в поле "имя"("домен") вносится запись _dmarc.3level
В поле значения вводим следующее: v=DMARC1; p=none; pct=100; rua=mailto:postmaster@3level.domain.com
Проверка корректности настроек почтового сервера
Проверку будем проводить при помощи mail-tester.com
Итоги проверки для нашего почтового сервера со всеми вышеуказанными корректно внесенными DNS-записями отображены на рис.
Если наш почтовый сервер находится внутри локальной сети за роутером(NAT), то необходимо прописать некоторые правила для него, чтобы наш почтовый сервер мог взаимодействовать с внешним миром и клиентами внутри сети, обращающимися к нему по доменному имени.
Настройка сетевого экрана для входящих почтовых сообщений
Для того, чтобы сервер принимал сообщения, нужно сделать mapping для 25 порта. Средствами Mikrotik это делается так:
Chain: dstnat; Protocol: tcp; Dst.port: 25; In. Interface: <наш интерфейс>; Action: netmap; To Address: 192.168.xx.yy(наш MTA); To Ports: 25
Невозможность клиента соединиться с сервером по доменному имени
Доменное имя разрешается во внешний адрес, а для доступа к нужным портам со внешнего адреса нужно делать их mapping, что не очень правильно. Второй вариант - прописать в hosts запись вида:
192.168.xxx.yyy mail.your-domain.com
Третий вариант - настроить внутренний DNS(не выполнялось).
Данную проблему решим следующим образом, создав 2 правила.
Правило 1:
Chain: dstnat
Src. Address: 192.168.xx.0/24 (локальные клиенты)
Dst. Address: 7.7.7.7 (внешний адрес нашей сети)
Protocol: tcp
Action: dst-nat
To Address: 192.168.xx.yy(наш MTA)
Правило 2:
Chain: srcnat
Src. Address: 192.168.xx.0/24 (локальные клиенты)
Dst. Address: 192.168.xx.yy (локальный адрес нашего MTA)
Protocol: tcp
Action: masquerade
Доступ к почтовому серверу извне
https://docs.iredmail.org/#mua
Традиционный клиент(ThunderBird)
POP3: порт 110 со STARTTLS (рекомендовано) или port 995 with SSL
IMAP: порт 143 со STARTTLS (рекомендовано) или port 993 with SSL ESMTP: порт 587 со STARTTLS(рекомендовано)
Если необходима поддержка старых почтовых клиентов с SMTP поверх SSL (порт 465), см раздел выше.
Дубовый клиент 1С:
Важно!!!
ThunderBird для Яндекс.Почты настраивается штатно по интрукции от Яндекс. Нужно иметь в виду, что на аккаунте Яндекс.Почты может быть включен и задан "пароль стороннего приложения". В этом случае для аутентификации необходимо использовать этот "пароль стороннего приложения", который не совпадает с паролем для Яндекс.ID. Пароль Яндекс.ID не подойдет для аутентификации.