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> |
Поменяться местами серверу и клиенту |
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 |
Обмен завершился аварийно |
Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе 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 как безопасные для почты
Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 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 отсутствует символ '-'.