Настройка почтовой системы в Linux

В Unix почтовая система тесно интегрирована с самой операционной системой. И если она не настроена, это аналогично езде на машине со спущенной шиной. Все нормально до тех пор, пока вы едете со скоростью до 10 км/ч. Как только вы превысите этот барьер, проблемы начнут возникать как грибы под дождем. Работающая почтовая система, как и сетевое подключение, является основной предпосылкой любой Unix-подобной операционной системы. Что я хотел бы показать в этой статье, так это пример работающей почтовой системы, которую можно скорректировать и адаптировать к вашим потребностям. Важным моментом является знание компонент, необходимых для работы системы в целом.

Фрагменты, образующие целое

Почтовая система состоит из трех нежестко определенных частей: MUA (Mail User Agent, пользовательский почтовый агент) - программное обеспечение для чтения и составления почты, MTA (Mail Transfer Agent, агент передачи почты) - обычно SMTP сервер, хотя это могут быть и другие программы, и программа получения почты (некоторые SMTP сервера включают в себя функциональность POP сервера, но, как правило, это отдельный сервер). Пользовательский почтовый агент может представлять собой практически все что угодно: это просто фронт-энд. То есть вы можете пользоваться тем, что вам по душе, если остальные две составляющие корректно работают. Вы можете использовать даже Netscape, если он вам нравится! В качестве оставшихся двух компонент, я буду использовать Exim, широко известный агент передачи почты, и "fetchmail" Эрика Раймонда (Eric S. Raymond), вероятно самая широко распространенная в мире утилита получения почты.

Настройка программного обеспечения

Настройка утилиты "fetchmail" не представляет особо сложной задачи. Все, что необходимо - это создать в вашем домашнем каталоге файл ".fetchmailrc" и указать в нем параметры вашего POP-соединения. В качестве примера привожу листинг моего файла:

# Я хочу протоколировать все сессии получения почты в файл "/var/log/mail.*"
set syslog

# Общие настройки
defaults protocol pop3, timeout 300, nokeep, fetchall, mda "procmail -f-"

# Получение почты от моего провайдера
poll "pop.happybruin.com", user "fuzzybear" password "а_вы_хотите_его_узнать?";

# Получение почты другой моей учетной записи
poll "pop3.bearsden.com", user "ben-fuzzybear", password "тсс_это_секрет";

Давайте быстро пройдемся по этому файлу - все очень хорошо описано в странице руководства "fetchmail". Я получаю почту двух разных учетных записей. Поскольку у меня несколько чудное соединение (беспроводной модем), я настроил "fetchmail" обрывать соединения по тайм-ауту через 5 минут (300 секунд). Я также указал удалять почту на сервере после получения ("nokeep"), игнорировать флаг "прочтено" и получать всю имеющуюся почту ("fetchall"), использовать программу "procmail" для кое-какой нужной мне обработки заголовков ("mda ..."). Последнее не обязательно нужно всем, просто некоторые некорректные SMTP-сервера "забывают" включить так называемый заголовок "Envelope-from", а данный параметр это исправляет. Все остальное, как мне кажется, достаточно очевидно.

Существуют два основных пути выполнения fetchmail. Он может запускаться как один из инициализационных скриптов (этот метод удобен при постоянном соединении), или из скрипта "/etc/ppp/ip-up.d" (как правило, используется при коммутируемых соединениях). Обычно, вам нужно выбрать метод при настройке "fetchmail". Кроме этого, каждый пользователь может запускать его вручную, для одноразового получения почты (просто введя в командной строке "fetchmail") или как демона для опроса почтового ящика через определенный промежуток времени (я обычно так и делаю, командой "fetchmail -d 600" которая опрашивает сервер с 10-ти минутным интервалом. Такая настройка может быть задана в файле ".fetchmailrc").

"fetchmail" намного более гибкий и мощный, нежели показано в приведенном примере. Достаточно сказать, что он может выполнять практически любое получение почты любым доступным почтовым протоколом. Конечно, если у вас есть свой любимый агент получения почты, это тоже хорошо.

Взгляд на большую картину

Настройка вашего SMTP-сервера не обязательно должна быть значительно сложнее приведенной выше - но она определенно должна быть намного более продуманной. Главным вопросом, на который нужно будет дать ответ, это где ваше место в сети? Для тех, кто никогда не задумывался о себе в таком масштабе, это еще один фрагмент мозаики: в действительности большая часть Сети состоит из маленьких кусочков - таких, как компьютер, за которым вы сейчас сидите. Ваш провайдер - это еще один узел Сети. Правда вы подключены с помощью их маршрутизаторов, но однажды подключившись, вы становитесь такой же частью Сети, как и ваш провайдер, следовательно становитесь ответственными за то, чтобы ваш маленький кусочек работал в гармонии с остальной частью Сети.

(Один из RFC по безопасности, который я недавно читал, не помню точно который, утверждает, что, вероятно, более 50% почтовых серверов подсоединенных к Сети, в той или иной степени неверно настроены. Весьма пугающая статистика... однако, весьма показательна надежность и гибкость почтовой системы в целом. Все это говорит о необходимости всем нам способствовать Светлой Стороне Силы, делая свое дело.).

У многих из нас ситуация предельно проста: рабочая станция, один провайдер и нет необходимости в своем SMTP-сервере. По крайней мере, не более чем передавать всю нашу почту SMTP-серверу провайдера. В этой ситуации подойдет любой агент передачи почты, поскольку почти ничего не требуется настраивать, кроме перезаписи адреса. Просто ответьте на вопросы при настройке, и - "ву а ля", вы готовы к работе. Однако, эта часть системы немного более "щекотливая" и когда приходит время изменений (использование нескольких провайдеров, и вообще, что-то отличающееся от стандартных случаев) приходится немного повозится с конфигурацией... вот тут народ начинает ругаться на почтовые системы.

 Конфигурационный файл "sendmail" выглядит так, словно кто-то долго прикладывался головой к клавиатуре. После того, как я его увидел, я понял почему! - Аноним

Многих системных администраторов выносили привязанными к носилкам и с пеной у рта после изучения файла "sendmail.cf". Уродливое творение... да и конфигурационный файл, с помощью которого он создается, выглядит не лучше. В 58-м выпуске (Configuring Sendmail in RedHat 6.2, or My Adventure in the Heart of the Jungle) я детально рассматривал его работу; сейчас мой нервный тик почти прошел, а доктор говорит, что таблетки можно будет перестать принимать всего через год, или около того...

Серьезно, это важный момент. Если ваше сетевое соединение будет меняться (провайдер, имя хоста, с коммутируемого на выделенный канал) более одного-двух раз, вам стоит задуматься о своем SMTP-сервере. Например, я пользуюсь своим, так как мне приходится много путешествовать и работать с большим количеством провайдеров (по коммутируемым и беспроводным каналам, кабельным модемам в отелях и т.п.) при самых различных конфигурациях. Этот вариант позволяет не волноваться о чужих настройках и настройках при миграции с одной системы на другую - масса удобств. Другими словами, настройка своего почтового сервера не просто очередная задача, а важное решение, которое должно быть основано на ваших потребностях. Я считаю, что подход "сделай-сам" более гибок, намного мощней и беспроблемней во всех случаях, когда окружение не статическое.

Настройка SMTP

Итак, к этому моменту мы определили две типичных SMTP-конфигурации:

1) Делегировать все, кроме переписи адреса (это нужно делать локально). SMTP-сервер провайдера (для нас это, так называемый, "smarthost") выполнит всю работу по доставке. Это хороший вариант, если у вас статическое окружение, которое не должно меняться, особенно если это крупный и надежный провайдер (ну, можем же мы помечтать?).

2) Делать всё самим. Этот вариант имеет массу преимуществ, включая обход ненадежных почтовых сервисов провайдера и возможность видеть, дошла ли почта до адресата (несколько лет назад, мой провайдер задерживал некоторую почту больше недели, после чего уничтожал её без извещений. Тогда-то я и начал использовать свой почтовый сервер...)

В общем, это решение делается при установке агента передачи почты (Mail Transfer Agent). Все очень просто: в случае с Exim вам дается пять вариантов, из которых лишь два представляют наш выбор (программа "eximconfig" запускается при установке, после чего может быть запущена в любое время):

You must choose one of the options below:
 (1) Internet site; mail is sent and received directly using SMTP. If your needs don't fit neatly into any category, you probably want to start with this one and then edit the config file by hand.
 (2) Internet site using smarthost: You receive Internet mail on this machine, either directly by SMTP or by running a utility such as fetchmail. Outgoing mail is sent using a smarthost. optionally with addresses rewritten. This is probably what you want for a dialup system. ...

Обратите внимание, что эти два варианта соответствуют нашему выбору так: "делать всё самим" соответствует варианту (1), а "smarthost" - варианту (2). После этого, "eximconfig" задаст еще несколько вопросов, один из которых выглядит так:

 ...

Which user account(s) should system administrator mail go to?
Enter one or more usernames separated by spaces or commas. Enter
`none' if you want to leave this mail in `root's mailbox - NB this
is strongly discouraged. Also, note that usernames should be lowercase!

Поскольку вы тот, кто настраивает систему, я полагаю, что вы будете ее и администрировать. Потому вам следует указать имя своей учетной записи. Если же вы пошли путем выбора "smarthost", вас спросят имя smarthost; аккуратно введите имя SMTP-сервера своего провайдера.

Чрево зверя

После всего этого, мы переходим к следующему пункту, общему для обоих путей: перезапись адреса. Сейчас ваш почтовый адрес будет выглядеть для системы, как "имя_пользователя@хост" и если у вас нет собственного домена, это не будет корректным Internet-адресом. К счастью, исправить это при помощи Exim не сложно.

Сперва нужно открыть в редакторе файл "/etc/exim/exim.conf" и добавить следующий фрагмент кода в шестую секцию ("REWRITE CONFIGURATION"):

*@localhost ${lookup{$1}lsearch{/etc/email-addresses}\ {$value}fail} Ffsr

Эта строка указывает Exim просматривать файл с правилами перезаписи адресов и заменять адреса соответствующим образом. В некоторых случаях, файл "exim.conf" может уже содержать аналогичные строки; в этом случае просто убедитесь, что они полностью соответствуют вышеприведенной строке, в частности указаны флаги "Ffsr" (которые указывают на необходимость перезаписи заголовков "Envelope-from", "From:", "Sender:" и "Reply-to:"). После этого перейдем к файлу (сюрприз!) "/etc/email-addresses" и добавим в него записи для всех наших пользователей.

# Почта пользователя Root не должна предназначаться 
# никому за пределами данной машины, но на всякий случай...
root: happybear@bruins.com
ben: happybear@bruins.com
rivka: sweetie@here.com
linda: babe@westcoast.org
jen: saucy@wench.net

Ну вот. В отличии от "sendmail" никаких баз перестраивать не нужно, а файл подчитывается "на лету". Одна из причин, почему мне нравиться Exim, это его конфигурационный файл, обильно снабженный комментариями. Кроме того, имеется файл "/usr/share/doc/exim/spec.txt.gz" с полным (и очень большим) руководством по всем параметрам конфигурации.

Разные подходы

Если вы движетесь по пути "smarthost", то к этому моменту у вас уже все настроено. Переходите к разделу "Тестирование". Если же вы любите "делать-все-сами", как я, то есть еще одно маленькое дополнение к конфигурации Exim. Поскольку теперь мы ответственны за доставку письма по назначению, то мы должны обрабатывать ситуации, когда доставка невозможна (например, хост получателя выключен, не работает промежуточный маршрутизатор, у нас пропало сетевое подключение и т.п.). Большинство реакций на такие ситуации уже хорошо определены по умолчанию. Но я нашел один параметр, позволяющий уменьшить количество "проблемных сообщений" от Exim (которые он будет присылать вам, как администратору) практически до нуля: в первой секции файла "/etc/exim/exim.conf" укажите строку:

auto_thaw = 5m

Каждый раз, когда письмо помечается как "замороженное" (недоставленное), Exim будет "размораживать" его (производить повторную доставку) через пять минут. Поскольку большинство сбоев временные, эта установка позволит нам "продавливать" почту практически все время, пока имя пользователя и домен указаны верно.

Ах, да! Поскольку вы теперь Главный Почтовый Администратор... :-) то вам теперь придется выполнять некоторые административные обязанности. Вообще-то , их не так много. Решать, что делать с проблемными сообщениями (если Exim оповещает вас, что что-то застряло в очереди, выполните команду "mailq", чтобы посмотреть, что это; потом взгляните на протокол этого сообщения командой "exim -Mvl "), добавлять новых пользователей в файл "/etc/email-addresses" и отвечать на сообщения о проблемах и спаме других пользователей. Прочтите страницу руководства "exim", чтобы познакомится поближе с этим зверем. Этого совсем достаточно. Опытных почтовых администраторов больших систем может бросить в ужас от моих слов, но для одной машины или маленькой локальной сети этого вполне достаточно. Правильно настроенная почтовая система являет собой в значительной степени беспроблемное и само-регулирующееся создание.

Тестирование

Exim имеет набор встроенных режимов тестирования, один из которых очень удобен. Главное, что нужно нам проверить - это работают ли наши правила перезаписи адресов. Это просто:

Baldur:~$ exim -brw ben sender: happybear@bruins.com from: happybear@bruins.com to: ben@localhost cc: ben@localhost bcc: ben@localhost
reply-to: happybear@bruins.com
env-from: happybear@bruins.com env-to: ben@localhost

Проверьте отправку сообщений просто с такими именами отправителя, как "имя_пользователя@localhost" и "имя_пользователя@ваш_хост"; все эти адреса должны быть правильно перезаписаны. Кроме того, проверьте работу почтовой системы при отправке сообщения с произвольным корректным Internet-адресом с тем, чтобы убедится, что он не меняется.

Если все работает правильно, значит ваша почтовая система, как минимум, сконфигурирована приемлемо (ребята, которые разрабатывают дистрибутивы, проделали неплохую работу по базовым настройкам). Чтобы проверить её, пошлите себе почту и посмотрите на заголовки. "From:" и "Reply-to:" (если он задан) должны соответствовать вашему правильному сетевому адресу, а не просто имени пользователя данной системы. Ниже приведен пример (почтовые/IP адреса здесь, как и в остальной части статьи изменены, чтобы помешать спамботам. Ешьте несуществующие адреса, спамерские слизняки):
В меню создания сообщения клиента Mutt, вы можете видеть следующее:

 From: "Benjamin A. Okopnik"  To: Benjamin Okopnik  Cc: Bcc: Subject: Rewrite test
Reply-To: Fcc: =Sentmail Mix:  PGP: Clear

Обратите внимание, что на локальном клиенте поле "From:" содержит локальный адрес. Кроме того, сейчас, когда у вас есть настоящая почтовая система, вы можете просто указать в командной строке:

mail -s "Rewrite test" happybear@bruins.com

Теперь любым способом посылаем почту, а когда она вернется:

Date: Tue, 30 Apr 2002 03:47:19 -0400
From: "Benjamin A. Okopnik" 
To: Benjamin Okopnik 
Subject: Rewrite test

WARNING: Deep Magic in progress.

Ben Okopnik
-=-=-=-=-=-

Если посмотреть на заголовки (в Mutt, нажмите клавишу "h"), мы увидим следующее:

(Горячая клавиша "h" сработатет в режиме "индекса". Прим.ред.)

From ben Tue Apr 30 03:48:15 2002
Return-Path: 
Received: from Baldur (pzw-199-999-99-999.sunbridge.com [199.999.99.999])) by bruins.com (9.10.3/9.10.3) with ESMTP id g3U7lR45008674 for  Tue, 30 Apr 2002 00:47:32 -0700 (PDT)
Received: from ben by Baldur with local (Exim 3.35 #1 (Debian)) id 172SM7-0004nd-00 for  Tue, 30 Apr 2002 03:47:23 -0400
Date: Tue, 30 Apr 2002 03:47:19 -0400
From: "Benjamin A. Okopnik" 
To: Benjamin Okopnik 
Subject: Rewrite test
Message-ID: <20020430074718.GA18398@Baldur>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Status: U 
X-UIDL: 27862

WARNING: Deep Magic in progress.

Ben Okopnik
-=-=-=-=-=

Читаем маршрутную информацию снизу вверх: Exim получил почту от меня, переписал заголовок и передал bruins.com. Значит, все было сделано правильно - все что говорит мой агент передачи почты правильно понимают другие. Если бы почта исчезла, я бы посмотрел, что случилось с сообщением в файле "/var/log/exim/mainlog" и, возможно, заглянул бы в очередь: не застряло ли оно? Однако, похоже, что вся наша магия удалась и все работает.

Заключение

Если вы проследовали со мной и все сделали до этих строк... принимайте поздравления. Вы теперь активный сетянин, один из тех, кто использовал немного своего времени и сил, чтобы Сеть работала немного лучше. И я рад, что делю IP-пространство с такими, как вы.

Всего хорошего и счастливого линуксирования!

Об авторе

Бен - редактор Linux Gazette и член группы ответов (The Answer Gang).

Бен родился в Москве, Россия в 1962. Электроникой он заинтересовался в возрасте шести лет - и сразу продемонстрировал это, вставив вилку в розетку; в результате начался пожар. С тех пор он погряз в рудниках технологий. Он работает с компьютерами, начиная c тех времен, когда нужно было спаивать их на монтажных платах, а программы должны были помещаться в 4Кб памяти. Бен с радостью заплатит хорошие деньги психологу, который сможет избавить его от проистекающих с тех пор ночных кошмаров.

В результате опыт работы Бена включает создание программ на дюжине языков, поддержка сетей и баз данных во время ураганов и написание статей для публикации начиная от морских и заканчивая высокотехнологичными журналами. Завершив недавно семилетний Атлантико-Карибский круиз под парусом, Бен бросил якорь в Балтиморе, Мэриленд, где сейчас и работает в качестве технического инструктора для Sun Microsystems.

Бен работает с Linux начиная с 1997, и связывает это с полной потерей интереса к ведению атомной войны в северо-западных областях Тихого океана.

Copyright (c) 2003, Ben Okopnik.