Discussion sur la configuration sql postfix lié à l'interface de gestion des comptes

le schéma de base envisagé est http://trac.sn.auf.org/guia/browser/trunk/guia/noyau/greffons/Postfix_MySQL/bases/

Fonctionnement et principes généraux

Objectifs:

• avoir des requêtes services les plus simples possible, en concentrant l'intelligence dans le greffon
• éviter au maximum les cas particuliers

L'authentification se ferait sur le login, pour garder la compatibilité avec l'existant. L'adresse d'expéditeur sera cherché dans la base à chaque fois que l'information est nécessaire (envoi de mail dans le cadre de scripts automatique, champ From: pour le webmail, etc) dans la table users, colonne "from".

Trois types d'adresses:

• les adresses sur un domaine local
• les adresses sur un domaine pseudo-local (@auf.org, par exemple)
• les adresses sur un domaine non local (@yahoo.fr, par exemple)

Une adresse sera locale, par définition, si la partie droite est présente dans le fichier de configuration du greffon (ou de GUIA en général) qui défini les domaines locaux. Dans ce cas, une entrée dans la table des utilisateurs sera créée, et le domaine ajouté à la table des domaines locaux de postfix. La colonne "from" sera identique à la colonne "mail".

Si un domaine est pseudo-local ou non local, une fonction de transformation sera appelée sur l'adresse email (fonction définie dans un fichier de configuration du greffon).

• Si le résultat est une adresse non locale : on ne fait rien, aucune entrée créée dans les tables postfix.

• Si le résultat est une adresse locale, on défini une entrée pour cet utilisateur avec l'adresse transformée, et le domaine sera ajouté à la table des domaines relais, ainsi qu'une entrée adresse@domaine nouvelleadresse@domainelocal dans la table virtual. La colonne "from" sera mise à l'adresse ayant donné lieu à la réécriture.

Exemples sur un site qui gère refer.sn et sn.auf.org :

• aristide@refer.sn : domaine local, donc création d'un utilisateur (login: aristide, mail: aristide@refer.sn, from: aristide@refer.sn)

• lucien@gmail.com : domaine non local :

  1. réécriture.

  2. aprés réécriture : toujours lucien@gmail.com : on ne fait rien

• roger@auf.org : domaine non local

  1. réécriture.

  2. aprés réécriture : roger@sn.auf.org, domaine local

     1. création de (login: roger, mail: roger@sn.auf.org, from: roger@auf.org)

     2. création du virtual (roger@auf.org, roger@sn.auf.org, 'PSEUDO')

gestion des aliases et redirections

Cela se fera via la table virtual, avec, en plus de la source et destination, un flag indiquant de quel type de redirection il s'agit (afin de faciliter le travail de greffon pour la création/déconfiguration des adresses, et pour le debugging). Les flags pourraient être :

• REDIRection : le domaine de l'adresse source soit doit être local ou pseudo-local. la destination peut être locale ou non

• ALIAS : le domaine de l'adresse source soit doit être local ou pseudo-local. la destination doit être locale ou pseudo-locale

• PSEUDo pour les adresses pseudo-locale (@auf.org) : la destination doit être une adresse locale

Les REDIRection et les ALIAS peuvent être multiples.

• Au niveau interface, prévoir une alerte visible sur l'interface en cas de redirection, pour éviter les confusions en cas d'assistance utilisateur.

copies et redirections

• le cas "copie" est gérée en ajoutant une entrée "mail vers mail" dans la table virtual. (une case à cocher dans l'interface)