Servidor Email

El correo combina transferencia, entrega y acceso al buzón. Separar MTA, MDA y cliente ayuda a encontrar dónde quedó el mensaje cuando parece haberse perdido entre portales. (・_・?)

La configuración de un servidor Email es una tarea compleja. Los requisitos son extensos y el entendimiento de su funcionamiento debe ser preciso para evitar problemas.

Los puntos que debemos tener a consideración:

• Mail Transfer Agent
  • Responsable de manejar el tráfico SMTP
  • Envía el correo de tu usuario a otro MTA y viceversa
• Mail Delivery Agent
  • LDA.
  • Recibe el correo del MTA y lo mueve la bandeja de usuario correspondiente.
  • Distintos MDA tienen distintos formatos lo que cambia el cómo se almacenan los correos
• IMAP y/o POP3 server
  • Protocolos usados por los clientes, es la forma en que se reciben los correos
  • IMAP es complejo, permite multiples usuarios accediendo a la bandeja.
    • Se copian los mensajes del servidor al cliente, se mantienen en el servidor
  • POP3 es más sencillo
    • POP3 permite recuperar mensajes y solicitar su eliminación; el cliente puede configurarse para conservar copias en el servidor.
• Filtro antispam
• AV
• Webmail
  • Acceso desde la web
• Nombre de dominio
• DNS records
• Certificados para TLS

Correr un servidor propio tiene sus ventajas: la escalabilidad propia y el costo puede ser menor o mayor al incluir operación, reputación, seguridad y disponibilidad. Sin embargo a veces puede resultar más sencillo saltarse todo esto y utilizar un servidor externo como Zoho, Office365, Google.

Una tercera opción es la de utilizar un servicio de reenvio de correos, como mailgun, donde creamos un correo con un dominio propio. Los correos recibidos en esa dirección, se redireccionan automáticamente a nuestro correo real, es a grandes rasgos una máscara (pero más complejo).

Protocolos

IMAP

Internet Message Access Protocol es el protocolo usado por la mayoría de las cuentas. Es donde utilizamos servidores remotos. Utiliza dos puertos:

• 143
  • IMAP sin TLS implícito; puede negociar STARTTLS, que debe exigirse cuando corresponda
• 993
  • IMAP sobre TLS implícito (cifrado)

POP3

Post Office Protocol 3. Se descargan los mensajes de un servidor al cliente. Tiene la ventaja de ser rápido, no cargar el servidor con requests constantes y poder mantener acceso a los correos aún sin acceso a internet. La eliminación depende de los comandos y la configuración del cliente; descargar con RETR no equivale a borrar con DELE, dificultando la sincronización. Utiliza uno de los dos puertos:

• 110
  • Por defecto, no encriptado
• 995
  • encriptado

SMTP

SMTP transfiere correo y permite envío al servicio de submission. El intercambio entre MTAs y la autenticación de usuarios son contextos distintos: submission suele exigir autenticación y un relay no debe quedar abierto. El spam no se explica solo por ausencia de autenticación SMTP. También maneja las notificaciones de recepción de email. Utiliza dos puertos:

• 25
  • Por defecto, no encriptado
  • Algunas veces está filtrado (justamente por el spam)
• 465 / 587
  • 465 usa TLS implícito; 587 es submission, normalmente con STARTTLS. El número de puerto por sí solo no prueba cifrado

SMTP relay

Importante mencionar que si vamos a mandar emails en masa o por grandes cantidades, el uso de un relay es importantísimo para que los correos no sean marcados como spam, liberar carga del servidor y mantener separadas nuestras transacciones, acciones, etc. Su configuración puede ser compleja pero existen alternativas de terceros.

HTTP

Si bien no es un protocolo de correos como tal, sí es el protocolo por el cual lo más probable es que se acceda al email. Es la parte de webmail mencionada más arriba.

---

Véase también

• Puertos comunes — Puertos habituales de los protocolos de correo.

Referencia: RFC 1939: POP3.

Contraste: uso de TLS para correo, RFC 8314. POP3/110 también puede negociar STLS. IMAP administra buzones y acceso concurrente, no necesariamente varios usuarios compartiendo una identidad. Un relay no garantiza evitar spam: importan autenticación de dominio (SPF/DKIM/DMARC), reputación, consentimiento y contenido. Webmail debe usar HTTPS. Los proveedores nombrados son ejemplos, sin recomendación ni comparación actual de planes.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi · Rin]                |
| SEAL: sha256/12: d3ca7b2092c4          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+