Introduction

© 2003 Evan Harris, PureMagic.com [Version originale].
Traduction française B&A Consultants - © 2004.

Qu'est-ce que le Greylisting ?

Le Greylisting (listes grises de messagerie) est une nouvelle méthode afin de bloquer, au niveau de votre serveur de messagerie, une quantité significative de pourriels sans pour autant utiliser de méthodes statistiques ou heuristiques lourdes (et sujettes à des erreurs). Il découle de ces caractéristiques que les mises en oeuvre du Greylisting sont légères, et peuvent même diminuer le trafic réseau et la charge de calcul de vos serveurs.

Présentation

Ce document propose une nouvelle méthode, actuellement très efficace, afin d'améliorer les systèmes de messagerie dans le but de limiter le pourriel reçu et transmis aux utilisateurs. Nous appelons cette méthode le Greylisting (littéralement : listes grises). Les raisons d'une telle dénomination deviendront claires au fur et à mesure de votre lecture.

Dès le début, le Greylisting a été conçu afin de répondre à plusieurs critères précis :

• Un impact minimal sur les utilisateurs.
• Des possibilités réduites de contournement pour les spammeurs.
• Un effort de maintenance minimal tant pour les utilisateurs que pour les gestionnaires de la messagerie.

Le blocage du pourriel au niveau des utilisateurs, s'il est relativement efficace, présente toutefois des inconvénients qui le rendent peu souhaitable dans la lutte continue contre le pourriel :

• Les émetteurs légitimes, dont un message serait accidentellement considéré comme du pourriel, ne reçoivent aucune information appropriée.
• L'essentiel du coût de traitement du pourriel est du ressort du receveur plutôt que du spammeur.
• Il n'y a pas de pénalité particulière qui pourrait amener les spammeurs à cesser de gaspiller notre temps et nos ressources.

De ces réflexions découle l'idée que le Greylisting doit être mis en oeuvre au niveau du serveur de messagerie, afin de causer le plus de désagréments aux spammeurs.

Afin d'évaluer et de tester le Greylisting, nous avons écrit une version d'exemple d'un filtre fonctionnant au niveau du MTA (Message Transfert Agent, agent d'acheminement des messages). Le source de cet exemple est disponible. Nous ajouterons, au fur et à mesure de leur apparition, d'autres versions ou outils.

Le Greylisting a commencé par être testé sur quelques serveurs de petite ampleur (moins de 100 utilisateurs, qui dialoguent avec de nombreuses personnes, et un volume dépassant 10000 messages par jour). La solution est conçue pour pouvoir facilement grandir et n'avoir qu'un faible impact sur les administrateurs et les utilisateurs. Elle devrait être utilisable dans un grand nombre de situations. Bien évidemment, les performances sont très dépendantes des détails de mise en oeuvre.

Actuellement, le Greylisting est utilisé sur de nombreux serveurs de messagerie, dont certains traitent plusieurs millions de messages par jour. Chaque jour, de nouveaux systèmes l'adoptent.

La méthode de Greylisting proposée dans ce document est complémentaire d'autres méthodes existantes ou (en théorie) à venir, et ne vise pas à remplacer celles-ci. Nous supposons d'ailleurs que, à terme, les spammeurs tenteront de minimiser l'efficacité de cette technique de blocage. Nous avons donc essayé de limiter leurs possibilités pour ce faire.

Un avantage essentiel du Greylisting est que les seules méthodes pour le contourner tendent à rendre d'autres techniques de contrôle (essentiellement celles basées sur le DNS et les listes noires d'adresses IP) plus efficaces.

Rapide introduction aux listes grises

Le Greylisting (listes grises de messagerie) repose sur le principe que la majorité des sources de pourriels ne se comporte pas comme des serveurs de messagerie normaux. Bien que particulièrement efficace actuellement, cette méthode donnera son maximum en conjonction avec d'autres formes de prévention du pourriel. L'article détaillé donne plus d'informations sur cette méthode.

Le terme Greylisting sert à désigner une méthode générale de blocage du pourriel basée sur le comportement du serveur d'émission plus que sur le contenu du message. Le Greylisting ne fait pas référence à une mise en oeuvre particulière de la méthode. Il n'existe donc pas un unique système de Greylisting, mais de nombreux outils qui incorporent certaines ou toutes les techniques décrites ici.

Vendez-vous des outils ou services de lutte anti-spam ?

Non, notre version d'exemple se nomme relaydelay et est disponible librement sur la page de téléchargement. Mais nous acceptons volontiers les dons si vous pensez que les recherches et/ou les outils sont utiles, et si vous souhaitez aider à leur développement. Pour cela, consultez la page des remerciements.

Concernant B&A...

Nous ne vendons pas d'outils, mais nous intervenons sur différents thèmes relatifs à la sécurité informatique, et notamment pour aider à installer/configurer ce type d'outils de contrôle des pourriels. Pour nous contacter...

Questions et réponses

Puis-je activer le Greylisting sur mon serveur ?

Il existe des mises en oeuvre du Greylisting pour de nombreux serveurs de messagerie. Même si notre version d'exemple (pour Sendmail) ne convient pas à votre environnement, il en existe d'autres. Consultez la page des liens pour de plus amples informations sur ces autres versions.

Puis-je utiliser le Greylisting sur mon compte de messagerie personnel ?

Les méthodes de Greylisting sont conçues pour fonctionner au niveau du serveur de messagerie. Sauf si vous contrôlez votre propre serveur, ou si votre fournisseur d'accès a installé un tel outil sur ses systèmes, vous ne pourrez profiter du Greylisting.

Où puis-je trouver de l'aide pour la mise en place du Greylisting ?

Vous pouvez vous abonner aux listes de diffusion (voir la page idoine). Afin d'éviter de poser des questions déjà traitées, commencez par consulter les archives. Evidemment, vous pouvez aussi nous contacter pour la mise en place du Greylisting sur vos systèmes.

La méthode du Greylisting

Le nom de la méthode vient de ce qu'il s'agit d'un croisement entre les listes noires et les listes blanches, avec une gestion pratiquement automatique. Cette automatisation constitue l'un des éléments clés de la méthode.

La méthode est très simple. Pour chaque message, nous n'analysons que trois informations (désignées sous le terme de triplet dans le reste du document) :

• L'adresse IP du système envoyant le message
• L'émetteur indiqué dans l'enveloppe du message, et
• Le destinataire indiqué dans l'enveloppe du message.

Ces éléments forment un triplet unique caractérisant une "relation" par courrier électronique. Nous définissons alors une règle simple :

Règle de rejet	Si le système n'a pas encore validé un triplet particulier, il rejette, temporairement et pendant une durée limitée, le message et tout autre présentant le même triplet

SMTP étant considéré comme non fiable, l'éventualité d'un rejet temporaire est prévue dans le protocole (cf RFC 821). Tout agent d'acheminement doit donc ré-essayer d'envoyer un message lorsqu'il reçoit un code d'erreur temporaire (lire la discussion traitant des agents non-conformes).

Lors des premières phases de test du Greylisting, à la mi-2003, nous avons observé que l'écrasante majorité du pourriel semble provenir d'applications conçues spécialement pour cette tâche. Ces outils semblent utiliser la technique du "fire-and-forget", c'est-à-dire qu'ils tentent d'envoyer le pourriel vers l'un des MX d'un domaine, mais ne gèrent pas la réémission comme doit le faire un véritable agent d'acheminement. Cela signifie que, dans notre environnement de tests, reposant sur une interprétation assez conservatrice des données obtenues, nous avons atteint une efficacité voisine de 95%, sans qu'aucun message légitime ne soit jamais bloqué de manière permanente.

Qui plus est, avec la prolifération des virus basés sur le courrier électronique, le Greylisting s'est aussi révélé particulièrement efficace sur ce plan, puisque le moteur SMTP des virus ne gère pas souvent la ré-émission. Ces virus étant plutôt volumineux, les gains en bande passante et en traitement sont notables si on les compare aux méthodes classiques de contrôle et nettoyage après réception d'un message.

Le coût de ce filtrage, en termes de ressources locales, est minime. Si l'on utilise une base locale afin de stocker les triplets et quelques autres données supplémentaires, le Greylisting ne provoque aucun échange supplémentaire sur le réseau. Comme le contenu du message n'est pas analysé, contrairement à bien d'autres méthodes de filtrage du pourriel, la capacité de traitement n'est pas fondamentalement entamée.

Il y a une conséquence visible, qui peut être considérée comme positive ou négative selon les situations. Le Greylisting provoque un délai dans l'acceptation d'un message, ce qui occasionne une charge de travail supplémentaire pour l'agent émetteur. D'un autre côté, cela provoque beaucoup plus de travail du côté des systèmes d'émission de pourriel. Nous espérons que cela augmentera le coût des envois massifs de pourriel, peut-être même au point de le rendre non-rentable pour certains.

Le plus intéressant est que, puisqu'il n'y a jamais un rejet permanent de message, dès que l'agent d'émission respecte les RFCs, aucun message ne devrait se perdre. Il n'y a pas de faux positifs.

Spécifications de mise en oeuvre

Afin de mettre en oeuvre le Greylisting, nous utiliserons une forme de base de données qui contient des informations sur les relations par courrier électronique. Cette base est indexée par le triplet que nous avons déjà décrit :

• l'instant auquel le triplet a été vu pour la première fois (enregistrement),
• l'instant auquel le délai de blocage du triplet va expirer,
• l'instant auquel l'enregistrement lui-même va expirer (pour effacer les anciennes données),
• le nombre de tentatives d'acheminement qui ont été bloquées,
• le nombre de messages qui ont été acheminés.

D'autres informations sont stockées et manipulées par la version d'exemple, et nous les aborderons plus tard; pour le moment, nous pouvons les ignorer; le nombre de messages bloqués et acheminés n'est pas réellement nécessaire, mais il est utile pour améliorer l'ensemble du processus.

Avec ces éléments, nous disposons de tout ce qui est nécessaire pour mettre en place la méthode du Greylisting.

Les contrôles devraient être exécutés le plus tôt possible dans une session SMTP, dès que l'on a reçu les informations nécessaires. Pour les lecteurs qui ne sont pas familiers des détails de bas niveau d'une session SMTP, voici une séquence normale de commandes :

-> HELO undomaine.com
  <- 250="" hello="" undomaine="" com="" br="">  -> MAIL FROM: 
  <- 250="" 2="" 1="" 0="" sender="" ok="" br="">  -> RCPT TO: 
  <- 250="" 2="" 1="" 5="" recipient="" ok="" br="">  -> DATA
  <- 354="" enter="" mail="" br="">  ...
  <- 250="" 2="" 0="" message="" accepted="" for="" delivery="" br="">

pour minimiser le trafic réseau alors que le message peut être rejeté, les contrôles devraient être exécutés dès que l'agent émetteur a envoyé la commande RCPT.

En cas de rejet temporaire d'un message, la transaction doit ressembler à

-> HELO undomaine.com
  <- 250="" hello="" undomaine="" com="" br="">  -> MAIL FROM: 
  <- 250="" 2="" 1="" 0="" sender="" ok="" br="">  -> RCPT TO: 
  <- 451="" 4="" 7="" 1="" please="" try="" again="" later="" br="">

Nous ne l'avons pas encore signalé, mais le Greylisting permet de placer certains relais, domaines ou même émetteurs en liste blanche.

Cette possibilité n'est pas strictement nécessaire mais, pour plusieurs raisons, une version minimale devrait autoriser quelques adresses IP comme localhost (127.0.0.1) ou les MX principaux et secondaires des domaines gérés. Ces derniers étant supposés capables de réémettre les messages, et ne devant jamais être bloqués, il est inutile de retarder les messages qu'ils nous envoient.

De même, pour un FAI ou une situation similaire, il peut être nécessaire de placer certains destinataires (ou domaines) dans une liste blanche. Les clients peuvent demander que leurs domaines soient libérés du délai provoqué par le Greylisting.

Une liste blanche reposant sur l'adresse de l'émetteur (ou son domaine), si elle est facile à mettre en place, est déconseillée. Dans la plupart des cas, il est préférable de mettre en liste blanche l'adresse IP du système expéditeur, nettement plus difficile à simuler qu'une adresse électronique. Et, dans bien des situations, les domaines ou les émetteurs que l'on souhaite placer en liste blanche sont très faciles à deviner ou à découvrir, et les spammeurs s'en serviraient pour contourner le Greylisting.

Du point de vue du Greylisting, le stockage des listes blanches, qu'il se fasse dans la base de données ou ailleurs (éventuellement dans le code en lui-même), n'a aucun impact. Toutefois, une solution permettant la mise à jour rapide et sans risque des listes blanches est préférable.

La méthodologie de mise en oeuvre d'un Greylisting élémentaire est la suivante :

• Contrôler si le relais (ou le réseau) d'émission est en liste blanche. Si oui, transmettre le message.
• Contrôler si le destinataire du message (ou son domaine) est en liste blanche. Si oui, transmettre le message.
• Contrôler si nous avons déjà vu le même triplet auparavant.
  • S'il est inconnu, créer l'enregistrement associé et rejetter temporairement le message.
  • S'il est connu, et que le délai de blocage n'est pas révolu, rejetter temporairement le message.
  • S'il est connu, et que le délai de blocage est révolu, accepter le message.
• Si le message est transmis et que l'acheminement se passe bien,
  • Mettre à jour le nombre de messages bien transmis dans l'enregistrement associé au triplet,
  • Recalculer la date d'expiration de l'enregistrement.
• Si l'acheminement est rejeté temporairement,
  • Mettre à jour le nombre de messages rejetés dans l'enregistrement,
  • Si l'on est dans le cas particulier d'un émetteur nul (), ne pas renvoyer d'échec après la commande RCPT mais attendre après la phase DATA.

Pour tous ces contrôles, les enregistrements dont la durée de vie est dépassée sont ignorés.

Problèmes

Quelques problèmes que nous avons rencontrés sont suffisamment notables pour qu'il soit nécessaire de modifier l'approche simple présentée ci-dessus.

L'un des problèmes vient de que certains agents (par exemple Exim) tentent de limiter les fausses adresses d'émission par un contrôle de la validité de l'adresse. Ce contrôle se fait par le biais d'un rappel (au sens SMTP) vers l'adresse d'émission. Notre objectif étant de minimiser le trafic, la meilleure option est de déclencher les rejets dès la commande RCPT. Cependant, un tel rejet exécuté pour un rappel SMTP provoquerait des délais inutiles dans l'acheminement du message initial.

Cela dit, la majorité des systèmes qui mettent en place cette vérification de l'adresse de l'émetteur utilisent, dans leur message de rappel, l'émetteur nul . La solution est simple, puisque nous pouvons modifier le traitement, dans le cas d'un tel émetteur nul, pour ne renvoyer de rejet temporaire qu'après la phase DATA. Or, lors d'un rappel SMTP, l'agent émetteur du rappel met un terme à la transaction SMTP avant d'arriver à cette phase DATA. Du point du vue de l'agent qui procède au rappel, ce dernier s'est bien déroulé. De notre point de vue, notre message sortant peut être accepté sans délais inutiles.

Postfix est un autre agent présentant des difficultés semblables. Ce dernier s'éloigne des procédures habituelles d'utilisation de l'émetteur nul pour les rappels SMTP, et utilise à la place une adresse modifiable. J'ai cherché une explication à ce comportement, et ai appris que cela vient de certains agents non-conformes qui rejettent l'émetteur nul quand bien même il est requis par les RFC traitant de SMTP.

Malheureusement, cela pose un problème d'adaptation à ce comportement de Postfix. Par chance, la valeur par défaut de l'émetteur utilisé dans ce cas semble être postmaster, ce qui permet de définir une solution adéquate.

Un autre problème apparaît avec les sites disposant de plusieurs serveurs d'émission, lorsqu'ils envoient un message vers un serveur utilisant le Greylisting. Si le groupe de serveurs est configuré afin que le même système (même adresse IP) fasse les réémissions lors du rejet temporaire d'un message, il n'y a aucune difficulté.

Mais si les serveurs sont configurés de telle manière que l'un quelconque d'entre eux peut réémettre un message qui a été rejeté temporairement, alors les acheminements de messages à destination d'un système utilisant le Greylisting peuvent souffrir de délais particulièrement élevés. Le délai maximal dépend du nombre de serveurs dans le groupe d'émission, et de la gestion des tentatives de réémission. Dans le pire scénario, le délai peut être tel que l'émission du message sera abandonnée.

La première solution à ce problème est de placer ces serveurs en liste blanche. Une autre solution est de contrôler le sous-réseau de l'adresse IP de l'émetteur plutôt que l'adresse IP exacte. La majorité des sites concernés ayant tous leurs serveurs sur le même sous-réseau (/24), cette méthode est relativement efficace et automatique. Malheureusement, elle facilite un peu la vie des spammeurs.

Un autre problème potentiel vient des listes de diffusion se servant d'adresses d'émission uniques pour les messages envoyés à un certain utilisateur. Cela permet de mieux gérer les erreurs et les rejets (dont le format n'est pas normalisé, rendant la détermination de l'adresse en erreur particulièrement difficile).

Cette gestion des rejets et erreurs est appelée VERP, pour Variable Envelope Return Paths (adresses de retour variables). La majorité des listes de diffusion met le VERP en oeuvre d'une manière proche de celle décrite dans ce document, et utilise la même adresse d'émission pour tous les messages envoyés à un utilisateur particulier.

Certains gestionnaires de listes (comme Ezmlm) tentent d'aller plus loin et de garder unitairement trace des messages rejetés, plutôt que de manière globale pour un même destinataire. Il s'agit d'une variante de la méthode VERP, chaque message émis par la liste ayant une adresse d'émission unique. Chaque message émis par ces outils sera retardé, puisque le système récepteur ne trouvera jamais un triplet portant la même adresse d'émetteur, par nature unique.

S'il peut sembler a priori intéressant de garder une trace des rejets individuels de messages, cette idée ne paraît pas très pertinente aujourd'hui, où l'on essaye d'authentifier les émetteurs. Nous espérons que les mainteneurs d'Ezmlm corrigeront ce point.

Il existe une solution manuelle, qui est de placer en liste blanche tous les systèmes qui génèrent ce type de trafic. Toutefois, même sans une telle configuration, l'impact reste faible. Les listes de diffusion sont rarement utilisées pour des messages urgents, et le délai reste acceptable par la majorité des utilisateurs. 

Principaux paramètres de configuration

Dans l'idée de donner autant de souplesse que possible au gestionnaire de la messagerie qui déciderait d'utiliser le Greylisting, plusieurs options doivent être facilement modifiables pour adapter, au cas par cas, le comportement du système. Nous détaillons ci-dessous ces options, ainsi que certains détails à garder à l'esprit s'il est jugé nécessaire de changer les valeurs par défaut.

Il peut être intéressant que chaque site modifie ces paramètres, ce qui obligera les spammeurs à s'adapter sans cesse.

• Délai d'attente d'un triplet inconnu : une heure.
• Durée de vie d'un triplet n'ayant pas encore validé un message : quatre heures.
• Durée de vie d'un triplet ayant autorisé le passage d'un message : 36 jours.

Le délai initial d'attente d'une heure a été choisi pour les raisons suivantes :

• Il est suffisamment court pour que, dans la plupart des cas, les utilisateurs ne se rendent même pas compte du délai.
• Il est suffisamment long pour que les administrateurs d'un serveur de messagerie compromis ou détourné puissent détecter et, peut-être, corriger le problème avant que les pourriels ne soient réémis.
• Il est assez long pour avoir une bonne chance que l'adresse IP de l'émetteur, s'il s'agit bien d'un spammeur, soit insérée dans une liste noire d'adresses IP utilisée conjointement avec le Greylisting. Même si le spammeur tente une réémission ultérieure, qui sera acceptée par le Greylisting, la liste noire le bloquera.
• Il est aussi suffisamment long pour que d'autres types d'analyses de trafic puissent être envisagées et mises en oeuvre afin d'identifier et bloquer les adresses IP des spammeurs, sans que les premiers destinataires du pourriel (avant que l'analyse de trafic ne sache identifier ces messages comme tels) n'aient à recevoir le message.

Les données collectées durant les tests montrent que plus de 99% des messages bloqués par le délai d'une heure auraient aussi été bloqués par un délai d'une minute. Cependant, nous pensons que les spammeurs vont progressivement prendre cette méthode de blocage en compte et modifier leurs outils afin de réémettre les messages rejetés temporairement. Un délai initial assez long sera alors très utile, car il donnera le temps à d'autres systèmes de se déclencher. C'est pour cette raison que nous conseillons de conserver le délai initial d'une heure, puisque les spammeurs s'adapteront dès que cette méthode sera utilisée fréquemment.

Il est nécessaire de maintenir ce délai en-dessous d'un seuil à partir duquel un nombre important d'agents d'acheminement abandonnent l'émission et rejettent le message. Ce seuil est généralement de plusieurs jours. Toutefois, dans des cas particuliers, il peut avoir été abaissé à quelques heures tout au plus. Même dans ces cas, le délai de rejet temporaire du Greylisting devrait être d'une heure ou plus.

Il semble probable qu'à terme, une analyse de trafic utilisant les données issues du Greylisting émergera, afin d'identifier de manière automatique les adresses IP des systèmes qui tentent d'expédier du pourriel.

Bien que ce type de fonctionnalité ne soit pas inclus dans ma version d'exemple, je suis très intéressé par son avènement, les schémas de fonctionnement des spammeurs étant souvent faciles à identifier après quelques minutes d'activité. Il s'agit souvent de très nombreuses tentatives d'acheminement, provenant d'une même adresse IP ou groupe d'adresses IP à partir desquelles (presque) aucun trafic de ce type n'avait été observé, vers une grande quantité de destinataires différents.

Il est regrettable que ces analyses, pour être utiles et précises, nécessitent un volume élevé de trafic. Les petits systèmes n'apporteront pas beaucoup d'aide, sauf si l'analyse est distribuée, ce qui s'avère difficile lorsqu'on ne peut pas systématiquement faire confiance aux collaborateurs potentiels.

La durée de vie initiale de quatre heures a été choisie pour les raisons suivantes :

• Pratiquement tous les serveurs de messagerie légitimes ont un délai de réémission inférieur à 4 heures.
• Une faible durée de vie permet de limiter le nombre d'enregistrements à gérer pour des sites très actifs, qui peuvent recevoir des volumes élevés de messages et des centaines de milliers de requêtes par seconde. Une courte durée de vie est importante lorsque le volume de pourriel s'accroit, puisque chaque pourriel reçu provoque la création d'un nouvel enregistrement.
• La courte durée de vie permet aussi de limiter la fenêtre temporelle durant laquelle un spammeur peut décider de réémettre le message à toute sa liste.

Nous soulignerons que, dans la version d'exemple, ce délai de quatre heures recouvre le délai initial d'une heure, ce qui signifie que la fenêtre durant laquelle le message sera accepté est de trois heures.

La durée de la fenêtre d'acceptation devrait être aussi brève que possible pour une seconde raison. Si un spammeur découvre et exploite un relais mal géré ou mal configuré, les performances de ce relais vont peut-être s'écrouler. Ce ralentissement augmente la probabilité que le serveur ne pourra pas traiter l'ensemble de la file d'attente durant la fenêtre d'acceptation.

La durée de vie des enregistrements en liste blanche est mise à jour à chaque message accepté. Nous avons choisi une durée de 36 jours pour les raisons suivantes :

• Cela permet de minimiser la taille de la base de données, en provoquant l'élimination des triplets obsolètes (sur le plan de l'émetteur, du relais ou du destinataire).
• Toutefois, la durée est suffisamment longue pour que des messages émis sur une base mensuelle (par exemple les notifications de certaines listes de diffusion) puissent être transmis sans délais.
• Dans la même idée, les messages mensuels émis un certain jour de la semaine peuvent être acheminés sans délais (ainsi, le premier lundi des mois de juin et juillet 2003 sont distants de 35 jours). 

Analyse de l'efficacité

Sur la base de notre environnement de tests avec la version d'exemple, et sur une période de six semaines, nous avons obtenu :

• Nombre de triplets uniques vus : 346968
• Nombre de triplets ayant occasionné la transmission d'un message : 8950
• Efficacité (sur la base des triplets) : 97.4%

Nous obtenons donc une efficacité supérieure à 97% en supposant que tous les messages sont du pourriel. Nous ne pouvons cependant pas calculer l'efficacité exacte et réelle sans inspecter chacun des messages, ce que nous n'avons évidemment pas fait.

A l'inverse, examinons l'inefficacité du système :

• Nombre de messages transmis : 85745
• Nombre total d'acheminements rejetés temporairement suivi d'un acheminement accepté : 33586
• Pourcentage de messages retardés : 39.2%

Il est clair que ce résultat n'est pas enthousiasmant. Corrigeons-le un peu. Pratiquement tous les messages retardés provenaient de listes de diffusion utilisant un identifiant unique pour l'émetteur du message (voir la discussion sur VERP). Si nous omettons tous les triplets qui n'ont provoqué l'acheminement que d'un seul message, nous excluons ce type de trafic, et les valeurs deviennent :

• Nombre de messages transmis : 85745
• Nombre total d'acheminements rejetés temporairement suivis d'une acceptation lors de la réémission : 3512
• Pourcentage de messages retardés : 4.1%

Ce résultat est beaucoup plus intéressant, et revient à ignorer les délais imposés à des messages dont l'acheminement n'est, à la base, pas critique.

Examinons ensuite l'effet que le Greylisting a sur la bande passante du réseau, en prenant les valeurs moyennes suivantes :

• Taille moyenne d'un pourriel : 5000 octets.
• Surcoût moyen associé au protocole SMTP : 500 octets.

Ces valeurs proviennent d'une analyse des pourriels collectés par différents biais avant notre période de tests. Nous avons arrondi les valeurs tout en restant proches de la réalité. Le surcoût associé à SMTP est généralement inférieur à 500 octets mais nous avons décidé de rester conservateurs.

A partir de ces éléments, il apparaît que, pour chaque pourriel bloqué, nous économisons suffisamment de bande passante pour "payer" dix rejets temporaires. Si nous faisons la somme de tout cela, afin d'obtenir des valeurs représentatives, nous obtenons :

• 338018 pourriels de 5000 octets = 1,69 Go de bande passante économisée.
• 33586 messages retardés, pour 500 octets de protocole = 16,7 Mo de bande passante consommée

Il ressort un gain net supérieur à 1,67 Go de bande passante économisée grâce au Greylisting, sachant que le test concernait un site "plutôt petit".

Suggestions pour une protection plus efficace

Le Greylisting ne devient réellement efficace que si tous les MX d'un certain domaine l'utilisent.

Un nombre non négligeable d'outils d'envoi de pourriel sont déjà suffisamment évolués pour utiliser les MX secondaires d'un domaine lorsque l'envoi au primaire a échoué. Cela part de la supposition que tous les MX d'un même domaine sont en liste blanche les uns pour les autres (quel est l'intérêt de rejeter même temporairement des messages venant d'un système pour lequel vous êtes certain qu'il réémettra le message ?). Si les spammeurs peuvent envoyer sans rejet temporaire des messages vers l'un de vos MX secondaires, vous n'êtes pas plus protégé que sans le Greylisting.

Le Greylisting a un impact négatif relativement faible, qui peut être rendu encore moins intrusif si tous les MX d'un domaine utilisent la même base de données afin de garder trace des tentatives d'acheminement. Afin d'illustrer ce point, prenons l'exemple de plusieurs systèmes identifiés comme MX d'un domaine, et qui utilisent des bases de données disjointes.

Un relais autorisé, dont le délai d'attente entre deux tentatives est d'une heure, essaye d'envoyer un message à l'un des MX du domaine. Ce dernier n'a encore jamais reçu le triplet associé. Il crée donc un enregistrement dans sa base de données, et rejette temporairement le message. Une heure s'écoule, et le serveur initial ayant constaté que son message a été rejeté par un MX précis, tente un acheminement vers un autre MX du domaine. Ce second MX ne connaît pas le triplet associé au message et ne sait rien de la précédente tentative puisque les bases de données sont disjointes. Il rejette donc temporairement le message et ajoute un nouvel enregistrement dans sa base de données locale.

L'exemple précédent montre bien que les délais d'acheminement d'un message légitime peuvent être fortement accrus en cas d'utilisation de plusieurs MX. Le délai peut augmenter de telle manière que le serveur initial abandonnera l'acheminement et renverra une erreur à l'émetteur.

Afin d'éviter cette situation pathologique, il est vivement suggéré d'utiliser une base de données commune contenant les triplets identifiants les messages, dès lors que plusieurs MX sont définis pour un même domaine. Dans certaines situations, les MX sont trop distants (au sens réseau) les uns des autres pour qu'une telle base commune puisse être mise en place mais, même dans pareil cas, le Greylisting se révèle suffisamment efficace pour que le scénario précédent puisse être toléré ou que son impact puisse être diminué.

Attaques courantes des spammeurs

Cette partie détaille quelques-unes des techniques les plus utilisées par les spammeurs, d'après nos observations pendant la période de tests du Greylisting. Nous y présentons aussi comment notre méthode y fait face.

• passage par un MX secondaire
• attaque par dictionnaire
• distribution massive et répartie
• relayage par un serveur Web

Méthode 1 : passage par un MX secondaire

Un nombre non négligeable de pourriels visent spécifiquement les MX secondaires des domaines destinataires. La raison en est simple : souvent, ces serveurs de secours acceptent tous les messages et les ré-envoient vers le serveur primaire sans les contrôler. Cette technique diminue les contraintes sur les systèmes du spammeur, ne nécessite pratiquement pas de travail de gestion de messages rejetés, et autorise des transactions nettement plus rapides, le système destinataire (MX secondaire) étant généralement peu chargé.

Le Greylisting contre très bien cette attaque, dont le seul objectif est de minimiser les rejets et les délais.

Méthode 2 : attaque par dictionnaire ou rouleau compresseur

De nombreux spammeurs utilisent aujourd'hui une technique de "rouleau compresseur", c'est-à-dire qu'ils envoient des messages à des noms usuels sur un certain domaine (pierre@, jean@, webmaster@; on parle aussi d'attaque par dictionnaire), ou à des adresses calculées à partir de noms collectés sur diverses sources. Il semblerait qu'ils utilisent plus souvent un dictionnaire de noms et prénoms communs, mais la technique des adresses "générées" peut prendre plus d'importance dans l'avenir.

Les spammeurs utilisent probablement cette méthode afin de joindre des personnes qui ont

• soit pris les mesures nécessaires pour éviter que leur adresse électronique ne puisse être collectée sur la toile,
• soit sont plutôt des novices et n'ont pas les ressources ou l'envie de créer leurs propres pages Web.

Le second cas semble le plus probable, les utilisateurs novices étant plus enclins à acheter un produit dont la publicité se fait via le pourriel.

Ce style d'attaque est très souvent combiné à l'utilisation des MX secondaires, puisque la majorité des messages émis provoqueront un rejet, surtout si le domaine ciblé ne comporte que peu d'utilisateurs. En conséquence, les spammeurs utilisent les MX secondaires, qui gèreront les rejets et les erreurs à leur place.

Le Greylisting contre bien cette attaque, puisque ces messages proviennent souvent d'adresses IP dynamiques. La majorité des messages devant, statistiquement, être refusée, il serait trop onéreux pour les spammeurs de gérer eux-même les rejets. De plus, cette attaque étant facile à détecter (une grande quantité de rejets provenant d'une adresse IP ou d'un groupe identifié d'adresses IP), le Greylisting donne le temps nécessaire pour ajouter des adresses dans d'autres listes noires.

Méthode 3 : distribution massive et répartie

Beaucoup d'attaques de spammeurs semblent utiliser les mêmes schémas que les dénis de services distribués (DDoS, distributed denial of service). Sur les systèmes sur lesquels nous avons évalué les méthodes des spammeurs, nous avons observé qu'il était assez courant de recevoir, dans un intervalle réduit, des pourriels provenant de nombreuses adresses IP différentes et sans lien entre elles. Et pourtant, toutes les adresses d'émission de ces messages étaient identiques ou très proches, et les destinataires étaient relativement ordonnés.

Le Greylisting, tel que nous l'avons défini ici, gère très bien ces attaques. Toutefois, lorsque les spammeurs s'y seront adaptés et réémettront leurs messages, l'efficacité devrait diminuer.

Cela dit, il reste possible d'adapter notre technique afin de limiter les possibilités de contournement. Par exemple, il devrait être possible, sans que cela ne nécessite trop de puissance de calcul, d'examiner les demandes d'acheminement reçues récemment et, si l'on détecte ce type de rafales, de mettre d'autres listes noires à jour.

Méthode 4 : attaque par relais sur un serveur Web

Une part signficative des pourriels semble provenir de relais de type CacheFlow ou autres. Il est souvent facile de les identifier car ils renvoient l'identifiant CacheFlowServer à une requête ident.

Le Greylisting bloque totalement ces attaque, puisqu'il ne s'agit pas de véritables agents d'acheminement, et ils ne tenteront jamais une seconde émission des messages.

Adaptations et contournements possibles de la part des spammeurs

Tel que nous l'avons défini, le Greylisting est relativement protégé contre les adaptations envisageables par les spammeurs afin de contourner ce blocage. Les diverses méthodes de contournement peuvent diminuer l'efficacité du Greylisting, mais elles rendent alors d'autres techniques de blocage plus efficaces.

Le comportement normal d'un spammeur est de changer d'adresse IP dès que son adresse courante est placée en liste noire. Cependant, une modification d'adresse n'arrange rien du point de vue du Greylisting, puisque chaque message (et la ré-émission qui lui est imposée) dépend de l'adresse IP du serveur d'émission. Si l'adresse change, cela remet à zéro ce délai, quand bien même l'émetteur et le destinataire restent identiques.

L'autre solution envisageable rend obsolète tous les outils de pourriel actuel, puisque dans leur très grande majorité ils ne sont pas suffisamment évolués pour gérer un délai d'acheminement ou toute autre forme d'erreur. Les spammeurs devront soit utiliser des outils plus évolués, soit se servir de relais.

Les spammeurs vont peut-être se mettre à orbiter autour des relais de messagerie ouverts, mais ceux-ci sont heureusement de moins en moins nombreux. Peut-être configureront-ils leurs propres relais. Dans les deux cas, cela n'empêche pas que ces relais soient placés dans des listes noires, diminuant d'autant leur efficacité pour l'émission de pourriels.

Si les spammeurs utilisent leurs propres relais, les délais imposés par le Greylisting et la nécessité d'essayer plusieurs fois avant de réussir un acheminement ne feront qu'accroître la capacité de stockage et la bande passante nécessaires pour les spammeurs. Mécaniquement, leurs coûts augmenteront. Et, si le pourriel devient moins rentable, on s'approche d'une solution au problème.

Inconvénients de la méthode

La tactique du retard, qui est au coeur du Greylisting, peut provoquer des délais indésirables si le serveur sur lequel ces outils sont utilisés accepte des messages de clients dont l'adresse IP change souvent. Ainsi, si des clients provenant d'autres réseaux peuvent relayer des messages sur un serveur, par exemple après une authentificaiton POP ou IMAP, nos outils ne permettent pas un acheminement rapide de ces messages.

Il existe des solutions à ce problème, mais elles ne sont pas mises en oeuvre dans le code d'exemple fourni. A la base, il suffit, en même temps que l'on autorise le relayage, d'injecter dans la base de données du Greylisting un enregistrement (avec une faible durée de vie) indiquant l'adresse IP du client. Ce dernier pourra alors émettre, pendant la durée de vie de cet enregistrement, ses messages sans délais inutiles.

La réception de messages provenant de systèmes qui ne gèrent pas correctement les rejets temporaires, ou qui ne ré-émettent jamais les messages, est plus problématique. On peut simplement espérer que les outils qui présentent ce genre de dysfonctionnements seront corrigés lorsque le Greylisting commencera à être utilisé par beaucoup de sites.

Malheureusement, nos tests ont détecté plusieurs systèmes de ce genre. Ils respectent très mal les RFCs concernant SMTP, quant ils ne les ignorent pas totalement. SMTP étant, par nature, une méthode de transport non-fiable, les systèmes incapables de réémettre des messages devraient être corrigés.

Voici une session SMTP provenant d'un tel système :

-> HELO undomaine.com
<- 250="" hello="" br="">-> MAIL FROM: 
<- 250="" 2="" 1="" 0="" sender="" ok="" br="">-> RCPT TO: 
<- 451="" 4="" 7="" 1="" please="" try="" again="" later="" br="">-> DATA
<- 551="" no="" valid="" recipients="" br="">

Il est clair que le système émetteur n'a pas contrôlé le retour de sa commande RCPT, et a poursuivi par la commande DATA. Cette dernière provoque un rejet définitif du message. Dans le cas précis de ce serveur, il traite correctement le code 551, qui est considéré comme une erreur "permanente". Le message a été renvoyé à son émetteur avec l'erreur idoine. Ce comportement n'est pas correct, puisqu'il faudrait tenir compte de l'erreur "temporaire" qui a précédé, et mettre un terme à la transaction à ce moment.

Exemple de mise en oeuvre

L'exemple de mise en oeuvre est un filtre en Perl pour Sendmail, bâti sur la version 0.18 de l'interface Sendmail::Milter (que l'on peut aussi se procurer sur CPAN. Il a été testé avec Sendmail 8.12.9, et devrait fonctionner avec toute version postérieure à 8.12.5. Sendmail::Milter impose l'utilisation d'une version de Perl avec threads. Nous avons fait les tests avec perl 5.8.0, que l'on peut aussi trouver sur CPAN.

Vous trouverez aussi des définitions de bases de données, ainsi qu'un fichier de configuration. La mise en oeuvre étant écrite en Perl, elle est facile à modifier (mais n'est pas encore sur CPAN...).

La base de données utilisée est Mysql 3.23.54, mais le système devrait fonctionner avec toute version postérieure, et probablement avec d'autres antérieures. Le système de tests utilisait aussi amavisd-new ainsi que la nouvelle interface milter associée, configurée à l'aide de Spamassassin 2.53 pour bloquer les pourriels reçus.

Dans l'idée de diffuser une version d'exemple simple et facile à comprendre, certaines fonctionnalités, qui auraient pu facilement être optimisées, ne l'ont pas été. Malgré cela, durant des tests sous forts volumes de pourriels, le léger allongement du temps de traitement est demeuré invisible dans la plupart des cas. Les rares fois pour lesquelles le délai devenait visible s'expliquaient par les temps d'accès à la base de données (placée sur un autre système).

Les aficionados de la programmation structurée pourront avoir un arrêt cardiaque en examinant certaines portions du code : nous y utilisons plusieurs fois des goto. Du fait du fonctionnement de l'interface milter, cela semblait la solution la plus simple.

Autres détails sur la version d'exemple

Les messages correctement transmis dont l'émetteur est nul () sont un cas particulier. L'enregistrement associé dans la base est détruit immédiatement après la transmission du message, afin d'éviter que cet émetteur ne soit placé en liste blanche. Cet émetteur (si l'on respecte la RFC 821) n'est utilisé que pour des messages administratifs, comme les rejets. Il n'est donc normalement jamais utilisé pour plus d'un message à la fois. De ce fait, il est inutile de mémoriser le triplet associé une fois le message transmis.

Malheureusement, de nombreux spammeurs utilisent volontairement cette adresse nulle car, usuellement, elle ne provoquera pas un message de rejet de la part du serveur de destination (il est inutile d'envoyer un message de rejet en réponse à ce qui est normalement déjà un message administratif). Supprimer immédiatement le triplet après la transmission du message permet de limiter son utilisation par les spammeurs, puisqu'ils ne peuvent en profiter pour envoyer plusieurs messages vers un même destinataire.

D'autres fonctionnalités mineures sont présentes dans la version d'exemple, qui ne font pas partie stricto sensu partie du Greylisting. Elles visent à améliorer ou affiner le fonctionnement du filtrage des pourriels.

La base de données n'est pas normalisée. Il s'agit d'un choix volontaire, pour permettre à des utilisateurs peu familiers des bases de données de comprendre son fonctionnement. Cependant, il devrait être relativement facile de normaliser le schéma si le besoin s'en fait sentir.

Les outils de la version d'exemple ne contiennent aucun outil de maintenance de la base de données. Il n'existe aucun moyen d'insérer des triplets en liste blanche, si ce n'est les commandes SQL du fichier dbdef.sql. Je suppose que, à terme, une interface Web apparaîtra, mais elle n'existe pas pour le moment.

Liens vers la version d'exemple et d'autres sources d'information

Vous pouvez me contacter à l'adresse eharris AT puremagic.com. Si votre message concerne des outils mettant en oeuvre le Greylisting, ou des idées d'amélioration de la méthode, les listes d'informations semblent plus appropriées. Vous pouvez aussi télécharger la version d'exemple de mise en oeuvre du Greylisting.

Concernant la version française, si vous relevez des erreurs ou inexactitudes, vous pouvez nous contacter directement.

Si vous connaissez une mise en oeuvre qui n'est pas évoquée ici, vous pouvez envoyer un message avec l'URL et une brève description.

Eléments spécifiques à certains MTAs

Sendmail

Pour télécharger ma version d'exemple (nommée relaydelay), il suffit d'aller sur la page de téléchargement.

Vous avez aussi accès aux versions en cours de développement de relaydelay (via CVS).

Morris Maynard a rédigé des instructions d'installation du filtre pour sendmail particulièrement pertinentes et utiles.

Chris Paul a écrit quelques notes sur l'utilisation de la version d'exemple sur OpenBSD 3.4.

Emmanuel Dreyfus a écrit une version du Greylisting en C, s'interfaçant avec sendmail, et ne nécessitant ni perl, ni base de données.

Anthony Howe propose une autre version en Perl, qui utilise les bases Berkeley DB.

Exim

Martin Dempsey travaille sur une version de Greylisting pour Exim 4.x.

Roman Festchook travaille aussi sur une version pour Exim.

Tor Slettnes a développé une version autonome en python, n'utilisant aucune base de données externe. Elle fonctionne avec n'importe quelle version d'Exim et ne demande aucun ajout ou extension. Elle est activée par l'intermédiaire d'une règle ACL Exim, plutôt que via local_scan() ou une autre interface de ce type. Il n'existe pas encore de page dédiée à cet outil, mais un paquetage Debian a été créé.

Marc Merlin a écrit sa version utilisant aussi Spamassassin, ainsi que la documentation appropriée et un fichier diff.

Alun Jones a écrit un filtre Perl pour Exim, utilisée à l'Université de Galles. Sa page dédiée contient des liens vers son outil ainsi qu'une présentation Powerpoint montrant (entre autres) l'efficacité de la méthode.

Tollef Fog Heen a développé une version utilisant PostgreSQL.

Il existe une autre version, basée sur celle de Tollef Fog Heen, s'interfaçant avec MySQL et Exim. L'auteur en est inconnu.

Qmail

La version de Martin Dempsey, prévue pour Exim 4.x, devrait aussi fonctionner avec Qmail.

Qpsmtpd

Gavin Carr a développé un module pour Qpsmtpd (un remplaçant de qmail-smtpd écrit en Perl).

Postfix

Wietse Venema (l'auteur de Postfix) a apporté quelques modifications à Postfix afin d'y autoriser une forme de Greylisting.

David Schweikert a écrit une version Perl améliorée du serveur de politique pour Postfix.

Salim Gasmi a développé une version en C.

Michael Moritz a écrit une autre version en C/C++, utilisant DBI/MySQL.

Squirelmail

Jason Frisvold a écrit un module pour Squirelmail.

Relais de messagerie

Graham Toal a écrit un relais spécifique (le même fichier, en HTML) mettant en oeuvre (entre autres) le Greylisting.

David Parsons a écrit un client et un serveur simples mettant en place le Greylisting.

Davig Given a écrit un relais de messagerie appelé spey, hébergé par Sourceforce.

Autres...

Vernon Schryver a ajouté une forme de Greylisting au DCC (Distributed Checksum Clearinghouse).

James a écrit une note sur l'utilisation du Greylisting, conjointement avec spamd, pour OpenBSD 3.5.

Liens vers des produits commerciaux

Des produits commerciaux utilisant diverses formes de Greylisting existent. En France, nous pouvons notamment citer AltoSpam.

Autres projets de filtrage/blocage des pourriels

• Le projet DSPAM

Listes d'informations

La liste Greylist-announce est utilisée pour signaler les nouvelles versions de ma mise en oeuvre du filtre pour Sendmail. Il s'agit d'une liste à très faible trafic. Elle peut inclure des annonces concernant d'autres mises en oeuvre de cette méthode, ou de versions utilisables pour d'autres serveurs que Sendmail. Si vous êtes intéressé par l'utilisation de cette méthode, l'abonnement à cette liste est conseillé.

Il existe aussi une liste pour les développeurs et utilisateurs de la version d'exemple, traitant éventuellement d'autres mises en oeuvre. Si c'est votre cas, la liste Greylist-users vous concerne. Le trafic y reste faible, rarement au-delà de 5 ou 10 messages par jour.

Témoignages d'utilisateurs

De nombreuses personnes (bien trop nombreuses pour en faire la liste complète) ont évoqué les avantages qu'elles ont retiré du Greylisting. Certains utilisateurs sont même allés jusqu'à créer des pages Web, avec statistiques et graphiques. Je donnerai ici des liens vers d'autres sites contenant de telles données, pas seulement des remerciements pour la méthode.

Les pages de Grey Mack présentent différents graphiques, et des analyses statistiques, avant et après l'activation du Greylisting.

Remerciements

Si vous avez un compte Paypal, et que vous jugez cette idée, ce projet ou le code utiles, vous pouvez faire un don...
Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.&item_name=Greylisting&no_note=1&currency_code=USD&tax=0">

Si vous voulez contribuer autrement que via Paypal, écrivez-moi.

Je tiens à remercier les personnes suivantes pour leurs judicieuses remarques, et pour avoir secoué ma théorie dans tous les sens afin de vérifier qu'elle tenait debout :

• Brad Roberts
• Brian Michalk
• Corey Huinker
• Bob Apthorpe

Merci à Jacqueline Hamilton, qui m'a aidé à améliorer mes pages (pour la version anglaise, NDT). Elle a aussi écrit un très intéressant ouvrage sur la programmation Web avec Perl.

Je remercie Paul Graham, dont l'article A plan for Spam a provoqué une réelle révolution dans le monde du filtrage anti-spam, et qui m'a inspiré pour trouver d'autres moyens de résoudre ce problème.

Merci à Charles Ying pour avoir deéveloppé Sendmail::Milter. Ce module a grandement facilité le développement de mon projet. Merci aux innombrables autres développeurs qui ont écrit Sendmail, Mysql, Perl, Amavis et Spamassassin.

Enfin, merci à tous les administrateurs et gestionnaires des listes noires et autres outils anti-pourriels, qui évitent que le courrier électronique ne deviennent totalement inutile.