главная - Статьи - Почта - Postfix + Dovecot + MySQL

Настройка Dovecot - размышления по ходу отладки

Сюда я буду помещать замечания о проблемах и особенностях, которые мне встретились, во время установки и эксплуатации почтового сервера в классической связке "Dovecot + MySQL + Postfix". Этот набор я ставил уже не раз, поэтому описанные ниже особенности не затрагивают "косяков" отдельно взятого компьютера. Начало летописи идет с сентября 2011 года.

Обращаю отдельное внимание на то, что синтаксис Dovecot 2.* отличается от синтаксиса Dovecot 1.*. Большинство руководств по настройке написаны давно либо являют собой реинкарнацию старых или чужих мануалов. Поэтому сначала постарайтесь понять, для какой версии Dovecot вы читаете руководство по установке.

Цель: создать простой и легко переносимый почтовый сервер POP/IMAP/SMTP безо всяких наворотов типа антиспама, антивируса и пр. Поэтому никаких пакетов, кроме Postfix, MySQL и Dovecot я не использую.

Перенос такого почтового сервера будет включать в себя копирование конфига Dovecot (2 файла), Postfix (4-6 файлов), MySQL (папка базы данных), папки почты пользователей.

Сразу приведу несколько внешних ресурсов, которые мне пригодились:
http://blog.scaytrase.ru/linux/301/
http://wiki2.dovecot.org/AuthDatabase/SQL
http://wiki2.dovecot.org/MailLocation
http://maint.unona.ru/doc/dovecot2.shtml
http://workaround.org/ispmail/lenny
http://redhat-club.org/
Dovecot - это фактически способ хранить почту на сервере и предоставить доступ к этой почте авторизованным пользователям. Чтобы Dovecot получил эту почту, ее надо ему передать. Для этого есть МТА, в моем случае Postfix. Проще говоря, сам по себе Dovecot - один в поле не воин.
Я не могу пошагово выполнять действия из чужих руководств - мне неинтересно и непознавательно. И то, и другое одинаково весомо. Поэтому при начальной установке я не использовал за основу каких-либо пошаговых руководств по настройке Dovecot. Внешние ресурсы понадобились чуть позже и их роль была примерно такая: есть идея в голове или вопрос - ищу похожие примеры. В моем подходе есть минус - если вы не разбираетесь (или не хотите копаться) в логах, проблемах и пр. - вы гарантированно получите кучу проблем! Придется подгонять то, что у вас есть, к тому, что вы найдете потом. Также можно получить полную кашу в голове от того. что у вас ничего не работает, а копипастить настройки из пошаговых руководств уже поздно! Но есть и плюс - когда вы прочувствуете основные настройки, поймете, как они связаны (порой, скорее ментально ;)) друг с другом, вы получите именно то, что нужно вам, а не было нужно кому-то, кто в свою очередь списал что-то у других.
Dovecot версии 2.0.beta6 я устанавливаю на CentOS 6 x86 на VDS-хостинге. Dovecot будет брать информацию о виртуальных пользователях из базы данных MySQL, установленной заранее и связанной с Postfix. Т.е. сейчас буду ставить финальный штрих - Dovecot, привязывать его к уже существующей базу данных MySQL и Postfix.
Для хранения и отправки почты используется специально созданный пользователь vmail (gid 500, uid 500). От имени этого пользователя Dovecot будет сохранять почту в почтовые ящики, а Postfix будет отправлять почту.
Устанавливаю Dovecot через менеджер пакетов yum. Не экспериментируйте с make, configure и прочими оптимизациями. Воспроизвести такую установку и отладку, а также обновить будет на порядок сложнее, если вы, конечно, не очень профессиональный администратор Linux.

yum install dovecot yum install dovecot-mysql
На уже настроенной конфигурации я целый день не мог понять, почему отправленные письма (причем авторизация прошла успешно) не приходят в почтовый ящик. Оказалось, все дело в том, что в правах доступа на лог-файл /var/log/dovecot.log стоял root, а надо было vmail.

Postfix при отправке ДОЛЖЕН иметь возможность ЗАПИСИ в этот лог-файл. Postfix осуществляет авторизацию средствами Dovecot от имени непривилегированной учетной записи vmail. Я думал, что можно потом разобраться, все-таки лог - это просто лог. А вот и нет! Как только я поменял права доступа на лог-файл, я получил сразу все письма, отправленные за вчерашний день!
Для исключения лишних проблем при отладке, все пароли передаются открытым текстом, в базе данных хранятся также в открытом виде. Это, вообще говоря, не порядок.
Актуально для тех, у кого будет несколько виртуальных доменов на одном сервере, т.к. в этом случае у вас логин будет равняться "email@domain".

Во время обработки полученных логина и пароля, Dovecot может отбросить доменную часть логина и дальнейшая аутентификация не пройдет. Вопрос (как и решение) по этому поводу я разместил на форуме opennet. Проблема описана на странице http://wiki2.dovecot.org/AuthDatabase/SQL в абзаце:

By default MySQL does case-insensitive string comparisons, so you may have a problem if your users are logging with different as "user", "User" and "uSer". To fix this, you can make the SQL database return a "user" field, which makes Dovecot modify the username to the returned value. Note that if you're using separate user and domain fields, a common problem is that you're returning only the "user" field from the database. This drops out the domain from the username. So make sure you're returning a concatenated "user@domain" string or username/domain fields separately. See the examples below.

Решение этого: в файле /etc/dovecot/dovecot-mysql.conf изменить (если это необходимо) запрос пароля:

#Исходный запрос закомментирован #password_query = SELECT username AS user,userpassword AS password FROM virtual_users WHERE username = '%n' AND userrealm = '%d' AND active='1' password_query = SELECT username AS user,userrealm AS domain,userpassword AS password FROM virtual_users WHERE username = '%n' AND userrealm = '%d' AND active='1'
Если не сделать выборку доменной части, в дальнейшем Dovecot ее потеряет (переменная %d будет пустой) и запрос пользовательских настроек не будет выполнен:

user_query = SELECT CONCAT(username,'@',userrealm) AS user, '500' AS uid, '500' AS gid FROM virtual_users WHERE username = '%n' AND userrealm = '%d' AND active='1'
Отдельно хочу сказать о проблеме, которая чуть не свела меня с ума. Привожу часть конфига /etc/dovecot/dovecot.conf

service auth {
unix_listener /var/spool/postfix/dovecot-auth {
   user = postfix
   group = postfix
   mode = 0660
}
unix_listener auth-master {
   user = vmail
   group = vmail
   mode = 0660
}
unix_listener auth-userdb {
   user = vmail
   group = vmail
   mode = 0660
}
#user=root
}

Обратите внимание на выделенную жирным закомментированный параметр user=root. Во время отладки авторизации Postfix через Dovecot, мне пришлось раскомментировать этот параметр, т.к. иначе постоянно были проблемы доступа к сокету. Потом я закомментировал его. Все должно работать без него. Чем меньше root, тем правильнее вы все настроили.
Добавлено 04.04.2012. Специально не стал удалять предыдущий пункт (№10) - себе в назидание. Вся проблема с доступами к сокету, оказывается, просто в том, что по-умолчанию Dovecot предлагает сделать не так, как решил делать я. Вот как это предлагается в Dovecot по-умолчанию:

service auth {
   unix_listener /var/spool/postfix/private/auth {
   user = postfix
   group = postfix
   mode = 0660
}
...
И вот что должно соответствовать этому в файле /etc/postfix/main.cf:

smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth
Я всегда считал (почему - вопрос интересный), что private/auth это не часть пути, а типа условных слов "частный доступ/с авторизацией"!!! Нет, это просто фантастика! Сейчас полез все-таки прочитать про эту ерунду в /usr/share/doc/Postfix-2.6.6/README_FILES/SASL_README. Со строки 181 я стал медленно сползать под стол: private/auth - это относительный путь. Относительно пути до директории очереди Postfix, т.е. /var/spool/postfix. Господа, это только лишний раз доказывает, что где-то увиденное - не обязательно истина в последней инстанции. И мой сайт bozza.ru также может содержать опечатки и ошибки. Очень жаль, что никто не обратил на это внимание раньше. Но главное, что это стало ясно хотя бы сейчас, спустя месяцы и совершенно случайно... Я подкорректировал этот пункт в настройке Postfix.
Добавлено 09.04.2012. Два дня пытался решить проблему, из-за которой не создавались папки почты. Я грешным делом подумал, что проблема в том, что vmail:vmail не имеет прав записи в папку /var. Перенес папку почты из /var/vmail в /vmail - результата нет. Вот что было в лог-файле:

*************************************
imap-login: Info: Login: user=<test@virtual.local>, method=PLAIN, rip=192.168.2.113, lip=192.168.2.105, mpid=3284
imap: Debug: Loading modules from directory: /usr/lib/dovecot
imap: Debug: Module loaded: /usr/lib/dovecot/lib20_autocreate_plugin.so
imap: Debug: Added userdb setting: mail=maildir:/vmail/virtual.local/test
imap(test@virtual.local): Debug: Effective uid=5000, gid=5000, home=/vmail/virtual.local/test
imap(test@virtual.local): Debug: Home dir not found: /vmail/virtual.local/test
imap(test@virtual.local): Debug: maildir++: root=/vmail/virtual.local/test, index=, control=, inbox=/vmail/virtual.local/test
imap(test@virtual.local): Debug: Namespace : Permission lookup failed from /vmail/virtual.local/test
imap(test@virtual.local): Debug: Namespace : Using permissions from /vmail/virtual.local/test: mode=0700 gid=-1
imap(test@virtual.local): Error: user test@virtual.local: Initialization failed: Initializing mail storage from mail_location setting failed: mkdir(/vmail/virtua
l.local/test) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /vmail, euid is not dir owner)
Apr 05 20:59:55 imap(test@virtual.local): Error: Invalid user settings. Refer to server log for more information.
*************************************

Самое главное: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /vmail, euid is not dir owner)

Я даже права 777 давал на папку /vmail - нет результата.

На форуме opennet.ru мне подсказали, что проблема может быть в том, что в CentOS 6 папки может не давать создавать SELinux. Отключил SELinux - все работает!
Добавлено 28.04.2012. Вообще, может и не супер, но хранение паролей в открытом виде в базе данных дает максимальную степень простоты настройки и, самое главное, взаимодействия компонентов, таких как Dovecot, MySQL, Postfix, PostfixAdmin, Roundcube, возможно, и других тоже. Я не специализируюсь на почтовых серверах, поэтому вполне допускаю, что есть достаточно сработанные и удобные схемы шифрования паролей, типа CRAM-MD5 и пр. Если у вас, дорогие читатели, есть свой опыт - я только рад, если вы рискнете высказывать его вслух.

Авторизуйтесь для добавления комментариев!