Архитектура почтовой системы

FAQ – Рекомендации по организации архитектуры почтовой системы домена и ее интеграция с сервисами RBL/DNSBL.

Раздел на стадии разработки.

Если у Вас есть пожелания и вопросы, которые необходимо осветить в этом разделе, пишите в Контакт.

Использование сервисов фильтрации спама на основе технологии RBL/DNSBL очень часто сопряжено с трудностями в работе как администраторов, так и обычных пользователей почты. Большинство проблем связано с архитектурной организацией самой почтовой системы домена, которая изначально строится по классической схеме, без учета принципов работы RBL/DNSBL сервиса.

Важно помнить: RBL/DNSBL сервис, есть не что иное, как постоянно изменяющий ACL с размещением на внешнем сервере. Проверка благонадежности клиента выполняется в момент его подключения по IP-адресу. Т.о., клиент может получить отказ в обслуживании до того момента, как получит возможность авторизоваться на сервере, подтвердив свои права. Что бы избежать подобных проблем, необходимо правильно выбрать и настроить архитектуру почтовой системы.

В этом разделе рассматриваются самые распространенные варианты архитектуры почтовой системы домена и способы их интеграции с сервисами RBL/DNSBL.

Почта на хостинге. (click to show/hide)

Характерные черты:

Почтовые сервера принадлежат и администрируются хостинг-оператором.
Почтовая система обслуживает почтовый сервис большого количества доменов одновременно.
Все пользователи почты подключаются к серверам единообразно, в соответствии с рекомендациями оператора.

Начальный и самый простой вариант организации почтовой системы домена. Через него проходит большинство компаний.

. Arch-0

Схема. Корпоративная почта на хостинге.

« Плюсы »:

Почтовая система домена расположена на оборудовании хостинг-оператора.
Отправка и получение E-Mail-корреспонденции, единообразна для всех пользователей домена и не зависит от территориального расположения пользователя.
Проблема спама для пользователей почты такого домена, как правило, отсутствует, либо ее решают средствами и способами, предлагаемыми хостинг-оператором с приемлемой эффективностью.

« Минусы »:

Размер почтового ящика пользователя ограничен хостинг-оператором, и как правило, невелик. Это вынуждает некоторых пользователей использовать протокол POP3. В результате архив почты на хостинге не сохраняется, что при WEB-доступе к почтовому ящику не позволяет видеть всю историю переписки.
Использование своих инструментов и сервисов для фильтрации спама невозможно. Инструментарий управления почтой домена полностью зависит от хостинга.

Использование RBL/DNSBL сервиса:

Использование сервисов RBL/DNSBL жестко регламентировано хостингом. Чаще всего, использование не предусмотрено.
Если сервисы RBL/DNSBL и предлагаются, то их список, как правило, един для всей почтовой системы хостинга. Эффективность предлагаемых сервисов низкая. Использование сервисов RBL/DNSBL, в первую очередь, не должно создавать проблем клиентам хостинга и только во вторую, обеспечивать фильтрацию спама.

Настройка DNS зоны домена:

Необходимо указать :

MX-записи, которые ссылаются на почтовые сервера хостинг-оператора.
SPF-запись, которая ссылается/включает SPF-записи основного домена хостинг-оператора.

Как правило, эти записи заносятся в зону автоматически, при ее создании.

Более полное описание технологии использования RBL/DNSBL в сложных почтовых системах см. ниже.

Почтовый сервер(а) на территории компании. Внешних пользователей почты нет. (click to show/hide)

Характерные черты:

Все пользователи почтовой системы домена расположены в локальной сети компании (LAN).
Внешние пользователи почтового сервиса, либо подключаются к LAN компании по VPN, либо пользуются WEB-доступом.

Тупиковый вариант реализации почты домена. Компании из него быстро вырастают, лучше сразу строить универсальную почтовую систему.

. Arch-1

Схема. Почтовые сервера расположены на территории компании.

На хостинге вспомогательный Relay.

« Плюсы »:

Почтовая система домена, расположена на территории и под контролем компании.
Возможность гибкой настройки почтовой системы. В том числе различных антиспамов и антивирусного ПО.
Почтовый сервер хостинг-оператора не используется или используется как вспомогательный Relay для входящей почты, а так же, в некоторых случаях, и для исходящей корреспонденции.
Размер почтового ящика пользователя определяется внутренней политикой компании. На сервере используется POP3, IMAP и WEB доступ к почтовому ящику.

« Минусы »:

Для сопровождения E-Mail-сервера необходим администратор(ы) и технические ресурсы (сервер, питание, надежные коммуникации и т.д.).
При использовании технологии RBL/DNSBL, пользователи E-Mail вне LAN и не подключенные к офисной сети по VPN могут пользоваться только WEB-почтой. Использование SMTP протокола для отправки корреспонденции затруднительно, т.к. большинство пользователей подключается с динамических адресов разных интернет провайдеров, которые блокируются большинством RBL/DNSBL.

Использование RBL/DNSBL сервиса:

Использовать сервисы RBL/DNSBL тривиально. Достаточно задать их параметры в соответствующих настройках почтового сервера.

Настройка DNS-зоны домена:

MX-записи, которые ссылаются на почтовые сервера компании.

Если почтовая система хостинга поддерживает функцию пересылки корреспонденции, то ее можно указать как вспомогательный сервер приема корреспонденции, на период недоступности почтовых серверов компании (аварийный случай).

SPF-запись, которая указывает политику домена относительно почты.

Если используются дополнительные RELAY-сервера, которые задействованы только в отправке корреспонденции (доп. офисы, рассылка уведомлений, маркетинговые системы и т.п.), то их необходимо так же указать в SPF-записи, как доверенные.

Для всех серверов, занятых в отправке корреспонденции, необходимо задать PTR-записи, которые однозначно связывают их с вашим доменом.

Эти записи необходимы для прохождения проверки обратной зоны, которая используется практически на всех современных почтовых системах.

Более полное описание технологии использования RBL/DNSBL в сложных почтовых системах см. ниже.

Универсальная архитектура почтовой системы компании. (click to show/hide)

Характерные черты:

Территориальное расположение пользователей почты не регламентировано, либо определяется внутренней политикой и правилами компании.
Почтовая система обеспечивает единообразный доступ всем пользователям почтовой системы домена, как внутри локальной сети компании, так и вне ее.
Пользователи, для доступа к почте, могут использовать любое доступное ПО (Web, MS Outlook, Mozilla Thunderbird и др.).

Данный вариант организации почтовой системы домена наиболее гибкий и функциональный.

. Arch-2

Схема. Универсальная архитектура почтовой системы.

ВАЖНО ПОНИМАТЬ, что работа электронной почты состоит из трех связанных, но обособленных этапов:

Прием входящей корреспонденции с почтовых серверов других доменов.

За прием корреспонденции отвечает сервер входящей почты, т.е. сервера указанные в MX-записях DNS-зоны домена (на рис. cервер MX).

ВНИМАНИЕ: Сервер входящей корреспонденции не должен принимать прямые подключения конечных пользователей почты доменов, которые он обслуживает.

Отправка пользователями исходящей корреспонденции.

Отправка осуществляется с почтового клиента или WEB-клиента, по протоколу SMTP на сервер исходящей почты MTA (MTA — Mail Transfer Agent), который в свою очередь осуществляет ее доставку на почтовые сервера доменов назначения (на рис. сервер SMTP), как частный случай, пересылает ее на MX-сервер домена, подобная операция позволяет упростить настройку домена, но повышает нагрузку на MX-сервер.

SMTP-сервер, если он не пересылает сообщения на другой доверенный Relay (например: на сервер MX), а занимается доставкой сообщений самостоятельно, должен быть указан в SPF-записи DNS-зоны домена, т.е. быть заявлен как доверенный отправитель электронной корреспонденции домена.

ВНИМАНИЕ: Сервер исходящей корреспонденции, принимает прямые подключения конечных пользователей почты и выполняет Relay их отправлений. Получением и доставкой входящей, для домена, корреспонденцией он не занимается.

Доступ пользователя к корреспонденции на сервере.

Получение и просмотр корреспонденции осуществляется по протоколам WEB / POP3 / IMAP (на рис. сервер Web / IMAP / POP3).

ВНИМАНИЕ: При использовании сервисов RBL/DNSBL совмещение серверов входящей и исходящей корреспонденции, т.е. серверов MX и SMTP (см. рис.) — НЕДОПУСТИМО. Все остальные вариации совмещения и разнесения серверов входящей и исходящей корреспонденции, а так же доступа к почтовым ящикам, на усмотрения администратора почтовой системы.

ЧАСТНЫЙ СЛУЧАЙ: когда почтовый сервер один, но необходимо выполнить формальное разделение MX и SMTP серверов.

Для решения задачи используется обычный TCP/IP Redirector (redir, tcpredir, pen и т.п.). Основная цель, перенаправить подключение клиента на почтовый сервер MX, с адреса, гарантировано не блокируемого сервисами RBL/DNSBL. Обычно редиректор устанавливается на сам почтовый сервер или соседний сервер (например: Proxy).

ВАЖНО ПОМНИТЬ:

Для внешних пользователей в качестве сервера исходящей почты указывается адрес и порт редиректора.

Так, если адресов у компании немного, то можно использовать адрес основного почтового сервера, но не стандартный порт, например: порт 2525.

Если используется дополнительный адрес, то порт лучше оставить стандартный — 25-ый.

Подключение внешних пользователей, при отправке корреспонденции, проходит через редиректор, с адреса который на почтовом сервере исключен из списка клиентских адресов (т.е. с него не допускается отправка корреспонденции, на внешние или все домены, без авторизации), но при этом, он не попадает в блокируемые сервисами RBL/DNSBL адресные диапазоны.
Если редиректор устанавливается на почтовый сервер, то нужно учитывать, что большинство MTA все свои локальные адреса считают доверенными, и не все MTA позволяют изменить статус этих адресов до уровня требующего авторизации. Т.о. поспешная установка редиректора на почтовый сервер, может превратить его во Free Relay.