Qual è il limite di lunghezza dell'oggetto dell'e-mail?

227

Quanti caratteri sono ammessi nella riga dell'oggetto dell'e-mail Internet? Ho fatto una scansione di The RFC per e-mail, ma non sono riuscito a vedere in particolare quanto tempo è stato concesso. Ho un collega che vuole validare a livello di programmazione.

Se non esiste un limite formale, qual è in pratica una buona lunghezza da suggerire?

email limit

— Scott Ferguson
fonte

17

255 è il limite di alcuni prodotti di ticketing (ad esempio Jira) e sembra essere il limite delle prospettive, thunderbird e gmail sembrano

— troncarsi

1

RFC2047 è più adatto alla convalida, vedo molti software di invio collettivo che producono contenuti RFC2047 non validi.

— Jasen,

3

Nei database è molto comune (una tradizione si può dire) definire la lunghezza di campi testuali non particolarmente lunghi o brevi come VARCHAR (255) o nomi equivalenti simili. Se viene presentata una stringa più lunga, genererà un errore o semplicemente verrà troncata al limite. Ecco perché Jira e Outlook, come menzionato qui, non supportano più caratteri. Per motivi di compatibilità, non consiglierei 255+ solo aggiungendo un po 'di crema sulla torta di 5 anni;)

— Alph.Dev

195

Vedere RFC 2822 , sezione 2.1.1 per iniziare.

Esistono due limiti che questo standard pone sul numero di caratteri in una riga. Ogni riga di caratteri DEVE essere non più di 998 caratteri e DOVREBBE non essere più di 78 caratteri, escluso il CRLF.

Come afferma la RFC in seguito, puoi aggirare questo limite (non che dovresti) piegando il soggetto su più righe.

Ogni campo di intestazione è logicamente una singola riga di caratteri che comprende il nome del campo, i due punti e il corpo del campo. Per comodità, tuttavia, e per gestire i limiti di carattere 998/78 per riga, la parte del corpo di campo di un campo di intestazione può essere suddivisa in una rappresentazione a più righe; questo si chiama "pieghevole". La regola generale è che ovunque questo standard consenta di piegare gli spazi bianchi (non semplicemente i caratteri WSP), un CRLF può essere inserito prima di qualsiasi WSP. Ad esempio, il campo dell'intestazione:
       Subject: This is a test
può essere rappresentato come:
       Subject: This
        is a test

La raccomandazione per non più di 78 caratteri nell'intestazione del soggetto sembra ragionevole. Nessuno vuole scorrere per vedere l'intera riga dell'oggetto e qualcosa di importante potrebbe essere tagliato a destra.

— Michael Petrotta
fonte

8

La versione corrente delle specifiche del FMI, RFC 5322, è disponibile qui: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

Questa risposta riguarda solo il limite di lunghezza della linea, non il limite di lunghezza complessiva.

— Gessoso

1

C'è RFC e c'è usabilità. Articolo di Jakob Nielsen Righe oggetto dell'e-mail: 5 consigli per attirare i lettori riassumono come: "Concentrati sui primi 40 caratteri. Le righe dell'oggetto descrittive e ben scritte consentono ai destinatari di prendere una decisione informata per ottenere maggiori dettagli o andare avanti".

— Édouard Lopez,

3

Per chiarire, non esiste un limite di lunghezza per le righe dell'oggetto, poiché gli standard consentono alle intestazioni più lunghe di 998 byte avvolgendo una singola intestazione su tutte le righe che desideri. La raccomandazione di ~ 80 caratteri è davvero ragionevole. Se si sta scrivendo un client di posta si deve essere in grado di far fronte a soggetti ridicolmente lunghi senza rompere in un modo orribile, preferibilmente per troncamento quando mostra come parte di una lista.

— thomasrutter,

1

... Questo sarebbe il caso anche di qualsiasi altro campo di intestazione (ad es. "Da"). PS se ti stai chiedendo perché 78 invece di 80 o perché 998 invece di 1000, è perché lo standard di posta elettronica specifica CRLF (\ r \ n) come separatore, che è di due byte, rendendolo 1000 byte per riga di cui 998 è l'intestazione stessa. Si noti anche che il nome dell'intestazione e qualsiasi spazio dopo i due punti, ad esempio "Oggetto:", devono adattarsi anche a questo.

— thomasrutter,

20

RFC2322 afferma che l'intestazione del soggetto "non ha limiti di lunghezza"

ma per produrre intestazioni lunghe, ma è necessario dividerlo su più righe, un processo chiamato "pieghevole".

il soggetto è definito come "non strutturato" in RFC 5322

ecco alcune citazioni ([...] indicano cose che ho omesso)

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
fonte

@jasen conosci uno strumento per piegare?

— Mahdi,

qualsiasi libreria di posta elettronica ben scritta lo farà. il mio preferito èc-client

— Jasen il

Questa è la risposta corretta La seconda parte della domanda "buona pratica" dipende totalmente dalla tua app. Se stai salvando le email ricevute, devi supportare lunghezze illimitate.

— Rob,

4

dopo alcuni test: se invii un'email a un client Outlook, l'oggetto è> 77 caratteri e deve essere utilizzato "=?ISO"all'interno dell'oggetto (nel mio caso a causa di accenti), OutLook "taglierà" l'oggetto nel mezzo di e maglie tutto ciò che viene dopo, incluso il testo del corpo, gli allegati, ecc ... tutta una maglia!

Ho diversi esempi come questo:

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

Per:

Come vedi, nella riga dell'oggetto è stato tagliato sul carattere 78 con un "=" seguito da 2 o 3 avanzamenti di riga, quindi è proseguito male con il resto del soggetto.

Mi è stato riferito da diversi clienti che in tutti i casi in cui utilizzano OutLook, altri client di posta elettronica trattano bene tali argomenti.

Se non hai ISO su di esso, non fa male, ma se lo aggiungi al tuo soggetto per essere gentile con RFC, allora ottieni questa sorpresa da OutLook. Bit se non aggiungi gli ISO, quindi l'e-mail di iPhone non lo capirà (e allega file con nomi usando tali caratteri non funzionerà su iPhone).

— Sergio
fonte

5

Esistono molti problemi con l'oggetto impostato: 1. Gli spazi devono essere codificati con '_', 2. Una 'parola codificata' (=? Charset? Q / B? Data? =) Non può essere più lunga di 75 caratteri (RFC2047). 3 ° Non è possibile uscire da una nuova riga con il carattere '=' alla fine della riga (la codifica QP dell'intestazione è diversa dal QP del corpo). La linea di fondo è: non è colpa di Outlook.

— Pawel Lesnikowski,

2

Non credo che ci sia un limite formale qui, e sono abbastanza sicuro che non ci sia alcun limite rigido specificato nell'RFC, come hai scoperto.

Penso che alcune limitazioni piuttosto comuni per le righe dell'oggetto in generale (non solo la posta elettronica) siano:

80 personaggi
128 personaggi
256 personaggi

Ovviamente, vuoi trovare qualcosa di ragionevole. Se stai scrivendo un client di posta elettronica, potresti voler scegliere qualcosa come 256 caratteri e ovviamente testare a fondo i grandi server commerciali là fuori per assicurarti che servano correttamente la tua posta.

Spero che questo ti aiuti!

— Ed Altorfer
fonte

13

Non vi è alcun motivo particolare per cui 256 sia migliore di 250, o 300 o 372. Da tempo usiamo i byte per le lunghezze delle stringhe.

— Greg Hewgill,

4

255 è il limite effettivo di alcuni prodotti (ad esempio Jira e Outlook)

— riconciliare il

5

Questa risposta è sbagliata RFC 5322, l'attuale versione delle specifiche del FMI, definisce chiaramente una lunghezza massima della linea. Vedi la risposta di @Michael.

— james.garriss,

2

+1 La limitazione della lunghezza della riga è per tutte le righe del messaggio, ma non vedo nulla che dica che non puoi avere un oggetto su più righe (senza implicare alcuna limitazione sul numero di caratteri per l'oggetto). Vedi 2.2.3 e l'esempio che segue subito dopo.

— Cypher

1

VARCHAR 255 è probabilmente la lunghezza della colonna di dati più comune (e più efficiente) in MySQL / MariaDB. I byte sono sicuramente ancora rilevanti. MySQL utilizzerà 1 byte per memorizzare la lunghezza se è inferiore a 256 o più altrimenti. Dai un'occhiata a come C ++ implementa std :: string se pensi che le lunghezze delle stringhe non siano molto importanti e contino in byte.

— ebyrob

0

L'importante è quale meccanismo stai usando per inviare l'e-mail. La maggior parte delle librerie moderne (ad es. System.Net.Mail) ti nasconderà la piegatura. Hai appena inserito una riga dell'oggetto email molto lunga senza (CR, LF, HTAB). Se inizi a provare a fare il tuo fold, tutte le scommesse sono disattivate. Inizierà a segnalare errori. Quindi se stai riscontrando questo problema basta filtrare CR, LF, HTAB e lasciare che la libreria faccia il lavoro per te. Di solito è anche possibile impostare il tipo di testo di codifica come campo separato. Non è necessaria la codifica ISO nella riga dell'oggetto.

— kariato
fonte