Re: тестирование спамоукреплспамоукр...
On Fri, Nov 12, 2004 at 11:57:13PM +0300, Artem Chuprina wrote:
> DVI> Вот тут-то наши позиции и расходятся. Вы предполагаете, что страшнее
> DVI> доставить спам, которого много, а я считаю, что доставить я должен все.
> DVI> Но спам отсортировать в другую папку.
>
> Это тождественно бессмысленно. Ибо если спама слишком много, то ложные
> срабатывания будет физически невозможно обнаружить. Я, собственно, спам
> весь и доставляю. Я просто не принимаю почту с практически заведомых
> спамогенераторов. В результате я получаю количество доставленного
> спама, которое на предмет ложных срабатываний физически проверить
> можно. А ты просто зря тратишь место на диске и прочие ресурсы.
Значит придется делать добавление заголовка и доступную юзеру "ручку",
чтобы включать удаление. Видимо придется ставить еще и sqwebmail,
чтобы управлять этим (оно умеет править юзерский $HOME/.mailfilter).
Меня волнует место на диске, но реакция у меня другая - поставить
больший диск. Все равно есть "мертвые души", и те, кто "что там в спаме"
не смотрят. Впрочем пока отчетливого решения этого ребуса я не вижу:
Проверка на спамность засунута в /etc/maildroprc, а $HOME/.mailfilter
вызывается maildrop уже после того, как пройден системный файл правил.
И надо будет сделать RTFM про spamassassin на тему "может ли он делать
заголовок не с его score, а со списком сработавших правил".
> DVI> То есть папочка Junk в моем проекте растет на 200 писем в день у каждого
> DVI> пользователя. Это, безусловно, затрудняет "выковыривание" ошибочно
> DVI> классифицированного как spam ham-а.
>
> Не надо тешить себя иллюзиями. Делает невозможным. Я пробовал. Я,
> собственно, только тогда и включил отстрел динамических адресов, когда
> стало понятно, что отлавливать в этой куче не по делу засунутые туда
> письма нереально.
Это убедительно. Согласен. Но метод все-таки хочу применять другой (см.
выше).
> До недавнего времени вот той почтовкой стоял P200. Если канала по
> какой-то причине не было полдня, он потом отлежавшуюся на втором MX
> почту обрабатывал сильно не вдруг - по ресурсам приходилось прижимать
> его до состояния "не более 2 писем одновременно". Сейчас там PII-300.
> 128 мегабайт памяти. Там же apache с CGI, courier-imapd с SSL, UUCP
> поверх SSL и postgresql. В ближайшее время собираюсь прикрутить туда же
Планируемая машина - P200 со 128 мегабайтами. Относительно Вашей схемы
-Apache +thttpd +squid +clamav -SSL -UUCP -postgresql. И жесткая уже
необходимость наращивать дисковое пространство (увы).
По поводу IMAP и "странного". IMAP дает возможность хранить почту на
нем. Но если это не нужно, то зачем замедлять открытие папки? Кому
надо - тот пользуется, кому не надо - нет. Я никого не заставляю.
WBR
Dmitri Ivanov
Reply to: