6. Détection et traitement des problèmes (Problem Detection and Handling)
Cette section décrit comment les implémentations SMTP devraient gérer divers problèmes qui surviennent lors de l'envoi de courrier.
6.1. Livraison fiable et réponses par courrier électronique (Reliable Delivery and Replies by Email)
Notifications d'état de livraison (Delivery Status Notifications, DSN)
Lorsque le courrier ne peut pas être livré, le système d'envoi DEVRAIT (SHOULD) générer une notification d'état de livraison (message de rebond) pour informer l'expéditeur.
Exigences DSN :
- DOIT (MUST) être envoyée au chemin inverse (adresse MAIL FROM)
- DOIT (MUST) utiliser un chemin inverse nul (
MAIL FROM:<>) pour éviter les boucles - DEVRAIT (SHOULD) inclure le message d'origine ou les en-têtes
- DEVRAIT (SHOULD) spécifier la raison de l'échec
Délais et nouvelles tentatives
Calendrier de nouvelle tentative :
- Échec initial : Réessayer après 30 minutes
- Échecs suivants : Backoff exponentiel (1 heure, 2 heures, 4 heures, etc.)
- Période de nouvelle tentative maximale : Au moins 4-5 jours
- Échec final : Envoyer un rebond à l'expéditeur
Messages d'avertissement :
- Après 4-6 heures : Envoyer un avertissement de retard à l'expéditeur
- Inclure la raison du retard
- Informer l'expéditeur que les tentatives de livraison se poursuivent
6.2. Messages non désirés, non sollicités et "d'attaque" (Unwanted, Unsolicited, and "Attack" Messages)
Les serveurs SMTP DEVRAIENT (SHOULD) implémenter des protections contre les abus :
Anti-spam
Techniques :
- Validation des destinataires : Vérifier que les destinataires existent avant d'accepter le courrier
- Vérification de l'expéditeur : Vérifier SPF, DKIM, DMARC
- Limitation de débit : Limiter les messages par connexion/temps
- Greylisting : Rejeter temporairement les expéditeurs nouveaux
- Filtrage de contenu : Scanner le contenu du message pour les motifs de spam
- Systèmes de réputation : Suivre la réputation de l'expéditeur
Protection contre le déni de service (DoS)
Défenses :
- Limites de connexion : Limiter les connexions simultanées d'une seule IP
- Limitation de débit : Limiter les commandes par seconde
- Tarpit : Ralentir les expéditeurs suspects
- Limites de ressources : Plafonner l'utilisation du CPU et de la mémoire par connexion
- Application des délais : Déconnecter les connexions inactives
Attaques de collecte d'annuaire (Directory Harvest Attacks, DHA)
Les attaquants envoient des commandes RCPT TO avec des adresses devinées pour trouver des boîtes aux lettres valides.
Contre-mesures :
❌ Vulnérable :
C: RCPT TO:<[email protected]>
S: 550 No such user (révèle invalide)
C: RCPT TO:<[email protected]>
S: 250 Ok (révèle valide)
✅ Protégé :
- Retarder les réponses aux commandes RCPT
- Utiliser la même réponse pour valide et invalide (par exemple, toujours "250 Ok")
- Valider les destinataires uniquement pendant ou après DATA
- Limiter le débit des commandes RCPT
Prévention du backscatter
Backscatter : Rebonds envoyés à des adresses d'expéditeur usurpées, créant du spam collatéral.
Prévention :
- Rejeter au moment SMTP : Rejeter les destinataires invalides pendant la transaction SMTP (avant DATA)
- Vérification de l'expéditeur : Ne pas accepter le courrier d'expéditeurs usurpés
- Ne pas générer de rebonds : Pour le courrier d'origine inconnue/suspecte
6.3. Détection de boucle (Loop Detection)
Les boucles de courrier se produisent lorsqu'un message est transféré de manière répétée à travers les mêmes serveurs.
Méthodes de détection
Méthode 1 : Compter les en-têtes Received
Compter les en-têtes Received dans le message
Si count > 100 :
Rejeter avec "554 5.4.6 Too many hops"
Méthode 2 : Analyser les en-têtes Received
Analyser les en-têtes Received
Vérifier si le serveur actuel apparaît plusieurs fois
Si oui :
Détecter la boucle et rejeter
Méthode 3 : Suivi de Message-ID
Mémoriser les Message-IDs des messages récemment traités
Si le même Message-ID est vu à nouveau dans un court laps de temps :
Probablement une boucle, rejeter
Prévention de boucle
Meilleures pratiques :
- Limite de sauts : Rejeter après 50-100 en-têtes Received
- Détection de motifs : Identifier les noms de serveur répétés dans la trace
- Cassage de boucle : Ne pas transférer le courrier qui semble boucler
- Examen de la configuration : Éviter les règles de transfert qui créent des boucles
6.4. Compensation des irrégularités (Compensating for Irregularities)
Les implémentations SMTP du monde réel dévient parfois des normes. Les implémentations robustes DEVRAIENT (SHOULD) gérer gracieusement les irrégularités courantes.
Irrégularités courantes
1. Espaces supplémentaires
Certaines implémentations envoient des espaces supplémentaires :
❌ Non standard :
C: MAIL FROM: <[email protected]> (espaces supplémentaires)
✅ Gestion robuste :
Accepter et analyser correctement
2. Commandes à casse mixte
❌ Non standard :
C: Mail From:<[email protected]>
✅ Gestion robuste :
Traiter comme insensible à la casse
3. Crochets angulaires manquants
Certains anciens systèmes omettent <> autour des adresses :
❌ Non standard :
C: MAIL FROM:[email protected]
✅ Gestion robuste :
Accepter avec ou sans crochets
4. CR ou LF seul (pas CRLF)
La norme requiert CRLF (\r\n), mais certains envoient uniquement LF (\n) ou CR (\r) :
✅ Gestion robuste :
Accepter CR, LF ou CRLF comme terminateurs de ligne
(mais toujours envoyer CRLF)
5. Lignes longues
Certaines implémentations envoient des lignes dépassant les limites :
✅ Gestion robuste :
- Accepter les lignes de plus de 512 octets
- Diviser en interne si nécessaire
- Ne pas interrompre pendant la transaction SMTP
Principe de robustesse
"Soyez conservateur dans ce que vous envoyez, libéral dans ce que vous acceptez"
- Envoi : Respecter strictement les normes
- Réception : Accepter gracieusement les déviations mineures
- Journalisation : Enregistrer le comportement non standard
- Ne pas faire : Corriger silencieusement et transférer (perpétue les problèmes d'interopérabilité)