Re: аналоги spamassasin
On Tue, 14 Jul 2015 18:14:31 +0300
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Tue, Jul 14, 2015 at 05:31:01PM +0300, Victor Wagner wrote:
> > Andrey Tataranovich <tataranovich@gmail.com> wrote:
> >
> > > Спамеры повадились прикреплять к письму большой кусок какого-либо
> > > текста, который фильтр в итоге пропускает.
> >
> > Ни разу такого не видел. Может от них greylisting спасает или header
> > checks?
>
> Нет, не спасает, потому что этот мусорный текст -- в body.
Как раз если мусорный текст в body, а письмо отсеивается ДО ТОГО, как
дело дойдет до заглядывания в body (например, greylisting-ом), то
спасает.
> > Но вот чего я не понимаю, так это зачем нужен amavisd. По-моему, это
> > глубоко лишняя сущность.
>
> Для того, чтобы выстроить очередь обработчиков к письму (например,
> антивирусы) и сериализовать процессинг. Нужно когда пользователей
> больше десятка.
Может больше тысячи? Всё-таки десятки пользователей, получающие
максимум сотни содержательных писем в день (включая репорты от
автобилдеров и сообщения об изменениях статусов issues в request
tracker-е и коммитах в репозиторий), это максимум единицы писем в
секунду. Для современных машин не нагрузка.
> > Куда проще приделать spamc к деливери-агенту.
>
> Весело будет выглядеть доставка письма на staff, когда в конторе
> 200-300 пользователей. :)
А если у каждого из этих 200-300 пользователей свой конфиг
спамассассина и свои байесовские базы (что есть умолчательный вариант
конфиграции), то никуда и не денешься. Разве что разрешить писать на
staff только тем, кто заведомо в белом списке.
Гораздо интереснее, как можно в такой конторе классифицировать
пользователей, чтобы была всё же не одна база на всех, поскольку то,
что для девелопера явный спам. для маркетингового отдела может быть
вполне осмысленной рабочей перепиской, но и не было необходимости для
каждого пользователя обрабатывать письмо на staff в индивидуальном
порядке, а раз этак пять-шесть для больших групп пользователей.
Reply to: