Quelle est la limite de longueur du sujet des e-mails?

227

Combien de caractères sont autorisés à figurer dans la ligne d'objet du courrier électronique Internet? J'ai eu une analyse du RFC pour le courrier électronique, mais je ne pouvais pas voir précisément combien de temps il était autorisé à être. J'ai un collègue qui veut le valider par programme.

S'il n'y a pas de limite formelle, quelle longueur suggérer dans la pratique?

email limit

— Scott Ferguson
source

17

255 est la limite sur certains produits de billetterie (Jira par exemple) et semble être la limite sur Outlook, Thunderbird et Gmail semblent tronquer après 130.

— Reconbot

1

RFC2047 est mieux adapté à la validation, je vois beaucoup de logiciels de publipostage en vrac produisant du contenu RFC2047 invalide.

— Jasen

3

Dans les bases de données, il est très courant (une tradition peut-on dire) de définir la longueur des champs textuels pas particulièrement longs ou courts comme VARCHAR (255) ou des noms équivalents similaires. Si une chaîne plus longue est présentée, elle générera une erreur ou sera simplement tronquée à la limite. C'est pourquoi Jira et Outlook, comme mentionné ici, ne prennent pas en charge plus de caractères. Pour des raisons de compatibilité, je ne recommanderais pas 255+ Ajouter simplement de la crème sur le gâteau de 5 ans;)

— Alph.Dev

195

Voir RFC 2822 , section 2.1.1 pour commencer.

Il y a deux limites que cette norme place sur le nombre de caractères dans une ligne. Chaque ligne de caractères NE DOIT PAS dépasser 998 caractères et DEVRAIT ne pas dépasser 78 caractères, à l'exclusion du CRLF.

Comme le RFC l'indique plus tard, vous pouvez contourner cette limite (pas que vous devriez) en pliant le sujet sur plusieurs lignes.

Chaque champ d'en-tête est logiquement une seule ligne de caractères comprenant le nom du champ, les deux points et le corps du champ. Cependant, pour des raisons de commodité et pour faire face aux limitations de 998/78 caractères par ligne, la partie corps de champ d'un champ d'en-tête peut être divisée en une représentation sur plusieurs lignes; c'est ce qu'on appelle le "pliage". La règle générale est que partout où cette norme permet de plier des espaces blancs (pas simplement des caractères WSP), un CRLF peut être inséré avant tout WSP. Par exemple, le champ d'en-tête:
       Subject: This is a test
peut être représenté comme:
       Subject: This
        is a test

La recommandation pour un maximum de 78 caractères dans l'en-tête du sujet semble raisonnable. Personne ne veut faire défiler pour voir la ligne d'objet entière, et quelque chose d'important pourrait être coupé à droite.

— Michael Petrotta
source

8

La version actuelle de la spécification du FMI, RFC 5322, peut être trouvée ici: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

Cette réponse ne concerne que la limite de longueur de ligne, pas la limite de longueur globale.

— Chalky

1

Il y a la RFC et la convivialité. Article de Jakob Nielsen Les lignes d'objet de l'e-mail: 5 conseils pour attirer les lecteurs se résument comme suit: "Concentrez-vous sur les 40 premiers caractères. Les lignes d'objet descriptives et bien écrites permettent aux destinataires de prendre une décision éclairée pour obtenir plus de détails ou continuer."

— Édouard Lopez

3

Pour clarifier, il n'y a pas de limite de longueur pour les lignes d'objet, car les normes autorisent les en-têtes de plus de 998 octets en enveloppant un seul en-tête sur autant de lignes que vous le souhaitez. La recommandation de ~ 80 caractères est en effet raisonnable. Si vous écrivez un client de messagerie, vous devez être en mesure de faire face à des sujets ridiculement longs sans casser de façon horrible, de préférence par troncature lors de l'affichage dans le cadre d'une liste.

— thomasrutter

1

... Ce serait le cas avec tout autre champ d'en-tête (par exemple "De"). PS si vous vous demandez pourquoi 78 au lieu de 80, ou pourquoi 998 au lieu de 1000, c'est parce que la norme de messagerie spécifie CRLF (\ r \ n) comme séparateur, qui est de deux octets, ce qui en fait 1000 octets par ligne dont 998 est l'en-tête lui-même. Notez également que le nom de l'en-tête et tout espace après les deux-points, par exemple "Objet:", doivent également y figurer.

— thomasrutter

20

La RFC2322 indique que l'en-tête du sujet "n'a pas de restriction de longueur"

mais pour produire de longs en-têtes, mais vous devez le diviser sur plusieurs lignes, un processus appelé "pliage".

le sujet est défini comme "non structuré" dans la RFC 5322

voici quelques citations ([...] indiquent des choses que j'ai omises)

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
source

@jasen connaissez-vous un outil de pliage?

— mahdi

n'importe quelle bibliothèque de courriels bien écrite le fera. mon préféré estc-client

— Jasen

Ceci est la bonne réponse. La 2ème partie de la question "bonne longueur dans la pratique" dépend totalement de votre application. Si vous enregistrez des e-mails reçus, vous devez prendre en charge des longueurs illimitées.

— Rob

4

après quelques tests: si vous envoyez un e-mail à un client Outlook et que le sujet est> 77 caractères, et qu'il doit être utilisé "=?ISO"à l'intérieur du sujet (dans mon cas à cause des accents), alors OutLook "coupera" le sujet au milieu de et maillez tout ce qui vient après, y compris le corps du texte, les pièces jointes, etc ... tout un maillage!

J'ai plusieurs exemples comme celui-ci:

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".?=

À:

Comme vous le voyez, dans la ligne d'objet, il a coupé le caractère 78 avec un "=" suivi de 2 ou 3 sauts de ligne, puis a continué avec le reste du sujet.

Il m'a été signalé par plusieurs clients qui utilisaient tous OutLook, d'autres clients de messagerie s'occupent de ces sujets.

Si vous n'avez pas d'ISO dessus, ça ne fait pas de mal, mais si vous l'ajoutez à votre sujet pour être sympa avec RFC, alors vous obtenez cette surprise d'OutLook. Si vous n'ajoutez pas les ISO, les e-mails de l'iPhone ne le comprendront pas (et joindre des fichiers avec des noms utilisant de tels caractères ne fonctionnera pas sur les iPhones).

— Sergio
source

5

Il y a beaucoup de problèmes avec le sujet que vous définissez: 1. Les espaces doivent être encodés avec '_', 2. Un 'mot encodé' (=? Charset? Q / B? Data? =) Ne doit pas dépasser 75 caractères (rfc2047). 3e Vous ne pouvez pas échapper à la nouvelle ligne avec le caractère '=' à la fin de la ligne (l'encodage QP de l'en-tête est différent de celui du corps QP). En bout de ligne: ce n'est pas la faute d'Outlook.

— Pawel Lesnikowski

2

Je ne crois pas qu'il y ait une limite formelle ici, et je suis à peu près sûr qu'il n'y a pas non plus de limite stricte spécifiée dans la RFC, comme vous l'avez constaté.

Je pense que certaines limitations assez courantes pour les lignes d'objet en général (pas seulement les e-mails) sont:

80 personnages
128 caractères
256 caractères

Évidemment, vous voulez trouver quelque chose de raisonnable. Si vous écrivez un client de messagerie, vous voudrez peut-être utiliser quelque chose comme 256 caractères, et évidemment tester minutieusement contre les gros serveurs commerciaux là-bas pour vous assurer qu'ils servent correctement votre courrier.

J'espère que cela t'aides!

— Ed Altorfer
source

13

Il n'y a aucune raison particulière pour laquelle 256 est meilleur que 250, ou 300 ou 372. Nous avons depuis longtemps utilisé les octets pour les longueurs de chaîne.

— Greg Hewgill

4

255 est la limite réelle de certains produits (Jira et Outlook par exemple)

— reconbot

5

Cette réponse est fausse. La RFC 5322, la version actuelle des spécifications du FMI, définit clairement une longueur de ligne maximale. Voir la réponse de @ Michael.

— james.garriss

2

+1 La limite de longueur de ligne s'applique à toutes les lignes du message, mais je ne vois rien qui dise que vous ne pouvez pas avoir un sujet sur plusieurs lignes (ce qui n'implique aucune limitation sur le nombre de caractères pour le sujet). Voir 2.2.3 et l'exemple qui suit directement après.

— Cypher

1

VARCHAR 255 est probablement la longueur de colonne de données la plus courante (et la plus efficace) dans MySQL / MariaDB. Les octets sont certainement toujours pertinents. MySQL utilisera 1 octet pour stocker la longueur si elle est inférieure à 256, ou plus sinon. Jetez un œil à la façon dont C ++ implémente std :: string si vous pensez que les longueurs de chaîne ne sont pas très importantes et sont comptées en octets.

— ebyrob

0

Ce qui est important, c'est le mécanisme que vous utilisez pour envoyer l'e-mail. La plupart des bibliothèques modernes (c'est-à-dire System.Net.Mail) vous cacheront le pliage. Vous venez de mettre une très longue ligne d'objet de courrier électronique sans (CR, LF, HTAB). Si vous commencez à essayer de faire votre propre pliage, tous les paris sont désactivés. Il commencera à signaler des erreurs. Donc, si vous rencontrez ce problème, filtrez le CR, LF, HTAB et laissez la bibliothèque faire le travail pour vous. Vous pouvez généralement également définir le type de texte d'encodage comme un champ distinct. Pas besoin d'encodage iso dans la ligne d'objet.

— kariato
source