Разработка почтовой программы на основе протоколов SMTP и POP3

Размещено на http://www.allbest.ru/

Введение

электронный почта письмо криптографический

Целью данной курсовой работы является написание программы, которая принимает и отправляет электронную почту. Программа должна позволять работать с письмами, содержащими текст и прикрепленные файлы. Т.е. соответствовать сегодняшним требованиям к программам такого класса.

На сегодняшний день существует множество почтовых программ. Самые известные из них это Microsoft Outlook и The Bat!. Эти программы очень сложны и обладают большим количеством различных возможностей, основная часть которых не используются рядовыми пользователями. Поэтому целью данной работы являлось предоставить пользователю оптимальный набор возможностей.

1. Аналитический раздел

1.1 Постановка задачи

В соответствии с заданием на курсовую работу необходимо разработать программный продукт, обеспечивающий возможность отправки и приема электронной почты.

Перечислим требования, предъявляемые к программному продукту:

· возможность следить за состоянием почтового ящика (загружать письма с почтового сервера; удалять, отправлять почту);

· возможность просматривать письма (читать текст письма, загружать прикрепленные файлы), редактировать и переадресовывать письма;

· приложение должно поддерживать адресную книгу, содержащую информацию об адресатах пользователя;

· обеспечение работы с несколькими почтовыми ящиками, так как многие пользователи имеют несколько почтовых адресов и так как на одном компьютере могут работать сразу несколько пользователей. С каждым из почтовых ящиков связан ряд настроек, и все они защищены паролями.

Описание протокола SMTP

Взаимодействие в рамках SMTP строится по принципу двусторонней связи, которая устанавливается между отправителем и получателем почтового сообщения. При этом отправитель инициирует соединение и посылает запросы на обслуживание, а получатель - отвечает на эти запросы. Фактически отправитель выступает в роли клиента, а получатель - сервера. Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течение нескольких секунд после отправки.

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

1.2 Основные команды

Команда: HELO [имя]

Аргументы: [имя] - строка, указывающая имя компьютера-отправителя

Описание: идентифицирует передатчик для почтового сервера

Команда: EHLO [имя]

Аргументы: [имя] - строка, указывающая имя компьютера-отправителя

Описание: идентифицирует передатчик для почтового сервера

Примечание: эта команда определена в стандарте RFC 2821 и позволяет получить от почтового сервера дополнительную информацию о его функциональности. В частности в строке ответа сервер указывает поддерживаемые механизмы авторизации (о них будет сказано позже)

Команда: MAIL FROM <имя>

Аргументы: <имя> - строка, указывающая e-mail-адрес отправителя

Описание: определяет адрес отправителя почты

Команда: RCPT TO <имя>

Аргументы: <имя> - строка, указывающая e-mail-адрес получателя

Описание: определяет адрес получателя почты

Примечание: в рамках одной транзакции может быть несколько команд RCPT TO, то есть за одну транзакцию можно передать письмо нескольким адресатам

Команда: DATA

Аргументы: отсутствуют

Описание: строки, следующие за этой командой, рассматриваются получателем как данные почтового сообщения. Признаком окончания сообщения служит последовательность CRLF-точка-CRLF.

Команда: QUIT

Аргументы: отсутствуют

Описание: требует выдать ответ ОК и закрыть текущее соединение.

Протокол SMTP оговаривает последовательность команд в рамках почтовой транзакции:

· HELO (EHLO)

· MAIL FROM

· RCPT TO

· DATA

· QUIT

Коды результатов операций

В спецификации SMTP требуется, чтобы сервер отвечал на каждую команду SMTP-клиента. Сервер отвечает трехзначной комбинацией цифр, называемой кодом ответа. Вместе с кодом ответа, как правило, передается одна или несколько строк текстовой информации. Каждая цифра в коде ответа имеет определенный смысл. Первая цифра означает, было ли выполнение команды успешно (2), неуспешно (5) или еще не закончилось (3). Ниже приведены возможные значения кодов ответа SMTP, определенные в RFC 821:

Код	Значение
211	Ответ о состоянии системы или помощь
214	Сообщение-подсказка (помощь)
220	<имя_домена> служба готова к работе
221	<имя_домена> служба закрывает канал связи
250	Запрошенное действие почтовой транзакции успешно завершилось
251	Данный адресат не является местным; сообщение будет передано по маршруту <forward-path>
354	Начинай передачу сообщения. Сообщение заканчивается комбинацией CRLF-точка-CRLF
421	<имя_домена> служба недоступна; соединение закрывается
450	Запрошенная команда почтовой транзакции не выполнена, так как почтовый ящик недоступен
451	Запрошенная команда не выполнена; произошла локальная ошибка при обработке сообщения
452	Запрошенная команда не выполнена; системе не хватило ресурсов
500	Синтаксическая ошибка в тексте команды; команда не опознана
501	Синтаксическая ошибка в аргументах или параметрах команды
502	Данная команда не реализована
503	Неверная последовательность команд
504	У данной команды не может быть аргументов
550	Запрошенная команда не выполнена, так как почтовый ящик недоступен
551	Данный адресат не является местным; попробуйте передать сообщение по маршруту <forward-path>
552	Запрошенная команда почтовой транзакции прервана; дисковое пространство, доступное системе, переполнилось
553	Запрошенная команда не выполнена; указано недопустимое имя почтового ящика
554	Транзакция не выполнена

Авторизация

Современные SMTP-серверы поддерживают, как правило, несколько механизмов авторизации. Среди них:

· LOGIN;

· PLAIN;

· CRAM MD-5 и другие.

В рамках данной курсовой работы реализован механизм LOGIN.

В рамках этого механизма клиент последовательно передает на сервер две строки, содержащие закодированные в BASE64 логин и пароль отправителя почтового сообщения.

1.3 Описание протокола POP3

Перед работой через протокол POP3 сервер прослушивает порт 110. Когда клиент хочет использовать этот протокол, он должен создать TCP соединение с сервером. Когда соединение установлено, сервер отправляет приглашение. Затем клиент и POP3 сервер обмениваются информацией пока соединение не будет закрыто или прервано.

Команды POP3 состоят из ключевых слов, за некоторыми следует один или более аргументов. Все команды заканчиваются парой CRLF ( символы с номерами 13 и10 ).

Ключевые слова и аргументы состоят из печатаемых ASCII символов. Ключевое слово и аргументы разделены одиночным пробелом. Ключевое слово состоит из трех-четырех символов, а аргумент может быть длиной до 40-ка символов.

Ответы в POP3 состоят из индикатора состояния и ключевого слова, за которым может следовать дополнительная информация. Ответ заканчивается парой CRLF. Существует только два индикатора состояния: "+OK" - положительный и "-ERR" - отрицательный.

Ответы на некоторые команды могут состоять из нескольких строк. В этих случаях каждая строка разделена парой CRLF, а конец ответа заканчивается ASCII символом "." и парой CRLF.

POP3 сессия состоит из нескольких режимов. Как только соединение с сервером было установлено и сервер отправил приглашение, то сессия переходит в режим AUTHORIZATION (Авторизация). В этом режиме клиент должен идентифицировать себя на сервере. После успешной идентификации сессия переходит в режим TRANSACTION (Передача).

В этом режиме клиент запрашивает сервер выполнить определённые команды. Когда клиент отправляет команду QUIT, сессия переходит в режим UPDATE. В этом режиме POP3 сервер освобождает все занятые ресурсы и завершает работу. После этого TCP соединение закрывается.

У POP3 сервера может быть INACTIVITY AUTOLOGOUT таймер. Этот таймер должен быть, по крайней мере, с интервалом 10 минут. Это значит, что если клиент и сервер не взаимодействуют друг с другом, сервер автоматически прерывает соединение и при этом не переходит в режим UPDATE.

Авторизация

Как только будет установлено TCP соединение с POP3 сервером, он отправляет приглашение, заканчивающееся парой CRLF, например:

S: +OK POP3 server ready

Теперь POP3 сессия находится в режиме AUTHORIZATION. Клиент должен идентифицировать себя на сервере, используя команды USER и PASS. Сначала надо отправить команду USER, после которой в качестве аргумента следует имя пользователя. Если сервер отвечает положительно, то теперь необходимо отправить команду PASS, за которой следует пароль. Если после отправки команды USER или PASS сервер отвечает негативно, то можно пробовать авторизироваться снова или выйти из сессии с помощью команды QUIT. После успешной авторизации сервер открывает и блокирует maildrop (почтовый ящик). В ответе на команду PASS сервер сообщает сколько сообщений находится в почтовом ящике и передаёт их общий размер. Теперь сессия находится в режиме TRANSACTION.

Команда: USER [имя]

Аргументы: [имя] - строка, указывающая имя почтового ящика

Описание: Передаёт серверу имя пользователя.

Возможные ответы:

· +OK name is a valid mailbox

· -ERR never heard of mailbox name

Команда: PASS [пароль]

Аргументы: [пароль] - пароль для почтового ящика

Описание: Передаёт серверу пароль почтового ящика.

Возможные ответы:

· +OK maildrop locked and ready

· -ERR invalid password

· -ERR unable to lock maildrop

Команда: QUIT

Аргументы: нет

Описание: Сервер завершает POP3 сессию и переходит в режим UPDATE.

Возможные ответы:

· +OK

Основные команды (Transaction)

После успешной идентификации пользователя на сервере POP3 сессия переходит в режим TRANSACTION, где пользователь может передавать ниже следующие команды. После каждой из таких команд следует ответ сервера. Вот доступные команды в этом режиме:

Команда: STAT

Аргументы: нет

Описание: В ответ на вызов команды сервер выдаёт положительный ответ "+OK", за которым следует количество сообщений в почтовом ящике и их общий размер в символах. Сообщения, которые помечены для удаления, не учитываются в ответе сервера.

Возможные ответы:

· +OK n s

Команда: LIST [сообщение]

Аргументы: [сообщение] - номер сообщения (необязательный аргумент)

Описание: Если был передан аргумент, то сервер выдаёт информацию о указанном сообщении. Если аргумент не был передан, то сервер выдаёт информацию о всех сообщениях, находящихся в почтовом ящике. Сообщения, помеченные для удаления, не перечисляются.

Возможные ответы:

· +OK scan listing follows

· -ERR no such message

Команда:RETR [сообщение]

Аргументы: [сообщение] - номер сообщения

Описание: После положительного ответа сервер передаёт содержание сообщения.

Возможные ответы:

· +OK message follows

· -ERR no such message

Команда: DELE [ообщение]

Аргументы: [ообщение] - номер сообщения

Описание: POP3 сервер помечает указанное сообщение как удалённое, но не удалет его, пока сессия не перейдёт в редим UPDATE.

Возможные ответы:

· +OK message deleted

· -ERR no such message

Команда: NOOP

Аргументы: нет

Описание: POP3 сервер ничего не делает и всегда отвечает положительно.

Возможные ответы:

· +OK

Команда: RSET

Аргументы: нет

Описание: Если какие - то сообщения были помечены для удаления, то с них снимается эта метка.

Возможные ответы:

· +OK

Обновление

Когда клиент передаёт команду QUIT в режиме TRANSACTION, то сессия переходит в режим UPDATE. В этом режиме сервер удаляет все сообщения, помеченные для удаления. После этого TCP соединение закрывается.

Дополнительные POP3 команды

Команда: TOP [сообщение] [n]

Аргументы: [сообщение] - номер сообщения [n] - положительное число (обязательный аргумент)

Описание: Если ответ сервера положительный, то после него он передаёт заголовки сообщения и указанное кол - во строк из тела сообщения.

Возможные ответы: +OK top of message follows -ERR no such message

Команда: UIDL [сообщение]

Аргументы: [сообщение] - номер сообщения (необязательный аргумент).

Описание: Если был указан номер сообщения, то сервер выдаёт уникальный идентификатор для этого сообщения. Если аргумент не был передан, то идентификаторы перечисляются для всех сообщений, кроме помеченных для удаления.

Возможные ответы:

+OK unique-id listing follows

-ERR no such message

2. Конструкторский раздел

2.1 Структура письма

С 1982 г. стандарт RFC 822 определил и внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, просто не была упомянута в RFC822, описывавшем лишь формат текстовых сообщений. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC822 - относительно короткие строки и 7-битная символьная таблица..

MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также , вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении RFC 1521.

По стандарту MIME, письмо состоит из заголовка и тела. Они отделены друг от друга пустой строкой. Заголовок содержит поля, несущие информацию о письме. Среди них, например, поле Subject - тема письма, поле From - имя и адрес отправителя, X-Mailer - имя почтовой программы, отправившей письмо.

По стандарту MIME, письмо может состоять из нескольких частей. Каждая из них при этом тоже может состоять из частей. Так же письмо может содержать в своем теле текст другого письма.

Стандарт описанный в RFC 2047 позволил передавать в некоторых полях заголовка символы из второй половины таблицы ASCII.

2.2 Заголовок письма

Обычно описание каждого поля занимает одну строчку.

Поле заголовка "MIME-Version"

Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле "MIME-Version", объявляющее версию стандарта, в соответствии с которым написано данное письмо.

Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, например:

MIME-Version: 1.0

Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля "MIME-version" дается следующим образом:

версия := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Т.о., будущие значения версии формата, коорые могут заменить "1.0", должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от "1.0", оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.

Важно, что поле заголовка "MIME-Version", должно располагаться в самом начале письма. Это не обязательно для каждой из частей тела письма в случае многочастного письма, но обязательно для заголовков частей типа "message", если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.

Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от "1.0". Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.

Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны):

MIME-Version: 1.0

MIME-Version: 1.0 (Generated by GBD-killer 3.7)

2.3 Поле заголовка "Content-Type"

Назначение этого поля - наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обаботки. Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля - просто набор парамеров, заданных в порядке "атрибут/значение". Набор параметров зависит от типа данных. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей "Content-*"). Очередность параметров значения не имеет.

Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Хотя многие параметры имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр "boundary" применим только с типом "multipart", а параметр "charset" может использоваться с несколькими типами).

Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегистрированный тип содержимого, ему должно быть дано имя, начинающееся с "X-", чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.

Правильное заполнение поля Content-Type:

"Content-Type" ":" тип "/" подтип *(";" параметр)

тип := "application" / "audio"

/ "image" / "message"

/ "multipart" / "text"

/ "video" / признак нестандартного типа

признак нестандартного типа := x- / iana-

iana- := <общепринятый признак расширения>

x- := <Два последовательных символа "X-" или "x-">

подтип := слово

параметр := атрибут "=" значение

атрибут := слово

значение := слово / строка в кавычках

слово := любые ASCII-символы кроме пробелов, Ctrl-последовательностей и специальных символов

cспециальные символы := "(" / ")" / "<" / ">" / "@"

/ "," / ";" / ":" / "\" / <">

/ "/" / "[" / "]" / "?" / "="

Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".

Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра

Существует два приемлемых механизма для введения новых подтипов для поля Content-Type:

1. Нестандартные значения (начинающиеся с "X-") могут быть опредлены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.

2. Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA.

Text - текстовая информация. Основой подтип - "plain" - соответствует обычному неформатированному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуализацию, но для понимания идеи содержания можно обойтись и без дополнительного ПО. Возможные подтипы могут описывать легко читаемые форматы различных текстовых процессоров.

Multipart - содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:

1. "mixed" - основной;

2. "alternative" - для представления одних и тех же данных в разных форматах;

3. "parallel" - если разные части документа должны просматриваться одновременно;

4. "digest" - если каждая из частей тела письма имеет тип "message".

Message -- письмо в письме. Тело, содержащее данные типа "message", само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка"Content-Type".
Подтипы:

1. "rfc822" - основной;

2. "partial" - определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;

3. "External-body" - используется, чтобы указать, что тело письма очень большое и находится вне письма.

Image - графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов - jpeg и gif.

Audio - звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип - "basic".

Video - видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единственный изначально определенный подтип - "mpeg".

Application - как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.
Подтипы:

1. "octet-stream" - основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.

2. "PostScript" - дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.

2.4 Поле заголовка Content-Transfer-Encoding

Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код. В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.

Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлемый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.

Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".

Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:

конвертация := "Content-Transfer-Encoding" ":" механизм

механизм := "7bit"

/ "quoted-printable"

/ "base64"

/ "8bit"

/ "binary"

/ x-token

Значения не чувствительны к регистру букв. Значение "7bit" означает, что тело письма уже имеет 7-битный формат и не требует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.

Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:

"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.

"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).

"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может не соблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.

Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной - ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.

Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов почты Internet, для которых является приемлемым включение в тело письма некодированных двоичных данных легальным в Internet.

Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.

Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

2.5 Механизм конвертации "Quoted-Printable"

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

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

· Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатеричных цифр, предваряемых знаком "=". При написании шестнадцатеричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

· Байты с десятичным значением с 33 по 60 и с 62 по 126 могут быть представлены ASCII-символами.

· Байты со значениями 9 и 32 могут быть представлены как ASCII-символы "Табуляция" и "Пробел", но не должны быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать печатный символ. В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом 1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

· Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

· В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

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

([*(простой текст / SPACE / TAB) простой текст]["="] CRLF)

простой текст := байт /<ASCII-символ без "=", SPACE, TAB>

байт := "=" 2(ЦИФРА / "A" / "B" / "C" / "D" / "E" / "F")

2.6 Механизм конвертации Base64

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

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

Значение Код Значение Код Значение Код Значение Код

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 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в таблице, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='.

2.7 Поле Content-ID

При создании почтового агента верхнего уровня может быть желательно позволить одному телу иметь ссылку на другое. Для этого поля могут быть помечены с помощью поля заголовка "Content-ID", синтаксически идентичного полю "Message-ID":

идентификатор := "Content-ID" ":" идентификатор письма

Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными.

2.8 Поле Content-Description

Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как "a picture of the Space Shuttle Endeavor." Этот текст и может быть помещен в поле заголовка Content-Description.

описание := "Content-Description" ":" *текст

2.9 Тело письма

При различных значениях типа поля Content-Type в теле письма может содержаться различная информация.

2.9.1 Тип Text

Тип Text предназначен для пересылки текстовых материалов. Это значение поля - по умолчанию. Для обозначения языковой кодировки текста используется параметр "charset" для некоторых подтипов, включая основной подтип, "text/plain", соответствующий простому (неформатированному) тексту. В Internet'овской почте значением Content-Type по умолчанию является следующее: "text/plain; charset=us-ascii".

2.9.2 Тип Multipart

Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтаксис письма RFC 822 (то есть, иметь заголовок, пустую строку и тело), но должна иметь открывающую и закрывающую границы.

Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть начинающиеся с "Content-". Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться "X-" поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.

Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Программы должны иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содержащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь "Content-Type: message" и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка "Content-Type: image".

Граница части письма не должна появляться внутри самой части письма.

Общий синтаксис

Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" и значения параметра 'boundary' из поля заголовка Content-Type.

Зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит.

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

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

Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.

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

Часть письма, в свою очередь, также может иметь тип 'multipart', то есть быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.

Граница

0*69<символов_границы> <символ_границы_без_SPACE>

символ границы := символ_границы_без_SPACE / " "

символ_границы_без_SPACE := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА /

"'" / "(" / ")" / "+" / "_" / "," /

"-"/ "." / "/" / ":" / "=" / "?"

Многочастное письмо

приамбула *<вложение> признак_конца эпилог

вложение := разделитель часть_тела CRLF

разделитель := "--" метка_границы CRLF

признак конца := "--" метка_границы "--" CRLF

приамбула := игнорируемый текст

эпилог := игнорируемый текст

игнорируемый текст := *(*текст CRLF)

часть_тела := <письмо RFC 822>

Основной подтип "multipart/mixed"

Это основной подтип для типа 'multipart', он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу 'mixed'.

Подтип "multipart/alternative"

Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику. Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.

Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных, пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив.

Подтип "multipart/digest"

Этот подтип идентичен подтипу 'multipart/mixed', но имеет другую семантику. Например, для 'digest' значением по умолчанию является не "text/plane", а "message/rfc822".

Подтип "multipart/parallel"

Отличие этого подтипа от "multipart/mixed", в частности, состоит в том, что порядок расположения частей письма не принципиален.

Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями.

2.9.3 Тип Message

При пересылке почты часто возникает необходимость включить внутрь письма другое письмо. Для этого и используется тип 'message'.

Основной подтип - "rfc822" - не требует параметров в поле Content-Type. Дополнительные подтипы - "partial" и "External-body" - предполагают наличие параметров.

Основной подтип 'message/rfc822'

Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей "From", "Subject" и, по крайней мере, одного поля "To".

Не смотря на использование числа "822", тело, имеющее подтип 'message/rfc822', может быть MIME-письмом.

Подтип 'message/partial'

Этот подтип определен с целью обеспечения возможности пересылки очень больших объектов в виде нескольких раздельных частей, автоматичски "склеиваемых" почтовой программой получателя. Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.

Для этого подтипа необходимо указание трех параметров:

1. "id" - уникальный идентификатор, позволяющий обнаружить остальные части послания.

2. "number" - целое число, означающее номер части послания.

3. "total" - целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

Нумирация частей начинается с 1, а не с 0.

Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.

При "сборке" таких посланий в пункте назначения должны учитываться следующие правила:

· Все поля заголовка части 1, кроме начинающихся с "Content-" и специальных "Message-ID", "Encrypted" и "MIME-Version" должны быть скопированы в заголовок нового (общего) письма.

· Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с "Content-", а также поля "Message-ID", "Encrypted" и "MIME-Version", должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.

· Заголовки второй и последующих частей целиком игнорируются.

2.9.4 Тип Application

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

Подобные приложения могут быть определены как подтипы для типа "application". Изначально предопределено два подтипа: "octet-stream" и "PostScript".

В общем, подтип для 'application' зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для 'application'. Такие употребления (кроме подтипов, начинающихся с "x-") должны быть зарегистрированы в IANA.

Основной подтип 'Application/Octet-Stream'

Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):

TYPE - обобщенный тип или категория двоичных данных, эта информация больше предназначена для получателя, чем для автоматической обработки.

Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, - просто предложить записать данные в файл без какого-либо преобразования или, возможно, произвести его в соответствии с указанием пользователя.

Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля "Content-Type" (например, в параметре "interpreter").

2.9.5 Тип Image

Этот тип означает, что тело письма содержит графический объект. Его подтипы соответствуют конкретным графическим форматам. Их значения нечувствительны к регистру букв. Два предопределенных подтипа - "jpeg" для формата JPEG с кодированием JFIF, и "gif" - для формата GIF.

Формальный синтаксис поля 'Content-Type':

image_тип := "image" "/" ("gif" / "jpeg" / подтип-расширение)

2.9.6 Тип Audio

Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по "идеальному" аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.

Предопределенный подтип - "basic" введен в ответ на это требование, обеспечивая минимальный примитивный аудио-формат.

Формальный синтаксис для поля 'Content-Type':

audio_тип := "audio" "/" ("basic" / подтип-расширение)

2.9.7 Тип Video

Этот тип означает, что в теле письма содержится анимационное изображение, возможно, со звуком и цветом. Термин "video" используется безотносительно к технологии получения подвижного во времени изображения. Подтип "mpeg" указывает на видео, кодированное в соответствии со стандартом MPEG.

Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые "video"-форматы включают синхронизированный звук, что допускается для подтипов типа "video".

Формальный синтаксис лдя поля 'Content-Type':

video-type := "video" "/" ("mpeg" / подтип-расширение)

2.10 Алгоритм формирования письма

Разрабатываемый программный продукт должен обеспечивать возможность отправки электронных писем с прикрепленными файлами, поэтому выбрана наиболее простая структура письма. В общем случае оно состоит из заголовка, тестовой части (тип text/plain) и одного или нескольких прикрепленных файлов (тип application/octet-stream).

Структура заголовка формируемых писем приведена ниже (одновременно представлен пример заголовка письма):

Для текстового письма:

From: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

To: kir_beat@mail.ru

Subject: =?Windows-1251?Q?=D2=E5=EC=E0?=

Date: Thu, 1 Dec 2005 1:51:49 +0000

Reply-To: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

MIME-Version: 1.0

Content-Type: text/plain; charset=Windows-1251

Content-Transfer-Encoding: 8BIT

Для письма с вложенными файлами:

From: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

To: kir_beat@mail.ru

Subject: =?Windows-1251?Q?=D4=E8=ED=E0=EB=FC=ED=E0=FF=20=E2=E5=F0=F1=E8=FF?=

Date: Thu, 1 Dec 2005 0:50:45 +0000

Reply-To: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

MIME-Version: 1.0

Content-Type: Multipart/Mixed; boundary="----bndr1E84A65B-2FE9-4C40-8F5C-D0F2AFA9CD57"

Как видно, для кодирования содержимого некоторых полей заголовка используется кодовая страница Windows-1251 и механизм кодирования Base64.

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

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

From: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

To: kir_beat@mail.ru

Subject: =?Windows-1251?Q?=D2=E5=EC=E0?=

Date: Thu, 1 Dec 2005 1:51:49 +0000

Reply-To: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

MIME-Version: 1.0

Content-Type: text/plain; charset=Windows-1251

Content-Transfer-Encoding: 8BIT

2.11 Тестовое письмо

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

Рассмотрим случай, когда письмо содержит несколько вложенных файлов:

From: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

To: kir_beat@mail.ru

Subject: =?Windows-1251?Q?=D4=E8=ED=E0=EB=FC=ED=E0=FF=20=E2=E5=F0=F1=E8=FF?=

Date: Thu, 1 Dec 2005 0:50:45 +0000

Reply-To: =?Windows-1251?Q?=C4=E5=ED=E8=F1=20=CB=EE=EC=E0=ED=EE=E2?=<lynxdel@yandex.ru>

MIME-Version: 1.0

Content-Type: Multipart/Mixed; boundary="----bndr1E84A65B-2FE9-4C40-8F5C-D0F2AFA9CD57"

------bndr1E84A65B-2FE9-4C40-8F5C-D0F2AFA9CD57

Content-Type: text/plain; charset="Windows-1251"

Content-Transfer-Encoding: 8BIT

Последний тест перед сдачей

------bndr1E84A65B-2FE9-4C40-8F5C-D0F2AFA9CD57

Content-Type: application/octet-stream

Content-Disposition: attachment; filename="KDe Mailer FINAL.rar"

Content-Transfer-Encoding: BASE64

UmFyIRoHAM+QcwAADQAAAAAAAAADJHTgkDgAAAAAAAAAAAACAAAAACYGgTMUMBMAEAAAAEtEZSBN

YWlsZXIgMzBfMTFfMDUAsFpiAuZpdGCAPwAvAAAALwAAAAKhdNYfXAGDMB01HwAgAAAAS0RlIE1h

aWxlciAzMF8xMV8wNVwhRGVsZXRlLmJhdKcYZANngvV8S7H6dxBWi1kMCgNVzo/ 8Oe5R/0bvCv/yEwfQ2MUP/hAxD17AEAHAA==

------bndr1E84A65B-2FE9-4C40-8F5C-D0F2AFA9CD57--

В этом случае вводится разделитель boundary, объявляемый в заголовке письма. В начале этого разделителя должна располагаться последовательность CRLF. Он должен располагаться перед каждой частью письма, содержащей текст или вложенный файл. При этом в начало разделителя должна добавляться последовательность “--”. Оканчиваться письмо должно разделителем, к которому в начале и в конце присоединены последовательности “--”, и заключительной последовательностью CRLF-точка-CRLF.

Как видно, в качестве транспортной кодировки для присоединенных фалов используется Base64. При использовании этой кодировки следует иметь ввиду, что максимальная длина строки ограничена 76 символами.

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

2.12 Алгоритм разбора письма

Алгоритм разбора письма можно разделить на три части. Первая часть осуществляет анализ заголовка письма, чтение полей и параметров письма. Вторая часть заполняет незаданные поля значениями по умолчанию. Третья часть анализирует тело письма. Алгоритм является рекурсивным, поскольку может содержать подписьма или состоять из нескольких частей.

Алгоритм анализа заголовка

· считывается очередная строчка из письма (Str);

· если строчка Str пустая, то значит что все поля заголовка считаны, алгоритм завершается;

· если Str начинается с пробела или табуляции, то это значит, что Str - продолжение предыдущего поля, приписываем Str к Buf;

· если Str не начинается с пробела или табуляции, то это значит, что поле считано в Buf полностью;

· тогда анализируем название поля и считываем из Buf значение этого поля и значения необходимых параметров (например параметров boundary или charset);

· обнуляем Buf..

Алгоритм установки значений по умолчанию

...