Resumo

  • No SMTP inicial, falhas de tamanho ou armazenamento podiam surgir apenas depois que DATA fosse transmitido por inteiro e descartado.
  • O RFC 1870 deixou o servidor anunciar um teto fixo no EHLO e o cliente declarar uma estimativa de octetos no MAIL FROM. Limite permanente recebeu 552; escassez temporária, 452.
  • O número continuou sendo evidência limitada: não encerrava DATA, não reservava recursos por toda a rota e não transformava a aceitação de MAIL em garantia de entrega.

O veredito vinha depois do custo

O RFC 821 ordenava a transação em MAIL, um ou mais RCPT e DATA. Depois da resposta 354, o remetente enviava cabeçalhos, corpo e terminador. Só então o receptor decidia sobre o objeto completo.

O servidor, porém, podia já saber que sua política nunca aceitaria aquele volume, ou estar temporariamente sem espaço. Sem extensão, o cliente transmitia cada octeto antes de receber a notícia, e o receptor jogava fora o conteúdo. O crescimento do correio multimídia transformou essa posição tardia em desperdício de enlace, tempo e memória.

Duas declarações, dois responsáveis

A ideia apareceu no RFC 1427 em 1993, passou pelo RFC 1653 e chegou ao padrão de 1995 no RFC 1870. O servidor inclui SIZE na resposta EHLO e pode acrescentar o maior tamanho que sua regra fixa admite.

Zero significa ausência de máximo fixo. A palavra sem número não informa qual é o máximo; não significa capacidade infinita. O cliente pode anexar outro SIZE ao MAIL FROM: sua estimativa para a mensagem específica. Quando o cálculo exato é inviável, a estimativa pode ser heurística e deve tender para cima.

O receptor descreve sua política; o emissor descreve seu objeto. A sintaxe comum põe os fatos em contato sem transferir controle do disco, da fila ou do conteúdo.

Contar não é delimitar

Entram na conta cabeçalho, corpo e pares CR-LF transmitidos após 354. Ficam de fora o ponto terminador de DATA e os pontos extras usados apenas para transparência SMTP.

O RFC 1870 proíbe usar SIZE para achar o fim de DATA. Uma estimativa errada pode alterar a aceitação, mas não pode transformar conteúdo em comando. O terminador antigo conserva a autoridade sobre o enquadramento. SIZE trata de recursos; transparência por pontos e BDAT tratam de fronteiras.

452 conserva o futuro; 552 o encerra

Quando a declaração excede o teto fixo, 552 diz que repetir a mesma mensagem contra a mesma política não resolverá. Quando faltam recursos agora, mas podem voltar, 452 permite reencaminhar a tentativa mais tarde.

Confundir os códigos cria danos opostos: política tratada como falha temporária produz repetição inútil; falta passageira tratada como proibição perde uma entrega possível. A decisão também pode ser por destinatário. O mesmo tamanho pode ser aceito para um RCPT, adiado para outro e recusado definitivamente para um terceiro.

O 250 inicial não é recibo

O sucesso de MAIL não garante DATA, armazenamento, próximo salto nem caixa final. O objeto real pode exceder a declaração; os recursos podem mudar. O servidor pode tolerar uma subdeclaração, mas não precisa.

Há confiança limitada: depois de aceitar o tamanho declarado, o servidor não deveria responder 552 após DATA por seu teto normal se o objeto real permaneceu dentro da declaração. Isso dá valor à decisão precoce sem inventar uma reserva universal.

O RFC 5321 exigiu depois pelo menos 64K octetos e recomendou SIZE a quem precise impor restrições. Não criou um limite mundial. Cada sistema continuou dono do próprio custo; o protocolo apenas tornou uma fronteira local visível a tempo.

Fontes e limites

O RFC 821 fornece a transação original; RFC 1427, RFC 1653 e RFC 1870 registram a extensão; RFC 5321 dá a base posterior. Eles não medem implantação atual nem limites de provedores. SIZE não autentica conteúdo, prova cota, reserva toda a rota ou confirma entrega. A história é mais estreita: evidência de capacidade evitou trabalho condenado sem centralizar autoridade.