Регистрация...

Eserv Forum / E4 / Mail / Индивидуадьные блеклисты по ящикам

wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Существуют ли такие в Eserv 4?
В этом возникла необходимость.
 
Комментарии к этой версии (15.09.2010 12:03) [~di_line] 937a8969
АвторДатаТекстtags
ac15.09.2010 12:22
Настраиваемые пользователями или админом? Если админом, то это делается SMTP-фильтрами.
wikipost
di_line15.09.2010 21:01
Пользователями конечно, для своего, личного ящика.
wikipost
alex112416.09.2010 12:21
А если фильтрами почтовой программы непосредственного пользователя?
wikipost
di_line16.09.2010 14:06
А зачем лишний трафик на почтовом сервере?
Тем паче, как показвает практика, если за почтовик зацепились спамеры или нечистоплоные "рассыльщики", то они просто так от почовика не отстанут. Это два. А раз: Имея такие блек-листы + реакция людей, то процес переноса из приватных листов в глобальный можно автоматизировать. Как, к примеру, на Майл.ру /Имею такой опыт / Или реальная ситуация: директор не хочет получать рассылку, но она должна быть у ряда работников. Но... на его выбор! До рассыльщика реально не достучатся.
wikipost
ili_a16.09.2010 14:23
ред: 16.09.2010 14:24
А чем вам встроенный антиспам не подходит?
Научите пользователей переносить ненужные письма в спам, а нужные во входящие, и все.
Плюс, если отправитель добросовестный, и его почта попала в спам, он сам сможет его протолкнуть через web
wikipost
di_line16.09.2010 16:12
Антиспам будет применяться ко всем ящикам?
А тут нужно ВЫБОРОЧНОЕ регулирование и не самим пользателем, а сверху. Человек на этой должности ДОЛЖЕН получать эту почту, вне зависимости хочет или нет, или по ошибке запихнул "письмо-другое" не туда.
wikipost
ac16.09.2010 17:55
di_line пишет: Пользователями конечно, для своего, личного ящика.

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


По-моему, эти пункты друг другу противоречат — в первом настраивается самим пользователем, во втором — админом. Второй вариант реализован — SMTP-фильтры. Т.е. нужно добавить правила обработки почты, которые пользователь сам крутит в веб-почте по аналогии с тем, что есть в почтовых клиентах. Так?
wikipost
di_line17.09.2010 02:22
Ага, именно так, AC!
И эти, индивидуальные черный и белые списки должны обрабатываться до глобальных (в рамках почтового сервера) листов.
Имхо, естественно.

Вторая цитата немного с другим контекстом в ответ на предложение "пихать все спам". Так как человек от не понимания (глупости, не желания и тп) туда может напихать все что ему не нравится. А отдуваться придется админу за все их выкрутасы.

Попутный вопрос: Планируется в 5-й версии, а может и раньше, перевод на полнофункциональный SQL-сервер? Firebird к примеру...
wikipost
ac20.09.2010 22:45
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х. Это, в общем, тема для отдельной статьи и отдельных исследований, на которые пока, увы, времени не найти.
wikipost
di_line21.09.2010 03:44
Не за-ради холивара.
А что, в SQL-lite есть такой же функционал тригеров, хранимых процедур, вьюшек как в Firebird?
Или по версионность ввели полную?
Я это к тому, что в случае роста нагрузки на БД почтового сервера, версионность(реальная) дает огромное преимущество перед блокировочниками.
Функционал, реализуемый посредством ХП (хранимых процедур) в Firebird решает множество промблем, и в первую очередь — с быстродействием системы в целом. Плюс в использовании SQL-сервера (не Еmbedded) позволит, имхо, решить вопросы маштабируемости, отказоустойчивости, восстановления почтового сервера.
Надо покрутить 4-ку Eserv-a на предмет бекапов БД: — Что там и как с этим?
wikipost
ac21.09.2010 12:40
Вьюшки и триггеры там есть. ХП нет, но у нас встроенный Форт с лихвой компенсирует этот недостаток. А другим наверное хватает возможностей Си-расширений для sqlite. Версий записей нет, но WAL-журналы — шаг в этом направлении: вместо in-place обновлений (требующих блокировок параллельных читателей) пишется новая версия записи в WAL. Основным узким местом там являются уже не блокировки, а (как и во всех файловых БД) фрагментация диска. В MySQL обойти это удавалось только за счет большого кэша (для наших скромных нужд — форум, wiki, bsm и магазин — для получения приемлемой производительности приходилось выделять аж 500Мб памяти для этого). Бэкапы (горячие) БД в sqlite тоже поддерживаются — есть api для этого, но в Eserv пока не задействовано (я уже пообещал Dandy прикрутить это).
di_line пишет: Я это к тому, что в случае роста нагрузки на БД почтового сервера, версионность(реальная) дает огромное преимущество перед блокировочниками.
По поводу WAL'а я уже сказал, но еще хочу заметить, что в E4 блокировки играют какую-то роль только при работе с общими папками, а личным ящикам не грозят, т.к. их индексы в отдельных файлах, а не в общих гигантских таблицах (как делали бы в sql-серверах из-за их неудобства/невозможности пофайловой работы).
wikipost
di_line02.11.2010 05:28
как бы Up "хотельки"...
wikipost
rvm16.11.2010 04:17
ac пишет: Для наших данных (сообщения, версии, деревья сообщений) реляционная модель подходит не очень хорошо. "Конкурирующие" варианты (xmldb, column-ориентированные и т.п. новомодные) подходят не лучше.


а почему для деревьев сообщений xmldb подходит хуже, чем RDBMS?
wikipost
Работает на Eserv/5.05555 (05.06.2016)