Увидела свет (http://www.dovecot.org/list/dovecot-news/2010-August/000167....) новая версия защищенного и надежного POP3/IMAP4-сервера Dovecot (http://www.dovecot.org/) - 2.0, серьезно отличающаяся от предыдущих веток. В частности, в новой версии реализованы следующие улучшения:
- Для разделения прав при работе теперь используются два системных пользователя для внутренних нужд (по умолчанию это dovenull и dovecot).
- Перепроектирован мастер-процесс, теперь он более модульный и содержит меньше кода, требующего исполнения от имени суперпользователя;
- Глобальный ACL отныне просматриваются с учетом префиксов пространства имен (namespace). К примеру, если ранее был префикс пространства имен INBOX и установлен глобальный ACL для "INBOX.Sent", теперь он будет браться из файла "INBOX.Sent" вместо файла "Sent", как это было ранее.
- Схема хранения Maildir: права доступа к файлам более не основаны на файле dovecot-shared, а базируются на правах на каталог почтового ящика;- Конф...
URL: http://www.dovecot.org/list/dovecot-news/2010-August/000167....
Новость: http://www.opennet.ru/opennews/art.shtml?num=27664
так что там с sieve, не понятно. ОЧЕНЬ полезное это sieve, используем.
В смысле "непонятно"? Сив там есть и работает.
Раньше нужно было дополнительно ставить костыли довекот-сиве и/или довекот-менеджсиве, а теперь все в одном флаконе. В принципе, и раньше было неплохо, а теперь д/б совсем хорошо.
только пока не вышел Pigeonhole sieve для 2.х ветке не зарелизили, только в гите лежит....
timo просто молодец
Фин же )) Как и Линус :)))
Линус швед из Финляндии.Managesieve через SSL пускать можно ?
> Managesieve через SSL пускать можно ?да, именно так и работает. plain text password over ssl:
dovecot: managesieve-login: Login: user=<a@b.c>, method=PLAIN, secured
Народ, у меня такая ситауция: Есть офис с почтовым сервисом (dovecot1/imap4 + postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе. Просто подключаться к основному серверу через инет не подходит, письма большие и слишком долго загружаются.Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения на одном сервере сразу же отражались бы и на другом, а изменения на втором тут же были видны и на первом (или не тут же, но сразу как связь появится). Dovecot2 такое умеет? В какую сторону смотреть? Тут в новости что-то про dsync мельком написано - это оно?
NFS?
А подробней можно? Каким боком тут можно NFS прикрутить? AFAIK - это просто сетевая файловая система, да ещё и медленная, как я слышал.
>А подробней можно? Каким боком тут можно NFS прикрутить? AFAIK - это
>просто сетевая файловая система, да ещё и медленная, как я слышал.
>Никаким - вам сказали глупость. НФС крайне плохо себя ведет в случае медленных, да еще и нестабильных линков. Ну и кроме того - трафик будет большим чем совместный доступ к imap shared folder, ага.
>[оверквотинг удален]
>postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе.
>Просто подключаться к основному серверу через инет не подходит, письма большие
>и слишком долго загружаются.
>
>Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения
>на одном сервере сразу же отражались бы и на другом, а
>изменения на втором тут же были видны и на первом (или
>не тут же, но сразу как связь появится). Dovecot2 такое умеет?
>В какую сторону смотреть? Тут в новости что-то про dsync мельком
>написано - это оно?Очевидного решения тут явно нет. Схема которую вы описали - не будет работать нормально.
Вот пример. Офис 1 открывает и модифицирует письмо, которое уже есть в офисе 2. Связи нет. Офис 2 открывает и модифицирует письмо, сохраняет. Связь появилась. Имеем конфликт :)
dsync тут вообще ни при чем - это тип хранилища, вы бы посмотрели довкот вики перед тем как писать, ага. Если канал нереально расширить, то есть несколько вариантов - например работа по имапу (shared folders) не загружая по умолчанию message body. Еще как вариант - офисы с медленным каналом используют веб морду, тот же раундкуб. Ну или мучительно и долго курить дбмейл и реализовывать синхронизацию средствами базы данных (тоже неочевидное решение).
> dsync тут вообще ни при чем - это тип хранилищаЭто Вы, уважаемый, путаете. dsync как раз утилита для синхронизации. Другой вопрос, сумеет ли она справиться в такой ситуации, когда на двух хостах одно и то же письмо поправлено независимо. Думаю, собственно, что более новые изменения затрут более старые.
Да, спутал с dbox, был неправ.http://wiki2.dovecot.org/Design/Dsync - тут описаны правила разрешений конфликтов, возможно это то, что и нужно автору. Но мне кажется, что это будет странно работать.
>Очевидного решения тут явно нет. Схема которую вы описали - не будет работать нормально.
>
>Вот пример. Офис 1 открывает и модифицирует письмо, которое уже
>есть в офисе 2. Связи нет. Офис 2 открывает и модифицирует письмо,
>сохраняет. Связь появилась. Имеем конфликт :)Изменение писем не такая уж супернеобходимая фича. Её можно вообще вырубить или при подобных конфликтах создавать две копии письма, т.е. чтобы на обоих серверах были видны обе модификации (а можно ещё и оригинал).
Вообще в нашем случае не важно как будут разрешаться подобные коллизии, поскольку они будут очень редкими и не смертельными.
>dsync тут вообще ни при чем - это тип хранилища, вы бы посмотрели
>довкот вики перед тем как писать, ага.да я-то посмотрел по диагонали: http://wiki2.dovecot.org/Tools/Dsync и http://wiki2.dovecot.org/Design/Dsync -- вроде на тип хранилища это менее всего похоже...
>Если канал нереально расширить, то есть несколько вариантов - например
>работа по имапу (shared folders) не загружая по умолчанию message body.Тела сообщений и так сейчас не загружаются, список писем подгружается без особых тормозов. А вот если тыкнуть в тандербёрде по письму с вложениями, тогда уже можно спокойно уходить на обед - к возврату оно как раз догрузится (кроме совсем клинических случаев).
Причём тут "shared folders" я не понял, это же вроде просто папки, расшареные для других юзеров?...>Еще как вариант - офисы с медленным каналом используют веб морду, тот же раундкуб.
А вот это вариант, хотя бы текст письма можно будет посмотреть. Спасибо, приму к сведению на случай если ничего не выйдет с зеркалированием.
Варианты: на второй хосте поднимайте SMTP-сервер, на нем заводите те же аккаунты, что и на первом, и пропишите на первом что почта для адресатов первого сервера еще и отсылается на имя-юзера@второй.сервер.Так что, как связь поднимется до второго сервера, SMTP на первом попробует доставить. И юзеры второго будут иметь на своей сервере копии писем.
Другой вариант - делать копию нужной почты в некий (служебный) ящик на первом сервере, его содержимое rsync-ом синхронизировать со служебным ящиком на втором сервере, а уже нужный Вам ящик второго сервера dsync-ать с этим служебным.
Пользя схемы - rsync умеет сжимать трафик, притом неплохо, так что, пока, связь есть, перегонится больше данных. rsync между двумя ящиками напрямую нельзя настраивать, иначе будет много глюков, напр., письмо на сервер "прочитали" - имя файла с письмом изменяется, а rsync может скачать его заново.
В общем, я бы Вам советовал первый вариант. Оно и надежнее, и настраивается проще.
Первый вариант не подходит, т.к. нужна полная синхронность ИМАП-ящиков. Работники должны курсировать между двумя офисами (то там работать, то тут), и не делать двойную работу при этом (удаление ненужных писем). И папка "отправленные" должна тоже синхронизироваться.Про rsync надо посмотреть, возможно dsync тоже сжимает траффик...
>Первый вариант не подходит, т.к. нужна полная синхронность ИМАП-ящиков. Работники должны курсировать
>между двумя офисами (то там работать, то тут), и не делать
>двойную работу при этом (удаление ненужных писем). И папка "отправленные" должна
>тоже синхронизироваться.
>
>Про rsync надо посмотреть, возможно dsync тоже сжимает траффик...Мне кажется, что в вашем случае есть смысл подумать о терминальном решении. Трафик будет при этом крошечный.
>[оверквотинг удален]
>postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе.
>Просто подключаться к основному серверу через инет не подходит, письма большие
>и слишком долго загружаются.
>
>Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения
>на одном сервере сразу же отражались бы и на другом, а
>изменения на втором тут же были видны и на первом (или
>не тут же, но сразу как связь появится). Dovecot2 такое умеет?
>В какую сторону смотреть? Тут в новости что-то про dsync мельком
>написано - это оно?imapsync
Можно посмотреть cyrus-imap, там есть sync_client:DESCRIPTION
Sync_client is the client side of the replication system. It runs on the client (master) system and connects to the target
(replica) system and generates an appropriate sequence of transactions to synchronize the replica system with the master sys-
tem.
>Можно посмотреть cyrus-imap, там есть sync_clientА вы случайно не в курсе, будет ли он работать с другими IMAP-серверами? Или он привязан исключительно к цирусу?
не будет. Там в настройках имапд цирроза надо куча всего указывать для него (sync_*).
Напрягает следующий момент в 1-м Dovecot: http://wiki.dovecot.org/TimeMovedBackwards
На почтовике стоит ntp сервер, который синхронизируется с другим ntp сервером в сети. Так вот dovecot отваливается (не прощает ;), когда время убегает. Жаль, что во 2-й версии не поправили сей факт.
странно как-то у вас время синхронизируется..
с ntp время вообще не должно убегать. там для этого всякие стратумы и пр.
в общем не понятно почему довекот под какой-то баг должны были править.
Довекот валится совершенно правильно в такой ситуации. Решение этой проблемы масса, погуглите. Самый оптимальный, на мой взгляд вариант, запретить ntpd менять время большими скачками.
>Самый оптимальный, на мой взгляд вариант, запретить ntpd менять время большими
>скачками.Как запретить ? Во FreeBSD был параметр ядра, касаемый максимальной дельты времени, но я его забыл. Да и не то это немного. Надо ntpd как-то настраивать. Мне он тоже однажды настроил время и убил Dovecot
Во втором Dovecot обещали сделать так, чтобы не падал, а ждал, если это возможно. Надеюсь, что сделали
это не возможно.
первое что проверяют спамассасины всякие - это время.
так что правьте ntp.вообще не понятно как это у вас получается.
может там руткит. или "привет" в кроне от бывшего админа?
такая ситуация с постоянным инетом - штатно невозможна.
зы:
вот прочитайте внимательно - http://ru.wikipedia.org/wiki/Ntpd раздел "Отладка".
собственно правильно настроенный ntpd "не_позволяет" часам убегать вообще и правит их сам.
Я тоже думал, что невозможно. Для того ntpd и использовал. Оказалось, что возможно. Никаких руткитов и добрых админов - сам всё ставил. Правда за 3 или 4 года года один раз только случилось, но неприятно.
мсье издеваться изволит?
Да мне скучно и делать больше нечего как только издеваться.15 Nov 19:08:36 ntpd[626]: time reset +5.008378 s и хана dovecot'у. Это не при старте, если что.
По-моему канал был сильно загружен или что-то вроде того. В общем причину я не нашёл. Поменял сервера в конфиге, ресетить перестал
да понял что не при старте.
но и без точного времени современная почта не тру. если только вечно из блэклистов вылезать не хочешь.
так что уж лучше решить проблему с точным временем, чем с падением довекота.
зы:
конечно про блэклисты я слегка приукрасил, но не так уж и сильно.
>Напрягает следующий момент в 1-м Dovecot: http://wiki.dovecot.org/TimeMovedBackwards
>На почтовике стоит ntp сервер, который синхронизируется с другим ntp сервером в
>сети. Так вот dovecot отваливается (не прощает ;), когда время убегает.
>Жаль, что во 2-й версии не поправили сей факт.Он совершенно прав, это честно с его стороны.
На крайний случай поставьте по крону watchdog и перезапускате dovecot.
А лучше, конечно, ntpd использовать, а по старту машины делать ntpdate, чтобы время поменялось скачком. Можно грубее сделать - по крону в 4 часа ночи останавливать dovecot, ntpd, запустить ntpdate, разрешив ему на любую величину дергать время, затем обратно запускать ntpd и dovecot. Но - как-то это неаккуратно, что ли.
>часа ночи останавливать dovecot, ntpd, запустить ntpdate, разрешив ему на любуюntpdate лучше вообше не использовать - dovecot может прямо на старте помереть. А в случае с ntpd его можно прописать в REQUIRE в dovecotовский скрипт запуска.
в предлагаемом сценарии - глупости.
и вообще довекот меня никогда не подводил. неубиваемый практически.
>в предлагаемом сценарии - глупости.Не конструктивно. Я не чувствую себя уязвлённым. Где конкретно глупости.
если в rc.conf ntpd_sync_on_start="YES"
то в dovecot# REQUIRE: LOGIN mysql ntpd
и sleep
Это FreeBSD если что. Так в чём здесь глупость ?
вот в этом
>ntpdate лучше вообше не использовать - dovecot может прямо на старте помереть.не коррелирует с этим:
остановить довекот и нтпд, дернуть время нтпдэйт, запустить нтпд и довекот.
Короче DOVECOT всем хороший кроме бага со временем. Подчеркну, что это именно БАГ. Система работающая с сообщениями не должна валиться ни при каких обстоятельствах - хоть на сервере "потоп".P.S. Вспоминайте лозунг системы "КАЖДАЯ ХЕРНЯ ДЕЛАЕТ СВОЕ ДЕЛО!".
Ну, может такое поведение описано в спеках? =) И потом, баг - всегда может оказаться фичей и наоборот... Все зависит от точки зрения.
>описано в спеках? =) И потом, баг - всегда может оказаться фичейАга, фича и есть... http://wiki.dovecot.org/TimeMovedBackwards