Resumo

  • O relay cria um recipient-list-history diferente para cada saída. Entradas bcc somem das cópias alheias; a cópia do destinatário cego pode manter seu próprio URI para orientar a prevenção de “responder a todos”.
  • A falta de copyControl significa bcc. Duplicatas geram no máximo um pedido e são resolvidas por to, cc, bcc; bcc também prevalece sobre anonymize, que de outro modo pode revelar existência e quantidade.
  • O histórico é uma parte opcional e não comprova endereço existente, alcance, aceitação, participação ou cobrança. Segurança do transporte e resultado da sessão exigem recibos próprios.

A última etapa da cópia cega acontece no cliente

O relay pode produzir uma projeção perfeita e, ainda assim, o segredo acabar no clique seguinte. Se o destinatário cego usa “responder a todos”, seu endereço pode entrar na nova mensagem e ficar visível para todo o grupo.

A RFC 5364 trata esse risco como parte da operação. Quando o próprio URI não aparece no histórico, ou aparece com condição cega, o agente deve impedir ou restringir a resposta coletiva.

Essa decisão exige reconhecer a identidade local. Alias, encaminhamento e várias contas podem fazer o cliente não perceber que o endereço cego é seu. O erro pode liberar uma resposta perigosa ou bloquear uma resposta legítima.

O recibo precisa ir além da configuração do servidor. Guarde o corpo recebido, o resultado do parser, a identidade escolhida, a correspondência encontrada, o estado da ação e os endereços realmente enviados.

Uma captura de tela com botão desativado é insuficiente se outro caminho de composição ainda permite a exposição. O resultado a provar é a ausência do URI cego em qualquer resposta emitida ao conjunto visível.

Cada saída carrega uma visão, não a lista-mãe

Depois de expandir a lista de recursos, o serviço conhece o conjunto operacional. Mas não deve entregar essa mesma informação a todos.

Itens to e cc podem permanecer visíveis. Itens bcc são retirados dos históricos dos demais. O próprio destinatário cego pode receber uma cópia distinta com seu URI, justamente para saber que sua presença não foi anunciada.

Duas solicitações da mesma expansão podem ter hashes de histórico diferentes sem que haja adulteração. A diferença só pode ser julgada quando se conhece o observador, a regra usada e o conjunto ocultado.

Mantenha o hash do XML original, o grafo de expansão, a classificação resolvida, o identificador de cada pedido e o hash do corpo destinado àquele receptor. Uma tabela final única apaga a prova de quem viu quem.

O autor controla a entrada; o relay aplica a política de divulgação; o destinatário recebe uma projeção limitada. Essas três superfícies não são uma única “lista de participantes”.

Campo ausente não significa exposição livre

Sem copyControl, o valor é bcc. A regra protege listas antigas, produtores incompletos e migrações em que o atributo desapareceu. O silêncio não concede permissão para mostrar o URI.

É importante separar bcc explícito de bcc aplicado por padrão. O resultado público é igual, porém a causa operacional não é. Um caso registra intenção; o outro registra contenção diante de dados incompletos.

Preserve bytes e hash do XML, versão do schema, presença do atributo, parser, regra de default e classe final. Se a normalização preencher o campo e apagar a ausência, perde-se uma evidência de qualidade e migração.

Atualizações de biblioteca precisam repetir o fixture de campo ausente. Uma mudança de default pode publicar silenciosamente endereços que durante anos ficaram cegos.

Anonimizar ainda conta pessoas

anonymize=true pode substituir URI reais pelo marcador SIP anônimo definido pela norma e usar count para representar várias entradas. A identidade desaparece, mas existência e cardinalidade continuam visíveis.

Em um encontro sensível, saber que há seis receptores anônimos pode mudar comportamento. Um teste que procura apenas endereços reais não detecta essa divulgação.

bcc e anonimização não são equivalentes. A cópia cega omite o item da visão alheia; a anonimização preserva um marcador. Quando ambas aparecem, bcc prevalece. Emitir o marcador nessa situação vaza uma existência que deveria permanecer oculta.

Registre atributos de origem, regra de precedência, itens omitidos, grupos anônimos, contagem e corpo renderizado. Avalie separadamente vazamento de identidade e de tamanho do grupo.

Uma interface que chama tudo de “privado” não informa qual dado ainda foi divulgado.

Duplicar um URI pode duplicar uma intenção conflitante

Listas aninhadas podem produzir várias ocorrências que as regras do esquema URI consideram a mesma identidade. Comparação textual simples pode não detectá-las; normalização excessiva pode unir destinos diferentes.

A RFC recomenda no máximo uma solicitação para o mesmo URI. Se as classes divergem, vence to, depois cc, depois bcc.

Guardar a primeira linha torna o resultado dependente da ordem. Enviar duas vezes pode entregar históricos incompatíveis ao mesmo terminal. A deduplicação, portanto, decide divulgação e precisa ser reproduzível.

Conserve formas originais, método de comparação, grupo de colisão, caminhos de origem, atributos concorrentes, vencedor e pedido único. O artigo sobre a RFC 5363 já cobre fan-out e resultados agregados; aqui, o ponto é a classe de visibilidade que sobrevive.

A parte opcional cria sucesso sem contexto

O histórico usa a disposição recipient-list-history com handling=optional. Um cliente antigo pode aceitar a solicitação SIP principal e ignorar a parte multipart.

Aceitação da solicitação e consumo da história são fatos separados. O relay pode ter anexado bytes que nunca foram preservados, interpretados ou exibidos. Nesse caso, a regra local de resposta também pode não ter recebido sua entrada.

Guarde montagem MIME, boundary, disposition, parâmetro, capacidade do endpoint, resultado de parse, exibição e fallback. O descarte permitido precisa gerar telemetria própria.

Compatibilidade protege disponibilidade, mas pode retirar contexto de privacidade. Serviços sensíveis precisam definir se aceitam esse modo degradado e como avisam o usuário.

Histórico não é lista de presença

A RFC adverte que o histórico não demonstra participantes reais. Um URI pode ser inexistente, inalcançável, não responder, recusar ou pertencer a uma máquina. Uma pessoa pode entrar por outra identidade.

Também não há prova de cobrança. Convite não é consumo; geração de pedido não é sessão aceita; uma linha não mede duração, capacidade nem responsabilidade financeira.

O conteúdo ainda pode ser falsificado. XML válido demonstra estrutura. Assinatura ou criptografia pode ligar bytes a um emissor, mas não transforma afirmação em observação.

Resposta do endpoint, ingresso autenticado, mídia, duração, recurso consumido e evento de faturamento devem existir como registros posteriores. Eles podem ser correlacionados; não podem ser substituídos pela aparição no histórico.

A pergunta respondida é “qual visão acompanhou esta solicitação?”, não “quem esteve presente?”.

TLS e S/MIME protegem outra fronteira

Relacionamentos entre destinatários são sensíveis. Autenticação, autorização, TLS e S/MIME ajudam a manter listas fora de mãos não confiáveis e a proteger transporte ou conteúdo segundo seus modelos.

Eles não provam que o relay abriu a versão correta, comparou URI corretamente, aplicou precedências, calculou a contagem ou mostrou a visão certa ao endpoint.

Registre peer, certificado ou chave, verificação e escopo da proteção. Em paralelo, registre entrada, versão do transformador, regras e hash de cada projeção.

Um canal seguro consegue transportar uma projeção errada com total fidelidade. Custódia não deve emprestar autoridade à semântica.

O livro de projeção precisa guardar ausências

O primeiro recibo congela principal, autorização, XML e contexto. O segundo registra expansão. O terceiro fixa comparação de URI e grupos duplicados.

O quarto registra valores explícitos, bcc padrão, anonimização e precedências. O quinto lista, por receptor, itens visíveis, omitidos, marcadores e contagens, ligando o hash ao pedido de saída.

Depois vêm processamento opcional, apresentação, bloqueio de resposta, entrega, participação e faturamento. Cada etapa tem relógio e responsável próprios.

Guardar apenas a projeção não prova o que foi escondido. Guardar apenas a lista-mãe não prova o que foi revelado. A trilha precisa das duas pontas e da transformação.

Os testes devem seguir o observador

Inclua fixtures para atributo ausente, to, cc, bcc, anonimização individual e agregada, combinação cega/anônima, duplicatas equivalentes com atributos conflitantes, cópia do próprio cego, cópia de receptor visível e cliente sem suporte à parte opcional.

Para cada caso, confirme número de pedidos e bytes exatos de todos os históricos. Depois valide identidade local, interface e resposta. Por fim, garanta que presença e cobrança não derivem da história.

Troque a lista após autorização, reordene duplicatas, remova atributos, adultere count, forje histórico, retire a parte opcional e reproduza projeção antiga. Toda aceitação deve deixar uma regra explicável.

A condição de Proposed Standard de outubro de 2008 e a página de errata capturada sem correspondências são fatos documentais. Não provam produto atual, adoção, interoperabilidade ou incidente real.