Какое ограничение длины темы письма?

Сколько символов должно быть в строке темы электронной почты в Интернете? У меня было сканирование RFC для электронной почты, но я не мог точно определить, как долго это будет разрешено. У меня есть коллега, который хочет программно подтвердить это.

Если нет формального предела, какую длину на практике предложить?

См. RFC 2822 , раздел 2.1.1 для начала.

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

Как будет сказано в RFC позже, вы можете обойти это ограничение (не так, как нужно), сложив объект в несколько строк.

Каждое поле заголовка логически представляет собой одну строку символов, содержащую имя поля, двоеточие и тело поля. Для удобства, однако, и для того, чтобы справиться с ограничениями в 998/78 символов на строку, часть тела поля поля заголовка может быть разбита на многострочное представление; это называется «складывание». Общее правило заключается в том, что там, где этот стандарт допускает складывание пробелов (а не просто символов WSP), CRLF может быть вставлен перед любым WSP. Например, поле заголовка:

       Subject: This is a test

может быть представлен как:

       Subject: This
        is a test

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

RFC2322 утверждает, что заголовок темы "не имеет ограничения по длине"

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

субъект определен как "неструктурированный" в RFC 5322

вот некоторые цитаты ([...] указывают материал, который я пропустил)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

после некоторого теста: если вы отправите электронное письмо клиенту Outlook, и тема будет> 77 символов, и его необходимо использовать "=?ISO"внутри темы (в моем случае из-за акцентов), тогда OutLook «обрежет» тему в середине это и меш это все, что следует после, включая основной текст, присоединения, и т.д ... все меш!

У меня есть несколько примеров, подобных этому:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

Для того, чтобы:

Как вы видите, в строке темы он обрезал символ 78 с помощью символа "=", за которым следовали 2 или 3 перевода строки, а затем продолжил с остальной темой.

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

Если у вас нет ISO, это не повредит, но если вы добавите его в свой предмет, чтобы быть в курсе RFC, то вы получите этот сюрприз от OutLook. Если вы не добавите ISO-образы, то электронная почта iPhone не поймет этого (и прикрепить файлы с именами, используя такие символы, не будет работать на iPhone).

Я не верю, что здесь есть формальный предел, и я почти уверен, что в RFC также не указан жесткий предел, как вы обнаружили.

Я думаю, что некоторые довольно общие ограничения для строк темы вообще (не только электронная почта):

• 80 персонажей
• 128 персонажей
• 256 символов

Очевидно, вы хотите придумать что-то разумное. Если вы пишете почтовый клиент, вы можете использовать что-то вроде 256 символов и, очевидно, провести тщательный тест на больших коммерческих серверах, чтобы убедиться, что они обслуживают вашу почту правильно.

Надеюсь это поможет!

Важно то, какой механизм вы используете, чтобы отправить электронное письмо. Большинство современных библиотек (например, System.Net.Mail) скрывают от вас сворачивание. Вы просто вставили очень длинную строку темы письма без (CR, LF, HTAB). Если вы начинаете пытаться сделать свой собственный фолд, все ставки сняты. Это начнет сообщать об ошибках. Поэтому, если у вас возникла эта проблема, просто отфильтруйте CR, LF, HTAB и дайте библиотеке сделать всю работу за вас. Обычно вы также можете установить тип текста кодирования в виде отдельного поля. Нет необходимости в iso-кодировании в строке темы.