Опубликован: 21.11.2006 | Уровень: специалист | Доступ: платный
Лекция 5:

Протокол 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, перекрывать автоматически подставленную дату.

Valentin Diduk
Valentin Diduk
Украина, одесса, кпи, 2010
Евгений Олабин
Евгений Олабин
Беларусь, Гродно