Приложения

На главную страницу


Приложение 1. Команды протокола SMTP

Таблица 3. Команды SMTP.

HELO <SP> <domain> <CRLF>

Открыть сессию взаимодействия по протоколу SMTP. < domain> - доменное имя машины

MAIL <SP> FROM:<reverse-path> <CRLF>

Сообщить адрес отправителя (<reverse-path>). Обязательная команда, которую надо выдать перед отправкой сообщения

RCPT <SP> TO:<forward-path> <CRLF>

Сообщить адрес получателя (forward-path). Обязательная команда, которую выдают после MAIL FROM, но перед DATA

DATA <CRLF>

Начать передачу тела почтового сообщения. Тело сообщения должно кончаться точкою(".") в первой позиции строки

RSET <CRLF>

 

SEND <SP> FROM:<reverse-path> <CRLF>

Послать сообщение на терминал пользователя, который определяется командой RCPT

SOML <SP> FROM:<reverse-path> <CRLF>

SEND OR MAIL. Послать в почтовый ящик или на терминал пользователя

SAML <SP> FROM:<reverse-path> <CRLF>

SEND AND MAIL. Послать в почтовый ящик и на терминал пользователя

VRFY <SP> <string> <CRLF>

Получить информацию о пользователе, имя которого указывается в качестве аргумента команды (<string>)

EXPN <SP> <string> <CRLF>

Получить информацию о пользователях зарегистрированных в качестве получателей корреспонденции

HELP [<SP> <string>] <CRLF>

Краткая справка по командам протокола

NOOP <CRLF>

Нет операции

QUIT <CRLF>

Завершить сессию

TURN <CRLF>

Поменяться местами серверу и клиенту

Приложение 2. Коды возврата SMTP

Таблица 4. Коды возврата SMTP.

211

System status, or system help reply

Статус системы или Help

214

Help message. [Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user]

Краткая справка

220

<domain> Service ready

SMTP-сервис готов к работе

221

<domain> Service closing transmission channel

Сервис закрыл канал передачи данных

250

Requested mail action okay, completed

Соединение установлено

251

User not local; will forward to <forward-path>

Пользователь не местный. Выполнить перенаправление запроса

354

Start mail input; end with <CRLF>.<CRLF>

Начать ввод почтового сообщения

421

<domain> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down]

Сервис отсутствует. Канал передачи данных закрыт

450

Requested mail action not taken: mailbox unavailable [E.g., mailbox busy]

Нет возможности записать данные в почтовый ящик

451

Requested action aborted: local error in processing

Ошибка при обработке запроса

452

Requested action not taken: insufficient system storage

Запрос не выполнен недостаточно памяти на вычислительной установке

500

Syntax error, command unrecognized [This may include errors such as command line too long]

<

Синтаксическая ошибка - нет такой команды

501

Syntax error in parameters or arguments

Синтаксическая ошибка в аргументах команды

502

Command not implemented

Данная команда не может быть выполнена

503

Bad sequence of commands

Неправильная последовательность команд

504

Command parameter not implemented

Параметр команды не может быть использован в данном контексте

550

Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access]

Не найден соответствующий почтовый ящик

551

User not local; please try <forward-path>

Пользователь не найден можно попробовать отправить почту по другому адресу

552

Requested mail action aborted: exceeded storage allocation

Превышены квоты на использование ресурсов памяти

553

Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect]

Имя почтового ящика неправильное

554

Transaction failed

Обмен завершился аварийно

Приложение 3. Механизм конвертации "Quoted-Printable"

Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.

В Quoted-Printable байты должны быть представлены в соответствии со следующими правилами:

ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатеричных цифр, предваряемых знаком "=". При написании шестнадцатеричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '<' и с '>' по '~').

ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлении текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.

ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

     Now's the time for all folk to come to the aid of
     their country.

то в Quoted-Printable encoding он может быть представлена следующим образом:

     Now's the time =
     for all folk to come=
     to the aid of their country.

Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовым агентом.

Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)

ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добиться действительно надежной транспортировки через EBCDIC-шлюз - экранировать ASCII-символы

     !"#$@[\]^`{|}~

в соответствии с правилом #1.

Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

Синтаксис данных в quoted-printable описывается следующим образом:

   quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст]
                        ["="] CRLF)
        ; Максимальная длина строки - 76 символов, включая CRLF
   простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ>
        ; символы, не перечисленные в приложении B к RFC 1521 как  безопас-
        ; ные для почты, также не рекомендуются к использованию
   байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F")
        ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ,
        ; и рекомендуется для представления любых символов, не  перечислен-
        ; ных в приложении B к RFC 1521 как безопасные для почты

Приложение 4. Механизм конвертации Base64

Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем не кодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлет встроенного "чистого" текста.

Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).

ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 - часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

Процесс кодирования преобразует 3 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").

Таблица 5. Алфавит Base64

Код

Значение

Код

Значение

Код

Значение

Код

0

A

17

R

34

i

51

z

               

1

B

18

S

35

j

52

0

               

2

C

19

T

36

k

53

1

               

3

D

20

U

37

l

54

2

               

4

E

21

V

38

m

55

3

               

5

F

22

W

39

n

56

4

               

6

G

23

X

40

o

57

5

               

7

H

24

Y

41

p

58

6

               

8

I

25

Z

42

q

59

7

               

9

J

26

a

43

r

60

8

               

10

K

27

b

44

s

61

9

               

11

L

28

c

45

t

62

+

               

12

M

29

d

46

u

63

/

               

13

N

30

e

47

v

 

 

               

14

O

31

f

48

w

=

(заполнитель)

               

15

P

32

g

49

x

 

 

               

16

Q

33

h

50

y

 

 

             

Выходной поток (закодированные байты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа '='; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода будут два символа Base64, с добавлением двух символов '='; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ '='.

Т.к. символ '=' является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.

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

Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ '-'.

back contents next

Hosted by uCoz