Россия, Казань, Казанский Национальный Исследовательский Технический Университет |
Протокол SMTP
Поля заголовка Resent-authentic
Поля Resent-authentic определяют отправителя сообщения, которое по какой-либо причине повторно передавалось программой-клиентом. Формат этих полей следующий:
Resent-From: date-time Resent-Sender: date-time
Поля Resent-From: и Resent-Sender: работают подобно полям From: и Sender:. Они лишь отражают, что сообщение было повторно передано клиентом по неизвестной причине.
Поля заголовка Dates
Поля заголовка Dates используются для помещения метки времени в сообщение при передаче его от клиента серверу. Формат полей Dates следующий:
Date: date-time Resent-Date: date-time
Поле Date: (Дата) будет пересылать информацию в заголовке сообщения в точном соответствии с оригиналом сообщения. Этот параметр может оказаться полезным при отслеживании времени получения ответов, в особенности — множественных ответов.
Поля заголовка Destination
В полях заголовка Destination указываются адреса электронной почты получателей сообщения. Эти поля являются чисто информационными. Сервер SMTP в любом случае не будет посылать сообщение в почтовый ящик пользователя, пока на получит команду RCPT, выданную для данного пользователя (см. раздел "Основные команды клиента SMTP"). Формат этих полей следующий:
To: address Resent-To: address CC: address Resent-CC: address BCC: address Resent-BCC: address
Поля To:, CC: и BCC: устанавливают стандартный алгоритм обработки электронной почты. Большинство пакетов для работы с электронной почтой используют именно эту терминологию для классификации получателей сообщения. Поле CC: сходно с памяткой, и указанные в нем получатели должны получить "копию" сообщения. Еще одно новое понятие, введенное системами электронной почты, — BCC: или "невидимая копия" (blind carbon copy). В поле "невидимой копии" также указывается получатель копии сообщения, но его адрес не виден посторонним (это не совсем этично). В связи с этой опцией обсуждалась вопросы компьютерной этики, но на сегодняшний день практически все программы для работы с электронной почтой поддерживают эту возможность.
Необязательные поля заголовка
Необязательными являются поля, которые более подробно идентифицируют сообщение для сервера SMTP, но, согласно RFC 822, могут и не присутствовать в сообщении. Тем не менее эти поля в настоящее время широко распространены, и многим из вас придется столкнуться с ними. Формат некоторых из них следующий:
Message-ID: message-id Resent-Message-ID: message-id In-Reply-To: message-id References: message-id Keywords: text - list Subject: text Comments: text Encrypted: word
Наиболее полезным и часто используемым из этого набора является поле Subject: (Тема). Большинство программ для работы с электронной почтой допускает ввод отправителем темы сообщения в одну строку, которая описывает для получателя содержание сообщения. Эта строка текста довольно часто используется почтовой программой-клиентом при формировании списков полученных сообщений. Еще одно необязательное поле также помогает идентифицировать почтовое сообщение. Это поле Message-ID: (Идентификатор сообщения). В этом поле сообщению присваивается уникальный идентификационный номер, который может затем отображаться в возвращенном сообщении. Специальное поле шифрования Encrypted: указывает, было ли сообщение в целях безопасности подвергнуто шифрованию, а в Keywords: можно задать ключевые слова, которые можно использовать при поиске определенного текста, встречающегося в сообщении (сообщениях).
Использование формата RFC 822 при почтовой операции по протоколу SMTP
Пример почтовой операции по протоколу SMTP с использованием полного формата сообщения согласно RFC 822 представлен в листинге 5.5.
1 [rich@shadrach rich]$ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is '^]'. 5 250 shadrach.smallorg.org Hello localhost [127.0.01], pleased to meet you 6 MAIL FROM:rich@localhost 7 250 rich@localhost... Sender ok 8 RCPT TO:rich 9 250 rich... Recipient ok 10 DATA 11 354 Enter mail, end with "." on a line by itself 12 Return-Path:rich@localhost 13 received: from localhost by localhost with TCP/IP id 1 for Richard Blum 14 Reply-to:rich@localhost 15 From:rich 16 Date:8/27/99 17 To:rich 18 cc:jessica 19 cc:katie 20 bcc:barbara 21 bcc:haley 22 Message-ID:1 23 Sub]ect:Test RFC 822 message 24 25 This is a test message sent from the local host to rich. 26 This message is a little larger, and sweet. 27 . 28 250 PAA02866 Message accepted for delivery 29 QUIT 30 221 shadrach.smallorg.org closing connection 31 Connection closed by foreign host. 32 You have new mail in /var/spool/mail/rich 33 [rich@shadrach rich]$ mail 34 Mail version 8.1.6/6/93. Type ? for help. 35 "/var/spool/mail/rich": 1 message 1 new 36 >N 1 rich@shadrach.smallo Fri Aug 27 18:50 18/622 "Test RFC 822 message" 37 &1 38 Message 1: 39 From rich@smallorg.org Fri Aug 27 18:50:21 1999 40 From: rlch@shadrach.smallorg.org 41 Reply-to: rich@shadrach.smallorg.org 42 Date: 8/27/99 43 To: rich@shadrach.smallorg.org 44 cc: jessica@shadrach.smallorg.org 45 cc: katie@shadrach.smallorg.org 46 Subject: Test RFC 822 message 47 48 This is a test message sent from the local host to rich. 49 This message is a little larger, and sweet. 50 51 &x 52 [rich@shadrach rich]$Листинг 5.5. Пример SMTP операции с сообщением в формате RFC 822
Этот пример сходен с тем, что представлен в листинге 5.2, но обратите внимание на отличия между ними. Строки 12–23, согласно RFC 822, отображают поля заголовков, которые были использованы в сообщении. В строке 36 показано, что программа для чтения электронной почты использует поле Subject: для краткого описания содержания сообщения. Строки 39–46 отображают поля заголовка, в том порядке, в котором они выводятся на экран программой для чтения почтовых сообщений. Обратите внимание на отсутствие полей BCC:. Поля BCC: используются только для идентификации "невидимых" копий. Те получатели сообщения, о которых другим получателям знать не следует, получают копии сообщения (немного путано, не правда ли?). Это имеет смысл для программы чтения почтовых сообщений, поскольку эти поля не отображаются в ней. Еще одна очевидная разница заметна в строке с датой. В строке 28 листинга 5.2 указывается полная дата, которая автоматически добавляется программой для работы с электронной почтой. В строке 42 листинга 5.5, согласно RFC 822, отображается дата, установленная в сообщении. Данный пакет для работы с электронной почтой позволяет полям, которые соответствуют RFC 822, перекрывать автоматически подставленную дату.