Cada día hay más organizaciones que optan por enviar mensajes por correo electrónico encriptado o a través de un servicio privado de retransmisión de correo electrónico que se ocupa de enmascarar la identidad del correo electrónico y el dominio del remitente original. Cualquiera de estos sistemas podría funcionar con Zendesk, pero el resultado depende en gran medida del estado en que se encuentre el correo que se envía o reenvía, y de la forma en que se encuentre durante esa parte del proceso de retransmisión. Al tratarse de servicios de correo electrónico privados, el éxito radica en cómo mantienen la coherencia del hilo de la conversación y cómo se adhieren a los protocolos que permiten que eso suceda.
Si es posible, y garantizando el cumplimiento de todos los acuerdos o los requisitos legales, de seguridad y de privacidad, es mejor enviar o reenviar a Zendesk un correo electrónico sin encriptar cuando se pueda verificar que se está haciendo de forma segura.
Zendesk no le puede descifrar un correo electrónico como si nosotros fuéramos el destinatario previsto y tuviéramos la identidad necesaria para tomar medidas respecto al correo electrónico o proporcionarle cualquier información útil sobre quién fue el remitente que le envió el correo electrónico a través de un servicio de retransmisión privado. El propósito de la encriptación (que exige la autenticación para el proceso de desencriptación) es evitar la intercepción no deseada de la información. Zendesk funciona como un repositorio de información, pero con más frecuencia está asumiendo también el rol de la retransmisión intermediaria dentro de un contexto más general. El propósito de las retransmisiones de correo electrónico privadas consiste en opacar la identidad del remitente y su dominio verdadero.
Mientras que desencriptar el correo electrónico o determinar la identidad de un remitente enmascarado es casi imposible en términos matemáticos, el solo hecho de tratar de desencriptarlos constituiría una violación de nuestras propias políticas de seguridad y privacidad, y posiblemente una violación de las leyes estatales y federales relacionadas con la privacidad.
Zendesk es responsable de preservar la seguridad de las comunicaciones, lo que incluye los servicios de envío de correos electrónicos encriptados o privados.
Este artículo contiene las siguientes secciones:
Encriptación del correo electrónico
Actualmente se usan distintas formas de encriptación del correo electrónico. Las dos que se usan con más frecuencia son S/MIME y PGP/MIME.
- S/MIME (Secure/MIME) es la forma más usada y está incorporada en la infraestructura de varios proveedores de correo electrónico importantes como OSX, iOS, Outlook, Gmail, etc.
- PGP/MIME (PrettyGoodPrivacy/MIME) funciona con un modelo descentralizado y una herramienta de encriptación de terceros.
También existen muchas otras que incluyen protocolos de encriptación que son de dominio exclusivamente privado. Algunas funcionan únicamente cuando el correo electrónico está en tránsito, por lo que son invisibles para los usuarios finales que ven los correos electrónicos dentro de sus clientes autenticados. Otras requieren una autenticación estricta de parte del usuario antes de que el correo electrónico pueda ser legible para un ser humano. Cuando un correo electrónico se reenvía a otro servicio, como suele suceder al llegar a los servidores de procesamiento de entrada de Zendesk, dependemos por completo del estado de encriptación en que llega el correo electrónico.
Actualmente Zendesk admite solo TLS-oportunista como protocolo de encriptación de correo electrónico de extremo a extremo. Eso quiere decir que tanto en el correo electrónico entrante como en el saliente aceptaremos o enviaremos correo electrónico encriptado por TLS siempre que el servidor de envío o de recepción también admita ese protocolo. Aquí puede consultar un artículo de información acerca de nuestras funciones de seguridad.
Retransmisión privada del correo electrónico
Este servicio está diseñado para opacar la identidad del remitente. En las mejores circunstancias interactuamos con normalidad, pero con una dirección de correo electrónico proxy. Si ocurren problemas, generalmente ocurren en el uso de las direcciones tokenizadas “Responder a:”. Esos campos de encabezados le indican al servicio de correo electrónico de un destinatario la dirección a donde debe enviarse cualquier respuesta. Se convierte en la dirección en el campo “Para:” del cliente de correo electrónico (MS Outlook, Mac Mail, Gmail, Yahoo, etc.) cuando se hace clic en “Responder” o “Responder a todos”. La retransmisión privada de correo electrónico debe por necesidad rellenar este campo con algo que no sea la dirección de correo electrónico del remitente original porque si no, la retransmisión no sería privada. A menudo estos servicios dependen de una dirección tokenizada que solo se puede analizar y dirigir en función de la cadena tokenizada que se encuentra en la porción local de la dirección de correo electrónico, así como la porción del dominio de la dirección de correo electrónico que refleja el recurso de la retransmisión privada de correo electrónico en lugar del remitente original. Esos tokens están protegidos contra la posibilidad de conversión por un destinatario, como aspecto fundamental del servicio que ofrecen.
Zendesk comprende que cualquier comunicación que usted tenga con su cliente es importante, e igual de importante es el hecho de que los remitentes de este tipo de correo electrónico desean que su información sea vista únicamente por el destinatario que ellos hayan designado. Si usted nos reenvía correo electrónico a nosotros, su propia dirección de reenvío bien podría ser el destinatario previsto. Si desea más información o aclaración sobre estos tipos de retransmisión de correo puede ir a la bandeja de entrada de la dirección de soporte que se usa de reenvío.
2 comentarios
Iniciar sesión para dejar un comentario.