Настраиваемые пользователями или админом? Если админом, то это делается SMTP-фильтрами.

di_line пишет: Пользователями конечно, для своего, личного ящика.

di_line пишет: тут нужно ВЫБОРОЧНОЕ регулирование и не самим пользателем, а сверху.

По-моему, эти пункты друг другу противоречат — в первом настраивается самим пользователем, во втором — админом. Второй вариант реализован — SMTP-фильтры. Т.е. нужно добавить правила обработки почты, которые пользователь сам крутит в веб-почте по аналогии с тем, что есть в почтовых клиентах. Так?

SQL-сервер — большой соблазн (упрощение программирования) , но я принципиальный противник включения SQL-сервера в комплект Eserv. Интеграция с любым сервером БД была возможна (и использовалась на практике — для совместной работы с BSM, например) в Eserv/3 и точно также по-прежнему возможна в Eserv/4. Эта возможность заключается в том, что любой список, с которыми работает E3/E4 может браться не только из файлов, но и из любой БД. Но за 7 лет продаж E3 мы убедились, что востребованность этого функционала невелика, а дополнительные сложности в настройке создавать может (даже у тех, кому эта функция не нужна — просто берутся покрутить, "раз уж есть"), поэтому эта интеграция попала под нож упрощения, и в базовом конфиге никак не представлена. Зато расширилась поддержка встраиваемой БД SQLite. И, к слову, SQLite по основному [необходимому нам] функционалу не уступает ни MySQL, ни Firebird, а возможности контроля со стороны приложения [нашего] — у SQLite выше. Лицензия SQLite также очень удобная.

Чего именно не хватает, на ваш взгляд, в SQLite до уровня "полнофункциональный SQL-сервер"? Imho, Eserv+SQLite — это уже намного-намного больше

Если же говорить об отдаленном идеальном будущем, то, действительно, мысли о замене БД-движка иногда меня посещают (потому что storage — вообще традиционно узкое место у информационных систем), но в качестве кандидатов на новую рабочую лошадку я SQL-серверы уже не рассматриваю. Для наших данных (сообщения, версии, деревья сообщений) реляционная модель подходит не очень хорошо. "Конкурирующие" варианты (xmldb, column-ориентированные и т.п. новомодные) подходят не лучше. Лучше подходят Форт-ориентированные модели, с которыми я экспериментировал еще в середине 90х. Это, в общем, тема для отдельной статьи и отдельных исследований, на которые пока, увы, времени не найти.

Вьюшки и триггеры там есть. ХП нет, но у нас встроенный Форт с лихвой компенсирует этот недостаток. А другим наверное хватает возможностей Си-расширений для sqlite. Версий записей нет, но WAL-журналы — шаг в этом направлении: вместо in-place обновлений (требующих блокировок параллельных читателей) пишется новая версия записи в WAL. Основным узким местом там являются уже не блокировки, а (как и во всех файловых БД) фрагментация диска. В MySQL обойти это удавалось только за счет большого кэша (для наших скромных нужд — форум, wiki, bsm и магазин — для получения приемлемой производительности приходилось выделять аж 500Мб памяти для этого). Бэкапы (горячие) БД в sqlite тоже поддерживаются — есть api для этого, но в Eserv пока не задействовано (я уже пообещал Dandy прикрутить это).

di_line пишет: Я это к тому, что в случае роста нагрузки на БД почтового сервера, версионность(реальная) дает огромное преимущество перед блокировочниками.

По поводу WAL'а я уже сказал, но еще хочу заметить, что в E4 блокировки играют какую-то роль только при работе с общими папками, а личным ящикам не грозят, т.к. их индексы в отдельных файлах, а не в общих гигантских таблицах (как делали бы в sql-серверах из-за их неудобства/невозможности пофайловой работы).