Analyse mail - Karitchi/woodytoys-admin2-b2-q2-y22_23 GitHub Wiki
1. Besoins du client
- Donnez à chaque employé une adresse e-mail au format nom.pré[email protected].
- Permettre aux employés d'afficher et d'envoyer des e-mails à l'aide de clients de messagerie traditionnels (lourds).
- Rendre le courrier électronique accessible depuis les postes de travail de l'entreprise et à distance.
- Configurez une adresse e-mail générique à transmettre aux contacts B2B et aux commerciaux.
- Ne pas utiliser de webmail.
2. Besoins techniques
A partir des besoins du client ci-dessus, nous avons identifié les besoins techniques suivantes:
- un serveur de récupération de mail depuis de serveurs distants
- Un serveur d'envoi de mail
- gestion de nom d'utilisateur du courrier électronique
- un client mail pour la récupération et l'envoi de mail depuis le post utilisateur : il doit également permettre la gestion des mails en mobilité
Pour répondre à ces besoins techniques, il nous faudra réfléchir sur les points suivants :
- rediriger le trafic lié au service mail vers le/les serveurs de récupération mail
- quelle architecture pour les serveurs ?
- les serveurs de récupération de mail et d'envoie pourrait etre colocalisés sur une meme machine physique tout comme on peut opter à les séparer
- les serveurs backup vont il etre sur le meme reseau que les deux premiers ou sur un réseau distinct.
- allons nous colocaliser sur une meme machine physique les serveurs backup?
- créer des comptes mail pour le différents utilisateurs du réseau
- créer un compte générique dont les mails sont redirigés vers les bonnes personnes
- sélectionner les logiciels que nous allons mettre en place pour les différents serveurs ainsi que pour les clients
3. Choix d'architecture
3.1 Localisation et redondance des serveurs
-
la première discussion portait sur la possibilité de colocaliser le serveurs de recupération de mail et celui d'envoi de mail sur la meme machine physique. Dans notre cas, nous utilisons des conteneurs mais on pourrait bien imaginer un seul conteneur faisant tourner les deux serveurs. Cependant, cela n'est pas une bonne pratique pour plusieurs raisons.
- Pour des raisons de sécurité, il n'est pas conseillé de colocaliser ces deux serveurs sur la même machine . Si jamais, un des serveurs présentes une faille de sécurité, le second n'en sera pas nécessairement impacté.[5]
- Le fonctionnement des deux serveurs sur une même machine peut entrainer des pertes de performance car les deux serveurs requièrent chacun un type de ressource plus que l'autre. De ce fait, un des serveurs peut manquer d'une certaine ressources car cette dernière est surconsommé par le 2e serveur.[5]
- Au niveau de la gestion, le fait d'avoir un seul type de serveur sur une machine donnée rend la gestion de cette machine moins complexe.[5].
Au vu de points qui précèdent, nous comptons séparer serveur de récupération et serveur d'envoi de mail.
-
la deuxième discussion concerne l'emplacement des serveurs backup. Il est clair que les différents backup ne seront pas sur les mêmes machines que les serveurs primaires. Cependant, il reste à déterminer s'il seront sur le même réseau ou pas. Pour des questions d'isolation complète, c'est à dire pour que les différents serveurs ne risquent pas d'être impactés par les mêmes problèmes, nous envisageons des placés les serveurs backup dans un réseau différent. Ce réseau sera dédié à heberger tous les serveurs backup de nos services privés. Et une fois de plus, le serveur backup de récupération sera séparé du serveur backup d'envoi de mail.
3.2 Schéma d'architecture
4. Choix des technologies
4.1 Protocoles
Sur base des besoins de notre client, au niveau des choix de protocole, IMAP parait le plus convenable car il offre la possibilité de consulter les mails directement sur le serveur et non pas en faire une copie locale. Cela permet effectivement d’être synchronisé avec ce dernier en tout temps[1]. Pour l’envoi de mail, le protocole SMTP demeure incontournable.
4.2 Client mail
Pour rendre effectivement possible l’accès au service mail même en mobilité, un client mail doit être mis en place sur les différents appareils des utilisateurs. Pour trier et sélectionner parmi la multitude de clients mail existant sur le marché, nous nous sommes fixé quelques critères de recherches tout en nous appuyant sur les souhaits du client. Le premier critère concerne la licence software du logiciel. Nous recherchons un logiciel qui soit open source. Le deuxième critère concerne l'OS utilisateur, le logiciel doit fonctionner indépendamment de l'OS de l'utilisateur. Puis, nous souhaitons également un logiciel qui soit léger et moins gourmand en ressource. Enfin, le logiciel doit être disponible en GUI.
Avec ces trois critères en tête, trois logiciel ressortent du lot : Alpine, Microsoft outlook, Thunderbird.
Le premier, Alpine est bien Opensource. Il fonctionne sur tout type d'OS [6 ]. Cependant, en plus de ne pas avoir pu récolter d'information sur sa légèreté ou pas, il s'avère qu'il n'est disponible qu'en ligne de commande. Ce qui n'est pas idéale pour nos clients.
Le deuxième, Microsoft outlook faisant parti des clients mail les plus populaires ne fonctionne que sur MAC et Windows. En plus, il n'est pas gratuit. Il est soumis à une licence en plus d'etre très demandant en ressource car il vient avec plusieurs fonctionnalités dont on a pas nécessairement besoin.[7 ]
Enfin, Thunderbird semble etre le meilleur choix car il est à la fois léger comme système et adapté aux OS Linux, Windows et Mac. Il est libre de droit et présente bien une interface graphique. [2]. C'est celui qui coche tous nos critères, par conséquent c'est celui que nous retenons pour notre client mail. Thunderbird est également plus facile à installer et à configurer. Le potentiel inconvénient pour l’heure est que Thunderbird n’est pas encore accessible sur mobile. Cependant, il le sera d’ici l’été 2023[3]. Pour l’avantage qu’il offre par rapport à Outlook ainsi que par rapport à la vision du développement durable du client nous pensons que cela en vaut la peine, surtout que les premiers prototypes de notre projet ne doivent être présentés que courant juin 2023.
4.3 Serveur de récupération de mail
Avant que le client mail ne puisse chercher et livré le message à l'utilisateur, le message doit d'abord être disponible sur un serveur de récupération de mail. Là aussi, il existe toute une liste de logiciel capable de réaliser la tache. Pour en choisir un, nous avons établi des critères de sélection similaires à ceux évoqués pour le client mail à la différence que cette fois-ci, il n'est pas nécessaire d'avoir une interface graphique et l'OS compatible importe peu. De plus, l'application choisi doit supporter IPV6 et avoir un niveau de sécurité assez élevé car nous l'utilisons dans un cadre professionnel.
Dans nos recherches, nous avons trouvée le serveur Cyrius comme candidat. Malgré sa popularité et le support d'IPV6, il demeure un gros obstacle pour choisir ce logiciel. Il ne supporte pas le protocole SMTP [[9](Wikipédia, Microsoft Outlook. en.Wikipédia.org. Consulté le 16 mars 2023.) ]. En plus il a une documentation pas très large et les mise à jour ne sont pas fréquent. Il a l'air d'être classé parmi les technologies qui sont en train d'être dépassé.
Ensuite, nous avons Courier Mail server qui semble aussi un bon candidat. Il répond à tout nos critère de sélection. Il supporte IPV6 et offre une sécurité raisonnable. Cependant, il est devancé de peu dans notre classement par Dovecot qui est moins complexe à installer et surtout plus léger et donc moins gourmand en ressource.
Dovecot est un serveur IMAP/POP3 open source, connu pour sa sécurité et sa stabilité. Il est plus modern et à une documentation plus récente par rapport à Cyrus par exemple[8 ]. Il peut être utilisé avec différents systèmes de stockage, tels que des fichiers locaux ou des bases de données. Il offre également de meilleures possibilités de migrations. IPV6 et SSL sont supportés. Il est le serveur mail le plus répandu en 2020 avec plus de 75 % du marché. Il convient aussi bien pour les petites que les grandes entreprises[4]. Sa large utilisation, le support d'IPV6, son niveau de sécurité élevé ajoutés au fait qu’il soit open source, sont les principaux éléments qui nous ont guidés dans le choix de cette technologie.
4.4 Serveur d'envoi de mail
Toujours en restant avec nos critères précédents, nous avons identifié quelques logiciels capable de répondre à nos attentes.
Parmi eux, il y'a sendmail. Ce dernier dispose d'une configuration impressionnante qui permet de répondre aux besoins spécifiques des utilisateurs. Sendmail est également hautement portable, ce qui le rend facile à utiliser sur différents systèmes d'exploitation. Il offre également une grande flexibilité en termes de fonctionnalités et d'extensions. Cependant, il y a aussi des inconvénients à son utilisation. La sécurité de Sendmail est considérée comme faible en comparaison avec d'autres logiciels de serveur de messagerie, ce qui peut poser des problèmes de sécurité pour les entreprises et les organisations [10 ].
Ensuite, il y'a Exim qui présente des avantages et des inconvénients similaires à Sendmail. En plus, Exim, peut présenter quelques lenteurs lorsque la demande devient de plus en plus grande et peut également nécessiter une maintenance complexe. [10 ].
Enfin, nous avons Postfix qui est un logiciel de serveur mail open-source qui est utilisé par de nombreuses entreprises pour gérer leur communication par e-mail. Il offre plusieurs avantages notables, notamment une forte concentration sur la sécurité, une documentation de haute qualité, une vitesse élevée de la file d'attente d'opérations et un développement actif. De plus, la configuration de Postfix est simple et les paramètres sont spécifiés dans le fichier de configuration. Par ailleurs, Il peut nécessiter une expertise technique pour effectuer des ajustements plus avancés. Cela dit, il est toujours considéré comme un choix solide pour les entreprises qui recherchent une solution de serveur de messagerie sécurisée et efficace. Le point sur la sécurité est la pricncipale raison pour laquelle notre choix se porte sur Postfix [ 10]
Références
- [1] : Sarah GALODÉ, "Protocoles de messageries : SMTP, POP, IMAP". Blog Provectio. Consulté le 09 mars 2023. https://blog.provectio.fr/protocoles-de-messageries-smtp-pop-imap/#:~:text=La%20grande%20diff%C3%A9rence%20entre%20les,de%20travail%20et%20le%20serveur.
- [2] : RiseUp, "Thunderbird ", Riseup.net, consulté le 09 mars 2023. https://riseup.net/fr/email/clients/thunderbird.
- [3] : Toolinux, "Mozilla Thunderbird arrivera sur Android en 2023", toolinux.com. Consulté le 10 mars 2023. https://www.toolinux.com/?mozilla-thunderbird-sortie
- [4] : Wikipédia, "Dovecot". fr.wikipedia.org. Consulté le 10 mars 2023. https://fr.wikipedia.org/wiki/Dovecot#cite_note-3
- [5] : chatgpt, prompt : "est ce une bonne pratique de colocaliser serveur de récupération de mail et serveur d'envoi de mail sur une meme machine?", consulté le 16 mars 2023
- [6] : Wikipédia, Alpine. en.Wikipédia.org. Consulté le 16 mars 2023. https://en.wikipedia.org/wiki/Alpine_(email_client)
- [7] : Wikipédia, Microsoft Outlook. en.Wikipédia.org. Consulté le 16 mars 2023. httpshttps://en.wikipedia.org/wiki/Microsoft_Outlook
- [8] : Server Fault, Dovecot vs Courier Vs Cyrius, serverfault.com. Consulté le 16 mars 2023. https://serverfault.com/questions/103639/dovecot-vs-courier-vs-cyrus
- [9] : Wikipédia, Comparison of mail server. en.Wikipédia.org. Consulté le 16 mars 2023.https://en.wikipedia.org/wiki/Comparison_of_mail_servers
- [10] : Plesk, Postfix vs Sendmail vs Exim, plesk.com, Consulté le 17 mars 2023 https://www.plesk.com/blog/various/postfix-vs-sendmail-vs-exim/
Habibou Moulaye Zeini. 2TM1-4