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.