Введение
Данная статья будет актуальна для тех, кто сам выполнил установку и настройку postfix или воспользовался готовой сборкой на базе iredmail. Это что касается материалов моего сайта. А в целом все описанное ниже будет актуально для любого почтового сервера, который хранит почту в формате maildir.
Скажу пару слов, почему именно maildir. Лично я этот формат использую за его удобство. В нем каждое письмо это отдельный файл, который можно посмотреть любым текстовым редактором. Эти файлы удобно бэкапить, анализировать содержимое, сортировать по каким-то признакам. В общем, с ними можно работать как с обычными текстовыми файлами. На основе этих плюсов и выполняется вся дальнейшая работа в статье. Из минусов вижу только один — огромное количество мелких файлов создают большую нагрузку на дисковую подсистему.
Приведу для наглядности пример, который позволит оценить нагрузку на диски. Для синхронизации с помощью rsync почтовой базы объемом примерно 1 терабайт, расположенной на raid10 обычных 3.5 sata дисков, на одиночный такой же диск для бэкапа, уходит где-то пару часов в основном на сравнение файлов между источником и приемником. Само копирование файлов проходит быстро, но чтобы сравнить изменения за день, приходится выполнять длительную операцию. При этом в целом работа пользователей (~30-40 человек) с этой базой вполне комфортна, каких-то тормозов не наблюдается.
То есть по сути, для такого количества пользователей, сервером может быть обычный десктопный компьютер с 2-4 обычными sata дисками. Хватит производительности любого процессора и примерно 2-4 гигабайта оперативной памяти. Отдельный вопрос, конечно, к надежности обычного системника. Я сервера на них не рекомендую собирать, но при большом желании можно.
Приведенные далее скрипты для очистки почтовой базы писались в разное время на разных серверах. Иногда может показаться, что все сделано нелогично или как-то сложно. Громоздкие конструкции часто возникали там, где появлялись проблемы с пробелами или спецсимволами в именах папок на русском языке, которые при переводе в UTF-7 (кодировка названия imap папок в dovecot) превращаются в весьма неудобные для обработки строки. Дальше будет понятно, что я имею ввиду.
Перейдем теперь к конкретным примерам.
Переключение на новый сервер
Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы 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 за все время админства. Можно сказать руку набил.
BCC копии всех писем, отправленных из родных доменов
возможны, благодаря тому, что можно указать несколько значений в recipient/sender_bcc_maps. Для копий отправленных, далее будет рассмотрен sender_bcc_maps.
BCC с его помощью можно создавать для ВСЕХ отправленных писем (с родными доменами), — в т.ч. и писем незарегистрированных пользователей, а также писем, отправленных из разных источников (но с использованием родного MTA).
Параметр sender_bcc_maps позволяет указать несколько значений, перечисленных через запятую. Эксперименты показали следующее: когда обрабатывается sender_bcc_maps с несколькими значениями, то сначала выполняется запрос указанный первым. Кроме того, если запрос вернул какое-то значение, то перехода к следующему — не происходит. Если же запрос не вернул строк — происходит переход к следующему запросу. Если ни один запрос не вернул строк, то отправка авто-BCC так и не состоится.
КСТАТИ! В маппинге алиасов Postfix ведет себя по-другому. Там, если первый запрос вернул значение отличное от запрашиваемого, — будет обработан следующий запрос.
Итак, задачу полного контроля над отправленными письмами можно решить двумя запросами:
- Первым запросом возвращать адрес отправителя только в том случае если он найден в таблице mailbox SQL-базы PostfixAdmin.
- Вторым запросом возвращать адрес специального единого ящика (например: «[email protected]») для неизвестных отправителей, но только в том случае, если доменная часть адреса отправителя найдена в таблице domain SQL-базы PostfixAdmin. И не возвращать ничего если отправитель «чужой».
В таком варианте, все входящие извне письма с «чужими» отправителями будут игнорироваться и авто-BCC срабатывать не будет.
Это может выглядеть примерно так (один из примеров упрощен, — см. доработанный пример, в котором изменена выделенная часть)
... sender_bcc_maps = mysql:/etc/postfix/mysql_bcc_mailbox_maps.cf,mysql:/etc/postfix/mysql_bcc_domain_maps.cf ...
user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_
password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_
hosts = 127.0.0.1
dbname = _ИМЯ_БАЗЫ_
query = SELECT username FROM mailbox WHERE username=’%s’ AND active = ‘1’
user = _ИМЯ_ПОЛЬЗОВАТЕЛЯ_MySQL_ password = _ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_MySQL_ hosts = 127.0.0.1 dbname = _ИМЯ_БАЗЫ_ query = SELECT '[email protected]' FROM domain WHERE domain='%d' AND active = '1'
Запрос /etc/postfix/mysql_bcc_mailbox_maps.cf по-видимому совпадает с запросом пользователя для параметра virtual_mailbox_maps = , т.е. может использоваться он-же.
Итак, имеем здесь для всех известных отправителей родных доменов — авто-BCC в их ящик, а также авто-BCC для всех неизвестных отправителей родных доменов — в специальный единый ящик. При этом отправители «чужих» доменов (входящая извне почта) — игнорируются.
Будут сохранены не только письма, отправленные не зарегистрированными в PostfixAdmin системными пользователями, но и письма активированных зарегистрированных пользователей, отправленные удаленными MUA (через родной MTA), или отправленные другими способами (например сгенерированные сайтом.)
Есть у этого решения один минус — будет выполняться два запроса не только для неизвестных отправителей родных доменов, но и для всех входящих писем «чужих» отправителей.
Отправка писем — общие сведения в контексте рассматриваемой конфигурации
Для начала одно важно замечание. Отправка письма состоит из двух этапов (сессий): прием письма от MUA и отправка письма далее по назначению
В первом случае Postfix выступает в роли сервера, во втором — в роли клиента. Таким образом может получиться так, что письмо будет принято к отправке от MUA но так и не уйдет. При этом MUA будет «ложно информирован» о том, что письмо якобы ушло и даже может поместить его в папку «Отправленные».
Есть два способа начать отправку почты. Подключиться изнутри на 25 порт, используя Postfix как релей (это разрешено для доверенных сетей, и локальный адрес 127.0.0.1 как раз относится к доверенным), или подключиться на 587 порт (Postfix) который как раз предназначен только для приема почты, которую необходимо отправить.
В первом случае (25 порт) аутентификация не требуется вообще (для localhost), во втором случае (587 порт) требуется не только аутентификация, но и обязательно использование TLS/SSL шифрования. Второй вариант можно, при необходимости, в любой момент открыть для доступа снаружи т.к. он достаточно защищен для этого. Первый вариант, упрощенный, удобен для использования сайтом или MUA установленным в той же локальной системе (хотя в описываемой конфигурации это не так — локальный MUA работает через 587 порт и использует шифрование, — это сделано для того, чтобы в будущем иметь возможность быстрее перенести его на другой сервер без дополнительной перенастройки, если это понадобится). Второй вариант (587 порт) здесь предусмотрен больше для задела на будущее — когда понадобится использование удаленного MUA (Outlook, Bat и т.п.).
В этом случае такое разделение функций между портами повышает общую надежность системы.
Шаг 4 — Переадресация системной почты
На этом шаге мы настроим переадресацию электронной почты для пользователя , чтобы сгенерированные системой сообщения, отправляемые на этот адрес, пересылались на внешний адрес электронной почты.
Файл содержит список альтернативных имен получателей электронных писем. Откройте его для редактирования:
По умолчанию он выглядит так:
/etc/aliases
Единственная содержащаяся в нем директива предписывает пересылать сгенерированные системой электронные сообщения пользователю .
Добавьте в конец файла следующую строку:
/etc/aliases
Для вступления изменений в силу выполните следующую команду:
При запуске команды будет построена база данных псевдонимов, используемых командой . Эти псевдонимы берутся из файла конфигурации, который вы только что отредактировали.
Протестируйте отправку электронных писем пользователю с помощью следующей команды:
Письмо должно прийти на указанный вами почтовый ящик. Если его там нет, проверьте папку «Нежелательная почта».
На этом шаге мы настроили переадресацию сгенерированных системой сообщений на ваш адрес электронной почты. Теперь мы можем включить шифрование сообщений, чтобы все отправляемые вашим сервером электронные письма были защищены от модификации во время пересылки и считались легитимными.
Установка Dovecot
Я уже давно для себя выбрал CentOS как основу для серверов. Поэтому все команды установки софта будут именно для этой операционной системы. Я крайне не советую ставить основные программы из исходников командами типа make, make install и т.д. Это приведет только к невозможности получения обновлений в удобной форме.
В процессе отладки я наступал на разные грабли, список которых выделил в отдельную страницу «размышления по ходу отладки». Не поленитесь, посмотрите, вдруг что-то пригодится.
yum install dovecot
yum install dovecot-mysql
chkconfig dovecot on
Вот и все, дальше надо настраивать конфиг.
Порты
Все ненужные порты можно закрыть снаружи Iptables (+ использовать некоторые дополнительные средства защиты, которые выходят за рамки темы). Закрыть не столько снаружи, но и изнутри. Во внешний мир и для внешнего мира (это две разные ситуации) для почты обязательно должен быть открыт только SMTP — 25 порт (для MTA). Внутри, за Iptables всё может быть немного по-другому.
Почтовые службы могут быть настроены например так (перечислено не все):
# sockstat -l USER PROCESS PID PROTO SOURCE ADDRESS FOREIGN ADDRESS STATE ... opendkim opendkim ... tcp4 127.0.0.1:8891 *:* LISTEN clamav clamav-milter ... tcp4 127.0.0.1:10026 *:* LISTEN root /usr/sbin/postg ... tcp4 127.0.0.1:10023 *:* LISTEN root dovecot ... tcp4 127.0.0.1:143 *:* LISTEN root dovecot ... tcp4 127.0.0.1:4190 *:* LISTEN root master ... tcp4 127.0.0.1:25 *:* LISTEN root master ... tcp4 IP.IP.IP.IP:25 *:* LISTEN root master ... tcp4 127.0.0.1:587 *:* LISTEN root master ... tcp4 IP.IP.IP.IP:587 *:* LISTEN ...
Здесь видно, что POP вообще отключен. IMAP (:143) висит только на внутреннем интерфейсе (это нормально, пока внешнего MUA-клиента нет) и отвечает за него — Dovecot.
Postfix слушает порт 25 (SMTP) на внешнем и внутреннем интерфейсе. Его основная функция — принимать почту для своего и только своего домена, а также отправлять свою и только свою почту.
587 порт тоже слушается Postfix на обоих интерфейсах и сконфигурирован на подключение MUA для отправки почты (отправляет ее наружу Postfix потом все равно с 25 порта, а ожидает ее от MUA для отправки — на 587).
При использовании только локального MUA, 587 порт можно закрыть для доступа снаружи, посредством Iptables (потом открыть в любой момент при необходимости).
LMTP работает через UNIX-сокет:
# netstat -l -p | grep lmtp ... unix 2 STREAM LISTENING ... .../dovecot /var/spool/postfix/private/dovecot-lmtp ...
Тестирование с использованием postmap
Предположим, что: «[email protected]» — зарегистрированный активный ящик, «[email protected]» — еще один зарегистрированный активный ящик, «[email protected]» — незарегистрированный или неактивный ящик, «domain.tld» — родной домен, «[email protected]» — чужой ящик чужого домена.
Используем примеры из предыдущего раздела для проверки SQL-запросов через консоль (показан ввод и вывод).
-
Зарегистрированный ящик в родном домене.
Должно вернуть имя зарегистрированного ящика в первом же запросе:
# postmap -q [email protected] /etc/postfix/mysql_bcc_mailbox_maps.cf
Второй запрос использован не будет. Копия отправленного письма будет доставлена через авто-BCC в зарегистрированный ящик отправителя («[email protected]»).
-
Незарегистрированный ящик в родном домене.
Нет значения для незарегистрированного ящика (родного домена) в первом запросе:
# postmap -q [email protected] /etc/postfix/mysql_bcc_mailbox_maps.cf
Но есть значение для незарегистрированного ящика (родного домена) во втором запросе
# postmap -q [email protected] /etc/postfix/mysql_bcc_domain_maps.cf
Копия отправленного письма будет доставлена через авто-BCC в ящик «[email protected]».
-
Чужой ящик чужого домена.
Нет значения для неизвестного ящика (чужого домена) в первом запросе:
# postmap -q [email protected] /etc/postfix/mysql_bcc_mailbox_maps.cf
Нет значения для неизвестного ящика (чужого домена) во втором запросе
# postmap -q [email protected] /etc/postfix/mysql_bcc_domain_maps.cf
Копия письма не будет отправлена.
Dovecot
В заметке, являющейся частичным переводом из официальной документации к «Dovecot 2»: Dovecot 2 — Sieve, описаны расширения плагина Pigeonhole Sieve, которые реализуют автоответчик «я в отпуске» — vacation и vacation-seconds. Второе расширение является дополнением к первому, добавляя возможность настраивать интервалы ответов в секундах. Оба включены по умолчанию в плагине Pigeonhole Sieve, который представляет из себя поддержку языка Sieve для Dovecot, пользовательский доступ к персональным правилам (ManageSieve), а также расширения и некоторые другие плагины.
В упомянутой заметке, раздел посвящен описанию работы автоответчика, создаваемого путем написания и подключения скрипта, пример которого приведен ту же. Кроме того описана логика работы Vacation и разобраны механизмы, которые он реализует.
КСТАТИ! Пакет из репозитариев Debian libnet-sieve-script-perl дает возможность читать, анализировать и записывать Sieve-файл сценария, организуя доступ к правилам, действиям и условиям объектов.
Установка.
Подготовка к установке
Я устанавливал iRedmail на ubuntu 14.04 TLS. Первым делом нам необходимо скачать дистрибутив, для этого мы идём на сайт iredmail.org и в разделе download берём ссылку на архив с почтовиком.
Затем загружаем его, я буду загружать в каталог /home/alexey/
cd /home/alexey
wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.2.tar.bz2
|
1 |
cdhomealexey wget https//bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.2.tar.bz2 |
Распаковываем
tar xjf iRedMail-0.9.2.tar.bz2
| 1 | tar xjf iRedMail-0.9.2.tar.bz2 |
Перед установкой мы должны привести запись с адресом нашего сервера в файле /etc/hosts к виду
127.0.0.1 mail.cmp.local mail localhost
| 1 | 127.0.0.1mail.cmp.local mail localhost |
т.е. обязательно должен быть FQDN адрес что-нибудь.домен.зона иначе установщик не запустится. На работу сервер, поскольку он у нас внутренний, этот адрес никакого значения не оказывает. Для редактирования набираем
sudo nano /etc/hosts
| 1 | sudo nanoetchosts |
осле внесение изменений сохраняем -> Ctrl+O и выходим Ctrl+X
Затем нам необходимо дать права на запуск установочного скрипта, и собственно запустить его из под рута.
cd iRedMail-0.9.2/
chmod +xX iRedMail.sh
sudo ./iRedMail.sh
|
1 |
cd iRedMail-0.9.2 chmod+xX iRedMail.sh sudo.iRedMail.sh |
Мастер установки
После чего начнётся процесс установки, для установки на машине должен быть интернет. Процесс установки будут сопровождать разные вопросы, например первый вопрос устанавливать ли iRedmail? Конечно отвечаем Yes.
Задаём пароль для root записи к серверу MySql.
На следующем шаге у нас узнают директорию для хранения писем, я оставил всё как есть, жмём Next.
После этого установщик интересуется какой сервер устанавливать, поскольку в дальнейшем нам понадобится phpmyadmin я выбрал Apache
Какую базу будем использовать? Мне ближе и понятней MySql.
Указываем имя почтового домена (то что будет идти после @). У меня это будет cmp.local
Назначаем пароль для учётной записи администратора почтового сервера. С помощью это учётной записи позже мы сможешь создавать новые почтовые ящики.
Проверяем какие компоненты будут установлены. Поскольку я не планирую давать доступ к почтовому серверу из вне я уберу компонент Fail2ban, остальное оставлю по умолчанию.
Проверяем какие компоненты будут установлены. Поскольку я не планирую давать доступ к почтовому серверу из вне я уберу компонент Fail2ban, остальное оставлю по умолчанию.
Нас предупреждают что в файле /home/alexey/iRedMail-0.9.2/config хранятся важные сведения, такие как логины и пароли дающие различные привилегии и напоминают что не мешало бы этот файл удалить. Хотя для особо забывчивых может лучше и оставить, но точно переместить в безопасное место. Соглашаемся вводим y и жмём enter.
Начнётся процесс установки по окончании которого будет ещё вопрос использовать ли правила фаервола предоставленные iRedMail, не вижу смысла отказываться, соглашаемся.
А так же перезагрузить ли фаервол, снова отвечаем да. И получаем окошко с поздравлением об успешной установке iRedMail и напоминанием что не мешало бы перезагрузить систему.
Ok, перезагружаем.
sudo reboot
| 1 | sudo reboot |
Дополнительные компоненты
На этом установка iRedMail завершена, но не завершён раздел статьи установка, нам осталось установить phpmyadmin, потому что часть настроек хранится в MySql и недоступна для настройки через web интерфейс iRedMail’a. Устанавливаем phpmyadmin.
sudo apt-get install phpmyadmin
| 1 | sudo apt-get install phpmyadmin |
Соглашаемся с тем что будут установлены дополнительные пакеты и будет использовано дисковое пространство. И выбираем веб сервер, у нас напоминаю apache2
На это шаге нас предупреждают о том что phpmyadmin для работы требуется установленная и настроенная база, соглашаемся
Вводим пароль от учётной записи root для mysql (указывали при установке iredmail)
Здесь нам предлагают ввести пароль для учетной записи phpmyadmin для доступа к базе, или оставить поле пустым что бы пароль был сгенерирован, оставляем пустым
На этом я считаю раздел установки закончен. Переходим к добавлению пользователей.
Пересылка на другой почтовый ящик
Открываем конфигурационный файл:
vi /etc/postfix/main.cf
Добавляем следующее:
virtual_alias_maps = hash:/etc/postfix/virtual
* при данной настройке все входящие сообщения будут копироваться по правилам в файле /etc/postfix/virtual.
Теперь открываем данный файл и вносим, примерно, следующее:
vi /etc/postfix/virtual
[email protected] [email protected]
* при данной настройке все сообщения, отправленные на [email protected] будут перенаправлены на [email protected].
Создаем карты:
postmap /etc/postfix/virtual
И перезапускаем почтовый сервер:
systemctl restart postfix
Шаг 1 — Установка Postfix
На этом шаге мы выполним установку Postfix. Быстрее всего будет установить пакет , включающий Postfix и несколько дополнительных программ, которые можно использовать для тестирования отправки электронной почты.
Вначале обновите базу данных пакетов:
Затем выполните установку Postfix, запустив следующую команду:
Перед окончанием установки вы увидите окно настройки конфигурации Postfix:
По умолчанию используетя опция (сайт). Это наиболее подходящая опция для нашего случая, поэтому нажмите , а затем нажмите . Если вы увидите только текст описания, нажмите для выбора пункта , а затем нажмите .
Если опция не отображается автоматически, запустите следующую команду:
После этого откроется еще один диалог настройки конфигурации System mail name (имя системной почты):
Имя системной почты System mail name должно совпадать с именем, которое вы присвоили своему серверу при его создании. После завершения настройки нажмите , а затем нажмите .
Мы установили Postfix и готовы приступить к настройке.
По домену через другой SMTP
Открываем на редактирование конфигурационный файл postfix:
vi /etc/postfix/main.cf
Редактируем или дописываем:
transport_maps = hash:/etc/postfix/transport_map
Теперь нужно открыть на редактирование файл транспорта:
vi /etc/postfix/transport_map
И добавить:
dmosk.ru smtp::25
[email protected] smtp::25
* где dmosk.ru — домен, для отправки на который используется другой сервер пересылки, а 10.10.10.10 — IP-адрес другого сервера SMTP. [email protected] и mail.mailsystem.ru — конкретный адрес электронной почты и сервер для его пересылки.
После создаем карту:
postmap /etc/postfix/transport_map
И перезапускаем postfix:
systemctl restart postfix
Конфигурируем Dovecot
Файл /etc/dovecot/dovecot.conf Нужно убедится в том, что все строки закомментированы и добавить следующее
!include_try /usr/share/dovecot/protocols.d/*.protocol
#Разрешаем авторизацию в plaintext
disable_plaintext_auth = no
# Журнал будем писать в файл /var/log/dovecot.err
log_path = /var/log/dovecot.err
# Формат даты и времени для регистрируемых событий
log_timestamp = "%Y-%m-%d %H:%M:%S "
#Включаем SSL
ssl = yes
# Порядок следования сертификатов имеет большое значение: сначала *.key, затем *.cert.
ssl_key =< /etc/dovecot/mail_volmed_org_ru.key
ssl_cert =< /etc/dovecot/mail_volmed_org_ru.cert
#Строка приветствия при ответе сервера
login_greeting = Dovecot ready.
#Описываем тип (maildir) и местонахождения почтовых ящиков (/var/spool/mail/%d/%n) %d - имя сервера, %n - имя пользователя
mail_location = maildir:/var/spool/mail/%d/%n
#Задаем идентификатор пользователя и группы, с которыми будет работать dovecot
mail_uid = 5000
mail_gid = 5000
mail_privileged_group = mail
valid_chroot_dirs = /var/spool/mail/
#Настраиваем вывод отладочных сообщений
auth_verbose = yes
auth_debug = yes
auth_debug_passwords = yes
#Типы допустимых вариантов аутентификации
auth_mechanisms = plain login digest-md5
#Задаем параметры аутентификации
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
service auth {
unix_listener auth-master {
mode = 0660
user = virtual
group = virtual
}
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
port = 993
ssl = yes
}
}
Настраиваем параметры соединения с базой данных MySQL. Редактируем /etc/dovecot/dovecot-sql.conf. Пишем туда следующее:
driver = mysql connect = host=127.0.0.1 dbname=mail user=mail_admin password=mail_admin_password default_pass_scheme = CRYPT password_query = SELECT email AS user , password FROM users WHERE (user = '%u') or (email = '%u');
Проверяем конфигурацию Dovecot
dovecot -a
MUA и ManageSieve
Автоответчик может быть задействован в т.ч. и в пользовательском почтовом клиенте — MUA. Например для RoundCube существует плагин rcubevacation, с FTP, SSHFTP, Setuid backends с поддержкой .forward и SQL.
См. раздел в заметке Полный пример установки всех пакетов и настройки конфигурационных файлов.
Кроме того, для того же RoundCube, к примеру, есть плагин managesieve, который позволяет использовать ManageSieve-сервер для сохранения пользовательских скриптов + имеет визуальный интерфейс, в котором эти правила можно создавать мышкой, не вникая в суть языка Sieve. Причем правила доступны достаточно сложные, с разным количеством условий и действий по результатам этих условий. В числе прочих стандартных элементов там есть функции автоответчика. Эти правила работают даже «в отсутствие пользователя». Т.е. Dovecot обрабатывает самостоятельно письмо при приеме, а не в момент подключения MUA. Это, например означает, что если в правилах стоит «Отбросить с сообщением…» (там есть такой стандартный элемент), то письмо будет принято Postfix, помещено в очередь, но Dovecot его не доставит в папку, и оно будет удалено, после чего будет создано ответное письмо с заданным в правиле текстом, которое будет отослано от «Mail Delivery Subsystem» (с соответствующим обратным адресом) отправителю. Подмена обратного адреса позволяет избежать зацикливания (см. следующий раздел). Обратный адрес в письме от автоответчика встречается в заголовке в виде «Return-Path: «, а в поле «From: » адрес берется из параметра настройки postmaster_address = [email protected] используемого агента доставки (для lmtp этот параметр указывается в файле , в секции ). Тестирование упомянутого плагина RoundCube managesieve с настроенным автоответчиком в пределах одного домена показало, что даже письма отправленные на «Mail Delivery Subsystem» ([email protected]), с двумя встречными автоответчиками к зацикливанию не приводило (письмо просто терялось). Письмо отправленное из «чистого» внешнего ящика на автоответчик несколько раз подряд, приводило к его постоянному срабатыванию.
КСТАТИ! В репозитариях Debian доступен пакет: php-net-sieve.
Должен сказать, что когда я добрался до ManageSieve, то у меня отпало всякое желание изучать другие механизмы. 
Настолько легко, просто и гибко можно всё делать с использованием этого плагина. К счастью это произошло в самом конце моих исследований и я успел все-же кое-что изучить до того, как это желание пропало.
См. также заметку Dovecot 2 — Sieve и разделы в ней: , и .
Еще несколько примеров работы с почтовой базой
Этот пример будет актуален, если вы используете почтовые ящики, куда копируется абсолютно вся переписка вашего сервера. Допустим, у вас есть ящик [email protected], куда сохраняется вся уходящая корреспонденция. Если на сервере идет активная переписка, то писем в ящике будет много и искать с помощью какого-то imap клиента будет неудобно, так как он может либо тормозить на большом списке писем, либо вообще отваливаться по таймауту и поиск или сортировка будут невозможны с его помощью. Тогда на помощь придут простые скрипты в консоли сервера. Найдем в этом ящике все письма, отправленные в период между первым и седьмым сентября 2017 года и скопируем их в отдельный ящик.
find /data/mail/virtual/[email protected]/Maildir/*/ -newerBt '2017-09-01 00:00' -and -not -newerBt '2017-09-07 00:00' -and -type f | cpio -pdmv /data/mail/virtual/[email protected]/Maildir/new
По сути тут просто использовались ключи к команде find. У нее их так много, что я для всех прикладных задач всегда храню готовые конструкции, чтобы заново не вспоминать все ключи и возможности.
Еще полезно бывает посмотреть размер почтовых ящиков. Некоторые пользователи имеют в разы больший объем ящика, чем все остальные. Есть любители хранить в почте презентации, пересылать разбитые на части архивы и т.д. Иногда приходится вручную проверять размеры ящиков, чтобы отдать команду на очистку заполненных сверх меры. Сделать это можно простой командой в директории с ящиками:
# du --max-depth=1 | sort -n -r
Команда выведет размеры всех ящиков и отсортирует их по мере увеличения объема, но при этом объем покажет в байтах, что не очень удобно. Можно вывести директории по алфавиту, но с размером в привычных мегабайтах или гигабайтах, но уже без сортировки.
# du -h --max-depth=1
Еще удобнее отправить сразу вывод в текстовый файл с датой в имени файла, чтобы потом было удобно сравнить с тем, что получилось после чистки почтовой базы.
# du -h --max-depth=1 >> "dirsize_`date +"%Y-%m-%d_%H:%M"`.txt"
Тут можно придумать много всяких способов отсортировать данные для более удобного восприятия, или потом автоматически сравнить размеры ящиков. Я не занимался этим.
