--- title: "Mails transactionnels" weight: 45 description: "Les courriers envoyés aux abonnés hors diffusion : confirmation, bienvenue, adieu, lien de connexion. Langue, personnalisation, forme HTML et texte." --- # Mails transactionnels À côté des messages qu'elle distribue, une instance difuzio envoie ses propres courriers aux abonnés : confirmer un abonnement, confirmer un désabonnement, souhaiter la bienvenue, accuser un départ, transmettre un lien de connexion à l'espace abonné. Ce sont les seuls courriers que difuzio rédige lui-même, et ce sont souvent les premiers qu'un abonné reçoit de vous. ## Les cinq courriers | Courrier | Déclencheur | Lien porté | Validité du lien | |---|---|---|---| | Confirmation d'abonnement | demande d'abonnement sur une liste en double opt-in, ou demande anonyme sur une liste ouverte | `/p/subscribe-confirm` | 72 heures | | Confirmation de désabonnement | demande de désabonnement par courrier | `/p/unsubscribe-confirm` | 72 heures | | Lien de connexion | demande d'accès à l'espace abonné | `/p/me/link` | 1 heure | | Bienvenue | abonnement devenu actif | `/p/me` | permanent | | Adieu | abonnement clos | formulaire d'abonnement de la liste | permanent | La durée de validité annoncée dans le courrier est lue sur le générateur de jetons, pas recopiée dans le texte : elle ne peut pas diverger de l'expiration réelle. ## Quand la bienvenue et l'adieu ne partent pas Ces deux courriers sont volontairement absents de certains chemins. Pas de mail de bienvenue sur un **import forcé** (import CSV, ajout par un gestionnaire avec `force`) : verser cinq mille adresses ne doit pas déclencher cinq mille courriers que personne n'a demandés. La bienvenue part quand la personne a elle-même demandé son abonnement : confirmation par courrier, inscription sur une liste ouverte, approbation par un modérateur de sa demande. Pas de mail d'adieu sur le **désabonnement en un clic** (RFC 8058). Ce bouton est couramment câblé sur l'action "signaler comme indésirable" du client de messagerie ; y répondre par un courrier de plus est le moyen le plus sûr de transformer un désabonnement propre en plainte. Pas de mail d'adieu non plus sur un effacement RGPD (on efface les données d'une personne, on ne lui écrit pas) ni sur une désactivation automatique pour rebonds (l'adresse ne fonctionne pas). L'adieu part en revanche quand un gestionnaire retire un abonné : c'est le cas où la personne n'a rien demandé et cesserait sinon de recevoir le courrier sans explication. ## Langue La langue est un réglage **du domaine** (`locale`, `fr` ou `en`, `fr` par défaut) : un domaine correspond à une organisation et à un public. Une même instance peut donc servir un domaine francophone et un domaine anglophone. À la création : difuzio domain add --name lists.example.org --base-url https://lists.example.org \ --display-name "Association Exemple" --locale fr Sur un domaine existant, par l'API : PATCH /api/v1/domains/lists.example.org {"locale": "en"} Une valeur inconnue est refusée en 422 plutôt que ramenée silencieusement au français : un abonné qui reçoit une confirmation dans la mauvaise langue est un défaut qu'aucun administrateur ne remonterait à une faute de frappe. ## Ce que vous pouvez personnaliser Deux réglages **par liste** insèrent vos propres mots dans les courriers de bienvenue et d'adieu : - `welcome_text` : paragraphes ajoutés au mail de bienvenue (charte de la liste, rythme de publication, contact de l'animateur) ; - `goodbye_text` : paragraphes ajoutés au mail d'adieu. Les lignes vides séparent les paragraphes. Le texte est inséré tel quel, échappé comme n'importe quelle donnée : ce sont des mots, pas du HTML. Un texte contenant des balises les affichera littéralement au lieu de les interpréter, ce qui est volontaire - ces courriers partent sous votre enveloppe et sous votre réputation. Le reste (mise en page, couleurs, structure) est embarqué dans le binaire et n'est pas surchargeable. Un gabarit cassé ne peut donc jamais rendre une confirmation d'abonnement indélivrable. Le nom affiché du domaine (`display_name`) et celui de la liste apparaissent dans l'en-tête, l'objet et le pied de chaque courrier : les renseigner suffit à ce que les courriers portent votre identité. À défaut, le nom technique est utilisé (`lists.example.org`, `annonces`). ## Forme des courriers Chaque courrier part en `multipart/alternative` : une partie texte brut et une partie HTML portant la même information dans le même ordre. - La partie texte n'est pas un pis-aller : elle contient le message complet et le lien en clair. Un courrier dont la partie texte se réduirait à "consultez ce message en HTML" est un motif que les filtres anti-spam pénalisent. - La partie HTML est construite pour des clients de messagerie et non pour un navigateur : tableaux imbriqués, styles en ligne, aucune image distante, aucune feuille de style externe, largeur 600 px et repli pleine largeur sur mobile. Elle suit le mode sombre du système quand le client le gère. - Le lien d'action est **toujours affiché en toutes lettres** sous le bouton. Un courrier de confirmation dont on ne peut pas lire la destination avant de cliquer ressemble à une tentative d'hameçonnage. - L'objet et le nom affiché sont encodés selon la RFC 2047, les corps en quoted-printable : un texte accentué arrive intact, y compris à travers un relais qui ne parle pas 8BITMIME. - `Date`, `Message-ID`, `Auto-Submitted: auto-generated`, `Precedence: bulk` et `X-Auto-Response-Suppress` sont posés par difuzio. Les deux derniers évitent qu'un répondeur d'absence réponde au robot. ## Vérifier le rendu avant une mise en service La suite de tests peut écrire un exemplaire de chaque courrier, dans les deux langues, pour les ouvrir dans un vrai client : DIFUZIO_MAIL_SAMPLES_DIR=/tmp/mails go test ./internal/mailtpl/ -run TestWriteSamples Le répertoire reçoit un fichier `.html` et un fichier `.txt` par courrier. ## Adresse d'expédition et signature Ces courriers partent de l'adresse du robot du domaine (`robot_name@domaine`, `difuzio@domaine` par défaut), avec le nom affiché du domaine. Le chemin de retour dépend du courrier : les confirmations et le lien de connexion utilisent un chemin VERP attribuable non comptabilisé dans la réputation, avec demande de notification d'échec, pour qu'une confirmation morte soit visible ; la bienvenue et l'adieu partent avec l'expéditeur nul et sans notification. difuzio ne signe pas ces courriers en DKIM lui-même : c'est le MTA frontal qui appose la signature du domaine de liste. Sans elle, ces courriers subissent le même sort que les messages de liste chez les grandes messageries. Voir [Délivrabilité](/difuzio/admin/delivrabilite).