Plus avec Dovecot

Dovecot peut être complété par l'utilisation de « plug-ins ». Voir la page qui y est consacrée.

Si nous désirons utiliser Sieve, il nous faut utiliser le plug-in cmusieve, que nous avons d'ailleurs déjà invoqué dans la configuration de Dovecot :

protocol lda {
  postmaster_address = sysop@maison.mrs
  hostname = janus.maison.mrs
  mail_plugin_dir = /usr/lib/dovecot/modules/lda
  sendmail_path = /usr/lib/sendmail
  auth_socket_path = /var/run/dovecot/auth-master
  mail_plugins = cmusieve
}

Mais ce n'est pas tout, il faut aussi que le compte virtuel dispose d'un « home ». Nous l'avons déjà fait aussi dans la configuration de Dovecot :

  userdb static {
    args = uid=vmail gid=vmail home=/home/virtual/mail/%d/%n
  }

cmusieve va alors chercher un script sieve s'il existe, dans le fichier .dovecot.sieve, situé dans le « home » du compte virtuel (ici, /home/virtual/mail/<domaine>/<utilisateur>). Malheureusement, Dovecot n'implémente pas, du moins dans la version que nous utilisons, de protocole ManageSieve, qui permettrait simplement à l'utilisateur de charger ses scripts Sieve. Lire la documentation de Dovecot ManageSieve Server pour avoir toutes les informations.

A moins de donner un accès ftp aux utilisateurs, ce sera donc à l'administrateur de placer les scripts… En attendant la version 2.0 de Dovecot, à moins de reconstruire un Dovecot patché.

Le problème des quotas est surtout épineux avec IMAP. Un peu moins avec POP si le client ne choisit pas de garder une copie des messages sur le serveur.

Les quotas se gèrent également au moyen d'un plug-in. Comme il s'agit d'un problème de bord, personne ne sait exactement à qui incombe la gestion de ces quotas. Est-ce le MTA, le serveur POP/IMAP, le système de fichiers du serveur ?

Wietse Zweitze Venema, le concepteur de Postfix, a une position tout à fait claire : ce n'est pas au MTA de le gérer. D'autres MTA comme EXIM le font cependant. Le « File System » doit savoir le faire, mais ici ça se passe au niveau du système d'exploitation et le client de messagerie n'a pas accès aux informations du système. C'est pourtant lui qui a besoin de connaitre cette information, puisque c'est à lui de gérer son espace de stockage.

Que se passe-t-il lorsque l'espace réservé au stockage des mails est entièrement occupé ? Le MDA (LDA) ne peut (le File System le lui interdit) ou ne doit (il a la consigne de gérer l'espace occupé) pas accepter de prendre en charge de nouveaux messages.

1. Les nouveaux messages entrants doivent être refusés par le MTA, en notifiant l'expéditeur.
2. Le destinataire doit être informé, par un moyen ou un autre, que sa boite déborde.

Nous avons bel et bien au moins deux composants qui sont dans le coup, si ce n'est trois, avec le File System.

Comment prévenir le destinataire que sa boite est pleine… En lui envoyant un message ? Il n'entrera pas dans la boite puisqu'elle est pleine… Il faut donc anticiper un peu et envoyer des alertes avant que ça ne déborde.

Comment prévenir l'émetteur du message de la non remise ?

1. soit le MTA gère directement ;
2. soit il reçoit l'information du MDA qui gère le quota ;
3. soit il reçoit l'information du MDA qui reçoit l'information du File System.

Clairement, c'est si le MTA qui gère qu'il y a le moins d'intermédiaires, au moins du côté des messages de notification.

La plupart des MUA gèrent de façon assez vilaine l'effacement des messages. Le chapitre sur IMAP vous en dira plus sur la question. Bref résumé :

• un message « effacé » doit être marqué comme tel, mais non détruit. Il reste dans le dossier où il a été effacé ;
• pour détruire physiquement un message, il faut envoyer au serveur IMAP la commande EXPUNGE. Les messages marqués comme effacés sont alors effectivement détruits par le File System.

La grande majorité des MUA utilise la « corbeille » (Trash) comme un dossier de classement :

• le message effacé est marqué comme effacé (protocole oblige) ;
• il est copié dans la corbeille.

L'effacement d'un message se traduit donc par l'augmentation du volume de données ! (sans compter les MUA qui ne font jamais de expunge automatique. Voir l'astuce avec Thunderbird).

Tout ceci se traduit pour l'utilisateur non spécialiste un piège dont il ne sait sortir. Sa boite est pleine et comme elle est pleine, il ne peut plus effacer de messages par les moyens habituellement utilisés.

Le plug-in de Dovecot est relativement souple et non moins relativement éphémère. La lecture de sa documentation montre clairement qu'il n'est pas encore stabilisé (à l'heure des versions 1.x). Noua allons donc l'utiliser dans le cadre de la version 1.0pre15 dont nous disposons.

Puisque nous sommes au format Maildir, nous utiliserons le standard Maildir++, qui permet de fixer non seulement un espace de stockage maximum mais aussi un nombre maximum de messages stockés. Nous n'utiliserons pas cette seconde limitation.

Au paragraphe « plugin » de dovecot.conf il faut ajouter ceci, en modifiant éventuellement les valeurs :

plugin {
  # 20 MB + 10000 messages quota limit
  quota = maildir:storage=20480
} 

Ceci fixera un quota par défaut pour toutes les boites aux lettres soumises au quota. Nous verrons qu'il est possible de surcharger ces valeurs individuellement. un storage=0 fera qu'il n'y aura pas de quota.

De plus, il faut indiquer pour chaque protocole que l'on utilise le quota :

protocol imap {
  mail_plugins = quota imap_quota
}

protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
  mail_plugins = quota
}
protocol lda {
  postmaster_address = sysop@maison.mrs
  hostname = janus.maison.mrs
  mail_plugin_dir = /usr/lib/dovecot/modules/lda
  sendmail_path = /usr/lib/sendmail
  auth_socket_path = /var/run/dovecot/auth-master
  mail_plugins = cmusieve quota
}

Pour surcharger les valeurs par défaut, nous pouvons exploiter userdb, c'est à dire notre base de données. Postfixadmin a d'ailleurs prévu un champ spécifique dans la table mailbox :

 mysql> select username, quota from mailbox;
+------------------+-------+
| username         | quota |
+------------------+-------+
| sysop@nain-t.net |     0 |
+------------------+-------+

Nous devons désormais lire toutes les informations de l'utilisateur dans la base. Autrement dit, dans, dovecot.conf, le paragraphe :

userdb static {
  args = uid=vmail gid=vmail home=/home/virtual/mail/%d/%n
}

Doit être remplacé par :

userdb sql {
   args = /etc/dovecot/dovecot-sql.conf
}

Et donc, notre fichier dovecot-sql.conf va devoir tenir compte de cette nouvelle requête qu'il faut ajouter :

user_query = SELECT CONCAT('/home/virtual/mail/',maildir, 'Maildir/') as home, 500 AS uid, 500 AS gid,CONCAT('maildir:storage=', quota) as quota FROM mailbox WHERE username = '%u'

• CONCAT('/home/virtual/mail/',maildir, 'Maildir/') parce que la base construite par postfixadmin ne contient que le chemin relatif du répertoire de l'utilisateur et qu'il faut indiquer le chemin absolu du répertoire Maildir ;
• CONCAT('maildir:storage=', quota) parce que la base ne contient que la valeur nupérique, alors qu'il faut transmettre à Dovecot la chaîne de paramétrage complète.

Postfixadmin peut gérer les valeurs de quotas dans la table mailbox. Cependant, dans un souci de simplification probablement, la valeur saisie doit être exprimée en Mio¹⁾ et elle est convertie (de façon approximative) en octets dans la base. Ainsi, lorsque nous mettons 4 dans le formulaire de postfixadmin, celui-ci écrit 4096000 dans la base. Comme le plug-in quota demande des valeurs en Kio, notre requête SQL est donc à revoir comme ceci :

user_query = SELECT CONCAT('/home/virtual/mail/',maildir, 'Maildir/') as home, 500 AS uid, 500 AS gid, CONCAT('maildir:storage=', floor(quota/1000)) as quota FROM mailbox WHERE username = '%u'

Voilà qui commence à faire une belle requête.