Aller au contenu principal

GUIDE ULTIME : Configuration de votre serveur pour une délivrabilité d'e-mails fiable. PARTIE I : Pare-feu

· 10 minutes de lecture
Customer Care Engineer

email-server-linux-firewall-configuration-smtp-imap-setup-guide

info

Le pare-feu est un logiciel (ou un appareil matériel-logiciel) qui contrôle quelles connexions vers le serveur sont autorisées et lesquelles sont bloquées. Dans la grande majorité des distributions modernes de serveurs Linux, une forme de pare-feu est disponible dès l'installation.

La délivrabilité fiable des e-mails au destinataire dépend non seulement du serveur de messagerie lui-même, mais aussi de la configuration correcte des enregistrements DNS et du pare-feu. Si quelque chose ne va pas avec ces éléments, vos messages atterriront très probablement dans le dossier Spam, ou ne seront pas livrés du tout.

Cet article décrit les étapes clés qui vous permettront d'atteindre une délivrabilité de messages envoyés depuis votre serveur proche de 100%. Dans la partie 1, nous examinerons en détail les problèmes liés au pare-feu ; dans la partie 2, vous trouverez les instructions pour configurer les enregistrements DNS.

Les informations contenues dans cet article s'appliquent uniquement aux serveurs de messagerie fonctionnant sur des distributions Linux. Debian 12 et Rocky Linux 8.10 avec le panneau de contrôle FASTPANEL sont utilisés comme exemples.

Prérequis

Étape 1. Installer les outils de diagnostic

Pour vérifier les enregistrements et les ports, vous aurez besoin de :

  • dig - pour analyser les enregistrements DNS

  • lsof - pour vérifier l'état du serveur de messagerie

  • netcat - pour vérifier la disponibilité des ports

  • whois - pour vérifier le fournisseur DNS actuel

Installation sur Debian/Ubuntu :

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd lsof whois

CentOS/AlmaLinux/Rocky Linux :

sudo yum install -y bind-utils nmap-ncat lsof whois

Disponibilité des ports de messagerie

info

Un port est un identifiant numérique utilisé pour adresser différents services sur un serveur. Chaque service ou application écoute sur son propre port pour échanger des données sur le réseau (par exemple, HTTP utilise le port 80 et SMTP utilise le port 25).

Pour effectuer toutes les étapes suivantes, connectez-vous à votre serveur via SSH en utilisant les identifiants de l'utilisateur root ou utilisez sudo lors de l'exécution des commandes, comme indiqué dans les exemples. Vous pouvez apprendre comment vous connecter à un serveur via SSH dans notre article sur SSH.

Étape 2. Vérifier l'état du serveur de messagerie

Avant de vérifier si les ports sont joignables sur le réseau, assurez-vous d'abord que les serveurs de messagerie fonctionnent correctement. Les e-mails sortants sont généralement gérés par Exim ou Postfix, et les e-mails entrants par Dovecot.

Pour vérifier qu'ils sont en cours d'exécution, utilisez les commandes :

sudo lsof -i:25
sudo lsof -i:143

Si les services fonctionnent, vous obtiendrez une sortie similaire à la suivante :

Port 25 :

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
exim    839 exim    4u  IPv6 778199358      0t0  TCP *:smtp (LISTEN)
exim    839 exim    5u  IPv4 778199359      0t0  TCP *:smtp (LISTEN)

Si votre serveur utilise un autre serveur SMTP, par exemple Postfix, vous verrez son nom exact au lieu d'exim dans la première colonne. Si nécessaire, utilisez ce nom dans les commandes ultérieures.

Port 143 :

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dovecot 859 root   39u  IPv4 778204692      0t0  TCP *:imap (LISTEN)
dovecot 859 root   40u  IPv6 778204693      0t0  TCP *:imap (LISTEN)

Cela signifie que tout va bien et que vous pouvez passer à l'étape suivante.

Si les services de messagerie ne fonctionnent pas, vous obtiendrez une sortie vide :

~ sudo lsof -i:25
~
~ sudo lsof -i:143
~

Dans ce cas, quelque chose ne va pas et les services de messagerie ne sont pas disponibles. Vous pouvez essayer de les démarrer manuellement, puis vérifier leur état :

Debian/Ubuntu :

systemctl restart exim4 dovecot
systemctl status exim4
systemctl status dovecot

CentOS/AlmaLinux/Rocky Linux :

systemctl restart exim dovecot
systemctl status exim
systemctl status dovecot

En état de fonctionnement, le statut du service ressemblera à ceci :

Exim:

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:57 UTC; 57min ago
 Main PID: 839 (exim)
    Tasks: 1
   Memory: 11.0M
   CGroup: /system.slice/exim.service
           └─839 /usr/sbin/exim -bd -q1h

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Dovecot :

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:58 UTC; 58min ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
 Main PID: 859 (dovecot)
    Tasks: 5
   Memory: 9.5M
   CGroup: /system.slice/dovecot.service
           ├─ 859 /usr/sbin/dovecot -F
           ├─ 880 dovecot/anvil
           ├─ 881 dovecot/log
           ├─ 882 dovecot/config
           └─1729 dovecot/stats

Dans ce cas, tout va bien et vous pouvez passer à l'étape suivante.

Si quelque chose ne va pas avec les services, vous verrez une sortie similaire à ceci :

Exim :

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:38:44 UTC; 3s ago
  Process: 839 ExecStart=/usr/sbin/exim -bd -q${QUEUE} (code=exited, status=0/SUCCESS)
 Main PID: 839 (code=exited, status=0/SUCCESS)

Dovecot :

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:39:32 UTC; 3s ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
  Process: 2278 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
  Process: 859 ExecStart=/usr/sbin/dovecot -F (code=exited, status=0/SUCCESS)
 Main PID: 859 (code=exited, status=0/SUCCESS)

Il existe de nombreuses raisons possibles pour lesquelles les services pourraient être indisponibles (erreurs dans les fichiers de configuration, fichiers journaux supprimés accidentellement, manque d'espace disque sur le serveur, et bien plus encore). Ces aspects sont hors du cadre de cet article.

Si vous rencontrez ce problème et souhaitez l'investiguer vous-même, nous vous recommandons notre article sur l'utilisation du journal du système. Ou contactez l'équipe de support de votre fournisseur d'hébergement pour obtenir de l'aide. Chez kodu.cloud, nous travaillons 24h/24 et 7j/7 et répondons aux demandes en quelques minutes.

Étape 3. Vérifier la disponibilité des ports de messagerie depuis le réseau mondial

Pour que la messagerie fonctionne correctement, les ports TCP suivants doivent être accessibles sur le réseau :

  • 25, 465, 587 - pour l'envoi de courriels (SMTP)

  • 143, 993 - pour la réception de courriels (IMAP)

Vous pouvez vérifier leur disponibilité en utilisant netcat :

nc -vz 1.2.3.4 25

Remplacez 1.2.3.4 par l'adresse IP réelle de votre serveur.

Si le port est ouvert, vous obtiendrez la réponse suivante :

Debian/Ubuntu :

Connection to 1.2.3.4 25 port [tcp/smtp] succeeded!

CentOS/AlmaLinux/Rocky Linux :

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 1.2.3.4:25.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Si le port est fermé, la réponse sera la suivante :

Debian/Ubuntu :

nc: connect to 1.2.3.4 port 25 (tcp) failed: Connection refused

CentOS/AlmaLinux/Rocky Linux :

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.

Exécutez cette commande pour tous les ports listés au début de cette section. Si tous sont disponibles, passez à la deuxième partie de cet article. Sinon, passez à l'étape 4 pour résoudre le problème.

Étape 4. Ouverture d'accès (facultatif)

Le plus souvent, les serveurs utilisent iptables ou UFW comme pare-feu pour se protéger contre les connexions indésirables. Exécutez la commande :

sudo ufw status

Si vous recevez la réponse suivante :

ufw: command not found

cela signifie qu'iptables est utilisé. Si, cependant, la sortie commence par :

Status: active

Cela signifie que UFW est utilisé.

Accédez à la sous-section pertinente de cette étape en fonction du pare-feu utilisé.

attention

Il existe d'autres logiciels pour gérer le pare-feu du système sous Linux (nftables, firewalld, et autres). Ils ne seront pas abordés dans cet article afin de ne pas augmenter sa taille.

Iptables

attention

Dans cette section, tous les exemples s'appliquent uniquement à IPv4. Si votre serveur possède une adresse IPv6 et que vous souhaitez également que les ports de messagerie soient accessibles via IPv6, répétez en plus toutes les commandes en utilisant ip6tables au lieu de iptables.

Pour afficher toutes les règles actuelles, exécutez :

sudo iptables -L -v -n --line-numbers

La sortie peut varier en fonction de l'ensemble des règles ajoutées sur le serveur. Par défaut, il n'y a pas de règles, mais en fonction de la configuration de l'hébergement ou du système d'exploitation, une configuration peut déjà avoir été effectuée. Examinons deux cas principaux qui sont souvent rencontrés lors de la configuration d'un serveur de messagerie.

  1. Politique « Tout ce qui n'est pas interdit est autorisé » (politique ACCEPT)

Dans ce cas, le pare-feu, par défaut, autorise tout trafic jusqu'à ce qu'une règle le bloquant explicitement soit créée. Cette politique est généralement utilisée par défaut.

Voici un exemple d'ensemble de règles où les ports SSH et de messagerie sont bloqués :

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22
2        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

Dans cet exemple :

  • La politique ACCEPT définit le comportement par défaut : toutes les connexions sont autorisées sauf indication contraire.

  • La chaîne INPUT (connexions entrantes) : les nouvelles connexions vers le port 22 (SSH) et vers tous les ports de messagerie standard (SMTP : 25, 465, 587 ; IMAP : 143 ; IMAPS : 993) sont bloquées.

  • La chaîne OUTPUT (connexions sortantes) : les paquets sortants vers les mêmes ports sont bloqués.

Le numéro de règle est indiqué au début de la ligne (num). Si vous devez supprimer, par exemple, la règle qui bloque les ports de messagerie dans la chaîne INPUT (règle numéro 2), la commande sera :

sudo iptables -D INPUT 2

Ici :

  • -D - est la commande pour supprimer une règle.

  • INPUT est la chaîne d'où la règle est supprimée (dans ce cas, le trafic entrant).

  • 2 est le numéro de ligne où se trouve la règle que vous souhaitez supprimer.

De même, pour supprimer le blocage des ports sortants de cet exemple, vous devez exécuter :

sudo iptables -D OUTPUT 1
attention

Les numéros de ligne dans la sortie de iptables -L -v -n --line-numbers peuvent changer si vous ajoutez ou supprimez d'autres règles. Par conséquent, si vous ajoutez de nouvelles règles, les numéros de ligne peuvent être décalés. Pour éviter les erreurs, vérifiez toujours les numéros de ligne actuels avant de supprimer une règle.

Après cela, pour vous assurer que tout est correct, exécutez à nouveau la commande :

iptables -L -v -n --line-numbers

La sortie ne devrait pas contenir de règles bloquant le fonctionnement des ports de messagerie :

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Si les règles sont toujours présentes, vérifiez l'exactitude des commandes que vous avez entrées et des numéros de ligne.

Après avoir modifié les règles du pare-feu, assurez-vous de sauvegarder les modifications, sinon elles seront perdues après un redémarrage. Pour enregistrer les règles iptables actuelles, exécutez :

Debian/Ubuntu :

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux :

iptables-save > /etc/sysconfig/iptables

Après cela, testez à nouveau la disponibilité des ports de messagerie, comme décrit à l'étape 3. S'ils sont toujours indisponibles, passez à l'étape 5. Si tout est en ordre, passez à la deuxième partie de cet article.

  1. Politique « Bloquer tout ce qui n'est pas explicitement autorisé » (politique DROP)

Ce type de configuration est beaucoup plus strict. Tous les ports et protocoles sont bloqués par défaut, et seules des règles d'autorisation explicites pour des ports spécifiques laissent passer le trafic. C'est une approche plus sécurisée et recommandée pour les serveurs, surtout si vous souhaitez minimiser les risques.

Voici un exemple de règles pour une telle configuration :

Chain INPUT (policy DROP 306 packets, 17962 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       92 12474 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2      466 32947 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 197 packets, 29192 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       44 10332 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Dans cet exemple :

  • La chaîne INPUT (connexions entrantes) : la politique est DROP, c'est-à-dire que tous les paquets sont bloqués par défaut, à l'exception de ceux pour lesquels il existe des règles d'autorisation.

Règle 1 : ACCEPT state RELATED,ESTABLISHED - autorise les paquets entrants qui sont liés à des connexions existantes ou qui leur sont associés. Ceci est important pour que le serveur reçoive correctement les réponses aux connexions sortantes (par exemple, requêtes SSH, e-mail, DNS). Règle 2 : ACCEPT tcp dpt:22 - autorise les nouvelles connexions entrantes sur le port 22 (SSH).

  • La chaîne OUTPUT (connexions sortantes) : la politique est DROP, c'est-à-dire que tous les paquets sortants sont bloqués par défaut.

Règle 1 : ACCEPT state RELATED,ESTABLISHED - autorise les paquets sortants qui sont liés à des connexions existantes. Cela permet au serveur de répondre aux requêtes du client (par exemple, connexions SSH, e-mail) et de maintenir une connexion stable.

Nous constatons donc qu'il n'y a pas de règles d'autorisation pour les ports de messagerie. Pour les ajouter, exécutez les commandes suivantes :

sudo iptables -A INPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT

Après cela, enregistrez les règles :

Debian/Ubuntu :

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux :

iptables-save > /etc/sysconfig/iptables

Testez ensuite à nouveau la disponibilité des ports de messagerie, comme décrit à l'étape 3. S'ils sont toujours indisponibles, passez à l'étape 5. Si tout est en ordre, passez à la deuxième partie de cet article.

UFW (Uncomplicated Firewall)

Sur certains serveurs, UFW est utilisé à la place d'iptables - une interface simplifiée pour configurer le pare-feu. Il convient à une configuration de serveur de messagerie basique et se trouve souvent sur Ubuntu et Debian.

Pour voir si UFW est activé et quelles règles sont actives, exécutez :

sudo ufw status verbose

Exemple de sortie :

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

Ici :

  • Default: deny (incoming) - par défaut, toutes les connexions entrantes sont bloquées.

  • Default: allow (outgoing) - par défaut, toutes les connexions sortantes sont autorisées.

Pour que le serveur de messagerie fonctionne correctement, vous devez ouvrir les ports standard. Exécutez les commandes suivantes en séquence :

sudo ufw allow 25/tcp
sudo ufw allow 465/tcp
sudo ufw allow 587/tcp
sudo ufw allow 143/tcp
sudo ufw allow 993/tcp

Si vous avez également des restrictions sortantes, vous devez autoriser les ports SMTP pour les e-mails sortants :

sudo ufw allow out 25/tcp
sudo ufw allow out 465/tcp
sudo ufw allow out 587/tcp

Après avoir ajouté les règles, vous pouvez les vérifier à nouveau :

sudo ufw status numbered

Vous verrez une liste de règles avec des numéros. Si vous devez supprimer une règle, utilisez le numéro de la sortie :

sudo ufw delete 3

Dans UFW, les règles sont sauvegardées automatiquement et resteront en vigueur après un redémarrage.

Testez ensuite à nouveau la disponibilité des ports de messagerie, comme décrit à l'étape 3. S'ils sont toujours indisponibles, passez à l'étape 5. Si tout est en ordre, passez à la deuxième partie de cet article.

Étape 5. Le pare-feu est configuré correctement, mais les ports de messagerie sont toujours indisponibles (facultatif)

Un tel comportement indique que les ports de messagerie sont bloqués non pas au niveau de votre serveur, mais sur l'équipement de votre fournisseur d'hébergement. Dans ce cas, créez un ticket de support et demandez-leur de débloquer ces ports pour votre serveur. Si cela n'est pas possible, la seule solution sera de changer de fournisseur d'hébergement.

Chez kodu.cloud, nous ne restreignons en aucun cas le fonctionnement des ports de messagerie. Nos règles interdisent les envois en masse, mais pour les clients de bonne foi, la messagerie est disponible dans son intégralité. Vous n'avez même pas besoin de configurer un serveur de messagerie, car tous nos clients bénéficient d'un accès gratuit au panneau de contrôle FASTPANEL avec une licence étendue. Commandez un serveur avec le panneau de contrôle et commencez à utiliser la messagerie sur votre propre domaine en quelques minutes seulement.

Les étapes suivantes pour une configuration correcte des enregistrements DNS seront abordées dans la deuxième partie de cet article.