Postfix настройки · 11 min read · Nov 14, 2025
Фильтр спама Postfix с использованием Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC и ClamAV - Страница 3
2.3 Настройки антиспама Postfix
Предварительные заметки:
Когда клиент (компьютер, пытающийся отправить нам почту) подключается к Postfix и начинает сеанс связи, Postfix записывает информацию об этом сеансе. До момента, когда Postfix принимает почту из этого сеанса для доставки, у нас есть возможность оценить сеанс и отклонить почту, установив некоторые ограничения в main.cf. Эта ссылка иллюстрирует, что происходит во время типичного SMTP-сеанса: http://helpdesk.islandnet.com/pep/smtp.php. Ограничения ниже помогают предотвратить спам и не позволяют нашей системе стать открытым релеем. Эти ограничения приводят к тому, что часть почты отклоняется Postfix прямо у “двери”. Это сэкономит ресурсы системы, так как почта не войдет в нашу систему и, следовательно, не будет просканирована MailScanner (а затем и SpamAssassin). Это хорошо и плохо. Это экономит ресурсы системы, но также не позволяет вам видеть отклоненную почту. Все, что вы увидите, это одна или две записи в журнале от Postfix, которые в основном говорят: “Эй, почтовый сервер с именем ‘xxxxxxxx’ по IP-адресу X.X.X.X попытался отправить почту, но нарушил правило XYZ, поэтому я отклонил ее”. Теперь это мог быть спам (спамеры часто намеренно не следуют RFC, чтобы достичь своих целей), но если это была “законная” почта, скажем, от клиента, чей ИТ-отдел просто неправильно настроил свой почтовый сервер (такое бывает), вам может понадобиться разобраться с недовольством.
Если вы хотите разрешить ВСЮ почту, адресованную нам, войти через “дверь”, и, следовательно, позволить MailScanner/SpamAssassin обрабатывать весь контроль спама в системе, вам нужно будет изменить несколько настроек ниже. Лично я считаю, что комбинация контроля антиспама Postfix и SpamAssassin является наилучшей. По крайней мере, вам нужно убедиться, что вы не отключаете встроенный контроль по умолчанию для предотвращения релеев в Postfix ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
Конфигурация ниже на самом деле очень консервативна, позволяя большей части электронной почты войти через “дверь”, чтобы MailScanner и SpamAssassin могли с ней поработать. Для меня это (безопасно) отклоняет около 35% почты, направленной к моим пользователям, так что я думаю, что эти настройки довольно ценны. Я рекомендую этот подход для начала. Добавление дополнительных ограничений увеличит вероятность отклонения действительной почты от неправильно настроенных компьютеров. Если вы решите добавить/удалить разрешения/ограничения в будущем, делайте это по одному за раз и дайте себе достаточно времени, чтобы оценить эффект изменения. Я настоятельно рекомендую вам действительно хорошо понимать, как работают эти ограничения, прежде чем вносить изменения в записи ниже. Среди прочего, неправильное понимание этих вещей может привести к отклонению законной почты и/или к тому, что мы станем открытым релеем. Обратите внимание, что ограничения не всегда ограничивают, некоторые также разрешают.
Если вы хотите лучше понять эти настройки, хорошими ресурсами являются http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, несколько устаревший (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt и эта отличная книга. Вы заметите, что я использую только несколько из тех же настроек, что и эти, так что эта конфигурация не является столь же ограничительной. Имейте в виду, что SpamAssassin и MailScanner вскоре вступят в дело и предоставят нам гораздо более гибкие и настраиваемые варианты для распознавания и манипуляции спамом.
2.3.1 smtpd_helo_required
Заставьте любой подключающийся почтовый сервер выполнить правильный SMTP “рукопожатие” и объявить свое имя. Интернет RFC требуют этого, поэтому мы тоже.
postconf -e "smtpd_helo_required = yes"Предисловие: Этапы ограничений Postfix следующие и обрабатываются в следующем порядке:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictionssmtpd_recipient_restrictions
smtpd_data_restrictionsМы собираемся разместить записи только в последних трех этапах ограничений. Этапы ограничений обрабатываются в этом порядке независимо от порядка, указанного в main.cf.
2.3.2 smtpd_sender_restrictions
Этот этап ограничения ограничивает, какие адреса отправителей эта система принимает в командах MAIL FROM: (отправитель конверта). Мы разместим три теста (ограничения) на этом этапе ограничения.
Этап ограничения содержит список ограничений (тестов). Обычно тесты оцениваются как DUNNO, REJECT или OK. DUNNO означает “Я не знаю, что делать, пусть следующий тест решит”. REJECT просто отклоняет почту. OK означает, что больше никаких тестов не выполняется на этом этапе ограничения, тесты продолжаются на следующем этапе (если он есть). Тесты типа Reject* обычно оцениваются как REJECT или DUNNO. Тесты типа Permit обычно оцениваются как OK или DUNNO, а тесты типа check__access могут выполнять различные действия. Иллюстрация показывает основную логику.
SMTP session
|
V
restriction stage-------------
test ---------------REJECT->
| \
| DUNNO
| \
| V
| next test------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
next restriction stage------->2.3.2.1 check_sender_access
См. http://www.postfix.org/access.5.html. Здесь мы просим Postfix сравнить отправителя конверта с записями в базе данных /etc/postfix/sender_access и действовать в соответствии с этими записями, если совпадение найдено. Мы также определяем, какое действие принимается там (OK, DUNNO, REJECT и т. д.) на основе каждого отправителя. Если отправитель не указан в файле, тест оценивается как DUNNO, и выполняется следующий тест. Я предоставлю примеры немного позже. Одно из применений этого файла - разместить список отправителей (адресов электронной почты, доменов, сетевых адресов и т. д.), от которых мы не хотим получать почту (включить в черный список). У нас также будет возможность включить в черный список отправителей в MailScanner и SpamAssassin, но будет экономия ресурсов, если мы включим их в черный список здесь. Мы также будем использовать этот файл, чтобы позволить конкретным отправителям обойти следующие два теста на этом этапе ограничения. Если мы дадим им OK здесь, больше никаких тестов не выполняется на этом этапе ограничения, тесты продолжаются на следующем этапе ограничения ( smtpd_recipient_restrictions). Обратите внимание, что если бы мы разместили эту настройку в этапе ограничения smtpd_recipient_restrictions перед тестом reject_unauth_destination, и мы бы дали кому-то OK там, тест reject_unauth_destination, расположенный там, был бы пропущен. Это было бы плохо, потому что любой, кому мы дали OK, мог бы использовать наш сервер как открытое реле. Ограничения доступа оцениваются в том же порядке, в котором мы их перечисляем, и если совпадение найдено, это повлияет на то, как (или будет ли) оцениваться дальнейшие ограничения.
2.3.2.2 reject_non_fqdn_sender
Отклонить, когда адрес отправителя конверта не в правильном формате. Помните, что “отправитель конверта” - это то, что отправляющий почтовый сервер указывает в строке “MAIL FROM:” во время сеанса SMTP, а не строке заголовка “From:”. “Joe” не может отправить нам почту (потому что мы не можем ответить “Joe”), но “[email protected]” по крайней мере является адресом электронной почты. Если отправитель не будет отклонен на этом этапе, этот тест оценивается как “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Отклонить, когда доменная часть адреса отправителя конверта не имеет DNS “A” или “MX” записи. Эта настройка отклоняет около 35% почты, поступающей на мой почтовый сервер. Обычно спамеры используют поддельные доменные имена, чтобы избежать последствий отклоненной почты. Также важно, чтобы мы не заполняли нашу очередь уведомлениями о возврате, которые никогда не могут быть доставлены из-за того, что домен отправителя даже не существует. Если у домена отправителя есть запись “A” или “MX”, этот тест также будет оцениваться как “DUNNO”. Иногда вы увидите в отчете, что кто-то, от кого вы хотите получить почту, был отклонен этой настройкой. Одной из возможных причин этого является то, что законные отправители намеренно используют поддельные доменные имена, чтобы вы не могли ответить им. Вот где список доступа отправителей оказывается полезным. Вы можете дать им OK там, и этот тест будет пропущен.
Теперь, чтобы реализовать эти три ограничения:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
Ограничения доступа, которые сервер SMTP Postfix применяет в контексте команды RCPT TO:. Это относится к “получателю конверта”, который клиент указал в строке “RCPT TO:” во время сеанса SMTP, а не строке заголовка “To:”. smtpdrecipient_restrictions - это еще один этап ограничения, который содержит список конкретных ограничений. Другие этапы ограничения, которые оцениваются перед smtpd_recipient_restrictions, - это smtpd_client_restrictions, smtpd_helo_restrictions и smtpd_sender_restrictions (в этом порядке). Ограничения, которые обычно идут на этих предыдущих этапах ограничения, могут быть альтернативно размещены в smtpd_recipient_restrictions. Поэтому некоторые люди предпочитают размещать все smtpd*_restrictions, которые обычно идут на предыдущих этапах ограничения, в smtpd_recipient_restrictions (в правильном порядке) и оставлять предыдущие этапы не настроенными (пустыми). В нашем случае безопаснее использовать smtpd_sender_restrictions и smtpd_recipient_restrictions. Давайте рассмотрим те конкретные ограничения (тесты), которые мы размещаем в smtpd_recipient_restrictions:
2.3.3.1 permit_mynetworks
Разрешает машинам, перечисленным в “mynetworks”, пропустить остальные тесты на этом этапе ограничения (permit = OK). Другими словами, он выходит из этого этапа и тестируется на следующем этапе (smtpd_data_restrictions). Поскольку permit_mynetworks размещен перед reject_unauth_destination, это означает, что машины в $mynetworks могут пересылать почту на любой домен. Без этого мы могли бы отправлять почту только на наши собственные домены. Если IP-адрес отправителя не указан в $mynetworks, тест оценивается как “DUNNO” и продолжается к следующему тесту (reject_unauth_destination).
2.3.3.2 reject_unauth_destination
Это, наряду с permit_mynetworks, используется для контроля релеев. Эта настройка, по сути, означает, что почта, предназначенная для любого домена, для которого мы не настроили нашу машину для приема почты, будет отклонена. В нашем случае Postfix будет использовать настройку relay_domains (или таблицу), которую мы настроили ранее, чтобы определить, какие это домены. См. http://www.postfix.org/postconf.5.html#reject_unauth_destination для получения дополнительных деталей. Если домен указан в relay_domains, этот тест оценивается как “DUNNO” и сеанс может продолжаться к следующему тесту (если он есть). Точно так же, как “mynetworks”, эта настройка крайне критична. Размещая permit_mynetworks непосредственно перед reject_unauth_destination, мы уверены, что можем отправлять почту на домены, отличные от наших, но мы будем принимать почту, адресованную нам, только от компьютеров вне нашей сети, таким образом permit_mynetworks и reject_unauth_destination работают как команда.
2.3.3.3 reject_unauth_pipelining
Отклоняет массовые рассылки, которые пытаются использовать пайплайнинг для ускорения доставки, не проверяя, поддерживается ли это сначала (не RFC, распространено среди спамеров).
Теперь, чтобы реализовать эти три ограничения:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Необязательные ограничения доступа, которые сервер SMTP Postfix применяет в контексте команды SMTP DATA:. Как и smtpd_recipient_restrictions, это этап ограничения.
2.3.4.1 reject_unauth_pipelining
Я повторяю эту настройку в smtpd_data_restrictions, так как она не всегда эффективна, когда размещена в smtpd_recipient_restrictions. Я включаю ее в smtpd_recipient_restrictions, так как мне нравится размещать ее перед любыми серверами политики. Обратите внимание, что есть только несколько ограничений, которые хорошо используют smtpd_data_restrictions.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 Файлы управления фильтрацией содержимого Postfix:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks и /etc/postfix/body_checks
Эти файлы будут перечислять определенные “строки” текста и сообщать Postfix, что делать с почтой, если он встретит эти строки в заголовках электронной почты или в теле сообщения. Примерные файлы уже созданы для нас, с комментариями, объясняющими, что в них помещать. Вы можете редактировать их по своему усмотрению. Обратите внимание, что эти файлы требуют использования “формата регулярных выражений”. “regexp” - это то, о чем вам стоит узнать, чтобы жить в мире *nix. Купите книгу или исследуйте это в Интернете в какой-то момент. Для примера сложного файла header_checks от кого-то с характером, взгляните на http://www.geekounet.org/filters/header_checks. Но не следуйте этому слепо, это всего лишь пример! Вот пример файла body_checks: http://www.securitysage.com/files/body_checks. Вам стоит проверить http://www.securitysage.com/guides/postfix_uce.html, когда у вас будет свободное время. В частности, http://www.securitysage.com/antispam/hedchek.html и http://www.securitysage.com/antispam/bodchek.html. Я не рекомендую вносить большое количество изменений в любую часть Postfix без того, чтобы дать себе достаточно времени для оценки эффектов. Как черепаха, двигайтесь медленно, живите долго.
2.3.5.1 header_checks & body_checks
Давайте добавим эти два в main.cf. header_checks необходим, потому что он позволяет нам удерживать всю входящую электронную почту, чтобы MailScanner мог сделать свое дело:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Редактируйте header_checks:
vi /etc/postfix/header_checksДобавьте эту строку в файл header_checks, без нее MailScanner не будет работать:
/^Received:/ HOLDОбратите внимание, что нам не нужно постмапировать таблицы типа pcre. Они остаются в виде обычного текста, и Postfix использует их “как есть”.
Вы также можете настроить mime_header_checks и nested_header_checks вместе с header_checks и body_checks. Если вы слишком креативны с фильтрацией содержимого в Postfix (используя header_checks и body_checks), это может значительно повлиять на производительность.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Мы ссылались на этот файл в smtpd_sender_restrictions. Мы используем этот файл, чтобы проверить отправителя прямо у “двери”. В этом файле мы перечислим определенных отправителей/доменов/диапазоны IP-адресов для специальной обработки. Ниже приведены поддельные примеры, создайте свои собственные по своему усмотрению. Пожалуйста, прочитайте /etc/postfix/sender_access для получения дополнительной информации. Хотя вы можете использовать этот файл для различных целей, учитывая, как мы его настроили в smtpd_sender_restrictions, я предлагаю использовать его либо для включения в черный список отправителей, либо для разрешения определенным отправителям обойти оставшиеся тесты в smtpd_sender_restrictions.
vi /etc/postfix/sender_access#Пример файла карты доступа отправителей
[email protected] 550 Нет MLM, спасибо
allspam.tld 550 Спам здесь не принимается
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKПоскольку это хеш-таблица, вам нужно постмапировать ее, как обычно:
postmap /etc/postfix/sender_access2.3.6 Последний взгляд на установку Postfix
Обзор изменений:
less /etc/postfix/main.cfПроверьте содержимое файла на наличие ошибок и исправьте при необходимости. Запустите Postfix:
postfix startПроверьте, что Postfix отвечает:
telnet 127.0.0.1 25Вы должны увидеть:
220 [yourFQDNhere] ESMTP Postfix (Ubuntu)нажмите [enter] несколько раз; затем введите quit, чтобы выйти.
Если он не отвечает таким образом, откройте другое окно терминала и остановите Postfix postfix stop. Убедитесь, что вы выполнили newaliases и все команды postmap выше. Проверьте все настройки в main.cf и master.cf. Есть хорошая статья по устранению неполадок Postfix по адресу http://www.postfix-book.com/debugging.html, но имейте в виду, что наша система еще не готова к пересылке почты в этот момент (она окажется в очереди).
Каждый раз, когда вы вносите изменения в master.cf или main.cf или в таблицы данных, в большинстве (но не во всех) случаев необходимо перезагрузить Postfix с помощью:
postfix reloadТеперь, когда у нас есть базовая конфигурация Postfix, http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall и http://www.postfix.org/BASIC_CONFIGURATION_README.html - хорошие места, чтобы лучше понять некоторые из настроек, которые мы использовали, и в этот момент эти README будут более понятны.
По умолчанию наш Postfix работает в chroot. Если вы не знаете, что это значит, это не будет иметь большого значения на данный момент. Я оставляю вам исследовать, что такое chroot, в более позднее время. Некоторые системные файлы, необходимые для правильной работы Postfix, были скопированы в тюрьму chroot Postfix ( /var/spool/postfix) во время установки. Иногда оригинальные файлы могут быть изменены, и Postfix будет жаловаться, что копия, которую он имеет, не такая же, как оригинал. Когда это происходит, вы можете вручную скопировать файл(ы), о которых Postfix жаловался, в тюрьму chroot, или мы можем просто запустить скрипт, который поставляется с исходным кодом Postfix (называется LINUX2), который снова скопирует все файлы, необходимые Postfix, туда, где они нужны.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkЭто делает скрипт LINUX2 исполняемым, копирует его в директорию в нашем пути, а затем выполняет его. LINUX2 обычно решает любые проблемы или неполадки с Postfix, если вы видите какие-либо ошибки в журналах с доступом Postfix к конфигурационным файлам или директориям.
Get new posts in your inbox
No spam. Unsubscribe anytime.