Протокол SMTP
Главной целью протокола Simple Mail Transfer Protocol (SMTP, RFC-821, -822) является надежная и эффективная доставка электронных почтовых сообщений. SMTP - это довольно независимая субсистема, требующая только надежного канала связи. Средой для SMTP может служить отдельная локальная сеть, система сетей или вся сеть Internet.
Протокол SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть оконечный или промежуточный адресат. SMTP-eiiaiau генерируются отправителем и посылаются получателю. Для каждой команды должен быть получен отклик.
Когда канал организован, отправитель посылает команду MAIL, идентифицируя себя. Если получатель готов к приему сообщения, он посылает положительный отклик. Далее отправитель посылает команду RCPT, идентифицируя получателя почтового сообщения. Если получатель может принять сообщение для оконечного адресата, он снова выдает положительный отклик. В противном случае он отвергает получение сообщения для данного адресата, но не вообще почтовой посылки. Взаимодействие с почтовым сервером возможно и в диалоговом режиме, например:
| tn dxmint.cern.ch 25 220 dxmmt.cern.ch Sendmail ready at Sun, 9 Jul 1995 11:13:57+200 | связь установлена |
| ehlo dxmint.cern.ch | поддерживает ли сервер расширение MIME? |
| 500 Command unrecognized helo crnvma.cern.ch | не поддерживает |
| 250 dxmint.cern.ch Hello crnvma.cern.ch, pleased to meet you | команда выхода на конкретный сервер |
| MAIL From <Alex@aha.ru> | от кого |
| 250 <>... Sender ok | команда прошла успешно |
| RCPT To:<ysemenov@cernvm.cern.ch> | указываем адрес места назначения |
| 250 <ysemenov@cernvm.cero.ch>... Recepient ok | команда прошла успешно |
| DATA | начало ввода текста сообщения |
| . . . . . . | текст сообщения |
| . | знак конца сообщения |
| quit | завершение процедуры |
| 221 dxmint.cern.ch closing connection |
SMTPсервера могут вести диалог с несколькими оконечными пользователями.
Любое почтовое сообщение завершается специальной последовательностью символов. Если получатель успешно завершил прием и обработку почтового сообщения, он посылает положительный отклик.
Протокол SMTP обеспечивает передачу почтового сообщения непосредственно конечному получателю, когда они соединены друг с другом. В противном случае пересылка может выполняться через одну (или более) промежуточную “почтовую станцию”.
Для решения поставленной задачи SMTP-сервер должен знать имя конечного получателя и название почтового ящика места назначения. Аргументом команды MAIL является адрес отправителя (обратный адрес); аргументом команды RCPT - адрес конечного получателя. Обратный адрес используется для посылки сообщения в случае ошибки.
Все отклики имеют цифровые коды. Команды, отклики и имена ЭВМ не чувствительны к тому, строчные или прописные символы использованы при их написании. Это не относится к написанию имен и адресов получателя.
Многие почтовые системы работают только с кодами ASCII. Если транспортный канал работает с октетами, 7-битовые коды будут дополнены нулевым восьмым битом. Для пересылки файлов через SMTP традиционно используется стандартная процедура преобразования данных UUCODE/UUDECODE, которая преобразует двоичный файл в массив символов, допустимых для передачи через SMTP.
Как уже было сказано, процедура отправки почтового сообщения начинается с посылки команды MAIL, которая имеет формат:
MAIL <SP> FROM:<reverse-path> <CRLF>,
где <SP> - пробел, <CRLF> - комбинация кодов возврата каретки и перехода на новую строку, a <reverse-path> - обратный путь.
Эта команда сообщает, что стартует новая процедура и следует сбросить в исходное состояние все статусные таблицы, буферы и o.a. Если команда прошла, получатель реагирует откликом: 250 ОК.
Аргумент <reverse-path> может содержать не только адрес почтового ящика: <reverse-path> в общем случае является списком адресов ЭВМ-серверов, через которые пришло данное сообщение, включая, разумеется, и адрес почтового ящика отправителя.
Первым в списке <reverse-path> стоит адрес ЭВМ-отправителя. После прохождения команды MAIL посылается команда:
RCPT <SP> T0:<forward-path> <CRLF>.
Эта команда указывает адрес конечного получателя <forward-path>. При благополучном прохождении команды получатель посылает код-отклик 250 OK и запоминает полученный адрес. Если получатель неизвестен, SMTP-na?aa? пошлет отклик 550 Failure reply. Команда RCPT может повторяться сколько угодно раз, если адресат не один.
Аргумент <forward-path> может содержать не только адрес почтового ящика, но и маршрутный список ЭВМ по пути к нему. Первым в этом списке должно стоять имя ЭВМ, получившей данную команду. По завершении этого этапа посылается собственно сообщение:
DATA <CRLF>.
При правильном приеме этого сообщения SMTP-сервер реагирует посылкой отклика 354 Intermediate reply (промежуточный отклик) и рассматривает все последующие строки в качестве почтового текста. При получении кода конца текста отправляется отклик: 250 ОК.
Признаком конца почтового сообщения является точка в самом начале строки, за которой следует <CRLF>.
В некоторых случаях адрес места назначения может содержать ошибку, но получатель знает правильный адрес. Тогда возможны два варианта отклика:
 | 251 User not local; will forward to <forward-path> (получатель берет на себя ответственность за доставку сообщения. Это случается, когда адресат, например, мигрировал в другую субсеть в пределах зоны действия данного почтового сервера); |
| 551 User not local; please try <forward-path> (получатель знает правильный адрес и предлагает отправителю переадресовать сообщение по адресу <forward-path>). |
Реакция на команду VRFY зависит от аргумента. Так, если среди клиентов почтового сервера имеется два пользователя с именем Ivanov, откликом на команду “VRFY Ivanov” будет “553 User ambiguous”. В общем случае команда “VRFY lvanov” может получить в качестве откликов следующие сообщения:
| 250 Vasja lvanov <lvanov@cUtep.ru>; |
| 251 User not local; will forward to <lvanov@cUtep.ru>; |
| 550 String does not match anything (данная строка ничему не соответствует); |
| 551 User not local; please try <Vasja@ns.itep.ru>; |
| VRFY Chtozachertovchina 553 User ambiguous (несуществующее имя). |
EXPN Example-People 250-Juri Semenov <Semenov@ns.itep.ru> 250-Alexey Sher <Sher@suncom.itep.ru> 250-Andrey Bobyshev <Bobyshev@ns.itep.ru> 250-lgor uursky <Gursky@ns.itep.ru>.
В некоторых системах аргументом команды EXPN может быть имя файла, содержащего список почтовых адресов.
Основной задачей почты служит доставка сообщений в почтовый ящик адресата. Сходную форму услуги оказывают некоторые ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP). Для посылки сообщений на экран терминала адресата предусмотрено три команды:
| SEND <SP> FROM:<reverse-path> <CRLF> - команда SEND требует, чтобы почтовое сообщение было доставлено на терминал. Если терминал адресата не активен в данный момент, то откликом на команду RCPT будет код 450; |
| SОML <SP> FROM:<reverse-path> <CRLF> - команда Send Or MaiL (SOML) пересылает сообщение на экран адресата, если он активен, в противном случае сообщение будет уложено в его почтовый ящик; |
| SAML <SP> FROM:<reverse-path> <CRLF> - команда Send And MaiL (SAML) предполагает доставку сообщения на экран терминала адресата и занесение в его почтовый ящик. |
HELO <SP> <domain> <CRLF>, где <domain> - имя запрашивающего домена, QUIT <CRLF>.
Выражение <forward-path> может быть маршрутом, имеющим вид "@ONE,@TWO:VANJA@THREE", где ONE, TWO и THREE - имена ЭВМ. Концептуально элементы из <forward-path> переносятся в <reverse-path> при пересылке сообщений от одного SMTP-na?aa?a к другому.
Если SMTP-na?aa? обнаружит, что доставка сообщения по адресу <forward-path> невозможна, то он формирует сообщение о “недоставленном письме”, используя <reverse-path>.
Тот факт, что электронная почта является наиболее популярным видом сервиса, делает ее объектом непрерывных доработок и усовершенствований. Так, в документах RFC-1425, -1426, -1427 предлагается вариант расширения возможностей протокола SMTP (ESMTP). Эта модификация сохраняет совместимость со старыми версиями. Клиент, желающий воспользоваться расширенными возможностями, посылает субкоманду EHLO вместо HELO. Если сервер поддерживает ESMTP, он выдаст код-отклик 250. Этот вид отклика является многострочным, что позволяет серверу сообщать о видах сервиса, которые он поддерживает. Например:
250-8В1ТМ1МЕ (rfc-1426)
250-EXPN ( rfc-821 )
250-SIZE (rfc-1427)
250-HELP (rfc-821)
Ключевое слово 8В1ТМ1МЕ говорит о том, что клиент может добавить ключевое слово BODY к субкоманде MAIL FROM и определить тип символов, используемых в сообщении (ASCII или 8-битовые). Ключевое слово XADR указывает на то, что любые ключевые слова, начинающиеся с X, относятся к местным модификациям SMTP. Документ RFC-1522 определяет способ включения не ASCII-код в заголовок почтового сообщения, например:
набор_символов кодировка закодированный_текст =”.
Здесь набор_символов - это спецификация набора символов us-ascii или iso-8859-X, где Х - одиночная цифра, например iso-8859-1. Поле кодировки содержит один символ, характеризующий метод кодировки. В настоящее время используются два метода:
| Q - набор печатных символов, в кодах которых восьмой бит не равен нулю; каждый символ набора отображается тремя символами: знаком равенства (”), за которым следует два шестнадцатеричных числа (например, ”AD). Так, символ пробела будет иметь кодировку ”20; |
| В - 64-символьный набор (Base64, латинские буквы, 10 цифр, а также символы + и /). Метод кодирования подробно описан ниже. |
/p>
Интересным дополнением к традиционной электронной почте является ее расширение MIME (Multupurpose Internet Mail Extentions, RFC-1521). MIME не требует каких-либо переделок в почтовых серверах, это расширение определяет пять новых полей-заголовков (расширение RFC-822):
| MIME-Version: (версия MIME, в настоящее время 1.0); |
| Content-Type: (тип почтового сообщения); |
| Content-Transfer-Encoding: (кодирование почтового сообщения); |
| Content-ID: (идентификатор почтового сообщения) |
| Content-Description: (описание почтового сообщения). |
| 7-битовый набор (NVT ASCII, по умолчанию); |
| набор печатных символов (полезен, когда только небольшая часть символов использует восьмой бит); |
| 64-символьный набор Base64; |
| 8-битовый набор символов, включающий псевдографику с использованием построчного представления; |
| двоичная кодировка (8-битовая кодировка без разбивки на строки). |
Таблица 1.
|
Тип почтового сообщения |
Субтип почтового сообщения |
Описание |
| text | plainrichtext enriched |
Неформатированный текст. Текст с простым форматированием: курсив, жирный, с подчеркиванием и т.д. Упрощение, прояснение и усовершенствование richtext. |
| multipart | mixedparrallel digest alternative |
Сообщение содержит несколько частей, которые обрабатываются последовательно.Сообщение содержит несколько частей, обрабатываемых параллельно. Краткое содержание сообщения. Сообщение содержит несколько частей с идентичным семантическим содержимым |
| message | rfc822patial external-body |
Почтовое сообщение в стандарте RFC-822.Фрагмент почтового сообщения. Указатель действительного текста сообщения |
| application | octet-stream postscript |
Произвольная двоичная информация. Программа PostScript |
| image | jpeg gif |
Формат ISO 10918. Формат обмена CompuServe (Graphic Interchange Format) |
| audio | basic | Формат ISO 11172 |
