Un message peut afficher un échec temporaire avant une livraison ultérieure. Le greylisting est une cause possible. La limitation du débit et d'autres problèmes temporaires peuvent produire la même classe de statut.
Comment fonctionne le greylisting ?
Un destinataire diffère temporairement un client d'envoi inconnu et vérifie si une tentative ultérieure est reconnue comme un réessai.
La RFC 6647 décrit cette technique anti-abus. Un logiciel qui ne réessaye jamais ne peut pas achever la livraison par ce contrôle.
Le destinataire renvoie un échec temporaire SMTP, laissant au système d'envoi la responsabilité de conserver et de réessayer le message. Réussir le test de réessai supprime cet obstacle. Les autres règles de filtrage du destinataire s'appliquent toujours.
Comment le destinataire reconnaît-il un réessai ?
Le destinataire compare les informations de la nouvelle tentative avec un enregistrement de la précédente.
La RFC 6647 recommande de suivre l'IP d'envoi, l'expéditeur d'enveloppe et le premier destinataire. L'expéditeur d'enveloppe est l'adresse utilisée pour les notifications d'échec de livraison.
Un changement de ces identifiants peut faire ressembler un réessai à un nouveau message. Envoyer depuis plusieurs serveurs peut donc compliquer la correspondance, selon la politique du destinataire.
La RFC recommande d'autoriser le trafic ultérieur depuis l'IP après un réessai réussi. Elle recommande également de faire expirer les enregistrements inactifs, afin que l'autorisation ne dure pas indéfiniment.
Pourquoi le greylisting peut-il bloquer certains courriers indésirables ?
Il bloque les logiciels d'envoi qui font une seule tentative et abandonnent face à un échec temporaire.
La technique teste le comportement de réessai. Elle ne détermine pas si le contenu du message est sûr ou souhaité. Un logiciel abusif qui réessaye peut aussi la franchir.
Un destinataire a donc besoin d'autres signaux de filtrage. Franchir le greylisting avec succès ne prouve ni l'authentification, ni le consentement, ni une bonne réputation d'envoi.
Combien de temps le délai peut-il durer ?
Le délai dépend du moment où l'expéditeur réessaye et des tentatives que le destinataire accepte comme étant dans les temps.
La RFC 6647 recommande une fenêtre de réessai par défaut d'une minute à 24 heures pour s'adapter aux calendriers de réessai habituels. Il s'agit d'une plage côté destinataire pour reconnaître les réessais. Elle ne garantit pas la livraison dans ce délai.
Par exemple, un réessai après 30 secondes est trop précoce pour cette fenêtre par défaut. Un réessai après 30 heures peut être traité comme une nouvelle tentative. Un réessai admissible doit encore satisfaire les autres contrôles du destinataire.
Un expéditeur qui ne réessaye qu'au bout d'une heure ne peut pas livrer par ce contrôle plus tôt. Pour un code de vérification expirant après dix minutes, cette livraison arrive après que le code est devenu inutilisable.
Comment distinguer le greylisting d'un autre échec ?
Utilisez les détails de la réponse et l'historique des réessais. Un code de statut temporaire seul ne prouve pas le greylisting.
| Observation | Ce que cela établit |
|---|---|
4xx, puis livraison réussie | Un échec temporaire résolu. Le greylisting est une cause possible |
Réponses 4xx répétées jusqu'à expiration | La livraison n'a jamais abouti. Le texte de la réponse et le schéma de réessai peuvent aider à identifier la cause |
Réponse 5xx | Un échec permanent pour cette requête SMTP |
La RFC 6647 mentionne 421 lors de la fermeture de la connexion et 450 dans les autres cas. Elle ne prescrit pas la formulation des réponses, le texte n'a donc pas besoin de nommer explicitement le greylisting.
E-mail différé et bounces décrivent les issues temporaires et définitives.
Que doit investiguer l'opérateur d'envoi ?
Confirmez que le message est réessayé et que ses informations d'identification restent adaptées à la politique de correspondance du destinataire.
Vérifiez si les réessais changent l'expéditeur d'enveloppe ou basculent entre des IP d'envoi différentes. Vérifiez également si différents serveurs MX du destinataire reconnaissent le même historique de réessai.
La RFC 6647 recommande que les serveurs de réception partagent une base de données de greylisting, car un réessai peut atteindre une destination différente. Une discordance peut retarder de façon répétée le courrier légitime.
Fournissez à l'opérateur de réception les heures des tentatives, les IP et le texte des réponses lorsque le retard persiste. La RFC prévoit des exceptions gérées par le destinataire pour les expéditeurs légitimes qui fonctionnent mal avec le greylisting.
Un destinataire devrait-il appliquer le greylisting aux soumissions authentifiées ?
La RFC 6647 recommande que les opérateurs excluent du greylisting les clients authentifiés de leur propre service de soumission. Ces clients se sont déjà authentifiés pour soumettre du courrier, donc vérifier si un expéditeur inconnu réessaye ajoute un délai évitable. Appliquez la règle au niveau du service de réception ou de soumission qui la contrôle.
Pour une application utilisant une plateforme d'envoi, consultez le résultat de livraison du message. Créer un nouvel envoi applicatif ne corrige pas la correspondance de greylisting de la première tentative. Cela peut produire des doublons.
En bref
Le greylisting teste le comportement de réessai.
Un échec temporaire demande au serveur d'envoi de réessayer. Il ne constitue pas un rejet permanent.
Un réessai ne garantit pas l'acceptation.
La tentative doit satisfaire les contrôles de délai et d'identité du destinataire, ainsi que ses autres règles de messagerie.
Le délai dépend des deux serveurs.
La fenêtre de réessai du destinataire et le calendrier de l'expéditeur déterminent conjointement le délai.
Les reports répétés nécessitent une investigation.
Vérifiez les détails de la réponse, les réessais et les changements d'identifiants de l'expéditeur avant de conclure que la cause est le greylisting.