Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 999-archives:messagerie:start [le 30/05/2025 à 09:10] – ↷ Page déplacée de 200-messagerie:00-archive:start à 999-archives:messagerie:start prof
+++ 999-archives:messagerie:start [le 30/05/2025 à 09:13] (Version actuelle) – prof
@@ Ligne 1: / Ligne 1: @@
-====== Archive ======
+====== SMTP/IMAP en pratique ======
-Ce chapitre regroupe les anciennes pages, désormais en très grande partie dépassées.
+===== Avertissement =====
+Cette suite de chapitres est avant tout destinée à montrer les diverses facettes d'un système de messagerie, de plus en plus complet. Elle n'a pas la prétention de fournir des solutions directement applicables en production, mais plutôt de présenter des pistes de recherche pour obtenir une solution qui réponde aux besoins.
+**L'étude étant progressive, les derniers chapitres, principalement [[200messagerie:030postfix3:start]] et [[200messagerie:040postfix4:start]] font appel à des notions vues dans les chapitres précédents...**
+===== Problématique =====
+Mettre en œuvre un système complet de messagerie est une aventure un peu compliquée.
+Si l'on souhaite disposer d'un système complet, capable d'envoyer des mails et aussi d'en recevoir pour un ou plusieurs domaines, il faudra également tenir compte des protocoles POP3 et IMAP et installer ce qui va avec.
+Il existe dans le monde libre de nombreuses solutions, nous en verrons quelques-unes :
+  * Postfix pour le SMTP avec un serveur POP/IMAP comme Dovecot;
+  * Postfix avec le serveur POP/IMAP nommé Cyrus ;
+Bien sûr, de nombreuses autres combinaisons sont possibles, principalement si l'on doit également tenir compte d'une très forte montée en charge et d'une tolérance de panne très faible.
+===== A savoir d'abord =====
+==== Qu'attendons-nous ? ====
+Un serveur SMTP en production doit être capable de faire au moins ceci :
+{{ :messagerie:chemins-smtp.png?500 |Les chemins de la messagerie}}
+  - depuis le réseau de son entreprise, nous devons pouvoir envoyer des messages aux comptes de messagerie dont nous avons la gestion.
+  - depuis le réseau de son entreprise, nous devons pouvoir envoyer des messages au reste du monde.
+  - le reste du monde doit pouvoir envoyer des messages aux comptes de messagerie dont nous avons la gestion.
+  - nous ne devons éventuellement servir de relais que dans certains cas bien spécifiques :
+    * vers des domaines qui nous l'ont expressément demandé ;
+    * éventuellement, pour des clients qui ont un compte que nous gérons, et qui souhaitent utiliser notre SMTP comme relais. Dans un tel cas, il faut bien entendu mettre en place une stratégie stricte de contrôle des clients autorisés.
+**En aucun cas nous ne devons pouvoir servir de relais ouvert**, c'est-à-dire que n'importe qui puisse utiliser notre service SMTP pour envoyer des messages n'importe où.
+==== Les restrictions imposées ====
+Si techniquement il est possible de faire tout ceci, le développement du « spam » et les parades qui sont d'usage (plus ou moins pertinent) sur l'internet vont amener quelques restrictions.
+=== Blocage du port 25 ===
+Vous disposez d'un accès que votre fournisseur a bridé. En effet, la solution simple, efficace (et contraire à l'éthique de l'internet) que votre fournisseur d'accès a mis en place consiste à vous interdire toute connexion TCP vers le port 25, hormis vers le serveur SMTP « officiel » de votre fournisseur.
+Dans un tel cas, vous ne pourrez pas faire grand chose, à part un serveur tampon pour l'envoi de vos messages vers le reste du monde. Si votre fournisseur est dans ce cas et qu'il n'y a pas moyen pour vous de faire débloquer le port 25, abandonnez toute envie de gérer vous-même votre messagerie ou changez de fournisseur.
+=== Les « BlackLists » ===
+Il existe sur la possibilité, nous le verrons, de créer ou d'utiliser des listes d'exclusion. Ces listes contiennent des adresses IP ou des blocs CIDR d'adresses IP qui sont sensées représenter des SMTP « malpropres ». Certains n'hésitent pas à mettre dans ces listes toutes les adresses IP qui sont utilisées par les fournisseurs d'accès pour leurs clients.
+Il n'y a pas de parade. Si l'hébergeur du domaine de messagerie @truc.com utilise une blacklist où vous êtes référencé, vous ne pourrez envoyer par vous-même aucun message @truc.com. Il vous faudra alors passer par le SMTP officiel de votre fournisseur (en priant pour que celui-ci ne soit pas aussi blacklisté).
+=== Adresse de l'émetteur ===
+Une saine précaution (dérisoire toutefois) est de contrôler que l'adresse de l'émetteur (valeur de ''from:'' dans le dialogue SMTP) est @unDomaineConnuSurLe.net. Ceci est généralement du ressort de vos utilisateurs qui doivent disposer d'une adresse e-mail valide.
+=== Cohérence DNS ===
+Lors du dialogue entre votre serveur SMTP et celui du destinataire, votre serveur se présente par son nom (valeur ''helo'' ou ''ehlo'' dans le dialogue SMTP). Le serveur destinataire peut effectuer plusieurs contrôles :
+  * le domaine annoncé existe-t-il vraiment (contrôle DNS) ?
+  * le « rdns » (recherche DNS inverse) donne-t-il quelque chose de cohérent ? Autrement dit, si votre serveur se présente comme « smtp.mondomaine.tld » avec l'adresse IP xx.yy.zz.tt, est-ce qu'une recherche rdns aboutit :
+    * à un nom de machine dans le domaine mondomaine.tld ?
+    * à un nom de machine égal à smtp.mondomaine.tld ?
+    * à une machine enregistrée comme MX (Mail Exchanger) pour le domaine mondomaine.tld ?
+Si votre fournisseur d'accès vous permet de personnaliser votre rdns, vous pouvez rendre tout ceci cohérent.
+=== Sender Policy Framework ===
+Ce très controversé [[http://www.openspf.org|système de contrôle]] utilise un champ particulier dans les DNS, qui permet d'indiquer quelles sont les hôtes autorisés à envoyer des messages pour le domaine dont nous avons la charge. Dans la mesure où vous pouvez créer cette entrée sur vos DNS, faites-le le moins salement possible...
+==== Les messages entrants ====
+Nous ne devons pas laisser entrer n'importe quoi. Plusieurs cas peuvent se produire :
+  - nous sommes sur un réseau local ou d'entreprise, le ou les blocs d'adresses IP utilisées sur ce réseau sont connus, nous disposons d'un ou de plusieurs domaines (au sens DNS du terme), les hôtes qui disposent d'une de ces adresses peuvent à priori sans restrictions utiliser notre serveur SMTP pour envoyer des messages à des utilisateurs @nos_domaines, depuis un hôte situé sur notre réseau ;
+  - les mêmes utilisateurs, lorsqu'ils sont sur notre réseau, doivent pouvoir utiliser notre SMTP pour envoyer des messages, au reste du monde ;
+  - le reste du monde ne doit pouvoir accéder à notre SMTP que pour y déposer des messages à destination de nos domaines ;
+  - les utilisateurs, qui ont un compte de messagerie dans l'un de nos domaines aimeraient pouvoir utiliser notre SMTP pour envoyer des messages au reste du monde, même s'ils ne sont pas connectés sur notre réseau. Ceci ne sera pas forcément possible, ne serait-ce qu'à cause des restrictions que certains fournisseurs (la majorité) mettent sur le port 25 ;
+  - **en aucun cas le monde ne doit pouvoir utiliser notre SMTP pour relayer des messages ailleurs dans le monde**