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
