Ciclo de vida del correo electrónico después de haber sido enviado

13

Estaba probando la configuración STARTTLS de mi servidor de correo cuando me topé con esta página: https://starttls.info/about . El siguiente extracto me desconcierta:

Cuando envía un correo electrónico a través de su servidor de correo saliente, ese correo electrónico potencialmente realizará múltiples saltos entre diferentes servidores de correo antes de llegar a su destino. Todos estos servidores intermedios tendrán que tener un fuerte soporte STARTTLS, para que su mensaje no sea expuesto en una o más etapas de su viaje.

Tenía entendido que el proceso de enviar un correo electrónico era el siguiente:

  1. El servidor de correo realiza una búsqueda de DNS para obtener el MX del nombre de dominio del destinatario.
  2. El servidor de correo inicia una conexión a la IP obtenida en el puerto 25 (SMTP).
  3. Si ambos servidores admiten cifrado oportunista, se establece una conexión segura.
  4. El correo electrónico se entrega al destinatario (EHLO, CORREO DESDE :, RCPT A :, DATOS,.)

Ahora, ¿dónde hay una oportunidad para que el correo electrónico rebote en varios servidores?

email Ejecutivos
fuente
1
Tome un correo electrónico recibido, mire los encabezados. Cada línea "Recibido:" muestra un sistema por el que pasó el correo. Podría haber varios sistemas en el mismo host (por ejemplo, un filtro de correo no deseado o un escáner de virus), en su mayoría reconocibles desde la dirección "localhost". Pero el resto serán todos los hosts que manejaron ese correo electrónico. Al menos en la medida en que cumplan con RFC y dejen uno de esos encabezados "Recibidos:".
Dubu

Respuestas:

19

El correo se devuelve regularmente entre servidores. Por ejemplo, si envío un correo electrónico a un amigo, podría:

  • Ir de mi computadora a mi propio servidor de correo (con suerte encriptado)
  • Mi servidor de correo lo envía a su servidor inteligente, ya que está configurado para no enviar correo directamente
  • El smarthost lo envía al registro MX del dominio de destino, que resulta ser un filtro de spam alojado
  • El filtro de correo no deseado intenta enviarlo al servidor de correo real del objetivo, pero es inalcanzable, por lo que utiliza el MX secundario, un sistema alojado que almacena su correo electrónico en caso de que el servidor de correo real esté inactivo.
  • El servidor de correo real vuelve a funcionar, el MX secundario envía el correo electrónico al servidor de correo objetivo.
  • Mis amigos descargan su correo electrónico desde su servidor de correo.

Esa es una configuración bastante común y hace que el correo electrónico rebote alrededor de 6 veces. Eventualmente llega a donde va, pero a menos que todos esos servidores usen STARTTLS u otro cifrado, en algunos puntos no se cifrará. Incluso con el cifrado de transporte, el administrador de cualquiera de esos servidores podría leer el correo electrónico. Se almacena sin cifrar en sus discos duros mientras espera ser enviado a la siguiente etapa.

Fácilmente podría haber aún más si mi amigo tuviera su correo electrónico configurado para reenviarlo a otro lugar, lo cual es común si su proveedor de alojamiento web también lo hace, y usted lo reenvía a su cuenta de Gmail.

Si le preocupa que las personas lean su correo electrónico, lo mejor que puede hacer es cifrar el mensaje usando algo como GPG, no confiar en el cifrado de transporte. Por supuesto, esto requiere que la persona que recibe el correo electrónico también se preocupe lo suficiente como para configurar GPG e intercambiar claves.

Conceder
fuente
¡Gracias por su respuesta! Aceptado por claridad (lo siento TomTom, ¡pero el tuyo también fue genial!). Buen detalle al señalar que los correos electrónicos se almacenan en texto sin formato en los servidores intermedios: no veo STARTTLS como otra cosa que no sea una defensa contra las escuchas pasivas.
Ejecutivos
@Executifs no se ofende. Dicho esto: "estatuas como cualquier otra cosa": una defensa contra las escuchas pasivas es crítica. Ambas partes controlan prácticamente todos los servidores intermedios (relés de envío, relés de destinatario) pero no tienen control sobre el medio de conexión. En los tiempos de hoy, donde Obama y otros funcionarios leen los correos electrónicos de todo el mundo para recibir noticias de desayuno (daramatización) que encriptan el camino entre los servidores es súper crítico.
TomTom
@TomTom Lo siento, parece que mi comentario no fue claro. Quise decir que para mí, STARTTLS es principalmente una defensa contra las capacidades de intercepción masiva y no retransmite las miradas indiscretas del administrador (para lo cual GPG sería una solución). Así que estoy completamente de acuerdo contigo en esto.
Ejecutivos
7

Pruebe eso: el servidor que envía no es el que finaliza. es MI servidor de puerta de enlace para correos electrónicos entrantes que está haciendo algunas cosas agradables contra el correo no deseado y luego lo reenvía al servidor real.

Se pone aún mejor. El servidor de correo electrónico que utiliza no es el que utiliza su empresa frente a Internet. NO realiza una búsqueda de DNS, sino que reenvía todos los correos electrónicos a un servidor de puerta de enlace que ENTONCES los envía al destinatario final. Esta no es una configuración rara en organizaciones más grandes.

Mantengo un sistema como ese en el que múltiples redes comparten un servidor de puerta de enlace común para correos electrónicos entrantes y salientes. Los correos electrónicos entrantes se reenvían a uno de los múltiples servidores, según el cliente.

En el sitio entrante también puede ser que el servidor de correo electrónico real esté inactivo. MX puede tener entradas de respaldo, y en algunos casos, estas solo almacenarán el correo electrónico y luego lo reenviarán una vez que el servidor real esté disponible nuevamente.

TomTom
fuente
Todas esas cosas, más los alias.
NickW
3

La forma en que lo describió es más o menos cómo funciona en todos los ámbitos.

Todavía hay servidores de correo intermedios, pero generalmente son los servidores públicos a los que se conecta su servidor de origen. Ese servidor puede retransmitir el mensaje a un servidor interno en función de cualquier número de reglas, como nombre de usuario, hora, carga, contenido (spam), etc.

Espero que estas organizaciones o proveedores externos admitan las mismas características en todo momento. Su correo no debe transitar a través de un servidor de correo desconocido para el origen o el destino, ya que todos los intermediarios deben ser propiedad o estar administrados por una parte confiable.

David Houde
fuente
Esa última oración ni siquiera es cercana a la verdad; pruebe dig mx insolvency.gsi.gov.ukuno de los innumerables ejemplos de enrutamiento de correo a través de servidores que no son propiedad de ninguna organización de origen ni de destino. O envíe un correo a cualquiera de los dominios de la legión que tienen su correo manejado por gmail.
MadHatter
2
Estás en lo correcto. Lo expresé mal, y tenía la intención de decir que el correo no debería enrutarse a través de un servidor de correo externo desconocido mientras está en tránsito hacia el destino final. Que cualquier servidor de correo intermedio si no es propiedad del origen o destino, al menos es conocido y administrado por una parte confiable. He editado la respuesta, gracias por aclararme.
David Houde
Lo que tienes ahora está mucho más cerca de cómo creo que todo funciona, así que he eliminado mi voto negativo.
MadHatter
Para agregar al comentario de @ MadHatter, alguien que utiliza un servicio de correo externo de este tipo también puede olvidarse de imponer otras características de seguridad (como SPF).
Hagen von Eitzen