Вы системный-администратор компании и перед Вами стоит задача настроить почтовый сервер для компании так, чтобы спама было как можно меньше. Первым делом Вы идете на google и ищете способы решения проблемы спама. Гугл Вам вываливает кучу ссылок на статьи на различных сайтах. Вы переходите по ссылкам и начинаете читать. Готов спорить на что-то не очень ценное, что в первой же статье одним из решений будет использование DNS Blacklists. И Вы, зачарованный словосочетанием blacklist, в надежде на то, что коллективный разум постмастеров планеты уже знает обо всех спамерах, полагаете, что Вам остается только воспользоваться результатами их работы и тут же добавляете в конфиг своего MTA десяток-другой блеклистов. И, казалось бы, вот он счастье… но не тут-то было. Пользователи начинают регулярно жаловаться на недошедшие к ним письма. Вы, конечно же, первым делом спрашиваете от кого было письмо, затем смотрите в логи и гордо сообщаете пользователю: “Ваш отправитель попал в черный список, ничего поделать не могу, проблема на их стороне”. С Вас взятки гладки, поскольку это ведь не Вы, а отправитель попал в черный список, но тем не менее вопрос недоставки честных писем остается не решенным.

Перед тем как бездумно влепить себе в конфиг пару десятков блеклистов, предлагаю вместе подумать о том для чего нужны блеклисты и почему они были созданы.

Для этого обратимся к истории развития интернета. Когда-то давным давно почтовые серверы релеили письма от кого угодно и это никого не огорчало, даже mail.ru когда-то был открытым релеем. Затем появились спамеры, которые стали пользоваться открытыми релеями для рассылки спама. И началась эпоха борьбы с открытыми релеями. Конфигурационные файлы всех MTA стали по-умолчанию содержать опции, которые не позволяют МТА использовать как открытый релей. Внимательные постмастеры вовремя замечали огрехи в настройке своих серверов и исправляли их. Тем не менее проблему открытых релеев это не решило. Оставалось еще много нерадивых постмастеров, которые то ли не замечали ошибок в конфигурации, то ли не хотели исправлять, то ли не знали как. Нужен был инструмент, который заставит их шевелиться. Таким инструментом стал первый (поправьте, если ошибаюсь) блеклист – ordb.org. И результат был достигнут – он заставил нерадивых постмастеров шевелиться и исправлять ошибки в конфигурации своих серверов (а как же не шевелиться, если никто почту от тебя не принимает). ordb.org сделал свое дело – убрал из сети остававшиеся открытые релеи и 1.01.2007 почил с миром, прекратив свою работу.

Вместе с умиранием открытых релеев спамеры умирать не желали и от использования открытых релеев они перешли к использованию вредосного ПО. По заказу спамеров пишутся вирусы, которые распространяются по сети, заражают обычные домашние и офисные рабочие станции. В дальнейшем я буду называть зараженные компьютеры термином “зомби”. На сегодняшний день технология рассылки спама следующая: зомби связывается со своим хозяином, получает от него текст сообщения, список почтовых адресов и начинает рассылку сообщений по полученным адресам.

Теперь снова вернемся к тем временам, когда ordb.org был мощным инструментом в борьбе со спамом. Технология DNSBL приобрела такую популярность, что различных блеклистов появилось вагон и маленькая тележка. При переходе спамеров с открытых релеев на ботнеты блеклисты старались идти в ногу со временем. Они заносили в свои базы данных целые подсети, разделяя их по различным признакам. К примеру была попытка создать блеклист включающий в себя подсети провайдеров, которые предназначены для выделения домашним пользователям и малым офисам. Считалось, что такие пользователи не должны отправлять почту напрямую, а использовать релеи провайдера. По факту же эта задумка провалилась по двум причинам: во-первых невозможно отследить абсолютно все клиентские сети абсолютно всех провайдеров, во-вторых сейчас огромное множество малых офисов, подключенных на бюджетные тарифные планы и нельзя их обделять в желании использовать свой личный почтовый сервер, если сообщения от него идут “чистые”.

На сегодняшний день ситуация сложилась таким образом, что в блеклисты нередко попадают честные релеи. Это накладывает свои ограничения на использование блеклистов – их нельзя использовать по привычному ранее принципу: “Есть запись в блеклисте – сообщение однозначно отклоняется”. Блеклисты можно использовать только при взвешенной оценке всех факторов. Пример такой реализации можно наблюдать в фильтре Spamassassin: если отправитель присутствует в блеклисте, то сообщению начисляется N баллов, по результату всех тестов баллы суммируются и выносится общее решение о “спамности” письма. Т.е. в этом случае мы наблюдаем не однозначное отклонение сообщения на основания ответа блеклиста, а всего лишь некоторое увеличение ВЕРОЯТНОСТИ его спамности. На сегодня это единственный разумный подход к использованию блеклистов.

Ну вот раскритиковал блеклисты, а как же теперь со спамом бороться? Ведь хочется отсекать спам еще на стадии соединения, чтобы сэкономить ресурсы системы и не нагружать фильтр, тот же spamassassin, к примеру, лишними сообщениями. Об этом ниже.

Сообщения, пришедшие из ботнетов имеют одну или несколько перечисленных характерных особенностей:
1. У хоста-отправителя нет обратной DNS-записи.
2. Синтаксис представления HELO не верный.
3. В HELO хост-отправитель представляется не полным именем.
4. В HELO хост-отправитель представляется именем, для которого нет A записи.
5. Хост-отправитель не повторяет попытку доставки собщения в ответ на ошибку 4хх
6. Сообщение имеет в поле From несуществующий домен.
7. Сообщение имеет в поле From существующий домен, но несуществующий адрес.

Я не буду подробно расписывать что означает каждый из пунктов, а всего лишь приведу часть конфигурационного файла postfix со ссылкой в скобках на пункты характеристик. Скобки, естественно, нужно убрать перед использованием опций в своем конфиге.

unverified_recipient_reject_code=550
smtpd_helo_required = yes

smtpd_client_restrictions =
permit_mynetworks,
reject_unknown_client [1]

smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_hostname, [2]
reject_non_fqdn_hostname, [3]
reject_unknown_hostname [4]

smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain [6]

smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unauth_pipelining,
reject_unauth_destination,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:10023 [5]

По п.5. стоит сделать замечание, что использование данной особенности называется Greylisting. Более подробную информацию по Greylisting’у можно прочитать в википедии. В данном случае для грейлистинга рекомендуется пакет postgrey.

Этих опций вполне достаточно для того, чтобы число спам-писем у Вас уменьшилось с нескольких десятков до 1-2 в день. При условии использования дополнительных контент-фильтров (DSPAM или SpamAssassin) количество спама уменьшится до 1-2 писем в месяц.

P.S. Текст написан для начинающих постмастеров, чтобы предостеречь их от ошибок.


Дополнительные записи: