В RFC 2822 (определение электронной почты) определено, что ни одна строка НЕ ДОЛЖНА быть длиннее 78 символов (исключая CRLF) и ДОЛЖНА быть не длиннее 998 символов. При использовании цитируемой печати более длинные строки будут разбиты на большее количество строк, каждая из которых будет заканчиваться знаком '=', пока не будет достигнут реальный разрыв строки. Соответствует ли письмо стандарту, если оно содержит строки длиной более 78 (или 998) символов, но закодировано с помощью quoted-printable?
Есть аргументы, что это не соответствует требованиям, потому что получающий почтовый клиент имеет более длинные строки после декодирования цитируемого сообщения.
РЕДАКТИРОВАТЬ: Чтобы прояснить вопрос так, как задал Дэвид Кэри: Да, я имею в виду, что закодированная почта с цитатой должна быть совместима с цитируемой печатью, что означает, что строки не длиннее 76 символов. Но декодированные сообщения могут иметь более длинные строки, чем это ограничение. Итак, мой вопрос: предполагается ли, что клиентское программное обеспечение, реализующее RFC 1521, обрабатывает бесконечно длинные строки после декодирования текстового содержимого в кавычках? На данный момент на оба ответа дан положительный ответ (спасибо) с ограничением, что это не рекомендуется Сетевым этикетом (RFC 1855). Но сетевой этикет даже ограничивает длину строки 65 символами - ограничения, которого почти никто не придерживается.
Это определенно соответствует требованиям. Весь смысл Quoted-Printable и остальных RFC серии MIME (от RFC 2045 до RFC 2049) состоит в том, чтобы разрешить кодирование данных, которые в противном случае не были бы действительны в электронной почте. RFC 2822 явно (и неоднократно!) Указывает читателям на эти RFC для получения информации о том, как это сделать.
Я не уверен, о чем вы спрашиваете:
получающий почтовый клиент находит длинные строки перед декодированием в кавычки
Скажем, программа кодирования с возможностью печати в кавычках на передающей стороне просто цитирует непечатаемые буквы, делая результирующую закодированную строку длиннее, чем исходная строка, без добавления «мягких разрывов строк», в результате чего закодированная строка длиннее предела.
Это не соответствует требованиям.
Строки закодированных данных в кавычках не должны быть длиннее 76 символов. Чтобы удовлетворить это требование без изменения закодированного текста, могут быть добавлены мягкие разрывы строк ... Эти мягкие разрывы строк также позволяют кодировать текст без разрывов строк (или содержащих очень длинные строки) для среды, в которой размер строки ограничен, например " 1000 символов в строке »для некоторых программ SMTP, как это разрешено RFC 2821.
- Википедия: цитируется-для печати, перефразируя RFC2045 Стр.21.
закодированные строки короткие, но получающий почтовый клиент находит длинные строки после декодирования в кавычках
Это соответствует RFC2822 и RFC2045 и должно поддерживаться всем программным обеспечением.
Тем не менее, создание таких сообщений не поощряется несколькими Правилами сетевого этикета, включая страницу 3 из RFC 1855 «Правила сетевого этикета».
Если вы действительно хотите знать, насколько сложно создать совместимый составитель и парсер электронной почты, тогда вы должен посмотрите это видео на Youtube: http://www.youtube.com/watch?v=JENdgiAPD6c
Рикардо Сигнес дает представление о различных RFC и о том, какую глупость они привносят в реальную жизнь.
Он длится 40 минут и лишь поверхностно описывает плохое и хорошее "содержание" электронной почты. После просмотра вы измените свое мнение о программном обеспечении электронной почты, которое, по вашему мнению, соответствует стандартам электронной почты.