Схема с выделенным почтовым сервером

Рассмотренная только что простейшая схема почтовой связи кажется работоспособной, однако у нее есть серьезный и очевидный дефект. Мы упоминали, что для обмена сообщениями необходимо, чтобы SMTP-сервер постоянно находился в ожидании запроса от SMTP-клиента. Это означает, что для того чтобы письма, направленные Полине, доходили до нее, ее компьютер должен постоянно находиться в режиме подключения. Понятно, что такое требование для многих пользователей неприемлемо.

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

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

Рис. 1. Схема с выделенным почтовым сервером в принимающем домене

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

1. Итак, пусть Данила решает послать письмо Полине, для чего он запускает на своем компьютере установленную на нем программу почтового клиента (например, Microsoft Outlook или Mozilla Thunderbird). Он пишет текст сообщения, указывает необходимую сопроводительную информацию, в частности адрес получателя polina@bim.com, и щелкает мышью на значке отправки сообщения. Поскольку готовое сообщение должно быть направлено совершенно определенному почтовому серверу, клиент обращается к системе DNS, чтобы определить имя почтового сервера, обслуживающему домен Полины bim. com. Получив от DNS в качестве ответа имя maii.bim.com, SMTP-клиент еще раз обращается к DNS, на этот раз, чтобы узнать IP-адрес почтового сервера mail.bim.com.

2. SMTP-клиент посылает по данному IP-адресу запрос на установление ТСР-соединения через порт 25 (SMTP-сервер).

3. С этого момента начинается диалог между клиентом и сервером по протоколу SMTP, с которым мы уже знакомы. Заметим, что здесь, как и у всех протоколов, ориентированных на передачу, направление передачи запроса от клиента на установление SMTP-соединения совпадает с направлением передачи сообщения. Если сервер оказывается готовым, то после установления TCP-соединения сообщение Данилы передается.

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

5. В какой-то момент, который принципиально не связан с моментом поступления сообщений на почтовый сервер, Полина, запускает свою почтовую программу и выполняет команду проверки почты. После этой команды почтовый клиент должен запустить протокол доступа к почтовому серверу, однако этим протоколом уже не будет SMTP. Напомним, что протокол SMTP используется тогда, когда необходимо передать данные на сервер, а Полине, напротив, нужно получить их с сервера. Для этого случая были разработаны другие протоколы, обобщенно называемые протоколами доступа к почтовому серверу, такие, например, как РОРЗ и IMAP. Оба этих протокола относятся к протоколам, ориентированным на прием данных (протокол РОРЗ ожидает запрос на установление TCP-соединения через порт 110, a IMAP — через порт 143, на рисунке эти порты обобщенно показаны как порт TCP). В результате работы любого из них письмо Данилы оказывается в памяти компьютера Полины. Заметим, что на этот раз направление запроса от клиента к серверу не совпадает с направлением передачи данных, показанному стрелкой.