Correo electrónico

Chinaski envía correos a las personas cuando algo sucede: restablecimientos de contraseña, decisiones de revisión, nuevos envíos de formularios, publicación programada, alertas de seguridad y resultados de builds. Cada mensaje sale por un único relay SMTP que configuras bajo Settings → Email. Esta página explica la configuración, las reglas de seguridad del transporte y todo lo que envía mail.

Configurar el relay

En la pestaña Email:

Campo	Por defecto	Qué saber
SMTP host	n/a	El hostname de tu mail relay (p. ej. `smtp.example.com`)
SMTP port	`587`	Puertos comunes: 587, 465, 25, 2525
Encryption	STARTTLS	O SSL/TLS, o None (texto plano): prefiere STARTTLS o SSL
From address	n/a	La dirección desde la que envían tus mensajes (p. ej. `noreply@example.com`)
SMTP username	en blanco	En blanco si el relay no requiere autenticación
SMTP password	en blanco	Almacenada cifrada; los formularios muestran "leave blank to keep current". El hint sugiere un app password
Build notification email	en blanco	Las notas de éxito/fallo de build van aquí; en blanco desactiva esas notas

Dos botones de prueba viven justo en la pestaña:

Send test email: escribe cualquier dirección y el CMS envía un mensaje a través del relay exactamente configurado. En caso de fallo, la respuesta te dice qué etapa falló (conexión, TLS, autenticación, aceptación del remitente, validación del destinatario o envío) más "check host, port, and credentials".
Send test build notification: ejercita específicamente la dirección de notificación de build, así ambas mitades se pueden verificar por separado.

Seguridad del transporte (integrada)

STARTTLS actualiza la conexión después de conectarse; SSL/TLS se conecta cifrado desde el inicio. Ambos verifican certificados (contra el hostname del relay) por defecto, así que las credenciales no pueden ser capturadas por un certificado falsificado. None se conecta en texto plano; útil solo para relays en una red privada.
Si tu relay usa un certificado auto-firmado, CHINASKI_SMTP_INSECURE_NOVERIFY=1 en el env de la instancia es el único opt-out documentado de la verificación de certificados.
La autenticación se intenta solo cuando tanto el username como el password están definidos; los relays sin auth van bien en blanco.
Cada notificación es texto plano UTF-8; los valores de headers se sanitizan contra inyección.

Modo air-gap

En modo air-gap no se envía ningún correo, nunca; el transporte regresa inmediatamente sin intento de red. Los correos de formularios, las notificaciones y los resúmenes programados se omiten todos, y la pestaña Integrations lo dice. No hay nada que configurar para que esto suceda; es global.

Quién recibe mail, y cuándo

Tú (site admin), típicamente vía la dirección de build-notification o la dirección de review-notification:
- Un build tuvo éxito o falló (si Build notification email está definida, enviada por el builder tras cada build; los fallos de entrega nunca perturban el resultado del build).
- Fallos de inicio de sesión repetidos y sostenidos (primera alerta por hora, a la misma dirección de build-notification).
- El scheduler auto-publicó contenido (resumen con títulos e idiomas por elemento, dirección definida en la pestaña Integrations).
- Envíos a revisión: "A page has been submitted for review by …" con un enlace directo de edición (dirección definida bajo Settings → Workflow).
Creadores de contenido, cuando tienen un email registrado:
- Aprobación de página (o rechazo con una razón): las notificaciones del Approval Workflow.
Remitentes y destinatarios (Forms):
- Un correo de confirmación al visitante cuando el formulario tiene un campo reply-to configurado (subject/From-name son configuraciones por formulario; el cuerpo es un agradecimiento más una copia de sus respuestas); enviado de forma asíncrona.
- El correo de notificación a tus destinatarios, uno por envío, listando el valor de cada campo, la IP de envío (a menos que esté deshabilitado o solicitado por privacidad) y el timestamp.
Users: enlaces de restablecimiento de contraseña, e invitaciones/restablecimientos enviados por el admin con sus límites de tiempo documentados.

Los dos tipos de fallo

Fallos del lado del relay: el envío regresa un mensaje flash o una entrada de log que nombra la etapa que falló (conexión, STARTTLS, AUTH, MAIL FROM, RCPT TO o DATA) más el código del servidor. El botón de prueba SMTP es el diagnóstico más rápido.
No-configuraciones silenciosas: lo más común es "la configuración existe pero el envío se saltó": modo air-gap activo, sin From address, los campos notify/confirmation del formulario en blanco, o un restablecimiento/otra acción cuyo destinatario no tenía un email válido. Cada camino trata deliberadamente una configuración faltante como "no enviar" en lugar de un error.
Los fallos de notificación de build son especiales: se registran en el log (un evento build_notify_email_failed) pero nunca convierten un build bueno en un fallo, ni viceversa.

Guía práctica

Usa un app password en lugar de la contraseña de tu cuenta personal (lo dice el hint del campo); las credenciales del relay son sensibles, incluso cifradas.
Define la From address antes de cualquier flujo que envíe: varios caminos la requieren incluso con un relay funcionando.
Tras cambiar cualquier campo, usa el botón de prueba que corresponde a lo que cambiaste; el flash te da una razón precisa en lugar de "el email no llegó".
Las notificaciones específicas de formularios se configuran por formulario (Forms → edit): campo reply-to, línea de subject, direcciones de notificación, inclusión de IP y la URL de agradecimiento; la pestaña Email es el relay, no el comportamiento.
Si un mensaje importante nunca llegó, las entradas del audit log (aprobaciones) y los resultados flash en la acción disparadora te dicen si el envío se intentó y qué dijo el relay.