Resumo

  • A RFC 5365 define um serviço SIP de mensagem instantânea em modo pager. O cliente envia um MESSAGE multipart com uma lista plana de URIs e o conteúdo; o serviço atua como B2BUA especializado e cria um MESSAGE novo para cada destinatário.
  • O serviço copia os corpos úteis restantes, mas não copia um corpo de segurança criptografado para si. Quando só resta uma parte, remove o wrapper multipart/mixed; pode ainda construir um recipient-list-history específico e protegê-lo para o receptor.
  • A governança precisa verificar equivalência no nível correto: parte de conteúdo, tipo de mídia, transformação permitida, audiência e proveniência. O mesmo texto não prova o mesmo pacote, a mesma identidade, a mesma autenticação, a mesma transação nem a entrega.

A embalagem tinha uma função temporária

Multipart não é um selo de essência. É uma forma de agrupar componentes que podem ter finalidades e destinatários diferentes. Na entrada da RFC 5365, a lista orienta o serviço, a mensagem serve ao receptor e um corpo de segurança pode existir apenas para que o intermediário processe a solicitação.

O UAC envia uma lista plana conforme o uso de RFC 4826, inclui o payload de mensagem instantânea e requer recipient-list-message. O servidor resolve a lista e produz uma requisição por URI canônica. A unidade vista pelo remetente torna-se várias operações.

O serviço é descrito como B2BUA especializado. Ele termina o lado de entrada como servidor e começa o lado de saída como cliente. Por isso, seu dever não é conservar a embalagem original a qualquer custo; é construir uma saída correta para cada receptor.

Se o produto exigir identidade binária do pacote inteiro, vai classificar como erro justamente o comportamento previsto. Se verificar apenas o texto renderizado, aceitará mudanças silenciosas em imagens, anexos, tipos de mídia e disposições. A equivalência precisa de um objeto mais preciso.

Cada parte carregava sua própria autoridade

Um corpo S/MIME criptografado para o serviço de lista tem audiência definida. Bob pode não possuir a chave e não participou daquela relação criptográfica. A RFC determina que o serviço não copie para fora um security body endereçado a ele mesmo.

Os corpos restantes, como texto ou imagem, devem em geral ser copiados. Depois de remover lista e material exclusivo do serviço, se só houver uma parte, o multipart/mixed deve ser retirado. A fronteira MIME e o hash do pacote completo mudam, mas o payload relevante pode permanecer idêntico.

O recibo adequado lista cada parte recebida: media type, disposition, hash, audiência, regra aplicada e destino. Depois lista cada parte emitida e o motivo de inclusão, remoção ou criação. É possível comparar o texto com o texto, a imagem com a imagem e a proteção com sua audiência real.

Essa modelagem evita chamar descriptografia intermediária de criptografia ponta a ponta. Uma proteção pode ser ponta a ponta entre Alice e o serviço e terminar ali. Se o serviço protege um novo corpo para Bob, cria outra relação, com outra chave e outra proveniência.

O histórico era um novo documento

Para apoiar responder a todos, o serviço pode criar recipient-list-history. Ele aplica as regras de RFC 5364 sobre To, Cc, Bcc e anonimização. Logo, não se trata da lista original anexada sem interpretação.

A visão de Bob pode diferir da visão de Carol. Um membro Bcc não deve aparecer por acidente, e um destinatário anonimizado não pode recuperar identidade durante a transformação. A recomendação de criptografar o histórico para o receptor confirma que ele tem audiência própria.

O registro deve vincular versão da lista, política de copy control, itens visíveis, itens excluídos, hash da visão, receptor e proteção. Entregar corretamente o texto não demonstra que o histórico preservou confidencialidade.

Essa distinção também impede que a lista seja tratada como um payload comum. Ela é entrada executável e, em parte, material sensível. O que pode ser revelado depende do destinatário.

A nova representação veio numa nova transação

Para cada receptor, o serviço deve criar To e Call-ID novos, manter CSeq separado, inicializar Max-Forwards e inserir seu Via. A Request-URI passa a apontar para o destino individual.

Esses campos registram uma ação nova. Call-ID e CSeq identificam e ordenam o intercâmbio; Via governa a volta das respostas; Max-Forwards inicia um limite contra loops. Nada disso é preservado pelo fato de o texto ser igual.

Um identificador de execução interno deve ligar a transação de entrada ao conjunto canônico e às tentativas filhas. Usar o Call-ID de Alice como chave de tudo apagaria a identidade das saídas. Guardar apenas os novos Call-ID apagaria a origem comum.

O mesmo modelo ajuda no retry. Uma falha em Carol não autoriza repetir Bob. A operação por destinatário precisa ter estado, tentativa e evidência próprios.

O remetente visível era uma transformação controlada

O valor de From na saída deve corresponder ao de entrada, sujeito às regras de privacidade. O tag não deve ser carregado como se o mesmo endpoint de diálogo continuasse. Um privacy service co-localizado tem precedência.

Preservar Alice na tela atende à conversa, mas não prova autenticação ponta a ponta. O serviço pode ter autenticado Alice, aplicado uma política e originado uma nova requisição sob sua própria autoridade.

P-Asserted-Identity obedece à confiança do caminho. Se veio de fonte confiável e o primeiro hop de saída também é confiável, deve ser propagado. Se o hop é não confiável e Privacy foi solicitado, não deve sair. O serviço também pode criar a afirmação quando autentica e mapeia o usuário para SIP ou SIPS URI.

Auditoria precisa guardar autenticação, mapeamento, confiança de entrada e saída, Privacy e decisão de PAI. A presença do mesmo nome em From não substitui essa cadeia.

Credenciais pertenciam ao realm que as pediu

Authorization e Proxy-Authorization respondem a um realm. Se o realm é do próprio serviço MESSAGE, as credenciais não devem ser copiadas para a requisição de Bob. Elas abriram a fronteira do intermediário, não uma fronteira universal.

Se a autorização se refere a outro realm, a RFC exige copiar o valor pertinente. A classificação é contextual. Remover tudo pode quebrar autenticação legítima; copiar tudo pode vazar segredo.

O log não deve armazenar o valor secreto. Tipo, realm, referência irreversível, decisão e contexto do destino bastam para explicar a política. O conteúdo da mensagem e o âmbito da credencial continuam sendo objetos independentes.

Um parâmetro não podia trocar o método

URIs SIP podem conter componentes de header. O serviço pode avaliar individualmente um pedido como Accept-Contact. O hname especial body não deve fornecer conteúdo alternativo e pode ser descartado.

Uma URI também pode pedir outro método. A RFC é explícita: este serviço gera MESSAGE e ignora um parâmetro de método diferente. Dados na lista não recebem poder para converter o intermediário em originador de INVITE ou outra ação.

O recibo de transformação deve mostrar quais componentes foram honrados, rejeitados ou ignorados. Sem isso, o chamador atribui à política do serviço algo que veio do dado, ou acredita que uma preferência foi executada quando não foi.

O 202 preservou a incerteza correta

Ao aceitar a entrada, o serviço responde 202 Accepted. A RFC avisa que isso não informa se os MESSAGE criados foram entregues. Significa que a requisição foi recebida e será tentada.

Essa semântica respeita o tempo. Rotas, respostas downstream e efeitos ainda não existem no momento do primeiro recibo. Um painel que chama 202 de entrega não simplifica; inventa uma realidade futura.

Se entrega for necessária, registre criação da saída, resposta SIP, eventual recibo de aplicação e efeito observado. RFC 5365 deixa o mecanismo específico fora de escopo, mas não autoriza preencher desconhecido com sucesso.

A RFC 5363 trata a pluralidade de resultados de forma adjacente. Aqui, a tese é a equivalência de representação: até o payload chegar a uma tentativa individual, o B2BUA já decidiu envelope, identidade, credencial, proteção e histórico.

O registro padronizou nomes, não envelopes reais

A IANA registra recipient-list-message e dispositions relacionadas. Isso permite negociação e parsing comuns. Não comprova que uma instância preservou o payload correto, protegeu Bcc, respeitou Privacy ou entregou uma mensagem.

A RFC 5365 saiu em outubro de 2008 como Standards Track. A RFC 3851 tornou-se obsoleta na evolução do S/MIME, incluindo a RFC 8551. Implementações atuais devem usar mecanismos atuais, mantendo a pergunta permanente: qual objeto foi protegido para qual audiência?

A nota de Lu Heng sobre especificação inicial mínima oferece uma lente declarada: padronizar o menor contrato compartilhado e deixar decisões futuras a quem possui informação local. Sua nota sobre camadas de realidade lembra que uma representação simbólica não é a operação física nem o efeito humano. Os fatos técnicos continuam ancorados nas RFCs e na IANA.