Anexo em e-mail descartável: qual o tamanho máximo?

O que conta como anexo

Uma mensagem é uma árvore de partes, e só algumas delas são arquivos. A regra aqui é deliberadamente generosa, porque a alternativa — confiar que o remetente vai rotular tudo corretamente — perde anexos em silêncio que um cliente de e-mail teria mostrado:

Qualquer coisa marcada como tal

Uma parte cujo Content-Disposition diz attachment. O caso comum, e o único em que todo cliente de e-mail concorda.

Qualquer coisa com um nome de arquivo

Uma parte com um filename, seja qual for sua outra rotulagem. Remetentes rotulam errado o tempo todo, e um arquivo com nome é um arquivo.

Partes nomeadas que não são texto

Uma parte com um name cujo tipo não é text/…. É isso que pega o logotipo em uma assinatura HTML — então uma mensagem pode chegar com anexos que você não esperava e que o remetente nunca pensou como anexos.

Por isso, a contagem que você vê costuma ser maior do que a que o remetente tinha em mente. Vinte é o máximo que uma mensagem mantém; uma mensagem com mais partes com nome de arquivo do que isso mantém as primeiras vinte e descarta o resto — vale saber disso antes de construir algo em cima.

Um nome de arquivo vindo da rede nunca é usado como caminho. O arquivo é gravado sob um nome gerado, e o nome original é carregado ao lado dele como dado — assim, um remetente não pode escolher onde seu arquivo vai parar só por batizá-lo com uma barra no nome.

O limite de tamanho, e onde ele realmente pesa

O número publicado é 5 MB, e vale ser exato sobre o que ele mede: a mensagem codificada inteira. Não o anexo, nem a soma dos anexos — tudo o que o servidor remetente entrega, depois que a codificação MIME já deixou tudo maior.

O base64 — o jeito que um binário atravessa um protocolo feito para texto — transforma cada três bytes em quatro. Some as quebras de linha que ele exige e um arquivo chega cerca de um terço maior do que era no disco, um pouco mais depois de contar essas quebras. Fazendo as contas de trás para frente a partir de 5 MB, isso coloca o limite real em um arquivo de aproximadamente 3,5 MB — e ainda menor para uma mensagem com assinatura e uma parte em HTML.

O que é medido

Cabeçalhos, a parte em texto, a parte em HTML e todos os anexos, tudo já codificado.

Anexos por mensagem

Vinte. Na prática, o limite de tamanho chega primeiro.

Partes em texto

Mantidas até 2 MiB cada, depois de decodificadas. Um corpo maior do que isso é armazenado truncado — o que nenhum e-mail comum chega perto de atingir, embora um relatório gerado automaticamente possa.

O que acontece quando um arquivo é grande demais

É recusado na porta, durante a conversa SMTP, antes de qualquer coisa ser armazenada. Um servidor remetente que anuncia o tamanho de antemão é barrado na hora, e a troca termina mais ou menos assim:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Isso importa mais do que parece. Um serviço que aceitasse a mensagem e a descartasse depois deixaria o remetente achando que ela foi entregue, e você esperando por algo que nunca ia aparecer. Uma recusa no momento do SMTP é uma falha real relatada a uma pessoa real: o remetente recebe um bounce com o motivo escrito nele.

Um remetente que não anuncia o tamanho de antemão recebe a mesma resposta no fim da mensagem, depois que o servidor de e-mail conta os bytes por conta própria. De um jeito ou de outro, nada chega à caixa de entrada e nada chega truncado.

Como baixar um anexo da caixa de entrada

No navegador, é onde você esperaria. Abra a mensagem e os anexos aparecem listados abaixo dela, cada um com o nome que o remetente deu e o tamanho que de fato chegou.

1. Abra a mensagem. A lista se atualiza sozinha, então um arquivo que chega enquanto você está olhando a caixa de entrada aparece sem precisar recarregar.
2. Leia o nome e o tamanho antes de clicar. Os dois são fatos sobre o que chegou, e são a última coisa que você vê antes de o arquivo estar na sua máquina.
3. Clique nele. O arquivo é baixado. Ele nunca abre no navegador, seja lá o que diga ser — a próxima seção explica por que isso é um recurso, não uma falha.

Imagens remotas no corpo da mensagem ficam bloqueadas até você liberá-las, e isso é diferente de um anexo: uma imagem bloqueada é buscada no próprio servidor do remetente no momento em que você permite, enquanto um anexo veio junto com a mensagem e não é buscado de ninguém.

Como baixar anexos pela API

Ler uma mensagem retorna seus anexos como uma lista, e cada um já chega com a URL pronta:

"attachments": [
  {
    "id":       "01JR8W2K4QATT1",
    "filename": "invoice.pdf",
    "mime":     "application/pdf",
    "size":     184320,
    "url":      "/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"
  }
]

Essa URL é um GET simples com a caixa de entrada como parâmetro de consulta, e nos domínios públicos ela não precisa de mais nada — sem chave, sem sessão, sem conta:

curl -OJ "https://grabmail.io/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"

-OJ diz ao curl para salvar o arquivo com o nome que o servidor envia, em vez do id. O endpoint responde uma de três coisas: o arquivo, um 404 se não existir esse anexo naquela caixa de entrada ou se ele já tiver expirado, ou um 429 se você estiver pedindo mais de uma vez por segundo.

O id de um anexo pertence à sua caixa de entrada, então um id de um endereço dá 404 em outro. Não existe endpoint que liste anexos sozinhos — eles chegam junto com a mensagem e são lidos a partir dela. A referência da API tem o formato completo de uma resposta de mensagem.

Por que todo anexo é baixado como binário

Seja lá o que o remetente disse que o arquivo era, ele volta como application/octet-stream e é baixado em vez de aberto. Isso não é descuido com os tipos de conteúdo — é a única resposta segura quando o arquivo veio de um desconhecido.

O tipo informado pelo remetente nunca é repetido de volta

Quem rotula o próprio arquivo como text/html e consegue fazer com que ele seja renderizado na nossa origem está rodando a página dele como se fôssemos nós, dentro da sua sessão, com tudo o que isso permite alcançar. Por isso o rótulo é descartado, e quem chama decide o que o arquivo é a partir dos metadados ao lado dele.

Sempre um download, nunca uma visualização

Content-Disposition: attachment em toda resposta, então nada é renderizado no lugar, não importa como esteja rotulado.

Sem inferência de tipo, e nada pode rodar

X-Content-Type-Options: nosniff impede que o navegador tente adivinhar um tipo por conta própria, e uma Content-Security-Policy de default-src 'none'; sandbox significa que, mesmo que algo chegasse a renderizar, não conseguiria carregar nem rodar nada.

O nome do arquivo não pode virar um cabeçalho

O nome é codificado em vez de ser colado direto na resposta, então um arquivo com uma quebra de linha no nome não consegue inserir um cabeçalho por conta própria.

O arquivo em si permanece intocado — byte a byte o que o remetente enviou. É a moldura em volta dele que é propositalmente sem graça. Ele também fica armazenado fora da raiz web, então adivinhar um caminho não é uma forma de entrar: a caixa de entrada precisa ser resolvida e autorizada antes de o arquivo ser lido.

Por que nada aqui faz varredura no arquivo

Não há antivírus, não há detonação em sandbox e não há checagem de reputação. Isso é um limite declarado, não um descuido, e muda o que você pode fazer com segurança com o que chega:

• Qualquer um pode enviar para um endereço público. Não precisam te conhecer — precisam conhecer o endereço, e os curtos são adivinhados. Um arquivo em uma caixa de entrada pública tem autor desconhecido por padrão.
• Executáveis e scripts são exatamente tão perigosos aqui quanto em qualquer lugar. Nada é filtrado por extensão, e nada olha dentro de um arquivo compactado para ver o que tem lá.
• Documentos que conseguem executar coisas são o caso mais comum. Arquivos de escritório com macro habilitada e PDFs com ações embutidas são como a maior parte disso realmente acontece — não executáveis óbvios.
• O nome não diz nada. Um arquivo chamado invoice.pdf é o que seus bytes disserem que é, e a extensão foi escolhida por quem o enviou.

Os anexos somem quando a mensagem some

Um anexo não tem vida própria. Ele pertence à sua mensagem, e some quando a mensagem some:

Depois de 5 dias

Excluído junto com a mensagem, lida ou não, num relógio que começou a contar quando ela chegou. Não há arquivo morto nem exportação.

Quando você apaga a mensagem

Imediatamente, e a URL passa a responder 404. É a mesma chamada, quer você apague pela caixa de entrada ou pela API.

Não há como voltar atrás

Sem desfazer exclusão, sem prazo de tolerância e sem caixa de suporte para pedir. Qualquer coisa que você vai querer amanhã precisa ser baixada hoje.

Quando e-mail não é a ferramenta certa

Parte do que as pessoas tentam fazer com anexos aqui não é um limite para contornar — é a ferramenta errada para o trabalho:

• Um arquivo acima do limite. Nada o aumenta. Envie um link em vez disso.
• Algo que você vai precisar mês que vem. 5 dias é um limite rígido aplicado por um job, não uma configuração. Baixe agora, ou use uma caixa de entrada de verdade.
• Qualquer coisa que você não gostaria que um estranho lesse. Em um domínio público, o endereço é a única fechadura da porta, e é uma fechadura curta.

Um domínio próprio muda o terceiro item dessa lista, mas não os dois primeiros: o limite e a retenção continuam exatamente os mesmos, mas o endereço fica em um nome que não aparece em lugar nenhum deste site, então ninguém envia arquivos para ele por adivinhação. Um único registro MX resolve isso:

Registro MX para o seu domínio10 smtp.grabmail.ioCopiar

O passo a passo completo está aqui — o registro, o que publicá-lo prova, e os limites honestos de uma caixa de entrada sem senha.

Perguntas