Email

Chinaski envoie des emails quand quelque chose arrive : réinitialisations de mot de passe, décisions de relecture, nouvelles soumissions de formulaires, publications planifiées, alertes de sécurité et issues de build. Chaque message part par un relais SMTP unique que vous configurez sous Settings → Email. Cette page explique la configuration, les règles de sécurité du transport, et tout ce qui envoie du courrier.

Configurer le relais

Sur l'onglet Email :

Champ	Défaut	À savoir
SMTP host	n/a	Le nom d'hôte de votre relais de messagerie (ex. `smtp.example.com`)
SMTP port	`587`	Ports courants : 587, 465, 25, 2525
Encryption	STARTTLS	Ou SSL/TLS, ou None (texte en clair) : préférez STARTTLS ou SSL
From address	n/a	L'adresse depuis laquelle vos messages partent (ex. `noreply@example.com`)
SMTP username	vide	Vide si le relais n'exige pas d'authentification
SMTP password	vide	Stocké chiffré ; les formulaires affichent « leave blank to keep current. » L'aide suggère un mot de passe d'application
Build notification email	vide	Les notes de succès/échec de build arrivent ici ; vide désactive ces notes

Deux boutons de test se trouvent directement sur l'onglet :

Send test email : tapez n'importe quelle adresse et le CMS envoie un message par le relais configuré exactement. En cas d'échec, la réponse indique quelle étape a échoué (connexion, TLS, authentification, acceptation de l'expéditeur, validation du destinataire, ou envoi) plus « check host, port, and credentials. »
Send test build notification : exerce spécifiquement l'adresse de notification de build, pour que les deux moitiés puissent être vérifiées indépendamment.

Sécurité du transport (intégrée)

STARTTLS met à niveau la connexion après s'y être connecté ; SSL/TLS se connecte chiffré d'emblée. Les deux vérifient les certificats (contre le nom d'hôte du relais) par défaut, si bien que les identifiants ne peuvent pas être capturés par un certificat forgé. None se connecte en texte en clair ; utile seulement pour des relais sur un réseau privé.
Si votre relais utilise un certificat auto-signé, CHINASKI_SMTP_INSECURE_NOVERIFY=1 dans l'env de l'instance est l'unique dérogation documentée à la vérification de certificat.
L'authentification n'est tentée que si nom d'utilisateur et mot de passe sont tous deux renseignés ; les relais sans auth s'accommodent très bien du vide.
Chaque notification est en texte simple UTF-8 ; les valeurs d'en-têtes sont assainies contre l'injection.

Mode air-gap

En mode air-gap aucun email n'est envoyé, jamais : le transport renvoie immédiatement sans aucune tentative réseau. Les emails de formulaires, les notifications et les résumés planifiés sont tous sautés, et l'onglet Integrations le dit. Rien à configurer pour que cela arrive ; c'est global.

Qui reçoit du courrier, et quand

Vous (admin du site), typiquement via l'adresse de notification de build ou l'adresse de notification de relecture :
- Un build a réussi ou échoué (si Build notification email est renseignée, envoyé par le builder après chaque build ; les échecs de remise ne dérangent jamais l'issue du build).
- Échecs de connexion répétés soutenus (première alerte par heure, vers la même adresse de notification de build).
- Du contenu a été auto-publié par le planificateur (résumé avec titres et langues par élément, adresse fixée sur l'onglet Integrations).
- Soumissions de relecture : « A page has been submitted for review by … » avec un lien d'édition direct (adresse fixée sous Settings → Workflow).
Les créateurs de contenu, quand ils ont un email enregistré :
- Approbation de page (ou rejet avec un motif) : les notifications de l'Approval Workflow.
Soumetteurs et destinataires (Forms) :
- Un email de confirmation au visiteur quand le formulaire a un champ reply-to configuré (sujet/nom d'expéditeur sont des réglages par formulaire ; le corps est un remerciement plus une copie de ses réponses), envoyé de manière asynchrone.
- L'email de notification vers vos destinataires : un par soumission, listant la valeur de chaque champ, l'IP soumise (sauf désactivation ou demande de confidentialité), et l'horodatage.
Les utilisateurs : liens de réinitialisation de mot de passe, et invitations/réinitialisations envoyées par l'admin avec leurs limites de temps documentées.

Les deux types d'échec

Échecs côté relais : l'envoi renvoie un flash ou une entrée de log nommant l'étape qui a échoué (connect, STARTTLS, AUTH, MAIL FROM, RCPT TO, ou DATA) plus le code du serveur. Le bouton de test SMTP est le diagnostic le plus rapide.
Non-configurations silencieuses : le plus souvent « le réglage existe mais l'envoi a été sauté » : mode air-gap actif, pas d'adresse From, champs notify/confirmation du formulaire vides, ou une réinitialisation/autre action dont le destinataire n'avait pas d'email valide. Chaque chemin traite délibérément une configuration manquante comme « pas d'envoi » plutôt que comme une erreur.
Les échecs de notification de build sont particuliers : ils sont journalisés (un événement build_notify_email_failed) mais ne transforment jamais un bon build en échec, ni l'inverse.

Conseils pratiques

Utilisez un mot de passe d'application plutôt que le mot de passe de votre compte personnel (l'aide du champ le dit) ; les identifiants du relais sont sensibles, même chiffrés.
Fixez l'adresse From avant tout flux d'envoi ; plusieurs chemins l'exigent même avec un relais fonctionnel.
Après avoir changé un champ quelconque, utilisez le bouton de test correspondant à ce que vous avez changé ; le flash vous donne une raison précise plutôt que « l'email n'est pas arrivé ».
Les notifications propres aux formulaires se configurent par formulaire (Forms → edit) : champ reply-to, ligne de sujet, adresses de notification, inclusion de l'IP, et l'URL de remerciement ; l'onglet Email est le relais, pas le comportement.
Si un message important n'est jamais arrivé, les entrées du journal d'audit (approbations) et les résultats de flash à l'action déclenchante vous disent si l'envoi a été tenté et ce que le relais a répondu.