Resumen

  • anonymize puede ocultar los URI y mantener un marcador con recuento; bcc elimina la entrada de las copias ajenas y prevalece cuando ambas instrucciones coinciden. Identidad y cardinalidad son superficies de privacidad diferentes.
  • La ausencia de copyControl equivale a bcc. Si un URI se repite, el servicio debería emitir una sola solicitud y resolver la clase con precedencia to, cc, bcc antes de construir cada historial.
  • La parte recipient-list-history es opcional y no certifica existencia, alcance, aceptación, participación ni facturación. La recepción SIP y el consumo de la vista son resultados separados.

Ocultar el nombre no oculta el tamaño del grupo

Una entrada con anonymize=true no se comporta como una copia ciega. El servicio puede dejar el URI anónimo reservado por la norma y adjuntar un contador. El destinatario no conoce la identidad, pero sabe que la proyección representa una o varias entradas ocultas.

Esa señal puede ser sensible. En una convocatoria, revelar que hay cinco participantes anónimos cambia la percepción de la reunión. En una respuesta operativa, el número de observadores puede alterar decisiones aunque ningún nombre se publique.

La privacidad debe medirse por dimensiones: identidad, existencia y cardinalidad. Un control que comprueba solamente que no aparece el URI real puede aprobar una filtración del tamaño del conjunto.

Conservar las entradas originales, el indicador de anonimización, el grupo condensado, el valor del recuento y el cuerpo exacto entregado. El marcador no es una persona ni una dirección enrutable; es una declaración del relé sobre información retenida.

Bcc elimina una existencia que anonymize conserva

Las copias bcc deben quedar fuera del historial enviado a los demás. El servicio puede incluir el URI ciego únicamente en la copia separada del propio destinatario, como advertencia para impedir que una respuesta colectiva lo revele.

Si una entrada tiene también anonymize, la regla ciega prevalece. El relé no debe convertirla en un marcador anónimo, porque hacerlo anunciaría una existencia que bcc exigía omitir.

Esta precedencia demuestra que las banderas no son etiquetas independientes sumables. La implementación necesita una regla ordenada y versionada. Guardar sólo el resultado final “oculto” impide saber qué instrucción ganó y por qué.

Las pruebas deben comparar la vista del destinatario ciego con las vistas ajenas. Un único historial reutilizado para todas las solicitudes sería una optimización incompatible con la semántica.

El valor ausente ya tiene significado

Cuando falta copyControl, RFC 5364 asigna bcc. Una lista antigua o un productor incompleto no autoriza al relé a mostrar la entrada. La omisión cae del lado de menor divulgación.

El registro debería distinguir bcc explícito de bcc por defecto. Ambos protegen la salida, pero el segundo puede indicar pérdida de metadatos o una versión anterior del productor.

Preservar XML, hash, versión del esquema, presencia del atributo, decisión de valor por defecto y clase final. Si la normalización rellena el campo y elimina la diferencia, el equipo pierde una señal de migración y no puede demostrar que el dato nunca estuvo presente.

Un cambio de parser merece una prueba específica: la misma entrada sin atributo debe seguir generando el mismo tratamiento ciego.

Cada destinatario recibe una historia distinta

La lista de recursos es una entrada de ejecución. Tras expandirla, el relé construye el cuerpo de historial que acompaña a cada solicitud. No copia sin más la lista maestra.

Las entradas visibles pueden aparecer como to o cc; las ciegas se retiran; las anónimas se sustituyen. La copia destinada al receptor ciego puede contener su propio URI mientras que las demás no lo contienen.

Por eso, una diferencia de hash entre dos cuerpos puede ser correcta. Para decidirlo, el auditor necesita la identidad del observador y la política aplicada. Sin esa unión, no puede distinguir privacidad de manipulación.

El libro de proyecciones debe enlazar un hash de la lista original con el resultado de expansión, la clasificación resuelta y cada solicitud saliente. También debe registrar qué entradas fueron visibles, omitidas o contadas.

Un duplicado es un conflicto de divulgación

Después de expandir listas anidadas, el mismo URI puede aparecer varias veces. La comparación debe usar las reglas del esquema URI. RFC 5364 desaconseja enviar más de una solicitud a la misma identidad.

Si las apariciones tienen clases distintas, la precedencia es to, después cc y después bcc. Resolver por posición, por orden de base de datos o por simple coincidencia textual puede cambiar quién ve qué.

Registrar las formas originales, el algoritmo de comparación, el grupo de colisión, los atributos de cada entrada, la clase ganadora y el único identificador de solicitud. La deduplicación ocurre antes de la proyección y debe ser reproducible.

RFC 5363 ya cubre el problema amplio de fan-out, normalización y resultados por componente. El asunto propio aquí es cómo la identidad duplicada transporta intenciones de visibilidad que necesitan una resolución normativa.

Responder a todos completa o rompe la política

El relé puede aplicar perfectamente bcc y aun así perder la confidencialidad en el terminal. Un destinatario ciego que pulsa “responder a todos” puede anunciar su dirección al grupo visible.

La especificación espera que el cliente limite esa acción cuando su URI no figura en el historial o aparece como ciego. La proyección es entonces una señal para el comportamiento local, no simple información decorativa.

El reconocimiento de identidad puede fallar con alias o varias cuentas. Un historial falso también puede influir en la interfaz. La prueba debe incluir el cuerpo recibido, la identidad seleccionada, la coincidencia, el estado del botón y los destinatarios reales del mensaje de respuesta.

No basta con una captura de pantalla. El resultado importante es que ninguna respuesta emitida haga visible una identidad que debía seguir oculta.

La solicitud puede llegar sin que llegue la historia

El cuerpo usa la disposición recipient-list-history y debería marcarse handling=optional. Así, un cliente heredado puede aceptar la solicitud principal aunque ignore la parte multipart que no comprende.

Entrega de solicitud y procesamiento de historial son recibos distintos. “HTTP/SIP aceptado” no confirma análisis, visualización ni aplicación de la regla de respuesta.

Guardar construcción MIME, límites, disposición, parámetro de tratamiento, capacidades declaradas, resultado del parser y presentación. Si la parte se descarta, debe quedar un evento de compatibilidad, no un éxito indistinguible.

En servicios sensibles, el operador debe decidir si continuar sin contexto es aceptable. La compatibilidad conserva disponibilidad pero puede retirar una defensa contra la revelación de copias ciegas.

La lista no prueba que alguien estuviera allí

El RFC advierte que el historial no representa necesariamente participantes reales. Un URI puede no existir, no responder, rechazar o pertenecer a un sistema automático. Una persona puede entrar con otra identidad.

Tampoco es un comprobante de facturación. Ser invitado no equivale a consumir servicio; aparecer en una vista no mide tiempo, capacidad ni responsabilidad económica.

Además, la historia puede falsificarse. XML válido y transporte protegido no convierten una declaración en observación. La firma, si existe, vincula a un emisor con bytes, no demuestra la realidad descrita.

Las respuestas de protocolo, la unión autenticada, el flujo de medios, la duración y el cargo deben conservarse como eventos posteriores. Correlacionarlos es legítimo; sustituirlos por pertenencia a la lista no lo es.

TLS y S/MIME responden otra pregunta

Las relaciones entre destinatarios merecen confidencialidad. TLS protege saltos bajo su modelo; S/MIME puede proteger contenido. Autenticación y autorización limitan quién puede entregar listas al servicio.

Ninguno de esos controles demuestra que se expandió la versión correcta, que se compararon bien los URI, que se aplicó la precedencia o que el contador anónimo era exacto.

Separar la evidencia de custodia de la evidencia de transformación. Registrar pares, certificados, claves y verificaciones junto al hash de entrada, la versión del motor y los cuerpos por destinatario.

Un canal seguro puede transportar una proyección incorrecta de forma impecable. La seguridad del trayecto no concede verdad al contenido.

Un libro mayor que conserve las pérdidas

La primera etapa congela principal, autorización, XML y contexto. La segunda registra expansión y procedencia de cada entrada. La tercera aplica comparación URI y forma grupos de duplicados.

La cuarta decide valor explícito o bcc por defecto, precedencia entre clases y relación entre bcc y anonymize. La quinta genera para cada receptor una lista visible, una lista omitida, marcadores y recuentos, más el hash de la parte MIME.

Después llegan resultados independientes: entrega, consumo de parte opcional, presentación, respuesta colectiva, aceptación de sesión, participación y cargo.

El diseño debe conservar también lo que no mostró. Si sólo guarda la salida visible, no puede demostrar que ocultó la entrada correcta. Si sólo guarda la lista maestra, no puede demostrar qué reveló.

Probar la semántica, no sólo el número de envíos

Crear fixtures para atributo ausente; valores to, cc, bcc; anonimización individual y agregada; combinación de ciego y anónimo; duplicados equivalentes con clases opuestas; copia propia del receptor ciego y terminal sin soporte multipart.

Verificar bytes exactos por receptor y un solo envío por identidad duplicada. Después probar la interfaz y la respuesta. Finalmente asegurar que ningún sistema de asistencia o cobro usa la lista como sustituto de evidencia real.

Mutar el orden, quitar atributos, alterar el contador, falsificar la historia, eliminar la parte opcional y reproducir una proyección antigua. Cada aceptación debe dejar una explicación.

La publicación en octubre de 2008 como Proposed Standard y la página de erratas capturada sin coincidencias describen documentos. No prueban implementación actual, adopción ni un incidente concreto.