Ответ 1

RFC 2646 говорит:

Тип текстового/обычного носителя - это самый низкий общий знаменатель электронной почты в Интернете с строками не более 997 символов (обычно не более 80)

Другой популярный стандарт - обернуть 72 символами. Это относится ко многим консольным приложениям (например, EDIT и многим интерфейсам BBS), которые отображают текст в окне "ASCII", включая рамку и полосу прокрутки, что позволяет отображать чуть менее 80 символов.

Ответ 2

Обычно для обертывания строк на 72 (80 также распространено, но это означает, что он будет превышать 80 при цитировании) для обработки хотя бы одного или двух уровней цитаты. Существует "текстовый/потоковый" тип MIME, что означает, что клиент будет обертывать текст сам по границам окна, но не так, чтобы многие клиенты его поддерживали. Просто настройте свой редактор на 72, и вы будете в безопасности и удобочитаемы большинством людей.

EDIT: точный тип text/plain с добавлением format=flowed следующим образом:

Content-Type: text/plain; format=flowed

Для пояснения см. rfc2646.

HTML-почту следует избегать IMNSHO, не все читают почту в браузере или имеют почтовые клиенты с поддержкой HTML. Большинство причин использовать HTML (обогащение почты с подчеркиванием, жирным шрифтом и т.д.) Можно эмулировать. HTML не нужно обертывать, так как клиент будет адаптироваться к размеру окна.

Альтернативой HTML является "текстовый/обогащенный" тип MIME, который дает вам большинство преимуществ почтовых сообщений HTML без хлопот, но опять же может не поддерживаться везде.

Смотрите здесь для текста/обогащенного.

Ответ 3

Google утверждает результаты 1 - 10 о...

3,160 for +word +wrap +email +"80 characters"
2,820 for +word +wrap +email +"50 characters"
1,790 for +word +wrap +email +"60 characters"
1,720 for +word +wrap +email +"70 characters"
1,540 for +word +wrap +email +"100 characters"
1,250 for +word +wrap +email +"65 characters"
1,120 for +word +wrap +email +"40 characters"
  962 for +word +wrap +email +"75 characters"
  836 for +word +wrap +email +"72 characters"

Ответ 4

Я часто получаю ответы на вопросы по электронной почте:

[Format recovered--see http://www.lemis.com/grog/email/email-format.php]

который я получил от Грега Лехи. Часть эта страница говорит:

Очевидно, что должен быть какой-то способ указать, что текст сообщения не должен быть обернут. Этот текст/равнина. Существуют специальные типы вложений MIME, которые позволяют обертывать, хотя я все еще думаю, что это плохая идея. Если вы укажете, что ваше сообщение может быть обернуто, вы делаете предположение о том, как выглядит экран приемника. Даже если вы правы некоторое время, вы не можете быть правы все время. Например, у одного человека может быть экран шириной 200 символов, чтобы иметь возможность отображать записи в длинном журнале, но он не захочет долго видеть его текст.

Ответ 5

Хороший почтовый API, такой как JavaMail, сделает это за вас. В идеале вам не нужно было бы подробно обсуждать эту проблему.

Ответ 6

RFC 5322

http://tools.ietf.org/html/rfc5322#section-2.1.1

2.1.1. Линейные пределы длины

Существует два ограничения, которые эта спецификация устанавливает на количество    символов в строке. Каждая строка символов ДОЛЖНА быть не более    998 символов, и ДОЛЖНО быть не более 78 символов, исключая    CRLF.

Предел 998 символов обусловлен ограничениями во многих реализациях    которые отправляют, получают или хранят сообщения МВФ, которые просто не могут обрабатывать    более 998 символов на линии. Получение реализаций    делать хорошо, чтобы обрабатывать произвольно большое количество символов в строке    ради надежности. Однако существует так много реализаций, которые    (в соответствии с транспортными требованиями [RFC5321]) не    принимать сообщения, содержащие более 1000 символов, включая CR    и LF на строку, важно, чтобы реализации не создавали    такие сообщения.

Более консервативная 78-значная рекомендация    многие реализации пользовательских интерфейсов, которые отображают эти    сообщения, которые могут усекать или катастрофически обернуть отображение    более 78 символов в строке, несмотря на то, что такие    реализации несовместимы с намерением этого    спецификации (и RFC5321), если они действительно вызывают    информация будет потеряна). Опять же, хотя это ограничение ставится    на сообщениях, это зависит от реализаций, которые отображают    сообщений для обработки произвольно большого количества символов в    (конечно, по крайней мере, до предела 998 символов) ради    надежности.

См. также: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 и RFC6838 для спецификаций MIME.

Это весело читать RFC. Вы знаете, что вам это нравится: -)

Ответ 7

Как правило, вы должны обернуть на 80 или немного меньше, чтобы позволить темным клиентам процитировать без упаковки.

Ответ 8

Не использовал linewrap, пока я не переключился на mutt/xterm (никогда не оглядываясь назад).

Ответ 9

Оберните первый символ пробела перед 72-й позицией или в 72-й позиции, если его нет. В Eudora, когда я использовал его, соглашение заключалось в том, чтобы оставить пробел в конце строки, указав, что оно было завернуто, поэтому оно будет сигнализировать, что принимающий клиент повторно передает абзац, где он нужен, в зависимости от ширины клиентское окно. Я не уверен, что это происходит в текущих почтовых клиентах.