Resumo

  • No message/partial, cada fragmento continuava sendo uma mensagem completa para o correio. id reunia o conjunto pretendido, number definia a posição e total declarava quantas partes eram esperadas.
  • A remontagem devolvia a semântica da entidade interna. Cabeçalhos da primeira embalagem e campos selecionados do interior eram combinados; os cabeçalhos das embalagens posteriores não passavam para o resultado.
  • Uma sequência completa não autenticava o emissor, não comparava bytes por hash e não comprovava exibição. O formato fornecia uma descrição verificável; a realidade utilizável dependia da validação local.

Um objeto encontrava muitos limites

Para quem anexava um documento, havia uma unidade. Para a infraestrutura de correio, havia uma cadeia de decisões sobre armazenamento, fila e tamanho. Um servidor aceitava, outro encaminhava e um gateway seguinte podia recusar porque o seu teto era menor. O SMTP não estabelecia um máximo universal.

O RFC 1123 registrou essa situação em 1989. O software de correio precisava enviar e receber ao menos 64 KB, e um máximo muito maior era altamente desejável. Ao mesmo tempo, o texto reconhecia limites de implementação e o uso do correio para documentos de um megabyte ou mais. O requisito criava um piso; não obrigava todos os saltos a oferecer o mesmo teto.

O MIME poderia ter condicionado a solução a uma atualização coordenada de toda a rede. Em vez disso, manteve a mensagem como unidade já aceita pelos transportes e separou dela a unidade de significado. Várias mensagens poderiam carregar uma entidade maior, mas nenhum intermediário declararia o todo antes que o destinatário tivesse as peças.

A embalagem chegava inteira; o conteúdo, não

Publicado em junho de 1992, o RFC 1341 incluiu message/partial na primeira especificação MIME. O corpo marcado com esse tipo era um fragmento de uma mensagem maior. A embalagem externa, porém, era uma mensagem de correio real, com Message-ID, linhas Received, horário e destino próprios.

Isso não era multipart/mixed com outro nome. Multipart leva várias partes dentro de uma entrega. Partial distribui uma entidade entre várias entregas. A parte 5 podia chegar antes da parte 2, passar por outro gateway e acumular evidência de transporte diferente sem ganhar outra posição no conteúdo.

A aceitação SMTP de um fragmento comprovava a aceitação daquele fragmento. Três embalagens em uma caixa comprovavam três armazenamentos. Nenhum desses registros, isoladamente, criava a entidade interna. A conclusão surgia mais tarde, onde havia dados e código para testá-la.

Três parâmetros, nenhuma autoridade implícita

id fazia a associação e deveria ser gerado tão próximo quanto possível da unicidade mundial. number informava a posição, começando por 1. total indicava a quantidade esperada. A ordem dos parâmetros no Content-Type era indiferente.

O último fragmento precisava trazer total. Nos anteriores, ele era opcional, embora as versões posteriores incentivassem seu uso. Assim, o emissor podia iniciar a divisão sem saber a contagem final, mas precisava oferecer um fim verificável ao marcar a última parte.

O RFC 1521, de 1993, manteve a construção e tornou suas condições mais explícitas. Não transformou id em resumo criptográfico. Duas peças com o mesmo número podiam conter bytes distintos. Um emissor podia repetir um identificador ou anunciar um total contraditório. O campo agrupava alegações, não certificava conteúdo.

Cabia ao receptor exigir a série de 1 até o total, comparar duplicatas segundo uma política definida, rejeitar contagens incompatíveis, impor limites e analisar a concatenação como MIME. O padrão descrevia invariantes suficientes para interoperar. A implementação em execução dizia se a evidência local os cumpria.

O andaime não virava a identidade do objeto

Depois da remontagem, o resultado era uma entidade MIME completa com seu próprio Content-Type. Se o interior fosse áudio, a apresentação deveria ser áudio — não uma mensagem contendo outra mensagem que, por sua vez, continha áudio. A embalagem parcial era semanticamente transparente.

Essa regra separava duas identidades parecidas. Cada mensagem externa podia ter seu Message-ID porque realizou uma viagem autônoma. A entidade interna também podia ter um Message-ID próprio, referente ao objeto remontado. Os identificadores externos documentavam entregas; o interno nomeava o resultado. Substituir um pelo outro apagaria a diferença entre percurso e significado.

A ordem de chegada também não comandava os bytes. O primeiro fragmento recebido poderia ser o de número 4. Isso informava atraso e roteamento do correio, mas number continuava decidindo a concatenação. Uma observação temporal não se convertia em poder sobre a estrutura.

O fragmento número 1 trazia a base dos cabeçalhos

Juntar corpos não bastava, porque cada embalagem tinha cabeçalhos potencialmente conflitantes. O MIME exigiu divisão apenas em limites de linha e definiu uma fusão assimétrica.

Da primeira mensagem externa eram copiados os cabeçalhos comuns, exceto Content-* e Subject, Message-ID, Encrypted e MIME-Version. Da entidade interna vinham Content-* e esses campos selecionados; outros cabeçalhos internos eram descartados. Da segunda embalagem em diante, nenhum cabeçalho externo entrava na entidade remontada.

O RFC 2046 consolidou essa divisão em 1996. A embalagem number=1 fornecia o contexto externo sobrevivente. O interior fornecia tipo e determinados campos semânticos. As demais embalagens continuavam úteis como evidência de jornadas, mas não votavam no cabeçalho final.

Isso torna a primeira parte mais do que o primeiro intervalo de dados. Um sistema pode reter todos os trechos do corpo e ainda perder a base correta se eliminar cedo demais a primeira embalagem. Também erra se escolher a primeira que chegou, em vez da parte numerada como 1.

Uma trilha auditável preserva os dois planos. As mensagens brutas explicam entrega, atraso, duplicação e autenticação. A entidade derivada explica o que o receptor construiu. Guardar só a saída limpa faz uma decisão local parecer um fato da rede.

Rotas independentes exigiam o denominador 7bit

Dados 8bit ou binários criavam um impasse. Um corpo do tipo message não podia simplesmente receber base64 ou quoted-printable por fora. Se um interior binário fosse dividido, cada parcial dependeria de transporte binário. Um gateway 7bit que recebesse somente uma peça não poderia esperar as outras para remontar e recodificar; elas talvez passassem por gateways diferentes.

Por isso, message/partial precisava usar transferência 7bit, e a entidade interna não podia depender de 8bit ou binary. O RFC 2045 forneceu o quadro geral de codificações MIME; o RFC 2046 aplicou a restrição particular aos fragmentos.

A regra admitia que nenhum gateway tinha visão soberana do conjunto. O emissor preparava uma representação compatível com a capacidade comum das rotas possíveis. O custo era uma codificação mais conservadora; a vantagem era interoperar sem inventar um ponto central de remontagem.

Limites diferentes também podiam gerar fragmentação aninhada. Após remontar um conjunto, o resultado podia revelar outro message/partial. Isso era permitido explicitamente. O receptor repetia o procedimento por camada, sob limites locais de profundidade e recursos.

SIZE antecipava uma resposta, não montava a entidade

Em 1995, o RFC 1870 definiu a extensão SMTP SIZE. Um servidor podia anunciar um teto fixo, e um cliente podia declarar uma estimativa antes de transmitir o corpo. Uma rejeição previsível ocorria mais cedo.

SIZE e message/partial atuavam em superfícies adjacentes. SIZE tratava da admissão de uma mensagem em uma sessão SMTP. O tipo MIME tratava da reconstrução de várias mensagens no agente do usuário. Uma resposta positiva à declaração de tamanho não garantia a transferência completa nem a entrega final, e tampouco informava suporte à remontagem.

O primeiro mecanismo tornava um limite local visível. O segundo preservava significado quando continuavam existindo vários limites. A história não é a simples substituição de um pelo outro, mas a manutenção da fronteira entre transporte e representação.

Três registros evitam uma falsa história única

O registro das embalagens guarda bytes brutos, Message-ID externo, Received, horário e resultado de cada entrega. O registro do conjunto guarda id, números, totais, lacunas, duplicatas conflitantes e expiração. O registro de remontagem guarda a peça escolhida por posição, a ordem, a fusão de cabeçalhos, o tipo obtido e novas camadas parciais.

Origem, integridade e segurança ficam fora do identificador. Um conjunto numericamente completo ainda pode ser hostil. Resultados de autenticação podem diferir entre embalagens. Um parser pode produzir MIME válido e ainda falhar em uma assinatura. Reconstrução não comprova exibição nem atenção humana.

O mérito da arquitetura foi limitar a alegação do registro. Um rótulo comum permitia coordenação entre sistemas autônomos sem criar um cartório central do conteúdo. A descrição preparava uma verificação; somente a adoção efetiva das regras no destino transformava peças em estado operacional.