Що таке обмеження довжини теми електронної пошти?

227

Скільки символів дозволено знаходитись у темі інтернет-електронної пошти? У мене було сканування RFC на адресу електронної пошти, але я не міг точно побачити, як довго це було дозволено. У мене є колега, який хоче програмно підтвердити її.

Якщо немає офіційного обмеження, що можна запропонувати на практиці?

email limit

— Скотт Фергюсон
джерело

17

255 - це ліміт на деякі квитки, що продаються (наприклад, Джира) і, здається, обмеження на світогляд, громовідвід і gmail, здається, скорочується після 130.

— перезавантаження

1

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

— Jasen

3

У базах даних дуже часто (традиція, яку ви можете сказати) визначати довжину не особливо довгих або коротких текстових полів як VARCHAR (255) або подібні еквівалентні імена. Якщо представлена довша рядок, вона призведе до помилки або просто буде обрізана до межі. Ось чому Jira та Outlook, як згадувалося тут, не підтримують більше символів. З міркувань сумісності я б не рекомендував 255+ Просто додав трохи крему на 5-річний торт;)

— Alph.Dev

195

Див. RFC 2822 , розділ 2.1.1 для початку.

Є два обмеження, які цей стандарт розміщує на кількості символів у рядку. Кожен рядок символів ОБОВ'ЯЗКОВО має містити не більше 998 символів, а ОБОВ'ЯЗКОВО бути не більше 78 символів, виключаючи CRLF.

Як зазначає RFC пізніше, ви можете обійти цю межу (не те, що слід), склавши тему на кілька рядків.

Кожне поле заголовка логічно являє собою один рядок символів, що включає ім'я поля, двокрапки та тіло поля. Для зручності, але для вирішення обмежень символів 998/78 на рядок, частина тіла поля заголовка може бути розділена на представлення на кілька рядків; це називається "складання". Загальне правило полягає в тому, що там, де цей стандарт дозволяє скласти пробіл (не просто символи WSP), перед будь-яким WSP може бути вставлений CRLF. Наприклад, поле заголовка:
       Subject: This is a test
може бути представлено у вигляді:
       Subject: This
        is a test

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

— Майкл Петротта
джерело

8

Поточну версію специфікації МВФ, RFC 5322, можна знайти тут: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

Ця відповідь стосується лише межі довжини рядка, а не загальної межі довжини.

— Крейда

1

Є RFC і є зручність. Стаття Якоба Нільсена Тематичні рядки електронної пошти: 5 підказок для залучення читачів підсумовують як: "Зосередьтеся на перших 40 символах. Описові та чітко написані рядки теми дозволяють одержувачам приймати зважене рішення отримати більш детальну інформацію або рухатися далі".

— Едуард Лопес

3

Для уточнення, для предметних рядків немає обмеження довжини, оскільки стандарти дозволяють заголовкам довше 998 байт, обертаючи один заголовок на стільки рядків, скільки вам подобається. Рекомендація ~ 80 символів справді є розумною. Якщо ви пишете клієнт електронної пошти, ви повинні мати можливість справлятися зі смішно довгими предметами, не розриваючись жахливим способом, бажано, усікаючи, коли відображаєтесь як частина списку.

— thomasrutter

1

... Так би було і з будь-яким іншим полем заголовка (наприклад, "Від"). PS, якщо вам цікаво, чому 78 замість 80, або чому 998 замість 1000, це тому, що стандарт електронної пошти визначає CRLF (\ r \ n) як роздільник, що становить два байти, що робить його 1000 байтами на рядок, з яких 998 сам заголовок. Також зауважте, що ім'я заголовка та будь-якого пробілу після двокрапки, наприклад "Тема:", теж має відповідати цьому.

— thomasrutter

20

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.

— Ясен
джерело

@jasen Ви знаєте інструмент для складання?

— махді

будь-яка добре написана бібліотека електронної пошти зробить це. мій улюбленийc-client

— Jasen

Це правильна відповідь. 2-а частина питання "хороша тривалість на практиці" повністю залежить від вашої програми. Якщо ви зберігаєте отримані електронні листи, вам доведеться підтримувати необмежену довжину.

— Роб

4

після деякого тесту: Якщо ви надішліть електронний лист клієнту з перспективою, а тема -> 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).

— Серхіо
джерело

5

Існує багато проблем із заданою вами темою: 1. Пробіли повинні бути закодовані символом "_", 2. "Кодоване слово" (=? Charset? Q / B? Data? =) Може бути не більше 75 символів (rfc2047). 3-й. Ви не можете уникнути нового рядка зі знаком '=' в кінці рядка (кодування заголовка QP відрізняється від тіла QP). Суть полягає в тому, що це не вина Outlook.

— Pawel Lesnikowski

2

Я не вірю, що тут існує формальний ліміт, і я впевнений, що в RFC немає жодного жорсткого обмеження, як ви знайшли.

Я думаю, що деякі досить поширені обмеження для тематичних рядків загалом (не лише електронної пошти):

80 персонажів
128 персонажів
256 персонажів

Очевидно, ви хочете придумати щось розумне. Якщо ви пишете клієнт електронної пошти, вам може знадобитися щось на зразок 256 символів і, очевидно, ретельно перевірити великі комерційні сервери там, щоб переконатися, що вони правильно обслуговують вашу пошту.

Сподіваюсь, це допомагає!

— Ед Алторфер
джерело

13

Немає конкретної причини, чому 256 краще, ніж 250, або 300, або 372. Ми вже давно використовуємо байти для довжини рядків.

— Грег Хьюгілл

4

255 - фактичний ліміт на деякі продукти (наприклад,

— Джира

5

Ця відповідь неправильна. RFC 5322, поточна версія специфікації МВФ, чітко визначає максимальну довжину лінії. Дивіться @ відповідь Майкла.

— james.garriss

2

+1 Обмеження довжини рядка є для всіх рядків повідомлення, але я не бачу нічого, що говорить про те, що ви не можете мати кілька рядків теми (маючи на увазі відсутність обмеження на кількість символів для теми). Див. 2.2.3 та приклад, який випливає безпосередньо після цього.

— Cypher

1

VARCHAR 255 - це, мабуть, найпоширеніша (і більш ефективна) довжина стовпців даних у MySQL / MariaDB. Байти, безумовно, все ще актуальні. MySQL використовуватиме 1 байт для збереження довжини, якщо вона менше 256 або більше в іншому випадку. Погляньте, як C ++ реалізує std :: string, якщо ви думаєте, що довжина рядків не має великого значення і рахується в байтах.

— ebyrob

0

Важливо, який механізм ви використовуєте для надсилання електронного листа. Більшість сучасних бібліотек (тобто System.Net.Mail) приховатимуть складку від вас. Ви просто помістите дуже довгий рядок теми електронної пошти без (CR, LF, HTAB). Якщо ви почнете намагатися робити власну складку, всі ставки вимикаються. Він почне повідомляти про помилки. Тож якщо у вас виникає ця проблема, просто відфільтруйте CR, LF, HTAB і дозвольте бібліотеці виконати роботу за вас. Зазвичай ви також можете встановити тип тексту кодування як окреме поле. Немає необхідності в кодуванні iso в рядку теми.

— каріато
джерело