Montando un servidor de correos con MailAD

MailAD (Freepik)

MailAD es una solución de correos creada por mi (AKA @pavelmc), es una receta para crear de la manera más automática posible un server de correo vinculado a un servidor de dominio (no importa si es Windows o Linux) y controlar todo lo posible desde la propia interfaz del Directorio Activo

Solución presentada obedece varias reglas y premisas:

  • En este momento no está lista para ser puesto de cara a internet (es una de las metas de desarrollo), nosotros recomendamos usar Proxmox Mail Gateway de cara a internet como Mail Gateway y MailAD interno en la DMZ sirviendo a los clientes finales.
  • No incluye filtrado de protocolos, o sea es tu tarea como sysadmin restringir con un firewall (mencioné que debe estar en al DMZ?) para solo dejar pasar a los clientes a los puestos seguros (587, 993, 995)
  • Actualmente no realiza procesamiento Anti-Spam o Anti-Virus (Planeado)
  • Por el momento solo soporta un dominio de trabajo (Planeado el soporte de multi dominios)
  • Soportado por ahora en:
    • Ubuntu Bionic 18.04
    • Ubuntu Focal 20.04
    • Debian Buster 10

Ya MailAD se usa en más de 5 sitios de internet en producción sin ningún percance o falla reportada, por lo que yo lo recomiendo si planeas instalar un server de email en empresa con un solo dominio.

Para probarlo necesitas:

  • Un server de dominio funcional (si, puedes usar el que tienes actualmente en tu empresa, puede ser Windows o Samba 4 en Linux)
  • Un a PC para instalar el server de correo con algunas de las distros soportadas
  • Acceso al repositorio para la instalación de paquetes
  • Acceso a internet aunque sea por proxy

Para ejemplo usaremos las siguientes configuraciones

Server de dominio:

  • IP: 10.0.3.2
  • Nombre: dc.co7wt.cu
  • Dominio: co7wt.cu
  • Corriendo: Ubuntu Focal 20.04 LTS (LXC en mi PC)

Server para mail server

  • IP: 10.0.3.7
  • Nombre: focal.co7wt.cu
  • Corriendo: Ubuntu Focal 20.04 LTS (LXC en mi PC)

Manos a la obra, pero antes una aclaración: Todos estos pasos están reflejados en los documentos del repositorio de MailAD en Github: https://github.com/stdevPavelmc/mailad/ pero en Inglés, o sea que cuando clonas el repositorio ya tienes la ayuda que necesitas

Configurar el server de dominio

Utilizando la herramienta de administración del dominio (RSAT) lo primero que debemos determinar y configurar el BaseDN de nuestro dominio. El DN o “Distinguished Name” es el nombre distintivo que representa un elemento de un directorio LDAP, se llama BaseDN a un elemento que contiene un grupo de elementos de interés.

El BaseDN en nuestro caso es el elemento (Unidad Organizativa) que contiene todos los usuarios y grupos que serán manejados por el server de correos; ojo esta no debe ser la base del dominio pues nos interesa que cierta información quede fuera por temas de seguridad, esto lo veremos luego.

En este tutorial usaremos un dominio de ejemplo llamado co7wt.cu como ya mencionamos, en la foto siguiente podemos apreciar la estructura actual del dominio, pronto entraremos en otros detalles.

MailAD Domain

Aquí el BaseDN sería:

ou=CO7WT,dc=co7wt,dc=cu

A los no versados en LDAP, una guía rápida:

  • Las partes se reparan con comas y son siempre «tipo=valor»
  • Los tipos mas comunes son:
    • Partes del dominio (dc)
    • Unidades organizativas (ou)
    • Carpetas de sistema, por ejemplo “Users” (cn)
    • Nombres de usuario (cn)

Ya identificamos el Base DN ahora debemos crear al menos un usuario, digo al menos porque si usan el Dominio activo su usuario ya está creado.

El otro usuario es un usuario satos que se usará solo para que tanto Postfix como Dovecot pregunten por datos al Dominio, mi sugerencia es crear este usuario en la OU “Users” (o Usuarios si estás en español) del árbol del directorio activo, donde mismo están el administrador del dominio y otras cuentas privilegiadas.

Recuerdan que el BaseDN contendrá los users con correo, pues al crear el user de enlace (que llamaremos linux) en esa Unidad Organizativa estamos sacándolo del procesamiento del correo

Las únicas restricciones de esta cuenta son:

  • El nombre de usuario no debe contener espacios
  • Contraseña bien compleja pero no similar a las de los administradores del domino (por temas de seguridad)
  • Usuario no puede cambiar la contraseña
  • Contraseña no caduca

Al crear el usuario linux en la carpeta “Users” su DN será el siguiente:

cn=linux,cn=Users,dc=co7wt,dc=cu

Tip: no importa que estés es español y la carpeta se llame “Usuarios” por debajo el LDAP la llama “Users”

El otro usuario es nuestro usuario, el del usuario que será administrador del correo y al cual llegarán las notificaciones y otros temas relacionados, en mi caso de ejemplo (ver la imagen anterior) este usuario se llama Pavel Milanes y radica en la OU “Informática” debajo del BaseDN

Ahora configuremos a este usuario para que pueda tener correo, veamos la imagen siguiente y comentemos:

MailAD Propiedaddes de un usuario

Explicación de las opciones:

  • Correo Electrónico: este es el correo electrónico del usuario en el dominio, puede coincidir o no con el nombre de usuario, en este caso es [email protected] pero pudiera ser [email protected] por ejemplo, se puede cambiar durante la explotación del server, sin problemas.
  • Oficina: esto es IDÉNTICO para todos los users del dominio y es la carpeta donde se almacena el correo de todos los usuarios del dominio en el server linux
  • Número de teléfono: Es la quota del user para su buzón, M = Mega, G = Giga, T = Tera, y si es REQUERIDO, o sea tiene que existir, todos tienen que tener una quota.
  • Página web: esta es la referencia a la carpeta del buzón de correos dentro del almacén de correos general, puede ser cualquier nombre pero se recomienda que sea idem al user de correos para organizarnos mejor. No se debe cambiar durante la explotación porque se creara una nueva carpeta automáticamente y el user perderá sus correos anteriores. Es REQUERIDO el “/” final, de esta manera se le dice al server de correo que es una carpeta y no un fichero

Con todos estos elementos llenos pasaremos a la PC donde se instalará el server de correos

Configurando el server de correos

En esta Pc debemos verificar algunas cosas antes de instalar el soft:

  • DNS, esa máquina debe tener como DNS al server de dominio u otro server que haga forward al server de dominio
  • Que puedes hacer ping al server de dominio y tienes conectividad irrestricta con el mismo
  • Debe tener bien configurado el nombre DNS completo (FQDN) para probarlo intente esto en consola

Por ejemplo este es un tést básico para saber si lo tenemos bien configurado:

Si el segundo comando devuelve solo el nombre del host (que es lo común) entonces necesitas configurarlo para que funcione como en el ejemplo que comento, aquí tienes un ejemplo de como configurarlo correctamente que es para Ubuntu pero es lo mismo en cualquier Debian like distro

Una vez solucionado estos detalles podemos pasar a instalar el software como tal (si estás detrás de un proxy puedes ver las notas en el fichero INSTALL.md del repositorio acerca de como configurar el entorno para que funcionen las cosas vía proxy)

Mailad está diseñado para radicar en /root, o sea en la carpeta del superusuario y para que todas las acciones se ejecuten como usuario root, así que si no lo eres, que esperas?

Con esto actualizamos nuestro sistema, instalamos algunas dependencias, clonamos el repositorio con el software necesario y nos aseguramos que estamos en al rama master (que es la única segura para producción)

Ahora debemos crear la config básica

Esto crea una config básica en /etc/mailad/mailad.conf fichero que editaremos para configurar nuestro server, a continuación se mostrará las opciones por defecto para el dominio de ejemplo y al finalizar algunos comentarios

Nota: Aunque en el fichero original están comentadas cada una de las opciones con todo detalle se pone aquí solo las opciones por brevedad

Tip: no ponga espacios al rededor del signo “=”, o sea “DOMAIN = co7wt.cu” está mal

  • DOMAIN: el dominio de nuestro server de correos
  • HOSTNAME: nombre de nuestra PC server de correos
  • ADMINMAIL: email del administrador del server de correos (El email declarado a nuestro server)
  • ALWAYSBCC: la cuenta de copia de correos (La que exige la OSRI) debe ser un usuario real configurado como mismo configuramos al usuario “Pavel Milanes” en el directorio activo
  • MESSAGESIZE: El tamaño máximo de los mensajes en MB, no use decimales, o sea 3.5M es INCORRECTO, solo use enteros
  • MYNETWORK: las PC o subredes que se consideran “Amigas” del server de correo y a las que no se les pedirá autenticación para enviar correos (Se excluye el propio server) estos pueden ser otros servers de la DMZ para que envíen notificaciones a ti usando el server de correos por el puerto 25
  • RELAY: si tienes una config en un VPN nacional y necesitas enviar tus emails salientes a otro server pues esta es la opción, se recomienda que si es una IP se debe escribir entre corchetes
  • VMAILSTORAGE: almacén de correos, debe coincidir con la configuración del usuario en la propiedad “Oficina”
  • HOSTAD: nombre del server de dominio, debe ser el nombre
  • LDAPBINDUSER: siempre entre comillas, el DN del user linux que creamos anteriormente
  • LDAPBINDPASSWD: siempre entre comillas, el passw0rd user linux que creamos anteriormente
  • LDAPSEARCHBASE: el BaseDN determinado anteriormente
  • SSL* : datos para el certificado autogenerado, si usted usa un certificado de Let’s Encrypt dejelo como está porque no se usará
  • EVERYONE: alias para la lista de correos del todos los usuarios del dominio, solo debe ser de su conocimiento, esto le permitirá enviar mensajes masivos y mantener la dirección de la lista oculta; no es recomendando usar [email protected]… pues es evidente, use algo personal y en broma como [email protected] [dejo a la imaginación del lector la frase que forman esas iniciales] Otro detalle es que este alias tiene una restricción que solo se puede usar desde cuentas de tu dominio, para alguien externo este alias no existe.
  • SPAM_FILTER_ENABLED: yes|no Habilita o no el filtro de Sieve para SPAM en todo el dominio, no recomendado si los usuarios usan POP todavía, pues puede que algunos mensajes caigan directamente en Trash y el user no los vea.

Con esto configurado para su dominio pues manos a la obra, instalemos las dependencias de ejecución:

En mi caso ya estaban instalados, así que en su caso será diferente, se instalaran algunos paquetes, pues ahora chequearemos la configuración por problemas:

En caso de que te de algún problema recibirás un mensaje de error con un tip sobre donde mirar para solucionarlo.

Una ves solucionada esta parte pasamos a la configuración de los certificados, en este paso si no tienes certificados el script generará uno autofirmado con 10 años de validez, en el caso que tengas un certificado de Let’s Encrypt pues simplemente debes identificar dos ficheros entre ellos

fullchain*.pem y privkey*.pem (o .key)

Simplemente copialos a la carpeta /etc/mailad/le/ en el server de correos con los nombres: fullchain.pem y privkey.pem antes de ejecutar lo siguiente

En mi caso tengo configurado los certificados de Let’s Encrypt (Falsos para probar) y ven lo que resulta. En el caso que genere los certificados autofirmados verás la generación en la consola.

Tip: si usas Let’s Encrypt hay un método descrito en la documentación para cambiar los certificados cuando caduquen.

Pues ya toca ya instalar y configurar las aplicaciones, esto lo logramos con el siguiente comando:

Si todo funcionó como debe pues la salida del comando anterior debiera ser similar a al final de lo que se muestra, o sea el estatus de postfix y dovecot corriendo correctamente

En algunas circunstancias es posible que la PC que usemos tenga instalado previamente algunos de los softwares y nos de un error de que tenemos un entorno sucio, esto se soluciona con el comando que sugiere el mensaje de error: “make install-purge” y al terminar este comando hacer nuevamente “make provision” que ya deberá funcionar

En este punto debemos tener nuestro server básico corriendo, y digo básico porque hay otro grupo de funcionalidades que revisar, pero antes un tip.

Sabías que te podías ahorrar todos los comandos “make tal-cosa” que diste luego de configurar tu fichero de /etc/mailad/mailad.conf?

Si, los he hecho ir paso a paso para que aprendan como se arma el “tinglado” pero es suficiente con hacer un “make all” luego de configurar el fichero /etc/mailad/mailad.conf y el script hará todos los pasos por nosotros, en caso de algún problema es corregirlo y seguir dando “make all” hasta que termine.

Características adicionales

Integración con el directorio Activo

Como ya se han dado cuenta, agregar un usuario es tan simple como añadir este usuario al directorio activo y añadirle los datos personalizados del correo descritos para el usuario “Pavel Milanes” en la parte inicial

Algunos detalles:

  • Que queremos deshabilitarle el correo a esa persona pero que la cuenta siga activa en el dominio: elimina el campo correo de sus propiedades y este deja de tener correo, pero los correos no se eliminan, es solo añadirle nuevamente el correo y ya tiene todo nuevamente
  • Que pasa si deshabilito el usuario en el dominio: igual deshabilitas el correo, es como si el usuario no existiera en el dominio
  • Quiero cambiarle la dir de correos a un user: cambia solo la dirección de correo y automáticamente funciona, no perderá correos a menos que cambies la propiedad “Página Web” que es donde este user almacena los correos

Las características de correo están ligadas al estado de la cuenta de correos, en ciertos casos esotéricos puede ser que se den propiedades no contempladas en el AD y el usuario deje de recibir correos o poder loguearse, en este caso por favor contáctenos para verificar que pudo haber pasado y eliminar este problema.

Como medida paliativa simplemente desbloqueando la cuenta y cambiando la contraseña directamente (no use el “Usuario debe cambiar la contraseña luego”) cámbiela directamente usted, suele eliminarse la condición anómala

Control de accesos por grupos de usuarios (Local/Nacional)

Si, esta es una característica muy solicitada de los servidores de correo en Cuba. En ciertas empresas exigen que existan cierto grupo de usuarios que solo puedan manejar correos en el dominio .cu y en algunas incluso que solo puedan manejar correos en el dominio local.

Pues esta función es simple (y opcional) en MailAD, solo tienes que crear una OU y dos grupos, tal como se muestra en la imágen que se muestra a continuación:

MailAD User Access Control

Debes crear una OU (Unidad Organizativa) llamada MAIL_ACCESS y dentro de esta dos grupos nombrados: Local_mail y National _mail (OJO así textualmente, las mayúsculas y minúsculas importan)

El esquema es simple:  los usuarios que pertenezcan al grupo Local_mail solo tienen acceso al dominio local (envío/recibo) y de manera similar los que pertenezcan al grupo National_mail solo pueden traficar correos desde y hacia servidores «.cu»

El resto de los usuarios que no está en ninguno de estos dos grupos tiene acceso total a traficar emails con el mundo entero. Los cambios son inmediatos, o sea desde el momento que añadas un usuario a e sos grupo este está limitado, lo contrario tambien es cierto

Al inicio comenté que esta es una característica opcional, si no la necesitas con no crear el OU y los grupos es suficiente.

Estos grupos pueden tener un email declarado para notificaciones, pero eso es para la siguiente función.

Alias para grupos usando el AD

Supongamos que tienes un departamento de contabilidad/finanzas donde reciben las facturas de ETECSA/CUBACELL y estados de cuentas del banco, etc.

No sería cool tener un grupo en el AD que reciba auto-mágicamente esos correos?

Pues es tan simple como crear un grupo en el AD debajo del BaseDN (para que MailAD pueda encontrarlo) le pones un correo en el campo “Correo Electrónico” del grupo y todas las personas que sean miembros de ese grupo y tengan correo configurado recibirán los correos que se envíen a esa dirección del grupo.

Por ejemplo:

MailAD Group Mail

Aquí todos los miembros del grupo “[email protected]” recibirán los correos enviados a esta dirección, en este caso los miembros son “Pepa Puig y Star Fire”

Aquí hay un catch: esta medida no es automática, está programada para aplicar los cambios una vez al día (daily, o sea aprox 6 am) porque generalmente los cambios en el grupo son son tantos una vez que los configuras.

Si estás apurado y lo necesitas para ya, puedes ejecutar esta línea en el server mail (siempre como root) y esto refrescará esta configuración:

Aquí hay un detalle, esta no es una lista de correos con todas las de la ley, es un alias automático, por lo que los correos nunca revelarán la dirección del alias y esto evita que se formen correos con el efecto “bola de nieve” como el “everyone” del Mdaemon por citar un ejemplo.

De la misma manera estos alias no tienen restricciones de acceso, o sea cualquiera puede enviar un email a esos alias de grupo.

Ya los veo pensando como hacer alias para personas con este truco, pero no, para eso hay otra manera, que involucra un poco al que lleva marketing, relaciones públicas y comunicación en la empresa

Alias personales o corrección de errores

Por ejemplo la ley exigía hasta hace poco (muchos siguen exigiéndolo todavía) que las cuentas de correo sean personales y no ligadas a cargos y eso está bien, el problema es cuando una persona importante sale de la empresa, un director o un económico, o un agente de ventas estelar…

Todos sus clientes tienen su correo personal y son oportunidades de negocios o informaciones que se pierden que al final vienen a nosotros los sysadmins a llorar para “ver si se puede recuperar los correos de pepe»…

Para esto yo recomiendo en mi consultoría a que se cambien las técnicas de marketing hacia un esquema de alias que facilite estas transiciones a futuro y te ahorras dolores de cabeza

Declarando por ejemplo en el server los siguientes alias y HACIENDO que las tarjetas de presentación de los directivos usen los aliases y en su trabajo que promuevan la dirección alias en vez de la personal

Yo se que esto lleva un poco de trabajo más allá de nuestro ámbito, pero vale la pena, ponerlo en los procedimientos para que recursos humanos nos notifique de los cambios en los cargos es una buena idea también.

Esto se configura en un fichero en el server de correo, el camino es “/etc/postfix /alias/alias_virtuales” al finalizar recuerda que debes hacer:

Para aplicar los cambios

Otro detalle, quien no ha tenido un usuario con un nombre raro o escrito de la manera con convencional y vemos a diario como llegan correos a la inexistente dirección que creen los usuarios que es la correcta…

Pues con este truco podemos arreglar eso, creando un alias con la dirección errónea más común apuntando a la dirección correcta.

Por ejemplo uno de mis clientes tiene una usuaria con nombre: velkis, si como lo leen. Se imaginan que llegan a diario emails para una inexistente belkys, pero con los alias podemos arreglar eso, una simple entrada como esta puede solucionar eso:

Ahora los correos “mal escritos” para belkys siempre llegarán a velkis, recuerde hacer postmap y recargar póstfix al modificar este fichero o los cambios no serán aplicados.

Lista negra

En nuesta actividad de sysadmins topamos con direcciones de correos o dominios que queremos banear o prohibir correos desde y hacia ellos (a veces la OSRI indica ciertos correos o dominios) para esto está pensado un fichero: «/etc/postfix/rules/lista_negra»

Vean los ejemplos en el fichero, es simple, poner la dirección o el dominio seguido de las palabras claves para denegar, en este caso tenemos dos opciones

  • REJECT: en este caso se rechaza directamente el correo
  • DROP: aceptarlo como válido pero mandarlo directo a /dev/null

Como administradores seguro que tienen a la mano algunos casos de uso para esta funcionalidad, como siempre recuerden aplicar los cambios:

Filtros de cabeceras y cuerpo

Para los mas avezados con expresiones regulares existen dos ficheros para macheo de cebaceras y cuerpo de los mensajes, estos son:

  • /etc/postfix/rules/header_checks
  • /etc/postfix/rules/body_checks

Cada uno tiene unos ejemplos básicos dentro, y como son filtros de expresiones regulares no necesitan hacerles postmap pero si que recarguen la config de postfix cada vez que son cambiados

Upgrades no dolorosos

Si más temprano que tarde MailAD sacará un fix o una nueva funcionalidad y no quieres perderla, entonces como upgradear la config?

Simple, pero primero una advertencia: Como todo Software Libre no ofrecemos más garantía que la expresada al decir que en nuestros entornos de prueba y producción funciona, por lo que si vas a hacer un upgrade: HAZ UNA SALVA de tu sistema antes de hacerlo

Hacer el upgade es tan simple como seguir estos pasos:

  • git pull
  • make upgrade

Así tan simple, ahora comentemos la salida que se muestra en este listado (esto es un upgrade real!)

  • Primero cambiamos a la carpeta de mailad /root/mailad/
  • Verificamos si hay upgrades con “git pull”, el listado muestra que si hay cambios y los descarga y aplica
  • Luego hacemos “make upgrade”, esto realiza varias tareas, veamos por partes:
    • Hacer un backup de TODA la configuración que anuncia se guardó en “ /var/backups/mailad/20200801_012900.tar.gz” (fecha y hora del backup)
    • Eliminar todos los softwares y sus configuraciones y volverlos a instalar desde CERO con nuestra configuración (esto garantiza que tengas un entorno limpio)
    • Restaurar los ficheros que puedes haber modificado a mano (alias_virtuales, header y body checks, lista_negra, etc)
    • Reinicia los servicios y te muestra el estado para que veas si ha fallado algo

Si algo va mal con el nuevo upgrade siempre puedes regresar a la configuración anterior desde el backup creado que radica en /var/backups/mailad/ puedes seguir las instrucciones de restaura ante un upgrade fallido en el sitio oficial

Conclusiones

Espero este tutorial les sirva para crear sus servidores de correos y a mi para mejorar MailAD, pues mientras más personas lo usen más detalles mejoraremos, los invito a participar en su creación ya que es software libre y está en Github: https://github.com/stdevPavelmc/mailad/

Para discutir podemos usar tanto los comentarios en este post como el canal de Telegram de la comunidad en esta dirección: https://t.me/sysadmincuba, no olviden mencionarme: @pavelmc

Saludos

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 8

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Please follow and like us:

3 comentarios

  1. Hola colegas, muy bueno el artículo aunque aún no lo he probado, pero algo así necesitaba para desplegar un ambiente de correo de poco consumo en comparación con Zimbra. Una ocsa que creo que no vi por ningún lado cuando estuve leyendo, no cuenta con webmail esta solución??

    • No, esto es solo el server de correo, puedes usar cualquiera de las opciones de webmail existentes, mis dos preferidas (por orden de preferencia)

      – Rainloop
      – Roudcube

      Pero eso amerita una guía aparte…

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*