Resumo

  • O RFC 5259 mantém o original no armazenamento e devolve um derivado pedido pelo cliente ou escolhido pelo servidor; abrir corretamente não prova bytes idênticos, assinatura válida ou substituição permanente.
  • Um OK final pode conter falhas por item, enquanto conversão padrão pode remover detalhe e substituir caracteres; o recibo precisa acompanhar cada resultado.

O celular resolveu a compatibilidade e criou uma pergunta de autoridade

Uma diretora recebeu um documento assinado, mas o aparelho não suportava o formato. O servidor o converteu, reduziu imagens e apresentou uma página impecável. O desenho da assinatura continuava ali. A aprovação seguiu como se aquele novo arquivo fosse o objeto autenticado.

O RFC 5259 afirma que, após a conversão de uma parte assinada no servidor, o cliente não consegue verificar a autenticidade do conteúdo convertido por meio da assinatura original. Quem não confia no servidor deve baixar, verificar o original assinado e converter localmente.

O derivado pode ser útil e correto para exibição. A utilidade não transfere a autoridade criptográfica da fonte. Formato acessível e objeto autenticado pertencem a camadas diferentes.

A fonte permanece; a representação é produzida

A conversão afeta somente os dados enviados. O conteúdo original do armazenamento não pode ser alterado. Isso preserva acesso por outros clientes, material para resposta e encaminhamento, BODYSTRUCTURE e verificação da assinatura.

A saída pode mudar tipo MIME, estrutura, codificação, dimensões, charset e tamanho. Ela pertence a uma execução. Arquivá-la não prova mudança da fonte; chamá-la apenas de “anexo” apaga a operação que define sua procedência.

Registre a identidade da fonte — caixa, UID, parte e hash — e a identidade do derivado — pedido, parâmetros, política, versão e hash.

Catálogo de capacidade não é recibo de bytes

O servidor anuncia CONVERT e BINARY. CONVERSIONS descreve pares MIME e parâmetros; AVAILABLECONVERSIONS lista alvos para uma parte. São possibilidades, não execução.

Depois, recursos podem faltar, o serviço pode estar fora do ar, valores podem ser inválidos ou não existir conversor. A versão ou política pode mudar entre descoberta e uso. O nome de uma rota não determina os bytes obtidos.

Capacidade e execução exigem evidências e horários separados.

NIL delega ao servidor o que o leitor verá

O cliente pode nomear o alvo ou passar NIL. Na escolha padrão, o servidor usa informações do dispositivo, preferências, configuração e sua noção de formato comum. O RFC não fecha o algoritmo.

Detalhes acima da capacidade do aparelho podem ser removidos, como resolução de imagem. Minimizar perda não é garantir equivalência sem perda. O servidor também pode adivinhar errado, razão pela qual o cliente é aconselhado a informar capacidade ou descobrir alvos.

A decisão padrão é uma delegação editorial. O recibo deve dizer qual formato foi escolhido e por quais sinais.

Resultado válido pode conter substituição

Na conversão textual, caracteres fora do charset alvo podem ser trocados pelo valor de unknown-character-replacement. O resultado satisfaz o pedido enquanto perde informação específica.

Cabeçalhos e parâmetros MIME também podem ser decodificados e recodificados. Significado aproximado não é identidade de octetos. Fidelidade precisa separar bytes, texto, layout, dimensões e omissões.

Intervalos parciais em CONVERT BINARY usam posições nos dados transcodificados e decodificados, não na fonte. Uma coordenada do derivado não localiza o original.

OK pode encerrar um conjunto incompleto

Itens CONVERTED podem trazer TEMPFAIL, BADPARAMETERS e MISSINGPARAMETERS. Se pelo menos uma conversão funcionar, o resultado final deve ser OK. Mesmo com todas em falha, OK ou NO são permitidos.

Logo, o estado geral não é uma contagem de sucesso. O cliente deve reconciliar cada item pedido com dado ou erro. Uma parte pode existir e outra faltar; estrutura pode chegar sem conteúdo.

BODYPARTSTRUCTURE costuma mostrar se o pedido foi atendido exatamente, mas pode não explicar toda a causa. Preserve-a com parâmetros e hashes.

Conversão não marca leitura e cache não cria cânone

CONVERT nunca define \Seen; isso exige STORE. Produzir bytes não prova que alguém os viu ou que o estado da caixa mudou.

O servidor pode manter cache e deve limitá-lo contra negação de serviço. Cache é estado temporário, não anexo alternativo permanente. Codec, política, fontes e serviço externo podem alterar uma repetição futura.

Se uma decisão consumiu a saída, preserve aqueles bytes e aquele ambiente.

O transcodificador é um principal de segurança

Um arquivo malicioso anexado antes de CONVERT pode atacar parser ou codec. Escala extrema consome recursos; conversão perigosa pode produzir executável. O RFC recomenda recusar operações caras, verificar saída, registrar a identidade autenticada e isolar a biblioteca do mailstore privilegiado.

Serviço externo acrescenta custódia. Mesmo no mesmo domínio de confiança, registre destino, entrada e saída. SASL/TLS autentica o servidor e o canal, não os novos bytes sob a assinatura antiga.

Um recibo entre duas camadas

Preserve caixa, UIDVALIDITY/UID, parte fonte, MIME, tamanho e hash; tipos e parâmetros; escolha explícita ou padrão; capacidade declarada; preferências, política, versão, transcodificador, tempo e domínio.

Acrescente cada item, erro e estado final, MIME/tamanho/hash derivados, redução e substituição, cache, verificação da assinatura fonte, ausência de herança no derivado, resultado do visualizador, \Seen e ação posterior.

“O servidor produziu estes bytes” é verificável. “Este é o anexo assinado” requer autenticação sobre a saída. “Converteu” exige resultado por item.

O RFC 5259 deu adaptação valiosa a clientes limitados. Liderança deve impedir que a representação conveniente se passe pela fonte autenticada.

Fontes