Qual é o limite de tamanho do assunto do email?


227

Quantos caracteres podem estar na linha de assunto do email da Internet? Eu fiz uma varredura no The RFC por e-mail, mas não pude ver especificamente quanto tempo isso poderia ter. Eu tenho um colega que deseja validar programaticamente por isso.

Se não há limite formal, qual é um bom comprimento na prática para sugerir?


17
255 é o limite em alguns produtos de bilhética (Jira por exemplo) e parece ser o limite para o Outlook, Thunderbird e gmail parecem truncar após 130.
reconbot

1
O RFC2047 é mais adequado para validação; vejo muitos softwares de envio em massa produzindo conteúdo RFC2047 inválido.
Jasen

3
Nos bancos de dados, é muito comum (uma tradição que você pode dizer) definir o comprimento de campos de texto não muito longos ou curtos como VARCHAR (255) ou nomes equivalentes semelhantes. Se uma string mais longa for apresentada, ela gerará um erro ou simplesmente será truncada até o limite. É por isso que o Jira e o Outlook, conforme mencionado aqui, não suportam mais caracteres. Por motivos de compatibilidade, eu não recomendaria 255+ Basta adicionar um pouco de creme no bolo de 5 anos;)
Alph.Dev

Respostas:


195

Veja RFC 2822 , seção 2.1.1 para iniciar.

Existem dois limites que esse padrão coloca no número de caracteres em uma linha. Cada linha de caracteres deve ter no máximo 998 caracteres e DEVE ter no máximo 78 caracteres, excluindo o CRLF.

Como a RFC indica posteriormente, você pode contornar esse limite (não é o que deveria) dobrando o assunto em várias linhas.

Cada campo de cabeçalho é logicamente uma única linha de caracteres que compreende o nome do campo, os dois pontos e o corpo do campo. Por conveniência, porém, e para lidar com as limitações de 998/78 caracteres por linha, a parte do corpo do campo de um campo de cabeçalho pode ser dividida em uma representação de várias linhas; isso é chamado de "dobrável". A regra geral é que sempre que esse padrão permitir dobrar espaços em branco (não apenas caracteres WSP), um CRLF poderá ser inserido antes de qualquer WSP. Por exemplo, o campo do cabeçalho:

       Subject: This is a test

pode ser representado como:

       Subject: This
        is a test

A recomendação para não mais que 78 caracteres no cabeçalho do assunto parece razoável. Ninguém quer rolar para ver toda a linha de assunto, e algo importante pode ser cortado à direita.


8
A versão atual da especificação FMI, RFC 5322, pode ser encontrada aqui: tools.ietf.org/html/rfc5322#section-2.1.1
james.garriss

6
Esta resposta aborda apenas o limite de comprimento da linha, não o limite geral de comprimento.
Chalky

1
Existe RFC e há usabilidade. Artigo de Jakob Nielsen Email Subject Lines: 5 dicas para atrair leitores resumem como: "Concentre-se nos primeiros 40 caracteres. Linhas de assunto descritivas e bem escritas permitem que os destinatários tomem uma decisão informada para obter mais detalhes ou seguir em frente".
Édouard Lopez

3
Para esclarecer, não há limite de comprimento para as linhas de assunto, pois os padrões permitem cabeçalhos com mais de 998 bytes, envolvendo um único cabeçalho em quantas linhas você desejar. A recomendação de ~ 80 caracteres é de fato razoável. Se você está escrevendo um cliente de e-mail, precisa lidar com assuntos ridiculamente longos sem quebrar de maneira horrível, de preferência por truncamento quando exibido como parte de uma lista.
thomasrutter

1
... Esse também seria o caso de qualquer outro campo de cabeçalho (por exemplo, "De"). PS: se você está se perguntando por que 78 em vez de 80 ou por 998 em vez de 1000, é porque o padrão de email especifica CRLF (\ r \ n) como separador, que é de dois bytes, perfazendo 1000 bytes por linha dos quais 998 é o próprio cabeçalho. Observe também que o nome do cabeçalho e qualquer espaço após os dois pontos, por exemplo, "Assunto:" também deve se encaixar nisso.
thomasrutter

20

RFC2322 afirma que o cabeçalho do assunto "não possui restrição de comprimento"

mas para produzir cabeçalhos longos, é necessário dividi-lo em várias linhas, um processo chamado "dobrar".

assunto é definido como "não estruturado" na RFC 5322

aqui estão algumas citações ([...] indicam coisas que eu omiti)

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 você conhece uma ferramenta para dobrar?
Mahdi

qualquer biblioteca de email bem escrita fará isso. meu favorito éc-client
Jasen

Essa é a resposta correta. A segunda parte da pergunta "bom comprimento na prática" depende totalmente do seu aplicativo. Se você estiver salvando e-mails recebidos, precisará oferecer comprimentos ilimitados.
Rob

4

após algum teste: se você enviar um email para um cliente do Outlook, e o assunto for> 77 caracteres, e ele precisar ser usado "=?ISO"dentro do assunto (no meu caso por causa de sotaques), o OutLook "cortará" o assunto no meio do e malha tudo o que vem depois, incluindo o texto do corpo, anexa, etc ... tudo uma malha!

Eu tenho vários exemplos como este:

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

Para:

Como você vê, na linha de assunto foi cortado no caractere 78 com um "=" seguido de 2 ou 3 alimentações de linha, depois continuou com o restante do assunto de maneira incorreta.

Foi relatado a mim por vários clientes que, todos usando o Outlook, outros clientes de email lidam com esses assuntos ok.

Se você não tem ISO, não faz mal, mas se você o adiciona ao assunto para ser agradável com a RFC, você obtém essa surpresa do OutLook. Pouco se você não adicionar os ISOs, o e-mail do iPhone não o entenderá (e anexar arquivos com nomes usando esses caracteres não funcionará nos iPhones).


5
Existem muitos problemas com o assunto que você define: 1. Os espaços devem ser codificados com '_', 2. Uma 'palavra codificada' (=? Charset? Q / B? Data? =) Não pode ter mais de 75 caracteres (rfc2047). 3º Você não pode escapar da nova linha com '=' char no final da linha (a codificação QP do cabeçalho é diferente da QP do corpo). A linha inferior é: não é culpa do Outlook.
Pawel Lesnikowski

2

Não acredito que exista um limite formal aqui e tenho certeza de que também não há nenhum limite rígido especificado na RFC, como você encontrou.

Eu acho que algumas limitações bastante comuns para linhas de assunto em geral (não apenas email) são:

  • 80 caracteres
  • 128 caracteres
  • 256 caracteres

Obviamente, você deseja criar algo que seja razoável. Se você estiver escrevendo um cliente de e-mail, convém usar algo como 256 caracteres e, obviamente, testar minuciosamente os grandes servidores comerciais disponíveis para garantir que eles atendam seus e-mails corretamente.

Espero que isto ajude!


13
Não há nenhuma razão específica para que 256 seja melhor que 250, 300 ou 372. Há muito que usamos bytes para comprimentos de string.
Greg Hewgill 20/10/2009

4
255 é o limite real de alguns produtos (Jira e outlook, por exemplo)
reinicie o

5
Esta resposta está errada. A RFC 5322, a versão atual das especificações do FMI, define claramente um comprimento máximo de linha. Veja a resposta de @ Michael.
James.garriss

2
+1 A limitação do comprimento da linha é para todas as linhas da mensagem, mas não vejo nada que diga que você não pode ter um assunto em várias linhas (implicando nenhuma limitação no número de caracteres para o assunto). Veja 2.2.3 e o exemplo a seguir diretamente depois.
Cypher

1
O VARCHAR 255 é provavelmente o comprimento da coluna de dados mais comum (e mais eficiente) no MySQL / MariaDB. Os bytes certamente ainda são relevantes. O MySQL usará 1 byte para armazenar o comprimento, se for menor que 256, ou mais. Veja como o C ++ implementa std :: string se você acha que os comprimentos das strings não são muito importantes e contados em bytes.
Ebyrob 16/03/19

0

O importante é qual mecanismo você está usando para enviar o email. A maioria das bibliotecas modernas (isto é, System.Net.Mail) ocultará a dobra. Você acabou de colocar uma linha de assunto de email muito longa sem (CR, LF, HTAB). Se você começar a tentar fazer o seu próprio fold, todas as apostas serão canceladas. Ele começará a relatar erros. Portanto, se você estiver tendo esse problema, filtre o CR, LF, HTAB e deixe a biblioteca fazer o trabalho por você. Você também pode definir o tipo de texto de codificação como um campo separado. Não há necessidade de codificação iso na linha de assunto.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.