Многие системные администраторы испытывают определенные трудности при работе с системами электронной почты. Это неудивительно, почтовый сервер имеет гораздо более сложную структуру, чем файловый сервер, роутер или сервер терминалов. В этой статье мы рассмотрим структуру и принцип работы почтовых серверов, без понимания которых настройка системы электронной почты вполне способна превратиться в шаманские танцы с бубном.
Данный материал содержит довольно много упрощений и обобщений, с целью дать системным администраторам необходимый минимум знаний. На наш взгляд, ради администрирования одного-двух почтовых серверов начального уровня становиться специалистом в области электронной почты совсем не обязательно.
Для большинства пользователей и начинающих администраторов почтовый сервер представляет собой некий "черный ящик", который получив письмо "неведомыми" путями доставляет его адресату и наоборот. Все взаимодействие с таким сервером заключается в обращении почтового клиента к определенным портам, а то и вообще через веб-интерфейс. Однако внутри скрыт целый механизм, понимание работы которого имеет ключевое значение для успешной настройки и обслуживания системы электронной почты. Это особенно важно для администрирования серверов на платформе Linux. В отличии от Windows, где почтовый сервер представляет собой законченное программное решение и о внутреннем взаимодействии уже позаботились разработчики, в Linux компоненты почтового сервера представляют собой отдельные программы и настраивать их взаимодействие нужно самостоятельно.
Рассмотрим структуру почтового сервера, а также что происходит когда пользователь пытается отправить почту.
Важнейшей часть почтового сервера является MTA (Mail Transfer Agent -- агент пересылки почты) в задачи которого входит прием и передача почты. Очень часто (в Linux / UNIX) МТА называют также почтовым сервером. MTA работает по протоколу SMTP, и его одного, в принципе, уже достаточно для создания системы электронной почты. Когда-то давно именно так и было и для доступа к своему почтовому ящику требовалось обладать определенными техническими знаниями.
Однако прогресс не стоит на месте, MTA, получая письмо, помещает его в почтовый ящик пользователя на сервере, к которому последний должен получить доступ, желательно наиболее простым и понятным способом. Вот здесь на сцену выходит MDA (Mail Delivery Agent -- агент доставки почты), его задача по запросу почтового клиента передать ему почту из почтового ящика на сервере. MDA может работать по протоколам POP3 или IMAP, в ряде случаев для "общения" почтового клиента и агента доставки могут применяться собственные протоколы, обладающие расширенной функциональностью, например MAPI (Exchange Server).
Вопреки распространенному заблуждению, MDA не имеет никакого отношения к процессу передачи почты. Это прерогатива MTA. Если провести аналогию, MTA можно представить как почтовое отделение, которое занимается приемом и отправкой почты, а MDA с почтальоном, который приносит пришедшую корреспонденцию к вам домой. Если почтальон заболел, то это никак не скажется на работе почты, просто вы не получите письма на дом. Также и MDA, его отказ не приводит к неработоспособности почтового сервера, становится недоступно только получение почты почтовым клиентом, в то же время к ней можно спокойно получить доступ другими путями, например, через веб интерфейс.
Посмотрим, что происходит при отправке почты. В нашем примере пользователь Иванов, находящийся в домене example.org (ivanov@example.org), пишет письмо Козлову в домен example.com (kozlov@example.com). Для Иванова процесс отправки почты состоит из создания сообщения и нажатия кнопки "Отправить" в почтовом клиенте. Почтовый клиент соединяется с МТА по протоколу SMTP и первым делом сообщает свои учетные данные. Авторизовав пользователя, MTA принимает сообщение и пытается доставить его дальше.
Вообще-то авторизация не является обязательной процедурой для MTA, но без авторизации мы получим открытый релей, т.е. любой может воспользоваться нашим сервером для пересылки почты, а как спамеры обрадуются! В настоящее время открытые релеи возникают в основном из-за ошибок настройки сервера. Однако вполне допустима ситуация, когда MTA без авторизации принимает почту от доверенных пользователей, например из локальной сети предприятия.
Для авторизации MTA может использовать собственный список пользователей, системный список, списки пользователей LDAP или AD. Также существует способ: авторизация POP прежде SMTP, когда пользователь перед отправкой почты авторизуется на MDA, который, в свою очередь подтверждает аутентификацию пользователя для MTA.
Следующим шагом MTA анализирует служебную информацию письма, определяя домен получателя, если он относится к доменам обслуживаем данным МТА, производится поиск получателя и письмо помещается в его ящик. Так произошло, если бы Иванов написал письмо Петрову или Сидорову.
Если домен получателя не обслуживается MTA, формируется DNS-запрос, запрашивающий MX-записи для данного домена. MX-запись представляет особый вид DNS-записи, которая содержит имена почтовых серверов, обрабатывающих входящую почту для данного домена. MX-записей может быть несколько, в этом случае MTA пробует последовательно установить соединение, начиная с сервера с наибольшим приоритетом. При отсутствии MX-записи запрашивается A-запись (запись адреса, сопоставляющая доменное имя с IP-адресом) и выполняется попытка доставить почту на указанный там хост. При невозможности отправить сообщение, оно возвращается отправителю (помещается в почтовый ящик пользователя) с сообщением об ошибке.
Мы не будем рассматривать работу принимающего сервера, будем считать что все прошло нормально, Козлов получил письмо от Иванова и написал ему ответ. Сервер, обслуживающий домен example.com, проводит точно такие же действия и пробует передать почту нашему серверу. Получив входящее сообщение MTA, как и в случае с локальным отправителем, проверяет домен получателя, если он входит в число обслуживаемых MТА, обработка сообщения продолжается, иначе сервер отказывается принимать почту. После проверки домена проверяется получатель, если он присутствует в списке пользователей, сообщение доставляется в его ящик, в противном случае возможны два варианта: отказ от приема сообщения или прием сообщения в общий почтовый ящик (ящик администратора). С одной стороны такая настройка увеличивает число принимаемого спама, с другой позволяет не потерять письма с ошибками в написании адреса.
Еще одной мерой защиты от спама является запрос PTR-записи. PTR-запись (запись указателя) связывает IP-адрес с именем домена. Запрашивая PTR, MTA принимает почту только в том случае если домен отправителя совпадает с доменом отправляющего сервера.
Рассмотрим пример более подробно. Некий спамерский сервер spam.com пытается рассылать письма с поддельным отправителем, якобы от известного нам сервера example.com. В случае фильтрации по белым / черным спискам такое письмо будет доставлено, так как отправителем числится пользователь из доверенного домена (на что и рассчитывали спамеры). В целях борьбы со спамом MTA формирует запрос PTR записи для IP-адреса отправляющего сервера, который он сообщает в процессе SMTP сессии. Для адреса y.y.y.y PTR-запрос вернет имя домена spam.com, которое не совпадает с доменом отправителя, что будет причиной отказа в приеме данного сообщения. В то-же время сообщения от сервера x.x.x.x будут получены, так как домен из PTR-записи для x.x.x.x (example.com) совпадает с доменом отправителя.
Итак, сообщение получено и находится в почтовом ящике пользователя. Как его прочитать? Почтовое хранилище, где находятся ящики пользователей, может быть организовано самыми различными способами: начиная от банальных папок и фалов, заканчивая базой данных. Не обладая техническими знаниями, прочитать собственную почту вряд-ли удастся. Но разве это должно волновать пользователя Иванова? Для него процесс получения почты сводится к нажатию кнопки "Получить" в почтовом клиенте.
Для получения почты клиент устанавливает соединение с MDA по протоколу POP3 или IMAP, обязательно передавая данные для авторизации. MDA проверяет наличие пользователя в списках и, при успешной проверке, передает клиенту все новые сообщения находящиеся в его почтовом ящике. Пользователь Иванов получает свою корреспонденцию и может работать с ней удобным ему способом.
На этом наша статья заканчивается, мы настоятельно рекомендуем вдумчивое прочтение и усвоение изложенного в ней материала. В последующем, при рассмотрении практических реализаций почтовых серверов мы будем подавать материал из расчета, что читатель имеет знания в объеме не менее данной статьи.
Дополнительные материалы:
Почтовый сервер для начинающих. Настраиваем DNS зону.
Для большинства пользователей и начинающих администраторов почтовый сервер представляет собой некий "черный ящик", который получив письмо "неведомыми" путями доставляет его адресату и наоборот. Все взаимодействие с таким сервером заключается в обращении почтового клиента к определенным портам, а то и вообще через веб-интерфейс. Однако внутри скрыт целый механизм, понимание работы которого имеет ключевое значение для успешной настройки и обслуживания системы электронной почты. Это особенно важно для администрирования серверов на платформе Linux. В отличии от Windows, где почтовый сервер представляет собой законченное программное решение и о внутреннем взаимодействии уже позаботились разработчики, в Linux компоненты почтового сервера представляют собой отдельные программы и настраивать их взаимодействие нужно самостоятельно.
Рассмотрим структуру почтового сервера, а также что происходит когда пользователь пытается отправить почту.
Важнейшей часть почтового сервера является MTA (Mail Transfer Agent -- агент пересылки почты) в задачи которого входит прием и передача почты. Очень часто (в Linux / UNIX) МТА называют также почтовым сервером. MTA работает по протоколу SMTP, и его одного, в принципе, уже достаточно для создания системы электронной почты. Когда-то давно именно так и было и для доступа к своему почтовому ящику требовалось обладать определенными техническими знаниями.Однако прогресс не стоит на месте, MTA, получая письмо, помещает его в почтовый ящик пользователя на сервере, к которому последний должен получить доступ, желательно наиболее простым и понятным способом. Вот здесь на сцену выходит MDA (Mail Delivery Agent -- агент доставки почты), его задача по запросу почтового клиента передать ему почту из почтового ящика на сервере. MDA может работать по протоколам POP3 или IMAP, в ряде случаев для "общения" почтового клиента и агента доставки могут применяться собственные протоколы, обладающие расширенной функциональностью, например MAPI (Exchange Server).
Вопреки распространенному заблуждению, MDA не имеет никакого отношения к процессу передачи почты. Это прерогатива MTA. Если провести аналогию, MTA можно представить как почтовое отделение, которое занимается приемом и отправкой почты, а MDA с почтальоном, который приносит пришедшую корреспонденцию к вам домой. Если почтальон заболел, то это никак не скажется на работе почты, просто вы не получите письма на дом. Также и MDA, его отказ не приводит к неработоспособности почтового сервера, становится недоступно только получение почты почтовым клиентом, в то же время к ней можно спокойно получить доступ другими путями, например, через веб интерфейс.
Посмотрим, что происходит при отправке почты. В нашем примере пользователь Иванов, находящийся в домене example.org (ivanov@example.org), пишет письмо Козлову в домен example.com (kozlov@example.com). Для Иванова процесс отправки почты состоит из создания сообщения и нажатия кнопки "Отправить" в почтовом клиенте. Почтовый клиент соединяется с МТА по протоколу SMTP и первым делом сообщает свои учетные данные. Авторизовав пользователя, MTA принимает сообщение и пытается доставить его дальше.
Вообще-то авторизация не является обязательной процедурой для MTA, но без авторизации мы получим открытый релей, т.е. любой может воспользоваться нашим сервером для пересылки почты, а как спамеры обрадуются! В настоящее время открытые релеи возникают в основном из-за ошибок настройки сервера. Однако вполне допустима ситуация, когда MTA без авторизации принимает почту от доверенных пользователей, например из локальной сети предприятия.
Для авторизации MTA может использовать собственный список пользователей, системный список, списки пользователей LDAP или AD. Также существует способ: авторизация POP прежде SMTP, когда пользователь перед отправкой почты авторизуется на MDA, который, в свою очередь подтверждает аутентификацию пользователя для MTA.
Следующим шагом MTA анализирует служебную информацию письма, определяя домен получателя, если он относится к доменам обслуживаем данным МТА, производится поиск получателя и письмо помещается в его ящик. Так произошло, если бы Иванов написал письмо Петрову или Сидорову.
Если домен получателя не обслуживается MTA, формируется DNS-запрос, запрашивающий MX-записи для данного домена. MX-запись представляет особый вид DNS-записи, которая содержит имена почтовых серверов, обрабатывающих входящую почту для данного домена. MX-записей может быть несколько, в этом случае MTA пробует последовательно установить соединение, начиная с сервера с наибольшим приоритетом. При отсутствии MX-записи запрашивается A-запись (запись адреса, сопоставляющая доменное имя с IP-адресом) и выполняется попытка доставить почту на указанный там хост. При невозможности отправить сообщение, оно возвращается отправителю (помещается в почтовый ящик пользователя) с сообщением об ошибке.
Мы не будем рассматривать работу принимающего сервера, будем считать что все прошло нормально, Козлов получил письмо от Иванова и написал ему ответ. Сервер, обслуживающий домен example.com, проводит точно такие же действия и пробует передать почту нашему серверу. Получив входящее сообщение MTA, как и в случае с локальным отправителем, проверяет домен получателя, если он входит в число обслуживаемых MТА, обработка сообщения продолжается, иначе сервер отказывается принимать почту. После проверки домена проверяется получатель, если он присутствует в списке пользователей, сообщение доставляется в его ящик, в противном случае возможны два варианта: отказ от приема сообщения или прием сообщения в общий почтовый ящик (ящик администратора). С одной стороны такая настройка увеличивает число принимаемого спама, с другой позволяет не потерять письма с ошибками в написании адреса.
Еще одной мерой защиты от спама является запрос PTR-записи. PTR-запись (запись указателя) связывает IP-адрес с именем домена. Запрашивая PTR, MTA принимает почту только в том случае если домен отправителя совпадает с доменом отправляющего сервера.
Рассмотрим пример более подробно. Некий спамерский сервер spam.com пытается рассылать письма с поддельным отправителем, якобы от известного нам сервера example.com. В случае фильтрации по белым / черным спискам такое письмо будет доставлено, так как отправителем числится пользователь из доверенного домена (на что и рассчитывали спамеры). В целях борьбы со спамом MTA формирует запрос PTR записи для IP-адреса отправляющего сервера, который он сообщает в процессе SMTP сессии. Для адреса y.y.y.y PTR-запрос вернет имя домена spam.com, которое не совпадает с доменом отправителя, что будет причиной отказа в приеме данного сообщения. В то-же время сообщения от сервера x.x.x.x будут получены, так как домен из PTR-записи для x.x.x.x (example.com) совпадает с доменом отправителя.Итак, сообщение получено и находится в почтовом ящике пользователя. Как его прочитать? Почтовое хранилище, где находятся ящики пользователей, может быть организовано самыми различными способами: начиная от банальных папок и фалов, заканчивая базой данных. Не обладая техническими знаниями, прочитать собственную почту вряд-ли удастся. Но разве это должно волновать пользователя Иванова? Для него процесс получения почты сводится к нажатию кнопки "Получить" в почтовом клиенте.
Для получения почты клиент устанавливает соединение с MDA по протоколу POP3 или IMAP, обязательно передавая данные для авторизации. MDA проверяет наличие пользователя в списках и, при успешной проверке, передает клиенту все новые сообщения находящиеся в его почтовом ящике. Пользователь Иванов получает свою корреспонденцию и может работать с ней удобным ему способом.
На этом наша статья заканчивается, мы настоятельно рекомендуем вдумчивое прочтение и усвоение изложенного в ней материала. В последующем, при рассмотрении практических реализаций почтовых серверов мы будем подавать материал из расчета, что читатель имеет знания в объеме не менее данной статьи.
Дополнительные материалы:
Почтовый сервер для начинающих. Настраиваем DNS зону.
Тут все хотели почтовый сервер. Только теорию, я смотрю, никто читать не хочет. Господа, вы определитесь, мы с вами идем дальше к практической реализации или вам нужен мануал по вбиванию команд в консоль? Последнее здесь вряд-ли будет,а без понимания изложенных здесь вещей дальше идти бессмысленно.
Ещё раз большое спасибо за все ваши статьи! Они мне очень помогают понять смысл работы в Linux. Конечно же я прочитал и осмыслил вашу вводную статью про почту, в первый же день как она появилась на сайте. И очень бы хотелось увидеть практическое решение реализации почтового сервера. Но не для бездумного копирования команд в консоли. В последующем, после понимания принципов работы ваших готовых решений я уже сам немного меняю конфигурацию под конкретные задачи в нашей организации. Скажу честно, я уже очень давно ждал эту статью и очень обрадовался когда она появилась! И хотелось бы увидеть продолжение! Вы очень хорошо умеете объяснять и за это я вам очень благодарен!
Уважаемый А.С.!
Пишите ещё. Просто (говорю за себя) не всё можно сразу применить и опробовать (то сил и времени не хватает, то средства не позволяют, то... да много ещё причин), но то, что Ваши статьи очень нужны новичкам, думаю согласятся все, кто их читал. Они очень информативны и интуитивно понятны.
Огромное Вам спасибо.
Я к тому, что скоро будет статья (практический материал уже готов) по почтовому серверу, при ее написании на вышеизложенных моментах мы останавливаться не будем, материала и так много. Однако без понимания базовых принципов с большой вероятностью возникнут проблемы.
Большое спасибо за человеческий язык!
Просто, доступно, понятно.
Доброго времени суток уважаемому автору :)
Большое спасибо за ваши статьи и хочу согласиться с тем, что теория очень важна и перед практической реализацией необходимо давать теоретическую базу. Я для себя очень много почерпнул из ваших статей и на многие вопросы сами собой нашлись ответы, а сочетая теоретическую базу с практическими реализациями эффект усвояемости материала и понимания просто отличный!!! Думаю ваша методика подачи материала очень хороша и надеюсь продолжите в том же духе.
Второй день как узнал о вашем проекте, очень все нравиться, отличные статьи и мануалы. Спасибо!
Вопрос немного не в тему,но всё же.
Чем Вы рисовали эти схемы? Очень красиво и понятно.
Я использую Dia, но его схемы выглядят "коряво". :-(
MS Visio, к сожалению достойной замены нам найти не удалось. В принципе если приобретать по программе Open License то цена вполне приемлема, около 6500 руб за Стандарт.
Очень интересно!
А когда продолжение ожидается?
Смотрите внизу статьи.
Появится ли практическая часть материала?
Например по работе с Postfix + Courier + MySQL.
Без антивирусного сканера, без квотирования, без спам-фильтра. А в конце статьи уже практически показать, как прикрутить спам-фильтр и антивирус...
Перепробовал уже с десяток сайтов, на которых расписаны настройки, то получается, что по одним настройкам только отправляет почту, по вторым настройкам отправляет и принимает, но не пускает в Веб-интерфейс (пишет, что невозможно соединиться с IMAP сервером).. и так далее, похожие проблемы и приходится всё переделывать снова..
Пытаемся уже давно проработать материал, но не хватает времени.
Что касается указанной вами связки, то ее рассматривать не будем точно. Будет Exim + Dovecot + системный список пользователей / LDAP. Расскажите, какой смысл для корпоративного почтовика в виртуальных пользователях, тем более выделять для этого SQL базу?
не знаю как прочитать сообщение из почтового ящика
Из какого почтового ящика? Вы вообще о чем?
Добрый день! Подскажите пожалуйста.
Имеем сервер Ubuntu с статическим ip. На нем настроен postfix для отправки писем на прямую. Через этот сервер шлют почту сотрудники компании. Соответственно до некоторых ящиков они не доходят, лог Postfix "Client host rejected: cannot find your hostname, [yyy.yyy.yyy.yyy] (in reply to RCPT TO command)"
Что сделал сейчас, зарегистрировал домен типа mail.домен.ру и прописал в нём запись типа А yyy.yyy.yyy.yyy. Скажите этого достаточно для того что бы удаленные сервера принимали от нашего сервера письма?
Ну вообще к домен.ру нужно сделать MX запись mail.домен.ру и не забыть сделать PTR запись для mail.домен.ру у провайдера выдавшего вам ip адрес.