что такое mta почта
Что такое SMTP, SMTP сервер и MTA
SMTP (аббревиатура от Simple Mail Transfer Protocol) — это один из старейших, популярных сетевых протоколов, предназначенный для доставки электронной почты в сетях TCP/IP.
Smtp протоколу более 35 лет. Последнюю модификацию протокол получил в 2008, которая включала в себя масштабируемое расширение — ESMTP (аббревиатура от английского названия Extended Smtp).
Стандартным TCP портом, на котором по умолчанию работает протокол, является 25 порт.
В другом смысле smtp-сервером (или почтовым сервером) является и физический или виртуальный (VPS/VDS) сервер, который выполняет функции почтового сервера. То есть, любой сервер, на аппаратных ресурсах которого развернуто программное обеспечение почтового сервера в просторечии именуют «smtp-сервером».
Работа MTA совмещает в себе одновременно функции внешней и локальной доставки и получения почты.
Схема, принцип работы почты
Путь письма от отправителя до получателя:
В почтовой программе (почтовом клиенте) пользователь-отправитель создает письмо и передает (опция «отправить») по smtp протоколу на почтовый сервер адреса своего почтового ящика к дальнейшей отправке. Почтовый сервер (MTA) пользователя-отправителя связывается, так же, по smtp протоколу с почтовым сервером (MTA) пользователя-получателя (адресата) письма и передает ему письмо для дальнейшей передачи в почтовый ящик пользователя.
Сравнить работу электронной почты можно с работой физической, бумажной почты
Программное обеспечение почтового сервера
Варианты SMTP-серверов (MTA) в операционных системах семейства Linux:
Варианты SMTP-серверов (MTA), которые могут быть установлены в операционных системах Windows:
Как работает электронная почта?
Вот подробная схема с википедии:
Подпись к изображению:
Объясните мне, как по этой схеме происходит отправка почты. когда я с mail.ru пишу на gmail?
Что будет являться MTU, что будет являться MUA, где именно хранятся все полученные письма?
Возьмём двух почтовых провайдеров: mail.ru и gmail.com.
На них зарегистрировались соответственно два пользователя: А@mail.ru и Б@gmail.com
Чтобы А успешно оправил письмо получателю Б, а тот его принял, происходит следующее.
Схема довольно проста:
Отправитель А@mail.ru посылает письмо получателю Б@gmail.com
Сервер mail.ru (MTA), получив задание с помощью почтового посредника MUA (клиентская почтовая программа (The Bat, Mozilla Thunderbird)) по протоколу SMTP, ищет почтовый сервер gmail.com (MTA) по доменной части адреса (в нашем случае gmail.com) через DNS. SMTP сервер mail.ru ищет в DNS для домена gmail.com запись MX (mail exchange), она и указывает на MTA сервер получателя Б@gmail.com (в простом случае).
Далее MTA mail.ru связывается с MTA gmail.com по протоколу SMTP, происходит ряд проверок со стороны обоих серверов, если все успешно, то письмо передается в почтовую очередь сервера gmail.com.
Затем MTA gmail.com доставляет письмо на сервер входящей почты (называющийся MDA, то есть агент доставки электронной почты), который хранит письмо в почтовом ящике пользователя Б@gmail.com в ожидании его приема пользователем. Далее с помощью MUA (клиентская почтовая программа (The Bat, Mozilla Thunderbird)) пользователь Б@gmail.com извлекает из MDA письмо по протоколу POP или IMAP.
В качестве MUA может выступать веб-интерфейс, использующийся для взаимодействия с сервером входящей почты (MDA) и сервером исходящей почты (MTA).
Это неправильная схема, соответственно выше к ней неправильные комментарии.
MTA (mail transfer agent) используется для обмена почтой между серверами, MDA (mail delivery agent) для локальной доставки письма в почтовый ящик, и MTA и MDA работают на почтовых серверах. MTA и MDA могут быть частями одной почтовой программы (большая часть MTA в той или иной степени поддерживают локальную доставку), а могут быть разными приложениями. Но к компьютеру ползователя ни MTA ни MDA не имеют отношения, они работают на почтовом сервере. MUA используется для получения письма из почтового ящика, создания письма, передачи письма MTA.
Схема такая:
1. MUA формирует письмо. В качестве MUA может выступать почтовая программа или веб-интерфейс.
2. MUA передает письмо MTA отправителя (relay), в случае почтовой программы через протокол SMTP Submission (SMTP с авторизацией), в случае веб-интерфейса обычно напрямую.
3. MTA отправителя (relay) определяет MTA получателя (mail exchanger) через MX или A записи DNS.
4. MTA отправителя (relay) передает письмо на MTA получателя (mail exchanger) по протоколу SMTP (без аутентификации)
5. MTA получателя либо передает письмо MDA для локальной доставки в почтовый ящик (обычный путь доставки) либо передает письмо другому MTA, например если в ящике установлено перенаправление.
6. MDA кладет письмо в ящик получателя
7. MUA получателя получает письмо из ящика через протоколы POP3, IMAP4 или веб-интерфейс
Почтовые серверы
Свободные MTA Postfix и Exim: общее
Почтовый сервер фактически является агентом пересылки почты (mail transfer agent, MTA). Говоря техническим языком, задача MTA — быть доступным на 25 порту и осуществлять приём писем своего домена от других почтовых серверов и передачу им писем в рамках протокола Simple Mail Transfer Protocol (SMTP).
MTA — всего лишь один из кирпичиков в вашем будущем здании. Дело в том, что по умолчанию Postfix и Exim (EXperimental Internet Mailer) доставляют почту только локальным системным пользователям, что в современных реалиях обычно не устраивает администраторов. Традиционно многочисленные почтовые учётные записи пользователей создают в реляционных базах данных типа MySQL, PostgreSQL или хранят в каталоге LDAP.
И тут же возникает вопрос, а как выделить администраторам интерфейс для удобного управления учётными записями и дополнительный веб-интерфейс к почте для пользователей? Администраторы обычно устанавливают себе что-то типа PostfixAdmin, если выбрали MTA Postfix и что-то типа Virtual Exim 2, если выбран Exim.
Пример архитектуры готового решения на базе Postfix
Для работы веб-интерфейса нужно поставить и настроить один из популярных веб-серверов Apache или Nginx и разобраться с версиями и модулями языков программирования PHP и Perl, на которых обычно создают веб-проекты. Веб-интерфейс для пользователей делают опционально, но если вы решитесь, то придётся настроить что-то типа Roundcube, SquirrelMail и т.д.
На этом всё? Современные реалии сурового Интернета требуют от администратора защиты от спама в лице свободных проектов Amavis, SpamAssassin, Rspamd и свободное антивирусное решение ClamAV или любое купленное вами. Идеально, если вся готовая система будет подписывать исходящие почтовые сообщения через DomainKeys Identified Mail (DKIM) и проверять через Sender Policy Framework (SPF).
Уф, на этом всё? К сожалению, нет. Пользователь должен иметь возможность обычной почтовой программой (mail user agent, MUA) забрать свои сообщения с почтового сервера. Но как? Обычно используется свободный сервер Dovecot (Local Delivery Agent, LDA), который реализует протоколы Internet Message Access Protocol (IMAP) и Post Office Protocol Version 3 (POP3).
Различия MTA Postfix и Exim
Безопасность
Самое серьёзное отличие Postfix от Exim состоит в том, что Postfix архитектурно грамотно заложил безопасность в свой фундамент со дня первого релиза. Дело в том, что в любой операционной системе для открытия программой на прослушивание (bind) портов с номером меньше 1024 требуются права администратора (root в Linux системе), что автоматически подразумевает открытие порта 25 SMTP (
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Почтовый сервер для начинающих. Структура и принцип работы
Многие системные администраторы испытывают определенные трудности при работе с системами электронной почты. Это неудивительно, почтовый сервер имеет гораздо более сложную структуру, чем файловый сервер, роутер или сервер терминалов. В этой статье мы рассмотрим структуру и принцип работы почтовых серверов, без понимания которых настройка системы электронной почты вполне способна превратиться в шаманские танцы с бубном.
Данный материал содержит довольно много упрощений и обобщений, с целью дать системным администраторам необходимый минимум знаний. На наш взгляд, ради администрирования одного-двух почтовых серверов начального уровня становиться специалистом в области электронной почты совсем не обязательно.
Для большинства пользователей и начинающих администраторов почтовый сервер представляет собой некий «черный ящик», который получив письмо «неведомыми» путями доставляет его адресату и наоборот. Все взаимодействие с таким сервером заключается в обращении почтового клиента к определенным портам, а то и вообще через веб-интерфейс. Однако внутри скрыт целый механизм, понимание работы которого имеет ключевое значение для успешной настройки и обслуживания системы электронной почты. Это особенно важно для администрирования серверов на платформе Linux. В отличии от Windows, где почтовый сервер представляет собой законченное программное решение и о внутреннем взаимодействии уже позаботились разработчики, в Linux компоненты почтового сервера представляют собой отдельные программы и настраивать их взаимодействие нужно самостоятельно.
Рассмотрим структуру почтового сервера, а также что происходит когда пользователь пытается отправить почту.
Вопреки распространенному заблуждению, 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 проверяет наличие пользователя в списках и, при успешной проверке, передает клиенту все новые сообщения находящиеся в его почтовом ящике. Пользователь Иванов получает свою корреспонденцию и может работать с ней удобным ему способом.
На этом наша статья заканчивается, мы настоятельно рекомендуем вдумчивое прочтение и усвоение изложенного в ней материала. В последующем, при рассмотрении практических реализаций почтовых серверов мы будем подавать материал из расчета, что читатель имеет знания в объеме не менее данной статьи.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Почтовый сервер оперирует двумя отдельными процессами:
Процесс Передачи Почты (MTA) используется для перенаправления e-mail. Как показано на рисунке, MTA получает сообщения от MUA или от другого MTA на другом почтовом сервере. На основании заголовка сообщения, он определяет, как сообщение должно быть перенаправлено, чтобы достичь своего назначения. Если почта адресована пользователю, чей почтовый ящик находится на локальном сервере, почта проходит к MDA. Если почта предназначена для пользователя не на локальном сервере, MTA перенаправляет e-mail на MTA подходящего сервера.
На рисунке мы видим, что Агент Доставки Почты (MDA) принимает часть e-mail от Агента Передачи Почты (MTA) и выполняет фактическую доставку. MDA получает всю входящую почту от MTA и помещает ее в соответствующие почтовые ящики пользователей. MDA может также разрешать финальные проблемы доставки, такие как противовирусное сканирование, фильтрация спама и обработку расписок о получении. Большинство e-mail коммуникаций используют приложения MUA, MTA и MDA. Однако, существуют и другие альтернативы для доставки e-mail.
Клиент может быть подключен к корпоративной системе e-mail, такой как IBM’s Lotus Notes, Novell’s Groupwise или Microsoft’s Exchange. Эти системы зачастую имеют свой собственный внутренний формат e-mail, и их клиенты обычно взаимодействуют с сервером e-mail посредством частного протокола. Сервер посылает или получает e-mail через Интернет по шлюзу Интернет почты продукта, который выполняет все необходимое переформатирование.
В качестве другой альтернативы можно привести пример компьютеров, на которых не установлен MUA, но они по прежнему могут подключаться к почтовой службе через веб браузер, чтобы получать и отправлять сообщения по аналогии, как это делается с помощью MUA. Некоторые компьютеры могут запускать свои собственные MTA и управлять внутри-доменной электронной почтой сами по себе. Если, к примеру, два человека, работающие в одной и той же компании, обмениваются e-mail друг с другом, используя частный протокол, их сообщения могут оставаться исключительно в пределах корпоративной системы e-mail предприятия.