Почтовый сервер linux ubuntu

Настройка Postfix и Dovecot на Ubuntu

Многие пользователи Убунту используют систему не только для домашних нужд. Такой подход вполне оправдан, ведь на Linux-системах гораздо удобнее заниматься программированием, созданием серверов и веб-сайтов. Одно из удобств — создание сервера электронной почты. Для новичков эта задача покажется ужасно трудной, однако если вы разберётесь, как установить и настроить почтовый сервер для Ubuntu, задача уже не покажется вам такой уж тяжёлой.

Как выполняется настройка почтового сервера на базе Ubuntu.

Немного теории

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

Настроенный почтовый сервер, если говорить очень просто — это почтальон, который получает «письмо» от одного почтового клиента и отдаёт другому. В этом, в принципе, вся суть работы этого программного обеспечения. Почтовый сервер нужен не только для передачи электронной почты. На сайтах он отвечает за регистрацию пользователей, передачу заполняемых форм и другие важные действия, без которых сайт стал бы подобием книги, на которую можно только смотреть, перелистывая страницы, а вот что-то сделать трудновато.

Почтовые серверы на Linux существенно отличаются от оных на Windows и других системах. На Винде это уже готовая закрытая программа, которой остаётся только начать пользоваться. Дистрибутивы Линукса же предполагают самостоятельную настройку всех компонентов. Причём сервер будет в итоге состоять не из одной программы, а из нескольких. Мы будем использовать Postfix в сочетании с Dovecot.

Почему Postfix?

На Убунту существует несколько почтовых клиентов, но всё же мы выбрали именно этот. Настройка Posfix на Ubuntu гораздо легче, чем того же SendMail, а это важно для начинающего пользователя. В сочетании с Dovecot Postfix способен выполнять всё то, что обычно требуют от почтовых серверов.

Postfix — это непосредственно сам агент передачи почты. Ему и предстоит сыграть главную роль во всём представлении. Это программа с открытым исходным кодом, которую используют по умолчанию многие серверы и веб-сайты. Dovecot — это агент получения доставки почты.

Установка Postfix

Первым делом нужно воспользоваться командой для обновления локальной базы пакетов:

Сам агент Postfix можно свободно установить из репозитория, и это будет следующий шаг:

Когда запустится интерфейс этого приложения, нужно выбрать пункт «Internet Site», после чего произойдёт создание файла конфигурации с именем main.cf.

Далее в поле «System mail name» впишите локальное имя будущего сервера, например, myserver.org или любое другое по своему желанию. С помощью команды nslookup вы всегда сможете узнать домен сервера в будущем – посмотрите и запишите, это пригодится для настройки.

Настройка Postfix

Теперь нужно произвести настройки почтового агента. Для этого нужно первым делом создать файл с именем virtual в папке /etc/postfix// Для этого можно воспользоваться командой touch:

Теперь нужно создать папку private в директории /etc/postfix/. В ней будут храниться настройки почты:

Далее нужно создать ещё несколько файлов в директории /etc/postfix/private/:

touch canonical sender_relay sasl_passwd

Теперь нужно поменять некоторые настройки в файле конфигурации main.cf. Откройте его в блокноте в привилегированном режиме:

В файле идут значения параметров, и через знак «=» перечисляются его значения. Здесь нужно у параметра myhostname поменять имя локального сервера – на myserver.org, как в нашем примере, или на то, которое вы указали при установке Postfix на предыдущем этапе. Вот так:

Посмотрите использующийся IP-адрес с помощью такой команды:

Этот IP-адрес нужно вписать в параметры mydestination. Параметр alias_maps замените на virtual_alias_maps, тогда письма смогут пересылаться на другие адреса.

Теперь нужно поменять расположение хэша:

Для параметра mynetworks установите такие значения:

Если вы хотите, чтобы сервер мог работать с почтой Яндекса, в конце файла добавьте следующие параметры:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/private/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sasl_mechanism_filter = login
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/private/sender_relay
sender_canonical_maps = hash:/etc/postfix/private/canonical

В файле /etc/postfix/private/canonical добавьте свою почту Яндекса:

В файл /etc/postfix/private/sender_relay добавьте:

В файл /etc/postfix/private/sasl_passwd добавьте пароль от почтового ящика Яндекса — вместо ***:

Если вы используете Ubuntu Server 16, нужно открыть порты для работы почтовых служб. Для этого используйте команду:

iptables -A INPUT -p tcp —dport 25 -j ACCEPT

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

Проверка работы Postfix

Полезно установить утилиту mutt, чтобы работать с почтой было удобнее. Это можно сделать с помощью команды:

Теперь можно попробовать отправить письмо на какой-нибудь почтовый ящик:

echo «Message» | mutt -s «msg» mail@example.com

Если всё хорошо, то письмо будет получено. Но учтите, что в Google такие письма обычно попадают в спам.

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

Сначала нужно установить утилиту:

sudo apt-get install dovecot-imapd dovecot-pop3d

Теперь откройте файл /etc/dovecot/dovecot.conf и добавьте в него перечень протоколов:

protocols = pop3 pop3s imap imaps

Далее откройте файл /etc/dovecot/conf.d/10-mail.conf и посмотрите, есть ли там такая строка:

Если эта строка имеет другое содержимое, нужно его изменить на указанное. Если её нет вовсе, то нужно её добавить.

Перезапустите сервис, чтобы изменения применились:

Откройте файл /etc/hosts и добавьте там свой домен, который указывали в самом начале. В нашем примере это был домен myserver.org. IP-адрес также определяли на этапе настройки Postfix.

Теперь осталось лишь открыть порты, чтобы почтовые службы беспрепятственно могли получать и отправлять письма:

iptables -A INPUT -p tcp —dport 220 -j ACCEPT
iptables -A INPUT -p tcp —dport 993 -j ACCEPT
iptables -A INPUT -p tcp —dport 110 -j ACCEPT
iptables -A INPUT -p tcp —dport 995 -j ACCEPT

Чтобы проверить работоспособность всей этой системы, нужно отправить письмо на указанный в настройках почтовый ящик. При этом в адресе нужно использовать созданный домен, а пользователь должен быть создан заранее, тогда письмо должно быть получено – проверять почту можно с помощью утилиты mutt, которую вы уже установили.

Источник

Почтовый сервер со всем фаршем на 10.04 LTS

Содержание

Этот документ описывает процедуру установки почтового сервера на базе Ubuntu 10.04 LTS . В документе использовано следующее форматирование:

это команды, которые мы задаем в терминале.

это ответы, которые мы получаем на введенные нами команды

это содержимое различного рода конфигурационных файлов.

Вся процедура создания почтового сервера проверена, однако, естественно, в документе возможны ошибки и неточности. Если у Вас что-то не получается, или получается не так, как следует/описано, то:

В процессе создания документа использована куча различного рода информации, доступной в Интернет. К сожалению, не представляется возможным перечислить все источники информации, однако хочется выразить признательность всем авторам, чья работа так или иначе была использована при написании этого документа.

Постановка задачи

Пользователь, за которым мы «сидим» — это, конечно, не root, а toor (Вы же не сидите за рутом, правда?).

Установка системы

Первое что мы сделаем после перезагрузки, еще не отходя от терминала — установим ssh-сервер, чтобы все остальное делать удаленно:

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

Нас спросят, уверены ли мы, что хотим соединиться с этим сервером

Нас спросят пароль пользователя toor на oban

Введем. Все, теперь для захода на наш сервер с нашего компьютера достаточно набрать

и мы там. Заметьте, что это не то же самое, что попытка входа как

так что если хотите — проделайте это еще раз уже для такого варианта.

Итак, вначале установим все обновления (их наверняка набралось уже порядочно):

Мы используем dist-upgrade а не просто upgrade чтобы получить обновления в том числе и для ядра.

Естественно, соглашаемся с предложенным списком и (если были обновления ядра или подобные важные обновления) перезагружаемся

Установим нужные пакеты

(здесь и далее соглашаемся с установкой дополнительных пакетов).

Отвечаем на вопросы

Обязательно устанавливаем пароль для пользователя root в mysql (это — не пароль пользователя root на компьютере, не путайте!). Здесь и далее это —

После окончания установки начнем конфигурацию.

Создадим базу данных mysql для хранения всей информации для почтового сервера

Нас спросят пароль пользователя root mysql

Введем выбранный на этапе установки пароль

Перейдем в оболочку mysql (опять вводя тот же пароль)

Создадим специального пользователя mail_admin и паролем (замените!) для доступа к нашей базе данных mail с привилегиями SELECT, INSERT, UPDATE и DELETE. Доступ ему будет разрешен только с локального компьютера (т.е. с самого сервера):

Теперь создадим нужные нам таблицы в базе данных mail

(здесь мы задаем квоту для пользователей по умолчанию без лимита — 0)

и выйдем из оболочки mysql

Настройка Postfix

Сейчас нам необходимо указать Postfix, где ему искать информацию в базе данных. Для этого создадим шесть текстовых файлов. Как вы можете заметить, я указываю Postfix соединяться с MySQL через IP адрес 127.0.0.1 вместо localhost. Это связано с тем, что Postfix запущенный в chroot окружении не сможет иметь доступа к MySQL сокету, если будет пытаться использовать localhost для подключения.

Проверим, что mysql «слушает» локальный IP адрес

Если пришлось поменять /etc/mysql/my.cnf, то перезапустим mysql

и проверяем, что он действительно слушает этот адрес:

(здесь 5908- это номер процесса, у Вас будет другой).

Теперь создадим файлы для того, чтобы postfix знал, где что искать в нашей базе данных:

Т.к. в этих файлах у нас лежит пароль для доступа к базе данных, меняем права доступа к ним (разрешаем чтение только группе postfix, в которую входит наш почтовый сервер postfix):

Проверяем права доступа к этим файлам:

Создаем нового пользователя и группу с названием vmail с домашней директорией /home/vmail , где будут находится почтовые ящики:

Предварительная настройка postfix (нам еще придется ее менять чуть позже). Не забудьте поменять oban.aaa.ru на Ваше реальное полное имя сервера, а то postfix не будет работать!

Создание SSL-сертификатов

Создадим папку, в которой будем генерить все сертификаты

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

Здесь и далее (замените на нужное Вам):

ST = Moscow Region (регион)

O = AAA Ltd. (название компании)

CN = aaa.ru (имя сервера, для которого выдается ключ; в случае CA — имя домена)

emailAddress = admin@aaa.ru (почтовый адрес администратора)

(закоментаренные строки нужны только, если Вы действительно хотите иметь более-менее нормальный CA с листами отзыва ключей и т.п., но это выходит за рамки этого how-to)

Создаем частный ключ ключ CA

Введите пароль для файла ca.key (два раза для подтверждения) и не забывайте его!

Он будет нужен для подписывания всех ключей (здесь используем sudo т.к. при этом переписывается состояние random_state компьютера)

Создаем открытый ключ CA. Мы говорим, что ключи нашего CA имеют «срок жизни» 10 лет (-days 3650).

(вводим выбранный нами на предыдущем шаге пароль закрытого ключа CA)

Создаем сертификат для подписывания:

openssl x509 -trustout -inform PEM -in ca.crt -outform DER -out ca.pfx

Создадим директорию, в которой у нас будут лежать все ключи для всех серверов (если мы в дальнейшем будем создавать и подписывать ключи для других серверов; например, захотим, чтобы ключи были разные для smtp.aaa.ru pop3.aaa.ru и imap.aaa.ru) и, соответственно, директории для всех имен серверов (в нашем случае — oban.aaa.ru)

Создаем файлы конфигураций для ключей серверов (в каждой директории — свой файл, т.к. в нем записано имя сервера). В случае одного имени (замените на нужные Вам значения):

Теперь сгенерим ключи для нашего сервера (заметьте, что мы опять используем здесь sudo):

Здесь 1234 — парольная фраза для промежуточного ключа. Она нам нужна только временно, т.к. мы в результате хотим получить ключ без пароля (требование postfix).

Убираем из ключа парольную фразу:

Генерим запрос на подпись нашего ключа

и удаляем промежуточный ключ

Теперь нам нужно подписать наш созданный ключ от имени своего CA

Сделаем конфигурационный файл для подписи (срок действия подписи 5 лет — 1828 дней):

и создадим директорию для хранения сертификатов подписей:

Для первого подписанного ключа создаем его номер и формируем индексный файл (для остальных — не нужно!)

и подписываем (обратите внимание, что мы опять используем sudo)

(введем пароль закрытого ключа CA)

Проверим подпись (на всякий случай):

Мы должны получить

Номер ключа и индексный файл автоматически обновились, удалим старые файлы

Скопируем ключи в директорию /etc/ssl

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

Теперь установим доверие к новому CA. Для этого создадим папку для него

и скопируем туда наш сертификат CA

После этого переконфигурируем наши корневые сертификаты

(ответим, что мы хотим доверять новым сертификатам и выберем в списке наш новый сертификат для активации)

Настройка saslauthd

Авторизация почтовых пользователей на нашем сервере будет происходить через pam, к которому будет обращаться демон авторизации sasl.

Сначала выполним следующую команду:

Затем отредактируем файл /etc/default/saslauthd

Установим параметр START в yes и заменим строку OPTIONS=«-c -m /var/run/saslauthd» на OPTIONS=«-c -m /var/spool/postfix/var/run/saslauthd -r»

Создадим файл /etc/pam.d/smtp

и сменим его права доступа

Создаем файл /etc/postfix/sasl/smtpd.conf

и меняем ему владельца и права доступа

Добавляем пользователя postfix в группу sasl (это даст Postfix права доступа к saslauthd):

Перезапускаем Postfix и Saslauthd:

Для проверки авторизации создадим пользователя admin@bbb.ru в базе данных (заодно вначале в таблице domains зададим оба наших почтовых домена — aaa.ru и bbb.ru):

Введем пароль mysql

(здесь secret — это пароль нашего пользователя, выберите более подходящий; квоту пользователю мы задаем в размере 10Мбайт)

Для проверки авторизации нам нужно сгенерить строку, которую нужно передать при авторизации (обратите внимание на обратные слеши перед @ и 0):

Теперь проверим авторизацию

(здесь вставляем полученную ранее строку авторизации)

Если мы получим ответ, отличный от «Authentication successful», то мы где-то ошиблись. Проверить, в чем именно, можно, посмотрев файлы /var/log/auth.log и /var/log/mail.log

Теперь сделаем аутентификацию по openldap. Установим нужные пакеты:

и ответим на вопросы:

(конечно, нужное замените на свои параметры). Здесь мы предполагаем, что:

и добавляем в него одну строку после закомментаренной #bind_policy hard

и добавляем в него строки

Теперь можем проверить аутентификацию ldap-пользователя (предполагаем, что в ldap есть пользователь admin с паролем secret (у которого, кстати, почтовый адрес admin@aaa.ru, но это сейчас неважно; важно понимать, что это — другой пользователь, а не admin@bbb.ru):

Создаем файл /etc/postfix/ldap-mailboxes.cf

Меняем права доступа

и меняем строку virtual_mailbox_maps = … в файле /etc/postfix/main.cf

Для проверки в том же файле временно меняем строку

(это запрещает доставку писем с локального IP-адреса не в наши виртуальные домены)

и проверяем работу обоих наших тестовых адресов — test@bbb.ru (который записан в базе данных) и betatest@aaa.ru (который записан в LDAP у пользователя betatest)

(если мы попробуем передать на несуществующий адрес, мы получим:)

Вернем обратно строку в файле /etc/postfix/main.cf:

Для запрета аутентификации в postfix с передачей данных открытым текстом, вставляем в файл /etc/postfix/main.cf

и перезапускаем postfix

Откроем и изменим /etc/aliases

Сделайте так, чтобы postmaster указывал на root, а root указывал на ваше имя пользователя или ваш почтовый адрес, у вас должно получится примерно так:

После изменения /etc/aliases вы должны запустить команду

Настройка dovecot

(мы будем для dovecot использовать тоже аутентификацию через pam)

Отредактируем файл /etc/dovecot/dovecot-ldap.conf

Мы не будем задавать квоту для локальных пользователей, чтобы у них была неограниченная квота (напомним, что мы задали по умолчанию квоту без лимита).

Отредактируем файл /etc/dovecot/dovecot-sql.conf

Отредактируем файл /etc/dovecot/dovecot.conf, изменив следующие параметры:

В блоке protocol imap < добавляем строку

В блоке protocol pop3 < добавляем строку

Создадим скрипт, который будет посылать пользователям напоминания при превышении ими квоты

(здесь мы посылаем сообщение от имени admin@aaa.ru, причем копию сообщения направляем на admin@aaa.ru)

и сделаем его выполняемым

Не ждите от dovecot немедленной реакции на достижение квоты пороговых значений: dovecot пересчитывает квоту периодически.

Сменим права файлам, в которых записана информация о доступе к mysql и ldap

и проверим аутентификацию dovecot для обоих наших пользователей:

(здесь, конечно, вводим пароль пользователя admin@bbb.ru)

(здесь, конечно, вводим пароль пользователя admin)

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

Установка horde

Установим нужные пакеты

Разрешим доступ к нашей web-почте только через ssl. Для этого вначале отредактируем файл /etc/apache2/sites-available/default-ssl

Подключаем модуль ssl, разрешаем сайт default-ssl и перезапускаем apache

Редактируем файл /etc/horde/horde3/conf.php и закомментарим строки

Распаковываем скрипт для создания базы данных horde

и меняем пароль в файле /usr/share/doc/horde3/examples/scripts/sql/create.mysql.sql

на другой (далее будем называть его )

Исполняем скрипт с параметрами администратора mysql

В первый раз нас пустят с администраторскими привилегиями. Настроим систему аутентификации. Вначале войдем в Управление — Приложения — Портал (horde) и выберем закладку Authentication.

Зададим список пользователей-администраторов, перечислив двух наших пользователей — admin@bbb.ru, admin (через запятую) в поле «Which users should be treated as administrators (root, super-user) by Horde?».

В поле «Configuration type» выберем Separate values .

В поле «The hostname or IP address of the server» оставим localhost

В поле «The connection protocol» выберем imap/notls

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

В поле «What database backend should we use?» выбираем MySQL

В поле «Username to connect to the database as» вводим horde

В поле «Password to connect with» вводим пароль, который мы вводили в скрипте создания базы данных-

В поле «How should we connect to the database?» выбираем TCP/IP

В поле «Database server/host» вводим localhost

В поле «Port the DB is running on, if non-standard» оставляем 3306

В поле «Database name to use» вводим horde

В поле «Internally used charset» оставляем utf-8

Переходим в закладку Mailer и настраиваем доступ к SMTP -серверу:

В поле «What method should we use for sending mail?» выбираем Use a SMTP server

Переходим в закладку Cache System и выбираем Store objects in filesystem в поле «If you want to enable the Horde Cache, select a driver here. This is used to speed up portions of Horde by storing commonly processed objects.». В поле «The location to store the cached files» выбираем /tmp

Переходим в закладку Virtual File Storage и выбираем Files on the local system в закладке «What VFS driver should we use?»

Переходим в закладку Custom Session Handler и настраиваем доступ к созданной ранее базе данных:

В поле «What sessionhandler driver should we use?» выбираем MySQL based sessions

В поле «What protocol will we use to connect to the database?» выбираем TCP/IP

В поле «What password do we authenticate to the database server with?» вводим пароль, который мы вводили в скрипте создания базы данных —

Остальные поля оставляем по умолчанию.

Теперь нажмем кнопку Generate Портал Configuration. Получим сообщение «Невозможно сохранить резервную копию конфигурации в файл /usr/share/horde3/config/conf.bak.php.
Невозможно сохранить файл конфигурации /usr/share/horde3/config/conf.php. Вы можете использовать опции для сохранения кода обратно в Приложения или скопировать вручную код, приведенный ниже в /usr/share/horde3/config/conf.php.»

Это нормально, т.к. мы не хотим, чтобы возможно было менять конфигурацию через веб. Скопируем показанный внизу на странице сгенеренный код и запишем его в файл /etc/horde/horde3/conf.php (важно скопировать ВЕСЬ текст, заменив ВЕСЬ текст, имеющийся в файле).

(здесь вставляем скопированный текст со страницы броузера)

Закроем окно броузера.

Отредактируем файл /etc/horde/imp4/servers.php

и закомментируем все остальные примеры ниже.

Войдем заново на https://oban.aaa.ru уже под одним из введенных нами пользователей с правами администратора.

Зайдем в Управление — Приложения — Почта (imp) и выберем закладку Server.

В поле «Should we display a list of servers (defined in config/servers.php) for users to choose from? The options are ‘shown’, ‘hidden’, and ‘none’. If the server list is hidden then you can use the ‘preferred’ mechanism to auto-select from it based on an HTTP virtualhost or another piece of data. If it is shown, the user will be able to pick from any of the options. If none, no server list will be shown and the defaults will be used unless another mechanism changes them.» выберем Hidden .

Нажмем кнопку Generate Почта Configuration, скопируем сгенеренный текст конфигурации и запишем в файл /etc/horde/imp4/conf.php

(здесь вставляем скопированный текст со страницы броузера)

Отредактируем файл /etc/horde/passwd3/backends.php

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

(здесь вместо вставьте пароль mysql пользователя mail_admin, а также можете изменить политику паролей — какие пароли допустимы:

‘minLength’ — минимальная длина паролей

‘maxLength’ — максимальная длина паролей

‘minUpper’ — минимальное количество заглавных букв в паролях

‘minLower’ — минимальное количество прописных букв в паролях

‘minNumeric’ — минимальное количество цифровых символов в паролях

‘minSymbols’ — минимальное количество прочих символов букв в паролях)

Зайдем в Управление — Приложения — Пароль (passwd) и в поле «Should we display a list of backends (defined in config/backends.php) for users to choose from? The options are ‘shown’, ‘hidden’. If the backend list is hidden then you can use the ‘preferred’ mechanism to auto-select from it based on an HTTP virtualhost or another piece of data. If it is shown, the user will be able to pick from any of the options.» выберем Hidden .

Нажмем кнопку Generate Пароль Configuration, скопируем сгенеренный текст конфигурации и запишем в файл /etc/horde/passwd3/conf.php

(здесь вставляем скопированный текст со страницы броузера)

Отредактируем файл /etc/horde/horde3/registry.php

и для приложений imp, passwd и turba заменим

Учтите, что для пользователей, которые входят с использованием ldap мы не настроили смену пароля (это лучше делать другими средствами — внутри нашей сети, а не давать им менять пароль через веб). Кроме этого, этим пользователям (т.к. они входят, вводя только имя, а не имя@домен), нужно задавать свой почтовый адрес в поле «Ваш адрес отправителя:« в Настройки — Почта — Личные.

Для настройки адресной книги выполним

Введем пароль пользователя horde

Зайдем в Управление — Приложения — Адресная книга (turba) и нажмем кнопку Create Адресная книга Configuration, скопируем сгенеренный текст конфигурации и запишем в файл /etc/horde/turba2/conf.php

(здесь вставляем скопированный текст со страницы броузера)

Основное мы уже установили и настроили. Теперь установим ряд дополнений.

Установка amavisd-new, SpamAssassin и ClamAV

Для установки amavisd-new, spamassassin и clamav, выполним следующую команду:

Включим ClamAV и SpamAssassin отредактировав /etc/amavis/conf.d/15-content_filter_mode

Добавим посередке параметр

(нам нужно указать amavis, что виртуальные домены являются локальными. Иначе он не будет вставлять заголовки и проверять на спам, т.к. будет считать, что письма, посланные на виртуальные домены — исходящие) .

Откроем файл /etc/amavis/conf.d/20-debian_defaults

Дальше — список параметров, которые используются у меня с кратким пояснением, зачем и почему.

Это позволяет держать небольшой кеш уже проверенных писем и не проверять точно такие же письма заново, если они уже есть в кеше. Проверка идет по сигнатуре, которую amavis генерирует сам. Полезно, когда, в частности, один и тот же спам валится на несколько адресов. ttl-параметры — это срок жизни сигнатуры в кеше (с положительным и отрицательным результатом проверки на спам). В моем случае, процент попадания в кеш порядка 8.

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

$sa_spam_report_header — добавление заголовков с подробным отчетом о результатах проверки. Учтите только, что эти заголовки будут вставлены только в письма, признанные спамом. Подробный отчет — это объяснения каждого сработавшего правила spamassassin, типа вот такого:

$sa_tag_level_deflt — добавлять заголовки с результатом проверки на спам в сообщения с указанной оценкой и выше. Здесь — всегда добавлять эти заголовки. Заголовки вот такие:

если опознан спам и

если сообщение «чистое». Еще раз подчеркну, что в этом случае заголовка «X-Spam-Report:» не будет. Если нужен — нужно править сам amavis.

$sa_tag2_level_deflt — уровень, начиная с которого сообщение признается спамом.

$sa_kill_level_deflt — уровень, начиная с которого выполняется правило по обработке спама (описание ниже)

$sa_dsn_cutoff_level — уровень, начиная с которого не отсылается сообщение о невозможности доставки. Очень советую его иметь равным $sa_kill_level_deflt, иначе Вас, скорее всего, внесут в какой-нибудь черный список. Особенно это любит делать, например, att.com

$sa_quarantine_cutoff_level — уровень начиная с которого письмо не сохраняется в карантине (/var/lib/amavis/virusmails/…)

Параметры задают правила обработки «нехороших» сообщений:

$final_virus_destiny — просто игнорировать (сами письма сохраняются в карантине)

$final_banned_destiny — письма с запрещенными вложениями по типу файлов: сообщить отправителю о невозможности доставки

$final_spam_destiny — игнорировать (это и есть то самое правило обработки спама, о котором шла речи выше)

$final_bad_header_destiny — некорректные заголовки писем пропускать.

$virus_admin — адрес, куда доставлять сообщения о вирусах и отраженных письмах с запрещенными вложениями (postmaster), чтобы можно было проверить содержимое писем в карантине. О письмах со спамом, попавшим в карантин, сообщений не будет.

Настройки, связанные с вирусами и запрещенными вложениями лучше оставить «по умолчанию».

Конкретные уровни оценки выставьте сами (я использую именно такие, и они меня полностью удовлетворяют, по крайней мере, по прошествии довольно большого времени и накопленной bayes-овской базы и с регулярными обновлениями правил spamassassin). Недавно специально проверял — за три дня ложных срабатываний было 0 (менял D_DISCARD на D_PASS у $final_spam_destiny).

Сделаем так, чтобы amavis не проверял исходящие письма на спам, а только входящие (на вирусы он будет проверять все письма). Вставим строки

Отредактируйте файл /etc/amavis/conf.d/21-ubuntu_defaults

и закомментируйте строки

Добавим пользователя clamav в группу amavis и перезапустим amavisd-new и ClamAV:

Укажем, чтобы postfix проверял почту через amavis

Отредактируем файл /etc/postfix/master.cf

и добавим в конец следующие строки

Для периодической очистки карантина вставим в cron

(ежедневная очистка всех файлов из карантина, старше 60 дней)

Установка Razor, Pyzor And DCC и настройка SpamAssassin

Установим нужные пакеты

DCC не содержится в репозитории Ubuntu, поэтому мы его установим так:

(Для работы клиента DCC нам нужно пробросить на шлюзе UDP порт 6277 на наш почтовый сервер)

Скажем spamassassin использовать эти три программы. Отредактируем /etc/spamassassin/local.cf добавив несколько строчек в конец:

Мы должны включить плагин DCC в SpamAssassin. Откроем /etc/spamassassin/v310.pre

и раскомментируем такую строчку

Проверим конфигурацию spamassassin

Мы не должны получить никакого сообщения, если у нас все в норме.

Обновим набор правил для SpamAssassin следующим образом:

Добавим в cron задание, чтобы набор правил обновлялся регулярно. Запустим

чтобы открыть редактор cron и добавим в него следующее задание:

Это позволит обновлять набор правил каждый 2 день в 4 часа 23 минуты.

Для работы razor нам нужно сформировать для него домашнюю директорию и зарегистрироваться, для того, чтобы иметь возможность сообщать о спаме. Т. к. spamassassin работает от имени пользователя amavis, сделаем следующее (по умолчанию домашней директорией пользователя amavis является /var/lib/amavis):

После этого у нас появится директория /var/lib/amavis/.razor/ в которой будет лежать информация о серверах razor и о имени/пароле для доступа к ним (сгенеренные автоматически).

Зададим правила отчета о спаме в horde. Зайдем броузером на https://oban.aaa.ru под административной записью и зайдя в Управление — Приложения — Почта (imp) и выберем закладку Message and Spam.

В поле «Should we report the spam message via an external program (e.g. /usr/local/bin/spamassassin -r)? If you include the placeholder %u in this string, it will be replaced with the current username. If you include the placeholder %l in this string, it will be replaced with the current short username. If you include the placeholder %d in this string, it will be replaced with the current domain name.» введем /usr/local/bin/spamassassin -r а в поле «Should we report the innocent message via an external program (e.g. /usr/local/bin/spamassassin -k)? If you include the placeholder %u in this string, it will be replaced with the current username» введем /usr/local/bin/spamassassin -k

При приеме писем postfix проверки на спам проводятся amavisd-new пользователем amavis, а при работе horde — пользователем www-data. Поэтому создаем ссылки

и вставляем пользователя www-data в группу amavis (чтобы разрешить доступ к bayes-базе при работе в horde)

и перезапустим apache

и вставим туда строку

Вставим периодическое обновление нашей bayes-базы (будем делать это каждую ночь). Отредактируем файл

Таким образом, при приеме писем postfix при помощи amavis будет проверять письма в том числе по bayes-базе, которая формируется автоматически (обучение идет из писем с достаточно большим значением уровня спама; письма с очень малым показателем также участвуют в обучении — они помечаются, как ham, т. е. не-спам; письма со средним значением уровня спама в автоматическом обучении не участвуют). Кроме этого, в пополнении базы данных принимают участие и пользователи, когда помечают письма, как спам или не-спам (innocent). Чем больше писем участвует в обучении (и как спам, и как ham), тем лучше работает bayes-база данных спама.

Дополнительные правила для защиты от спама

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

Дело в том, что процесс передачи/получения письма начинается с представления серверов друг другу. После соединения по порту 25 (SMTP ), компьютер — инициатор выдает команду

Принимающий сервер уже на этом этапе может отсечь кучу спама. Как это сделать? Очень просто. Нормально сконфигурированный сервер обязан в сообщении HELO передать свое истинное имя; причем это имя должно соответствовать IP-адресу, с которого осуществляется соединение; а IP-адрес должен резолвится в обратной зоне в это имя. Если это не так — Вы имеете полное право отсечь соединение прямо на этом этапе. Плюсы: не тратится лишний трафик на прием сообщений, которые заведомо являются спамом; экономятся вычислительные затраты на дальнейшие проверки писем на спам и вирусы. Необходим какой-то трафик для проведения проверок по DNS (но он заведомо меньше трафика на прием писем). Отсечь «нормальное» письмо бояться не стоит: неверная настройка почтового сервера, который Вы отсекли — не Ваша головная боль.

Для того, чтобы такие проверки проводились на этапе приемки писем, в файл /etc/postfix/main.cf нужно вставить следующие строки:

(отредактируйте существующие и добавьте отсутствующие) Если Вы не собираетесь использовать postgrey (я рекомендую его использовать), не вставляйте check_policy_service inet:127.0.0.1:10023,

Подробнее об этих параметрах:

disable_vrfy_command — запрет на использование команды VRFY. Эта команда зачастую используется для сбора с сервера существующих адресов почты для дальнейшей рассылки на них спама.

smtpd_delay_reject — подождать команды RCPT TO перед (возможным) отказом от приема письма. Нужно из-за того, что некоторые сервера неверно реагируют на отказ от приема писем до посылки ими команды RCPT TO

smtpd_helo_required — требовать от сервера обязательно представиться командой HELO. Это дает возможность проведения нужных нам проверок.

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

smtpd_client_restrictions — ограничения на этапе установления связи по протоколу SMTP

sleep 1 — пауза на 1 секунду для отсекания совсем нетерпеливых спам-хостов (обычно они просто сразу же рвут соединение — им нужно разослать как можно больше спама, поэтому ждать им — как серпом…)

reject_unauth_pipelining — отсечь хосты, которые пытаются слать команды в конвейере, даже не проверив, поддерживает ли это наш сервер. Это часто делают именно спам-хосты для увеличения скорости передачи

permit_sasl_authenticated — разрешить для авторизованных клиентов (пользователи)

permit_mynetworks — разрешить при соединении из моей подсети

permit — в другом случае продолжать прием

smtpd_helo_restrictions — ограничения на этапе команды HELO:

permit_mynetworks — разрешить при соединении из моей подсети

permit_sasl_authenticated — разрешить при аутентификации (пользователи)

reject_invalid_helo_hostname — отказать при нарушении синтаксиса имени хоста в HELO (случается очень редко, тем не менее…)

reject_non_fqdn_helo_hostname — отказать, если имя хоста в HELO не в полной форме (не должно быть просто server, а должно быть типа server.domain.ltd)

reject_unknown_helo_hostname — отказать, если у хоста, указанного в команде HELO, в DNS нет записи типа MX или A (множество зобми-хостов)

permit — в другом случае продолжать прием

smtpd_sender_restrictions — проверки по команде MAIL FROM (имя отправителя)

permit_mynetworks — разрешить при соединении из моей подсети

permit_sasl_authenticated — разрешить при аутентификации (пользователи)

reject_non_fqdn_sender — отказать, если имя отправителя не в полной форме (должно быть не name или name@domain а name@domain.ltd)

reject_unknown_sender_domain — отказать, если наш сервер не является «родным» для отправителя и домен отправителя не имеет в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)

permit — в другом случае продолжать прием

smtpd_recipient_restrictions — проверки по команде RCPT TO (имя получателя)

reject_unauth_pipelining — отсечь хосты, которые пытаются слать команды в конвейере

permit_sasl_authenticated — разрешить для авторизованных клиентов (пользователи)

permit_mynetworks — разрешить при соединении из моей подсети

reject_unauth_destination — отказать, если домен-адресат: 1) не перечислен в списке доменов, для которых мы форвардим почту ($relay_domains) и не содержит команд переадресации (типа user@another@domain); 2) не является «нашим» (т.е. не перечислен в списках $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, или $virtual_mailbox_domains ) и не содержит команд переадресации (типа user@another@domain). Это — традиционные правила, чтобы наш сервер не служил т.н. Open Relay, через который спамеры рассылают почту третьим лицам.

reject_non_fqdn_recipient — отказать, если имя получателя не в полной форме (должно быть не name или name@domain а name@domain.ltd)

reject_unknown_recipient_domain — отказать, если мы не являемся «родным» сервером для получателя и домен получателя не имеет в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)

reject_unlisted_recipient — отказать, если адрес получателя не указан в списках получателей домена (не перечислен в $local_recipient_maps или $virtual_alias_maps или $virtual_mailbox_maps или $relay_recipient_maps, в зависимости от того, в какой именно таблице найден домен получателя)

check_policy_service inet:127.0.0.1:10023 — проверка у стороннего сервиса (в данном случае — postgrey, о нем чуть позже)

permit — продолжать прием

Такая конфигурация позволяет отсечь просто КУЧУ спама.

Установка postgrey

Теперь о postgrey. Это еще один способ борьбы со спамом. Многим он не нравится, мне — так очень. Работает он так. При приходе письма (конечно, если оно «прорвалось» через все проверки, указанные выше) сервер запоминает три параметра (так называемый триплет): от кого оно послано, кому послано, и кем (т.е. адрес сервера, который его посылает), и сообщает передающему серверу «Я сейчас занят, повторите чуть позже», после чего начинает отсчет времени для конкретного триплета. Большинство спамеров, как мы знаем, ждать не любят, и либо пытаются повторить посылку сразу же (на что получают тот же ответ), либо просто прекращают свои попытки. Наш же сервер, если обнаружит повторное письмо с тем же триплетом по прошествии некоторого времени (по умолчанию — 5 минут), спокойно его примет. При этом этот триплет будет запомнен на какое-то время (35 дней), так что следующие письма с тем же триплетом пройдут без задержки. Если это Ваш постоянный корреспондент, то задержек больше не будет вообще.

Установить postgrey очень просто:

(в main.cf обращение к postgrey у нас уже добавлено)

Если Вы хотите изменить параметры postgrey, то это делается в файле /etc/default/postgrey.

добавив параметры –delay=N (в секундах; по умолчанию 300) и –max-age=N (в сутках; по умолчанию 35):

Стоит заглянуть еще в два файла: это /etc/postgrey/whitelist_clients и /etc/postgrey/whitelist_recipients. В первом перечислены домены-отправители, письма от которых принимаются автоматом (по разным причинам), во втором — адреса-получатели, письма на которые также принимаются сразу всегда (например, abuse@). Можете при необходимости дописать в эти файлы свои строки.

Установка spf, , sender id, dkim, domainkey

И еще немного о борьбе со спамом.

Зачастую спамеры пытаются «замаскироваться» под обычных отправителей, т.е. подделывают обратный адрес (mail from:).

Есть способ а) обезопасить себя от таких «подделок» и б) проверять на этапе приема, не подделан ли обратный адрес.

Для этого в настоящее время существует четыре варианта. Советую использовать все.

Использование SPF

(здесь aaa.ru — Ваш домен)

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

Эта запись означает, что домен aaa.ru использует версию SPF1 и разрешает от своего имени посылать почту серверу, указанному в записи MX и A домена, и запрещает всем остальным.

Вместо -all на этапе тестирования можно вставить

all (в этом случае письмо будет не отклонено, а сервер-получатель получит «предупреждение» о возможной подделке адреса отправителя — т.н. softfail).

Вообще говоря, запись для SPF в домене можно сгенерировать автоматически, ответив на несколько вопросов вот тут: http://www.openspf.org/

Для того, чтобы Ваш почтовый сервер производил проверку по SPF, нужно установить пакеты:

Отредактируйте файл /etc/postfix/main.cf

В строку smtpd_recipient_restrictions вставьте

(эту проверку следует вставить после reject_unauth_destination чтобы не было риска использовать Вас, как open relay)

Отредактируйте файл /etc/postfix/master.cf

Проверка на SPF нужна только для входящих писем, исходящие письма с Вашего сервера проверять не надо.

Использование Sender ID

Технология Sender ID — это вариант от Microsoft. И, хотя мы не собираемся проверять входящую почту на Sender ID, мы уже сконфигурировали все, что необходимо для отправки писем с использованием Sender ID: эта технология использует ту же запись в DNS , которую мы внесли. Единственно что можно еще сделать — это зарегистрировать нашу запись в Microsoft вот здесь: https://support.msn.com/eform.aspx?productKey=senderid&page=support_senderid_options_form_byemail&ct=eformts

Использование Domainkey и DKIM

Эта технология несколько отличается от SPF. DKIM — это несколько улучшенный вариант Domainkey, однако лучше использовать оба сервиса, тем более, что установка очень похожа. Для использования Domankey и DKIM установим пакеты

Выбирайте все опции «по умолчанию» при установке — сейчас мы сконфигурируем их вручную. Вначале сгенерим ключи (вместо aaa.ru используйте свой домен):

У Вас в текущей директории появится два файла: mail.private и mail.txt

Создадим директорию для хранения ключа и перепишем ключ в нее под именем mail (опять же, используйте свое имя домена), изменим разрешения для него и переименуем файл mail.txt:

(при необходимости повторим для другого домена)

Отредактируем файл /etc/default/dk-filter

и вставим туда строку

(если нужно несколько доменов — перечисляем их через запятую)

Отредактируем файл /etc/default/dkim-filter

должна быть раскомментарена.

Отредактируем файл конфигурации /etc/dkim-filter.conf

и поменяем в нем строку

Если нужно подписывать почту от нескольких доменов, вставляем список этих доменов:

и следующие строки

Создадим файл /etc/mail/dkim-keys.conf

(вставляем строки с соответствующими параметрами для каждого домена)

Создадим файл /etc/mail/dk-keys.conf

(вставляем строки с соответствующими параметрами для каждого домена)

Создаем директорию для записи протокола работы dkim и меняем ее владельца

Отредактируем файл /etc/postfix/main.cf

и добавим в него строки

Проверьте, что файл

содержит раскомментаренную строку

Отредактируем файл /etc/postfix/master.cf

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

Последнее, что нам осталось сделать — это внести изменения в DNS -записи нашего домена (доменов):

Здесь вместо aaa.ru — Ваш домен, а вместо XXXXXXXXXX — значение, записанное в «p=» в файле aaa.ru.txt для соответствующего домена, который появился при генерации ключей.

Важное замечание: в записи _domainkey.aaa.ru. вместо «o=-» на этапе тестирования можно вставить «o=

». Первое означает, что ВСЕ письма от вашего домена подписываются, а второе — что подписываются только некоторые письма.

Кроме этого, на этапе тестирования в запись mail._domainkey.aaa.ru. (внутри кавычек) можно добавить ключ t=y; :

Перезапускаем сервисы dk-filter и dkim-filter

Если они запустились нормально, перезапускаем postfix

Протестировать только что установленные сервисы можно послав тестовое письмо на адрес check-auth@verifier.port25.com

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

то все работает нормально.

Проверяем работу антиспама и антивируса

Для проверки работы антивируса пошлите себе с внешнего почтового аккаунта (например, gmail) письмо, содержащее следующую строку (это — не вирус, а стандартное тестовое письмо EICAR для проверки антивируса):

и проверьте логи /etc/log/mail.log

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

Это письмо попадет в карантин (в нашем случае — в /var/lib/amavis/n/virus-nGy-KxAsczIP)

Для проверки антиспама пошлите себе с внешнего почтового аккаунта (например, gmail) письмо, содержащее следующую строку (это стандартный антиспам-тест GTUBE):

и проверьте логи /etc/log/mail.log

(обратите внимание, что это тестовое письмо получит «вес» около 1000)

Установка fail2ban

Еще одно добавление к серверу. Дело в том, что все сервера так или иначе «торчащие» в интернет, становятся целью для атак, и наш почтовый сервер — не исключение. Одна из атак — попытка «взлома» паролей пользователей. Такая атака обычно проводится с перебором паролей, и рано или поздно может быть удачной. В нашем случае — это атака на аутентификацию пользователей по IMAP , POP3 , SMTP .

Бороться достаточно просто — есть прекрасная программа fail2ban, которая после N неудачных попыток просто прописывает в файрволле правила, запрещающие доступ с атакующего IP-адреса на определенный срок (чаще всего — на час через 3 неудачных попытки). Такие «паузы» делают подобные атаки практически бессмысленными.

Для защиты устанавливаем пакет fail2ban

Создаем файл /etc/fail2ban/filter.d/dovecot.conf

Скопируем на всякий случай файл /etc/fail2ban/jail.conf

В нем есть примеры множества сервисов, нас же интересуют только часть из них. Отредактируем нужные строки в файле /etc/fail2ban/jail.conf

Здесь мы говорим, чтобы fail2ban игнорировал атаки с адресов 127.0.0.1 и сети 10.0.0.0/255.255.0.0 (предполагаем, что это наша внутренняя сеть, и из нее могут быть разве что ошибочные попытки набора паролей пользователями); после 3 неудачных попыток аутентификации мы ставим бан на 3600 секунд (1 час); информацию о банах будем посылать на admin@company.ru (поменяйте на свой).

По правилам, описанным в файле /etc/fail2ban/filter.d/sshd.conf мы:

Пример записи в /etc/log/auth.log которая будет «поймана»

По правилам, описанным в файле /etc/fail2ban/filter.d/dovecot.conf мы:

Примеры записей в /etc/log/mail.log которые будут «пойманы»

По правилам, описанным в файле /etc/fail2ban/filter.d/sasl.conf мы:

Примеры записей в /etc/log/mail.log которые будут «пойманы»

Можно проверить срабатывание написанных нами правил:

Если в лог-файлах были попытки неверной аутентификации, мы получим по ним «отчет».

Когда убедимся, что все работает — перезапустим сервис

и наслаждаемся попадающими к нам «хакерами».

Дополнительные настройки

Для того, чтобы наш сервер нормально воспринимали другие сервера, нам нужно сделать еще две вещи.

Вторая — если Ваш почтовый сервер расположен за NAT, а Вы используете алиас на шлюзе, то он будет виден другим серверам не со своим IP-адресом (адресом алиаса), а с IP-адресом шлюза, что нехорошо (Ваши письма могут быть «отражены» адресатом на этом основании). Чтобы Ваш почтовый сервер был виден под своим IP-адресом (т.е. IP-адресом алиаса на шлюзе), нужно вставить на шлюзе что-то типа

(здесь eth1 — внешний интерфейс шлюза, 10.0.0.6 — IP-адрес почтового сервера, AA.BB.CC.DD — IP-адрес алиаса на шлюзе)

Установка mailman

Установим и настроим пакет mailman

Ответим на вопросы

Выберем русский и английский ( en и ru )

Нас предупредят, что Отсутствует список рассылки сайта. Мы его создадим чуть позже.

Т.к. mailman не поддерживает utf8, часть операций с mailman производим с указанием LANG=C

Исправим ошибки (они неизбежны при установке) и проверим:

Мы получим что-то типа такого списка

Это нормально, т.к. все это — ссылки.

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

Отредактируем нужные строки в файле /etc/mailman/mm_cfg.py

Проверим содержимое файла /etc/postfix/master.cf

Если в нем строка mailman имеет вид

Настроим apache. Создадим файл /etc/apache2/sites-available/mailman

и разрешим запуск этого сайта

и перезапустим apache

Вставим запись в таблицу transport postfix

Проверим содержимое файла /etc/postfix/master.cf

и убедимся, что он содержит

(здесь должно быть две строки)

Отредактируем файл /etc/postfix/main.cf

Теперь перезапустим сервисы и запустим mailman

Создание листа рассылки

Введем адрес администратора листа рассылки

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

Нажмите Enter.

Добавим в таблицу forwardings базы данных mail следующие записи:

чтобы у нас был доступ к нашим спискам рассылки через веб.

Теперь мы можем зайти с паролем администратора листа mailman браузером на http://lists.aaa.ru для дальнейшей настройки листа рассылки.

Прочие листы рассылки добавляются аналогично.

Установка автоответчика

Создадим файл ./autoresponse следующего содержания (отличие от варианта, лежащего на http://nefaria.com/project_index/autoresponse/ в том, что для совместимости с mailman мы используем -autoresponse вместо +autoresponse):

Откроем файл /etc/postfix/master.cf

сразу после нее вставим

(она должна начинаться хотя бы с одного пробела)

В конце файла вставляем

(это две строки, причем вторая строка должна начинаться хотя бы с одного пробела)

и перезагружаем postfix

Теперь для того, чтобы при Вашем отсутствии на работе (например, отпуск) всем, кто послал Вам письмо, автоматически отправлялось сообщение о Вашем отсутствии, нужно послать по адресу -autoresponse@aaa.ru то письмо, которое Вы хотите установить в качестве автоответчика, например admin-autoresponse@aaa.ru (здесь и далее замените aaa.ru на Ваш домен).

Если все прошло нормально, Вы получите ответ с темой «Out Of Office» следующего содержания: «Autoresponse enabled for admin@aaa.ru by SASL authenticated user: admin@aaa.ru from: x.x.x.x», где x.x.x.x — IP-адрес хоста, с которого было отправлено письмо.

Теперь при посылке Вам письма все автоматически в ответ будут получать то письмо, которое вы установили в качестве автоответчика, сами письма будут сохраняться у Вас в папке «Входящие» как обычно.

Для того, чтобы убрать сообщение автоответчка, пошлите еще раз любое письмо на адрес -autoresponse@aaa.ru и Вы получите в ответ письмо с темой «Out Of Office» следующего содержания: «Autoresponse disabled for admin@aaa.ru by SASL authenticated user: admin@aaa.ru from: x.x.x.x», где x.x.x.x — IP-адрес хоста, с которого было отправлено письмо.

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

Письма для включения/выключения автоответчика должны быть посланы с Вашего адреса, иначе они не «сработают».

Установка munin

Установим нужные пакеты

(если у Вас уже установлен munin на каком-нибудь сервере, то установите только munin-node)

и поменяем (если необходимо) строку

Нас интересуют более подробные графики того, что происходит у нас с почтой. Поэтому создаем файлы

Сделаем их исполняемыми

И создадим нужные ссылки

Отредактируем файл /etc/munin/plugin-conf.d/munin-node

и вставим в него строки

и через 5-10 минут получим графики. Они обновляются раз в пять минут.

Заключение

Все установленные пакеты находятся в работоспособном состоянии, причем уровень безопасности вполне достаточен. Дальнейшую настройку параметров всех пакетов и (при необходимости) ужесточение мер безопасности проводите, руководствуясь доступными в Интернет рекомендациями и описаниями соответствующих пакетов.

Имеющиеся проблемы

При полной установке почтового сервера по этому документу есть следующие нерешенные проблемы:

1. Установленный автоответчик не дает возможности работать обходу проверки на спам для исходящих писем, т.к. не срабатывает $policy_bank <'MYUSERS'>в amavis. Соответственно, munin не считает отосланные наружу письма. Решения пока нет.

Приложения

Приложение 1 — управление пользователями через веб

Создадим новую директорию:

и вставим туда строки

и вставим туда строки

и добавим в него строки

(замените oban.aaa.ru на имя своего сервера)

Мы, во-первых, разрешаем доступ к этой директории только для пользователей, чьи имена и пароли записаны в файле /var/www/control/.htpasswd (мы сейчас его создадим) и, во-вторых, требуем, чтобы доступ к этим скриптам шел только с использованием ssl.

Введем пароль пользователя admin, которому мы даем доступ к скриптам

Повторим тот же пароль.

После этого у нас в директории /var/www/control/ появится файл .htpasswd, содержащий в зашифрованном виде наш пароль.

Изменим права доступа на эти файлы

и перезапустим apache

После этого, зайдя браузером на https://oban.aaa.ru/control и введя имя пользователя admin и пароль (который мы ранее для него задали), мы сможем создавать пользователей, удалять их, задавать им пароль (если они его забыли), а также создавать и удалять новые алиасы.

Приложение 2 — фильтрация писем на сервере

Если у Вас есть необходимость использовать фильтрацию писем на сервере, а не по правилам, которые могут устанавливать сами пользователи в horde, то это можно сделать с помощью procmail.

и вставим в него следующие строки:

(вторая строка должна начинаться хотя бы с одного пробела)

и вставим в него строку

(значение переменной WS — два символа: пробел и табуляция. Это нужно, чтобы проще было писать правила)

Если хотите, чтобы у каждого пользователя велся собственный протокол фильтрации, раскомментируйте строку #LOGFILE=»/home/vmail/$NEXTHOP/$USER/procmail.log» (уберите символ # из начала строки).

Предположим, что у нас есть пользователь, почту которого мы хотим фильтровать по правилам на сервере — test@aaa.ru. Вставим в таблицу transport запись, которая говорит, что почта, поступившая на адрес получателя test@aaa.ru должна передаваться procmail для фильтрации:

И создаем в папке пользователя test@aaa.ru файл .procmail с нужными нам фильтрами, например:

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

Нужная папка создастся сама при первом срабатывании фильтра (т. к. у нас пользователь vmail, от имени которого запускается procmail, имеет право на создание папок в директориях пользователей).

Информацию, как именно писать фильтры для procmail можно найти в Интернет.

Приложение 3 — пользователь без почты

Зачастую необходимо создание такого пользователя, у которого вся приходящая почта будет уничтожаться (например, от имени такого пользователя обычно рассылаются сообщения, на которые ответы не ожидаются) — назовем его noreply@aaa.ru .

Сначала заведем этого пользователя в нашей таблице users (мы предполагаем, что такой пользователь нам в нашей ldap-таблице пользователей не нужен):

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

Для того, чтобы указать, что почту, приходящую этому пользователю, нужно просто уничтожать, используем таблицу transport:

Теперь вся почта, приходящая на адрес noreply@aaa.ru будет просто уничтожаться.

Приложение 4 — фильтрация писем на сервере при помощи sieve

Есть еще одна возможность фильтровать письма на сервере — так называемые скрипты sieve. Их отличие в том, что несмотря на то, что фильтрация происходит на сервере, пользователи могут сами создавать и редактировать правила фильтрации, причем не только при помощи horde: плагины для управления скриптами sieve (протокол управления называется managesieve — не правда ли, неожиданно?) существуют для многих почтовых клиентов (например, thunderbird).

Скрипты sieve поддерживаются dovecot, правда, для этого нам придется переложить на dovecot задачу раскладывания писем по папкам (у нас этим занимался postfix).

Отредактируем файл /etc/dovecot/dovecot.conf

изменив следующие параметры

Здесь мы задаем расположение скриптов sieve относительно «домашней» директории наших пользователей (а также разрешаем использовать устаревшие команды imapflags — они нам нужны для управления фильтрами с помощью horde). В каждый момент времени может быть активным только один файл со скриптами, на него будет (автоматом, при активации файла в том или ином плагине) делаться ссылка .dovecot.sieve. У нас все пользователи — виртуальные, причем часть из них — ldap, остальные же — mysql пользователи, поэтому нам нужно задать домашнюю директорию для обоих типов.

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

Здесь мы явно задаем наш домен aaa.ru, т. к. пользователи этого домена авторизуются в ldap без указания домена, а только своим именем.

и отредактируем строку

Теперь настроим postfix на использование dovecot для локальной рассылки писем.

(вторая строка начинается хотя бы с одного пробела)

Перезапустим dovecot и postfix

Для управления sieve в horde установим необходимые пакеты:

К сожалению, в текущей версии php-net-sieve есть ошибка, которая приводит к выдаче отладочной информации, поэтому нам нужно отредактировать файл

и закомментировать строку (в текущей версии файла это 83-я строка)

Теперь настроим ingo. Отредактируем файл

Закомментируем все, кроме следующих строк (отредактировав соответственно приведенному примеру):

Зайдем пользователем-адинистратором на https://oban.aaa.ru и войдем в Управление — Приложения — Фильтры (ingo). В поле «What storage driver should we use?» выберем Preference System .

Нажмем кнопку Generate Фильтры Configuration, скопируем сгенеренный текст конфигурации и запишем в файл /etc/horde/ingo1/conf.php

(здесь вставляем скопированный текст со страницы браузера)

Зайдем пользователем, у которого мы хотим использовать скрипты, войдем в Настройки — Фильтры, выберем (установим птичку) параметр «Automatically update the script after each change?» и нажмем кнопку Сохранить настройки.

Теперь в разделе Почта — Фильтры можно активировать, редактировать имеющиеся фильтры или добавлять новые. Все правила, которые Вы будете задавать через horde (ingo) будут записываться в файл правил с именем ingo. Этот файл будет доступен для редактирования с помощью любого другого плагина sieve (например, к thunderbird).

Источник