Шрифт:
Закладка:
Проще всего установить транспортное соединение между компьютером-источником и компьютером-получателем, а затем передать по нему сообщение. Так изначально и работал протокол SMTP. Однако со временем возникли два разных способа его применения. Первый — подача почтового сообщения, шаг 1 в архитектуре e-mail на илл. 7.9. Так пользовательские агенты передают данные в почтовую систему для их дальнейшей отправки. Вторым способом является пересылка сообщений между агентами передачи сообщений (шаг 2 на илл. 7.9). Такая последовательность обеспечивает доставку почты на всем пути от отправляющего до получающего агента передачи сообщений за один шаг. Окончательная доставка происходит при участии других протоколов, которые мы опишем в следующем разделе.
В этом разделе мы расскажем об основах SMTP и механизме его расширения. Затем мы обсудим разные способы его использования для подачи почты и передачи сообщений.
SMTP и его расширения
В интернете для доставки электронной почты компьютер-источник устанавливает TCP-соединение с портом 25 компьютера-получателя. Этот порт прослушивается почтовым сервером, который поддерживает простой протокол передачи электронной почты (Simple Mail Transfer Protocol, SMTP). Сервер проверяет безопасность входящих соединений, утверждает их и принимает сообщения для передачи. Если письмо невозможно доставить, отправителю возвращается отчет об ошибке, в котором содержится первая часть этого письма.
SMTP представляет собой простой ASCII-протокол. Это не недостаток, а его характерная особенность. Использование текста в формате ASCII позволяет легко модифицировать, тестировать и исправлять ошибки в протоколах. Они могут тестироваться отсылкой команд вручную, при этом записи сообщений легко читать. Сейчас так работает большинство интернет-протоколов прикладного уровня (например, HTTP).
Разберем простую передачу сообщений между почтовыми серверами, которые их доставляют. Установив TCP-соединение с портом 25, передающий компьютер, выступающий в роли клиента, ждет запроса принимающего компьютера, работающего в режиме сервера. Сервер начинает диалог с того, что отсылает текстовую строку с его идентификатором и информацией о том, готов ли он к приему почты. Если нет, клиент разрывает соединение и повторяет попытку позднее.
Если сервер готов принимать почту, клиент сообщает, от кого она поступила и кому предназначается. Если такой получатель существует на этом направлении, сервер дает клиенту добро на пересылку сообщения. Тогда клиент отправляет его, а сервер подтверждает его получение. Контрольные суммы не проверяются, так как TCP обеспечивает надежный байтовый поток. Если у отправителя есть еще почта, она также отсылается. После передачи всей почты в обоих направлениях соединение разрывается. Пример такого диалога представлен на илл. 7.16. Здесь строки, отправленные клиентом (то есть отправителем), снабжены префиксом C:. Строки, отправленные сервером (то есть получателем), снабжены префиксом S:.
Сначала клиент, естественно, отправляет серверу приветствие — HELO. Это наиболее удачный вариант сокращения слова HELLO до четырех символов. Зачем все эти команды нужно было сокращать до четырех символов, сейчас уже никто не помнит.
В нашем примере сообщение нужно отправить только одному получателю, поэтому используется только одна команда RCPT (от слова «recipient» — «получатель»). Использование этой команды несколько раз позволяет отослать одно сообщение ряду получателей. Каждая передача подтверждается или отвергается индивидуально. Даже если не получится передать сообщение некоторым получателям (из-за их отсутствия на этом направлении), сообщение все равно может быть доставлено по остальным адресам.
Наконец, несмотря на то что синтаксис четырехсимвольных команд строго определен, синтаксис ответов не столь строг. Ограничен только числовой код в начале строки. Все, что следует за этим кодом, может считаться комментарием и зависит от конкретной реализации протокола.
Базовый протокол SMTP хорошо работает, но имеет ряд ограничений. Прежде всего, он не предусматривает аутентификации. Это означает, что команда FROM в нашем примере может отобразить какой угодно адрес отправителя, что крайне удобно для рассылки спама. Еще одно ограничение протокола — он позволяет передавать сообщения в кодировке ASCII, но не бинарные данные. Именно поэтому для передачи MIME-контента приходилось использовать кодировку base64. Однако применение base64 при передаче почты ведет к неэффективному использованию пропускной способности, что становится проблемой в случае больших сообщений. Третье ограничение SMTP заключается в том, что он отсылает сообщение в незашифрованном виде. То есть сообщения никак не защищены от посторонних глаз.
S: 220 ee.uwa.edu.au - служба SMTP готова
C: HELO abcd.com
S: 250 cs.uchicago.edu приветствует ee.uwa.edu.au
C: MAIL FROM: <[email protected]>
S: 250 подтверждаю отправителя
C: RCPT TO: <[email protected]>
S: 250 подтверждаю получателя
C: DATA
S: 354 Отправляем письмо, завершая его символом ".", расположенным в отдельной строке
C: From: [email protected]
C: To: [email protected]
C: MIME-Version: 1.0
C: Message-Id: <[email protected]>
C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm
C: Subject: Земля обошла вокруг Солнца целое число раз
C:
C: Это преамбула. Пользовательский агент игнорирует ее. Хорошего дня.
C:
C: --qwertyuiopasdfghjklzxcvbnm
C: Content-Type: text/html
C:
C: <p>С днем рожденья тебя!
C: С днем рожденья тебя!
C: С днем рождения, дорогой <bold>Боб</bold>!
C: С днем рожденья тебя!
C:
C: --qwertyuiopasdfghjklzxcvbnm
C: Content-Type: message/external-body;
C: access-type="anon-ftp";
C: site="bicycle.cs.uchicago.edu";
C: directory="pub";
C: name="birthday.snd"
C:
C: content-type: audio/basic
C: content-transfer-encoding: base64
C: --qwertyuiopasdfghjklzxcvbnm
C: .
S: 250 сообщение принято
C: QUIT
S: 221 ee.uwa.edu.au разрывает соединение
Илл. 7.16. Передача сообщения от [email protected] для [email protected]
Чтобы справиться с этими и многими другими проблемами, связанными с передачей сообщений, к SMTP было добавлено расширение. Оно является обязательной частью стандарта RFC 5321. Использование SMTP с расширениями называется расширенным SMTP (Extended SMTP, ESMTP).
Клиенты, желающие применить ESMTP, на первом этапе высылают EHLO вместо HELO. Если этот вариант отвергается, сервер работает с обычным SMTP, а пользователь должен идти по стандартному пути. Если EHLO принимается, сервер сообщает, какие расширения он поддерживает. После этого клиент может использовать любое из них. Несколько стандартных расширений показаны на илл. 7.17. В таблице даны ключевые слова, в том виде, в каком они используются в механизме расширения, и описание нового функционала. Более подробно рассматривать расширения мы не будем.
Ключевое слово
Описание
AUTH
Аутентификация клиента
BINARYMIME
Сервер принимает бинарные сообщения
CHUNKING
Сервер принимает большие сообщения по частям
SIZE
Проверка размера сообщения перед попыткой отправки
STARTTLS
Переключение на безопасный канал (TLS; см. главу 8)
UTF8SMTP
Интернационализированный адрес
Илл. 7.17. Некоторые расширения SMTP
Чтобы лучше понять, как работает SMTP и другие рассмотренные в этой главе протоколы, попробуйте поработать с ними самостоятельно. Для начала найдите компьютер, подключенный к интернету. В системе UNIX (или Linux) наберите в командной строке:
telnet mail.isp.com 25
подставив вместо mail.isp.com DNS-имя почтового сервера провайдера. На компьютерах с Windows сначала, возможно, потребуется установить и запустить программу telnet (или ее
