= Pourquoi faire ? =

Postfix peut stocker les informations des tables de correspondance (''alias'', ''virtual'' et autres) dans des tables MySQL. Cela permet une grande souplesse dans la création et la gestion des adresses email et des comptes utilisateurs : il n'y a plus de fichier texte à manipuler (avec les postmap qu'on oublie toujours) et on peut construire des requêtes SQL "intelligentes" qui sauront calculer les correspondances.

L'usage de ce type de stockage, associé à l'utilisation des [[http://postfix.traduc.org/index.php/VIRTUAL_README.html|virtual_mailbox]] permet d'avoir des comptes utilisateurs complétement dissociés des comptes Unix du serveur.
 
Voir la [[http://postfix.traduc.org/index.php/DATABASE_README.html|documentation sur les tables de correspondances]] de Postfix, et, plus particuliérement, celle détaillant [[http://postfix.traduc.org/index.php/MYSQL_README.html|les tables mysql]] pour le fonctionnement général.

Note : la configuration du serveur IMAP/POP (l'utilisation de [[Dovecot]] est vivement conseillée) doit bien entendu être synchrone à la configuration MySQL de Postfix. C'est facile car Dovecot peut lui aussi utiliser des tables MySQL.

= Comment faire ? =

Les façons de faire sont multiples... Ce qui est indiqué ci-dessous n'est qu'une technique parmis d'autres.

== Schéma conseillé pour la base de données ==

Cette documentation part du principe que le schéma de base de données utilisé est [[http://trac.sn.auf.org/guia/browser/trunk/guia/noyau/greffons/Postfix_MySQL/bases/postfix.sql|celui de GUIA]] (mais l'utilisation de GUIA n'est pas obligatoire... vu qu'il n'existe pas encore `;)` ). Dans la suite on suppose que la base de donnée existe et contient déjà toutes les informations nécessaires.

== Exemple typique : gestion de boites aux lettres virtuelles ==
 
On place dans {{{virtual_mailbox_domains}}} les domaines qui seront gérés en "virtuel", c'est-à-dire sans aucun utilisateur au niveau Unix. Vérifier que ces domaines ne sont '''pas''' dans {{{mydestination}}} ni {{{virtual_domains}}}, pour éviter les incohérences.
  {{{
# (... extrait de main.cf ...)
# liste des domaines qui sont gérés sur ce serveur :
virtual_mailbox_domains = ca.auf.org, secours
}}}

On configure le système de "virtual_mailbox" pour qu'il cherche ses informations dans une table mysql :
  {{{
# (... extrait de main.cf ...)
# Ce fichier défini la requête à faire pour récuperer les données.
# Ici, la requête sera "quel est le répertoire pour stocker les mails de telle adresse ?"
virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual_mailbox_maps.cf
# Un préfixe à ajouter devant chaque chemin de boîte aux lettres. 
# On préfère mettre des chemins absolus dans la base, pour se simplifier la vie :
# certains logiciels (Postfix) autorisent l'ajout de préfixes, d'autres seulement de
# suffixe...
virtual_mailbox_base = /
}}}

On spécifie l'utilisateur Unix à qui appartiendront les fichiers de toutes boîtes aux lettres. Il faut '''créer un utilisateur dédié à ce seul usage''' et ne pas utiliser "mail:mail", destiné à d'autres usages.
  {{{
# (... extrait de main.cf ... on a créé un compte vmail:vmail uid=127, group=127)
virtual_uid_maps = static:127
virtual_gid_maps = static:127
virtual_minimum_uid = 127
}}}

On créé le fichier {{{/etc/postfix/virtual_mailbox_maps.cf]}}} qui décrit la façon d'accéder aux données, c'est-à-dire à quelle base se connecter et quelle requête effectuer :
  {{{
# /etc/postfix/virtual_mailbox_maps.cf
user = utilisateur-mysql
password = pass-de-utilisateur-mysql
hosts = hote-mysql
dbname = nom-de-la-base-mysql
query = SELECT homedir FROM users WHERE mail = '%s'
}}}

Et bien sûr il faut créer l'utilisateur MySQL correspondant, en ne lui donnant '''que''' le droit "select" sur les tables nécessaires :
  {{{
mysql> grant select on nom-de-la-base-mysql.* to utilisateur-mysql@'localhost' identified by 'pass-de-utilisateur-mysql';
}}}

Voilà... A partir de là, quand il aura besoin de faire une correspondance entre une boite aux lettre d'un des domaines virtuels et le répertoire où stocker le message, Postfix lancera la rêquete SQL (si aucun résultat ne revient, c'est que l'adresse n'est pas gérée). Il placera alors le message (fichier) dans le répertoire (plus exactement dans le sous-répertoire `new/`), ce fichier appartenant à l'utilisateur "127".

== Généralisation ==

On peut utiliser des tables MySQL partout où des tables existent déjà, par exemple des tables `hash:`. 

Autre exemple avec `virtual_maps` :
  {{{
# (... extrait de main.cf ...)
virtual_maps = proxy:mysql:/etc/postfix/mysql_virtual.cf
}}}
Il faut ensuite adapter la requête pour aller chercher les informations correspondantes. Ici, le contenu de `mysql_virtual.cf` pourra être :
  {{{
# /etc/postfix/mysql_virtual.cf
user = utilisateur-mysql
password = pass-de-utilisateur-mysql
hosts = hote-mysql
dbname = nom-de-la-base-mysql
query = SELECT destination FROM virtual WHERE source = '%s'
}}}


= Que faire lorsque ça ne fonctionne pas ? =

 * Toute d'abord, bien entendu, [[VérifierLesLogsEnCasDeSoucis|analyser les logs]]. Les logs de Postfix mais aussi ceux de MySQL (à activer si ce n'est pas fait)
 * Si Postfix n'arrive pas à se connecter à la base MySQL en général : essayer de se connecter au même serveur en ligne de commande, avec les mêmes paramètres.
 * Si certains modules de Postfix n'arrivent pas à se connecter à la base alors que d'autres le peuvent : sachez que Postfix lance certains de ses modules en chroot. Si le serveur MySQL est sur la même machine, cela va passer par un fichier 'socket' plutôt que par une connexion réseau, qui ne sera donc pas accessible dans l'environnement chroot. Vérifier alors que le mot "proxy:" précède bien les entrées "mysql:" correspondantes. Dans ce cas, un proxy dédié à l'interrogation de la base mysql sera lancé, et ferra l'intermédiaire entre postfix et mysql.
 * "loops back to myself"
 * ... ?