Вышла новая версия DBMail 2.2, почтового pop3/imap сервера

Вот уж где сложностей не будет, так это здесь. :) Напиши скриптик, чтоб вытаскивал письма из базы и скармливал их кламаву, если что - грохал их. Тоже мне проблема. Примерно 5-10 строк на перле.

fs - ext3 в cyrus - с помощют lmtp (unix socket) в dbmail - тоже lmtp (inet socket) в dovecot - просто maildir exim'ом. про индексы dovecot'а: второй раз, когда индексы настроены он открывал ящик минуты 3. Многовато будет для второго раза.

>Примерно 5-10 строк на перле.

И это Вы предлагаете делать при больших объемах, для которых rdbms преподносят как хорошее решение? Ну-ну...

>>Примерно 5-10 строк на перле.

>И это Вы предлагаете делать при больших объемах, для которых rdbms преподносят как хорошее решение? Ну-ну...

но но же не виноват что кламав не умеет чистить вирусы в базе. А собственно что вам не нравится?

Кстати, одному из высказавшихся тут авторов по поводу "я держу по два аккаунта", PAM для авторизации применять не пробовали ? Советую =) Хоть через черта лысого авторизоваться можно. Абсолютно универсально.

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

>И это Вы предлагаете делать при больших объемах, для которых rdbms преподносят как хорошее решение?

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

> И это Вы предлагаете делать при больших объемах

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

> Кстати, может всетаки кто то рассказать практическое применение sieve?

Из практики.

При работающем на сервере spamassassine - перенос почты с X-Spam-Status: Yes в INBOX/Spam.

Прошаренные юзеры сами ставят vacation перед отпуском или командировкой.

Манагеры со сменными рабочими станциями типа офисная тачка/ноут/домашняя тачка быстро врубаются в рулез клиентонезависимых фильтров.

Для себя любимого - разбор писем от всяких монитов/логчеков/крон-аптов. Представь себе сколько их прокачивалось бы через INBOX после двух недель отпуска. А так пришёл, все уже по местам.

Правда традиционный гимор с non-ASCII заголовками. Но это уже от реализации парсера зависит. Что там в RFC написано, не помню.

Понятный народу интерфейс - http://smartsieve.sourceforge.net/ Сам можешь через шелл править скрипты на месте.

Короче говоря, sieve это скорее рулез, чем наоборот. :)

Короче говоря, всё перечисленное и procmail может. Хотя в procmail не нравится, что нет блоков с правилами (типа если условие выполняется, то дальше целый блок правил с разными дополнительными условиями и так далее) и вообще ветвлений. Но это скорее небольшое неудобство, чем прямо недостаток (да и то только когда ручками procmailrc пишешь).

> Короче говоря, всё перечисленное и procmail может.

Оно да. Только манагеру синтаксис procmail тяжко объяснять. :) А тут он через веб-морду сам всё разруливает, как белый человек.

Кроме того я с sieve работаю как раз на cyrus-imap, а с его форматом мейлдиров сторонние приблуды врядли справятся.

Ну я примерно на то и намекаю, что если б к procmail'у была нормальная морда, то разницы бы не было.

>абсолютно неважно, с какой скоростью старая база будет проверена.

Вы предлагаете остановить сервис? :-)

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

Для меня очевидно, что в случае rdbs это будет медленнее. Хотя бы из-за накладных расходов на обращение к этой самой rdbms.

Но дело то даже не в этом, а в том, что авторы подобного софта не предлагают никаких инструментов для решения.

Неудачная попытка телепатии.

> > Cyrus-IMAP можно посмотреть.

> А как там у него с security? Судя по всему не очень хорошо, в отличие от Dovecot.

А сколько dovecot лет? ИМХО еще не искали уязвимости, поэтому их и нет :-) Плюс пускай по возможностям до cyrus'а дотянется, тогда и можно будет сравнивать. А так, это просто вещи из разных весовых категорий.

> Вестимо через maildrop define(`LOCAL_MAILER_PATH',`/usr/bin/maildrop')dnl

Это уже поздно, сообщение на этом этапе уже принято.

Не свисти. За dovecot Timo объявил премию за каждую найденную уязвимость (многие ли кроме Кнута и DJB это сделали), и вообще это один из основных акцентов проекта.

> Короче говоря, всё перечисленное и procmail может.

Одно но. Оно заливается через соответствующий порт с пользовательскими логином/паролем.
1. То есть, никаких поблем с созданием пользовательских эккаунтов в системе и раскладкой в них procmailrc по ftp/ssh/разное.
2. Есть вероятность поддержки языка произвольными почтовыми клиентами. В KMail уже делают.

> (многие ли кроме Кнута и DJB это сделали),

По поводу Кнута ссылок не видел ( ;-) ), а вот по поводу DJB...
http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
И перевод:
http://slssoft.altai.info/qmail-bugs/ (что-то не сильно живой сейчас)

Ну и open relay by default, опять же...

Жду аналогичного URL про dovecot. :)

Я смотрю на ЛОРе опять входит в моду спорить на с основной мыслью поста, а с чем-нибудь в кавычках, не имеющим по сути никакого отношения к топику.

dbmail+exim+clavav (dbmail - предпоследний) О!, вспомнил такой глюк: когда делал backup системы, спискок процессов раздуло до 2 тыс. записями типа "...pop3...defunct..". К сожалению повторить возможности сейчас нет.

Может кто знает, что это было?

Подохли после долгого ожидания ввода-вывода?

> Жду аналогичного URL про dovecot. :)

Не мог я qmail не пнуть. :-)

> Я смотрю на ЛОРе опять входит в моду спорить на с основной мыслью поста, а с чем-нибудь в кавычках

А что с основной мыслью спорить ? Спорь, не спорь, а новая версия DBMail вышла. Аксиома уже. :-)

>> перевел несколько серверов на DBMAIL с Cyrus'а - не нарадуюсь. >Субъективно работать стало быстрее.

>На какой ФС спулы Cyrus-IMAP жили ? Так, для статистики. Наверное, надо начать собирать...

ReiserFS v.3 смонтированный с noatime, notail

Н увобше-то если так надо то там есть courier-authdaemon.

при большом числе пользователей будет большая проблема с I/O, если не принимать различных мер

> >Ерунда полная. По-вашему, нельзя сделать custom индексирование? C какой стати?

> можно, не вопрос. Только зачем? На то они и базы данных что бы другие занимались ускорением и обработкой данных. Потом в них как правило реализованны достаточно сложные алгоритмы деревьев и т.п. Хотите, реализовывайте все это сами. Лично у меня и так времени нету.

Никогда не надо путать тёплое с мягким. Вы автор DBMail либо другого почтового сервера? При чём тут _ваше_ время? Автор кастомного индексатора может один раз потратить [действительно немало] времени на обдумывание и реализацию, но потом его нужно точно так же использовать. Просто испольовать. С таким же успехом я могу сказать, что вам не хватит времени писать sql-сервер, чтобы DBMail запустить ;) Это во-первых.

Во-вторых, с чего вы взяли, что sql-базы занимаются ускорением чего бы то ни было? БД хранят данные, и основная их задача - хранить данные надёжно. Скорость тут хотя и важна, однако всё-таки вторична по сравнению с надёжностью. И алгоритмы для обеспечения этой самой надёжности сложны в том числе по причине разнородности информации, которую можно хранить в базе. Нужно это для хранения писем? очевидно, нет. Именно в sql-движках куча кода для триггеров и прочей проверки валидности собственно данных - зачем это всё для хранения почты? Тормоза на ровном месте. Если уж БД - то MUMPS-like, зачем тут sql-образные базы - совершено непонятно.

Далее. В случае sql-базы по приходу каждого письма будет отрабатывать commit - иначе никакой надёжности не будет. При этом внутри sql-движка производится куча проверок, отрабатывается куча блокировок, м.б. частично пересчитываются индексы. Значит, к админу почтового сервера нужен ещё dba, чтобы обеспечить сколько-нибудь хорошее итоговое качество услуги. Офигенная экономия и средств. Это при том, что узкозаточенный индексатор во-первых эффективнее за счёт знания о том, с какими данными он работает, а главное не требует никакого обслуживания вообще, если нормально продуман.

И на фига козе музыкальный инструмент?

> у меня dbmail крутится на postgres, с бекапом никаких проблем нет.

А с чего быть проблемам с бэкапом, если сервер не Exchange? :)

>БД хранят данные, и основная их задача - хранить данные надёжно. Скорость тут хотя и важна, однако всё-таки вторична по сравнению с надёжностью. И алгоритмы для обеспечения этой самой надёжности сложны в том числе по причине разнородности информации, которую можно хранить в базе. Нужно это для хранения писем? очевидно, нет.

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

>Именно в sql-движках куча кода для триггеров и прочей проверки валидности собственно данных - зачем это всё для хранения почты? Тормоза на ровном месте. Если уж БД - то MUMPS-like, зачем тут sql-образные базы - совершено непонятно.

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

>Далее. В случае sql-базы по приходу каждого письма будет отрабатывать commit - иначе никакой надёжности не будет. При этом внутри sql-движка производится куча проверок, отрабатывается куча блокировок, м.б. частично пересчитываются индексы.

все тоже самое будет делаться и в случае любого другого качественного почтового сервера. И индексы точно будут пересчитываться. Ну commitы действительно займут чуть больше времени, тут согласен, но это не критично. Зато искать по базе значительно проще чем в maildir.

>Значит, к админу почтового сервера нужен ещё dba, чтобы обеспечить сколько-нибудь хорошее итоговое качество услуги. Офигенная экономия и средств.

я не говорил что это большая экономия средств. А зачем нужен dba? тут кроме бекапа и вакума больше нечего делать. Да и это делается по крону.

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

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

maxik73, крайе сложно спорить с человеком, который опять передёргивает написанное.

Мне действительно нужно объяснять, что не надёжность не нужна - а способы обеспечения оной, принятые в sql-серверах.

Читайте то, что действительно написано ;)

>maxik73, крайне сложно спорить с человеком, который опять передёргивает написанное.

>Мне действительно нужно объяснять, что не надёжность не нужна - а способы обеспечения оной, принятые в sql-серверах.

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

По-моему, тут не очень рациональное желание всё на свете делать Универсальным Единственно Верным Способом (в твоём случае - через БД). Про то, что ничего "писать заново" не надо, всё уже написано, тебе неоднократно говорили.

И вообще спор не очень рациональный и осмысленный. Сравнивать надо конкретные системы по экспериментально проверенным параметрам работы (которые ещё сильно зависят от правильной настройки), а не обобщённо "БД vs собственное индексирование".

Дело, как говорится, вкуса. Кому-то нужна база данных, кому-то - нет. Однако для тех, кто понимает толк в sql-серверах, вполне очевидно - DBMail офигенно удобная штука. Здесь самому можно сделать и прикрутить массу удобных вещей, которых от других почтовых серверов можно ожидать годами. Чтобы выполнить ряд операций на других почтовиках, нужно еще подумать, как это сделать. В DBMail многое можно сделать практически сходу, например, получить список пользователей, кто не заглядывал в свой ящик уже более полугода; для каждого пользователя в папке Spam регулярно чистить сообщения, которым уже больше месяца; собрать любую, интересующую статистику и т.д. и т.п. Если говорить про оптимизацию и "заточку" в работе с данными, то лучше, чем это сделано в sql-серверах, нет нигде. Здесь разработчики годами именно на этом специализируются. И никто меня не убедит, что индексирование или поиск где-то работает лучше, чем в базах данных. Почему тогда Оракл реализовал, а Майкрософт планирует в ближайшее время реализацию файловой системы на основе sql-сервера? Потому что надежность, скорость, транзакции и т.п.

>А с чего быть проблемам с бэкапом, если сервер не Exchange? :)
>Dimentiy

Ой ... уй ... аж зубы заболели! Ты так больше не шути ... :)
_Там_ базу восстановить не останавливая все можно только начиная с 2К3 ... да и то :(

>Дело, как говорится, вкуса. Кому-то нужна база данных, кому-то - нет.
Ну это - да :)

>В DBMail многое можно сделать практически сходу, например, получить список пользователей, кто не заглядывал в свой ящик уже более полугода;
Ну и ? Он в этом не уникален :)

>для каждого пользователя в папке Spam регулярно чистить сообщения, которым уже больше месяца;
Во первых - лезть в _юзерские_ данные - самая плохая идея, какая только может быть. Во вторых - если уж приспичило - какие проблемы с этим на FS-based системах? Нету их.

>собрать любую, интересующую статистику и т.д. и т.п.
И опять мимо кассы. Совсем недавно пробегало как показать статискику по всем разрезам юзая RRD - можно даже менеджерам показывать до чего все понятно и с картинками :)

>Если говорить про оптимизацию и "заточку" в работе с данными, то лучше, чем это сделано в sql-серверах, нет нигде.
Berkeley DB порвет любой сиквель, но программить его ... не всем дано :-)

>Почему тогда Оракл реализовал, а Майкрософт планирует в ближайшее время реализацию файловой системы на основе sql-сервера? Потому что надежность, скорость, транзакции и т.п.
Потому что денег хотят.

Странно но ты не упомянул __единственное__ важное преимущество. Унификация доступа к данным. _Только_ из за этого с $Subj ем и играюсь. Ныне людой пионер сможет сделать клиента говорящего SQL'ем используя любой ЯП на любой НОС ...

IMNHO.
With best wishes GR. :)

плюсов действительно много
в том числе и простота создания отказоустойчивого кластера - все остальные решения требуют либо внешнего стораджа (очень дорогого если специфического - и проблемного если nfs), либо распределённой fs (что по моему адский ад).

плюс конечно простота созадания бэкапов, в том числе если бд позволяет то бэкапов логов - то есть потери минимальны при восстановлении. в классческой схеме rsync на больших объёмах ре совсем эффективен.

ну и унификация доступа - очень большой бонус.

непонятно только совсем что с производительностью - особенно под большой нагрузкой.

mysql правда действительно не очень подходит, с устойчивостью у него проблемы, туту никуда не дется
но postgres - самое оно
учитывая возможность прозрачной кластеризации данных даже пробелм с огромными размерами таблиц не должно быть

А что, проблемы в случае использования MySQL неизбежны? У меня вот уже база на одном из серверов 3,5 Гб размера и юзается в хвост и в гриву. MySQL 4.1.x. Пока (тьфу-тьфу-тьфу) никаких проблем. Из обслуживания, как уже здесь заметили, бэкапы и вакуум ;-)

Чего плохого можно ожидать? Есть какие внутренние проблемы MySQL? Извне вроде у меня все сделано достаточно надежно - RAID1, UPS, бэкапы.

При некорректном завершении MySQL индекс может слететь, и придётся его чинить через myisamchk или REPAIR TABLE. Понятно, что случается это не каждый день, но когда случится, то уже трёхгиговая база будет чиниться заметное время. А когда дорастёшь до 30 гигов, вообще будешь молиться, чтоб не дай бог этого не произошло. :)

А что, в случае использования PostgreSQL такого не может произойти? Ведь при некорректном завершении работы любой СУБД могут возникнуть проблемы.

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

Кстати, заметьте что в этой теме получилось весьма аргументированное и цивилизованное обсуждение. Как-то непривычно видеть такое на LOR'е. ;)

> А что, в случае использования PostgreSQL такого не может произойти?

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

Эхехехе .....жаль что проблемы про модель ACID ничего не знают :)

GR.

Есть конкретный пример проблемы с postgresql при "некорректном" завершении работы ?