plesk, spamassasin и нестандартная директория для почты

Этот plesk у меня никогда не закончится.

Когда я устанавливал панель (предварительно ознакомившись с документацией), из этой самой документации я не совсем правильно понял фразу

if you want to use a separate partition for Panel, mount the partition to /opt/psa/

Понадеялся, что все, что относится к плеску, будет установлено туда. Разметку диска производил соответственно. Но оказалось, что, например, почту он все равно собирается хранить в привычной директории /var/qmail/mailnames (даже если при установке мы выбрали postfix и никакого qmail'a у нас нет). Переустанавливать и переразмечать все это хозяйство очень не хотелось, т.к. это требовало еще и поездки в дата-центр (сервер не был подключен к IP-KVM, а IMM у него был без лицензии на эту фичу). Путем недолгого гугления нашлась вот эта статья на сайте Parallels. Немного смутило то, что она для 9 и 10 версий, но про 11 ничего найти не удалось.

Выполнил все, как было написано в статье, после чего смигрировал аккаунты на этот сервер. Все хорошо, почта лежит там, где я это указал в /etc/psa/psa.conf и ничего не предвещает беды.

Но когда дело дошло до spamassasin, все пошло не так. Суть в том, что вроде он и работает, но явный спам проскакивает во входящие, так к нему еще и почему-то не добавляются заголовки от SA. При этом заголовки вполне себе присутствуют в легитимных письмах.

В логах нашлось следующее:

spam_hook[32577]: Exiting with exit code: 75
spam_hook[32577]: Unable to delivery message into Spam folder

Как это? Почему нельзя? Непонятно. Директория есть, права есть, все вроде хорошо.
На директиву save в user_prefs, кстати, spamassasin не реагировал.

Тут-то я и вспомнил о перемещении Maildir'ов, о котором писал в начале.
В результате проблему удалось решить одной короткой командой:

ranzhe@plesk:~$ sudo ln -s /opt/psa/mail/mailnames /var/qmail/mailnames

Т.е. где-то в хуке для spamassasin'a безобразно захардкодили путь, из-за чего оно и не работало.
Вот и верь после этого документации.

И снова plesk, теперь file (fail?) sharing

В общем-то, я наверное даже готов поверить в то, что все мои проблемы с плеском - следствие миграции с 9.5.4 на 11.0.9, но на то были свои причины и выбора особо не было.

Через некоторое время после миграции начала вылезать неприятная (и непонятная, впрочем, тоже) ошибка: при попытке сменить пароль на каком-либо из смигрированных почтовых аккаунтов, панель ругалась примерно так:

unable to execute file-sharing : empty error message from utility

Но вот ведь какое дело: на старом сервере не было никакого файл-шаринга, да и не нужен он и на новом, но попытки отключить его путем снятия соответствующих галок в настройках панели (Server - File Sharing - Enable Public Files) заканчивались тем, что галки эти после перезагрузки страницы опять возвращались на место.

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

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

Решилась проблема следующим образом:

ranzhe@plesk:~$ sudo /opt/psa/admin/sbin/file-sharing --sync

Точнее, не совсем. При попытке выполнить этот самый синк (а делается это php-скриптом), php отваливался из-за превышения лимита памяти, мол 128 мегабайт не хватает. Но чего не сделаешь ради хорошо дела? Вот только оказывается, что выполняется это все не просто через php-cli, конфиг которого в дебиане/убунте лежит в привычном /etc/php5/cli/php.ini, а через sw-engine-cgi, у которого свой php.ini, и путь к нему такой:

/opt/psa/admin/conf/php.ini

После увеличения лимита памяти sync отработал без ошибок, и file sharing перестал ругаться на то, что я "недостаточно прав", и вообще позволил наконец-таки отключить себя. Больше он меня не беспокоил.

Легкий способ сделать SRS в postfix

В наше время все чаще встречаются почтовые серверы, проверяющие SPF очень строго. С учетом количества спама, гуляющего по сети, администраторов этих серверов можно понять. Но  можно столкнуться с такой ситуацией: письмо поступает с mail1@example.com на mail2@example2.com, проходит все проверки, и все хорошо. Но на сервере example2.com стоит правило "форварднуть письмо на mail3@domain3.com". Сервер example2.com начинает пересылку, но сервер domain3.com видит, что письмо от mail1@example.com пришло от сервера example2.com, который, по результатам проверки SPF, не имеет никакого права слать такую почту.

Для исправления ситуации существует SRS (Sender Rewrite Scheme). И мой любимый exim умеет это из коробки, а вот postfix - нет. Но иногда эксим прикрутить нельзя (например, у нас панель управления, которая работает только с постфиксом). Можно, конечно, написать rewrite map, и переписывать FROM на сервере example2.com, но если у нас тысяча с лишним ящиков, что делать?

Реализаций SRS для postfix существует великое множество, но многие из них требуют патча исходников либо достаточно сложны в прикручивании к уже имеющейся системе.

Но есть простое решение, появившееся не так давно. Называется postsrsd.

Тем, у кого используется ubuntu server, достаточно сделать следующее:

add-apt-repository ppa:roehling/stable
aptitude update
aptitude install postsrsd

Остальные могут сходить на github и забрать исходники для самостоятельной сборки

Дальейшая настройка предельно проста. При установке генерируется ключ, нужный для подписания писем, которые мы будем форвардить. Остальные настройки есть в /etc/default/postsrsd. Мне понадобилось сменить порты, которые слушает демон, т.к. дефолтные уже были заняты.

В конфиг постфикса пишем следующее:

sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes= envelope_recipient

После этого убеждаемся, что postsrsd запущен и релоадим postfix. Готово.

Plesk и политика паролей в Horde

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

Раньше политика паролей на сервере позволяла задавать любые пароли, но после того, как некоторые неплохо так проспамились со своих адресов, было принято решение повысить требования к паролям.

Да, настройки это позволяют, хоть и не очень гибко:

И вроде все хорошо, панель больше не позволяет создать/сохранить простой пароль.

А теперь заходим в web-интерфейс почты (по умолчанию Plesk ставит Horde), выбираем в дереве слева "My Account" - "Password" иии... Да, пароль можно сменить на любой, сложность никто не проверяет. То есть пользователь, не желающий заморачиваться со сложным паролем, может просто пойти и задать себе любой. Отлично.

К счастью, в Horde предусмотрена проверка сложности для нового пароля (вот тут совсем не понятно, почему же тогда это не задействовали?). Не нашел способа получить через CLI от панели значение для действующей политики, поэтому просто забил руками параметры в файл

/usr/share/psa-horde/passwd/config/backends.php

Изначально там у единственного доступного бэкенда стоит значение

'password policy' => array(),

меняем на

'password policy' => array(
      'minLength' => 10,
      'maxSpace'  => 0,
      'minUpper'  => 1,
      'minLower'  => 1,
      'minNumeric' => 1,
      'minSymbols' => 1,
    ),

Готово.

Думаю, объяснять, какой парамтер в данном случае что означает особого смысла нет, догадаться нетрудно.

Искренне недоумеваю, почему внезапно такой важный момент в безопасности остался без внимания. Тикет в Parallels написал, конечно, после того как сам все поправил, но ведь очевидный же косяк.