Quelques vérifications et restrictions supplémentaires.

REMARQUE PRÉLIMINAIRE : Je n'ai pas testé ce type de configuration avec tumgreyspf dans un environnement de production. Procédez avec prudence. Laissez-moi un commentaire si cela a fonctionné pour vous. Merci.

Postfix permet d'appliquer des filtres pendant la session SMTP. Quand un mail arrive sur votre serveur de courrier les étapes suivantes normalement s'enchaînent :

CLIENT

Connexion entrante sur le port 25.

HELO

Le serveur distant vous donne son identité.

MAIL FROM

Fournit le nom et l'adresse mail de l'expéditeur.

RCPT TO

L'adresse mail du destinataire du courrier.

DATA

Lors de cette phase de la session SMTP le mail est effectivement transmis.

QUIT

Marque la fin de la session SMTP.

Avec une configuration adaptée des restrictions de SMTPd vous pouvez contrôler quelles vérifications devront être effectuées à l'arrivée d'un courrier. Ces restrictions sont définies dans le fichier de configuration /etc/postfix/main.cf et on un nom de la forme smtpd_..._restrictions. Vous pouvez par exemple restreindre à certaines IP l'ouverture d'une connexion SMTP (TCP/25) sur votre serveur pendant la phase client. Ou vous pouvez filtrer quels destinataires sont autorisés pendant la phase rcpt to. En fonction de la liste de phases ci-dessus ces restrictions peuvent être appliquées :

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

Donc par défaut Postfix n'applique de vérifications que durant la phase RCPT TO pour vérifier que le mail à la fois provient de votre réseau privé (l'adresse IP de l'expéditeur fait partie des valeurs acceptées dans la variable mynetworks) et est destiné à un compte mail existant sur votre serveur de courrier. Il est important que vous compreniez que les restrictions doivent être effectuées lors de la bonne phase. Rien ne sert d'appliquer une règle de vérification de l'adresse email (MAIL FROM) pendant la phase HELO car à cette étape cette information est encore inconnue. Beaucoup d'administrateurs de serveurs de mail se contentent d'effectuer leurs vérificaiton dans la variable de restriction smtpd_recipient_restrictions. Les sections qui suivent vous donnent quelques informations sur la façon de configurer convenablement vos restrictions.

Les listes noires en temps réel (Realtime blacklists ou RBLs)

La technique principale de combat contre les spammeurs est de nos jours l'utilisation de listes noires d'IP. Il existe des douzaines de ces liste utilisables gratuitement. Ceux qui mettent en oeuvre de telles listes ont différentes politiques quant à la récolte des adresses à mettre en liste noire. Mais la plupart d'entre eux exploitent des pièges sur Internet dans lesquels tombent les spammeurs. Ces pièges sont des adresses mail jamais utilisées placées sur des sites web dans un endroit dissimulé ou utilisées dans des listes de diffusion. Avec des logiciels automatisés les spammeurs parcourent Internet à la recherche d'adresses email et envoient alors du spam aux adresses trouvées par leurs robots. Si une de ces adresses piège reçoit un courrier cette information est utilisée par l'opérateur de la liste noire pour construire sa liste d'IP à bloquer. L'utilisation des listes noires est potentiellement dangereuse car vous pouvez ainsi bloquer un courrier provenant d'un serveur légitime si ce serveur a par erreur été mis en liste noire. Ma liste noire favorite SORBS par exemple m'a plusieurs fois planté en mettant en liste noire tous les envois de grands fournisseurs d'accès à Internet pendant des heures, parfois des jours. Il est donc prudent de lire les informations qu'ils fournissent concernant leur politique de banissement et de voir si elle vous convient. Car au bout du compte c'est vous qui assumez le risque. Une fois que vous avez rejeté un mail il est impossible de le récupérer. Mais je vous recommande pourtant fortement d'utiliser des listes noires, sous peine d'être littéralement submergés par le spam.

Les listes noires d'IP sont spécifiées par un nom de domaine du type bl.spamcop.net. Pour contrôler si une adresse IP est listée sur cette liste vous devez vérifier si une entrée pour l'adresse IP inversée existe (reversed IP) dans cette zone. Admettons qu'un serveur possédant l'adresse 217.217.34.231 veuille vous envoyer un mail. Si vous dites à Postfix d'utiliser la liste noire bl.spamcop.net alors Postfix va renverser l'adresse IP et chercher une entrée DNS pour 231.34.217.217.bl.spamcop.net. Je l'ai fait et j'ai obtenu ce résultat :

$> 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 ait été trouvé (du type 127.0.0.2) indique que l'adresse IP est en liste noire et que vous ne devriez pas accepter les mails qui en proviennent. Postfix va dire à l'envoyeur qu'il a déclenché une réponse de la part d'une liste noire et va fermer la connexion. Le résultat retourné est presque toujours une adresse 127.0.0.x où le x indique la raison de la mise en liste noire. Vous devrez lire les règles de la liste noire en question pour connaître cette raison. Testons une autre adresse IP qui n'est pas inscrite sur cette liste noire, 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)

Je n'obtiens pas de résultat donc l'IP n'est pas dans la liste noire et vous devriez accepter le courrier en provenant.

Voici les listes noires principales dont vous devriez évaluer l'utilisation :

SORBS (dnsbl.sorbs.net)

SORBS est très efficace, mais plusieurs fois par an il a tendance à bloquer de vastes rangs d'IP de fournisseurs d'accès Internet par accident. Je ne l'utilise plus actuellement car j'ai eu trop de plaintes de la part d'utilisateurs.

SpamCop (bl.spamcop.net)

Plutôt fiable. Sur une seule journée il a bloqué 29 spams sur mon serveur de mail.

SpamHaus (zen.spamhaus.org)

Également plutôt fiable. Sur une journée il a bloqué 147 mails sur mon serveur.

UCEprotect (dnsbl-1.uceprotect.net)

Attention, les listes class-2 et class-3 sont trop strictes et bloquent même des utilisateurs légitimes. En une journée il a bloqué 33 mails sur mon serveur.

Si vous voulez utiliser ces listes noires sur votre serveur alors vous devez placer ces restrictions dans votre fichier /etc/postfix/main.cf :

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 aussi lister toutes ces restrictions sur une seule ligne, séparées par des virgules. Mais je préfère utiliser plusieurs lignes indentées, cela rend plus lisible le fichier main.cf.

Avec ces restrictions en place Postfix va lancer chacune de ces vérification après la phase RCPT TO du dialogue SMTP.

1. L'adresse IP de l'expéditeur est elle dans votre réseau ?
2. Est-elle blacklistée par SORBS ?
3. Est-elle blacklistée par SpamCop ?
4. Est-elle blacklistée par SpamHaus ?
5. Est-elle blacklistée par UCEprotect ?
6. Votre serveur est-il responsable du domaine du destinataire ? Ou l'utilisateur utilise-t-il l'authentification SMTP pour obtenir le relayage ?

Note du traducteur : ATTENTION les restrictions et permissions s'appliquent dans l'ordre où elles apparaissent dans la liste. La documentation française dit :

« Indiquez une liste de restrictions, séparé (sic) par des virgules et/ou des espaces. Continuez les lignes longues en commençant la ligne suivante par des espaces. Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui correspond est appliquée et les suivantes sont ignorées. »

Si vous voulez créer un smarthost, c'est à dire un serveur servant à envoyer le courrier comme les serveurs de votre FAI, il faudra prendre garde d'autoriser l'identification avant de lancer les rbls sous peine de ne pouvoir envoyer de courrier depuis des IP de connexion. Voici ce que j'ai sur mon smarthost :

smtpd_recipient_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination
  reject_rbl_client bl.spamcop.net
  reject_rbl_client zen.spamhaus.org

Autres restrictions à envisager

Postfix propose quantité d'autres vérifications que vous pouvez utiliser dans vos clauses smtpd_…_restrictions. Voici quelques unes que j'utilise sur mon serveur de mail :

reject_unknown_client_hostname

Lance deux requêtes DNS, l'une pour l'adresse IP et l'autre pour le nom de domaine du serveur distant. C'est potientiellement dangereux et rejetera le courrier de serveurs de mail légitimes mais mal configurés, mais de nos jours tout serveur de mail décent est sensé prendre soin de sa configuration DNS.

reject_unknown_sender_domain

Vérifie si le domaine utilisé dans l'adresse de l'expéditeur existe vraiment. Cela lance un requête pour trouver l'enregistrement MX ou A du domaine d'expédition.

reject_unauth_pipelining

Certains robots de spam essayent simplement d'envoyer les mails le plus vite possible. Selon les bonnes pratiques l'expéditeur doit attendre la réponse du serveur de réception à chaque étape du dialogue SMTP. Si le serveur de réception autorise le tunnelage (pipelining) alors l'envoi rapide est autorisé. Cette directive rejette la connexion si une tentative de tunnelage intervient avant qu'elle ne soit proposée par le serveur de destination.

D'autres réglages figurent dans la documentation de Postfix.

Note du traducteur : j'ai remplacé les liens vers la documentation anglaise proposés par Christoph par ceux vers la traduction française. Si vous voulez voir les liens originaux consultez-les depuis la page originale de Christoph Haas.

Votre IP figure-t-elle sur une liste noire ?

Bien entendu vous voulez pouvoir envoyer votre courrier au travers de 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 de contrôler votre adresse IP via des services de test spécialisés comme par exemple :

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

(Ces services vous donnent en plus une idée de toutes les listes noires disponibles.)

Si votre IP figure sur une de ces listes vous allez devoir vous faire radier. La façon de faire est spécifique à chaque liste. Certaines n'offrent pas le retrait manuel de la liste. Si votre FAI vous alloue une IP dynamique, alors vous vous trouvez dans le cas appelé dialup IP range (Ndt : que l'on pourrait traduire par segment d'IP de connexion) et êtes plus que certainement « blacklisté » et il n'y a aucune chance de sortir de la liste ( lisez cette page pour une solution). Un grand nombre de spam provient d'adresses IP dynamiques. Parfois les spammeurs envoient le spam depuis leur connexion FAI. Ou le grand nombre d'ordinateurs sous Windows infestés de virus de par le monde sert à relayer le spam. C'est pourquoi les adresses IP dynamiques sont vues d'un mauvais œil par les administrateurs de serveurs de courrier.

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

Le chapitre sur les listes noires vous a aidé à combattre le spam en le rejetant. Maintenant passons à une autre mesure de sécurité pour prévenir l'usurpation d'adresse mail (en anglais source address spoofing). Spoofing (usurpation) signifie que quelqu'un falsifie l'information. Et la source address est l'adresse mail qui apparaît comme étant celle de l'expéditeur. Cela signifie que quelqu'un prétend être quelqu'un d'autre en falsifiant l'adresse de l'expéditeur. Peut-être n'y avez vous pas encore réfléchi beaucoup mais de manière très simple n'importe qui peut envoyer un mail en prétendant être quelqu'un d'autre. Peut-être même avez vous utilisé vous-même de multiples adresses d'expéditeur. Comment empêcher quelqu'un de se faire passer pour vous ? Il existe deux options courantes :

SPF Sender Policy Framework

Grâce à SPF (Sender Policy Framework que l'on peut traduire approximativement par « cadre de règles d'expédition ») n'importe qui peut savoir si un email a été envoyé depuis une adresse IP (c'est à dire un serveur de mail) autorisée à agir en tant que serveur de mail pour le domaine de l'expéditeur. Techniquement avec SPF vous cééz une entrée DNS pour votre domaine et listez les adresses IP autorisées à envoyer du courrier pour le compte de votre domaine.

DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail que l'on peut traduire par « identification de courriers par clés de domaine ») utilise un jeu de clés privée/publique pour signer tous les courriers sortants automatiquement. En rendant la clé publique de votre domaine accessible via le DNS tout serveur de mail sur Internet est capable de vérifier si la signature est valide pour votre domaine et personne ne peut usurper votre adresse mail. Bien que SPF soit plus répandu que DKIM il a une faille d'importance : il empêche de transférer un courrier (car l'adresse IP d'expédition change et peut ne pas être une adresse figurant dans la liste des adresses autorisées).

Configurer votre propre entrée SPF

Le contenu de l'entrée SPF suit une syntaxe précise. Pour faciliter les choses vous pouvez utiliser une application en ligne disponible sur OpenSPF pour configurer votre entrée SPF. Vous entrez votre nom de domaine et vous remplissez les champs du formulaire. Le site web vous indiquera à quoi devra ressembler votre entrée SPF. Copiez ce résultat dans votre zone DNS et à la fois vous aiderez les autres à combattre le spam et vous éviterez que quiconque envoie des mails non sollicités sous votre identité. Anciennement un enregistrement TXT était ajouté à la zone DNS, de nos jours il existe un enregistrement SPF particulier pour cet usage.

Vérifier les entrées SPF des autres utilisateurs

De nombreux domaines ont déjà leurs entrées SPF. Donc je vous encourage à utiliser cette information pour votre propre protection contre le spam et l'hameçonnage (en anglais phishing). Lisez la section suivante sur le greylisting (qui signifie « inscription sur liste grise ») pour apprendre comment utiliser le service tumgreyspf pour profiter à la fois de la puissance de SPF et du greylisting.

Le transfert de mail échoue avec SPF

Comme entrevu plus haut, SPF souffre d'un défaut de conception majeur. L'identification SPF échoue si quelqu'un transfert un mail vers un autre serveur. Le serveur de transfert ne figurant pas sur la liste de l'entrée SPF, le serveur de destination va (normalement) rejeter le mail. Les utilisateurs les moins techniquement qualifiés ne comprendront pas cette limitation. Du coup de nombreux administrateurs de serveurs mail ne prennent en compte la vérification SPF que pour la recherche de spam mais en fin de compte ne rejettent tout de même pas le mail. C'est à vous de voir. SPF combat efficacement l'usurpation d'identité pour de grands domaines comme PayPal, eBay, Amazon et d'autres grandes entreprises qui sont souvent la cible de tentatives d'hameçonnage. Dans certains cas ce sera juste un excès de prudence.

Vérification des signatures DKIM des mails entrants

DKIM a été inventé dans un but similaire à celui de SPF. Il fournit une authentification des mails pour permettre au serveur de réception de vérifier que le mail provient bien d'un domaine donné. SPF se contente de dire quelles IP sont autorisées à envoyer du courrier pour un domaine d'expéditeur donné. Mais DKIM fonctionne de façon plus fiable car il ajoute une signature cryptographique à chaque mail sortant. Pour vérifier qu'un mail est bien authentique un serveur de mail peut utiliser la signature du mail et la contrôler avec la clé publique du domaine de l'expéditeur qu'il peut obtenir via DNS. Cela vous semble trop compliqué ? En fait c'est plutôt simple si vous comprenez les bases de la cryptographie par clés-publiques. Avez-vous déjà utilisé PGP ? Alors vous savez que vous devez créer une paire de clés consistant en une clé privée que vous pouvez utiliser pour signer les mails et une clé publique que vous distribuez aux autres pour qu'ils chiffrent les mails qui vous sont destinés ou qu'ils puissent vérifier votre signature. DKIM utilise exactement cette technique. Le serveur mail d'envoi a une paire de clés pour chaque domaine. Quand il envoit un email il va utiliser la clé privée du domaine de l'expéditeur pour signer cryptographiquement le mail qui est sur le point d'être envoyé. La signature est ajoutée au courrier (comme un entête supplémentaire au mail) et le serveur destinataire pourra contrôler la signature dans l'entête du mail au moyen de la clé publique du domaine d'expédition pour déterminer si elle est valide.

Note du traducteur : Christoph Haas utilise dkim-filter qui a été retiré des dépôts officiels de Wheezy. Heureusement il existe une altrenative moderne qui est opendkim. J'ai donc ajouté un chapitre sur l'installation d'opendkim intégré à la méthode d'installation de Christoph Haas.

Ajouter la vérification des signatures DKIM des autres domaines est très simple. Il suffit d'installer le filtre logiciel DKIM :

apt-get install dkim-filter

En fait ce logiciel est ce qu'on appelle un milter. Les milters sont des filtres de mail (contraction de mail filters en anglais) qui ont été ajoutés en tant que programmes additonnels à l'ancien logiciel serveur de courrier électronique Sendmail. Les milters parlent un protocole particulier que le serveur Sendmail peut utiliser pour communiquer avec eux, et par chance Postfix sait lui aussi utiliser ce protocole et donc les milters. Dès la fin de l'installation de dkim-filter un processus est déjà lancé et tourne en arrière plan. Mais comme Postfix tourne dans une prison chroot dans /var/spool/postfix il ne peut utiliser le socket de communication du filtre DKIM à son emplacement par défaut qui est /var/run/dkim-filter/dkim-filter.sock. Vous pouvez modifier les permissions d'accès et faire en sorte que DKIM utilise un socket dans /var/spool/postfix à la place, mais je préfère lancer dkim-filter comme un service TCP plutôt que de lui faire utiliser un socket. Éditez votre fichier /etc/default/dkim-filter qui contient la configuration par défaut de DKIM et ajoutez-y :

SOCKET="inet:54321@localhost"

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 que Postfix puisse utiliser ce milter lancez ces commandes pour ajouter la bonne définition du milter à 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

Après cela Postfix va faire passer tous les mails (à la fois entrants et sortants) à travers votre filtre DKIM et vérifier les signatures DKIM (si il en trouve) des mails entrants. Il ne signe pas encore les mails sortants, cet aspect est traité dans le chapitre suivant.

A noter : vous pouvez décider de ce qui doit se passer si il y a un problème avec le filtre DKIM. Par défaut Postfix rejetera temporairement le mail jusqu'à ce que vous corrigiez le problème. C'est à vous de voir. Mais pour ma part je préfère simplement accepter le mail si il y a un problème avec le milter. Du coup j'ajoute :

postconf -e milter_default_action=accept

Pour en savoir plus sur le sujet consultez la documentation de Postfix sur les milters.

Configurer DKIM pour l'envoi de mails

L'idée principale de DKIM est de faire en sorte qu'un serveur de courrier signe automatiquement les mails sortants pour un domaine. Pour cela vous devez tout d'abord avoir une paire de clés cryptographiques. Heureusement vous n'avez pas besoin d'acheter un certificat car la publication de votre clé publique dans le DNS est suffisante. L'outil dont vous avez besoin est dkim-genkey qui n'a besoin que du nombre d'octets que doit avoir la clé et du nom de domaine. Vous pouvez optionnellement utiliser un sélecteur pour utiliser plusieurs clés. Par défaut le sélecteur est nommé default. Je vous suggère d'utiliser votre nom de domaine comme sélecteur ce qui nomera vos clés correctement de façon automatique.

Il est préférable de créer un répertoire spécifique pour ranger vos clés. Je garde les miennes dans /etc/postfix/dkim :

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

Créez alors la paire de clés :

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

Dans votre répertoire courant vous allez maintenant trouver deux fichiers :

1. example.org.private est la clé privée que le filtre DKIM utilisera pour signer tous les mails sortants ;
2. example.org.txt est la clé publique que vous êtes supposé ajouter à votre zone DNS.

Le fichier de configuration du milter DKIM est /etc/dkim-filter.conf. Le seul changement que vous devez y apporter est d'ajouter une ligne pour indiquer le fichier contenant la liste des clés. Par exemple :

KeyList     /etc/dkim-keys.conf

Créez maintenant le fichier /etc/dkim-keys.conf sur lequel vous venez de faire pointer la configuration de dkim-filter. Son contenu doit définir quelle clé utiliser pour chaque adresse d'expédition. Précisément la syntaxe, comme expliqué dans la page de manuel man dkim-filter.conf, est celle-ci :

sender-pattern:signing-domain:keypath

Si votre domaine est example.org vous devriez écrire :

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

Ajoutez une ligne par domaine d'expédition dont vous voulez signer les mails sortants.

ATTENTION AU PIÈGE SUIVANT : dkim-filter ajoute « .private » au chemin spécifié pour le fichier de clé. La ligne ci-dessus est donc correcte. N'utilisez pas /etc/postfix/dkim/example.org.private ou la signature échouera car il recherchera /etc/postfix/dkim/example.org.private.private.

Redémarrez votre milter DKIM :

/etc/init.d/dkim-filter restart

Maintenant les mails sortants devraient recevoir automatiquement une signature DKIM. Envoyez un mail vers un autre serveur de mail et vérifiez les entêtes de ce mail. Vous devriez voir un entête de 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ètre peut être trouvée sur la page wikipedia de DKIM (Ndt : il s'agit de la page en anglais, la page française étant beaucoup plus succinte) ou dans un format moins sympathique à lire dans la RFC 4871.

Cependant le destinataire ne peut dire si il s'agit d'une signature correcte, car il ne dispose pas de la clé publique qui lui permettrait de la vérifier. Éditez la zone DNS du domaine que vous voulez signer ajoutez-y simplement l'enregistrement TXT que dkim-genkey a créé pour vous dans /etc/postfix/dkim/example.org.txt. Sur mon serveur de test il 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 la zone DNS de votre domaine contient bien la bonne entrée en lançant une requête pour un enregistrement TXT avec votre domaine et le sélecteur que vous avez utilisé :

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

Cela devrait vous renvoyer votre clé publique :

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

Cette fois tous les mails sortants pour …@example.org auront une signature DKIM ajoutée automatiquement et les destinataires pourront la vérifier. Tous les serveurs utilisant les signatures DKIM peuvent maintenant vérifier la légitimité des emails provenant de votre domaine.

Je suppose que vous avez configuré le milter DKIM dans Postfix comme décrit ci-dessus. la configuration de smtpd_milters et non_smtpd_milters dans le fichier /etc/postfix/main.cf va maintenant permettre d'effectuer tant la vérification des signatures DKIM des mails entrants que la signature des mails sortants.

Greylisting

Une autre voie pour vous aider à réduire le nombre de spam reçu par votre serveur est l'utilisation des « listes grises » (greylisting). Les listes blanches (whitelisting) servent à indiquer qu'un certain type de mails doit être toujours accepté (avec un code de distribution 2.x.x). Les listes noires (blacklisting) à l'inverse bloquent toujours certains emails (avec un code de distribution 5.x.x). Les listes grises sont quelque chose entre les deux et vont temporairement refuser d'accepter un email pour quelques minutes. L'idée est de tromper les ordinateurs infestés de virus qui essayent de spammer votre serveur de mail. Les Viruses (ou plus exactement les spam worms (vers à spam)) essaient juste d'envoyer un mail une fois. Les vrais serveurs de courrier ont une file d'attente de mails sortants et quand ils reçoivent un message d'erreur temporaire ils essayent de le renvoyer plus tard. Si le serveur de mail ne nous a jamais encore envoyé de courrier alors le greylisting va lui envoyer un code d'erreur temporaire (code de distribution 4.x.x) qui indique à l'expéditeur de réessayer d'envoyer son message dans quelques minutes. Votre serveur prend note de l'IP du serveur distant et après une période définie (une valeur courante est 10 minutes) le blocage est levé et à la prochaine tentative le mail sera accepté. Le service de greylisting va également prendre note de cette IP dans son cache et les futurs envois passeront directement.

L'inconvénient évident est que les mails sont souvent retardés de plusieurs minutes, particulièrement si vous venez juste de commencer à utiliser le greylisting et que le cache de serveurs de confiance est vide. Il reste à voir si vos utilisateurs peuvent accepter ça. Suivant mon expérience le greylisting n'est plus aussi efficace de nos jours qu'il l'a été à ses débuts. Il semble que les logiciels malveillants essayent maintenant de délivrer le spam plusieurs fois. Mais c'est une mesure qui peut permettre de bloquer quelques spams.

Il existe plusieurs façons de mettre en place le greylisting Je le fais en utilisant le programme tumgreyspf. Commençons par l'installer :

apt-get install tumgreyspf

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

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

Vous devez également l'ajouter à votre variable smtpd_recipient_restrictions de votre fichier /etc/postfix/main.cf. Par 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 des exemples de filtrage. Ne vous contentez pas de les copier/coller. L'exemple n'est là que pour vous montrer un bon endroit pour placer cette règle de contrôle dans votre smtpd_recipient_restrictions.

Pour finir rechargez Postfix 

postfix reload

Pour personnaliser le comportement de tumgreyspf, vous pouvez modifer les fichiers dans /etc/tumgreyspf (la façon de faire est documentée dans le fichier /usr/share/doc/tumgreyspf/README.Debian).