Greylisted в каком файле список
Уже устал рассказывать пользователям и знакомым что такое Greylisting и "с чем его едят". А также отвечать на кучу вопросов "зачем", "как" и "почему". Поэтому и появилась эта статья.
Немного теории
Преимущества
В то же время грейлистинг практически полностью исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату. Исключение может составить разве что случай, когда почтовый сервер отправителя по тем или иным причинам не вполне следует установленным стандартам. Но это, как говорится, не наши проблемы.
Недостатки
Ещё одна проблема связана с серверами, на которых эксплуатируется «конкурирующая» система борьбы со спамом – так называемый обратный звонок (callback). Суть этого метода заключается в следующем: при получении входящего соединения сервер на стадии RCPT TO приостанавливает сессию и имитирует рабочую сессию с сервером, указанным в команде MAIL FROM. Если эта попытка из-за несуществующего адреса отправителя или по другим причинам завершается неудачей, то и приостановленное соединение разрывается без дальнейшей обработки.
Нетрудно догадаться, что если вы будете использовать грейлистинг, то у вас наверняка возникнут проблемы с отправкой почты на серверы, где настроен callback: в ответ на ваше подключение удалённый сервер попытается установить с вами «встречное» соединение, а вы его отправите «попробовать немного позже». Кому от этого будет хуже – неизвестно.
Как это работает?
Технология Graylisting предельно проста. Для ее работы необходимы всего лишь три составляющие SMTP-сессии, т.н. «триплет»:
3. Адрес получателя, так же передаваемый в MIME-конверте
-> MAIL FROM: < sender [at] somedomain [dot] com >
<- 250 2.1.0 Sender ok
-> RCPT TO: < recipient [at] otherdomain [dot] com >
<- 250 2.1.5 Recipient ok
<- 250 2.0.0 Message accepted for delivery
Понятно, что на этапе установки SMTP-сессии можно провести массу проверок, как то проверка по DNS SBL\RBL, проверку Reverse DNS Lookup, проверка на блокировку отправителя\получателя по Custom Blacklist\Whitelist. Ну а если спамер новенький? Письмо пройдет, а зачастую письма могут быть очень серьезных объемов из-за обилия графической информации, различных вложений, а зачастую и вирусов, и лишь после полного прохождения в дело вступят интеллектуальные контентные фильтры. Что мы имеем? Мы имеем гигантский трафик, мы имеем значительную ресурсоемкость приложений контентной фильтрации, и даже можем получить остановку почтового потока. Что в данной ситуации делает Graylisting?
-> MAIL FROM: sender [at] somedomain [dot] com
<- 250 2.1.0 Sender ok
-> RCPT TO: < recipient [at] otherdomain [dot] com >
<- 451 4.7.1 Please try again later
1. Время, когда данный триплет был получен впервые (record create time)
2. Время прекращения блокировки данного триплета (block expiried time)
3. Время жизни записи (record age time)
4. Время последнего вхождения данного триплета (last entry time)
Дополнительно может храниться информация об общем количестве отложенных сессий и о количестве сессий, прошедших успешную передачу.
В технологии Graylisting’а, одним из очень частых методов является ручное составление белых списков. Это часто используется для ускорения доставки писем от важных отправителей, от доверенных доменов, от надежных ретрансляторов.
Технология белых списков основана на абсолютном доверии доменному суффиксу, либо IP-адресу сервера, выполняющего отправку, либо конкретному отправителю. Этот метод тоже имеет свои недостатки, например при помощи подмены адреса, спамер может теоретически обойти Graylisting используя белые списки. Но на это есть другие проверки, о чем речь не в этой статье.
1. Проверка по белому листу IP-адреса сервера-отправителя, если сервер в белом списке – письмо принимается.
2. Проверка адреса отправителя по белому листу – если адрес в нем присутствует – письмо принимается.
3. Проверка адреса получателя по белому списку – если он там имеется, письмо принимается. (А что, есть общительные люди, горящие желанием принимать абсолютно всю почту, и с наслаждением в ней копаться. Чужие слабости надо уважать)
4. Проверка триплета на вхождение:
4.1. Если это первое вхождение, создается запись в базу\файл данных со штампом RCT (record create time), запускается счетчик BET (block expiried time) и отправляющему серверу отправляется код ошибки 451 4.7.1.
4.2. Если это не первое вхождение триплета, но счетчик BET еще не обнулился, отправляющему серверу уходит код ошибки 451 4.7.1., в базе создается запись со штампом last entry time
4.3. Если это не первое вхождение, счетчик BET равен нулю, письмо принимается сервером. Запись last entry time обновляется
5. При успешном прохождении добавляется единица к счетчику успешных попыток передачи, и время жизни записи сбрасывается на исходное значение.
6. Если поле MAIL FROM имеет значение null, что классифицируется как message with blank sender, после команды RCPT TO временная ошибка не отправляется, но она отправляется после команды DATA.
Greylisting: панацея от спама или «мыльный пузырь»?
Методов борьбы со спамом за последние годы разработано множество – от технических, таких как «чёрные списки», Байесовые классификаторы, комплексный анализ заголовков, до юридических, когда за рассылку спама предусматриваются всё более жестокие наказания вплоть до уголовной ответственности.
Один из этих методов, получивший название «greylisting», или «серых списков», в последнее время приобретает всё большую популярность. Для удобства восприятия, я буду использовать транслитерированный термин «грейлистинг».
Идея «серых списков»
Пример практической реализации
Чтобы было понятнее, рассмотрим работу грейлистинга на конкретном примере. Для Sendmail существует программа milter-greylist. Её установка из портов FreeBSD труда не составит:
Ну и полезным будет дополнить представленный в конфигурационном файле список «белых» адресов теми серверами, с которых вы регулярно получаете «легальную» корреспонденцию. Это опять-таки некоторый «акт милосердия» по отношению к отправителям:
Ещё пропишите в /etc/rc.conf такую строку:
Теперь соответствующий демон будет запускаться сценарием /usr/local/etc/rc.d/milter-greylist.sh автоматически. Из текста этого же сценария можно узнать точный путь к сокету, который должен использовать Sendmail для взаимодействия с milter-greylist. Этот сокет и нужно указать в вашем mc-файле для настройки Sendmail:
INPUT_MAIL_FILTER(`miltergreylist', `S=local:/var/milter-greylist/milter-greylist.sock, F=, T=S:4m;R:4m')dnl
Теперь, пересобрав конфигурационный cf-файл и перезапустив Sendmail, вы получите работающий «серый» фильтр. В /var/log/maillog (если не менялись настройки по умолчанию демона Syslog) вы сможете отследить то, как этот фильтр работает:
Jun 5 10:23:52 mydomain milter-greylist: k556NpVc033684: addr 1.2.3.4 from
to delayed for 00:05:00
Jun 5 11:23:58 mydomain milter-greylist: k557Nuv5034199: addr 1.2.3.4 from
rcpt : autowhitelisted for 24:00:00
Продолжим рассмотрение лог-файла. Так будет выглядеть подключение со стороны сервера, представленного в «белом» списке, т.е. в правилах acl whitelist:
Как видите, ему никаких препятствий в работе не создаётся. Ну и, наконец, для спамеров (к сожалению, не для всех) будет представлена только одна запись про «delayed for 00:05:00». Что и требовалось доказать.
Плюсы грейлистинга
В то же время грейлистинг практически полностью исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату. Исключение может составить разве что случай, когда почтовый сервер отправителя по тем или иным причинам не вполне следует установленным стандартам. Но это, как говорится, не наши проблемы.
Минусы грейлистинга
Рассмотренный выше milter-greylist позволяет настроить синхронизацию между различными MX-хостами (см. комментарии к опциям peer и syncaddr в конфигурационном файле, а также man greylist). Благодаря этому все настроенные таким образом почтовые серверы будут использовать общую базу. То есть отправитель, обратившийся на резервный хост после неудачной попытки пробиться на основной, уже будет известен Backup-серверу, и соответственно его обработают успешно.
Правда, опять-таки сработает это лишь в том случае, если повторная попытка будет выполняться не сразу, а спустя некоторое время. Ну и к сожалению, не каждый администратор имеет полный доступ к настройке машин, определённых как Backup-серверы для его домена.
Ещё одна проблема связана с серверами, на которых эксплуатируется «конкурирующая» система борьбы со спамом – так называемый обратный звонок (callback). Суть этого метода заключается в следующем: при получении входящего соединения сервер на стадии RCPT TO приостанавливает сессию и имитирует рабочую сессию с сервером, указанным в команде MAIL FROM. Если эта попытка из-за несуществующего адреса отправителя или по другим причинам завершается неудачей, то и приостановленное соединение разрывается без дальнейшей обработки.
Нетрудно догадаться, что если вы будете использовать грейлистинг, то у вас наверняка возникнут проблемы с отправкой почты на серверы, где настроен callback: в ответ на ваше подключение удалённый сервер попытается установить с вами «встречное» соединение, а вы его отправите «попробовать немного позже». Кому от этого будет хуже – неизвестно.
В нашем «наглядном пособии» – milter-greylist – эта проблема тоже известна, и для её решения предусмотрен ещё один параметр – delayedreject. При его активации milter-greylist будет возвращать ошибку 4xx не после команды RCPT TO, как это предусмотрено по умолчанию, а после получения команды DATA. Это вынуждает удалённый сервер надеяться на успех чуть дольше, но зато не создаёт препятствий для «обратного звонка», который, как правило, завершается после ответа сервера на команду RCPT TO.
Прогнозы на будущее
Можно сделать вывод, что грейлистинг при всех своих недостатках на данный момент – вполне эффективная технология. Но её эффективность определяется исключительно низкой распространённостью. Звучит парадоксально, но это так и есть – чем больше серверов станут использовать «серые» списки в своей практике, тем менее эффективной и более проблемной для законопослушных отправителей станет эта технология.
Так, по мере распространения грейлистинга всё больше ресурсов будет тратиться на доставку почты. Хорошо, если ваши пользователи имеют ограниченный и регулярный список адресатов, большая часть которых будет постоянно присутствовать в «белом» списке, не влияя на эффективность работы. А если нет?
Не исключено, что крупные почтовые провайдеры будут вынуждены устанавливать специальные Fallback-серверы исключительно для обслуживания «серой» почты, что естественно приведёт к удорожанию услуг или снижению их качества (впрочем, о каком качестве может идти речь, если каждое новое письмо в среднем будет задерживаться минут на сорок).
Конечно, можно возразить, что «своя рубашка ближе к телу» и что дополнительные затраты на грейлистинг с лихвой компенсируются значительным снижением спам-трафика и нагрузки на оборудование, им создаваемой. Только вот действительно ли это снижение будет столь уж значительным?
Поэтому не стоит возлагать такие надежды на использование «серых» списков. И уж конечно же, не нужно всюду пропагандировать эту технологию – чем меньше людей о ней знают, тем больше преимуществ она принесёт лично вам.
Ложка мёда
Так что будем надеяться, что когда-нибудь в наших почтовых ящиках будут «оседать» только действительно нужные нам письма.
Приложение
Сколько можно ждать?!
Вас же вполне могут убедить часто приводимые доводы в защиту именно этого значения:
- Многие MTA используют как раз 1 час в качестве периода обработки очереди;
- Этот интервал достаточен для того, чтобы рассылка спамера была обнаружена, и его адрес попал в соответствующие «чёрные» списки;
- Большинство пользователей вполне могут подождать 1 час в ожидании письма, и такая задержка во многих случаях останется незамеченной.
Немного статистики
Испытания milter-greylist на небольшом, но очень «боевом» почтовом сервере показали, что пользователи стали получать спама примерно в десять раз меньше, чем до внедрения этой системы (при том, что для обслуживания домена используется неподконтрольный мне Backup-сервер без грейлистинга). Показатели по вирусам ещё лучше – их число снизилось примерно в 30 раз (как правило, они автоматически рассылаются вирусами же, которые менее сообразительны, чем живые спамеры).
Здесь учитывался лишь спам, источники которого не попали в DNSBL-списки, используемые на сервере (в первую очередь срабатывает блокировка по DNSBL, а затем уже выполняется проверка по greylist.db).
Автор: Сергей Супрунов
Источник
Этот пост June 23, 2008 at 6:23 pm опубликовал molse в категории Spam. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.
Данная статья посвящена описанию конфигурационного файла ISPmanager (/usr/local/mgr5/etc/ispmgr.conf). Для удобства чтения и восприятия описанные параметры условно разделены в соответствии с модулями ISPmanager (многие параметры используются разными модулями). Алфавитный список параметров и опций конфигурации с указанием, к какой именно панели относится тот или иной параметр конфигурации, представлен в статье "Список параметров конфигурации ISPmanager 6" .
Модуль управления пользователями
- path DefaultHomeDir — задаёт значение домашней директории пользователей (полный путь). Не изменяйте данный параметр после начала работы с ISPmanager, это приведет к непредсказуемым последствиям! Не рекомендуем использовать вместе с ISPmanager Business. Значение по умолчанию: /var/www
- path DefaultShell — определяет полный путь до интерпретатора команд. Значение по умолчанию: /bin/bash
- Option EnableQuota — если указана данная опция, панель будет активировать модуль управления системными квотами, если опция не указана, активироваться квоты не будут
- Option DisableQuotasync — если указана данная опция, панель не будет вызывать команду quotasync перед получением информации о системных квотах. Применяется при использовании панели на виртуализации OpenVZ для решения проблем с отображением значений квот.
- Option XfsQuota — если указана данная опция, панель будет работать с квотами с помощью команд управления квотами XFS
Модуль управления FTP-пользователями
-
FTP <FTP-сервер> <Хранилище> — данный параметр сигнализирует об установленном и настроенном для работы FTP-сервере. Здесь:
- DNS — используемый сервер доменных имён
- DnsHostname — параметр, описывающий формат SOA-записи, по умолчанию берется hostname сервера (для Business-версии параметр указывается в ispmgrnode.conf на сервере с ролью основного сервера имен)
- SOAExpireTime — параметр Expire для SOA-записи. Определяет время в секундах, в течение которого вторичный DNS-сервер будет пытаться завершить синхронизацию зоны с первичным.
- SOARefreshTime — параметр Refresh для SOA-записи. Применяется для первичного сервера имён. В ISPmanager Business используется на узле с первичным сервером имён.
- SPFRelayIP — список IP-адресов, включаемых по умолчанию в автоматически создаваемую при создании доменного имени TXT-запись вида "v=spf1". Для ISPmanager Business этот параметр нужно прописать в ispmgrnode.conf на узле кластера с ролью "Основной сервер имен"
- ViewName — имя горизонта видимости DNS (view), используемого ISPmanager для создания доменных зон.
- DnsNsMasterIp — при использовании внешних серверов имён (NSы) данный параметр имеет приоритет при указании основного сервера имён (master) для зон, создаваемых на внешних серверах имён. Если параметр не указан, используется один из IP-адресов сервера.
- DomainContact — значение поля "Email администратора", указываемое в настройках создания доменных имён
- NameServers — значение поля "Серверы имен", указываемое в настройках создания доменных имён
- MailServers — значение поля "Почтовые серверы", указываемое в настройках создания доменных имён
- DefaultARecords — значение поля "Поддомены", указываемое в настройках создания доменных имён
- NsIps — адреса для NS-серверов разделенные пробелом.
- Option NoSPFRecord — данная опция отключает автоматическое создание TXT-записи вида "v=spf1" при создании доменного имени
- Option InsecureDomain — указывает панели, что при создании доменов не нужно проверять владельца домена более высокого уровня.
- Option AcmeSkipAccountCheck — отключает проверку числа неудачных попыток подключения к аккаунту Let's Encrypt
- AcmeAccountCheckAttempts — количество неудачных проверок аккаунта Let's Encrypt, после которого аккаунта будет создаваться заново. Значение по умолчанию — 3.
- LetsencryptProcessCount — количество одновремено выпускаемых сертификатов Let's Encrypt.
- LetsencryptVerifyPeriod — минимальный период между повторными попытками выпуска сертификата Let's Encrypt.
- DBCacheMaxDelay — максимальная задержка в секундах перед следующим запросом на обновление данных о реальном размере БД
- DBCacheCheckInterval — интервал (в минутах) между проверками необходимости обновления размеров баз данных (по умолчанию "1"). Для ISPmanager Business этот параметр нужно прописать в ispmgrnode.conf
- DbAllowUpperCase — разрешает использовать символы в верхнем регистре в именах пользователей и баз данных. По умолчанию отключена, то есть по умолчанию имя базы данных при редактировании или создании будет приведено в нижний регистр.
- DockerMaxAttempt — количество попыток соединения с базой данных для проверки её доступности. Попытки проходят каждые 10 секунд после запуска докер-контейнера с базой данных. Значение по умолчанию — 60.
- MySQLDumpOptions — список дополнительных параметров командной строки mysqldump
- PGDumpOptions — список дополнительных параметров командной строки pg_dump
- path phpmyadmin-servers — путь до специального конфигурационного файла phpMyAdmin куда панель будет записывать информацию о доступных серверах баз данных. По умолчанию, /etc/phpmyadmin/servers.ini.php
- path mysql — путь до исполняемого файла mysql
- path mysqlcheck — путь до исполняемого файла mysqlcheck
- MTA — почтовый сервер
- POP3 — POP3-сервер
- MailFilter — сортировщик писем
- Greylisting — sendmail — milter-greylist, для exim и postfix — postgrey
- afterlogic-alias — псевдоним afterlogic
- SievePipePlugin — плагин для сортировщика Sieve
- EmailAuth — способ авторизации
- DovecotPwScheme — схема шифрования по умолчанию
- GreyListKeyword — параметр greylisting (acl/racl), может отличаться в зависимости от версии
- DkimCheck — приложение для подписи DKIM
- WebMail — используемый WebMail
- EmailAVCheck — приложение для проверки писем на вирусы
- EmailSpamCheck — приложение для проверки писем на спам
- EmailRecacheDelay — время в минутах через которое будет "перестраиваться" пароли для почтовых ящиков (чтобы избежать изменения извне). Если данный параметр равен 0 то данное действие не будет производиться.
- ForwardEmailCount — максимальное количество почтовых ящиков для отправки копии письма.
- path afterlogic — путь до директории afterlogic
- path clamav-srvc — путь до директории clamav
- path clamav-whitelist — путь до белого списка clamav
- path dovecot-passwd — путь до dovecot.passwd
- path dovecot-doveadm — путь до doveadm
- path exim-passwd — путь до exim4/passwd
- path exim-aliases — путь до /exim4/aliases
- path exim-domainips — путь до exim4/domainips
- path exim-whitelist — путь до exim4/whitelist
- path exim-blacklist — путь до exim4/blacklist
- path milter-greylist-restart — команда перезапуска greylisting
- path greylist-conf — путь до конфигурационного файла greylisting
- path mtaname-virtusertable — путь до виртуальной таблицы пользователей (где mtaname — имя mta)
- path mtaname-localhostnames — путь до localhostnames (где mtaname — имя mta)
- path mtaname-accessdb — путь до БД доступа (где mtaname — имя mta)
- path mtaname-aliases — путь до таблицы псевдонимов (где mtaname — имя mta)
- path opendkim-srvc — путь до сервиса OpenDKIM
- path opendkim-keyspath — путь до ключей OpenDKIM
- path opendkim-genkey — путь до opendkim-genkey
- path postfix-postmap — путь до postmap
- path postfix-postalias — путь до postalias
- path postfix-bin — путь до postfix
- path postfix-domainips — путь до domainips
- path postfix-master — путь до основного конфигурационного файла postfix
- path postgrey-restart — команда для перезапуска postgrey
- path postgrey-recipients — путь до postgrey_whitelist_recipients
- path postgrey-clients — путь до postgrey_whitelist_clients
- path sasldb — путь до sasldb
- path db4 — путь до db4
- path saslpasswd — путь до saslpasswd2
- path sendmail-newaliases — путь до newaliases
- path sendmail-restart — команда перезапуска sendmail
- path sendmail-mc — путь до sendmail.mc
- path spamassassin-restart — команда для перезапуска spamassassin
- path spamassassin-localcf — путь до local.cf
- path MailHomeDir — название директории для писем по умолчанию
- Option LocalDelivery — разрешить только локальные перенаправления
- Firewall — название используемого брандмауэра
- Option FirewallCheckAccess — параметр отключения контроля безопасности
- path gnutar — путь до архиватора gnu tar, здесь же можно задать дополнительные опции. По умолчанию берется из PATH
- path gzip — путь до архиватора gzip, здесь же можно задать дополнительные опции. По умолчанию берется из PATH
- path cat — путь до утилиты cat, здесь же можно задать дополнительные опции. По умолчанию берется из PATH
- BackupPriority — приоритет с которым будет запускаться процесс backupctl. Значение от -20 до 19. Где -20 — самый высокий приоритет, 19 — самый низкий. По умолчанию выставлен приоритет 10
- BackupTimeout — таймаут на подготовку данных. По умолчанию значение не ограничено. Более актуально для VMmanager и VEmanager
- Option EnableOldBackup — использовать параллельно и старую, и новую реализацию резервного копирования
- DefaultInterface — имя интерфейса, на который будут добавляться дополнительные IP адреса. Для ISPmanager Business добавляется в файл конфигурации ispmgrnode.conf
-
FTP-сервер — это короткое имя FTP-сервера. Возможные значения: proftpd, pureftpd и vsftpd.
Хранилище — тип хранилища виртуальных пользователей. На текущий момент поддерживается только тип file.
Модуль управления Web-доменами
Параметры конфигурации данного модуля подробно описаны в статье "ISPmanager: Конфигурация web сервера"
Модуль управления доменными именами
Модуль управления базами данных
path mysqldump — путь до исполняемого файла mysqldump
Если какой-либо из вышеописанных путей не задан в конфигурационном файле панели, то будет произведен поиск необходимого исполняемого файла в директориях указанных в переменной среды PATH.
Модуль управления почтовыми доменами
Модуль управления брандмауэром
Модуль резервного копирования
Примечание: Временная директория периодически очищается панелью. Не нужно назначать временной директорией директорию, в которой есть важные данные
Модуль управления IP-адресами
Модуль управления PHP
-
PhpReloadDelay — задержка перед обновлением конфигурации PHP-FPM. Значение по умолчанию — 2 с.
Option DisableFpmPerSite — отключить создание индивидуальных настроек PHP-FPM для сайта.
Большая часть спама рассылается при помощи бот-сетей (сетей организованных из зараженных вирусом компьютеров). Поскольку рассылку спама выполняет не полноценный почтовый сервер, то найдя особенности, отличающие его от такового мы можем отличить спам от обычных писем. Что делает почтовый сервер в случае если он по какой-то причине не может сразу доставить почту? Правильно, делает повторы с увеличивающимися таймаутами. Вирус на подобные действия не имеет ни времени, ни ресурсов, поэтому если имитировать ошибку доставки письма, то обычной почте это не повредит, а спам-письмо скорее всего доставлено не будет.
Такой способ называется фильтрацией писем на основе серых листов. При коннекте к почтовому серверу, проверяется IP отправителя, адреса From, To на наличие их в списке сервера. Если таковые адреса в списке сервера уже имеются, то почта принимается. В противном случае сервер отвечает отказом сессии и отправитель вынужден сделать повтор спустя какой-то промежуток времени. Адрес отправителя при отказе принять от него письмо заносится в так называемый серый список. При повторном соединении от этого отправителя его адрес будет перемещен на некоторое (обычно этот интервал в диапазоне нескольких недель) в так называемый белый список и прием с этого адреса будет разрешен в течение всего этого времени.
Что есть в Debian на эту тему?
В дебиан для использования фильтрации на основе серых листов необходимо просто установить пакет greylistd:
Далее, как обычно в Debian, все просто. Просматриваем два конфига только что установленного демона.
/etc/greylistd/config
Этот конфиг после установки уже довольно оптимально настроен, поэтому в большинстве случаев его достаточно просто просмотреть. Наиболее интересные параметры в данном конфиге следующие:
-
Почтовые сервера обычно делают повторы соединений на основе своих собственных настроек и от Вашего конфига тут ничего не зависит.
Интервал "жизни" записи в сером списке. Если в течение этого интервала сервер сделает повторную передачу, то адрес передающего сервера попадет в белый список.
Время на которое адрес отправителя будет включен в белый список, после удачного повтора. По умолчанию два месяца.
/etc/greylistd/whitelist-hosts
В этот список можно поместить адреса (или домены) заведомо неспам-серверов. Обычно заполнение данного конфига не требуется, однако имеет смысл сюда прописать IP-адреса Ваших резервных MX.
А теперь попробуем со всем этим взлететь
После того как конфиг-файлы были отредактированы (или просмотрены), нужно (пере)запустить сервер greylistd:
Теперь надо сделать так, чтобы наш почтовый сервер мог использовать greylistd, для этого запустим скрипт, идущий в составе пакета greylistd:
Данная команда установит в каталог /etc/exim4/conf.d два файла с acl-инструкциями. Теперь нужно дать знать exim-серверу, чтобы он перечитал конфиги:
Все система работает.
Работа
Для контроля состояния и работы демона есть утилита greylist. Демон ведет некоторую статистику, посмотреть которую можно командой greylist stats, например:
В приведенном примере мы видим статистику работы демона за последние 9 дней. Демон установлен на не особо нагруженном (домашнем) сервере, однако из статистики видно, что данный метод позволил отфильтровать более 99% спама. Более 27000 писем просто не дошли до spamassassin-а!
с помощью данной команды можно посмотреть содержимое белого и серого списков:
После длительного периода работы данные списки довольно объемны, поэтому для нахождения в них нужного адреса применяйте утилиту grep. Учтите, что команда greylist list выводит оба списка сразу, поэтому в сочетании с grep используйте опции --white или --grey:
Читайте также: