настройка spamassassin

Причём как показывает практика: броня давно и монотонно проигрывает. :)
Что, впрочем, не является поводом к полному отказу от неё.

Затрудняюсь с ответом сразу.
Пока приведу статистику сервера за прошлую неделю с пон. до пон.

Grand Totals
------------
messages

   6932   received
 251460   rejected (97%)
 258392   total


    Data command rejected: Improper use of SMTP command pipelining (total: 2)
    5.3.4 Message size exceeds fixed limit (total: 2)
    Client host rejected: Greylisted for 300 seconds (total: 42)
    Client host rejected: rDNS client SPAM (total: 4322)
    Helo command rejected: Host not found (total: 2985)
    Helo command rejected: Invalid name (total: 3532)
    Helo command rejected: need fully-qualified hostname (total: 89870)
    Helo command rejected: rDNS helo SPAM (total: 125517)
    Recipient address rejected: Improper use of SMTP command pipelining (total: 1)
    Recipient address rejected: User unknown in virtual mailbox table (total: 7427)
    Relay access denied (total: 5328)
    Sender address rejected: Domain not found (total: 134)
    blocked using bl.spamcop.net (total: 70)
    blocked using psbl.surriel.com (total: 43)
    blocked using zen.spamhaus.org (total: 11092)
    blocked using Country SPAM (total: 504)
    blocked using karmasphere.email-sender.dnsbl.karmasphere.com (total: 338)
    blocked using b.barracudacentral.org (total: 251)

и настройки postfix:

smtpd_recipient_restrictions =
 reject_unauth_pipelining
 permit_mynetworks
 permit_sasl_authenticated
 reject_unauth_destination
 reject_invalid_helo_hostname
 reject_non_fqdn_helo_hostname
 check_helo_access hash:/etc/postfix/helo_access
 check_helo_access pcre:/etc/postfix/helo.pcre
 check_client_access pcre:/etc/postfix/client.pcre
 check_helo_access hash:/etc/postfix/client_access
 reject_non_fqdn_sender
 reject_unknown_sender_domain
 reject_non_fqdn_recipient
 reject_unknown_recipient_domain
 reject_unlisted_recipient
 reject_unknown_helo_hostname
 reject_rbl_client zen.spamhaus.org
 reject_rbl_client psbl.surriel.com
 reject_rbl_client bl.spamcop.net
 check_spam
 check_client_access pcre:/etc/postfix/client_greylist.pcre

Тут нужно подумать, сопоставить статистику и расставить все по местам, как в случае с RBL :)
А также найти наиболее подходящее место для ловушки.
Предварительно я думаю, что ее можно ставить после локальных проверок (без обращения в сеть) поскольку, что проверить
regexp, что записать в mysql по-моему одинаково, только mysql расти начнет.
Еще нужна статистика попыток отправления на адрес, как Вы говорите.
Можно сделать более гибкий вариант - вначале соединения (в точке подключения ловушки) увеличиваем счетчик подключений для IP (подсети). Если счетчк стал большим - выкидываем.
Ставим проверку reject_unlisted_recipient в самый конец, как говорит Avari.
А после этой проверки уменьшаем счетчик на единицу.
Таким образом, у всех кто не дошел до этого момента, счетчик будет расти. Кто прошел, счетчик будет нулевой.
У этого метода есть плюс - не прошел ЛЮБУЮ проверку - больше не пройдешь.
И минус - попал твой клиент в zen - потом неделю не вылезет из бана.
Естественно, такую базу надо чистить раз в неделю или в месяц.
Но думаю, если идею отшлифовать, можно ее использовать.
Например, увеличивать счетчик на единицу, а уменьшать на 2. И большие минусы не чистить - это whitelist.
Такой вариант не требует почтового ящика ловушки.
Что Вы на это скажете?

В таблицу заносим

create table blacklist
triplet
count
timestamp
debug_info - client_name,from etc.

Cron:

раз в день
delete from blacklist where count=1;
раз в неделю
delete from blacklist where count between 0 and 10;
раз в месяц

delete from blacklist where now()-timestamp>30days;
delete from blacklist where count between -10 and 0;

Я вот подумал, для virtual hosting как у меня
reject_unauth_destination - 1 обращение к mysql и ничего, живет.
так что ставим ловушку сразу после permit.

Добавлено.

Проверил на статистике:

#cat mail.log-20090223 | grep reject | awk '{print($10)}' | sort | uniq -c | sort -r -n | awk '{print($1)}' | uniq -c

      1 527
      1 471
      1 467
      1 448
      1 432
      2 431
      1 429
      1 427
      1 424
      1 421
...........
    344 15
    103 14
    106 13
    266 12
     86 11
    500 10
   2132 9
    281 8
    274 7
   1291 6
   1445 5
   1019 4
   4193 3
   2322 2
  10038 1

Первое число - количество хостов, второе - количество отказов за неделю для каждого из этих хостов.

Таким образом, всего хостов, которым отказано = 27412
Хостов, которым отказов меньше 10 = 22995
То есть, в среднем в базе 4417 хостов + 300, от которых я все время получаю + 22995/7=3000 (в среднем в день не успел удалить)
Всего не более 8000.
Общее количество отказов = 251520
Для хостов, которые я постоянно буду удалять (потому что количество отказов меньше 10) общее количество отказов = 69662 или 27,7%
То есть 75% отказов будет происходить минуя все остальные проверки.
По идее, это должно работать быстрее, в 4 раза меньше нагрузка на все сетевые проверки в том числе.

Кстати, число 10 тоже не случайно. 251520/27412 = 9,2 - среднее колчество отказов на 1 хост.