docs: registra el cierre del incidente SMTP (certificado + Spamhaus XBL)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

PRODUCCION.md

@@ -150,6 +150,42 @@
   confirmado distinto en ambos), verificado contra `https://project.linkedcorp.net` (bundle nuevo
   servido, `GET /api/projects` sin token responde 401 como se espera).
 
+## Cierre del incidente SMTP (2026-09-09) — certificado vencido + IP en Spamhaus XBL
+
+Con el host ya sin espacios (fix de v1.4.0), el boton de prueba seguia fallando con
+`certificate has expired`. Investigacion completa en el servidor de correo (`192.168.222.10`,
+iRedMail):
+
+- **Causa del certificado**: en `/etc/nginx/sites-available/00-default.conf` (puerto 80) el
+  `return 301 https://...` estaba directo en el bloque `server{}`, que en nginx se ejecuta en la
+  fase de *server rewrite* **antes** de evaluar `location` — por eso el reto ACME
+  `/.well-known/acme-challenge/` de certbot siempre terminaba redirigido a HTTPS, y ahi fallaba
+  contra NPM (sin certificado asignado para `mail.linkedcorp.net` en el 443, SNI rechazado). Fix:
+  mover el redirect dentro de `location / { return 301 ...; }` para que la ubicacion mas
+  especifica del challenge tenga prioridad. Certificado renovado con `certbot renew`
+  (valido hasta 2026-12-08); Postfix y Dovecot recargados (`systemctl reload`, sin cortar
+  conexiones). Backup del nginx original guardado junto al archivo en el servidor.
+- **Causa de que Hotmail/Outlook rechazara igual**: la IP publica compartida de toda la red
+  (`186.3.190.7`, NAT de `192.168.222.0/24` — no exclusiva del correo) estaba listada en el
+  **XBL de Spamhaus** por una deteccion real de malware (`urlzone`/Bebloh, conexion a un C2,
+  ultima deteccion 2026-09-03). No era fuerza bruta ni relay de spam del correo. Delisting
+  pedido y confirmado por Spamhaus el mismo dia (autoservicio, `check.spamhaus.org`); no se logro
+  rastrear el dispositivo infectado especifico (el `filter.log` de pfSense solo retenia horas de
+  historial — se amplio a ~25 dias por si se repite).
+- **Verificado end-to-end**: envio real via `testSmtpConfig` desde el propio backend de
+  produccion a Gmail y Hotmail, ambos confirmados recibidos (`{"sent":true}` + confirmacion
+  visual del usuario en Hotmail).
+- **Endurecimiento aplicado de paso** (servidor de correo): `fail2ban` con `maxretry` 5->3,
+  `bantime` 1h->24h con escalado a 7 dias para reincidentes, jail `recidive` nuevo. Cuentas
+  `admin@`/`postmaster@linkedcorp.net` identificadas bajo ataque de fuerza bruta activo con clave
+  sin rotar desde su creacion (dic. 2024) — **pendiente que el superadmin rote esas claves**, no
+  se toco por no ser parte del alcance de este proyecto.
+- Inventario completo de cuentas de correo del grupo (que app usa cada una, ultima actividad,
+  candidatas a borrar) documentado en `project-md-templates/CUENTAS_CORREO.md`. De paso se
+  encontraron y corrigieron dos apps de otros proyectos (`album-mundial-2026`, `linkedsign`) que
+  tenian `MAIL_TLS_REJECT_UNAUTHORIZED=false` como workaround del mismo certificado vencido —
+  revertido a `true` y servicios reiniciados una vez el certificado quedo renovado.
+
 ## Actualizacion v1.6.0 (2026-09-09) — administradores por proyecto, Configuracion solo superadmin
 
 - Un proyecto puede tener uno o mas administradores (`role_in_project='admin'` en