¿Cuál es la razón técnica detrás de los servidores de correo electrónico intermedios?

0

Survelliance Self-Defense (SSD) de EFF tiene una ilustración de cómo el correo electrónico sobre SMTP pasa por servidores intermedios de intercambio de correo:

SeesperaqueAFAIKacadaservidorintermedioagreguesupropioencabezadoReceived:alcorreoelectrónicoparaquealmenoseltránsitosearastreable.Noestoysegurodelofácilqueesevitaresto.Parecequehayunagrancantidaddeterminologíarelacionadapara Agentes de transferencia de mensajes , como mail relay , servidor de correo, intercambiador de correo y host MX o MTA.

Observando la falta de una amplia adopción de medidas de privacidad de correo electrónico como GNU Privacy Guard (GPG) con Pretty Good Privacidad (PGP) a pesar de los tutoriales disponibles , parece seguro asumir que hay una cantidad significativa de usuarios que se preocuparían por esto, pero son simplemente sin darse cuenta del problema, despistando a los servidores "proxy".

La idea de un lego sobre el proceso de envío de correos electrónicos podría compararse con la de la web:

  • el nombre de dominio del host del servidor de correo del destinatario debe resolverse en una IP a través de DNS
  • se debe configurar una conexión segura con TLS (o SSL) para esa IP
  • el correo electrónico debe enviarse a un servidor en el host en esa IP

Ahora se puede saber que se pueden configurar alias o identidades de correo electrónico, por ejemplo, donde hay varios dominios con direcciones de correo electrónico pero solo un host de un solo controlador. [email protected] puede ser manejado por [email protected] si por ejemplo. una organización tiene múltiples dominios.

Pero esto no parece justificar la transmisión del cuerpo del correo electrónico a cada nodo intermedio único. No es difícil imaginar, hablando en sentido figurado, un sistema en el que dichos alias se resuelven antes enviando el cuerpo real. El servidor de correo en bar.org podría decirle a [email protected] que el host real está en foo.org , antes de que se envíe cualquier cuerpo de correo electrónico.

editar Desde un punto de vista de seguridad, este sistema actual parece ser desafortunado. Si bien existen alternativas como BitMessage , esta pregunta tiene como objetivo averiguar qué se interpone en la seguridad de la infraestructura de correo electrónico actual y comprender. Lo que llevó a este sistema en primer lugar.

¿Cuál es la justificación técnica o histórica que justifica la existencia continua de servidores de correo intermedios?

    
pregunta n611x007 03.07.2014 - 19:12
fuente

3 respuestas

2

SMTP es un protocolo muy, muy antiguo, que data de los primeros días de Internet cuando las conexiones no eran confiables y la seguridad no era un problema importante. Muchos de los problemas con SMTP (relés abiertos, remitentes no autenticados, etc.) son el resultado de tratar de proporcionar una entrega confiable en una red no confiable donde todos conocían a todos los demás (o al menos el administrador de sistemas de todos).

La razón original para los servidores intermedios era que si su servidor no podía comunicarse con el servidor de destino, podría comunicarse con un tercer servidor que podría retransmitir el correo electrónico al destino.

    
respondido por el Mark 03.07.2014 - 21:44
fuente
0

Los servidores de correo electrónico intermedios generalmente no son necesarios, pero permiten escalar y permiten que los servicios de correo electrónico especializados se encarguen de requisitos particulares como:

  • Escaneo AV / AS
  • Filtrado de contenido para controles de información
  • Auditoría de terceros a través de BCCing (para representantes registrados de la SEC, escuelas, etc.)
  • Enrutamiento especializado (enrutamiento P1 / P2, enrutamiento del remitente)

Los servidores de correo electrónico intermedios a menudo son necesarios para los siguientes escenarios

  • Listas de correo
  • Reenvío / reescritura de los encabezados (P1 / P2)
  • Reenvío de correo electrónico de alumnos de la escuela

En la práctica, la mayoría de las compañías (J & J, Schwab, BoA) están configurando un TLS estático entre MTA y tienen una ruta dedicada para esos dominios de destino. Este es, en última instancia, el mejor punto medio entre compatibilidad y seguridad.

Desde el MTA que recibe la entrada estática de TLS, la compañía puede usar tantos MTA intermedios para manejar las necesidades de entrega internas.

    
respondido por el random65537 03.07.2014 - 21:26
fuente
0

Muchas organizaciones tienen un servidor de correo electrónico central que es el único que está expuesto al exterior y que reenvía los correos electrónicos a algún nodo satélite (uno por sitio geográfico o por departamento organizativo) que no es visible para la red externa.

Además, el correo electrónico se puede reenviar de un servidor a otro. Dado que el reenvío puede basarse en el contenido del correo, no puede reemplazarlo haciendo que el servidor de reenvío diga "póngase en contacto con este otro usuario" antes de ver el contenido del correo electrónico.

En cualquier caso, TLS en SMTP y GPG resuelve diferentes problemas. GPG proporciona confidencialidad y autenticidad de extremo a extremo. TLS en SMTP no protege contra un servidor de correo electrónico malicioso que registra de forma subrepticia los correos electrónicos en tránsito. De hecho, TLS en SMTP entre servidores tiene una utilidad práctica limitada, ya que un adversario que puede escuchar en ese punto a menudo está en posición de controlar uno de los servidores de correo electrónico en la ruta. GPG solo requiere lo mínimo: que las máquinas de origen y destino no estén comprometidas.

Lo que GPG no proporciona pero TLS en SMTP proporciona hasta cierto punto es la privacidad. Si un adversario puede ver el tráfico de la red localmente, pero quién no controla ninguno de los servidores SMTP en la ruta del correo electrónico y no ve el tráfico de la red en ambos extremos (lo que permitiría las correlaciones), entonces el adversario no puede saber quién está enviando un correo electrónico. quien.

    
respondido por el Gilles 04.07.2014 - 02:31
fuente

Lea otras preguntas en las etiquetas