Commit Graph

2 Commits

Author SHA1 Message Date
sirxavor
6a10eab342 docs: por que la config es como es, y fuera el CI muerto
El README describia un flujo que no existe: ./build.sh con Kaniko y un workflow de
Gitea Actions. Kaniko y Gitea Actions se estan retirando, y ademas este workflow
llevaba roto desde mayo -- era el unico del arbol que usaba actions/checkout@v4,
que necesita node, y el runner :host no lo tiene. Fallaba en 70 s en cada push sin
que nadie lo mirara: la imagen que sostuvo el correo 70 dias era del 20 de mayo.
Un CI que falla siempre y en silencio es peor que no tener CI, asi que se borra en
vez de dejarlo de adorno.

Se documenta el build con mcp-build (con el gotcha del image_name sin host, que
duplica el registro y muere con 401) y, sobre todo, POR QUE cada linea de la config
es la que es. Las cuatro que no se pueden tocar sin reabrir el incidente llevan su
sintoma exacto al lado, para que el siguiente que las vea raras sepa lo que cuesta
"limpiarlas": tlsmgr, el grupo sasl, el realm desde RELAY_AUTH_DOMAIN y chroot=n.

Y queda escrito como se prueba un cambio de esta imagen ANTES de desplegarlo, que
aqui no es opcional: desplegar es reiniciar el unico pod que sostiene el correo, y
si falla no hay alerta que lo diga porque la alerta ES el correo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-29 23:12:05 +02:00
xavor
9e21e1e669 feat(smtp-relay): initial custom postfix+sasl relay image
Postfix relay image with Cyrus SASL (sasldb2) authentication.
Replaces mwader/postfix-relay with a controlled image built via Kaniko and
stored in Harbor. Credentials injected from Vault ExternalSecret at startup.
2026-05-20 20:25:04 +00:00