Divers moyens de filtrer et de contrôler l'envoi et la réception de mails.

Filtrages pendant la session SMTP

Postfix offre la possibilité d'appliquer différents filtres pendant la session SMTP. Quand un mail arrive sur votre serveur il se déroule les étapes suivantes :

CLIENT

Connexion TCP entrante sur le port 25

HELO

Le serveur expéditeur vous donne son nom

MAIL FROM

Le nom et l'adresse de courriel de l'éxpéditeur

RCPT TO

Le destinataire du courrier électronique

DATA

A cette étape de la connexion le mail en lui-même est transmis

QUIT

Fin de la session SMTP

Avec les réglages appropriés des restrictions SMTPd vous pouvez contôler les vérifications effectuées par Postfix lors de la réception d'un courrier. Ces restrictions sont définies dans le fichier de configuration /etc/postfix/main.cf et portent un nom de type smtpd_..._restrictions. Vous pouvez par exemple empêcher certaines adresses IP d'initier une connexion SMTP (TCP/25) avec votre de courrier pendant la phase « client ». Ou vous pouvez filtrer les destinataires autorisés pendant la phase « rcpt to ». La liste ci-dessous présente les restrictions applicables :

• smtpd_client_restrictions (valeur par défaut : vide)
• smtpd_helo_restrictions (valeur par défaut : vide)
• smtpd_sender_restrictions (valeur par défaut : vide)
• smtpd_recipient_restrictions (valeur par défaut permit_mynetworks, reject_unauth_destination)
• smtpd_data_restrictions (valeur par défaut : vide)

Avec ces réglages par défaut Postfix n'effectue des vérifications que pendant la phase RCPT TO pour contrôler que le courriel provient soit de votre propre réseau interne (l'adresse IP de l'expéditeur figure dans les maramètrages de « mynetworks ») ou que le destinataire possède bien un compte valide sur votre serveur. Si aucune des deux conditions n'est remplie le courriel est rejeté. Il est important de comprendre que les restrictions sont prises en compte chacune dans leur phase respective. Il est inutile d'appliquer une restriction sur l'adresse mail de l'expéditeur (MAIL FROM) pendant la phase HELO parce que cette information est encore inconnue lors de cette phase. Beaucoup d'administrateurs de serveurs de courrier se contentent de placer toutes leurs vérifications dans le filtre smtpd_recipient_restrictions. La suite de cette page vous donne quelques informations pour configurer vos restrictions de manière adéquate.

Listes noires en temps réel (Realtime blacklists ou RBL en anglais)

La principal technique utilisée de nos jours pour lutter contre les spammeurs est l'utilisation de listes noires d'IP. Il existe des douzaines de telles listes que vous pouvez utiliser gratuitement. Les mainteneurs de ces listes ont différentes politiques pour décider de qui doit être mis sur liste noire. La plupart d'entre eux disposent de pièges sur Internet dans lesquels tombent les spammeurs. La technique des pièges à spammeurs consiste à créer des adresses de courrier inutilisées dont le nom est placé dans des endroits cachés de sites Internet ou qui sont uniquement utilisées sur des listes de diffution. Les robots des spammeurs qui parcourent automatiquement Internet à la recherche d'adresses de courriel enregistrent ces adresses piège et leur envoient des courriers non sollicités. Si une de ces adresses reçoit un courrier cette information est utilisée par les opérateurs créant les listes noires d'IP, rajoutant l'IP expéditrice à la liste des serveurs de pourriel.

L'utilisation de ces listes noires est potentiellement dangereuse, car vous pouvez bloquer des courriels légitimes pour peu que leur serveur expéditeur ait été mis sur liste noire par erreur. Ma liste noire favorite « SORBS » m'a plusieurs fois laissé tomber en mettant en liste noire tous les courriels de Fournisseurs d'Accès Internet entiers pendant des heures voir des jours. Il est donc toujours très fortement recommandé de vérifier leur politque de bannissement pour vérifier qu'elle vous convient. Car au bout du compte le risque est pour vous. Une fois que vous avez rejeté un courriel il n'est plus possible de le récupérer. Mais malgré ces inconvénients potentiels je vous recommande d'utiliser les listes noires, sinon vous serez litéralement noyé sous les pourriels.

Les listes noires d'IP sont accessibles par un nom de domaine du style « bl.spamcom.net ». Pour vérifier qu'une certaine adresse IP est listée dans cette zone vous devez vérifier qu'elle contient une entrée pour l'IP inverse. Supposons qu'un serveur de courriel avec l'adresse IP 217.217.34.231 veut vous envoyer un courriel. Si vous demandez à Postfix d'utiliser la liste noire « bl.spamcom.net » Postfix va alors rechercher l'IP inverse (231.34.217.217) et vérifier s'il existe une entrée DNS pour :
231.34.217.217.bl.spamcop.net.. Je viens de le faire et j'obtiens le résultat suivant :

$ host 231.34.217.217.bl.spamcop.net
231.34.217.217.bl.spamcop.net has address 127.0.0.2

Le fait qu'un résultat existe (127.0.0.2) signifie que l'adresse est sur liste noire et que vous ne devriez pas accepter les courriels qu'elle envoit. Postfix répondra alors au serveur qu'il l'a trouvé sur une liste noire et clora la connexion. Le résultat renvoyé par ces listes a presque toujours une forme du type 127.0.0.x où X représente la raison du bannissement. Il vous faudra consulter le site internet de la liste noire détaillant leur politique de mise en liste noire pour savoir à quoi correspond ce code. Regardons une autre adresse qui n'est pas bannie, par exemple 85.214.93.191 :

$ host 191.93.214.85.bl.spamcop.net
Host 191.93.214.85.bl.spamcop.net not found: 3(NXDOMAIN)

Aucun résultat n'a été trouvé, l'IP ne figure donc pas sur la liste noire et je peux accepter le courriel qu'elle envoit.

Les principales listes noires que vous pouvez utiliser sont les suivantes :

SORBS (dnsbl.sorbs.net)

SORBS est très efficace mais plusieurs fois par an elle a tendance à bloquer de grands FAI accidentellement. Je ne l'utilise plus actuellement car j'ai eu à cause de cela trop de plaintes d'utilisateurs.

SpamCop (bl.spamcop.net)

Assez fiable. Sur un seul jour elle a bloqué 29 pourriels sur mon serveur.

SpamHaus (zen.spamhaus.org)

Également assez efficace. En un seul jour elle a bloqué 147 pourriels sur mon serveur.

UCEprotect (dnsbl-1.uceprotect.net)

A utiliser avec précaution. Les classes 2 et 3 sont trop strictes et bloquent même des utilisateurs légitimes. Sur une journée elle a bloqué 33 pourriels sur mon serveur.

Si vous utilisez ces listes noires les restrictions dans votre fichier /etc/postfix/main.cf devraient être les suivantes :

smtpd_recipient_restrictions =
  permit_mynetworks
  reject_rbl_client dnsbl.sorbs.net
  reject_rbl_client bl.spamcop.net
  reject_rbl_client zen.spamhaus.org
  reject_rbl_client dnsbl-1.uceprotect.net
  reject_unauth_destination

Note : Vous pouvez également lister les restrictions sur une seule ligne en les séparant par une virgule. Personnellement je préfère utiliser plusieurs lignes en indentant les lignes de restrictions. Cela rend le fichier main.cf plus lisible.

Avec ces restrictions actives, Postfix les appliquera chacune leur tour après la phase RCPT TO du dialogue SMTP.

1. L'adresse IP de l'utilisateur est-elle dans votre classe de réseau ?
2. Est-elle bloquée par SORBS ?
3. Est-elle bloquée par SpamCop ?
4. Est-elle bloquée par SpamHaus ?
5. Est-elle bloquée par UCEprotect ?
6. Votre serveur de mail est-il responsable du domaine du destinataire ou bien l'expéditeur utilise-t-il l'authentification SMTP pour relayer son courrier ?

Autres restrictions possibles

Postfix offre de nombreuses autres contrôles utilisables dans vos smtpd_…_restrictions. En voici juste quelques unes que j'utilise sur mon serveur de courriel :

reject_unknown_client_hostname

Réalise une vérification DNS double sur l'adresse IP et le nom d'hôte. C'est potentiellement dangereux et rejetera tout courriel légitime provenant d'un serveur de mail mal configuré, mais de nos jours tout serveur de mail décent est sensé faire attention à ses réglages DNS.

reject_unknown_sender_domain

Vérifie que le domaine utilisé par l'expéditeur existe bien réellement. Cela lance une requête pour trouver un enregistrement MX et un enregistrement A dans la configuration DNS du domaine.

reject_unauth_pipelining

Quelques robots de pourriel essaie d'envoyer les courriels le plus rapidement possible. Selon le protocole le serveur expéditeur doit attendre la réponse du serveur destinataire à chaque étape SMTP. Si le serveur destinataire autorise le tubage alors l'expédition rapide est autorisée. Ce règlage rejette la connexion si le serveur expéditeur essaye d'utiliser le tubage avant d'y être invité par le serveur destinataire.

D'autres règlages peuvent être trouvés sur la page Postfix documentation.

Êtes-vous sur liste noire ?

Bien entendu vous voulez envoyer du courrier en utilisant votre serveur de mail. Vous devez donc vous assurer que l'adresse IP de votre serveur ne figure sur aucune liste noire. Je vous suggère donc de tester l'adresse de votre serveur sur un des services de test en ligne :

• http://www.anti-abuse.org/multi-rbl-check/
• http://rbl-check.org/

(Ces services vous donneront également une idée des multibples autres services de liste noire disponibles.)

Si vous figurez sur l'une quelconque de ces listes vous voudrez vous en faire rayer. La procédure à suivre dépend de la politique de bannissement choisie par chaque gestionnaire de liste noire. Certains n'acceptent aucun retrait manuel de leurs listes. Si votre FAI vous alloue une adresse IP dynamique vous vous trouvez alors sur un segment d'IP appelé « dial up IP range » et cette IP est vraissemblablement bannie d'avance et sans possibilité d'être sortie de la liste. Lisez cette page qui fournit une solution à ce problème. Beaucoup de pourriel provient d'adresses IP dynamiques. La cause en est soit que certains spammeurs utilisent leur compte chez un FAI ou plus sûrement que l'immense quantité de PC sous Windows infestés de virus en service dans le monde entier serve de relais de pourriel. Ainsi les segments d'IP dynamiques sont-il rejetés par les administrateurs de serveurs de courriel.

Note du traducteur : les connexions dites « dial up » correspondent aux connexions commutées (passant par le réseau téléphonique). Ces classes d'IP correspondent également aux connexion actuellement plus courantes par câble ou ADSL (dites en anglais Broadband, à large bande).

Prévenir l'usurpation d'adresse d'expéditeur

Les sections qui précèdent sur les listes noires d'IP vous ont aidé à combatre le pourriel en le rejetant. Nous allons maintenant ajouter des mesures de sécurité destinées à prévenir l'usurpation d'adresse d'expéditeur (« source address spoofing » en anglais). Usurpation signifie que quelque'un contrefait des informations et l'adresse d'expéditeur est celle qui apparaît comme étant celle de l'expéditeur du mail. Cela signifie donc que quelqu'un prétend être quelqu'un d'autre en contrefaisant l'adresse de l'expéditeur. Vous n'y avez peut-être jamais réfléchi, mais n'importe qui peut envoyer un courriel en prétendant être quelqu'un d'autre. Vous utilisez peut-être vous-même plusieurs adresses de courriel. Qu'est-ce qui empêche quelqu'un d'envoyer un mail en fournissant une de votre adresse comme adresse d'expéditeur ? Il existe deux grandes options pour empêcher cela :

1. SPF (Sender Policy Framework): Using SPF anyone can find out if an email was sent from an IP address (=mail server) that is allowed to act as a mail server for that sender domain. Technically with SPF you create a DNS entry for your domain and list the valid IP addresses there that are allowed to send email on your domain's behalf.
2. DKIM (DomainKeys Identified Mail): DKIM uses a private/public key pair to sign all outgoing emails automatically. By making your domain's public key available through DNS every mail server on the internet can check if the signature is valid for your domain and nobody spoofed the email. Although SPF is more widespread than DKIM it has a major design flaw because it fails when you forward email (as the sending IP address changes and may not be a valid address listed in the SPF entry any more).

Configurer votre propre enregistrement SPF

Le contenu d'un enregistrement SPF suit une certaine syntaxe. Pour faciliter les choses vous pouvez utiliser le service OpenSPF pour configurer votre enregistrement SPF. Entrez votre nom de domaine et remplissez les champs du formulaire. Le site Internet vous affichera votre enregistrement SPF tel qu'il doit se présenter. Ajoutez-le dans votttre zone DNS et à la fois vous aiderez les autres à lutter contre le spam et vous vous aiderez vous-même en évitant que n'importe qui puisse envoyer des maisl non désirez sous votre identité. Auparavant un enregistrement TXT était utilisé dans la zone DNS, mais maintenant il existe un type d'enregistrement SPF pour couvrir ce besoin.

Note du traducteur : je laisse le lien sur la page wikipedia anglaise, la page française étant actuellement seulement à l'état d'ébauche.

Vérifier les enregistrements SPF des autres

De nombreux domaines ont déjà des entrées SPF. Vous êtes donc encouragés à utiliser ces informations pour votre propre protection contre le pourriel et le « phishing » où « hameçonnage ». Lisez la section suivante pour apprendre comment utiliser le service tumgreyspf pour bénéfier à la fois des avantages de SPF et du greylisting.

Note du traducteur : en français deux traductions sont proposées pour « phishing », « hameçonnage » et « filoutage », la première étant québecoise la seconde française. la quebecoise me semble plus parlante et proche de la fabrication du mot anglais.

Le transfert des mails casse le contrôle SPF

SPF a une faiblesse de conception majeure : il empêche que quelqu'un puisse transférer un courriel vers un autre serveur. Le serveur de transfert n'étant pas listé dans l'enregistrement SPF le serveur de destination (logiquement) rejette le courriel. Les utilisateurs peu au fait de la technique ne comprennent pas cette limitation. Du coup nombre d'administrateurs prennent juste en compte la vérification SPF lorsqu'ils filtrent le pourriel, mais ne vont pas jusqu'à rejeter le courriel. C'est à vous de voir. SPF combat de façon fiable l'usurpation et l'hameçonnage pour de grands domaines comme PayPal, eBay ou Amazon et d'autres grandes entreprises qui sont souvent la cible des hameçonneurs. Dans certains cas il peut s'agir d'un excès de prudence.

Vérifier la signature DKIM des courriels entrants

DKIM a été inventé dans un but similaire à celui de SPF. Il fournit une authentification des courriels qui permet que le serveur recevant le courriel puisse vérifier que le courriel est authentique et provient bien du domaine de courriel annoncé par l'expéditeur. SPF se contente de dire quelles IP sont autorisées à envoyer des courriels pour un domaine. Mais DKIM est encore plus sûr parce qu'il ajoute une signature cryptée à chaque courriel envoyé. Pour vérifier l'authenticité du courriel le serveur de réception peut utiiser la signature en la contrôlant à l'aide de la clé publique du domaine qu'il peut obtenir par le DNS. Cela vous semble compliqué ? En réalité c'est assez simple si vous avez compris les bases du cryptage par clé publique. Avez-vous déjà utilisé PGP ? Alors vous savez que vous devez créer un paire de clés consistant en une clé privée que vous utilisez pour signer les courriels et une clé publique que vous pouvez donner aux autres pour qu'ils qu'ils encryptent les courriels qui vous sont destinés ou qu'avec ils vérifient vos signatures. DKIM utilise exactement cette technique. Le servuer d'expédition à une paire de clés pour chaque domaine. Quand il expédie un courriel il utilise la clé privée du domaine d'expédition du courriel et signe le courriel avec une signature cryptée. Cette signature est rajoutée au courriel (dans un entête spécifique) et le serveur de réception peut utiliser cette signature cryptée et la clé publique du domaine pour décider si la signature est valide.

Ajouter la vérification automatique des signatures DKIM des autres domaines est assez facile. Il suffit juste d'installer le programme de filtrage DKIM :

# aptitude install dkim-filter

En réalité ce programme est appelé un « milter ». Les milters sont des « filtres de courriel » (mail filters en anglais) qui furent introduits en tant que morceaux de code additionnels à l'ancien logiciel serveur de courriel Sendmail. Les milters parlent un certain protocole que les serveurs de mail peuvent utiliser pour communiquer avec eux et par chance Postfix sait aussi utiliser les milters. Juste après l'installation un processus dkim-filter est déjà démarré en arrière plan. Mais comme Postifix est installé dans une prison « chrootée » dans /var/spool/postfix il ne peut utiliser le socket de communication du filtre DKIM à son emplacement par défaut dans /var/run/dkim-filter/dkim-filter.sock. Vous pouvez modifier les permissions pour faire en sorte que DKIM lance un socket dans /var/spool/postfix à la place, mais pour ma part je préfère plutôt faire tourner dkim-filter en tant que service TCP plutôt que sur un socket. Éditez votre fichier /etc/default/dkim-filter qui contient ses réglages par défaut et ajoutez-y :

SOCKET="inet:54321@localhost"

puis redémarrez le processus dkim-filter :

/etc/init.d/dkim-filter restart

Maintenant dkim-filter écoute sur le port TCP 54321 sur l'interface localhost. Pour permettre à Postfix d'utiliser ce milter, lancez ces commandes pour ajouter les définitions de milter appropriées à votre fichier /etc/postfix/main.cf :

# postconf -e smtpd_milters=inet:127.0.0.1:54321
# postconf -e non_smtpd_milters=inet:127.0.0.1:54321

Maintenant Postfix fera passer tous les courriels (à la fois entrants et sortants) par le filtre DKIM et vérifiera les signatures DKIM (si il en trouve) sur les courriels entrants. Il ne signera pas encore les courriels sortants depenant. Nous allons voir cette configuration dans la section suivante.

Une remarque annexe : vous pouvez décider de ce qui doit se passer en cas de problème avec le filtre DKIM. Par défaut Postfix rejetera temporairement ces courriels jusqu'à ce que vous ayez résolu le problème. C'est vous qui voyez. Pour ma part je préfère simplement les laisser passer en cas de problème de fonctionnement du filtre. Je rajoute donc à la configuration de Postfix :

# postconf -e milter_default_action=accept

Vous trouverez davantage d'informations sur les milters en consultant la documentation de Postfix à propos des milters (en anglais).

Configuration de DKIM pour l'envoi de courriels

L'idée de base de DKIM est de faire en sorte qu'un serveur de courriel d'un domaine signe automatiquement les courriels sortants pour ce domaine. Pour faire cela vous devez avant tout créer une paire de clés de cryptage. Heureusement vous n'avez pas besoin d'acheter un certificat, car publier la clé publique dans votre zone DNS suffit. L'outils dont vous avez besoin est dkim-genkey qui n'a besoin pour fonctionner que de la longueur de la clé en octets et du nom de domaine à protéger. Vous pouvez également utiliser un sélecteur pour utiliser des clés multiples. Par défaut le sélecteur est appelé « default ». Je vous suggère d'utiliser votre nom de domaine en tant que sélecteur, ce qui aura pour effet de nommer correctement vos fichiers de manière automatique.

Il est préférable de créer un répertoire séparé pour stocker les clés. J'ai placé le mien dans /etc/postfix/dkim :

# mkdir /etc/postfix/dkim
# cd /etc/postfix/dkim

Une fois dans le répertoire on crée la paire de clés :

# dkim-genkey -b 1024 -d example.org -s example.org

Vous avez maintenant deux clés dans votre répertoire :

• example.org.private est la clé privée avec laquelle le milter DKIM signera tous les courriels sortants
• example.org.txt est la clé privée que vous devez placer dans la zone DNS de votre domaine

Le fichier de configuration du milter DKIM est /etc/dkim-filter.conf. Éditez le. La seule modification à y apporter est de rajouter une ligne pour indiquer où trouver le fichier listant les clés :

KeyList     /etc/dkim-keys.conf

Il reste à créer ce fichier /etc/dkim-keys.conf vers lequel vous avez fait pointer DKIM. Son contenu sert à définir quelle clé utiliser pour chaque expéditeur. La syntaxe à employer est précisemment :

motif de l'expéditeur:domaine de signature:chemin de la clé

comme cela est indiqué dans la mage de manuel man dkim-filter.conf. Ainsi si votre domaine est example.org il vous faudra écrire :

*@example.org:example.org:/etc/postfix/dkim/example.org

Ajoutez une ligne par domaine expéditeur dont vous voulez que les mails soient signés.

ATTENTION : dkim-filter ajoute « .private » au chemin que vous spécifiez. La ligne ci-dessus est donc correcte. Si vous spécifiez /etc/postfix/dkim/example.org.private la signature échouera.

Redémarrez le milter DKIM :

/etc/init.d/dkim-filter restart

Maintenant les courriels sortants devraient avoir automatiquement une signature DKIM. Expédiez un courriel à un autre serveur et contrôlez les entêtes de ce courriel. Vous devriez voir quelque chose dans ce genre :

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.org; s=example.org t=1307571770; bh=OtZOIOSkkhL1t+kR5KOE6HvvjUjLkDE+70agcKmcjJg=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=RlxE9IRiOJrOzM4JbJFIp/YmK4XBRJFti79rL0vzGkppAC1AJi2CdtwGFT/sTovt/iKikrdyQ7M7JhdlC9u3bh8rrvhLA53HZCmu6WvHvv059ysdpjUhrktEqZFrFpgds2wqCkzF4ar/ly3TzYZmoZJO+C8j2uU5L3cKzESfGw4=

La signification de chaque paramètres peut être trouvée sur la page Wikipedia ou bien dans le format moins agréable à lire pour un humain de la RFC 4871.

Cependant les destinataires ne peuvent dire si la signature est correcte parce qu'ils n'ont pas la clé publique pour effectuer la vérification. Éditez la zone DNS de votre domaine et ajoutez-y juste un enregistrement TXT contenant la clé que dkim-genkey a créé pour vous dans /etc/postfix/dkim/example.org.txt. Sur mon serveur cela ressemble à ça :

example.org._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKPFhCADCGcxDchGHFqvSoQYuW0epBT0gJuCwDMkX0uPejeeMdBNDcaGo8AyZdXJTFKqGK5kao2OvpDsH6XeKMBjPt/CnyBm4PNwlwNrkJTBc15xjD6Swmlk457+Ioz/tbpBA3b3RnC8NsqiknLQ3JxDkE7fXfji7Uds5+swWwJQIDAQAB" ; ----- DKIM example.org for example.org

Vérifiez que votre zone DNS contient bien la bonne entrée pour votre domaine en l'interrogeant à la recherche d'un enregistrement TXT concernant votre nom de domaine et le sélecteur que vous avez utilisé :

$ dig +short example.org._domainkey.example.org txt

cela devrait vous retourner votre clé publique :

"v=DKIM1\; g=*\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKPFhCADCGcxDchGHFqvSoQYuW0epBT0gJuCwDMkX0uPejeeMdBNDcaGo8AyZdXJTFKqGK5kao2OvpDsH6XeKMBjPt/CnyBm4PNwlwNrkJTBc15xjD6Swmlk457+Ioz/tbpBA3b3RnC8NsqiknLQ3JxDkE7fXfji7Uds5+swWwJQIDAQAB"

Maintenant tous les courries sortants pour …@example.org porteront une signature DKIM automatiquement ajoutée et les destinataires pourront la vérifier. Tous les serveurs de courriel utilisant les signatures DKIM pourront maintenant véfifier si les mails prétendant provenir de votre domaine sont légitimes ou pas.

Si je postule que vous avez configuré le milter DKIM dans Postfix comme je viens de l'expliquer. Le fait de placer les options de configuration smtpd_milters et non_smtpd_milters dans votre fichier /etc/postfix/main.cf aura pour conséquence que Postfix effectuera à la fois la signature des courriels sortants et la vérification des signatures des courriels entrants.

Greylisting (littéralement listes grises)

Une autre façon de vous aider à réduire la quantité de pourriels que vous recevrez est l'utilisation du greylisting. Le Whitelisting (liste blanche) signifie qu'une certaine catégorie de courriels sont toujours acceptés (avec un statut de distribution de la forme  2.x.x). Le Blacklisting (liste noire) correspond au contraire et bloque toujours certains courriels (avec un statut de distribution de la forme5.x.x). Le Greylisting est quelque chose d'intermédiaire qui refuse temporairement un courriel pour une durée de quelques minutes. L'idée est de tromper les ordinateurs infestés par des virus qui essayent de vous envoyer des pourriels. Les Virus (ou plutôt les Vers de pourriel) essayent juste d'envoyer un pourriel une fois. Les vrais serveurs de courriel ont une file d'attente de courriers sortants et face à une erreur temporaire ils vont réessayer de vous délivrer le courriel. Si le serveur d'expédition ne vous a jamais envoyé de courriel auparavant le greylisting va leur envoyer un code d'erreur temporaire (de la forme 4.x.x) qui demandera au serveur expéditeur de réessayer son envoi dans quelques minutes. Votre serveur va noter l'adresse IP du serveur expéditeur et après un période d'attente (une valeur courante est 10 minutes) le blocage sera levé et à la prochaine présentation du mail, celui-ci sera accepté. de plus le service de « liste grise » notera cette IP dans son cache et les futurs envois seront immédiatement acceptés.

L'inconvénient évident consiste en ce que les courriers électroniques sont souvent retardés de plusieurs minutes, particulièrement lorsque vous venez de lancer le service de greylisting et que son cache de serveurs de confiance est vide. Vous pouvez faire ce choix à condition que vos utilisateurs acceptent cet inconvénient. Sur la base de mon expérience personnelle, le greylisting n'est plus aussi efficace de nos jours qu'à ses débuts. Il semble que les vers et virus aient appris à expédier leurs pourriels plusieurs fois. Cela peut pourtant encore bloquer quelques pourriels.

Il existe plusieurs façons d'implémenter le greylisting. J'utilise pour ma part le logiciel tumgreyspf. Commençons par l'installer :

# aptitude install tumgreyspf

Pour que Postfix utilise tumgreyspf vous devez définir un service pour lui dans /etc/postfix/master.cf :

tumgreyspf unix  -      n       n       -       -       spawn
		    user=tumgreyspf argv=/usr/bin/tumgreyspf

Vous avez également besoin de l'ajouter à votre smtpd_recipient_restrictions dans le fichier /etc/postfix/main.cf. Exemple :

smtpd_recipient_restrictions =
	permit_mynetworks
	permit_sasl_authenticated
	reject_rbl_client bl.spamcop.net
	check_policy_service unix:private/tumgreyspf
	reject_unauth_destination

Ce sont de simples exemple, ne les copiez/collez pas. Ils sont juste là pour vous montrer un bon endroit pour placer ces règles dans votre smtpd_recipient_restrictions.

Relancez Postfix :

# postfix reload

Pour personnaliser le comportement de tumgreyspf, vous pouvez modifier les fichiers dans /etc/tumgreyspf (cette procédure est également documentée dans le fichier /usr/share/doc/tumgreyspf/README.Debian.)

Finalement testez le relayage

Vous souvenez-vous de ce que j'ai dit plus tôt concernant le relayage ? Vous ne devez pas devenir un relais ouvert, ou alors vous serez considéré comme un supporter des expéditeurs de pourriels et mis sur liste noire. Il y a une façon très simple de lancer quelques vérifications à ce sujet. Connectez-vous sur votre serveur de courriel et lancez :

telnet relay-test.mail-abuse.org

Attendez quelques secondes. Le service distant va se connecter à votre serveur et lancer quelques contrôles sanitaires. Si après que tous les tests aient été effectués vous voyez :

System appeared to reject relay attempts
		Connection closed by foreign host

alors vous avez configuré votre serveur de manière sécurisée, bien joué.