Ваш город: Москва
Знакомство с Linux: часть 24. Мусор - долой!
Вот именно "уплочено" и есть ключевое слово. Спамеры могут сколь угодно скрупулёзно изучать Конституцию и Федеральный Закон "О связи", чтобы ткнуть оппонентов в них носом - мол, свобода распространения информации, она для всех, и ничего криминального мы не делаем. Речь сейчас не о криминале, а о том, что для подавляющего большинства из нас Интернет - не халява. И за бесконечный поток никчёмных рекламных сообщений мы с вами выкладываем свои кровные денежки - неважно, платим при этом за время или за мегабайты. Не будем останавливаться на этической стороне вопроса; не станем обсуждать и то, как наиболее аккуратно "светить" свой электронный адрес в Интернете, дабы риск его попадания в спам-лист оказался минимальным. Рассмотрим более практическую задачу и решим её с максимальной эффективностью - в рамках излюбленной нами операционной системы. А это, спешу напомнить, в настоящий момент Linux в варианте Fedora Core 1.
Итак, дано: компьютер с полной установкой этой самой Fedora Core 1, плюс налаженное (через kppp, для определённости) модемное соединение, плюс один или несколько почтовых ящиков на внешних серверах. Требуется: оптимизировать способ получения и отправки почты таким образом, чтобы отсекать рекламную порошу с максимальной эффективностью. Каким будет решение?
Первым делом, разберёмся с тем, каким образом почта со внешнего сервера добирается до вас. В прежних выпусках серии я упоминал о графических клиентах Kmail и Evolution - для любого, кто хоть раз в жизни запускал Outlook Express, освоить эти программы никакого труда не составит. В частности, для настройки получения почты извне надо открыть управляющую панель выбранного клиента, прописать там адрес сервера и периодичность обращения к нему, а также извечную пару логин/пароль. Очень простой и надёжный путь: как только модемное соединение будет налажено и наступит время очередной проверки почты, клиент обратится ко внешнему серверу и закачает на ваш комптютер всю поступившую к этому времени корреспонденцию - разумеется, вместе со спамом.
Выходит, не годится такой способ. О да: теоретически, фильтрацию спама может осуществлять сам провайдер. Соответствующие программные инструменты для этого имеются. Но, во-первых, не все находят на установку фильтров время, и во-вторых - мало один раз поставить программу, нужно постоянно актуализировать её базы. Современный спамер - ушлый зверёк, на мякине его провести становится всё труднее; он постоянно изыскивает новые способы перелезть через возводимые стремящимися сохранить адекватность пользователями барьеры. Так что полностью полагаться на провайдера не стоит - даже если он и противопоставляет что-то рассыльщикам почтовой ерунды, плошать рядовому получателю писем никак нельзя.
И первый шаг на пути к выводу своей персональной почтовой службы из зоны поражения спамерами - отказ от традиций. А именно: от непосредственных обращений к POP3-серверам через клиентские программы вроде Kmail или Evolution, а также от применения стандартного для Fedora Core 1 (наследницы всей линейки Red Hat Linux) агента почтовой пересылки, Mail Transfer Agent (MTA) - программы sendmail. Что же с ним не так? Это ведь одна из священных коров мира *NIX/Linux, и до сих пор около 70% почтовых серверов по всему миру работают именно с ее использованием?
В этом-то и проблема. Вместе с долгой и славной историей применения пакет sendmail обладает не менее пространным списком выявленных в процессе эксплуатации багов. Помимо того, у sendmail имеется и такой серьезный недостаток, как достаточно сложные даже для бывалых линуксоидов правила формирования конфигурационного файла. И есть смысл хотя бы на домашнем компьютере отказаться от применения sendmail, препоручив его обязанности более свежей, компактной и простой в управлении программе. Претендентов на это звание немало, но остановисмся мы сейчас на пакете postfix, также входящем в состав дистрибутива Fedora Core 1 и разработанном при спонсорском участии IBM (с сохранением, однако, открытости исходного кода и свободы распространения).
Первым делом, активизируем работу postfix, отправив sendmail в запас. Сделать это несложно, если воспользоваться доставшимся по наследству от Red Hat Inc. инструментом - конфигуратором системных ресурсов. Достаточно открыть терминальную сессию root и выполнить команду
redhat-config-services
В появившемся графическом списке системных служб нужно выбрать sendmail. По умолчанию после установки Fedora Core 1 он активен - значит, стартует каждый раз при запуске системы, и в частности, действует в настоящий момент. Чтобы остановить его работу в текущем сеансе, досаточно использовать кнопку "Остановить" на верхней панели окна, а чтобы вовсе отменить запуск этой службы при новом старте системы - снять пометку с соответствующего чекбокса. Сохранив изменения, закроем окно. Теперь sendmail есть смысл вовсе удалить из системы посредством следующего набора команд (не забыв запустить терминальную сессию root):
mkdir /root/sendmail-old
cp /etc/aliases /root/sendmail-old/
cp -R /etc/mail/* /root/sendmail-old/
rpm -e sendmail sendmail-doc sendmail-cf --nodeps
Теперь надо удостовериться, что postfix в системе присутствует:
rpm -q postfix
Если нет - требуется отыскать его на одном из трёх инсталляционных дисков Fedora Core 1 и поставить (если в своё время была выбрана опция "Установить все пакеты", то, напомню, необходимости в этом не будет).
Запустить новый МТА на исполнение можно командой
postfix start
и кстати, в перечне системных служб (redhat-config-services), где строчка postfix теперь появилась, следует пометить чекбокс напротив неё. Вот теперь можно заняться настройкой.
Терминальную сессию root, открытую для удаления sendmail, не стоит торопиться прерывать: конфигурирование postfix производится путём правки файлов в каталоге /etc/postfix/, и прежде всего /etc/postfix/main.cf. Этот файл, хотя по размерам и великоват, содержит на деле не так много собственно управляющих строк - просто они обильно перемежаются подробными комментариями. Ещё больше информации имеется на страницах руководства man postfix и в каталоге /usr/share/doc/postfix-2.0.11/ (если текущая версия пакета именно 2.0.11, естественно). Особое внимание нужно обратить на подкаталог /usr/share/doc/postfix-2.0.11/samples/ - там находятся файлы с примерами конфигурационных параметров, которые по тем или иным причинам не были прямо включены в /etc/postfix/main.cf, и примеры эти нам совсем скоро пригодятся.
Как же нужно изменить конфигурационные файлы, чтобы заставить postfix работать? Прежде всего, в /etc/postfix/aliases следует внести самое важное изменение - назначить получателем системной почты root тот логин, под которым администратор компьютера обычно входит в систему. Дальше потребуется приняться за правку /etc/postfix/main.cf, чтобы исходящая почта отправлялась во внешний мир через внешний же почтовый сервер.
Для чего это нужно? Дело в том, что отправка письма напрямую подразумевает расшифровку адреса: по имени почтового сервера, стоящему в е-мейле после пресловутой "собачки", почтовая программа должна (запросив внешние сервера службы доменных имён) вычислить IP-адрес получателя и отослать письмо туда. Но такой подход не всегда удобен - каждый запрос на уточнение адреса может отнимать много времени, особенно если скорость соединения низка. Гораздо проще передоверить доставку специализированному серверу, точный адрес которого априори известен, - а этот мощный внешний сервер пусть уже сам разбирается с частностями.
Так и сделаем. Пусть отправляемые через postfix письма будут теперь уходить в Интернет не непосредственно с нашего компьютера, а через SMTP-транспорт - с внешнего почтового сервера. Этот метод отправки носит название релея, и задаётся он в /etc/postfix/main.cf так:
defer_transports = smtp
(понятно, зачем)
disable_dns_lookups = yes
(не будем тратить собственные силы на распознавание доменных имён)
relayhost = 80.68.244.50
(а это, собственно, сервер пересылки почты, будем знакомы!)
Откуда взялся IP-адрес почтового сервера? В данном случае он был получен как результат исполнения команды
resolveip smtp.hotbox.ru
Смысл указания именно IP-адреса, а не доменного имени - в экономии времени: преобразование DNS в этом случае каждый раз производить не придётся. Другой вариант - прописать IP-адрес почтового сервера в /etc/hosts.
Здесь возникает некая проблема: пересылка почты через внешние сервера - как раз излюбленное занятие спамеров, и все вменяемые владельцы таких серверов, в том числе и бесплатной почты, давно приняли меры против несанкционированного использования своих ресурсов. А именно: для отправки письма посредством внешнего сервера по протоколу SMTP надо пройти процедуру аутентификации, то есть указать свои логин и пароль. Как это сделать в случае postfix? Не слишком сложно. Подробности содержатся, например, в строках комментариев файла /usr/share/doc/postfix-2.0.11/samples/sample-smtp.cf. Необходимо добавить к /etc/postfix/main.cf следующие строки:
smtp_sasl_auth_enable = yes
(здесь, собственно, разрешается сам процесс аутентификации)
smtp_sasl_password_maps = hash:/etc/postfix/saslpass
(это указание на файл с волшебными парами логин-пароль для каждого из внешних севреров)
smtp_sasl_security_options =
(да, именно так: конец строки сразу после знака равенства. Эта опция может быть и иной: по умолчанию в файле примера приводится строка
smtp_sasl_security_options = noplaintext
то есть запрещается отправка на внешний сервер пароля в виде простого текста. Однако для данного конкретного сервера, рассматриваемого мной в качестве примера, этот метод не сработал, - пришлось использовать менее устойчивый ко взлому, но более распространённый способ).
Формат хеш-таблицы /etc/postfix/saslpass элементарен:
80.68.244.50 dummy@pochta.ru:jlhku4576frfqwyh
Здесь сперва указывается идентификатор сервера в том виде, в которм он приводился в строке relayhost основного конфигурационного файла postfix, а потом - пара логин-пароль через двоеточие. Важно обращать внимание на то, в каком именно виде требует каждый конкретный сервер указания этой самой пары. Где-то в качестве логина понадобится только учётное имя пользователя, где-то - полный адрес...
Ну и последний (в том, что касается отправки почты) штрих. Как быть, если ваш провайдер располагается в одном домене, а почтовый сервер - в другом? Ведь обратный адрес письма будет в этом случае совершенно не тем, каким вам (и вашему получателю) хотелось бы его видеть. На этот случай предусмотерна процедура задания “канонического отправителя”. Потребуется, во-первых, завести (или подредактировать, если он уже есть) текстовый файл /etc/postfix/sender_canonical. В нём должна появиться строка, в которой сначала будет указан локальный идентификатор отправителя (его учётная запись на данном компьютере), а затем, через пробел или символ табуляции, - желаемый внешний почтовый адрес:
maxim dummy@pochta.ru
Затем содержимое /etc/postfix/sender_canonical нужно преобразовать в доступный для использования программой вид. Осталось прописать упоминание об этой подмене адреса в /etc/postfix/main.cf:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
после чего активировать её и перезапустить postfix:
postmap /etc/postfix/sender_canonical
postfix reload
Вот теперь с параметрами отправки почты все в порядке. Последнее, что здесь следует сделать, - это позаботиться о своевременности отправки. Всякий раз, когда мы будем теперь создавать письмо и (в том же, допустим, Evolution), при отдаче команды “отправить” оно встанет в очередь postfix. Можно инициировать отправку вручную - командой
postfix flush
(кстати, команда mailq позволит увидеть, есть ли на данный момент в принципе письма в очереди на отправку). А чтобы почтовая очередь передавалась внешнему серверу сразу же после установки модемного соединения, добавьте к соответствующему скрипту команду
/usr/sbin/sendmail -q
Теперь, пожелав написать письмо, спокойно создавайте его в наиболее удобном редакторе, текстовом или графическом, отправляйте в очередь, затем налаживайте соединение с провайдером - и оно сразу же, как только установится связь, уйдёт во внешний мир. Быстро и гарантированно.
Наша же следующая задача - научиться получать почту извне. И делать мы это будем с применением fetchmail, простой и действенной утилиты. Со страниц руководства man fetchmail любопытствующие смогут получить массу ценной информации – ведь если, как мы и рекомендовали при инсталляции Fedora Core 1, вы выбрали установку всех пакетов, fetchmail уже присутствует в системе. Управляющим файлом для этой программы в домашнем каталоге каждого из пользователей служит .fetchmailrc (обратите внимание, имя файла начинается с точки!). Создать его можно в простейшем текстовом редакторе вроде vi, и выглядеть он должен хотя бы вот так:
poll imap.pochta.ru with proto POP3
user “dummy” there with password “jh34uyGyghg” is maxim here
Сохранив файл, установите необходимые права доступа к нему:
chmod 600 .fetchmailrc
Где создавать этот файл? Можно - в домашнем каталоге каждого польователя системы, чтобы тот потом от своего имени мог выполнять по мере надобности команду fetchmail для доставки своей почты.
Но лучше всё-таки доверить эту процедуру суперпользователю - разместив, соответственно, .fetchmailrc в каталоге /root. А вызов команды fetchmail прописать, в свою очередь, в перечне вызываемых сразу после налаживания ppp-соединения программ - скажем, среди параметров команды kppp. Тогда при старте kppp, требующей введения пароля root'а, "подхват" команды fetchmail осуществится естественным образом - с теми параметрами, которые как раз прописаны в /root/.fetchmailrc.
Свежие письма, принятые с сервера, добавятся к стандартному почтовому спулу (в примере с локальным пользователем maxim - /var/spool/mail/maxim). Забрать их оттуда позволит любой почтовый клиент - хоть элементарнейший текстовый mail, хоть Kmail или Evolution. Вот только фильтрации почты при этом осуществляться не будет, - фильтров-то никаких не задано. Пока не задано.
Первым делом, имеет всё-таки смысл обратить внимание на провайдерские системы блокировки спама - если они есть. Сейчас наиболее популярным средством убить спамера становится Spamassasin (useast.spamassassin.org/index.html) - достаточно мощный "интеллектуальный" рекламный фильтр. Интеллектуальность его заключается в том, что он анализирует пришедшее на почтовый сервер письмо по целому ряду параметров, присваивая каждому из критериев оценки свой весовой коэффициент и в итоге вынося вердикт: считать данное письмо спамом или нет. Этот вердикт записывается в заголовок письма, которое затем направляется во входящий почтовый спул пользователя - и дальше уже его, пользователя, дело решать, действительно ли это спам. Подробный отчёт о работе фильтра приводится в заголовке письма. Если включить опцию показа исходного текста, то собщение с темой
[***SPAM*** Score/Req: 05.80/05.00] !
будет содержать такой примерно анализ с указанием проведённых тестов и результатов по ним:
X-Spam-Status: Yes, hits=5.8 required=5.0
tests=HTML_20_30,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_TIME version=2.55
X-Spam-Level: *****
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
X-Spam-Report:
---- Start SpamAssassin results 5.80 points, 5 required; *
0.1 -- BODY: HTML included in message *
1.2 -- BODY: Message is 20% to 30% HTML *
4.4 -- Message-Id is fake (in Outlook Express format) *
0.1 -- Message only has text/html MIME parts
---- End of SpamAssassin results
X-Spam-Flag: YES
Как видно, содержащее HTML письмо с поддельным идентификатором сообщения (Message-Id) однозначно является спамом. Spamassasin на сервере провайдера, принимая для вас почту, проверит каждое сообщение, и изменит заголовки особо подозрительных так, чтобы они сразу бросились в глаза. А уж мы эти письма сумеем отфильтровать. Как? А вот небольшой пример файла .fetchmailrc, как раз и реализующего фильтрацию:
# Будем записывать лог соединения в /var/log/maillog:
set syslog
# Общие для всех серверов настройки:
defaults protocol pop3,
mda "procmail"
# Первый сервер:
poll
imap.pochta.ru
user "dummy" there with password "LdfGfljyrf" is maxim here
# Второй сервер:
poll
mail.inbox.ru
user "dummy" there with password "ljher33tsdjy" is maxim here
Все настройки для подготовленного читателя более или менее очевидны, за исключением некоего mda "procmail". А это ни что иное, как использование в качестве Message Delivery Agent, агента непосредственной доставки почты пользователю, службы procmail - замечательного средства для обработки писем. Procmail входит в состав практически каждого дистрибутива *NIX/Linux. Управлять его работой procmail можно точно так же, как и fetchmail - посредством размещаемого в домашнем каталоге (в данном случае) root файла .procmailrc. О деталях его синтаксиса вам, как водится, поведают man procmail и man procmailrc, а живой и достаточно эффективный пример этого файла - чтобы не затягивать переход поближе к делу - приведу здесь:
MAILDIR=/var/spool/mail
DEFAULT=$MAILDIR/maxim
LOGFILE=/var/log/maillog
SPAMFILE=$MAILDIR/spam
MYEMAIL=(dummy@pochta.ru|abstinent@inbox.ru)
SPAMWORDS=(SPAM|viagra|penis)
# 1. Письма не для меня -в корзину:
:0:
* $!^(Resent-)?(To|Cc|Bcc).*$MYEMAIL
$SPAMFILE
# 2. Письма с заголовками, где есть много $$$$s или !!!! - в корзину:
:0:
* ^Subject.*(\$\$\$|!!!!)
$SPAMFILE
# 3. Письма без темы – в корзину:
:0:
* !$^Subject
$SPAMFILE
# 4. Письма с нелюбопытными для меня заголовками – в корзину:
:0:
* $^Subject.*$SPAMWORDS
$SPAMFILE
# 5. Письма, направляемые во множество адресов сразу, - в корзину:
:0:
* ^TO.*@.*,$?.*@.*,$?.*@.*,$?.*@.*,$?.*@.*,$?.*@.*,$?.*@.*
$SPAMFILE
# 6. Письма без Message Id или с неверным Id – в корзину:
:0:
* !^Message-Id.*<[^@ ]+@[^@ ]+>
$SPAMFILE
# 7. Никакого html. Мои соболезнования:
:0:
* ^Content-Type:.*html
$SPAMFILE
Коротко о главном. Изначально параметром MAILDIR задаётся местоположение почтового каталога, DEFAULT указывает на основного получателя почты, SPAMFILE - это хранилище почты, помечаемой как спам. Важно: в почтовый ящик пользоватеоля maxim сообщения из спула SPAMFILE никак не попадут - поэтому время от времени в "отстойник" имеет смысл заглядывать на предмет обнаружения случайно попавших туда значимых писем. Либо - без зазрения совести уничтожать: тогда проще сразу поставить в начало файла
SPAMFILE=/dev/null
Далее. MYEMAIL - важный параметр: это перечень тех адресов, НА которые вы ожидаете приёма почты. То есть ваших собственных. Спамеры часто отправляют письма таким образом, что поле "Кому:" остаётся пустым, либо заполняется каким-нибудь мусором. Так вот, первое же правило просто запрещает приём писем, в поле "Кому:" или "Копия:" которых отсутствует хотя бы один из перечисленных в MYEMAIL адресов.
Параметр SPAMWORDS фигурирует в правиле 4. Многие спамерские письма в своих заголовках содержат такие слова, которые ваши корреспонденты в здравом уме вряд ли будут в своей переписке использовать. Расширять этот список можно и далее - насколько достанет фантазии и опыта.
Правила 2 и 3 также имеют дело с заголовками. Наверняка вы не раз получали сообщения с темами вроде "$$$$$$ MEGABUCKS FOR FREE !!!!!!!!!!!!!!!" Опять-таки, ясно, что нормальный человек столько символов доллара и восклицательных знаков в теме использовать не станет. Кстати, строенный восклицательный знак вполне допустим, так что настройках правила 2 фигурируют, обратите внимание, четыре таких знака как показатель никчёмности письма. А третье правило фильтрует письма, в которых заголовок попросту отсутствует - тоже фирменный спамерский знак. Правда, частенько и полноценные живые пользователи могут отправлять письма без заголовков - но своих-то можно и предупредить.
Пятое правило позволяет считать спамом письма, у которых в поле "Кому:" прописано сразу несколько почтовых адресов (то есть много "собачек" - именно по ним ведётся фильтрация). Шестое апеллирует к Message Id - уникальному идентификатору, которое каждое письмо получает при формировании. По правилам, он должен выглядеть приблизительно так:
Message-Id: <40683C93.000004.08217@colgate.yandex.ru>
То есть в подлинном письме содержится точный Интернет-адрес компьютера, с которого оно было отправлено. Зачем это спамерам? А наличия Message-Id многие почтовые релеи настоятельно требуют. И тогда ушлые рекламщики подделывают его, особо не заботясь о корректном воспроизведении полей. В корзину такие письма!
И наконец, седьмое правило может не прийтись по душе любителям html-отправлений. Однако мой личный подход к вопросу таков: письмо - это информация, то есть текст (либо картинка, но о них разговор отдельный). Текст вполне функционально доносит заключённую нём информацию без HTML-изысков, уж не говоря о том, что теги и красивости в оформлении добавляют письму дополнительный "вес". А спамерское письмо, поскольку содержит рекламную информацию, в громадном большинстве случаев создаётся именно с применением броских HTML-приёмов. Потому всё, что мои корреспонденты желают мне сказать, они говорят простым открытым текстом - а HTML отправляется в корзину.
Собственно, на данном этапе - всё. Разумеется, немало спама будет прорываться через приведённый здесь достаточно примитивный фильтр. Но... я не зря ограничился самой примитивной конструкцией фильтра. Дело в том, что существует немало развитых проектов, (вроде SpamBouncer.org), нацеленных именно на построение максимально непробиваемой системы отсева сорной рекламной почты. Вот вдумчивому знакомству с подобными мощными инструментами мы и посвятим следующую статью цикла: всем необходимым инструментарием мы теперь владеем.
© 1998-2023 fcenter.ru | Россия
© 1998-2023 fcenter.ru | Россия
