Почта. Основы настройки в Linux

Когда начинающие системные администраторы сталкиваются с необходимостью настройки почтового сервера, они могут испытывать затруднения связанные с пониманием основных принципов работы почтового механизма. Чтобы внести ясность, я подготовил эту статью, основанную на освещении тех моментов, которые были мне в свое время непонятны. Статья подойдет также разработчикам ПО, которым надо быстро поднять почтовый сервер и протестировать свое приложение.

Итак, прежде, чем бросаться настраивать почтовый сервер, необходимо понять, как в принципе работает почта.

Буквально на пальцах рассмотрим пример. Пусть у нас есть внешний статический 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 того сетевого интерфейса, который настроен именно для работы с локальной сетью. Далее указываем имя учетной записи и пароль.

А теперь, когда вся почтовая система работает, вы можете заниматься ее оптимизацией, ведь здесь еще есть много вещей, которые можно улучшить и много нововведений, которые просто просят о том, чтобы их привнесли. Удачи!
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 19

    –2
    Спасибо, я новичек в этом деле, добавлю в закладки
      0
      Пожалуйста, эта статься как раз для новичков.
      0
      О, и да, а как с IMAP?
        +1
        Я выбрал QPopper для статьи, потому что он наиболее прост в настройке, на мой взгляд. Для работы с IMAP можно использовать Dovecot.
        +1
        Спасибо давно искал материал для новичков, на эту тему
          +5
          Материала для новичков в интернетах — пруд пруди. На одном только opennet.ru их легион в самых разных интерпретациях и конфигурациях.
          0
          Отлично, а как насчет момента корректного хождения почты?
          Я тут не профи, но вроде нужно настроить сервер на резолвинг имени по айпи? Или еще что?
            +1
            обратную зону и прямую зону mx-запись
              0
              Для того, что-бы ваша свежая почтовая система воспринималась остальными почтовыми серверами как легитимная, необходимо прописать обратную запись для IP адреса.
              Вот правильно зарегистрированный почтовый сервер mx.example.ru

              >host example.ru
              example.ru has address x.x.x.x
              example.ru mail is handled by X mx.example.ru

              >host mx.example.ru
              mx.example.ru has address 1.2.3.4

              >host 1.2.3.4
              4.3.2.1.in-addr.arpa domain name pointer mx.example.ru

              В обычном порядке обратные записи регистрируются и поддерживаются провайдером, выделившим вам IP адрес.
              0
              обратную зону и прямую зону mx-запись
                0
                Вот почему постоянно возникают инструкции, подобные этой? Вы всерьёз считаете, что локальные пользователи в качестве почтовых аккаунтов — это хорошая идея? Это было хорошо лет 10 назад, но сейчас — это мягко говоря нонсенс. В современных реалиах $mydestination должен быть пустым на обычном почтовике всегда. И никогда не должны использовать локальные пользвоатели. Специально, чтобы уйти от ущербной практики прибивания всех внешних сервисов гвоздями к системному окружению в postfix есть такая штука, которая называется virtual. И даже если у вас два пользователя — virtual обеспечивает гораздо большую гибкость, чем локальные пользователи.

                Поэтому сначала изучите вопрос до конца — а потом уже пишите инструкции.

                Кроме этого — ни слова про настройку DNS и правил обработки писем. Постфикс, к вашему сведению, в большинстве пакетных дистрибутивов идёт преднастроенным как раз так, как написано, хоть это и глупо. Но даже пытаться запустить почтовый сервер не понимая, что такое PTR, MX, SPF и прочие прелести, как управлять рестрикшенами постфикса — это абсолютно бесполезно. Вы 100% сделает ещё один рассадник спама, который быренько забанят на гугле и прочих ресурсах и почта у вас будет работать только в сферическом ваакуме.

                В общем полезной информации в статье — 0, а для новичков она вообще однозначно вредна.
                  0
                  >Вы всерьёз считаете, что локальные пользователи в качестве почтовых аккаунтов — это хорошая идея?
                  Внезапно, да. Часто бывает так, что один и тот же сервер выполняет много функций: файл-сервер, терминальный, почта. Я считаю, что удобнее следить за одним аккаунтом пользователя, чем за его соответствиями в разных программах.

                  >Поэтому сначала изучите вопрос до конца — а потом уже пишите инструкции.
                  Ну ничего себе? Если бы я влил бы кучу технических подробностей, ее было бы трудно читать.

                  >Кроме этого — ни слова про настройку DNS и правил обработки писем.
                  А за вот это замечание спасибо. Надо было бы мне добавить про это. Эти вещи совсем не лишние.
                    0
                    В том-то и весь прикол, что всё уже давно не завязано на локальных пользователей. И файловые серверы в том числе. Более того, чтобы сделать качественную корпоративную систему вам придётся использовать внешних пользователей. На локальных далеко не уедешь — только простенькие задачи for fan. Да и проще настраивать у правлять системами, в которых есть отдельная база пользвоателей внешних сервисов.
                      0
                      Для небольшой сети — самое то. И, самое, главное, для примера, то, что нужно. Для сетей побольше, на мой взгляд, лучше использовать LDAP и через него предоставлять доступ к различным сервисам. Но сильно разбрасывать аккаунты по разным системам мне не нравится.
                  0
                  useradd -mU -p $(openssl passwd password)
                    0
                    О, спасибо. Это как раз то, что нужно.
                    0
                    ИМХО, такая настройка подойдёт только для разработчиков, системных администраторов с такими знаниями я бы не допустил к настройке почтового сервера :)
                    Помню, на моей первой работе первым же большим серьёзным заданием был перевод почты компании (50 программистов) с сендмэйла (в котором не разбирался никто) на экзим. О, этой статьи мне бы точно не хватило тогда :)
                      0
                      Эта статья написана с целью дать представление о почтовом механизме (она так и называется — «Основы настройки в Linux») и я старался сделать упор не на технические детали, но окинуть взглядом всех участников процессов отправки и получения почты.
                      В комментарии выше мне подсказали, какие детали стоило бы еще рассмотреть.
                      Так что, поставлю себе в планы написать еще одну статью, посвященную как раз подробностям различного рода.
                      Всем спасибо за замечания.
                        0
                        Извините, но основы настройки — это вот: workaround.org/ispmail/squeeze
                        То, что описано в статье, с легкостью делает dpkg-reconfigure.

                    Only users with full accounts can post comments. Log in, please.