Le serveur annonce les mécanismes d'authentification après que le client envoie EHLO. Le client en complète un avant d'envoyer un message.
Quand l'authentification SMTP a-t-elle lieu ?
Un client se connecte, démarre TLS si nécessaire, puis envoie EHLO. Le serveur liste les mécanismes d'authentification dans sa réponse. Le client envoie ensuite AUTH avec le mécanisme et les identifiants. Après un échange réussi, le client peut émettre MAIL FROM et poursuivre la transaction SMTP.
RFC 6409 sépare la soumission de messages du relais entre serveurs. Elle impose aux serveurs de soumission d'authentifier les clients sauf si une exception explicite s'applique. Ce comportement par défaut empêche toute soumission non autorisée. Utilisez une connexion chiffrée avant d'envoyer des identifiants.
| Mécanisme | Ce qu'il protège ou prouve |
|---|---|
| TLS | Protège la connexion en transit |
| SMTP AUTH | Identifie le client expéditeur auprès du relais |
| SPF, DKIM et DMARC | Autorisent ou vérifient le domaine expéditeur |
RFC 4954 définit l'extension AUTH ainsi que ses réponses de succès et d'échec. AUTH ne prouve pas qu'un destinataire acceptera le message.
Quels identifiants SMTP utilise-t-il ?
Un relais peut utiliser un nom d'utilisateur et un mot de passe, une clé API comme mot de passe, ou un autre mécanisme qu'il annonce. Traitez les deux éléments comme des secrets. Gardez-les hors du contrôle de version et des journaux, car quiconque lit un identifiant exposé peut soumettre du courrier en tant que votre compte.
L'authentification prouve que le client peut soumettre via ce relais. Elle ne prouve pas qu'un destinataire acceptera le message. Elle ne prouve pas le placement en boîte de réception. L'authentification de domaine telle que SPF, DKIM et DMARC concerne une autre étape de la distribution.
Pourquoi un envoi authentifié peut-il quand même échouer ?
Le relais peut rejeter les identifiants, les permissions de l'expéditeur, la politique de message ou la politique de destinataire à différentes étapes. Lisez le code de réponse SMTP et son texte, puis corrigez l'étape en échec avant de réessayer.
Un AUTH réussi ne fait que compléter la connexion. Une réponse RCPT TO ultérieure peut encore rejeter le destinataire. Un fournisseur de réception peut encore filtrer un message accepté.
C: EHLO app.example
S: 250-AUTH PLAIN LOGIN
C: STARTTLS
S: 220 Ready to start TLS
C: EHLO app.example
C: AUTH <credentials omitted>
S: 235 Authentication successful
Le serveur renvoie 535 lorsque l'authentification échoue. Ne placez jamais un vrai mot de passe ou un identifiant en base64 dans un journal ou un exemple. Quiconque le lit pourrait soumettre du courrier en tant que votre compte.
Comment s'authentifier avec Bird ?
Utilisez l'hôte SMTP correspondant à la région de votre clé. Choisissez le port 587 avec STARTTLS ou le port 465 avec TLS implicite. Authentifiez-vous avec le nom d'utilisateur bird et une clé API avec le scope emails comme mot de passe. Le guide du relais SMTP présente les paramètres de connexion et le traitement des réponses.
En bref
- L'authentification SMTP prouve qu'un client peut soumettre via un relais.
- Authentifiez-vous après l'activation du chiffrement.
- La réussite de la connexion ne garantit ni la distribution ni le placement en boîte de réception.
- Bird utilise
birdcomme nom d'utilisateur et la clé API comme mot de passe.
