Un envoi d’e-mail fiable distingue la demande du logiciel, l’acceptation par le fournisseur et la livraison réelle au destinataire.
Un message peut être accepté par un serveur puis rejeté plus tard. Le logiciel doit donc conserver un état et une prochaine action. Un envoi unique ne doit pas devenir plusieurs messages après une reprise technique.
Définir les états
Utilisez des états comme demandé, remis au fournisseur, livré, rejeté et annulé selon les informations disponibles. N’affirmez pas qu’un destinataire a lu le message si aucun signal ne le prouve. L’interface doit afficher une date et une raison lorsqu’elle est connue.
Gérer les reprises
Une erreur temporaire peut être retentée avec un délai. Une adresse invalide doit être isolée afin de ne pas retenter indéfiniment. Les clés d’opération doivent empêcher un double envoi lorsque l’utilisateur répète une action.
Le contenu du message doit correspondre à la version du dossier au moment de l’envoi. Une modification après l’envoi doit apparaître dans l’historique et ne pas réécrire le message déjà transmis.
Protéger les destinataires
Vérifiez que le rôle peut déclencher l’envoi et que l’adresse appartient au bon compte. Les pièces jointes doivent utiliser les règles du stockage sécurisé de fichiers. Évitez de placer une information confidentielle dans un sujet visible par d’autres personnes.
Surveiller
Mesurez les rejets, les délais, les doublons et les désabonnements. Une baisse de livraison peut venir d’une configuration, d’un domaine ou d’une liste dégradée. Le support doit disposer d’un identifiant d’envoi pour enquêter.
Sources : RFC 5321, SMTP, OWASP, abus d’e-mails.
Préparer le message
Le sujet doit permettre au destinataire d’identifier le dossier sans révéler une donnée sensible. Le corps doit indiquer l’action attendue et le lien vers l’espace autorisé. Un message envoyé après une modification doit afficher la date et l’état correspondant à l’événement.
Les modèles doivent être versionnés et testés dans les langues proposées. Vérifiez les caractères accentués, les liens, les pièces jointes et l’affichage sur mobile. Une traduction incomplète ou un lien expiré peut produire un ticket alors que l’opération métier est correcte.
Distinguer les retours
Un fournisseur peut signaler une adresse invalide, une boîte pleine, un délai ou un blocage temporaire. Mappez ces résultats vers des états lisibles. Une adresse qui a été rejetée plusieurs fois ne doit pas être retentée indéfiniment.
Un clic ou une ouverture ne prouve pas que le destinataire a compris le message. Utilisez ces signaux pour diagnostiquer une distribution, pas pour déclarer une tâche terminée. La gestion des tâches doit suivre une action confirmée dans le logiciel.
Gérer les reprises
Une clé d’opération relie l’envoi à l’événement qui l’a créé. Une reprise après timeout vérifie si le fournisseur a déjà accepté le message. Les messages en échec vont dans une file avec le nombre de tentatives, la dernière raison et l’action proposée au support.
Surveillez le délai entre la demande et la remise, les rejets par domaine et les doublons. Une hausse peut venir d’une rotation de secret, d’une configuration DNS ou d’un modèle mal formé. Les secrets doivent être remplacés selon une procédure contrôlée.
Respecter les préférences
Les notifications nécessaires à un workflow peuvent être distinguées des messages promotionnels ou informatifs. Affichez les préférences, la fréquence et le canal. Conservez les demandes de désabonnement et empêchez le logiciel de réactiver un type sans décision de l’utilisateur.