Несколько замечаний/дополнений. Естественно, применительно к обсуждаемому варианту установки почтового сервера.
Небольшие изменения конфигурации amavis
Работа amavis с виртуальными доменами.
Если Вы используете виртуальные домены, то Вам нужно указать amavis, что они являются локальными. Иначе он не будет вставлять заголовки и проверять на спам, т.к. будет считать, что письма, посланные на виртуальные домены - исходящие.
Если у Вас настроено по настоящему руководству, то Вам нужно вставить в файл /etc/amavis/conf.d/50-user примерно следующие строки:
@lookup_sql_dsn = (['DBI:mysql:mail; host=127.0.0.1; port=3306', 'USERNAME' ,'PASSWORD']);
$sql_select_policy = 'SELECT "Y" as local FROM domains WHERE CONCAT("@",domain) IN (%k)';
где USERNAME и PASSWORD - имя пользователя и пароль для доступа к БД с именем mail (домены, напоминаю, перечислены в таблице domains)
Т.к. используется amavis-new, то параметры для spamassassin нужно задавать именно в конфигурации amavis (т.е. в файле /etc/amavis.conf.d/50-user). Учтите при этом, что параметры, заданные непосредственно в файле конфигурации spamassassin (файл /etc/mail/spamassassin/local.cf) в большинстве будут просто проигнорированы (например, amavis-new никогда не модифицирует тело письма, даже если это прямо указано в конфигурации spamassassin).
Дальше - некоторые параметры, которые используются у меня с кратким пояснением, зачем и почему.
$enable_db = 1; # enable use of BerkeleyDB/libdb (SNMP and nanny)
$enable_global_cache = 1; # enable use of libdb-based cache if $enable_db=1
$spam_check_negative_ttl = 30*60;
$spam_check_positive_ttl = 30*60;
Это позволяет держать небольшой кеш уже проверенных писем и не проверять точно такие же письма заново, если они уже есть в кеше. Проверка идет по сигнатуре, которую amavis генерирует сам. Полезно, когда, в частности, один и тот же спам валится на несколько адресов. ttl-параметры - это срок жизни сигнатуры в кеше (с положительным и отрицательным результатом проверки на спам). В моем случае, процент попадания в кеш порядка 8.
$sa_spam_subject_tag = '***SPAM*** ';
$sa_spam_report_header = 1;
$sa_tag_level_deflt = undef; # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 4.5; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 6.9; # triggers spam evasive actions
$sa_dsn_cutoff_level = 6.9; # spam level beyond which a DSN is not sent
$sa_quarantine_cutoff_level = 6.9;
$sa_spam_subject_tag - добавление указанной строки в начало темы письма. Удобно для получателей.
$sa_spam_report_header - добавление заголовков с подробным отчетом о результатах проверки. Учтите только, что эти заголовки будут вставлены только в письма, признанные спамом. Подробный отчет - это объяснения каждого сработавшего правила spamassassin, типа вот такого:
X-Spam-Report:
* 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
* [score: 0.5000]
* 1.8 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding
* 1.3 AWL AWL: From: address is in the auto white-list$sa_tag_level_deflt - добавлять заголовки с результатом проверки на спам в сообщения с указанной оценкой и выше. Здесь - всегда добавлять эти заголовки. Заголовки вот такие:
-Spam-Flag: YES
X-Spam-Score: 4.54
X-Spam-Level: ****
X-Spam-Status: Yes, score=4.54 required=4.5 tests=[AWL=1.336, BAYES_50=0.001,
HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_MULTIPLE_AT=1.449] если опознан спам и
X-Spam-Flag: NO
X-Spam-Score: -0.708
X-Spam-Level:
X-Spam-Status: No, score=-0.708 required=4.5 tests=[AWL=0.403, BAYES_05=-1.11,
SPF_PASS=-0.001]если сообщение "чистое". Еще раз подчеркну, что в этом случае заголовка "X-Spam-Report:" не будет. Если нужен - нужно править сам amavis.
$sa_tag2_level_deflt - уровень, начиная с которого сообщение признается спамом.
$sa_kill_level_deflt - уровень, начиная с которого выполняется правило по обработке спама (описание ниже)
$sa_dsn_cutoff_level - уровень, начиная с которого не отсылается сообщение о невозможности доставки. Очень советую его иметь равным $sa_kill_level_deflt, иначе Вас, скорее всего, внесут в какой-нибудь черный список. Особенно это любит делать, например, att.com
$sa_dsn_cutoff_level - уровень начиная с которого письмо не сохраняется в карантине (/var/lib/amavis/virusmails/...)
$final_virus_destiny = D_DISCARD; # (data not lost, see virus quarantine)
$final_banned_destiny = D_BOUNCE; # D_REJECT when front-end MTA
$final_spam_destiny = D_DISCARD;
$final_bad_header_destiny = D_PASS; # False-positive prone (for spam)
$virus_admin = "postmaster@$mydomain"; # due to D_DISCARD default
Параметры задают правила обработки "нехороших" сообщений:
$final_virus_destiny - просто игнорировать (сами письма сохраняются в карантине)
$final_banned_destiny - письма с запрещенными вложениями по типу файлов: сообщить отправителю о невозможности доставки
$final_spam_destiny - игнорировать (это и есть то самое правило обработки спама, о котором шла речи выше)
$final_bad_header_destiny - некорректные заголовки писем пропускать.
$virus_admin = адрес, куда доставлять сообщения о вирусах и отраженных письмах с запрещенными вложениями (postmaster), чтобы можно было проверить содержимое писем в карантине. О письмах со спамом, попавшим в карантин, сообщений не будет.
Настройки, связанные с вирусами и запрещенными вложениями лучше оставить "по умолчанию".
Конкретные уровни оценки выставьте сами (я использую именно такие, и они меня полностью удовлетворяют, по крайней мере, по прошествии довольно большого времени и накопленной bayes-овской базы и с регулярными обновлениями правил spamassassin). Недавно специально проверял - за три дня ложных срабатываний было 0 (менял D_DISCARD на D_PASS у $final_spam_destiny).
Пользователь решил продолжить мысль 29 Января 2010, 21:08:47:
Дополнительные правила для защиты от спама
Множество спам-хостов находится на компьютерах-зомби. К счастью, в большинстве случаев эти компьютеры не настроены должным образом, как мейл-серверы, что дает возможность их с легкостью отсекать еще на начальном этапе получения писем.
Дело в том, что процесс передачи/получения письма начинается с представления серверов друг другу. После соединения по порту 25 (SMTP), компьютер - инициатор выдает команду
HELO hostname.domain.ltd
Принимающий сервер уже на этом этапе может отсечь кучу спама. Как это сделать? Очень просто. Нормально сконфигурированный сервер обязан в сообщении HELO передать свое истинное имя; причем это имя должно соответствовать IP-адресу, с которого осуществляется соединение; а IP-адрес должен резолвится в обратной зоне в это имя. Если это не так - Вы имеете полное право отсечь соединение прямо на этом этапе. Плюсы: не тратится лишний трафик на прием сообщений, которые заведомо являются спамом; экономятся вычислительные затраты на дальнейшие проверки писем на спам и вирусы. Необходим какой-то трафик для проведения проверок по DNS (но он заведомо меньше трафика на прием писем). Отсечь "нормальное" письмо бояться не стоит: неверная настройка почтового сервера, который Вы отсекли - не Ваша головная боль.
Для того, чтобы такие проверки проводились на этапе приемки писем, в файл /etc/postfix/main.cf нужно вставить следующие строки:
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_client_restrictions = sleep 1, reject_unauth_pipelining, permit_sasl_authenticated, permit_mynetworks, reject_unknown_client_hostname, permit
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:60000, permit
Подробнее об этих параметрах:
strict_rfc821_envelopes - запрет на использование заголовков в стиле RFC822. Если кратко - этот стандарт не имеет отношения к SMTP, а к формату самих писем, и не должен использоваться на этапе общения между серверами. Даже их названия об этом говорят: 821: SIMPLE MAIL TRANSFER PROTOCOL, 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES.
disable_vrfy_command - запрет на использование команды VRFY. Эта команда зачастую используется для сбора с сервера существующих адресов почты для дальнейшей рассылки на них спама.
smtpd_delay_reject - подождать команды RCPT TO перед (возможным) отказом от приема письма. Нужно из-за того, что некоторые сервера неверно реагируют на отказ от приема писем до посылки ими команды RCPT TO
smtpd_helo_required - требовать от сервера обязательно представиться командой HELO. Это дает возможность проведения нужных нам проверок.
Проверки на каждом этапе происходят последовательно, в указанном в каждой команде порядке. Если условие выполнено, дальнейшие проверки не производятся.
smtpd_client_restrictions - ограничения на этапе установления связи по протоколу SMTP
sleep 1 - пауза на 1 секунду для отсекания совсем нетерпеливых спам-хостов (обычно они просто сразу же рвут соединение - им нужно разослать как можно больше спама, поэтому ждать им - как серпом...)
reject_unauth_pipelining - отсечь хосты, которые пытаются слать команды в конвейере, даже не проверив, поддерживает ли это наш сервер. Это часто делают именно спам-хосты для увеличения скорости передачи
permit_sasl_authenticated - разрешить для авторизованных клиентов (пользователи)
permit_mynetworks - разрешить при соединении из моей подсети
reject_unknown_client_hostname -отказать в случае, если 1) не удалось сопоставить IP адрес имени хоста (по PTR-записи в DNS), 2) не удалось сопоставить имя IP-адресу хоста (прямой запрос DNS), 3) адрес, полученный из DNS по имени не совпадает с IP-адресом , с которого идет соединение. Отсекается ОЧЕНЬ много спам-хостов (в моем случае - процентов 80)
permit - в другом случае продолжать прием
smtpd_helo_restrictions - ограничения на этапе команды HELO:
permit_mynetworks - разрешить при соединении из моей подсети
permit_sasl_authenticated - разрешить при аутентификации (пользователи)
reject_invalid_helo_hostname - отказать при нарушении синтаксиса имени хоста в HELO (случается очень редко, тем не менее...)
reject_non_fqdn_helo_hostname - отказать, если имя хоста в HELO не в полной форме (не должно быть просто server, а должно быть типа server.domain.ltd)
reject_unknown_helo_hostname - отказать, если у хоста, указанного в команде HELO, в DNS нет записи типа MX или A (множество зобми-хостов)
permit - в другом случае продолжать прием
smtpd_sender_restrictions - проверки по команде MAIL FROM (имя отправителя)
permit_mynetworks - разрешить при соединении из моей подсети
permit_sasl_authenticated - разрешить при аутентификации (пользователи)
reject_non_fqdn_sender - отказать, если имя отправителя не в полной форме (должно быть не name или name@domain а name@domain.ltd)
reject_unknown_sender_domain - отказать, если наш сервер не является "родным" для отправителя и домен отправителя не имеет в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)
permit - в другом случае продолжать прием
smtpd_recipient_restrictions - проверки по команде RCPT TO (имя получателя)
reject_unauth_pipelining - отсечь хосты, которые пытаются слать команды в конвейере
permit_sasl_authenticated - разрешить для авторизованных клиентов (пользователи)
permit_mynetworks - разрешить при соединении из моей подсети
reject_unauth_destination - отказать, если домен-адресат: 1) не перечислен в списке доменов, для которых мы форвардим почту ($relay_domains) и не содержит команд переадресации (типа user@another@domain); 2) не является "нашим" (т.е. не перечислен в списках $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, или $virtual_mailbox_domains ) и не содержит команд переадресации (типа user@another@domain). Это - традиционные правила, чтобы наш сервер не служил т.н. Open Relay, через который спамеры рассылают почту третьим лицам.
reject_non_fqdn_recipient - отказать, если имя получателя не в полной форме (должно быть не name или name@domain а name@domain.ltd)
reject_unknown_recipient_domain - отказать, если мы не являемся "родным" сервером для получателя и домен получателя не имеет в DNS записи MX или A, или если он имеет неверную запись MX (например, пустую)
reject_unlisted_recipient - отказать, если адрес получателя не указан в списках получателей домена (не перечислен в $local_recipient_maps или $virtual_alias_maps или $virtual_mailbox_maps или $relay_recipient_maps, в зависимости от того, в какой именно таблице найден домен получателя)
check_policy_service inet:127.0.0.1:60000 - проверка у стороннего сервиса (в данном случае - postgrey, о нем чуть позже)
Такая конфигурация позволяет отсечь просто КУЧУ спама.
Теперь о postgrey. Это еще один способ борьбы со спамом. Многим он не нравится, мне - так очень. Работает он так. При приходе письма (конечно, если оно "прорвалось" через все проверки, указанные выше) сервер запоминает три параметра (так называемыймтриплет): от кого оно послано, кому послано, и кем (т.е. адрес сервера, который его посылает), и сообщает передающему серверу "Я сейчас занят, повторите чуть позже", после чего начинает отсчет времени для конкретного триплета. Большинство спамеров, как мы знаем, ждать не любят, и либо пытаются повторить посылку сразу же (на что получают тот же ответ), либо просто прекращают свои попытки. Наш же сервер, если обнаружит повторное письмо с тем же триплетом по прошествии некоторого времени (по умолчанию - 5 минут), спокойно его примет. При этом этот триплет будет запомнен на какое-то время (35 дней), так что следующие письма с тем же триплетом пройдут без задержки. Если это Ваш постоянный корреспондент, то задержек больше не будет вообще.
Установить postgrey очень просто -
sudo apt-get install postgrey
после чего просто добавьте в main.cf обращение к postgrey, как указано выше.
Если Вы хотите изменить параметры postgrey, то это делается в файле /etc/default/postgrey. Отредактируйте строку
POSTGREY_OPTS="--inet=127.0.0.1:60000"
добавив параметры --delay=N (в секундах; по умолчанию 300) и --max-age=N (в сутках; по умолчанию 35):
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=300 --max-age=35"
Стоит заглянуть еще в два файла: это /etc/postgrey/whitelist_clients и /etc/postgrey/whitelist_clients. В первом перечислены домены-отправители, письма от которых принимаются автоматом (по разным причинам), во втором - адреса-получатели, письма на которые также принимаются сразу всегда (например, abuse@). Можете при необходимости дописать в эти файлы свои строки.
В следующем посте напишу еще об интересных способах борьбы со спамом, которые я использую у себя. Удачи!
Пользователь решил продолжить мысль 30 Января 2010, 01:29:27:
Да, совсем забыл. У меня еще на всякий случай ежедневно отсылается отчет о "проделанной работе" по борьбе со спамом.
Возьмите скрипт
http://www.postconf.com/docs/spamrep/spamrep_today и сохраните его под именем
/etc/postfix/spamrep_today
сделайте его исполняемым
chmod 755 /etc/postfix/spamrep_today
и добавьте вызов его в cron
59 23 * * * /etc/postfix/spamrep_today mail &> /dev/null
Можете изменить в нем адрес для доставки отчета
MAILTO=postmaster
После этого ежедневно Вы будете получать для анализа информацию обо всех отраженных письмах.
Тема: HowTo. Почтовый сервер Postfix, Courier, MySQL и SquirrelMail (Ubuntu 8,04) (Прочитано 462227 раз)
