Journal Architecture locale de réception, envoi et filtrage de courriel

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
17
5
jan.
2020

’lut nal,

Aujourd’hui je vais te parler d’architecture locale pour assurer la réception, le filtrage, la délivrance et l’envoi des courriels des utilisateurs du réseau local. Dans un billet précédent, j’avais évoqué l’installation d’un serveur webmail basé sur Roundcube mail. L’intérêt de la manip est de pouvoir stocker ses courriels sur son serveur perso et de pouvoir y accéder d’un poste du réseau local mais également d’Internet à partir d’un téléphone mobile sous Android (ou autres) où qu’on soit. Cela présente le grand avantage d’être indépendant d’un GAFAM qui n’aura aucun scrupule à analyser les courriels pour en tirer un quelconque profit. Dans le présent billet, je vais aller plus loin en présentant l’architecture globale dans laquelle s’insère ce webmail.

L’idée générale est que mon serveur récupère les courriels sur des serveurs POP ou IMAP sur Internet des utilisateurs du réseau local, puis les passe au travers de filtres anti‑spam et antivirus avant de les délivrer à un serveur de courriel local. Ils peuvent être ensuite consultés via un client lourd du réseau local comme Thunberdird, ou d’un navigateur via le webmail du réseau local ou d’Internet sur un mobile. Pour l’envoi, les courriels ne partent pas directement vers un serveur SMTP sur Internet (généralement celui du fournisseur d’accès) mais passent d’abord par le serveur de courriel local avec sa batterie anti‑spam et antivirus.

Commençons par un petit schéma pour illustrer le tout :

Architecture de la messagerie électronique

Cette architecture s’appuie sur plusieurs outils :

  • Fetchmail (MRA — mail retrieval agent) permet de récupérer les courriels des utilisateurs du réseau local sur des serveurs POP ou IMAP accessibles sur Internet ;
  • sendmail (MTA — mail transport agent), serveur SMTP qui permet de gérer localement la réception des courriels et d’appliquer certains filtres anti‑spam et antivirus en se basant sur SpamAssassin et ClamAV ;
  • procmail (MDA — mail delivery agent) permet de délivrer les courriels et les distribuer suivant leurs destinataires, il peut également appliquer d’autres filtres ;
  • le serveur IMAP basé sur Dovecot permet de rendre accessible aux lecteurs de courriel (MUA — Mail User Agent) du réseau local les messages qui sont arrivés ;
  • le serveur webmail basé sur Roundcube mail permet de gérer les courriels via un navigateur, y compris d’un téléphone mobile via Internet ; pour cela, il faudra rendre son serveur Web visible d’Internet, tout l’intérêt de la manip est de ne rendre accessible d’Internet que le serveur HTTP, il n’est pas nécessaire d’ouvrir les ports du serveur IMAP ou SMTP.

Pendant longtemps j’ai utilisé un serveur POP local, j’y accédais via Thunderbird et pour que les courriels soient accessibles sur tous les postes du réseau local, le répertoire .thunderbird dans lequel sont stockés les courriels était partagé par NFS. Inconvénient de la méthode, les courriels n’étaient accessibles que du réseau local et d’un client lourd. Je suis passé au serveur IMAP pour pouvoir installer un webmail car il permet de pouvoir gérer une arborescence de dossiers de messages. En effet, sous Thunderbird, j’avais initialement classé mes messages dans des dossiers et sous‑dossiers, et seul IMAP permet de retrouver la même arborescence avec le webmail à partir d’un navigateur ou d’un mobile. Pour ce faire, j’ai dû migrer le format de stockage de mes courriels de mbox (en gros les messages d’un dossier sont dans un fichier unique) vers Maildir (un courriel est un fichier et un dossier est un répertoire).

Cette architecture présente plusieurs avantages :

  • indépendance pour le stockage de ses courriels, comme évoqué précédemment ;
  • accès aux courriels en multi‐plate‑forme et multi‑support ;
  • performance du taux de filtrage des indésirables (spams) en gardant la gestion du filtrage sans avoir à compter sur celle de son fournisseur d’accès (ou de messagerie) généralement bien moins performante et souple.

Néanmoins, cette architecture peut paraître particulièrement lourdingue tout en se basant sur des outils qu’on peut considérer comme antédiluviens, comme sendmail, voire totalement obsolètes, comme procmail, qui est en état de mort cérébrale. Certes, certains disent que tant qu’on a pas cherché à configurer sendmail, on n’est pas un vrai administrateur système… Mais disons que j’ai commencé à la bâtir il y a maintenant plus de vingt ans sur mon réseau local à l’époque où sendmail était, de loin, la référence. Et par paresse et manque de temps, je n’ai pas cherché à la faire évoluer significativement ; d’autant qu’elle me donne encore aujourd’hui toute satisfaction.

J’ai toutefois conscience qu’il existe maintenant des outils bien plus simples à administrer comme Postfix ou d’autres outils de filtrage de courriels basés sur le langage Sieve. Aussi, vous qui me lisez, j’aurais souhaité avoir votre avis et vos idées sur le sujet, histoire de mettre un coup de neuf à mon architecture et savoir si ça en vaut la peine.

Sinon pour aller plus loin :

  • # Solution docker

    Posté par  . Évalué à 6.

    J'ai dû installer ces outils manuellement il y a déjà bien longtemps de ça, mais abandonné depuis car trop compliqué à maintenir…
    Après des années chez les GAFAMs je suis revenu sur une solution auto hébergée pour mon mail pro : Mailcow qui a un comme gros avantage de proposer une solution facile à installer et pas trop compliquée à maintenir. Ça fait maintenant 6 mois que je suis dessus et je ne suis pas déçu du résultat.

  • # « Simple à administrer »

    Posté par  . Évalué à 4. 

    > postconf -d | wc -l
1038

    Voilà. Et il y a plein de paramètres dynamiques. J'utilise postfix, j'en suis très content, mais ce n'est pas simple.

    OpenSMTPD est bien plus simple. Il a des réglages par défaut normaux (même si postfix n'est pas trop mal), et une configuration humainement lisible. Par contre, pour l'instant, il est limité. Par exemple, il ne gère pas SMTPUTF8.

  • # DKIM, SPF et chiffrement des protocoles POP, IMAP et SMTP

    Posté par  . Évalué à 5.

    Quelques idées d’amélioration de ton infra de messagerie :

    • en matière de lutte contre le pourriel :
      • signature DKIM,
      • définition de la politique d’envoi SPF ;
    • en matière de sécurité, mise en place du chiffrement :
      • implicite sur les ports dédiés 993 (IMAPS), 995 (POP3S) et 465 (SMTPS),
      • explicite (StartTLS) sur les ports standards, que l’on peut rendre obligatoire depuis l’extérieur.

  • # Sieve

    Posté par  . Évalué à 2.

    Les filtres Sieve, ça marche pas trop mal et c'est quand même plus simple que d'aller sur le serveur pour modifier les règles procmail/maildrop/etc. Ils sont gérés côté Dovecot par le plugin dovecot-pigeonhole, et côté Roundcube par le plugin managesieve.

    Sur Thunderbird malheureusement, le seul plugin existant n'est pas compatible avec la version 68.

  • # Euhhhhh....

    Posté par  . Évalué à 4.

    Cela présente le grand avantage d’être indépendant d’un GAFAM qui n’aura aucun scrupule à analyser les courriels pour en tirer un quelconque profit.

    puis un peu plus loin

    L’idée générale est que mon serveur récupère les courriels sur des serveurs POP ou IMAP sur Internet des utilisateurs du réseau local

    Bref en gros, les emails passent toujours par ces providers, ils ne sont simplement pas stockés là-bas uniquement et à long terme.

    Cela n'amène strictement aucun avantage au niveau analyse du courier par les providers. Les providers voient toujours les emails.

    • [^] # Re: Euhhhhh....

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Certes, mais je ne vois pas comment faire autrement que de passer par un POP ou IMAP et SMTP externe, il me semble que si je devais monter mes propres serveurs directement accessibles sur internet j'entre dans une autre dimension au niveau complexité et administration. Alors pour l'instant je me repose sur les serveurs POP et SMTP d'online.net, c'est une boîte française sous juridiction française et donc sous le coup de la protection du secret de la correspondance (article 68 de la loi pour une république numérique) ça ne me donne pas une protection absolue mais ça limite grandement les risques par rapport à une adresse gmail par exemple.

      https://www.funix.org mettez un manchot dans votre PC

      • [^] # Re: Euhhhhh....

        Posté par  . Évalué à 1.

        J'ai juste un grand mal à comprendre la valeur du truc sachant que la plupart des providers font déjà du spam filtering et autres.

        Avoir une copie locale des emails ? Un client lourd genre Thunderbird suffit pour cela.

        • [^] # Re: Euhhhhh....

          Posté par  . Évalué à 1.

          Si les perfs de recherche IMAP sont mauvaises. Par exemple, Gandi ne semble ne pas avoir d'index full text sur les emails pour l'IMAP, donc les performances sont moisies. Faire un IMAP miroir permettrait donc d'avoir un Roundcube avec des perfs potables.

        • [^] # Re: Euhhhhh....

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          le peu que j'ai pu tester des providers était au mieux médiocre au pire inefficace (du genre tous les mails pertinents étaient classés faux positif et les spams n'étaient pas reconnus) sans compter que leur configuration est très limitée.

          Sinon tu n'as sans doute pas lu tout mon post, mais mes mails étaient auparavant stockés sur un client lourd (thunderbird) mais je ne pouvais pas y accéder de mon mobile.

          https://www.funix.org mettez un manchot dans votre PC

  • # Index full text pour Dovecot

    Posté par  . Évalué à 1.

    La seule chose que je changerais, c'est ajouter Apache Solr pour avoir un index full text sur les mails. C'est toujours chouette de pas mettre des plombes à retrouver des infos dans un vieux mail.

  • # JMAP ?

    Posté par  . Évalué à 2.

    Est-ce que qqun a déjà expérimenté la mise en place de JMAP.

    Je lorgne dessus depuis longtemps car il répond à une problématique que j'ai depuis encore plus longtemps : l'externalisation des pièces jointes.

    Cette fonctionnalité permet(trait) :

    • le transfert (FW) de pièces jointes sans passer par le client
    • la dé-duplication des pièces jointes
    • un cycle de vie des pièces jointes différents de celui du message ; détruire la pièce jointe sans détruire le message qui l'accompagnait
    • une recherche plus efficace si seul le message est stocké dans le moteur

    Je trouve intéressant aussi d'avoir un seul protocole pour la réception et l'envoi d'email.

    Après je me dis que le protocole est récent et qu'il faut du temps pour avoir une bonne implémentation - tant côté client que serveur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.