¿Se garantiza que los correos electrónicos de BCCing sean confiables?

En otras palabras, ¿es seguro asumir que ninguno de los destinatarios verá correos electrónicos en BCC? ¿Qué sucede si el destinatario es administrador de su servidor de correo (pero no del remitente) y puede hacer alguna modificación en su servidor?

No. SMTP es un protocolo de texto sin formato , que utiliza métodos de almacenamiento y reenvío .

Lo que esto significa:

• Texto sin formato: todos los servidores que transmiten este mensaje lo ven en su totalidad, incluida toda la información del encabezado. Aunque cada destinatario en el campo BCC generalmente recibe su propio correo electrónico (por lo que el servidor envía un correo electrónico personalizado donde todos los demás destinatarios BCC deben ser eliminados (¡énfasis en debería !), A diferencia de CC, donde los datos se conserva), que un solo correo electrónico todavía se almacena en los encabezados, en texto sin formato (sin cifrado, sin ofuscación, nada).
• Almacenar y reenviar: el correo electrónico no necesariamente va directamente al servidor de correo del destinatario, sino que podría reenviarse (y generalmente se reenvía) a través de una serie de servidores de correo electrónico intermedios; se almacena en cada uno (por un tiempo indefinido) y luego se reenvía al siguiente salto (nuevamente, no necesariamente el destino final).
• tenga en cuenta que el correo electrónico se envía a una dirección inexistente, completa, bloqueada o que no funciona: la copia del correo, junto con los datos de diagnóstico, puede terminar en varios lugares, no todos necesariamente buzones ( por ejemplo, registros de errores o el buzón del administrador de correo)
• (esto antes de que su correo electrónico termine en los servidores de correo del destino, que podrían almacenarlo para siempre y entregárselo fácilmente a quien venga con una citación, pero esa es una historia ligeramente diferente)

En otras palabras, su suposición es insegura. Si desea privacidad y seguridad, use firmas digitales y cifrado, por ejemplo, GPG; El correo electrónico de vainilla es una herramienta incorrecta para tal trabajo.

Cualquier agente de transferencia de correo (MTA) que cumpla totalmente con RFC 2822 (específicamente, sección 3.6.3, Campos de dirección de destino ) eliminará el Bcc:campo del encabezado antes de intentar la entrega, haciendo imposible que los destinatarios no ciegos puedan determinar los destinatarios ciegos 'identidades.

Hay un par de capturas:

• A menos que tenga control sobre el primer MTA que alcancen sus correos electrónicos salientes, no puede garantizar que el software de ese MTA haga lo que indica RFC 2822.

• El hecho de que un correo electrónico suyo a un destinatario que haya sido copiado a ciegas atravesó uno o más MTA puede sobrevivir en los registros de esos MTA.

Nunca debe suponer que los destinatarios no se darán cuenta del destinatario de BCC. Los destinatarios de BCCed presionaron "Responder a todos" en su programa de correo y anunciaron a todos que recibieron un correo antes, en una sorprendente falta de comprensión de lo que realmente significaba BCCed. Si realmente necesita que sea privado, reenvíe el mensaje desde su carpeta Enviados después de enviarlo a los destinatarios originales, de modo que la única otra dirección en los encabezados del mensaje sea la suya.

Dicho esto, incluso si usó BCC, siempre que el servidor del destinatario BCCed esté separado del destinatario original, el servidor del destinatario no tendría acceso a la información de BCC, ya que se habría eliminado (o más probablemente nunca se incluyó en el cuerpo del mensaje) por el servidor de correo de su proveedor.

En una nota al margen: SMTP no es confiable, ni particularmente privado. Algunos carteles afirman que existen "cadenas" de servidores SMTP, pero en general, SMTP envía desde su computadora, a su ISP, al ISP de los destinatarios. (y sin importar cuántos servidores tengan internamente) En general, su correo NO se enrutará al servidor de correo de un tercero, y de hecho, tales intentos generalmente no se permiten por razones contra correo no deseado. (Hay excepciones, ya que los pequeños proveedores y las redes domésticas se reenviarán a su proveedor, pero esta es la excepción, no la regla)

Dicho esto, no se garantiza que el correo electrónico en tránsito esté encriptado, y no se debe confiar en que cualquier cosa potencialmente sensible no esté encriptada en Internet a través de CUALQUIER método, incluido el correo electrónico, ya que es trivial para cualquier proveedor grande, o una empresa de telecomunicaciones para aprovechar las fibras que se ejecutan sus instalaciones o paquetes de registros que viajan a través de sus enrutadores.

El FBI lo hace regularmente a través del Carnivore y otros programas, y también se han documentado elementos corruptos en el pasado.

Su cliente o servidor de correo electrónico (no sabe cuál) debería eliminar la información de BCC antes de enviar un mensaje. Si aparece un mensaje de CCO en un mensaje y luego ve la fuente, no debería encontrar su dirección de correo electrónico en ningún lugar, excepto en la línea De (verificado con mi propio correo).

Todo depende del servidor. La mayoría de los servidores tomarán la línea BCC y básicamente enviarán el mensaje una vez por dirección. básicamente colocando la dirección bcc en el envío de la línea cc, la siguiente dirección en la línea cc y el tipo de envío. Pero todo depende de la configuración del servidor de CORREO. BCC nunca debe ir más allá de su servidor de correo saliente.

Todo lo que viaja en la red sin firma digital o cifrado puede modificarse fácilmente. Si necesita integridad de extremo a extremo para el correo electrónico, use la firma PGP / GPG.

También deberá transferir su clave pública PGP / GPG a los destinatarios de alguna manera (para que puedan verificar que sus mensajes de correo electrónico sean realmente suyos). Su tipo de problema de huevo y gallina: es establecer un canal de comunicación seguro, pero ya requiere un canal de comunicación seguro. Enviarlo por correo electrónico está bien, pero debe verificar la huella digital de la llave PGP / GPG por teléfono o por otros medios. Publicarlo en un sitio web habilitado para https también es una buena idea, ya que SSL proporciona las garantías de integridad de transporte necesarias.