Traduction de la page : https://workaround.org/ispmail/stretch/big-picture

Le serveur de mail que vous vous apprêtez à installer utilise plusieurs composants logiciels. Laissez moi vous expliquer brièvement l'utilité de chacun de ces programmes :

• Debian « Stretch » Le système d'exploitation ;
• Postfix qui reçoit les mails arrivant depuis Internet et relaye les mails vers les autres serveurs ;
• rspamd qui contrôle chaque mail entrant pour savoir si c'est un spam ou s'il contient des logiciels malveillants et le cas échéant soit le rejeter purement et simplement soit le placer dans le répertoire « Junk » de l'utilisateur ;
• Dovecot qui enregistre les mails sur votre disque dur, applique des filtres et permet à vos utilisateurs de récupérer leur courrier par l'un des deux protocoles POP3 ou IMAP ;
• Roundcube qui est une interface web (webmail) qui permet à vos utilisateurs de lire leurs emails en utilisant un navigateur Internet, de définir leurs règles de filtrage et de changer leur mot de passe ;
• MariaDB qui est une base de données qui enregistre les informations à propos de vos domaines, vos alias de mail et vos comptes email ;

Que se passe-t-il quand quelqu'un vous envoit un email ?

Supposons que vous soyez responsable du domaine de mail example.org et que quelqu'un sur Internet envoit un email à john@example.org. Voici ce qui arrive étape par étape :

1. Le serveur de mail distant interroge le serveur DNS le plus proche pour savoir qui est le MX (Mail eXchanger) du serveur du domaine du destinataire. Le domaine dans notre cas est example.org donc il demande quel est l'enregistrement MX du domaine example.org. Le serveur DNS réponds que le nom du serveur responsable du domaine du destinataire est  mx15.example.org. Dans le cas où il n'existe pas d'enregistrement MX il essayera d'utiliser l'enregistrement A comme solution de replis. Le DNS peut répondre avec une liste de plusieurs serveurs ayant chacun une priorité différente. Le serveur distant utilisera si nécessaire toutes ces entrées dans l'ordre des priorités. Ce mécanisme permet une répartition de charge ou l'existence de serveurs de mail de replis pour les grands réseaux.
2. Le serveur de mail interroge à nouveau le serveur DNS pour obtenir l'adresse IP du serveur de courrier mx15.example.org. Le serveur DNS répond en donnant cette adresse.
3. Maintenant le serveur de mail établit une connexion TCP sur le port 25 (qui est par convention utilisé pour SMTP le simple mail transport protocol) sur cette IP et contacte le démon Postfix sur votre serveur de mail. Il envoit à Postfix les adresses email de l'expéditeur et du destinataire et le contenu du mail. La connexion SMTP reste ouverte pendant l'étape suivante (la vérification du mail avec rspamd pour savoir si ce n'est pas un spam ou un logiciel malveillant). Si rspamd est certain que le mail est soit un spam soit un logiciel malveillant, alors la connexion SMTP qui est restée ouverte est fermée avec un message d'erreur approprié « 5.7.1 Spam message rejected ». rspamd peut également autoriser Postfix à accepter le message et le marquer comme étant du spam. Ou il peut demander à Postfix de mettre en liste grise le serveur d'expédition (c'est à dire lui demander de réessayer l'envoi dans quelques minutes).
4. Postfix contacte le processus rspamd et lui transmet le mail ainsi que l'adresse IP de l'expéditeur. rspamd effectue un grand nombre de vérifications et calcule un score numérique. Un score faible signifie que le mail est probablement légitime. Un haut score signifie qu'il y a de fortes chances pour que ce soit un spam ou qu'il contienne un logiciel malveillant. Suivant la manière dont rspamd a été configuré il demande à Postfix d'accepter le mail, de demander un délai de renvoit (liste grise) ou de rejeter le mail avec un message d'erreur.
5. Si rspamd a accepté le mail, alors Postfix va faire de nouvelles vérifications, appellées « restrictions ». Est-ce que votre serveur est responsable du domaine du destinataire ? Est-ce que cette adresse existe dans ce domaine ? Si le destinataire n'existe pas, alors le mail est rejeté, encore pendant le dialogue SMTP.
6. Maintenant Postfix a finalement accepté le mail et fermé la connexion SMTP avec le serveur expéditeur. Il transmet alors le mail au processus Dovecot sur votre serveur. Cette communication utilise LMTP (une version allégée de SMTP). Postfix retire alors la mail de sa file d'attente.
7. Dovecot vérifie si le destinataire a défini des règles sieve. Par exemple : « if the header contains ‘List-Id: rspamd-user’ then ‘move to folder mailinglists/rspamd-user’ » (soit si l'entête contient 'List-Id: rspamd-user' alors déplacez le mail dans le répertoire 'mailinglists/rspamd-user'). En plus des règles sieve définies par l'utilisateur il exécute les règles sieve globales. Nous les utilisons pour déplacer les emails que rspamd a marqués comme spam dans un répertoire « Junk » séparé.
8. Dovecot sauve le mail dans un fichier situé dans un dossier de l'utilisateur. Dans cet exemple : /var/vmail/example.com/john/Maildir/…

Pffff, ça fait un tas d'informations. N'essayez pas de vous rappeler de tout. Revenez juste à ces explications si vous vous sentez perdu entre les différents composants logiciels par la suite. Plus vous avancerez dans le guide, mieux vous comprendrez.

Il se passe un tas de choses quand vos utilisateurs reçoivent un mail. La situation suivante que je voudrais expliquer est…

Que se passe-t-il quand un utilisateur relève son courrier en utilisant IMAP/POP3 ?

Ce processus est nettement plus simple. Il ressemble à ça :

1. L'utilisateur a généralement un client de messagerie (dont le nom anglais est « mail user agent ») qui sait communiquer en utilisant les protocoles POP3 ou IMAP pour relever les mails sur le serveur. Il existe des tonnes de clients de mail disponibles. Je préfère Thunderbird ou Evolution sur Linux par exemple. Le client de mail se connecte au port POP3 (TCP 110) ou port IMAP (TCP 143) et envoit la commande STARTTLS pour initier une connexion chiffrée et envoyer le nom de l'utilisateur (qui est dans notre cas l'adresse mail) et son mot de passe. Si possible les utilisateurs devraient utiliser IMAP qui laisse toujours les mails sur le serveur et qui de plus supporte les dossiers multiples. POP3 est très limité et n'est plus guère utilisé de nos jours.
2. Dovecot effectue une requête sur la base de données MariaDB et vérifie que le nom d'utilisateur et le mot de passe envoyés correspondent bien à un utilisateur connu. Le mot de passe n'est pas enregistré en clair dans la base de données. Dovecot utilise le hachage avec salage des mots de passe (en anglais « salted hashes ») qui permettent de vérifier un mot de passe, mais pas de le rendre lisible. C'est une façon moderne et sûre de conserver des mots de passe. Si le mot de passe n'est pas bon, alors Dovecot refusera la connexion.
3. Nous utilisons un schéma simple pour organiser la façon dont les mails sont enregistrés sur le disque. Le nom d'utilisateur pour se connecter est en fait l'adresse mail. Donc si un utilisateur s'appelle jane@examle.com alors Dovecot va rechercher ses fichiers de mail dans /var/vmail/example.org/jane/Maildir/… et renvoyer à l'utilisateur les mails demandés.

Étonnamment beaucoup d'utilisateurs (particulièrement les moins ferrus de technologie) n'aiment pas installer et configurer un client de messagerie. Ils préfèrent lire leurs mails depuis leur navigateur. Pas de problème, c'est pour cela que nous offrons une interface webmail.

Que se passe-t-il quand un utilisateur lit ses mails depuis le web mail ?

Le logiciel Roundcube qui fournit l'interface web mail est simplement un logiciel écrit en PHP qui sert de passerelle entre des pages HTML et un client IMAP incorporé. Il parle HTML à l'utilisateur et donc il peut fonctionner dans un navigateur. Et il parle IMAP avec Dovecot pour récupérer les mails. De cette façon il imite un client de messagerie.

1. Les utilisateurs saisissent dans leur navigateur l'URL de l'interface web mail. Le serveur web Apache reçoit la connexion et lance les scripts PHP de Roundcube. Roundcube affiche un formulaire d'identification. L'utilisateur entre son nom d'utilisateur (adresse email) et son mot de passe et envoit ces données en validant le formulaire.
2. Roundcube se connecte à Dovecot en utilisant IMAP et lui transmet le nom d'utilisateur et le mot de passe pour qu'il vérifie si ils sont valides.
3. Dovecot traite cette connexion comme une connexion d'un client de messagerie. Il interroge la base de données MariaDB pour vérifier le nom d'utilisateur et le mot de passe.
4. Si l'identification est vérifiée, Dovecot relève les fichiers de mail sur le disque et les envoit via IMAP à Roundcube. Roundcube alors formate les emails en HTML et l'utilisateur peut les lire.

Vous voyez donc que l'accès par web mail fonctionne aussi en IMAP. Cependant l'utilisateur ne s'en rend pas compte.

Et le dernier scénario dont je voudrais parler est…

Qu'arrive-t-il si un utilisateur veut envoyer un mail via Internet ?

Bien entendu vos utilisateurs veulent pouvoir envoyer des mail vers d'autres utilisateurs sur Internet. Mais ils ne peuvent envoyer de mails directement aux serveurs mail de destination. La première raison est que leur client de messagerie ne connaît pas le serveur responsable du domaine du destinataire, cette fonctionnalité n'étant tout bonnement pas incluse dans leur client de messagerie. Et la seconde raison est qu'il est plus que probable que l'utilisateur dispose d'une adresse IP dynamique qui est bloquée par quasiment tous les serveurs de mail car elle ont tendance à être abusivement utilisées par des PC sous Wind*ws infectés qui envoient du spam. Donc la seule façon correcte d'envoyer un mail sur Internet est de le faire par l'intermédiaire de votre serveur de mail. C'est ce que l'on appelle « relayage » car votre serveur de mail agit comme un relais. Dans cet exemple votre utilisateur veut envoyer un mail à fred@example.net.

1. L'utilisateur écrit son mail dans son client de messagerie et clique sur le bouton Envoyer. Le client de messagerie établit une connexion SMTP avec votre Postfix. Pour s'assurer que l'utilisateur est autorisé à envoyer des mails via votre système, celui-ci demande un nom d'utilisateur et un mot de passe joints au mail. Cette information est envoyée sous forme chiffrée.
2. Avant d'accepter le mail, Postfix commence par vérifier le nom d'utilisateur et le mot de passe. Postfix a la capacité de parler avec une base SQL, mais ses capacités sont étonnament limitées et compliquées. Pour simplifier le processus il interroge Dovecot qui sait déjà comment réaliser l'identification d'un utilisateur.
3. Dovecot envoit une requête à MySQL pour vérifier si le nom d'utilisateur et le mot de passe (son hachage) sont corrects et envoit le résultat à Postfix.
4. Postfix sait maintenant qu'il est autorisé à envoyer le mail pour le compte de l'utilisateur. Il dit à l'utilisateur qu'il a accepté le mail. Le mail est placé dans la file d'attente de Postfix en attente de son traitement. Postfix va maintenant interroger le DNS (serveur de nom) le plus proche pour déterminer quel est le serveur de mail responsable du domaine du destinataire. Comme le destinataire a une adresse en …@example.com il va demander l'enregistrement MX du domaine « example.com” » et ensuite va demander son adresse IP.
5. Postfix sait maintenant à quel serveur envoyer le mail. Il ouvre donc une connexion SMTP avec lui et envoit le mail.