Интегрированные сети ISDN
Базовые моменты при посылке почтовых сообщений
2. Базовые моменты при посылке почтовых сообщений
Почта в Интернет не совершенная однородная система. Почта может оказаться поврежденной на нескольких этапах ее транспортировки к месту назначения. Почтовое сообщение может проходить через участки среды, использующие различные сетевые технологии. Многие сетевые и почтовые технологии не поддерживают полную функциональность, возможную в рамках протокола SMTP. Почтовое сообщение, проходя через эти среды, может быть модифицировано, для того чтобы решить проблему его передачи адресату.
В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.
1) |
При некоторых обстоятельствах кодирование, использованное для данных, может изменить работу почтового шлюза или агента пользователя. В частности, может потребоваться преобразование из base64 в закавыченную печатную форму и обратно. Это может вызвать искажения для последовательностей CRLF, определяющих границы строк в тексте. |
2) |
Многие системы могут выбрать для хранения и представления текста другое локальное соглашение для обозначения начала новой строки. Это локальное соглашение может не согласовываться с RFC-822, где для этого используется CRLF. Известны системы, где для этой цели применяют один символ CR, один LF, CRLF, или нечто совсем другое. В результате получается, что изолированные CR и LF символы не вполне надежны; они могут быть потеряны или преобразованы некоторыми системами в другие разделители, следовательно, на них нельзя положиться. |
3) |
Передача нулей (US-ASCII значение 0) проблематична в Интернет-почте. Это по большей части результат введения нулей, используемых в качестве завершающего символа во многих стандартных программных библиотеках реального времени в языке Си. Практика использования нулей в качестве завершающего символа настолько распространена, что нельзя рассчитывать на то, что эти нули будут сохранены в сообщении. |
4) |
TAB (HT) символы могут быть неверно интерпретированы или автоматически преобразованы в переменное число пробелов. Это неизбежно в некоторых условиях, в особенности тех, которые базируются на символьном наборе US-ASCII. Такое преобразование не рекомендуется, но может случиться и форматы почты не должны полагаться на сохранение символов TAB (HT). |
5) |
Строки длиннее 76 символов могут быть разорваны или укорочены некоторыми почтовыми агентами. Разрыв строк или укорочение при транспортировке почты не рекомендуется, но избежать этого иногда невозможно. Приложения, которые требуют длинных строк, должны каким то образом делать различие между "мягким" и "жестким" разрывом строки. Простым способом решить эту проблему является применение кодирования с помощью закавыченных строк печатных символов. |
6) |
Завершающие символы строки (SP и HT) могут быть отброшены некоторыми транспортными агентами, в то время как другие могут дополнить строки этими символами так, что все строки почтового файла обретают равную длину. На присутствие завершающих символов SP или HT рассчитывать не приходится. |
7) |
Многие почтовые домены используют вариации символьного набора US-ASCII, или работают с символьными наборами типа EBCDIC, который содержит большинство но не все символы из US-ASCII. Корректная трансляция символов в не инвариантный набор не может быть зависимой от конвертирующих шлюзов по дороге. Например, возникает проблема при пересылке информации, обработанной программой uuencodE, через сеть BITNET. Аналогичные проблемы могут возникнуть без прохода через шлюз, так как многие ЭВМ в Интернет используют символьный набор отличный от US-ASCII. Определение печатной строки в X.400 добавляет новые ограничения в некоторых специфических случаях. В частности, символами, которые могут быть пропущены через любые шлюзы, считаются 73 символа. В их число входят прописные и строчные буквы A-Z и a-z, 10 цифр - 0-9 и следующие одиннадцать специальных символов. "'" (US-ASCII десятичное значение 39) "(" (US-ASCII десятичное значение 40) ")" (US-ASCII десятичное значение 41) "+" (US-ASCII десятичное значение 43) "," (US-ASCII десятичное значение 44) "-" (US-ASCII десятичное значение 45) "." (US-ASCII десятичное значение 46) "/" (US-ASCII десятичное значение 47) ":" (US-ASCII десятичное значение 58) "=" (US-ASCII десятичное значение 61) "?" (US-ASCII десятичное значение 63) Максимально переносимое почтовое сообщение имеет короткие строки, содержащие только эти 73 с имвола. Кодирование base64 отвечает этому правилу. |
(8) |
Некоторые почтовые транспортные агенты искажают данные, которые содержат определенные символьные строки. В частности, одиночный символ точка (".") на строке может быть поврежден в некоторых SMTP реализациях, а строки, которые начинаются с пяти символов "From " (пятым символом является пробел), также могут быть повреждены. Хорошие агенты-отправители могут предотвратить эти искажения путем кодирования данных (например, в закавыченных строках печатных символов в начале строки вместо "From " используется "=46rom " и "=2E" вместо одиночной "."). |
Заметим, что приведенный выше список не является рекомендацией для почтовых транспортных агентов. В документе RFC-821 не запрещается заменять символы или разрывать длинные строки. Более того, данный список отражает негативную практику для существующих сетей и программные реализации должны быть устойчивы против таких эффектов, с которыми им придется столкнуться.
