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"
• ... ?