A propos du classement des bounces

Envoyer de gros volumes d’emails peut être difficile. Bien gérer les bounces peut être encore plus difficile. Décoder, analyser et classer les différents formats de messags de bounce est une tâche complexe. Pour vous donner une idée de ce que vous pourriez rencontrer, voici quelques exemples de bounces:

421 4.7.1 Intrusion prevention active for [X.X.X.X] 451 qq read error (#4.3.0)

452 Message for would exceed mailbox quota

530 Authentication required

550 5.1.1 Not our Customer

550 Mailbox unavailable or access denied –

550 Administrative prohibition

550 Envelope blocked – User Entry

550 no such address here

550 5.7.1 e-mail address access denied

550 not valid

550 failedaddressrouter router forced verify failure

553 sorry, that domain isn’t in my list of allowed rcpthosts (#5.7.1)

554 5.7.1 UBE Not Welcome Here!

554 5.3.0 rewrite: map parse not found

Afin de traiter les bounces correctement, ils doivent d’abord être classés. Après cette classification, nous pouvons leur appliquer les règles de traitement. Une bonne règle fait en sorte que les adresses non valides soient immédiatement désactivées et exclues des envois ultérieurs. Les autres types de bounce doivent être supprimés dès qu’il est clair que le problème est permanent. Les bounces liés aux blocages antispam doivent être détectés et une action de l’expéditeur est souvent nécessaire afin de les résoudre.

Les deux catégories génériques «hard» et «soft», pour lesquelles beaucoup de définitions différentes existent, correspondent à un concept flou et constituent une grossière généralisation. Elles ne devraient pas être utilisées dans une logique d’entreprise. Tous les serveurs de messagerie fiables effectueront une nouvelle tentative face à une erreur commençant par le code ’4xx’ (indiquant une défaillance temporaire). Ainsi, lorsqu’un bounce est finalement détecté, il a fait l’objet de nombreuses tentatives, en réalité n’y a rien de «doux» à son sujet.

Si vous pensez que les code d’erreur SMTP à trois chiffres peuvent être utilisés pour la classification, vous êtes aussi dans l’erreur. Même les codes d’état améliorés décrits dans la RFC 3463 sont souvent ambigus ou mal utilisés. De plus, les classes d’état décrites dans ce document et dans d’autres RFC ne sont pas vraiment utiles du point de vue de la gestion des listes d’emails. Par exemple, une erreur de type 5.7.1 “relay access denied” n’est pas vraiment un problème de sécurité, mais est souvent causée par un domaine de messagerie invalide.

Alors, qu’est ce qu’une bonne classification? Après y avoir longuement réfléchi et analysé de nombreux bounces, je propose ce qui suit :

  • Relatif au destinataire
    • Adresse invalide
    • Adresse inactive
    • Boite pleine
  • Relatif au domaine
    • Domaine invalie
    • Absence d’un hôte pouvant recevoir les emails pour ce domaine
    • Relais/accès refusé
  • Lié à un blocage antispam
    • Expéditeur bloqué
    • Blocage lié au contenu
    • Blocage lié à une politique du serveur destinataire
  • Lié à un problème système
    • Problème système
    • Problème de protocole
    • Problème de connexion

Ces quatre catégories principales permettent de clarifier, la source des problèmes. En utilisant les sous-catégories, vous pouvez ensuite durcir ou bien assouplir vos règles de bounces. Par exemple, en modifiant le comportement des adresses inactives ou des boîtes pleines.

J’ai pu analyser et classer des centaines de milliers de bounces dans les catégories mentionnées ci-dessus. En utilisant, un système de recherche textuelle j’ai fini par obtenir une liste de près de 400 modèles différents. Je vous en dirais plus à ce sujet dans un prochain article.

Il est étonnant de voir comment certains FAIs remplacent un simple «utilisateur inconnu» par des réponses telles que «unrouteable address», «no such mail drop defined» ou «unsupported mail destination». Cela rend presque impossible la classification automatique des bounces sans mise à jour fréquente des règles de classement. Comment ces FAIs peuvent-ils attendre des expéditeurs qu’ils maintiennent correctement leur base de données dans ces conditions?

Plus d’informations ?
Si vous souhaitez en savoir plus sur la manière dont nous pouvons vous aider, envoyez-nous simplement un message via notre page de contact.

Les commentaires sont fermés.

Voulez-vous en savoir plus sur this blog article?



Postmastery respecte votre vie privée, nous ne vous contacterons jamais et ne partagerons pas vos données avec d’autres.