Развитие стандартов кодирования сообщений электронной почты

  Ответ MTA-сервера  может состоять из нескольких строк  специального формата. Каждая строка (кроме  последней) многострочного ответа начинается с кода ответа, дефиса (-), текста и  комбинации CRLF. Последняя строка многострочного ответа начинается с кода ответа, за которым следует пробел:

  123-Первая  строка сообщения из нескольких  строк

  123-Код  ответа, 123, не изменяется

  123-1 сообщение  может начинаться с цифры

  123 Последняя  строка начинается не с дефиса, а с пробела

  За кодом  каждой строки, кроме последней, следует  знак дефиса (-). Это необходимо, чтобы  клиент MTA смог отличить строку-продолжение  ответа от последней строки. За кодом  ответа в последней строке всегда следует пробел. 
 
 
 
 

  Ограничения по размерам.

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

  Ограничения на размеры объектов SMTP

  Если клиент МТА превысил ограничения на размер передаваемой информации, сервер МТА  отвечает одним из следующих кодов:

  500 Line too long.

  (слишком  длинная строка)  

  501 Path too long.

  (слишком  длинный путь)  

  552 Too many recipients.

  (слишком  много получателей)  

  552 Too much mail data.

  (слишком много данных в сообщении) 

При кодировании  текста могут применяться следующие  методы кодирования:

• метод UUENCODE
• по стандарту MIME
• метод Quoted Printable
• метод Base64.

  Метод UUENCODE является самым "старым", поэтому он часто используется в программах с давней историей, в частности, для почты off-line (UUCP), и, наоборот, в современных программах этот метод часто не поддерживается, но может включаться для "совместимости" с другими программами.

  Методы  кодирования по стандарту MIME применяются практически во всех современных программах для on-line почты (по протоколу POP).

  Поддержка методов кодирования (UUENCODE/MIME) никак не связана с типом используемой почты (например, UUCP/POP), а определяется только возможностями почтовой программы. Более "старому" сервису (UUCP) часто служат более "старые" программы, то получается, что многие клиенты UUCP почты могут понять в лучшем случае UUENCODE-кодирование, а абоненты почтового ящика POP, наоборот, чаще работают с современным MIME-стандартом.

  Таким образом, метод UUENCODE старайтесь использовать, если у Вашего абонента "старая" программа (например, Bmail для Dos), а если у него современная программа под Windows (например, Internet Mail, почтовый модуль в Netscape Navigator), то почти наверняка подойдет кодирование по стандарту MIME.

  Стандарт MIME определяет 2 метода кодирования - Quoted Printable иBase64. метод Quoted Printable, когда большая часть текста набрана латинским шрифтом с небольшим "вкраплением" 8-битных символов (буквы русского алфавита, в частности), т.к. в этом методе кодируются только 8-битные символы, но количество их увеличивается не меньше чем вдвое.

• метод Base64, когда большая часть текста состоит из 8-битных символов (например, полностью русскоязычный текст), т.к. в этом методе кодируется весь текст (включая латинский алфавит), но размер его увеличивается не более чем на треть.

Метод кодирования "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 как  безопасные для почты

Метод кодирования  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 ("-").