Когда начинающие системные администраторы сталкиваются с необходимостью настройки почтового сервера, они могут испытывать затруднения связанные с пониманием основных принципов работы почтового механизма. Чтобы внести ясность, я подготовил эту статью, основанную на освещении тех моментов, которые были мне в свое время непонятны. Статья подойдет также разработчикам ПО, которым надо быстро поднять почтовый сервер и протестировать свое приложение.
Итак, прежде, чем бросаться настраивать почтовый сервер, необходимо понять, как в принципе работает почта.
Буквально на пальцах рассмотрим пример. Пусть у нас есть внешний статический ip — 195.195.122.129 и собственный почтовый сервер, зарегистрировано доменное имя example.ru. Когда кто-то посылает почту на почтовый адрес, например, thedude@example.ru, то, рано или поздно, запрос относительно того, на какой же ip отправлять почту человеку с адресом на домене example.ru (то есть dns-запрос), дойдет до dns-сервера, где хранятся mx-записи с реквизитами example.ru, то есть говоря еще проще — этот dns-сервер отвечает в соответствии с этой записью, что почту, идущую на example.ru, нужно перенаправлять на 195.195.122.129. А когда письмо приходит на наш сервер мы уже его обрабатываем сами. Обрабатывать пришедшее письмо мы будем с помощью Message Transport Agent (далее MTA). Под MTA мы будем понимать программу, которая может:
1. Пересылать письма от пользовательского почтового клиента (Mail User Agent, далее MUA), к удаленному почтовому серверу. MTA пересылает письма, используя протокол SMTP (Simple Mail Transfer Protocol). Примерами MUA служить Mozilla Thunderbird, MS Outlook и др.
2. Доставлять письма в локальные почтовые ящики (заметьте, что здесь имеются ввиду ящики на сервере, а не на локальных компьютерах пользователей).
3. Пересылать письма другим MTA.
В данной статье мы будем рассматривать MTA Postfix. Он прост в конфигурировании, что позволит сосредоточиться на содержании, а не на форме. Приведем ниже основные параметры главного конфигурационного файла — main.cf. К примеру, в openSUSE этот файл находится в каталоге /etc/postfix. Вы можете изменять значения параметров в соответствии со своими потребностями.
1. queue_directory = /var/spool/postfix
В процессе приема-получения почты письма могут находиться в разном состоянии. Одни только-только переданы на отправку, другие уже получены и пользователю остается только забрать их, а третье вообще зависло, потому что менеджер, которому отправляется письмо, был после хардкорной пьянки и не мог внятно продиктовать свой email, так что почта не может дойти до адресата. Для каж��ой из групп писем, имеющих одинаковый статус, предусмотрены отдельные каталоги, которые будут содержаться именно там, где указано в параметре queue_directory.
2. mail_owner = postfix
Дело в том, что будет плохо, если демон Postfix будет крутиться в режиме суперпользователя, поэтому при установке Postfix создается новый пользователь с именем postfix, который и будет являться владельцем этого процесса.
3. myhostname = mail.example.ru
Здесь мы задаем полностью определенное доменное имя нашего хоста. Это имя будет указываться в операциях, выполняемых про протоколу SMTP, в частности, в приветствии HELO. В принципе этот параметр может отсутствовать, если задан следующий параметр — mydomain. Можно значение myhostname вообще оставить пустым, при этом задав непустое значение для mydomain. Но лучше его все-таки задать, поскольку некоторые почтовые серверы, которым мы пересылаем почту, могут ругаться на то, что значение myhostname левое, неизвестно откуда взятое и вообще откажутся принимать от нас почту. В любом случае, если мы задаем значение параметра myhostname, значение mydomain будет сгенерировано автоматически на основании значения myhostname.
4. mydomain = example.ru
Здесь мы пишем имя нашего домена. И если мы пропустили предыдущий параметр, то он будет автоматически создан путем слияния результата вывода команды «uname -n», определяющей имя текущего хоста.
5. myorigin = example.ru
Этот параметр при отправлении почты добавляет свое значение к адресу отправителя, если оно указано не полностью. Например, если почта адресована юзеру thedude (это может быть даже почта, исходящая от локальных программ на данном сервере, например mdadm может послать сообщение с текстом «чувак, проверь-ка рейд-массивы»), то адрес, в соответствии со значением myorigin = example.ru, будет преобразован в thedude@example.ru.
6. mydestination = localhost, $mydomain, $myhostname, localhost.$mydomain
Как было сказано выше, одной из функций MTA является получение почты от одних MTA, и персылка ее другим MTA. Так вот, параметр mydestination служит для того, чтобы почта, приходящая на определенные адреса, указанные в значении параметра, не перенаправлялась куда-то, а оседала на нашем сервере в локальные почтовые ящики. То есть в нашем случае, мы будем принимать без перенаправления почту с адресами thedude@mail.example.ru, thedude@example.ru.
Да, еще один момент! Может еще быть непонятным — а как же заводить пользователей на почтовом сервере, давать им пароли, то есть осуществлять полноценный контроль пользовательских учетных записей. Например, нужно завести учетные записи coolboy@example.ru и coolgirl@example.ru. Для этого на почтовом сервере просто необходимо завести локальных пользователей, типа useradd coolboy; passwd coolboy; (далее ввести пароль для крутого парня) и, соответственно useradd coolgirl; passwd coolgirl; (девушку мы тоже без пароля не оставим). Мы можем посмотреть, что пользователи добавлены в файле /etc/shadow. Там будут логины и хеши паролей.
Да, еще один момент, команда useradd предусматривает сразу установку пароля (параметр -p), но, к сожалению, все равно приходится использовать passwd после этого, потому что аутентификация происходит с использованием хеша пароля, а useradd с параметром -p записывает пароль в /etc/shadow открытым текстом, например мы задали пароль 123456, и в файлик запишется 123456, что будет принято программой аутентификации за хеш пароля, в итоге юзер не получит почту с сообщением о том, что пароль неверный.
Таким образом, праильно указав, в соответствии со своими потребностями, вышеназванные параметры, мы получаем работоспособный MTA. Однако, это еще не все. Почта то пришла на наш сервер. А пользователям ее кто раздавать будет. А может быть они ее будут забирать сами? Сейчас мы ответим и на эти вопросы.
Итак, процедура получения пользователями писем с нашего сервера будет выглядеть следующим образом. Взаимодействие между почтовым сервером и пользовательским MUA осуществляется по протоколу POP3, то есть MUA на своем птичьем языке (команды POP3) говорит почтовому серверу, чтобы он не жадничал и отдал ему почту.
Однако, чтобы что-то услышать, для этого надо прежде всего слушать. Логично? То есть на сервере должен крутиться демон в ожидании запроса по POP3 протоколу. Для этого обратим свой взгляд в сторону xinetd. Xinetd (eXtended InterNET Daemon, еще его называют суперсервером) — это служба, которая управляет сетевыми соединениями. Говоря еще проще, она слушает запросы из сети по разным протоколам и у нее есть указания, каким программам на сервере передавать то, что она услышала. xinetd запускает эти программы, передавая при этом соответствующие параметры. А запросы по протоколу POP3 xinetd будет передавать POP3 серверу Qpopper (надо его сначала установить). Итак, заходим в /etc/xinetd.d, там открываем файлик qpopper и приводим его к следующему виду:
Названия параметров говорят сами за себя. Еще раз осознаем то, что мы проделали. Соответствие указания типа интернет-сервиса и обрабатывающей его программы (в нашем случае service pop3 соответствует /usr/sbin/popper) находятся в директории /etc/xinetd.d в виде файлов, которые содержат в себе информацию о том, какая программа будет обрабатывать запросы определенного типа/ При установке Qpopper сам создал указание, что запросы по pop3 будет обрабатывать именно он. А нам необходимо его активировать, установив disable в no.
Теперь заключительный этап — настройка MUA. Необходимо задать в настройках MUA POP3-сервер, SMTP-сервер (их ip-адреса или доменные имена). В нашем случае это один и тот же компьютер, поэтому указываем в этих параметрах одно и то же. Необходимо учесть, что во внутренней локальной сети необходимо указывать ip того сетевого интерфейса, который настроен именно для работы с локальной сетью. Далее указываем имя учетной записи и пароль.
А теперь, когда вся почтовая система работает, вы можете заниматься ее оптимизацией, ведь здесь еще есть много вещей, которые можно улучшить и много нововведений, которые просто просят о том, чтобы их привнесли. Удачи!
Итак, прежде, чем бросаться настраивать почтовый сервер, необходимо понять, как в принципе работает почта.
Буквально на пальцах рассмотрим пример. Пусть у нас есть внешний статический ip — 195.195.122.129 и собственный почтовый сервер, зарегистрировано доменное имя example.ru. Когда кто-то посылает почту на почтовый адрес, например, thedude@example.ru, то, рано или поздно, запрос относительно того, на какой же ip отправлять почту человеку с адресом на домене example.ru (то есть dns-запрос), дойдет до dns-сервера, где хранятся mx-записи с реквизитами example.ru, то есть говоря еще проще — этот dns-сервер отвечает в соответствии с этой записью, что почту, идущую на example.ru, нужно перенаправлять на 195.195.122.129. А когда письмо приходит на наш сервер мы уже его обрабатываем сами. Обрабатывать пришедшее письмо мы будем с помощью Message Transport Agent (далее MTA). Под MTA мы будем понимать программу, которая может:
1. Пересылать письма от пользовательского почтового клиента (Mail User Agent, далее MUA), к удаленному почтовому серверу. MTA пересылает письма, используя протокол SMTP (Simple Mail Transfer Protocol). Примерами MUA служить Mozilla Thunderbird, MS Outlook и др.
2. Доставлять письма в локальные почтовые ящики (заметьте, что здесь имеются ввиду ящики на сервере, а не на локальных компьютерах пользователей).
3. Пересылать письма другим MTA.
В данной статье мы будем рассматривать MTA Postfix. Он прост в конфигурировании, что позволит сосредоточиться на содержании, а не на форме. Приведем ниже основные параметры главного конфигурационного файла — main.cf. К примеру, в openSUSE этот файл находится в каталоге /etc/postfix. Вы можете изменять значения параметров в соответствии со своими потребностями.
1. queue_directory = /var/spool/postfix
В процессе приема-получения почты письма могут находиться в разном состоянии. Одни только-только переданы на отправку, другие уже получены и пользователю остается только забрать их, а третье вообще зависло, потому что менеджер, которому отправляется письмо, был после хардкорной пьянки и не мог внятно продиктовать свой email, так что почта не может дойти до адресата. Для каж��ой из групп писем, имеющих одинаковый статус, предусмотрены отдельные каталоги, которые будут содержаться именно там, где указано в параметре queue_directory.
2. mail_owner = postfix
Дело в том, что будет плохо, если демон Postfix будет крутиться в режиме суперпользователя, поэтому при установке Postfix создается новый пользователь с именем postfix, который и будет являться владельцем этого процесса.
3. myhostname = mail.example.ru
Здесь мы задаем полностью определенное доменное имя нашего хоста. Это имя будет указываться в операциях, выполняемых про протоколу SMTP, в частности, в приветствии HELO. В принципе этот параметр может отсутствовать, если задан следующий параметр — mydomain. Можно значение myhostname вообще оставить пустым, при этом задав непустое значение для mydomain. Но лучше его все-таки задать, поскольку некоторые почтовые серверы, которым мы пересылаем почту, могут ругаться на то, что значение myhostname левое, неизвестно откуда взятое и вообще откажутся принимать от нас почту. В любом случае, если мы задаем значение параметра myhostname, значение mydomain будет сгенерировано автоматически на основании значения myhostname.
4. mydomain = example.ru
Здесь мы пишем имя нашего домена. И если мы пропустили предыдущий параметр, то он будет автоматически создан путем слияния результата вывода команды «uname -n», определяющей имя текущего хоста.
5. myorigin = example.ru
Этот параметр при отправлении почты добавляет свое значение к адресу отправителя, если оно указано не полностью. Например, если почта адресована юзеру thedude (это может быть даже почта, исходящая от локальных программ на данном сервере, например mdadm может послать сообщение с текстом «чувак, проверь-ка рейд-массивы»), то адрес, в соответствии со значением myorigin = example.ru, будет преобразован в thedude@example.ru.
6. mydestination = localhost, $mydomain, $myhostname, localhost.$mydomain
Как было сказано выше, одной из функций MTA является получение почты от одних MTA, и персылка ее другим MTA. Так вот, параметр mydestination служит для того, чтобы почта, приходящая на определенные адреса, указанные в значении параметра, не перенаправлялась куда-то, а оседала на нашем сервере в локальные почтовые ящики. То есть в нашем случае, мы будем принимать без перенаправления почту с адресами thedude@mail.example.ru, thedude@example.ru.
Да, еще один момент! Может еще быть непонятным — а как же заводить пользователей на почтовом сервере, давать им пароли, то есть осуществлять полноценный контроль пользовательских учетных записей. Например, нужно завести учетные записи coolboy@example.ru и coolgirl@example.ru. Для этого на почтовом сервере просто необходимо завести локальных пользователей, типа useradd coolboy; passwd coolboy; (далее ввести пароль для крутого парня) и, соответственно useradd coolgirl; passwd coolgirl; (девушку мы тоже без пароля не оставим). Мы можем посмотреть, что пользователи добавлены в файле /etc/shadow. Там будут логины и хеши паролей.
Да, еще один момент, команда useradd предусматривает сразу установку пароля (параметр -p), но, к сожалению, все равно приходится использовать passwd после этого, потому что аутентификация происходит с использованием хеша пароля, а useradd с параметром -p записывает пароль в /etc/shadow открытым текстом, например мы задали пароль 123456, и в файлик запишется 123456, что будет принято программой аутентификации за хеш пароля, в итоге юзер не получит почту с сообщением о том, что пароль неверный.
Таким образом, праильно указав, в соответствии со своими потребностями, вышеназванные параметры, мы получаем работоспособный MTA. Однако, это еще не все. Почта то пришла на наш сервер. А пользователям ее кто раздавать будет. А может быть они ее будут забирать сами? Сейчас мы ответим и на эти вопросы.
Итак, процедура получения пользователями писем с нашего сервера будет выглядеть следующим образом. Взаимодействие между почтовым сервером и пользовательским MUA осуществляется по протоколу POP3, то есть MUA на своем птичьем языке (команды POP3) говорит почтовому серверу, чтобы он не жадничал и отдал ему почту.
Однако, чтобы что-то услышать, для этого надо прежде всего слушать. Логично? То есть на сервере должен крутиться демон в ожидании запроса по POP3 протоколу. Для этого обратим свой взгляд в сторону xinetd. Xinetd (eXtended InterNET Daemon, еще его называют суперсервером) — это служба, которая управляет сетевыми соединениями. Говоря еще проще, она слушает запросы из сети по разным протоколам и у нее есть указания, каким программам на сервере передавать то, что она услышала. xinetd запускает эти программы, передавая при этом соответствующие параметры. А запросы по протоколу POP3 xinetd будет передавать POP3 серверу Qpopper (надо его сначала установить). Итак, заходим в /etc/xinetd.d, там открываем файлик qpopper и приводим его к следующему виду:
#
# qpopper - pop3 mail daemon
#
service pop3
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/popper
server_args = -s
flags = IPv4Названия параметров говорят сами за себя. Еще раз осознаем то, что мы проделали. Соответствие указания типа интернет-сервиса и обрабатывающей его программы (в нашем случае service pop3 соответствует /usr/sbin/popper) находятся в директории /etc/xinetd.d в виде файлов, которые содержат в себе информацию о том, какая программа будет обрабатывать запросы определенного типа/ При установке Qpopper сам создал указание, что запросы по pop3 будет обрабатывать именно он. А нам необходимо его активировать, установив disable в no.
Теперь заключительный этап — настройка MUA. Необходимо задать в настройках MUA POP3-сервер, SMTP-сервер (их ip-адреса или доменные имена). В нашем случае это один и тот же компьютер, поэтому указываем в этих параметрах одно и то же. Необходимо учесть, что во внутренней локальной сети необходимо указывать ip того сетевого интерфейса, который настроен именно для работы с локальной сетью. Далее указываем имя учетной записи и пароль.
А теперь, когда вся почтовая система работает, вы можете заниматься ее оптимизацией, ведь здесь еще есть много вещей, которые можно улучшить и много нововведений, которые просто просят о том, чтобы их привнесли. Удачи!