web-dev-qa-db-fra.com

Quelle est la longueur maximale du sujet de l'e-mail?

Combien de caractères sont autorisés à figurer dans l'objet du courrier électronique Internet? J'ai eu un scan de La RFC pour le courrier électronique mais je ne pouvais pas voir précisément combien de temps il était permis. J'ai un collègue qui veut valider par programme pour cela.

S'il n'y a pas de limite formelle, quelle est la bonne longueur à suggérer dans la pratique? À votre santé,

email
204
Scott Ferguson

Voir RFC 2822 , section 2.1.1 pour commencer.

Il y a deux limites à cela places standard sur le nombre de caractères dans une ligne. Chaque ligne de les caractères NE DOIVENT PAS être plus de 998 caractères, et ne devrait pas être plus que 78 caractères, à l'exclusion du CRLF.

Comme le RFC l'indiquera plus tard, vous pouvez contourner cette limite (pas comme il convient) en repliant le sujet sur plusieurs lignes.

Chaque champ d'en-tête est logiquement un ligne unique de caractères comprenant le nom du champ, les deux points et le corps de champ. Pour plus de commodité, cependant et traiter avec le caractère 998/78 limitations par ligne, le corps du champ une partie d'un champ d'en-tête peut être fractionnée en une représentation multiligne; c'est ce qu'on appelle "plier". Le général règle est que partout où cette norme permet de plier des espaces (pas simplement des caractères WSP), un CRLF peut être inséré avant tout WSP. Pour 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 l'écran pour voir l'intégralité de la ligne d'objet, et quelque chose d'important risque d'être coupé du côté droit.

177
Michael Petrotta

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

mais pour produire de longs en-têtes mais vous devez le scinder 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.
14
Jasen

après certains tests: si vous envoyez un courrier électronique à un client Outlook et que le sujet est> 77 caractères, et qu'il doit utiliser "=?ISO" dans le sujet (dans mon cas, à cause des accents), Outlook "coupera" le sujet au milieu. et maille tout ce qui vient après, y compris le corps du texte, attache, 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 de sujet, il coupait le caractère 78 avec un "=" suivi de 2 ou 3 sauts de ligne, puis continuait avec le reste du sujet.

Il m'a été rapporté par plusieurs clients qui utilisaient tous Outlook, d'autres clients de messagerie traitent ces sujets correctement.

Si vous ne possédez aucune image ISO, cela ne fait pas mal, mais si vous l'ajoutez à votre sujet pour qu'il soit sympa à RFC, vous obtenez cette surprise d'Outlook. Si vous n’ajoutez pas les images ISO, l’e-mail de l’iPhone ne le comprendra pas (et les fichiers joints contenant des noms contenant de tels caractères ne fonctionneront pas sur les iPhones).

4
Sergio

Je ne crois pas qu'il existe une limite formelle ici, et je suis à peu près sûr que la RFC ne spécifie pas non plus de limite stricte, comme vous l'avez constaté.

Je pense que certaines limitations assez communes pour les lignes d'objet en général (pas seulement le courrier électronique) sont:

  • 80 caractères
  • 128 caractères
  • 256 caractères

De toute évidence, vous voulez proposer quelque chose qui est raisonnable. Si vous écrivez un client de messagerie, vous voudrez peut-être utiliser quelque chose comme 256 caractères, et bien évidemment tester à fond contre les gros serveurs commerciaux pour vous assurer qu'ils servent votre courrier correctement.

J'espère que cela t'aides!

2
Ed Altorfer

L'important est de savoir quel mécanisme 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 ouverts. Il va commencer à signaler des erreurs. Donc, si vous rencontrez ce problème, il vous suffit de filtrer CR, LF, HTAB et laissez la bibliothèque faire le travail à votre place. Vous pouvez généralement également définir le type de texte d'encodage en tant que champ séparé. Pas besoin de codage ISO dans la ligne d'objet. 

0
kariato