Un usuario decide rescatar un PC de 2012 —un Intel i7-3770 con 16 GB de RAM y dos SSD SATA— para montar un servidor de correo autohospedado con Mailcow. No lo hace por necesidad urgente, sino por curiosidad técnica y por una idea que cada vez gana más fuerza: si el hardware antiguo ya no vale casi nada en reventa, quizá todavía pueda ofrecer una segunda vida útil en servicios críticos… siempre que la instalación sea sólida.
La premisa del experimento es clara: correo entrante y saliente estable, sincronización con Outlook, iPhone y eM Client, y un entorno que permita actualizar el sistema y Docker sin romper la entrega de emails. El punto de inflexión llega tras más de 48 horas de frustración intentando desplegar Mailcow sobre Linux Mint, con síntomas clásicos de “infierno Docker”: correo saliente que se cae tras una actualización, comportamiento errático del puerto 25, y diagnósticos que parecían apuntar al ISP… hasta que el propio operador confirma que el problema era del servidor.
La solución final fue “borrón y cuenta nueva”: instalación mínima de Ubuntu Server 24.04 LTS, Docker oficial y una decisión práctica que suele marcar la diferencia en sistemas con contenedores: separar el sistema operativo de los datos y mover el data-root de Docker a un SSD dedicado.
El requisito que mata cualquier proyecto: puerto 25 saliente
El texto insiste en un punto que muchos descubren tarde: sin puerto 25 saliente, el correo autohospedado pierde el sentido (si se busca entrega directa sin retransmisión SMTP). En su caso, la receta pasa por:
- Tener IP(s) estática(s).
- Pedir al ISP el desbloqueo del 25.
- Solicitar y configurar rDNS (PTR) apuntando al FQDN del servidor (por ejemplo,
mail.tudominio.com).
Como ejemplo práctico, se incluye una plantilla de correo para AT&T (EE. UU.) solicitando desbloqueo del 25 + DNS inverso. La advertencia es directa: antes de invertir horas en contenedores y DNS, conviene comprobar conectividad con algo tan básico como:
telnet gmail-smtp-in.l.google.com 25
o, alternativamente,nc -vz ... 25
Si conecta, el camino está abierto. Si no, hay que resolverlo con el ISP o asumir un SMTP relay.
Hardware “de 2012” que todavía aguanta el tipo
La configuración usada es deliberadamente modesta (y realista para muchos “PC rescatados”):
- CPU: Intel i7-3770 (4c/8t)
- RAM: 16 GB DDR3-1600
- Disco SO: SSD SATA 120 GB (limpio)
- Disco Mail/Docker: SSD SATA 1 TB (para datos “para siempre”)
La recomendación también es práctica: SSD por fiabilidad y rendimiento, y copias de seguridad automatizadas para no convertir una avería tonta en una pérdida catastrófica.
Guía operativa (copiar y pegar): Ubuntu Server 24.04 + Docker oficial + Mailcow
Nota: donde aparezcan
youruser,yourdomain.com,UUID=...o/dev/sdb1, hay que adaptar al entorno real.
Fase 1 – Instalación mínima de Ubuntu Server 24.04 LTS
- Arrancar desde USB.
- Configurar IPv4 manual (IP estática, gateway, DNS).
- En almacenamiento, borrar solo el SSD pequeño del sistema operativo.
- Marcar “Instalar servidor OpenSSH”.
- Omitir snaps.
- Reiniciar.
La idea es reducir “ruido” y dependencias, y trabajar sobre una base estable.
Fase 2 – Montaje del SSD de 1 TB y restauración de claves SSH
sudo mkdir -p /mnt/mail
sudo mount /dev/sdb1 /mnt/mail # cambia si es sdc1 (comprueba lsblk)
sudo mkdir -p /home/youruser/.ssh
sudo cp /mnt/mail/ssh_key_backup/authorized_keys /home/youruser/.ssh/
sudo chown youruser:youruser /home/youruser/.ssh -R
sudo chmod 700 /home/youruser/.ssh && sudo chmod 600 /home/youruser/.ssh/authorized_keys
Lenguaje del código: PHP (php)Fase 3 – Montaje automático “para siempre” (fstab)
sudo blkid /dev/sdb1
sudo tee -a /etc/fstab <<EOF
UUID=your-uuid-here /mnt/mail ext4 defaults,noatime 0 2
EOF
sudo mount -a
Fase 4 – Instalación de Docker (repositorio oficial)
sudo apt update && sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USER && newgrp docker
Lenguaje del código: PHP (php)Fase 5 – Mover el data-root de Docker al SSD de 1 TB
sudo systemctl stop docker
sudo mkdir -p /mnt/mail/docker-data
sudo rsync -aP /var/lib/docker/ /mnt/mail/docker-data/
sudo mv /var/lib/docker /var/lib/docker.old
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/override.conf <<EOF
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --data-root=/mnt/mail/docker-data --containerd=/run/containerd/containerd.sock
EOF
sudo systemctl daemon-reload && sudo systemctl start docker
Lenguaje del código: JavaScript (javascript)Este paso es clave para que los contenedores y volúmenes no vivan en el disco del sistema y para facilitar migraciones o sustitución de hardware.
Fase 6 – Despliegue limpio de Mailcow
cd /mnt/mail
sudo git clone https://github.com/mailcow/mailcow-dockerized.git
cd mailcow-dockerized
sudo apt install -y jq
./generate_config.sh # → mail.yourdomain.com
docker compose pull
docker compose up -d
Lenguaje del código: PHP (php)Fase 7 – Abrir puertos (crítico)
Aunque Mailcow utiliza su propio contenedor de netfilter, se abre UFW “por si acaso”:
sudo apt install -y ufw
sudo ufw allow 25,465,587,80,443,993,4190
sudo ufw reload
sudo ufw enable
Fase 8 – Crear un administrador real (y dejar atrás el default)
Acceso inicial: https://tu-ip-publica (o el FQDN cuando DNS apunte bien).
Login por defecto: admin / moohoo → crear un usuario administrador propio con contraseña robusta y permisos globales, y cambiar credenciales cuanto antes.
Fase 9 – Mantenimiento sin dramas
# Actualización mensual de Mailcow
cd /mnt/mail/mailcow-dockerized && sudo ./update.sh
# Actualizaciones de seguridad automáticas
sudo dpkg-reconfigure --priority=low unattended-upgrades
Lenguaje del código: PHP (php)Kit mínimo de herramientas de diagnóstico
La guía lista los paquetes “extra” que acabaron siendo útiles:
sudo apt update && sudo apt install -y telnet netcat-openbsd jq rsync lshw dnsutils ufw
Con eso se cubren pruebas de conectividad, verificación DNS, copia de datos y detalles de hardware.
Lo que deja claro esta experiencia (y lo que muchos pasan por alto)
Más allá del “copiar y pegar”, el relato subraya varias realidades del correo autohospedado:
- La entrega saliente depende tanto de tu configuración como de políticas externas (ISP, rDNS, reputación, listas negras, etc.).
- El aislamiento (servidor dedicado para correo) reduce riesgos de “contagio” con otros servicios.
- Separar SO / datos facilita recuperación: si la placa muere, se mueven discos a otra máquina y se vuelve a levantar.
- Las actualizaciones deben hacerse con cabeza: el propio autor avisa de no precipitarse, porque así es como se rompe todo.
Si se busca un resumen del resultado: Mailcow actualizado a diciembre de 2025, datos fijados en el SSD de 1 TB, funcionamiento estable en un equipo de 13 años, y clientes habituales sincronizando sin incidencias.
Si quieres, puedo convertir este texto en un artículo “para publicar” (tono medio tecnológico, sin formato de guía paso a paso) o, al revés, en una guía aún más limpia con secciones de DNS (SPF/DKIM/DMARC), checklist de reputación y verificación final de deliverability.
vía: Reddit
