Уж сколько раз твердили миру... (с) Крылов И.А.Рассказ в этом топике пойдёт о мониторинге работы почтового сервера в одной торговой организации. И о занятных наблюдениях по поводу различных BL, сделанных в процессе этого мониторинга.
Итак: имеем небольшую торговую компанию, организующую также различные обучающие семинары. Имеем шлюз этой организации, работающий на Ubuntu и iptables. Имеем почтовый сервер внутри сети организации, настроенный абсолютно корректно и работающий без нареканий. На шлюзе заблокирован 25 порт всем, кроме почтового сервера. На почтовом сервере за всё время его работы не было замечено ни одной попытки несанкционированного доступа какой-либо программы или вируса. И всё равно организация попадает с завидной регулярностью в блоклисты.
Для начала поток ругани в адрес отдельных личностей, настраивающих почтовые сервера. Всякое бывает и кто-то действительно может начать рассылать спам из-за вируса или по недосмотру. Очень быстро этот кто-то поймёт, что у него есть проблемы, благодаря отбойкам о неотправленных письмах со стороны своего сервера. Хорошо, лезем в логи и видим там такое:
host emx.infobox.ru[92.243.91.50] said: 550 5.7.1
Recipient not authorized, your IP has been found on a block list (in reply
to RCPT TO command)И что мы понимаем из этого сообщения? Что почтовый администратор infobox.ru очень нехорошая личность (о которой очень хочется говорить матом). Блоклистов только популярных существует с десяток, и в какой мы интересно попали и что нам теперь делать? Это уже не просто дилетантство — это просто элементарная некомпетентность, руки за такое отрывать надо, увольнять уж точно.
Ладно, хорошо, обычно всё же серверы удосуживают себя сообщением о конкретном блоклисте. Например вот так:
host imx1.rambler.ru[81.19.66.235] said: 554 5.7.1 Client host [xx.xx.xx.xx] blocked using xbl.spamhaus.org; http://www.spamhaus.org/query/bl?ip=xx.xx.xx.xx (in reply to RCPT TO command)Лезем по ссылке, запрашиваем удаление, ждём сутки и радуемся нормальной работе почты.
Но сутки проблем с почтой вызывают вопросы, поэтому начинаем разбираться, кто виноват в том, что мы попали в блоклисты. В первую очередь смотрим на шлюз и убеждаемся, что напрямую через него никто не мог послать спам из локальной сети, поскольку 25 порт закрыт наглухо для всех. Хорошо, лезем на почтовый сервер и начинаем анализировать его логи. В результате анализа выявляем факты массовой рассылки писем с отдельных аккаунтов, которые судя по всем признакам и виноваты в попадание сервера в блоклисты.
Однако же постойте: это торговая организация, сотрудники которой с завидной регулярностью рассылают рекламную информацию своим клиентам, добровольно на это подписавшимся и желающим её получать. База клиентов собирается в оффлайне (на семинарах, выставках и т.д.), поэтому добрая четверть адресов в базе является некорректной, что видимо также способствует попаданию в блоклисты. Для рассылки используется как Thunderbird, так и специальные программки.
Запретить рассылку рекламной информации я не могу — это в конце концов серьёзная торговая организация, им что, по факсу рассылать клиентам предложения? Как либо технически улучшить ситуацию тоже — почтовый сервер настроен максимально корректно по всем мыслимым и немыслимым правилам. Пока у меня есть только одна идея — использовать сторонний сервис рассылок, но это жутко неудобно и неэффективно.
Мораль сей басни такова: да, блоклисты безусловно позволяют эффективно отфильтровывать спам одним лёгким движением руки (включением этих самых блоклистов на сервере). Вот только вместе со спамом вы неизбежно будете отсеивать важные письма, пришедшие от совершенно конкретных пользователей и ничего общего со спамом не имеющие. Вопрос ко всем системным администраторам, использующим блоклисты в своей практике: вы готовы подписаться под заявлением, что несёте полную ответственность за факты срыва важных заказов из-за того, что ваш сервер использует фильтрацию по блоклистам?
В качестве альтернативы я лично рекомендую рассмотреть грейлистинг. Хотя он и создаёт задержку принятия корреспонденции, однако из-за него ни одно письмо, корректно ушедшее от нормального отправителя, никогда не потеряется. Если ваши пользователи будут возмущаться задержке, можете поставить их перед фактом: либо риск полной потери важной корреспонденции, либо небольшая задержка, либо поток спама в ящики. Но при использовании грейлистинга вы, как системный администратор, можете с полной уверенностью списать все проблемы доставки на администратора серверов отправителя. Поскольку абсолютно в любом случае виноват в проблемах связи будет он. Есть и более щадящие механизмы фильтрации спама, как-то принятие решения исходя из совокупности нескольких критериев.
Напоследок я хочу ещё раз повторить: использование любых блоклистов на почтовом сервере для непосредственно блокировки спама — это дилетантство и признак непрофессионализма системного администратора. И ведёт это только к тому, что администратор однажды будет виноват в том, что было неполучено какое-нибудь очень важное письмо.
Про основные методы нормальной фильтрации спама с помощью почтового сервера Postfix можно почитать на ресурсе русскоязычной документации по Ubuntu.
P.S. Кстати, очень интересно наблюдать по логам, какие сервера используют блоклисты, а какие — нет. В целом однозначно видно, что блоклисты чаще всего используются на серверах сомнительных ненадёжных организаций, а чем серьёзней компания — тем меньше шанс нарваться на отказ в принятии письма из-за блоклистов.
