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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда: AUTHENTIFICATE

Аргументы: имя механизма аутентификации

Описание: команда показывает серверу механизм аутентификации. Если сервер поддерживает указанный механизм, то выполняется обмен данными для аутентификации клиента;

Результат:

OK - аутентификация прошла успешно;

NO - неудача при аутентификации, неподдерживаемый механизм, нет полномочий;

BAD - команда не поддерживается или аргументы некорректны.

Команда: LOGIN

Аргументы: имя пользователя, пароль

Описание: используется для представления клиента серверу и передачи пароля и логина в виде открытого текста;

Результат:

OK - аутентификация прошла успешно;

NO - неудача, имя пользователя и пароль отвергнуты;

BAD - команда не поддерживается или аргументы некорректны.

Команда: LOGOUT

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

Описание: информирует сервер о намерении клиента закончить работу;

Результат:

OK - команда выполнена

BAD - команда не поддерживается или аргументы некорректны.

Команда: SELECT

Аргументы: имя почтового ящика

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

FLAGS - флаги почтового ящика;

<n> EXISTS - число сообщений в почтовом ящике;

<n> RECENT - число сообщений с флагом \Recent

OK [UIDVALIDITY <n>] - уникальный идентификатор корректности.

В каждом соединении может быть выбран только 1 почтовый ящик. Для работы с несколькими ящиками требуется соответствующее число соединений. При выборе нового почтового ящика команда SELECT автоматически отменяет предыдущий выбор.

Результат:

OK - выбор завершен успешно;

NO - отказ при выборе;

BAD - команда не поддерживается или аргументы некорректны.

Команда: LSUB

Аргументы: база, имя почтового ящика (возможны шаблоны)

Описание: возвращает список папок почтового ящика;

Результат:

OK - успешное завершение;

NO - неудача;

BAD - команда не поддерживается или аргументы некорректны.

Команда: STATUS

Аргументы: имя почтового ящика, имена элементов состояния

Описание: запрашивает сведения о состоянии указанного почтового ящика. Не меняет выбранный ящик и не влияет на состояние каких-либо сообщений в ящике.

Элементы состояния:

MESSAGES - число сообщений в почтовом ящике;

RECENT - число сообщений с флагом \Recent;

UIDNEXT - значение UID, которое будет использовано для следующего сообщения;

UIDVALIDITY - значение идентификатора корректности для почтового ящика;

UNSEEN - число сообщений, для которых не установлен флаг \Seen.

Результат:

OK - успешное завершение;

NO - неудача - для заданного имени нет данных о состоянии;

BAD - команда не поддерживается или аргументы некорректны.

Команда: CLOSE

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

Описание: уничтожает в текущем почтовом ящике все сообщения с флагом \Deleted и закрывает текущий почтовый ящик.

Результат:

OK - выбор ящика отменен;

NO - отказ - нет выбранного почтового ящика;

BAD - команда не поддерживается или аргументы некорректны.

Команда: EXPUNGE

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

Описание: уничтожает в текущем почтовом ящике все сообщения с флагом \Deleted.

Результат:

OK - удаление завершено;

NO - отказ - возможно, нет прав на удаление;

BAD - команда не поддерживается или аргументы некорректны.

Команда: SEARCH

Аргументы: критерии поиска

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

Со списком поддерживаемых ключей можно ознакомиться в RFC 2060.

Результат:

OK - удачное завершение поиска;

NO - ошибка при поиске;

BAD - команда не поддерживается или аргументы некорректны.

Команда: FETCH

Аргументы: набор сообщений, имена элементов данных в сообщениях

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

Типы данных для выборки перечислены в RFC 2060.

Результат:

OK - успешная выборка;

NO - неудача при попытке выборки;

BAD - команда не поддерживается или аргументы некорректны.

Команда: STORE

Аргументы: набор сообщений, значение для элемента данных сообщения

Описание: изменяет данные для указанного сообщения в почтовом ящике. Могут изменяться следующие данные:

FLAGS <flag list> - замена флагов сообщения. Новые значения флагов возвращаются в непомеченном отклике FETCH;

FLAGS.SILENT <flag list> - эквивалент FLAGS, но без возврата отклика;

+FLAGS <flag list> - добавления флага. Новые значения флагов возвращаются в непомеченном отклике FETCH;

+FLAGS.SILENT <flag list> - эквивалент +FLAGS, но без возврата отклика;

-FLAGS <flag list> - удаление флага сообщения. Новые значения флагов возвращаются в непомеченном отклике FETCH;

-FLAGS.SILENT <flag list> - удаление флага сообщения, но без возврата отклика.

Результат:

OK - успешная запись;

NO - неудача;

BAD - команда не поддерживается или аргументы некорректны.

Команда: COPY

Аргументы: набор сообщений, имя почтового ящика

Описание: копирует заданные сообщения из текущего в конец заданного почтового ящика.

Результат:

OK - успешное копирование;

NO - неудача;

BAD - команда не поддерживается или аргументы некорректны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подтипы:

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

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

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

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

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

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

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

Подтипы:

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

"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-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

Механизм конвертации "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")

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

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

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

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

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

2.5 Поле Content-ID

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

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

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

2.6 Поле Content-Description

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

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

2.7 Тело письма

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

2.7.1 Тип Text

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

2.7.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.7.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'

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

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

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

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

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

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

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

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

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

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

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

2.7.4 Тип Application

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

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

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

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

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

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

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

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

2.7.5 Тип Image

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

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

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

2.7.6 Тип Audio

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

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

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

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

2.7.7 Тип Video

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

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

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

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

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

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

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

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

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

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

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

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

Buf. очищается.

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

Если в заголовке письма или части письма нет поля Content-Type, то

Если это главный заголовок письма, устанавливаем для письма тип text и подтип plain.

Если же это заголовок части письма, то

Если эта часть относится к digest, то устанавливаем для письма тип message и подтип rfc822.

Иначе устанавливаем для части письма тип text и подтип plain.

Если тип письма или части письма - text и у не задан параметр charset, то в charset записывается us-ascii.

Если не задано поле Content-Transfer-Encoding, то в него записывается 7bit.

Алгоритм анализа тела письма

Если тип письма или его части - text, то

декодируем его в соответствии со значением Content-Transfer-Encoding.

перекодируем текст из кодировки charset в кодировку, которую есть возможность отобразить.

Если тип письма или его части - application, image, audio или video, то

декодируем его в соответствии со значением Content-Transfer-Encoding.

Если тип письма или его части - multipart, то

Читаем построчно и выявляем части письма лежащие между «--» + boundary, либо между «--» + boundary + «--».

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

Если тип письма или его части - message, а подтип rfc822, то

Запускаем рекурсивно алгоритм разбора для тела письма или для части письма.

3. Технологический раздел

3.1 Выбор языка и средств программирования

Программный продукт был разработан в среде разработки Borland C++ Builder, поскольку эта среда программирования предоставляет широкие возможности по созданию пользовательского интерфейса и ускоряет процесс разработки программных продуктов. Данная среда программирования содержит множество стандартных элементов оконного пользовательского интерфейса, использование которых позволило сделать управляющее приложение простым и понятным для пользователя. Кроме того, в составе среды разработки Borland C++ Builder поставляются заголовочные файлы, предоставляющие возможность использование структур SOCKET, что делает разработку весьма производительной и значительно ускоряет ее.

Для рассматриваемого приложения объем исполняемого файла не является критичным фактором, поэтому выбор среды Borland C++ Builder можно считать вполне обоснованным.

Модульная структура программного продукта

Разработанный программный продукт состоит из следующих модулей:

uAbout - вывод окна «О программе»;

uMain - главный модель программы, содержит в основном функции, отвечающие за пользовательский интерфейс, использует функции всех остальных модулей;

uMessageInfo - вывод окна, содержащий информацию об основных полях письма;

uNetProcs - содержит функции для работы по протоколу IMAP;

uParseMail - содержит функции для разбора заголовка письма;

uSettings - модуль настроек программы;

uViewMessage - модуль просмотра писем. Использует методы класса TMailParser. Класс TMailParser был разработан в рамках данного курсового проекта и оформлен в виде компонента для среды разработки C++ Builder. Этот класс содержит необходимый набор методов для разбора MIME-писем.

3.2 Программная реализация проекта

Для извлечения информации о полях письма, его тексте и прикрепленных файлах используется компонент TMailParser, разработанный в рамках данного проекта. Поскольку письмо в общем случае может иметь древовидную структуру, то компонент осуществляет построение дерева в памяти. В листьях дерева хранятся указатели на буферы, содержащие текст письма или прикрепленные файлы. Каждый узел дерева хранит значение полей письма. В корне дерева хранятся главные поля письма, такие как Subject, Date и т.д. Построение дерева осуществляется вызовом метода Translate. В зависимости от значения передаваемого параметра, происходит анализ либо всего письма, либо только заголовка. Для уничтожения дерева используется метод Clear.

Каждый узел дерева содержит массив указателей на потомков данного узла и переменную с количеством потомков. Вызвав функцию узла GetDataNode можно получить указатель на буфер, содержащий прикрепленный файл или текст письма. Функция узла GetParentNode возвращает указатель на вершину предка данного узла, а функция GetChildNode возвращает указатель на потомка, номер которого указывается в параметре функции.

Поскольку для осуществления этих действий по работе с почтой необходимо обмениваться данными с IMAP-сервером, были разработаны следующие функции (модуль uNetProcs):

get_own_ip - получение собственного IP-адреса;

get_server_ip - разрешение символьного имени сервера в его IP-адрес;

send_listen - отправка пакета и получение ответа на него;

ConnectIMAP - подключение к IMAP-серверу;

LoginIMAP - аутентификация на IMAP-сервере;

GetBoxesIMAP - получение списка папок почтового ящика;

SelectMailPath - выбор текущей папки почтового ящика;

CloseMailPath - закрытие текущей папки;

CountMessages - получение информации о количестве писем в папке;

GetMessagesHeaders - загрузка заголовков писем выбранной папки;

GetMessagesBody - загрузка письма;

CopyMessage - копирование письма из одной папки почтового ящика в другую;

DeleteMessage - удаление письма с сервера;

DisconnectIMAP - отключение от IMAP-сервера.

3.3 Пользовательский интерфейс

Форма приема почты

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

загрузка информации о папках почтового ящика;

вызов формы настроек;

копирование письма из одной папки в другую - при нажатии на правую часть кнопки вызывается контекстное меню, содержащее список папок почтового ящика;

перемещение письма из одной папки в другую - аналогично предыдущему пункту;

просмотр письма - открытие формы просмотра письма. Форма встраивается в главную форму приложения;

удаление письма - удаление письма с сервера;

закрытие программы.

В левой части формы содержится TreeView со списком папок почтового ящика. В правой части расположен TreeView со списком заголовков. Содержимое TreeView заголовков зависит от фокуса TreeView папок почтового ящика.

Форма настроек

Содержит информацию обо всех настройках программы. Настройки хранятся в файле settings.ini в основном каталоге программы.

Форма просмотра почты

Панель в верхней части формы содержит следующие кнопки (слева направо):

сохранение прикрепленного файла, выделенного в TreeView;

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

вызов формы информации о письме;

закрытие формы просмотра письма, возврат к главной форме приложения.

Заключение

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

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

Размещено на Allbest.ru

...