Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

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

108

ОБРАЗОВАТЕЛЬНАЯ АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ВОЛЖСКИЙ УНИВЕРСИТЕТ ИМ. В.Н. ТАТИЩЕВА»

(ИНСТИТУТ)

Кафедра «Информатика и системы управления»

Допустить к защите

Зав. кафедрой, д.т.н., профессор

________________ С. В. Краснов

«____»________________ 2011 г.

ДИПЛОМНЫЙ ПРОЕКТ

по специальности 230101.65

«Вычислительные машины, комплексы, системы и сети»

на тему

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

Студент группы ИС-503

_________________ А.А. Левченко

Руководитель дипломного проекта

старший преподаватель кафедры ИиСУ

_________________ Н.В. Калягина

г.о. Тольятти 2011 г.

ОАНО ВПО Волжский университет имени В.Н. Татищева (институт)

Факультет «Информатика и телекоммуникации»

Кафедра «Информатика и системы управления»

УТВЕРЖДЕНО

заседанием кафедры

протокол №___от___________2011г.

Зав. кафедрой, д.т.н., профессор

____________________ С.В. Краснов

«___»______________2011г.

ЗАДАНИЕ НА ДИПЛОМНЫЙ ПРОЕКТ

Студенту ___Левченко Александру Александровичу_______________________

группы ИС-503

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

Приказ на утверждение темы дипломного проекта ректора Волжского университета им В.Н. Татищева № _____ от ____________________________

Цель и задачи дипломного проекта: Разработать корпоративную почтовую систему для типовой организации ОАНО ВПО ВУиТ. Основные задачи: централизованный доступ сотрудников к электронной почте, а также обеспечения безопасности почтовых сервисов внутри организации.

Исходные данные:

Технические требования для создания почтового сервера, описанные в техническом задании. Спецификации свободного программного обеспечения, описанные в Single UNIX Specification, Version 4. Также RFC, касающиеся стандартов электронной почты, в частности SMTP, POP3, TLS и ISO|IEC по вопросам информационной безопасности.

Содержание

Введение

Техническое задание

Введение

1 Основание для разработки

2 Источники разработки

3 Технические требования

3.1 Состав изделия

3.2 Технические параметры

3.3 Принцип работы

3.4 Требования к надежности

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

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

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

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

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

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

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

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

1.1.3 Протокол SMTP

1.1.4 Транспортировка сообщений

1.1.5 Доставка почтовых сообщений

1.1.6 Форматы серверных почтовых хранилищ

1.1.7 Организация доступа к серверным хранилищам

1.1.8 Получение сообщений

1.2 Технология DNS

1.3 Способы организации базы данных сообщений

1.4 Способы организации безопасности среды

1.4.1 Организация безопасности средствами операционной системы

1.4.2 Повышенная безопасность с использованием антивирусной защиты

1.4.3 Защита переписки криптографическими средствами

1.5 Технология кластеризации

1.6 Требования к программной части

1.7 Требования к аппаратной части

2 Проектирование корпоративной почтовой системы

2.1 Обоснование выбора DNS-сервера на основе BIND

2.2 Обоснование выбора агента передачи почты Postfix

2.2.1 Основные подсистемы Postfix

2.2.2 Демоны Postfix

2.2.3 Подсистема обработки входящих сообщений

2.2.4 Подсистема доставки почтовых сообщений

2.2.5 Управление очередями сообщений

2.2.6 Вспомогательные утилиты

2.2.7 Описание основных конфигурационных файлов Postfix

2.3 Сервер доставки почты MDA Dovecot

2.4 Обоснование выбора службы каталогов OpenLDAP в качестве базы данных

2.5 Обеспечение безопасной работы в почтовой системе

2.6 Организация кластера на основе Linux-HA

2.6.1 Программный пакет DRBD

2.6.2 Программный пакет Heartbeat

2.7 Обоснование выбора оборудования для почтового сервера

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

3 Реализация корпоративной почтовой системы

3.1 Этапы установки и настройки компонент почтвой системы

3.1.1 Установка и настройка DNS-сервера BIND

3.1.2 Установка и конфигурация компонентов почтового сервера

3.2 Тестирование почтовой системы

3.2.1 Тестирование DNS-сервера

3.2.3 Тестирование спам-фильтра

3.2.4 Тестирование SSL

4 Оценка показателей качества и расчет общей стоимости владения почтовой системой

4.1 Оценка показателей качества

4.2 Расчет общей стоимости владения почтовой системой

4.3 Расчет стоимости теоретического проекта вычислительной системы

4.4 Расчет стоимости технического проекта вычислительной системы

4.5 Расчет стоимости внедрения вычислительной системы

4.6 Расчет стоимости эксплуатации вычислительной системы

4.7 Общая стоимость владения вычислительной системой

5 Раздел безопасности жизнедеятельности

5.1 Требования безопасности при эксплуатации видеодисплейных терминалов (ВДТ) и персональных электронно- вычислительных машин (ПЭВМ)

5.2 Охрана труда для операторов и пользователей персональных электронно-вычислительных машин (ПЭВМ)

5.2.1 Общие положения

5.2.2 Требования безопасности перед началом работы

5.2.3 Требования безопасности во время работы

5.2.4 Требования безопасности в аварийных ситуациях

5.2.5 Требования безопасности после окончания работы

5.3 Выводы по разделу

Заключение

Список используемой литературы

Приложение А

Приложение Б

Приложение В

Введение

Современный мир невозможно представить без электронной почты. Сотни миллионов почтовых ящиков, триллионы сообщений ежегодно, терабайты данных ежедневно. Адрес электронной почты стал для современного общения столь же обязательным, как домашний адрес и номер телефона, а нередко он заменяет их.

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

Для построения качественного почтового сервиса необходима надежная, удобная система, а также качественное и совместимое с ней программное обеспечение. В настоящее время существует достаточно много реализаций почтового сервера, а также всех необходимых компонент для обеспечения безопасной и удобной работы, как пользователей, так и администраторов системы. Множество крупных компаний, таких как Intel, Oracle, Sun рекомендуют свободные проекты, специализированные для корпоративных систем. Конечной целью данного проекта является реализация почтового сервера на базе высокодоступного кластера для обеспечения качественного, быстрого решения, а также минимизации затрат за счет выбранных технических средств и свободных лицензий на распространение программного обеспечения.

Почтовый сервер, как правило, требуется организациям с большим количеством сотрудников, где внутренняя почтовая служба является неотъемлемой частью бизнес-процессов. Располагая бизнес-переписку на «чужом» сервере, арендатор услуги рискует потерей секретности: ведь информация находится во владении (и в свободном доступе) со стороны третьих лиц и может быть разглашена (или передана) без ведома владельца почтового ящика. Вот почему для вящей безопасности даже владельцы фирм, в которой насчитывается менее 10 сотрудников, нередко предпочитают организовать собственную почтовую систему, находящуюся под контролем ответственного персонала. Вторым немаловажным поводом для внедрения такого сервиса считают независимость от провайдера и его канала: например, при переезде компании в другой офис, или при вынужденной смене провайдера, или при временной утрате основного канала и переходе на резервный сохраняется и доступ к архиву переписки, и возможность обмена сообщениями внутри компании.

Внедрение коммерческого ПО обычно сопровождается не только затратами на покупку самого продукта, но также на тех. поддержку и лицензии на использование, а в некоторых случаях даже на обновление. При выборе проприетарного ПО тоже есть свои минусы, и состоят в том что программу нельзя изменить под свои нужды, так как право на изменение имеет только правообладатель, к тому же свободное ПО разрабатывается с учетом того, что открытые стандарты должны быть наименее подвержены уязвимостям, чтобы каждая программа работала хорошо, что соответствует философии UNIX. Так как проприетарные решения обычно не дают возможности построения гибкой системы, выбор остается за свободными продуктами и открытыми стандартами. Создание почтового сервера на базе Linux обеспечивает гибкость решения: из блоков создается конфигурация, отвечающая любым запросам пользователя.

ОБРАЗОВАТЕЛЬНАЯ АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ВОЛЖСКИЙ УНИВЕРСИТЕТ ИМ. В.Н. ТАТИЩЕВА»

(ИНСТИТУТ)

Кафедра «Информатика и системы управления»

СОГЛАСОВАНО: УТВЕРЖДАЮ:

Руководитель дипломного проекта Зав. кафедрой ИиСУ

ст. преподаватель кафедры ИиСУ д.т.н., профессор

____________ Н.В. Калягина ____________ С.В. Краснов

«___»______________2011г. «___»______________2011г.

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

Техническое задание

Листов: 4

Разработал:

студент группы ИС – 503

___________А. А. Левченко

«___»______________ 2011г.

Тольятти, 2011 г.

Техническое задание

Введение

Настоящее техническое задание распространяется на разработку корпоративной почтовой системы для типовой организации ОАНО ВПО ВУиТ.

Почтовая система предназначена для организации и автоматизации документооборота, оперативного обмена информацией внутри сети, защищенной деловой переписки.

1 Основание для разработки

Основанием для разработки почтовой системы является задание на дипломное проектирование, утверждённое приказом ВУиТ № ___ от «__» марта 2011 г.

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

2 Источники разработки

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

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

2. RFC 1939 – Post Office Protocol - Version 3 – протокол почтового отделения, версия 3, используется почтовым клиентом для получения сообщений электронной почты с сервера.

3. RFC 2505 – Anti-Spam Recommendations

4. RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.

5. ISO|IEC 17799:205 – информационные технологии, методы обеспечения безопасности. Правила управления информационной безопасностью.

6. СанПиН 2.2.2.542-96.

3 Технические требования

3.1 Состав изделия

В состав готового программного решения будут входить следующие компоненты:

операционная система CentOS 5.6;

DNS-сервер BIND 9.8;

агент передачи сообщений Postfix 2.8;

протокол доступа к каталогам OpenLDAP 2.4;

IMAP/POP3-сервер Dovecot 1.2;

антивирус Clam Antivirus 0.9;

smtp-фильтр ClamSMTP 1.1;

спам-фильтр SpamAssasin 3.3;

криптографический протокол OpenSSL 1.0;

программный пакет DRBD 8.3;

сервис Heartbeat 2.1.

3.2 Технические параметры

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

3.3 Принцип работы

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

3.4 Требования к надежности

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

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 <[email protected]>

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

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: [email protected]

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 <[email protected]>

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

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: [email protected]

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: [email protected]

250 Ok

RCPT TO: [email protected]

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:<[email protected]> SIZE=361

Response: 250 2.1.0 <[email protected]>... 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 <[email protected]>; 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: [email protected]

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 - тот же самый, что и для обмена незашифрованными сообщениями. Зашифрованное сообщение имеет следующий вид:

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