Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Начиная с этого момента, возможен обмен последовательностями команд, показанными в листинге 7.3, если сервер готов принимать от вас почтовые сообщения.

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

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

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

Эта удаленная коммуникация не вызывает проблемы сама по себе. Именно для подобных случаев был разработан протокол TCP/IP. Однако провайдер или компания обычно без энтузиазма относятся к тому, что у удаленного пользователя будет возможность подавать сообщения на их почтовый сервер для доставки в какое-то иное место. Такой сервер не является общественным. Кроме того, этот вид открытой почтовой станции( open mail relay) привлекает спамеров. Это происходит из-за наличия возможности скрыть настоящего отправителя и таким образом затруднить идентификацию сообщения как спама.

Учитывая эти особенности, SMTP обычно используется для подачи писем с расширением AUTH. Это расширение позволяет серверу проверять данные отправителя (имя пользователя и пароль) для подтверждения того, что сервер должен обеспечить работу с почтой.

Есть еще несколько отличий в том, как SMTP используется при подаче почты. Например, задействуется порт 587, а не порт 25, и SMTP-сервер может проверять и исправлять формат сообщений, отосланных пользовательским агентом. Чтобы узнать больше об использовании SMTP при подаче писем, посмотрите RFC 4409.

Передача сообщений

Когда отсылающий агент передачи почты (сообщений) получает сообщение от пользовательского агента, он доставляет его получающему агенту передачи почты, используя SMTP. Чтобы это сделать, отсылающая сторона использует адрес назначения. Посмотрите на сообщение в листинге. 7.2, адресованное к bob@ee.uwa.edu.au. На какой почтовый сервер оно должно быть доставлено?

Чтобы определить верный почтовый сервер, запрашивается DNS. В предыдущем разделе мы описали то, как в состав DNS входят различные типы записей, включающие запись MX (mail exchanger — запись для обмена почтовыми сообщениями). В этом случае запрос DNS делается для записей MX домена ee.uwa.edu.au. Этот запрос возвращает упорядоченный список имен и IP-адресов одного или более почтовых серверов.

Затем отсылающий агент передачи почты создает TCP-соединение с IP-адресом почтового сервера на порте 25, чтобы связаться с принимающим агентом передачи почты. Для передачи сообщения используется SMTP. Принимающий агент передачи почты затем помещает сообщения для пользователя bob в нужный почтовый ящик, чтобы позднее Боб мог их прочитать. Этот шаг локальной доставки может включать перемещение сообщения между компьютерами, если существует разветвленная почтовая инфраструктура.

При помощи этого процесса доставки почта путешествует от начального до конечного агента передачи почтовых сообщений за один шаг. На этапе передачи сообщения нет промежуточных серверов. Однако этот процесс доставки может повторяться несколько раз. Один из примеров мы уже привели (когда агент передачи сообщений применяет список рассылки). В этом случае сообщение получает список адресатов. Затем оно распадается на сообщения для каждого члена списка и посылается на его индивидуальный адрес.

Еще один пример перенаправления почты выглядит следующим образом: Боб мог закончить Массачусетский технологический институт и, соответственно, быть доступным по адресу bob@alum.mit.edu. Вместо того чтобы собирать почту с разных аккаунтов, Боб может сделать так, чтобы почта, посылаемая на данный адрес, переправлялась на bob@ee.uwa.edu. В этом случае сообщения, отправленные на bob@alum.

mit.edu, будут доставляться дважды. Сначала они будут посылаться на почтовый сервер alum.mit.edu. Затем на сервер ee.uwa.edu.au. Каждый из этих шагов является полноценной отдельной доставкой, если мы рассматриваем их с точки зрения агентов передачи почтовых сообщений.

Также не стоит забывать о спаме. Сегодня девять из десяти отсылаемых сообщений принадлежат именно к этой категории (McAfee, 2010). Мало кто хочет получать подобную почту, но ее сложно избежать, так как нежелательные сообщения маскируются под обычные. До приема сообщения могут быть проведены дополнительные проверки, чтобы сократить возможности спама. Сообщение для Боба было отослано с адреса alice@cs.washington.edu. Принимающий агент передачи почты может обратиться к агенту передачи почты, отправившему сообщение, через DNS. Это позволяет проверить, совпадает ли IP-адрес на другом конце TCP-соединения и DNS-имя. В общем случае, получающий агент может проверить отсылающий домен в DNS и выяснить, придерживается ли он политики отправки почты. Эта информация часто выдается в формате TXT- и SPF-записей. В ней может говориться о том, что возможно проведение и других проверок. Например, почта, посылаемая с cs.washington.edu, может всегда отправляться с хоста june.cs.washington.edu. Если высылающий агент передачи почты не june , возникает проблема.

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

7.2.5. Окончательная доставка сообщений

Наше почтовое сообщение почти доставлено. Оно прибыло в почтовый ящик Боба. Осталось только передать копию сообщения пользовательскому агенту Боба, чтобы оно могло отобразиться. Это шаг 3 в архитектуре на рис. 7.4. Когда пользовательский агент и агент передачи почты работали на одном и том же компьютере и представляли собой всего лишь разные процессы, эта задача была несложной. Агент передачи почты просто писал новые сообщения в конце файла почтового ящика, а пользовательский агент просто проверял файл почтового ящика на наличие новых сообщений.