GitLab CI/CD
Contrôles d’e-mail dans le widget de test de votre merge request
Un composant du catalogue qui envoie un vrai e-mail à partir de votre modèle via votre relais. Chacun des 42 contrôles apparaît comme un cas de test, donc un échec DKIM est affiché par son nom.
42 vérifications · Aucune clé · Aucun compte
Inclure le composant
Le mot de passe du relais doit être stocké dans une variable CI/CD nommée EST_SMTP_PASSWORD. Masquez-la si possible.
include: - component: $CI_SERVER_FQDN/stanichev90/email-spam-tester/email-spam-tester@~latest inputs: smtp-host: smtp.example.com smtp-port: 587 smtp-username: billing@example.com from: "Acme Billing <billing@example.com>" subject: Your invoice html-file: templates/invoice.html min-score: 80L’alignement DMARC peut être rompu
sans le moindre rebond.
Où le trouver
Questions
Faut-il une clé ?
Aucune clé ni aucun compte.
Où les résultats apparaissent-ils ?
Dans le journal du job, le widget de test de la merge request et le rapport complet accessible via un lien.
Qu’est-ce qui fait échouer le job ?
Un échec de la vérification SPF, DKIM ou DMARC, ou un score inférieur à min-score.
Pourquoi utiliser un vrai e-mail ?
Les vérifications analysent ce que votre relais ajoute et ce que le destinataire reçoit. Une simulation ne contient ni l’un ni l’autre.