На прошлой неделе вызвал нас - меня и моих напарников - начальник и сказал, что опять его “заел” спам. Что же, это неудивительно: адрес, который он проверяет, открытым текстом (то есть ссылкой) указан на корпоративном сайте http://www.ism.kiev.ua - неудивительно, что спам-роботам не представляет трудностей его обнаружить. Мы обсудили различные способы, но они либо были слишком сложны для быстрой реализации, либо малоэффективны, либо наоборот - эффективны черезмерно - например, были случаи попадания в DNSBL серверов Академии Наук Беларуси. При этом мы заметили характерную особенность поступающего спама: он был направлен не на конкретный адрес, которых хотелось защитить, а на большие списки рассылки, причем многие адреса из этого списка либо давно не используются, либо вообще никогда не существовали. То есть спам-роботы использовали технологию поиска имени пользователя по словарю. И анализируя документацию по почтовому серверу sendmail, используемом на нашем корпоративном сервере, обнаружилась интересная фича: если в файле access  указать следующее правило типа:

To:vasili_pupkin    DISCARD

то если в адресатах встретится имя ящика vasili_pupkin , письмо будет удалено, без уведомления отправителя. То есть письмо не будет доставлено ни одному из списка рассылки, даже если все остальные адреса “живые”. Тем правило DISCARD отличается от правил типе REJECT - знающие формат файла access почтового агента (MTA) sendmail поймут, о чём идёт речь.  И родилась мысль использовать для борьбы со спамом технологию адресов-ловушек. Для этого потребовалось проанализировать файлы журналов sendmail, чтобы определить, какие адреса наиболее часто используют (точнее, имеют в своих словарях) спам-роботы и ввести соответствующие правила в файл access. При этом именя оказались довольно неожиданными, например, sara.774 (почему именно такие цифры, сказать сложно, но раз спамеры держат в своих словарях, пришлось их “уважить”) или dgamilya.isimbaeva. Со слов начальника, число спамовых писем уменьшилась раз 5, то есть такой способ весьма эффективен. Следует также отметить, что при применении средства DISCARD спамовое письмо уничтожается без уведомления получателя. В этом есть определённый минус: если добропорядочный корреспондент случайно отправит письмо на этот адрес, например, не расслышав диктуемый E-mail по телефону, то письмо ему не вернётся, и он будет думать, что его проигнорировали. Но на мой взгляд, такое достаточно маловероятно, ибо настолько похожих, чтобы можно было перепутать, адресов у нас нет. Зато есть и плюс: как правило, спамеры подставляют в качестве адресов отправителя совершенно “левые” адреса, то есть в “отлупы” получат либо совершенно посторонние люди, либо - особенно если поток этих “отлупов” будет достаточно велик, - сервер получателя это воспримет как атаку и может заблокировать по IP. Сам я с таким не сталкивался, но коллеги рассказывали, что такое возможно.

Предлагаемый способ не претендует на панацею. Но как один из многих, показал эффективность.

Мир всем!Долго искал решение одной проблемы. В своё время - это было где-то в 2007 -начале 2008 года, для борьбы со спамом подключил на сервере DNSBL. До недавнего времени всё было приемлемо - отвергалось примерно 80% спама, оставшийся можно было удалять вручную. Однако относительно недавно обнаружилось, что в этим DNSBL - возможно заслуженно, возможно случайно - стали попадать и "нормальные" почтовые серверы, в частности, НАН Украины. Кстати, в своё время НАН Украины даже прислала циркуляр, согласного к-рому переписка с Академией должна вестись только через собственный сервер Академии через Web-интерфейс, они для этого сделали нашему Институту там учетные записи. Впрочем, руководство, ведущее переписку, благополучно этот циркуляр проигнорировало. В общем, после анализа ситуации начальник дал мне категорической указание отключить на сервере фильтрацию спама с помощью DNSBL. Я и мои коллеги предлагали альтернативные решения- серые списки, белые списки, байесовские фильтры, однако все они были категорически отвергнуты. Со спамом решили бороться на уровне пользователя. Но у меня, как у системного администратора возникла новая проблема: появилось большое количество так называемых "двойных отлупов". То есть спамер шлёт спамовое письмо через какой-нибудь "левый" сервер, подставляя существующий обратный адрес, как правило на Mail.RU или Yandex.RU - если бы он подставлял явно несуществующий адрес, то мой сервер бы это письмо просто отвег бы: на нём стоит встречная проверка адреса отправителя. Но целевой адрес оказывается заблокирован. Возникает ситуация, описанная хотя бы здесь - http://forum.lissyara.su/viewtopic.php?f=20&t=35702&p=330623#p330623 . Такая ситуация называется двойной отлуп: письмо не может быть ни доставлено, ни возвращено отправителю - сервер адреса, подставленного спамером, отвергает это письмо с диагнозом service unavaible . По умолчанию sendmail - у меня используется этот МТА - такое письмо отправляет на ящик postmaster. Долго я искал по специализированным форумам решение этой проблемы, но к моему удивлению не нашел. А вот здесь - http://sysadmins.ru/topic55314.html - к сожалению, этот форум (пока) не работает, вообще утверждалось, что явного решения этой проблемы не существует, и предлагалось блокировать домены. Но как оказалось (нашел в старом руководстве по UNIX - читать старые книги новыми глазами иногда полезно), что решение есть и до смешного простое. Как впрочем, всё гениальное просто и очевидно.В файл mc добавить следующее:  define(`confDOUBLE_BOUNCE_ADDRESS', `double_bounce_p')dnl А в файл /etc/aliases   double_bounce_p: /dev/null пересобираем конфиги   make all  make install  newaliases  make restart --- эти двойные отлупы будут отправляться в "черную дыру". Понятно, что если есть желание в них колупаться, можно например, отправить их в другой ящик (файл), специально предназначенный для этого, Procmail задействовать. Например, некоторые почтовые сервера, нормальное уведомление о прочтении за спам принимают. Но то уже простор для творчества админа.Удивительно, почему об этом не было сказано ни в одном из найденных форумов. Может быть кому пригодится.