Différences

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

--- 200messagerie:040postfix4:010_principe [le 03/03/2009 à 18:48] – modification externe 127.0.0.1
+++ 200messagerie:040postfix4:010_principe [Date inconnue] (Version actuelle) – supprimée - modification externe (Date inconnue) 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-{{keywords>postfix sympa mailing-lists listes diffusion}}
-====== Le principe général ======
-Nous savons désormais que par défaut, lorsque Postfix par un moyen ou un autre, identifie une adresse comme étant locale (« vrai domaine » ou domaines virtuels), il transmet le message au MDA, pour qu'il le range dans la boite aux lettres du destinataire.
-Dans le cas d'une liste de diffusion qui, à première vue, dispose d'une adresse locale, Postfix ne devra pas transmettre le message au MDA, mais au robot de gestion des listes. Quelle que soit l'adresse de la liste, Postfix devra remettre le message au même robot, qui se chargera de le diffuser sur la liste adéquate, en suivant la politique de gestion de la liste en question.
-{{ :175messagerie:040postfix4:distribution.png |}}
-  - Le message entrant doit et peut être relayé vers un autre MTA
-  - Le message entrant concerne une livraison dans une boite aux lettres locale, il est remis au MDA.
-  - Le message entrant concerne une liste de diffusion, il est remis au robot des listes de diffusion.
-  - Le robot créera le ou les messages nécessaires en fonction de l'entrée reçue, et injectera sa sortie dans l'entrée du MTA.
-Il nous faudra donc mettre en place un mécanisme cohérent avec ce que nous avons déjà, et qui permette d'indiquer le bon transport local, suivant qu'il s'agit d'une adresse de boite aux lettres ou de liste de diffusion.
-Si la résolution de ce problème est plus ou moins complexe, suivant le nombre de listes créées et aussi suivant le nombre de domaines hébergés.
-===== Un peu plus de piment ? =====
-Pour compliquer un peu les choses, le travail d'un robot de liste ne se borne pas à dupliquer l'entrée sur tous les inscrits à la liste.
-En effet, il existe des règles de gestion pour une liste donnée et le robot doit suivre ces règles :
-  * l'émetteur du message est-il autorisé à poster sur cette liste ?
-  * la liste est-elle modérée ?
-    * si oui,
-      * s'agit-il d'un message entrant ?
-      * est-ce une autorisation de diffuser un message modéré ?
-    * si non,
-      * le destinataire est-il habilité à poster ?
-  * est-ce une demande d'inscription ?
-  * est-ce une demande de résiliation ?
-  * est-ce une demande administrative ?
-Suivant la finesse de gestion, le nombre de cas à gérer est plus ou moins important et les réactions du robot de même.
-Pour ce faire, le robot crée plusieurs adresses pour une liste donnée. Prenons le cas d'une liste qui s'appellerait ''liste1@nain-t.net''. Nous aurons au final avec (cas du robot ''Sympa'') les adresses :
-  - liste1@nain-t.net
-  - liste1-request@nain-t.net
-  - liste1-editor@nain-t.net
-  - liste1-subscribe@nain-t.net
-  - liste1-unsubscribe@nain-t.net
-  - liste1-bounce@nain-t.net
-Nous voyons bien que la création d'une nouvelle liste entraine des modifications dans la configuration de Postfix, qui devra appliquer le bon transport aux adresses associées à cette nouvelle liste. Sympa tout comme Mailman, proposent une aide acceptable à la résolution de cette problématique, du moins tant que nous ne gérons pas de domaines virtuels. C'est à ce niveau que l'on peut être amené à sérieusement se demander si Qmail,Vpopmail et EZmlm, avec Qmailadmin qui centralise toute la gestion de l'usine de façon bien homogène n'est pas finalement une bonne solution, même si la construction de cette usine n'est pas une sinécure :-)
-===== Etat des lieux =====
-Nous avons une interface (web-cyradm) qui ne sait que gérer les comptes de messagerie (en PHP). Nous allons avoir une autre interface, qui ne sait gérer que les listes de diffusion (en Python pour Mailman et en Perl pour Sympa) et ce, en ignorant la configuration du MTA dès lors que l'on a à gérer des domaines virtuels.
-Autant dire que nous devons non seulement renoncer à disposer d'une interface de gestion homogène, mais en plus nous résoudre à intervenir plus ou moins en profondeur sur la configuration du MTA en mettant les mains directement dans le cambouis.
-===== Quelques solutions =====
-Une solution simple, sale et catastrophique en cas de spam, consisterait à dire :
-  * nous créons un sous domaine dédié aux listes, par exemple ''lists.nain-t.net'';
-  * tout ce qui entre à destination de ce sous-domaine est automatiquement dirigé vers le robot des listes.
-^  Pour   ^  Contre  |
-| Une seule règle par domaine virtuel nous permet de créer autant de listes qu'on le souhaite dans ce domaine, sans plus toucher à la configuration du MTA | Le MTA ne gère pas les fausses adresses de listes, c'est au robot de le faire. En cas de spam sur le sous-domaine avec des adresses forgées aléatoirement, le robot sera soumis à rude épreuve. |
-Comment éviter cet inconvénient  ? Créer une règle  spécifique pour chaque liste de diffusion.
-^  Pour   ^  Contre  |
-| Une adresse de liste (une famille d'adresses, en fait) ne sera acceptée par le MTA que si elle est connue de lui. Le robot ne recevra que des messages légitimes.\\ \\ Il n'est plus nécessaire de créer un sous domaine dédié aux listes. | Il faut revenir sur la configuration du MTA à chaque création ou destruction d'une liste. Nous devrons le faire directement dans les fichiers de configuration de Postfix, ce qui obligera à faire intervenir un administrateur système.|
-La dernière solution consisterait à modifier le code des scripts de gestion des listes de manière à automatiser la configuration de Postfix, ce qui en plus de nécessiter des compétences de programmation, interdirait la mise à jour simple des scripts à partir des paquets de la distribution.
-Dans ce qui suit, nous choisirons la méthode de mise en œuvre la plus simple, même si ce n'est pas forcément la meilleure.