1. Bug Report

Descriptif du bug

Lors de l'envoi d'un mail via notre serveur mail, la connexion pour la réception des mails fonctionne correctement sur le port 993, mais l'envoi génère une erreur. Le message d'erreur exact (Thunderbird) est :

Le résultat attendu est que l'envoi de mails fonctionne sans erreur. Le résultat obtenu est une erreur qui empêche l'envoi des mails, même si la réception semble se dérouler normalement.

Description du système

• Infrastructure impliquée :
  Un serveur mail configuré en Docker pour utiliser les ports 25, 465, 587 et 993.

• Logiciels utilisés :

  • Serveur mail : Docker Mailserver (latest : 15.0.2)
  • Client mail : Thunderbird 137.0.1 (provenance du message d'erreur)
  • Système d'exploitation : Debian 12.10
  • Version de Docker : Docker version 28.0.1

Le client utilise le port 993 pour la réception des mails via IMAP.

• Infrastructure réseau :

• Configuration utilisée :
  Pour accéder à la configuration, veuillez consulter ce lien.

Reproduction

Sur un VPS, déployez la configuration disponible ici : configuration.

Dès le lancement, connectez-vous et essayez d'envoyer un mail depuis une adresse de votre domaine, puis envoyez un mail depuis un service externe vers votre domaine.
Créez ensuite votre premier utilisateur comme recommandé dans la documentation de notre conteneur Mailserver.
Vous atteignez alors le même état que celui du service mail actuellement non fonctionnel.

2. Analyse du problème

Symptôme 1 : Réception des mails fonctionnelle via IMAP

Commande / Outil : Connexion IMAP via Thunderbird, depuis un poste client (machine locale) vers le serveur mail distant (port 993).

Résultat obtenu : Les mails sont bien reçus dans la boîte de réception, sans message d'erreur.

Conclusion :

• La configuration IMAP est fonctionnelle.
• Le port 993 est ouvert et accessible.
• L’authentification IMAP est correcte.
• Le serveur mail reçoit bien les connexions entrantes pour la consultation des mails.

---

Symptôme 2 : Erreur lors de l'envoi des mails

Commande / Outil : Envoi de mail via Thunderbird, depuis le même poste client, en utilisant les ports SMTP 465/587.

Résultat obtenu :
Message d'erreur affiché dans Thunderbird (voir capture ci-dessous) :

Conclusion :

• L’envoi de mails échoue, ce qui laisse penser à :
  • Une mauvaise configuration SMTP (port, TLS, authentification),
  • Un port SMTP bloqué (465 ou 587),
  • Un service SMTP non fonctionnel sur le conteneur.

---

Symptôme 3 : Vérification des traces Wireshark

Outil :
Trace Wireshark d’un envoi de mail via Thunderbird.

Résultat obtenu :

Plusieurs envois depuis mon client, mais aucune réception.

Conclusion :

• La connexion ne parvient jamais à destination.
• Il semble que la communication soit bloquée avant d'atteindre le serveur, probablement en raison d'un filtrage ou d'un blocage par un pare-feu (ou un autre dispositif réseau).
• Le pare-feu du serveur ou un autre dispositif réseau pourrait être configuré pour refuser les connexions sur ce port (587), ce qui explique l'absence de réponse du serveur.

---

Symptôme 4 : Vérification de l'ouverture des ports du serveur mail

Commande :

sudo ss -tuln | grep -E ':25|:465|:587|:993'

(exécutée sur le serveur hébergeant le conteneur Docker Mailserver)

Résultat obtenu :

Conclusion :

• Les ports 25, 465, 587 et 993 sont bien listés comme "LISTEN".
• Les ports sont ouverts au niveau du système.
• Le conteneur expose bien les ports nécessaires.
• Reste à vérifier si ces ports sont exposés vers l’extérieur ou si un pare-feu/DNS empêche la communication.

---

Symptôme 5 : Test d'un échange de mail en local

• Commande / Outil :
  Utilisation de swaks depuis le serveur lui-même pour tester l’envoi d’un mail de [email protected] vers [email protected].

swaks --to [email protected] \
      --from [email protected] \
      --server localhost \
      --auth LOGIN \
      --auth-user [email protected] \
      --auth-password yoygonnanevernowmypsswd \
      --tls

• Résultat obtenu :
  

• Conclusion :

  • Le serveur SMTP accepte et traite correctement les mails envoyés entre utilisateurs internes du domaine.
  • Cela signifie que :
    • Le service postfix est opérationnel.
    • L’authentification SMTP fonctionne.
    • La remise locale des mails est fonctionnelle.
  • Ce test isole donc le problème comme étant lié à l'envoi vers l'extérieur, et non au fonctionnement de base du serveur mail.

---

Symptôme 6 : Test de connectivité SMTP depuis le client

Commande (test depuis la machine cliente) :

telnet l2-6.ephec-ti.be 587

Résultat obtenu :

Conclusion :

• Le port 587 semble être accessible depuis l'extérieur.
• La connexion TCP s’établit, donc la couche réseau ne bloque pas la connexion.
• Cela peut indiquer :
  • que le pare-feu n’applique pas la règle comme prévu (ex. iptables surchargé par Docker, règle dans la mauvaise chaîne, mauvaise interface, etc.),
  • ou que la règle est appliquée après l’établissement TCP, ce qui n’empêche pas le handshake mais coupe la session ensuite (hypothèse plus rare).
• Cependant, l’envoi de mails depuis Thunderbird échoue : → Cela suggère que même si la connexion TCP est ouverte, le flux SMTP est ensuite rejeté, interrompu, ou échoue à cause d'un autre mécanisme (authentification, STARTTLS).
  → Cependant, nous avons déjà établi que le fonctionnement du serveur mail n'est pas remis en cause.

Voici un symptôme où les ports sont bloqués, sauf le port 993 pour IMAP, ce qui indique un problème de pare-feu mal configuré.

---

Symptôme 7 : Vérification de la configuration du pare-feu

• Commande / Outil :
  Utilisation de ufw pour vérifier les règles du pare-feu.

  Vérification avec ufw :

  sudo ufw status
  

• Résultat obtenu :
  

• Conclusion :

  • Le port 993 est correctement ouvert pour IMAP, ce qui permet les connexions de réception de mails.
  • Cependant, les ports 587 (SMTP) et 465 (SMTP sécurisé) ne sont pas en ALLOW, ce qui empêche l'envoi de mails depuis un client.
  • Cela indique une erreur de configuration du pare-feu, où seulement le port IMAP est autorisé, mais les ports nécessaires pour l'envoi de mails ne sont pas ouverts.
  • Action nécessaire : Ouvrir les ports 587 et 465 dans les règles du pare-feu pour permettre l'envoi des mails.

3. Explication du problème

Le bug en lui-même :

L'envoi des emails via le serveur SMTP ne fonctionnait pas. Les mails reçus étaient accessibles, mais les messages n'atteignaient pas le destinataire (externe au serveur). Après une investigation, il s'est avéré qu'un blocage du pare-feu sur les ports 25, 465, 587 empêchait l'application de se connecter au serveur de messagerie.

L'explication :

Le pare-feu de la machine serveur bloquait les connexions entrantes/sortantes sur les ports 25, 465, 587, qui sont utilisés pour l'envoi de mails. En raison de ce blocage, toutes les tentatives d'envoi de mails échouaient, car l'application ne parvenait pas à établir une connexion avec le serveur de messagerie. Cela a entraîné des erreurs de connexion, et les messages sont restés en file d'attente sans être envoyés. Le problème a été résolu en ouvrant les ports 25, 465, 587 dans les règles du pare-feu pour permettre les connexions entrantes/sortantes. Lors de mes tests avec telnet, la connexion était établie avec la machine cible. Cela indique que le handshake initial (l'établissement de la connexion) se déroulait correctement. Cependant, il semble que ce soit après cette phase que le pare-feu intervenait et bloquait la communication, probablement au niveau des échanges ultérieurs de données, une fois la connexion établie. Cela suggère que le pare-feu accepte la connexion initiale mais empêche les échanges de données après le handshake, ce qui peut être dû à une règle de filtrage sur les ports spécifiques.

4. Correction du bug

Étape 1 : Autoriser les ports nécessaires

Ouvre les ports nécessaires pour l'envoi de mails via SMTP. Les ports sont le 25, le 465 (pour SMTPS) et le 587 (pour SMTP avec STARTTLS). J’utilise les commandes suivantes :

sudo ufw allow 25
sudo ufw allow 465
sudo ufw allow 587

Étape 2 : Recharger les règles de UFW

Après avoir ajouté les règles pour autoriser les ports, recharge UFW pour appliquer les modifications :

sudo ufw reload

Cela permettra au pare-feu de prendre en compte les nouveaux changements et d’ouvrir les ports nécessaires à l’envoi des e-mails.

5. Validation

Afin de valider que le bug soit résolu, nous allons suivre une procédure reprenant les méthodes utilisées lors de l’analyse.

Wireshark

Nous analysons la trace lors de l’envoi d’un mail depuis le client :

Et nous voyons bien la réponse "Server Hello", indiquant que le serveur répond positivement à la connexion, ainsi que la suite d’échanges entre le client et le serveur par la suite.

Swaks

Nous allons aussi tenter l’envoi d’un mail depuis le client en utilisant la commande suivante :

swaks --to [email protected] \
      --from [email protected] \
      --server mail.l2-6.ephec-ti.be \
      --auth LOGIN \
      --auth-user [email protected] \
      --auth-password apasswordyougonnaneverknowagain \
      --tls \
      --port 587

Le résultat obtenu :

Et on voit que l’échange fonctionne. Le mail arrive bien à destination.

Thunderbird

Maintenant, on peut réessayer depuis le client.

Et vérifier sur la boîte mail externe.

LOGS

On peut aussi voir que la connexion est affichée dans les logs (ce qui n’était pas le cas plus tôt, étant donné que le conteneur ne recevait aucune connexion).

Et nous voyons maintenant que tout fonctionne.
La procédure de validation nous a permis de valider le fonctionnement de l’envoi des mails de notre système.