Infrastructure email
Statut
Document de cadrage DevOps — version initiale.
Objectif
L'email est nécessaire pour les notifications transactionnelles : invitations, confirmations, alertes, support et communications système.
L'infrastructure email doit être fiable, traçable et compatible avec la délivrabilité.
État actuel visible
Le fichier deployment/.env.production.example prévoit une configuration SMTP :
MAIL_MAILER=smtp;MAIL_HOST=smtp.postmarkapp.comcomme exemple ;MAIL_PORT=587;MAIL_ENCRYPTION=tls;MAIL_FROM_ADDRESS=noreply@dansmonvillage.fr.
Le module AssoSuite contient un mail d'invitation.
Supervisor définit une queue dédiée mail, ce qui indique une séparation des emails des jobs par défaut.
Usages email
| Usage | Criticité |
|---|---|
| Invitation AssoSuite | Haute |
| Authentification ou récupération compte | Haute si activé. |
| Notifications système | Moyenne à haute |
| Alertes mairie par email | À confirmer |
| Facturation ou paiement | Haute si email applicatif utilisé. |
| Support | Moyenne |
Provider
Le provider email final n'est pas confirmé.
Options possibles :
- Postmark ;
- Mailgun ;
- Amazon SES ;
- SMTP provider fiable ;
- solution locale uniquement pour développement.
Délivrabilité
À prévoir :
- SPF ;
- DKIM ;
- DMARC ;
- domaine d'envoi dédié ;
- suivi des bounces ;
- suivi des plaintes ;
- séparation transactionnel / marketing si besoin.
Principes
- Les emails critiques passent par queue.
- Les erreurs email doivent être monitorées.
- Ne pas envoyer de secrets en clair inutilement.
- Prévoir des templates sobres et accessibles.
- Limiter les volumes non sollicités.
- Respecter consentement et désabonnement selon type d'email.
Points à clarifier
- Provider retenu.
- Domaine d'envoi.
- Configuration SPF/DKIM/DMARC.
- Volumes attendus.
- Politique de logs email.
- Gestion des bounces.
- Emails mairie et notifications push/email.