Корпоративная почтовая система на базе высокодоступного кластера

3.5 Условия эксплуатации

1. При использовании почтовой системы следует распределить права пользователей, групп и доверенных сетей.

2. Помещения для ПЭВМ  должны иметь естественное и искусственное освещение согласно СанПиН 2.2.2.542-03.

3.6 Требования безопасности

При организации почтовой системы следует обеспечить защиту передаваемой информации и базы данных пользователей. Данные шифруются криптографическим алгоритмом TLS/SSL. Аутентификация происходит через базу пользователей LDAP. Помимо этого следует учесть особенности среды Linux, изолированное окружение по средствам операции chroot, а также ограничения прав пользователей по средствам программы chmod.

4 Экономические показатели

Использование собственного почтового сервера на основе свободных программных продуктов позволит:

1.      Повысить эффективность информационной структуры в целом.

2.      Уменьшить затраты, так как распространяется бесплатно.

3.      Уменьшит затраты на пользование другими сервисами.

4.      Улучшит надежность, хранение и удобство деловой переписки.

5 Порядок испытаний

Тестирование почтовой системы проводится поэтапно рядом проверок:

1. Проверка доставки, получения писем внутри локальной сети и Интернет.

2. Проверка входящих сообщений на фильтрацию спама.

3. Проверка работы антивируса, путём сканирования входящих и исходящих сообщений.

4. Проверка отказоустойчивости организованного кластера в случае выхода из строя одного из серверов, входящих в кластер.

1 Анализ программных средств и технологий

1.1 Принципы работы электронной почты

Главной отличительной чертой почтовой системы, построенной на открытом программном обеспечении, является ее модульность. Отдельные компоненты являются взаимозаменяемыми, для каждого компонента существует несколько реализаций. Замена компонентов, предназначенных для одной цели, в большинстве случаев проблемой не является: базовая функциональность заменяемых компонентов в целом одинакова, настройки и данные тоже, как правило, можно перенести, а иногда даже использовать без изменения. На рисунке 1.1 представлена общая схема взаимодействия основных компонентов.

Рисунок 1.1 – Принципиальная схема работы электронной почты и способы взаимодействия между ее основными компонентами

1.1.1 Создание почтового сообщения

С точки зрения пользователя почтовой системы существует только один компонент - это MUA (Mail User Agent), или, другими словами, его почтовый клиент (Mozilla, Outlook, The Bat!, KMail, mutt, pine, mailx, а также Web-приложения аналогичного назначения), предназначенный для создания, отправки, получения и чтения почтовых сообщений.

Формат почтовых сообщений описан в RFC 2822 (Internet Message Format) и в серии RFC с 2045 по 2049, которые посвящены формату MIME - Multipurpose Internet Mail Extensions (Format of Internet Message Bodies, Media Types, Message Header Extensions for Non-ASCII Text, Registration Procedures, Conformance Criteria and Examples).

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

Следующие заголовки считаются обязательными:

1. From - адрес и, возможно, полное имя отправителя.

2. To - адрес и, возможно, полное имя того, кому адресовано письмо (адресатов может быть несколько).

3. Subject - тема письма

4. Date - локальные дата и время отправления письма.

Другими часто используемыми заголовками являются:

1. Сс (carbon copy) - кому отправить копию письма (адресатов может быть несколько), при этом и основному адресату, и дополнительным, будет об этом известно.

2. Received - путь прохождения письма.

3. Content-Type - информация о том, каким образом письмо должно быть отображено.

Имена заголовков могут содержать только 7-битные ASCII-символы. Значения заголовков не ограничены символами ASCII, но при наличии не ASCII-символов они должны использовать MIME-кодирование в форме "=?charset?encoding?encoded text?=".

Существуют следующие типы кодирования:

­         7bit – до 998 октетов на строку из диапазона [1..127]\{CR, LF}. Используется по умолчанию;

­         quoted-printable – используется в первую очередь для US-ASCII-символов, но также содержит символы из других диапазонов;

­         base64 – используется для двоичных данных;

­         8bit - до 998 октетов на строку из диапазона [1..255]\{CR, LF}. Этот тип кодирования в заголовках почтовых сообщений использовать нежелательно, о причинах мы поговорим позже;

­         binary – произвольная последовательность октетов (фактически отсутствие какого бы то ни было кодирования). Этот тип кодирования использовать нельзя.

Точно таким же образом кодируется тело письма, при этом кодировка и тип кодирования указывается в заголовках Content-Type и Content-Transfer-Encoding. Ниже представлено правильно оформленное письмо. Текст с техническими заголовками письма, оформленный по всем требованиям для корректной доставки.

Message-ID: <436F19FC.7050901@mail.domain1.com>

Date: Mon, 07 Nov 2005 12:10:20 +0300

From: User 1 <user1@domain1.com>

User-Agent: Mozilla Thunderbird 0.6 (X11/20040511)

X-Accept-Language: en-us, en

MIME-Version: 1.0

To:  user2@domain2.com

Subject: =?KOI8-R?Q?=F4=C5=D3=D4?=

Content-Type: text/plain; charset=KOI8-R; format=flowed

Content-Transfer-Encoding: 8bit

Привет!

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

Message-ID: <436F2097.5060703@mail.domain1.com>

Date: Mon, 07 Nov 2005 12:38:31 +0300

From: User 1 <user1@domain1.com>

User-Agent: Mozilla Thunderbird 0.6 (X11/20040511)

X-Accept-Language: en-us, en

MIME-Version: 1.0

To:  user2@domain2.com

Subject: =?KOI8-R?Q?=F4=C5=D3=D4?=

Content-Type: multipart/mixed;

boundary="------------070102080309020306010600"

This is a multi-part message in MIME format.

--------------070102080309020306010600

Content-Type: text/plain; charset=KOI8-R; format=flowed

Content-Transfer-Encoding: 8bit

Привет!

--------------070102080309020306010600

Content-Type: text/plain;

name="file.txt"

Content-Transfer-Encoding: 7bit

Content-Disposition: inline;

filename="file.txt"

Text file content

--------------070102080309020306010600--

1.1.2 Отправка почтового сообщения

После создания сообщения MUA должен передать его MSA (Mail Submission Agent). В RFC 2476 (Message Submission) MSA описан как сервис, принимающий клиентские подключения на порту 678 по TCP/IP, и выполняющий первичную проверку почтовых сообщений на соответствие стандартам, авторизацию пользователей и блокирование UCE (Unsolicited Commercial Email – чаще нежелательная корреспонденция обозначается словом «спам») еще на этапе отправки. Затем MSA должен передать письмо MTA (Mail Transfer Agent) - сервису, принимающему клиентские подключения на порту 25 по TCP/IP, который, в свою очередь, уже должен заняться доставкой письма непосредственно адресату. И в первом, и во втором случае должен использоваться протокол SMTP, описанный в RFC 2821 (Simple Mail Transfer Protocol) и RFC 1869 (SMTP Service Extensions), но MUA и MTA не должны общаться напрямую друг с другом.

На практике отдельных реализаций MSA не существует, а большинство реализаций MTA способны также выполнять функции MSA. Более того, для MSA практически никогда не конфигурируется порт 678, а все почтовые сообщения от MUA принимаются непосредственно на порт 25.

Поведение MTA после того, как он получил почтовое сообщение от MUA или MSA, зависит от настроек самого MTA, а также от домена, которому принадлежит почтовый адрес получателя. В простейшем случае (в отсутствии постоянного подключения к Интернет, постоянного реального ip-адреса и dns-имени – в сегодняшних реалиях такое происходит довольно редко) MTA вообще не берет на себя ответственность за пересылку письма, а просто отдает ее вышестоящему MTA, который для него является релеем (relay – MTA, через который производится пересылка). Релей может определить список сетей/хостов и/или список логинов/паролей, которым разрешено пересылать через него свои почтовые сообщения. Домены, обслуживаемые релеем, как правило, являются исключением: для них сообщения принимаются от кого угодно.

Релей, не устанавливающий никаких ограничений на пересылку почтовых сообщений, называется открытым релеем (open relay). Недостатками таких релеев являются:

­         их услугами начинают активно пользоваться спамеры;

­         релей попадает в какой-либо черный список, и все MTA, выполняющие фильтрацию по черным спискам (а их сейчас большинство), перестают принимать от него почтовые сообщения.

МТА, принимающий на себя ответственность за пересылку, сначала проверяет, обслуживает ли он домен адресата. В случае отрицательного решения MTA предпринимает попытку найти другой MTA, обслуживающий этот домен. Для этого он с помощью DNS-запроса получает список MX-записей домена, каждая из которых содержит приоритет в виде целого числа - чем оно меньше, тем MTA «главнее». В первую очередь предпринимается попытка отправить почтовое сообщение на главный MTA домена, а в случае его недоступности - по очереди на следующие за ним по приоритету (резервные) до тех пор, пока сообщение не будет отправлено. Резервные MTA могут передать сообщения на главный после восстановления его работоспособности, а могут выполнить доставку сообщения в почтовый ящик адресата самостоятельно.

1.1.3 Протокол SMTP

SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты) – это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты, почтовый клиент должен использовать протоколы POP3 или IMAP. Работа с SMTP происходит непосредственно на сервере получателя. Поддерживает функции: установление соединения, аутентификация, передача данных.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).

Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя.

Sendmail был одним из первых агентов отправки сообщений, который начал работать с SMTP. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы.

Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст. В качестве примера ниже представлена простая telnet-сессия с использованием протокола SMTP.

# telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 mail.domain1.com ESMTP Postfix

EHLO host1.domain1.com

250-mail.domain1.com

250-PIPELINING

250-SIZE 10240000

250-ETRN

250-STARTTLS

250-AUTH PLAIN

250 8BITMIME

MAIL FROM: user1@domain1.com

250 Ok

RCPT TO: user2@domain2.com

250 Ok

DATA

354 End data with <CR><LF>.<CR><LF>

Hello!

.

250 Ok: queued as 24D501771C

QUIT

221 Bye

Connection closed by foreign host.

Получив приглашение, входящее сообщение проходит первую проверку с помощью команды EHLO, и в ответ получает список расширений, поддерживаемых тем MTA, к которому прошло подключение, то есть используемого на сервере получателя. Отправитель указывается с помощью команды "MAIL FROM:", а получатель c помощью команды "RCPT TO:". После команды DATA вводится содержимое самого письма и завершается точкой на новой строке. С помощью команды QUIT происходит отключение от MTA.

Требуется соблюдать правила оформления, то есть в сообщение должны быть все вышеперечисленные заголовки, как представленном ниже правильно оформленном сообщения.

Response: 220 mail.domain2.com ESMTP Sendmail 8.13.5/8.13.1; Mon, 7 Nov 2005

16:29:00 +0300 (MSK)

Command: EHLO mail.domain1.com

Response: 250-mail.domain2.com Hello mail.domain1.com [xxx.xxx.xxx.xxx],

pleased to meet you

Response: 250-ENHANCEDSTATUSCODES

Response: 250-PIPELINING

Response: 250-8BITMIME

Response: 250-SIZE

Response: 250-DSN

Response: 250-ETRN

Response: 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN

Response: 250-STARTTLS

Response: 250-DELIVERBY

Response: 250 HELP

Command: MAIL FROM:<user1@domain1.com> SIZE=361

Response: 250 2.1.0 <user2@domain2.com>... Sender ok

Message: Received: from host1 (host1.domain1.com [xxx.xxx.xxx.xxx])

Message:     by mail.domain1.com (Postfix) with ESMTP id 24D501771C

Message:     for <user2@domain2.com>; Mon,  7 Nov 2005 16:30:58 +0300 (MSK)

Message: Message-Id: <20051107133058.24D501771C@mail.domain.com>

Message: Date: Mon,  7 Nov 2005 16:30:58 +0300 (MSK)

Message: From: user1@domain1.com

Message: To: undisclosed-recipients:;

Message:

Message: Hello!

Message: .

Message: QUIT

Response: 250 2.0.0 jA7DT0o5090086 Message accepted for delivery

Response: 221 2.0.0 mail.domain2.com closing connection

Протокол SMTP не позволяет однозначно идентифицировать отправителя сообщения, однако существует возможность потребовать от отправителя авторизоваться - для этого служит расширение AUTH, описанное в RFC 2554 (SMTP Service Extension for Authentication). Для реализации этого расширения MTA используют механизм SASL, описанный в RFC 2222 (Simple Authentication and Security Layer), который позволяет использовать различные способы передачи и хранения логина и пароля, в том числе и те, которые используют не сам пароль, а его хэш.

Существует также возможность шифровать SMTP-трафик с помощью технологий TLS/SSL (Transport Security Layer / Secure Socket Layer), для чего могут использоваться 2 механизма:

­         устаревший протокол SMTPS - фактически это тот же самый SMTP, но шифруется весь трафик, начиная от начального приветствия MTA, при этом используется порт 465;

­         расширение STARTTLS, описанное в RFC 2487 (SMTP Service Extension for Secure SMTP over TLS) - если клиент MTA (MUA, MSA или другой MTA) поддерживают его, при этом используется порт 25 - тот же самый, что и для обмена незашифрованными сообщениями. Зашифрованное сообщение имеет следующий вид: