Gestion des listes grises

Voici une note présentant les listes grises de messagerie.

Le comportement des listes grises avec Policy Daemon est contrôlé par les paramètres suivants (définis dans le fichier policyd.conf) :

• GREYLISTING : activation de la fonctionnalité (1) ou non (0).
• GREYLIST_REJECTION : message transmis au MTA en cas de rejet pour cause de liste grise.
• GREYLIST_X_HEADER : ajout (1) ou non (0) d'un entête spécifique dans les messages passant la liste grise.
• GREYLIST_HOSTADDR : nombre d'octets à prendre en compte dans l'adresse IP du MTA qui dialogue avec nous. La valeur par défaut (3) revient à regrouper tous les MTA d'une même classe C. Nous conseillons d'utiliser la valeur 4 (contrôle sur l'adresse IP complète).
• TRIPLET_TIME : délai minimal après lequel un triplet sera accepté. Les diverses études et statistiques faites tendent à montrer que 4 ou 5 minutes suffisent.
• TRIPLET_AUTH_TIMEOUT : durée de validité (en jours, usuellement) d'un triplet accepté, si aucun nouveau message ne vient le rafraîchir. Nous conseillons de lui donner une valeur légèrement supérieure à 30 afin de prendre en compte les listes d'information qui, une fois par mois, envoient un rappel de l'abonnement à la liste.
• TRIPLET_UNAUTH_TIMEOUT : durée (en jours) au-delà de laquelle un triplet qui n'a pas été validé sera effacé de la base.

Le paramètre GREYLIST_HOSTADDR mérite que l'on se penche un peu dessus. Il définit la longueur (en octets) de l'adresse IP du système émetteur que l'on va utiliser pour contrôler la présence d'un triplet dans la base. Le fonctionnement classique des listes grises procède à un contrôle sur l'adresse IP complète. Imaginons que le domaine émetteur dispose de trois serveurs d'émission, qui se partagent les files d'attente. Un message mis en attente peut dont être réémis par l'un des trois serveurs. Si vous n'avez pas de change, il sera successivement émis par SERVEUR1 (IP1), SERVEUR2 (IP2) et SERVEUR3 (IP3). Chaque fois, le triplet sera différent, puisque l'adresse IP du serveur d'émission ne sera pas la même. Le message sera donc temporisé bien plus longtemps que nécessaire.

GREYLIST_HOSTADDR permet de limiter ce problème, dans l'unique cas où les serveurs d'émission partagent une racine d'adresse IP commune. Il permet de ne faire porter le test non plus sur les adresses IP complète, mais sur les N premiers octets seulement (N étant compris entre 0 et 4). Si les adresses IP des trois serveurs précédents sont, respectivement, 1.2.3.11, 1.2.3.22 et 1.2.3.33, et si GREYLIST_HOSTADDR vaut 3 :

1. le MX reçoit un message de Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. pour Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., émis par SERVEUR1. Le message est repoussé, et le triplet (1.2.3.11, Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.) est mémorisé dans la base.
2. après un certain temps, le message est réémis par SERVEUR3. Le triplet associé est normalement (1.2.3.33, Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.). Mais le test ne porte que sur les trois premiers octets de l'adresse IP. Les deux triplets sont donc "identiques", au quatrième octet de l'adresse IP près.
3. le message est accepté.

Malgré l'intérêt apparent de ce comportement, nous conseillons de maintenir les tests sur les adresses IP complètes, et donc de définir GREYLIST_HOSTADDR à 4 et non pas à la valeur par défaut de 3. Cela pour les raisons suivantes :

• Le nombre de sites disposant de plusieurs serveurs d'émission est limité. Ce sont généralement de très gros fournisseurs de messagerie (et d'autres services).
• Dans le cas où un site dispose de plusieurs serveurs d'émission, ils ne sont que peu souvent tous sur des racines d'adresses IP communes.
• Si plusieurs systèmes d'un même sous-réseau (par exemple les clients d'un fournisseur d'accès) sont infectés du même zombie spammeur, ce qui est une situation loin d'être exceptionnelle, et si chaque zombie émet les mêmes messages (du point de vue des adresses de l'émetteur et du destinataire), votre MX acceptera tous les spams provenant des "voisins" du premier spammeur.

Cela dit... Rien ne vaut une analyse fine des journaux de votre messagerie pour juger de l'intérêt de ce paramètre et de la valeur à lui attribuer.

La fonction de liste grise de Policy Daemon a été activée le mardi de la semaine 34 à 15:30.

Il n'y a guère de doute quant à l'efficacité des listes grises (qu'elles soient gérées via Policy Daemon ou par un autre outil).