Puertos, cifrado e inicio de sesión

Módulo 1: Cómo funciona el correo electrónico · Tiempo de lectura: 10 minutos

Objetivo de aprendizaje: Después de esta lección podrá indicar para qué sirve cada puerto de correo, explicar la diferencia entre STARTTLS y TLS directo, y explicar un aviso de certificado o un inicio de sesión rechazado.

Conceptos clave: puerto 25, 587, 465, 993, 995, 143, 110, STARTTLS, TLS directo (implicit TLS, RFC 8314), certificado, nombre de servidor, autenticación SMTP (SMTP AUTH), open relay, bloqueo del puerto 25, contraseña de aplicación, OAuth

Un puerto es una puerta

Un servidor tiene una sola dirección IP, pero muchas puertas. Cada servicio escucha en su propio puerto, un número. Su navegador web llama al puerto 443, su programa de correo al puerto 993 para leer el correo y al 587 o 465 para enviarlo. Si elige la puerta equivocada, nadie responde, o responde alguien que habla otro idioma. Eso produce mensajes de error vagos como «no se puede conectar» o «el servidor no responde».

Los puertos de correo, en resumen:

¿Por qué no usar simplemente el puerto 25 para enviar?

Antes se configuraba el puerto 25 en el programa de correo. Eso es cosa del pasado por dos razones.

En primer lugar: en el puerto 25, un servidor de correo acepta correo de cualquiera, para sus propios dominios. No se inicia sesión. Un servidor que en el puerto 25 también reenvía correo de cualquiera hacia otros dominios se llama un open relay, y los spammers lo aprovechan en cuestión de horas. Por eso el envío de su propio correo al mundo entero se convirtió en un servicio aparte: submission en el puerto 587 (y 465), donde siempre se inicia sesión primero.

En segundo lugar: muchos proveedores de internet bloquean el tráfico saliente hacia el puerto 25 desde conexiones domésticas. Así, un ordenador infectado en un salón no puede enviar spam directamente a servidores de correo. Consecuencia para usted: si intenta enviar desde su programa de correo mediante el puerto 25, puede que no funcione en casa y sí en la oficina, o al revés.

Recuerde: los programas de correo envían mediante 587 o 465, con inicio de sesión. El puerto 25 es para servidores entre sí.

¿STARTTLS o TLS directo?

Hay dos formas de cifrar una conexión de correo.

TLS directo (implicit TLS): la conexión está cifrada desde el primer byte, igual que un sitio web con https. Esto ocurre en 465, 993 y 995.

STARTTLS: la conexión empieza sin cifrar. El servidor dice «puedo cifrar», el cliente responde STARTTLS, y a partir de ese momento todo queda cifrado. Esto ocurre en 587 (y en 25, 143 y 110).

Para la seguridad apenas importa cuál se use, siempre que su programa exija STARTTLS de forma obligatoria. El riesgo de STARTTLS está en el inicio: alguien situado entre usted y el servidor puede eliminar el aviso «puedo cifrar». Un programa que entonces continúe silenciosamente sin cifrar envía su contraseña legible por la línea. Por eso el RFC 8314 (2018) recomienda para los programas de correo el TLS directo (465, 993, 995) por encima de STARTTLS. En la práctica, 587 con STARTTLS y 465 con SSL/TLS son ambos adecuados, siempre que configure el cifrado en su programa como «obligatorio» y no como «si está disponible».

Un error frecuente es la combinación incorrecta: puerto 587 con «SSL/TLS», o puerto 465 con «STARTTLS». El programa espera entonces algo distinto de lo que hace el servidor, y la conexión se cuelga o falla. Recuerde los pares: 587 + STARTTLS y 465 + SSL/TLS. Los programas a veces llaman al TLS directo «SSL», «SSL/TLS» o «TLS»; STARTTLS a veces también se llama «TLS». Fíjese, por tanto, en el puerto.

El certificado y el nombre del servidor

En cada conexión cifrada, el servidor muestra un certificado que demuestra que es quien dice ser. Su programa de correo comprueba dos cosas: si el certificado fue emitido por una entidad de confianza y sigue siendo válido, y si en él figura el nombre que usted ha indicado como servidor.

Esto último es lo que más falla. Si usted indica mail.example.com, pero en el certificado solo figura server12.hosting.example, recibirá un mensaje como «No se puede verificar la identidad del servidor» o «El nombre principal del destino es incorrecto». La conexión en sí está cifrada, pero su programa no puede estar seguro de que esté hablando con el servidor real.

No descarte ese aviso sin más. La solución es indicar un nombre de servidor que sí figure en el certificado (véase la lección 2.1). En un servidor compartido suele ser el nombre del propio servidor, que le indica su proveedor. Otra causa conocida: un antivirus que «analiza» el correo cifrado e interpone su propio certificado. En el aviso aparecerá entonces el nombre del antivirus junto a «emitido por».

Inicio de sesión al enviar

En 587 y 465 debe iniciar sesión antes de que el servidor quiera enviar su correo hacia fuera. Esto se llama autenticación SMTP (SMTP AUTH). En su programa, la opción se llama «el servidor de salida requiere autenticación», «se requiere inicio de sesión» o «autenticación: contraseña normal». Normalmente utiliza el mismo nombre de usuario y la misma contraseña que para IMAP.

Si la autenticación está desactivada, o el nombre de usuario del servidor de salida quedó vacío, podrá leer correo pero no enviarlo. El servidor responderá entonces con algo como 530 5.7.0 Authentication required o 554 5.7.1 Relay access denied. Es la razón más habitual de que «recibir funciona, enviar no».

Un segundo tipo de rechazo: 535 5.7.8 Authentication failed. En ese caso, la combinación de nombre de usuario y contraseña no es correcta. Tenga en cuenta que, tras varios intentos fallidos, muchos servidores bloquean la dirección IP desde la que proceden esos intentos, como protección contra adivinación de contraseñas. Un teléfono antiguo con una contraseña antigua puede así hacer que bloqueen toda su oficina.

Contraseñas de aplicación y OAuth

En proveedores grandes como Google y Microsoft, iniciar sesión con solo su contraseña habitual en un programa de correo independiente funciona cada vez menos. Estos usan OAuth: su programa le envía a una página de inicio de sesión del proveedor, usted inicia sesión allí (eventualmente con verificación en dos pasos), y el programa recibe una clave en lugar de su contraseña. Los programas que no pueden hacerlo reciben a veces una contraseña de aplicación: una contraseña aparte y larga, válida solo para ese programa concreto, que puede revocar por separado.

En un buzón normal de una empresa de hosting, normalmente inicia sesión con la contraseña del propio buzón. Eso hace que una contraseña fuerte y única sea especialmente importante (lección 3.4).

En la práctica: la configuración de un buzón

En un buzón de WebOké, la configuración es: IMAP 993 con SSL/TLS, POP3 995 con SSL/TLS, envío por 587 con STARTTLS o 465 con SSL/TLS, autenticación activada con su dirección de correo completa y la contraseña del buzón. En otros proveedores funciona de forma parecida: los puertos son casi siempre los mismos, solo cambia el nombre del servidor. En la lección 2.1 se explica qué nombre de servidor elegir.

Resumen

• Los programas de correo envían mediante 587 (STARTTLS) o 465 (TLS directo), siempre con inicio de sesión. El puerto 25 es para servidores entre sí y a menudo está bloqueado en casa.
• La lectura se hace mediante 993 (IMAP) o 995 (POP3), ambos con TLS directo.
• Combine correctamente: 587 + STARTTLS, 465 + SSL/TLS. Configure el cifrado como obligatorio.
• Un aviso de certificado suele significar: el nombre de servidor que indicó no figura en el certificado. Descartarlo sin más no es una solución.
• «Puedo leer pero no enviar» es casi siempre: la autenticación del servidor de salida está desactivada o vacía.

Cuestionario

Ejercicio

Ejercicio Z1.4: Puertos y certificado de un servidor de correo. Indique el nombre del servidor entrante y del servidor saliente que utiliza para su propio buzón (si no tiene buzón propio, use imap.gmail.com y smtp.gmail.com). Para el puerto 993 (entrante) y los puertos 465 y 587 (salientes), indique lo que espera: TLS directo, STARTTLS o no accesible, y señale si cree que el nombre figura en el certificado. El programa se conecta por sí mismo a los tres puertos y compara el resultado con sus respuestas.

Para saber más

Los pasos de estos artículos corresponden a los paneles de WebOké; en otros proveedores funciona de forma parecida.

• Manual de DirectAdmin 8.1: Todos los ajustes de un vistazo: servidores, puertos y seguridad
• Manual de DirectAdmin 8.8: Enviar o recibir correo no funciona: así lo soluciona
• Error de certificado al recibir el correo
• No puedo enviar correos electrónicos (la recepción sí funciona)
• RFC 8314 (TLS directo para programas de correo), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)