Postfixadmin на centos 7. установка и настройка веб-интерфейса для управления postfix

Введение

Если у вас еще нет почтового сервера, то читайте как установить и настроить почтовый сервер postfix, а если нет сервера мониторинга, то соответственно вот это — установка и настройка zabbix на centos или то же самое на debian. Для мониторинга я буду использовать известную утилиту pflogsumm, которая анализирует почтовый лог postfix. В разных системах он может называться по-разному:

/var/log/mail.log в debian и ubuntu
/var/log/maillog в centos и freebsd

Само содержание будет одно и то же, поэтому статья будет актуальна для любого сервера с postfix и любой версией мониторинга zabbix. Я за основу возьму bash скрипт, который чаще всего попадается, если в поисковике поискать что-то на тему мониторинга postfix в заббиксе. Не знаю, кто у кого его скопировал изначально, поэтому автора указывать не буду. Сам скрипт достаточно простой, я расскажу подробно что он делает и как работает, чтобы вы понимали и по возможности могли его изменить так, как вам потребуется.

Я буду показывать на примере системы CentOS. Нам понадобится установить утилиту pflogsumm. Делается это просто.

# yum install postfix-pflogsumm

Настройка IP и DNS

Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR

Это основные требования для запуска собственного почтового сервера.

Публичный статический IP-адресIP-адрес почтового сервера должен быть общедоступным и постоянным во времени. Убедиться в этом можно у хостинг или Интернет-провайдера.
Доменное имя указывает на IPDNS-запись публичного доменного имени почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS провайдера доменного имени.
IP указывает на доменное имяСамое главное, обратная DNS-запись (именуемая PTR) должна указывать на доменное имя почтового сервера по IP-адресу. Можно попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его. Его можно легко проверить по IP-адресу онлайн (например, тут), или с помощью команды ‘nslookup’ в Windows и команды ‘host’ в системах на основе UNIX.

Настройка MX записи в DNS

Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.

Например, если наш домен — mycompany.com, почтовый сервер — mail.mycompany.com, то запись DNS для mycompany.com будет:

Type	Host	Value	Priority	TTL
MX	@	mail.mycompany.com	10	1 min

где:

Priority (приоритет) используется, когда в домене более одного почтового сервера.
TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при отладке настроек.

Настройка DKIM записи в DNS

Почта, идентифицированная ключами домена (DKIM) — это протокол безопасности электронной почты, который прикрепляет зашифрованную цифровую подпись к электронному письму. Принимающий сервер проверяет его с помощью открытого ключа, чтобы убедиться, что электронное письмо не было подделано.

Понадобятся приватный и открытый ключи. Их можно создать с помощью онлайн-инструментов, например Power DMARC Toolbox — DKIM Record Generator, или с помощью команд OpenSSL (приведен пример для Windows):

Создать приватный ключopenssl.exe genrsa -out private.key 2048
Создать публичный ключ из приватногоopenssl.exe rsa -in private.key -pubout -outform der 2>nul | openssl base64 -A > public.key.txt

И запись DNS будет выглядеть так:

Type	Host	Value	TTL
TXT	selector._domainkey	v=DKIM1; k=rsa; p=public_key	1 min

где:

selector — самостоятельно выбранный идентификатор (например, mysrv), который будет использоваться в приложении почтового сервера (смотрите ниже).
public_key — открытый ключ, закодированный алгоритмом base64 (содержимое public.key.txt).
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Настройка SPF записи в DNS

Инфраструктура политики отправителя (SPF) — это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.

Тут запись DNS будет выглядеть так:

Type	Host	Value	TTL
TXT	@	v=spf1 a mx include:relayer_name -all	1 min

где:

relayer_name — имя необязательного внешнего почтового сервера-ретранслятора (смотрите ниже). Если не нужно — убирается вместе с «include:».
TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Можно использовать удобный онлайн-генератор записи SPF.

Дополнительные записи DNS

Некоторые поля не обязательны, но желательно иметь.

DMARCЗапись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.
BIMIИндикаторы бренда для идентификации сообщений (BIMI) — это новый стандарт, созданный для того, чтобы упростить отображение логотипа рядом с сообщением. Кроме того, BIMI предназначен для предотвращения мошеннических электронных писем и улучшения доставки.
TLS-RPTTLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.
MTA-STSСтрогая транспортная безопасность агента пересылки почты (MTA-STS) — это новый стандарт, направленный на повышение безопасности SMTP, позволяя доменным именам выбирать строгий режим безопасности транспортного уровня, требующий аутентификации и шифрования.

Все эти записи кроме MTA-STS могут быть созданы с помощью Power DMARC Toolbox. Конфигурация MTA-STS похожа на , также описывалась на habr, и, наконец, может быть проверена с помощью Hardenize.

Настройка аутентификации на Postfix

Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.

а) если используем Ubuntu / Debian:

apt-get update

apt-get install postfix dovecot-imapd dovecot-pop3d

б) если используем CentOS / Red Hat:

yum install postfix dovecot

После установки пакетов, разрешаем автозапуск dovecot и postfix:

systemctl enable postfix dovecot

Открываем на редактирование конфигурационный файл нашего MTA Postfix:

vi /etc/postfix/main.cf

Добавляем строки (или меняем значения):

smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination

* где:

smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
- permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
- permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
- reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.

Проверяем корректность настройки:

postconf > /dev/null

Если команда не вернула ошибок, перезапускаем Postfix:

systemctl restart postfix

Переходим к настройке dovecot — открываем файл:

vi /etc/dovecot/conf.d/10-master.conf

… и приводим опцию service auth к следующему виду:

service auth {
…
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
…
}

* если соответствующей секции unix_listener нет, то ее нужно создать

Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth

Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):

vi /etc/dovecot/conf.d/10-ssl.conf

Проверяем, чтобы значение ssl не было required:

ssl = yes

* нас устроит оба варианта — yes или no.

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

* данные механизмы позволяют передачу данных в открытом виде.

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

Если команда ничего не вернула, перезапускаем сервис:

systemctl restart dovecot

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

useradd smtptest

passwd smtptest

Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:

Пробуем отправить письмо. Отправка должна потребовать ввода логина и пароль — используем аутентификационные данные для записи, созданной выше.

Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.

Подключение LDAP

И так, наш сервер требует ввода логина и пароля от системных учетных записей для отправки писем. Теперь сделаем так, чтобы эти учетные записи брались из LDAP (на примере Active Directory).

В службе каталогов нам нужна учетная запись со стандартными правами — ее мы будем использовать для подключения к LDAP. Создаем служебную учетную запись, например, postfix в корневом контейнере Users. Таким образом, в моем примере, это будет запись cn=postfix,cn=Users,dc=dmosk,dc=local (в домене dmosk.local).

Теперь возвращаемся на наш сервер. Если у нас Debian/Ubuntu, необходимо установить пакет dovecot-ldap:

apt-get install dovecot-ldap

Открываем файл:

vi /etc/dovecot/dovecot-ldap.conf.ext

* в системах deb файл уже будет создан и в нем будут приведены примеры настройки; в системах RPM файл будет создан новый файл.

Добавляем в него следующее:

hosts = dmosk.local
ldap_version = 3
auth_bind = yes
dn = cn=postfix,cn=Users,dc=dmosk,dc=local
dnpass = ldap-password-for-postfix
base = ou=Пользователи,dc=dmosk,dc=local
scope = subtree
deref = never
pass_filter = (&(objectCategory=Person)(sAMAccountName=%n))
user_filter = (&(objectCategory=Person)(sAMAccountName=%n))

* где:

hosts — имя нашего сервера ldap (в моем примере указан домен, так как по нему у меня разрешается кластер LDAP).
ldap_version — версия ldap. Как правило, третья.
auth_bind — указываем, нужно ли выполнять аутентификацию при связывании с LDAP.
dn — учетная запись для прохождения авторизации при связывании со службой каталогов.
dnpass — пароль от записи для прохождения авторизации.
base — базовый контейнер, в котором мы ищем наших пользователей. Нельзя использовать поиск на уровне домена. Внимательнее проверяем путь на предмет использования контейнеров (CN) или организационных юнитов (OU).
scope — указывает на каком уровне нужно искать пользователей:
- subtree — во всех вложенных контейнерах.
- onelevel — во всех вложенных контейнерах, но на один уровень.
- base — только в контейнере, который указан в base.
deref — параметр означает использование поиска по разыменованным псевдонимам. К сожалению, не нашел подробного описания. Обычно, не используется.
pass_filter — фильтр для поиска паролей пользователей. Его формат зависит от используемой реализации LDAP. В нашем примере это Active Directory.
user_filter — фильтр для поиска учетных записей пользователей. Формат зависит от того, какую реализацию для LDAP мы используем.

Не знаю причину, но если для base указать корневой путь к домену, например, dc=dmosk,dc=local, наша связка не будет работать, а система вернет ошибку … failed: Operations error.

Открываем файл:

vi /etc/dovecot/conf.d/10-auth.conf

Комментируем строку для использования аутентификации по системных учетных записям и снимаем комментарий для аутентификации в ldap. Получим следующий результат:

#!include auth-system.conf.ext
…
!include auth-ldap.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

И перезапускаем его:

systemctl restart dovecot

Возвращаемся к настроенному почтовому клиенту и меняем параметры для авторизации с smtptest на учетную запись из домена, например, [email protected]. Проверяем отправку письма — системы должна запросить пароль и отправить письмо при успешной проверке пользователя.

Можно переходить к настройке почтовых ящиков для пользователей из LDAP.

Установка почтового клиента

Поздравляем! Postfix и Cyrus успешно установлены на VPS. Тем не менее, обе эти программы занимаются обработкой электронной почты, а не ее отправкой. Средство отправки сообщений можно быстро установить с помощью командной строки.

Есть множество клиентов, которые можно использовать; для примера подключимся с помощью MailX

Получив подтверждение запроса, mailx закончит установку.

Чтоб отправить сообщение, введите в терминал следующую команду, заменяя mail почтовым адресом адресата.

Терминал запросит предметную строку. Введя тему, нажмите клавишу ввода. В следующие строки введите сообщение. Оно будет отправлено только после нажатия клавиши Enter и точки.

Сообщение выглядит примерно так:

Поздравляем! Теперь на сервере установлен postfix и запущена электронная почта. Сервер полностью готов к отправке электронных сообщений.

CentOSCyrusPostfix

Создание сертификата и настройка домена

Для создания сертификата можно воспользоваться бесплатным онлайн инструментом на сайте dkimcore.org. Однако, в данном примере, мы воспользуемся opendkim-genkey и сформируем его самостоятельно. Мы будем работать с доменом dmosk.ru (Вам необходимо его заменить своим).

И так, создаем каталог для размещения ключей домена:

mkdir -p /etc/opendkim/dmosk.ru

И генерируем их следующей командой:

opendkim-genkey -D /etc/opendkim/dmosk.ru/ —domain dmosk.ru —selector relay

* где dmosk.ru — домен, с которого будет отправляться почта: relay — имя селектора (селектор — это строковый идентификатор, он может быть любым).

В папке /etc/opendkim/dmosk.ru должно появиться два файла с расширениями .private и .txt. Первый — закрытый ключ (храним его у себя на сервере), второй — готовая txt-запись для DNS.

Создадим пользователя opendkim.

FreeBSD:

pw useradd opendkim -m -s /usr/sbin/nologin -w no

Linux (Ubuntu, CentOS):

useradd opendkim -m -s /sbin/nologin

* мы можем получить ошибку useradd: user ‘opendkim’ already exists — это значит, что пользователь уже создан. Просто продолжаем настройку.

После создания пользователя, задаем группу владельца opendkim для созданных ключей:

chown :opendkim /etc/opendkim/dmosk.ru/*

Если система выдаст ошибку, что группы opendkim не существует (chown: opendkim: illegal group name), необходимо сначала создать учетную запись.

Задаем права для группы владельца:

chmod g+rw /etc/opendkim/dmosk.ru/*

Открываем созданный нами ранее TrustedHosts:

vi /etc/opendkim/TrustedHosts

И добавим следующее:

…
*.dmosk.ru

* где dmosk.ru — почтовый домен.

Создаем таблицу KeyTable. В ней хранится список соответствий между селекторами, доменами и файлами с закрытыми ключами. Формат записей:<селектор>._domainkey.<домен> <домен>:<селектор>:<путь к закрытому ключу>

vi /etc/opendkim/KeyTable

И в соответствии с форматом приводим его к нужному виду:

relay._domainkey.dmosk.ru dmosk.ru:relay:/etc/opendkim/dmosk.ru/relay.private

vi /etc/opendkim/SigningTable

И приводим к такому виду:

*@dmosk.ru relay._domainkey.dmosk.ru

Перезапускаем opendkim:

service opendkim restart

или:

systemctl restart opendkim

Установка и настройка PostfixAdmin

Сначала скачиваем последнюю версию postfixadmin:

wget https://sourceforge.net/projects/postfixadmin/files/latest/download -O postfixadmin.tar.gz

* если система вернет ошибку, установите wget — yum install wget.

Распаковываем скачанный архив в директорию с порталом:

tar -C /var/www/html -xvf postfixadmin.tar.gz

* где /var/www/html — каталог по умолчанию для хранения сайтов в Apache.

Переименовываем распакованную папку (убираем указание на версию), чтобы было удобнее вводить URL-адрес:

mv /var/www/html/postfixadmin-3.0.2 /var/www/html/postfixadmin

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

chown -R apache:apache /var/www/html/postfixadmin

* в данном примере, в качестве веб-сервера используется Apache, который по умолчанию запускается от пользователя apache, поэтому мы и задаем его в качестве владельца.

Создаем базу данных postfix и учетную запись в mariadb:

mysql -u root -p

CREATE DATABASE postfix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* где postfix — имя базы.

GRANT ALL ON postfix.* TO ‘postfix’@’localhost’ IDENTIFIED BY ‘postfix123’;

* где postfix — имя учетной записи; postfix123 — пароль; localhost разрешает подключение только с локального сервера.

Выходим из командной оболочки MariaDB:

Открываем конфигурационный файл postfixadmin:

vi /var/www/html/postfixadmin/config.inc.php

И редактируем следующее:

Запускаем браузер и вводим адрес http://<IP-адрес сервера>/postfixadmin/setup.php

Начнется процесс проверки конфигурации и установки портала PostfixAdmin. После ее окончания вводим дважды пароль и генерируем хэш:

После перезагрузки страницы копируем хэш:

Открываем конфигурационный файл и редактируем следующее:

vi /var/www/html/postfixadmin/config.inc.php

$CONF = ‘7a8e14…c26’;

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

В итоге мы увидим следующее:

И переходим в браузере на страницу http://<IP-адрес сервера>/postfixadmin/

Вводим логин и пароль для созданного пользователя.

Готово.

Настройка DNS

Смотрим содержимое файла txt, который был сформирован при генерировании сертификата для домена:

cat /etc/opendkim/dmosk.ru/relay.txt

* где dmosk.ru — домен, для которого производилась настройка.

И используя данное содержимое, в панели управления нашим DNS создаем TXT-запись следующего формата:

relay._domainkey IN TXT «v=DKIM1; k=rsa; p=MIGfMA0GCSqG…rhyaj8OcbwIDAQAB»

* где relay — название нашего селектора MIGfMA0GCSqG…rhyaj8OcbwIDAQAB — сокращенная запись открытого ключа (она длиннее).

Дополнительные необязательные записи

_domainkey IN TXT «o=~; [email protected]»

* где o=~ означает, что не все сообщения подписываются для домена (o=- — говорит, что все письма используют DKIM).

_adsp._domainkey IN TXT «dkim=all»

* all запрещает принимать письма от домена без цифровой подписи. Другие варианты: discardable — блокировать сообщения на стороне получателя, unknown — по умолчанию (такую запись создавать не обязательно).

Завершение установки Postfix

После того, как все необходимые конфигурации были внесены, настройка postfix почти завершена.

Для предотвращения ошибок необходимо выполнить следующих 2 действия.

В строке virtual_alias_maps = hash:/etc/postfix/virtual в конфигурационный файл были внесены виртуальные псевдонимы; теперь нужно создать эту базу данных.

Откройте файл

Удалите из файла весь текст, затем только внесите следующую строку, заменяя user настоящим именем пользователя, а example.com – правильным доменом:

Затем нужно сохранить и выйти.

Далее введите в терминал:

Это вернет виртуальный файл в таблицу поиска, создавая базу данных, необходимую для работы postfix.

В завершение используйте команду, которая создаст новый файл, необходимый postfix перед отправкой.

После того как все вышеописанные действия были исполнены, нужно отконфигурировать Cyrus.

Добавление новых записей dkim

Разберем процесс добавления дополнительных записей dkim. Чтобы работать было удобнее и быстрее, в консоли создадим переменную, значением которой должен быть наш домен:

DKIM_DOMAIN=domain.zone

* где вместо domain.zone ставим наш домен.

Создаем каталог для размещения ключей домена:

mkdir -p /etc/opendkim/$DKIM_DOMAIN

Генерируем ключ:

opendkim-genkey -D /etc/opendkim/$DKIM_DOMAIN/ —domain $DKIM_DOMAIN —selector relay

Задаем нужные права:

chown :opendkim /etc/opendkim/$DKIM_DOMAIN/*

chmod g+rw /etc/opendkim/$DKIM_DOMAIN/*

Смотрим содержимое файла txt:

cat /etc/opendkim/$DKIM_DOMAIN/relay.txt

… и используя данное содержимое, в панели управления нашим DNS создаем TXT-запись.

Добавляем соответствующие настройки в файлы TrustedHosts, KeyTable, SigningTable:

echo «*.$DKIM_DOMAIN» >> /etc/opendkim/TrustedHosts

echo «relay._domainkey.$DKIM_DOMAIN $DKIM_DOMAIN:relay:/etc/opendkim/$DKIM_DOMAIN/relay.private» >> /etc/opendkim/KeyTable

echo «*@$DKIM_DOMAIN relay._domainkey.$DKIM_DOMAIN» >> /etc/opendkim/SigningTable

Перезапускаем службу.

а) если Linux:

systemctl reload opendkim

б) если FreeBSD:

service milter-opendkim restart

Готово.

Переключение на новый сервер

Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы dovecot и postfix почтового сервера. После этого сразу же запускаем синхронизацию каталогов между старым и новым сервером. Мы накатываем все изменения почтовой базы, делая ее полностью актуальной в новом сервере. Для этого надо добавить ключ —delete к rsync.

# /usr/bin/rsync --delete -av [email protected]:/data/mail /data

Важно не перепутать источник с приемником. Сначала идет старый сервер, потом новый

Перед запуском хорошенько проверяйте команды. Один раз я угробил новый сервер, ошибившись в команде и удалив с корня системы некоторые каталоги. Просто слешом ошибся на источнике, когда копировал в корень приемника. Это было не страшно, так как повредил новый сервер. Пришлось отложить перенос и восстановить его.

Ждёте окончания синхронизации. Она должна быть не долгой, так как перед остановкой почтового сервера вы и так накатили все изменения. Обычно несколько минут занимает процесс финального копирования. Когда он закончен, выключаете старый сервер, убираете его из автозагрузки гипервизора. На новом сервере меняете IP на адреса старого сервера и перезагружаете его. Можно и не перезагружать, но я для проверки всегда перезагружаю. Можно не менять IP адрес, если у вас все завязано на dns имена, отредактируйте dns запись. Но я обычно все же меняю ip, так надежнее. Обязательно найдется какое-нибудь старое оборудование, типа сканера, где адрес указан в виде ip адреса и т.д. Эти лишние проблемы потом не нужны. Лучше все сделать максимально незаметно и надежно.

После запуска нового сервера, убедитесь, что все службы работают, почта ходит, мониторинг не показывает проблем. Если все прошло гладко и по плану, то время простоя будет несколько минут. В ночное время этого могут и не заметить.

Бывает, что не все идет гладко. У меня были ситуации, когда после перехода уже на новый сервер, начинались проблемы, которые предусмотреть заранее было нельзя. Новое хранилище начинало тормозить или возникали еще какие-то проблемы. Например, с блокировками на nfs. Вы это не проверили заранее. С работой dovecot на nfs есть свои нюансы. Если вы понимаете, что оставить в работе новый сервер нельзя и надо откатываться, то нужно опять синхронизировать почтовую базу, если для вас важна та корреспонденция, которая была доставлена в то время, как поработал новый сервер. Для этого останавливаете почтовые службы на новом сервере, меняете на нем ip, запускаете старый и выполняете синхронизацию в обратном порядке — с нового на старый. Не ошибитесь в параметрах rsync! После этого оставляете старый сервер в работе, а с новым спокойно разбираетесь и готовите его еще раз к переносу.

Вот, в принципе, и все по переносу почтового сервера из моей практики. Я их переносил штук 10 за все время админства. Можно сказать руку набил.

Проверка

Стоит учитывать, что записи в DNS могут обновляться на протяжении длительного времени, например, от 15 минут до 24 часов. Если проверка дала отрицательный результат, пробуем повторить тест через час.

Отправляем письмо

Отправляем электронное сообщение на различные почтовые системы — mail.ru, gmail.com, yandex.ru.

Способов отправки несколько, например, можно выполнить следующие команды.

а) на Red Hat / CentOS:

yum install mailx

* данная команда установит утилиту для отправки почты из командной строки, если ее нет.

echo «Test DKIM» | mail -s «Testing DKIM» -S smtp=»localhost:25″ -S from=»[email protected]» -S return-path=»[email protected]» [email protected]

б) на Debian / Ubuntu:

apt-get install mailutils

* данная команда установит утилиту для отправки почты из командной строки, если ее нет.

echo «Test DKIM» | mail -s «Testing DKIM» -a «Smtp: localhost:25» -a «From: [email protected]» -a «Return-path: [email protected]» [email protected]

* где [email protected] — почтовый ящик, от которого отправляется письмо (напомню, в данном примере подпись создается для домена dmosk.ru), [email protected] — должен быть Ваш адрес почты, на который придет письмо.

Второй способ — настроить почтовый клиент, который будет отправлять почту через настроенный нами сервер.

Проверяем заголовки

Открываем наше письмо и смотрим заголовки (в mail.ru: Еще — Служебные заголовки).

Среди них мы должны увидеть следующую строчку:

dkim=pass header.d=dmosk.ru

Проверка домена на базе DKIM настроена успешно.

Install SSL Certificate

Enable the EPEL repository:
Install the Certbot and web server-specific packages, then run Certbot:
Certbot will ask for information about the site. The responses will be saved as part of the certificate:
Certbot will also ask if you would like to automatically redirect HTTP traffic to HTTPS traffic. It is recommended that you select this option.
When the tool completes, Certbot will store all generated keys and issued certificates in the directory, where is the name of the domain entered during the Certbot certificate generation step.

Finally, Certbot will update your web server configuration so that it uses the new certificate, and also redirects HTTP traffic to HTTPS if you chose that option.
If you have a firewall configured on your Linode, you may need to add
to allow incoming and outgoing connections to the HTTPS service. On CentOS, firewalld is the default tool for managing firewall rules. Configure firewalld for HTTP and HTTPS traffic:

Make a note of the certificate and key locations on the Linode. You will need the path to each during the
configuration steps.

Установка

Первичная задача – скачать файл установки с официального сайта https://github.com/iredmail/iRedMail/releases/download/1.0/iRedMail-1.0.tar.gz.

Следующим шагом мы распаковываем данный файл tar zxf iRedMail-x.y.z.tar.gz.

Переходим в распакованную папку и запускаем скрипт bash iRedMail.sh.

После запуска скрипта в первом окне мы видим окно уведомления, в котором предоставлены данные о том, где мы можем задать или найти вопросы по установке, а также информация по закрытию скрипта. Нажимаем далее и указываем папку для установки почтового сервера.

Далее выбираем веб сервер, без него не будет работать наш веб-интерфейс. В текущей версии мы выбираем Ngnix.

Выбираем базу данных для нашего почтового сервера и задаем пароль для пользователя.

Необходимо задать пароль для postmaster@домен. Данный пользователь будет администратором нашего почтового сервера и необходим для добавления и редактирования учетных записей на сервере.

На следующем этапе мы выбираем необходимые дополнительные модули для нашего почтового сервера. В данном случае нами были выбраны модули по умолчанию. Так как для нашей задачи модуль SOGo не нужен, его установку мы не выбираем.

После прохождения всех этапов скрипт выводит указанные нами выше данные, проверяем их и если все верно соглашаемся с установкой.

После проведенной установки скрипт выведет информацию повторно. После чего для запуска нашего сервера нам достаточно перезагрузить наш сервер.

Проверяем нашу «админскую» панель на работоспособность, заходя по адресу https://домен/iredadmin.

По итогу проведенных работ нами был поднят почтовый сервер с использованием средств iRedMail.