Contents

  1. Apperçu
    1. Formations préalables
    2. Temps estimé
    3. Objectifs
  2. Préparation des participant.e.s
  3. Survol du sujet
  4. C'est quoi que ça fait un MDA?
  5. Configuration
    1. Authentification
    2. Services démarrés par Dovecot
    3. SSL/TLS
    4. Emplacement sur disque des boîtes courriels
    5. Plugins
  6. Rétrospective
  7. Information complémentaire

Apperçu

Formations préalables

Temps estimé

On vise 1h à 1h30

Objectifs

Préparation des participant.e.s

Les exercices se feront à l'aide d'une VM locale, via le control repository, qui utilise AlternC:

Survol du sujet

Dovecot est un MDA (Mail Delivery Agent), mais ça rempli également une couple d'autres fonctions additionnelles dont on peut se servir.

Pour un petit rappel de l'information dans FormationPostfix:

FormationPostfix/E-mail.svg

MUA
Mail User Agent, une application cliente tel que Thunderbird, Webmail, ou php-mailer. Un MUA devra généralement utiliser le protocole SMTP pour envoyer des emails en se connectant à un MTA. La pluspart des MUA permettent également de consulter les emails en utilisant les protocoles POP3 ou IMAP.
MTA
Mail Transfer Agent, une application qui reçoit et transmets les courriels à l'aide du protocole SMTP. La transmission vers d'autres MTA demande une coordination qui passe par l'enregistrement MX du DNS. Quelques exemples de MTA sont: postfix, exim4, qmail.
MDA
Mail Delivery agent, une application qui prends les courriels pour les stocker à long terme. Certains MDA remplissent ce rôle de manière exclusive, comme par exemple Dovecot. Certains MTA peuvent également remplir le rôle de MDA: par exemple postfix peut se charger du stockage (mais ses fonctionnalités sont plus limitées que ce que Dovecot offre)

Quelques fonctions additionelles que Dovecot peut remplir:

C'est quoi que ça fait un MDA?

Le but principal d'un Mail Delivery Agent c'est de gérer le stockage à long terme des courriels, donc sur disque. Différents formats de stockage peuvent être choisis selon les besoins comme mbox, Maildir et une variante non-standard de Maildir implémentée par dovecot seulement nommée dbox.

Koumbit utilise Maildir: chaque répertoire de mailbox est un répertoire sur disque et un email est représenté par un fichier dans un répertoire.

Une fois que le email est archivé sur disque, il faut également que le MDA permette sa lecture, quand les personnes veulent consulter leur courriels, et donc deux protocoles de consultation de emails sont rendu disponibles par Dovecot:

Donc on a généralement besoin d'un MDA en plus d'un MTA.

Configuration

Tous les fichiers de configuration de Dovecot se trouvent sous /etc/dovecot/conf.d/.

On ne jettera pas un coup d'oeil sur tous les fichiers de configuration pendant la formation, mais ce qui est présenté représente la majorité des fonctionnalités utiles.

Authentification

On ne veut normalement pas que n'importe qui puisse lire les emails de n'importe qui d'autre. Donc on veut configurer une forme d'authentification.

La séparation des configurations dans les fichiers sous conf.d n'est pas obligatoire mais plutôt logique. On peut avoir des configurations pour les différentes sections dans un fichier additionnel: c'est d'ailleurs ce qu'AlternC a tendance à faire.

Le fichier principal pour ça c'est 10-auth.conf. Le fichier contient généralement seulement quelques valeurs globales, puis on peut inclure un autre fichier pour compléter les détails de l'authentification selon la méthode utilisée pour trouver et comparer les informations d'authentification.

Lorsqu'on utilise AlternC, celui-ci a ne touche pas au fichier 10-auth.conf mais va plutôt ajouter les informations d'authentification dans un fichier en plus, 95_alternc.conf.

Dovecot peut utiliser différents mécanismes pour retrouver l'information d'authentification:

Pour configurer l'authentification, on a besoin de deux blocs de configuration: un pour dire à Dovecot comment trouver les mots de passe et un autre pour dire à Dovecot comment trouver les informations des utilisateurs (comme leur répertoire de stockage, leur UID si nécessaire). On peut jeter un coup d'oeil au fichier auth-sql.conf.ext, qui défini les deux blocs et ensuite consulter le fichier qui y est référé, /etc/dovecot/dovecot-sql.conf.ext.

Dans le dernier, on y met les informations de connexion à MySQL (ou une autre base de données si nécessaire), puis deux requêtes nommées password_query et user_query qui nous aideront à trouver l'information pour les deux blocs de configuration.

Pour voir un exemple un peu plus concret d'une configuration d'authentification via SQL, on peut vérifier comment AlternC configure ces deux requêtes. Le fichier /etc/dovecot/alternc-sql.conf contient les exemples de requêtes SQL pour trouver l'information dans la base de données d'AlternC: 

user_query = select \
       `mailbox`.`path` AS `home`, \
       `domaines`.`compte` AS `uid`, \
       1998 as gid, \
       concat('*:storage=',cast(`mailbox`.`quota` as char charset latin1),'M') AS `quota_rule` \
       from `mailbox` join `address` on `address`.`id` = `mailbox`.`address_id` join `domaines` on `domaines`.`id` = `address`.`domain_id` where `address`.`enabled` = 1 and `domaines`.`gesmx`=1 and `domaines`.`domaine`='%d' and `address`.`address`='%n'

password_query = select  \
       concat(`address`.`address`,'@',`domaines`.`domaine`) AS `user`, \
       `address`.`password` AS `password`, \
       `mailbox`.`path` AS `userdb_home`, \
       `domaines`.`compte` AS `userdb_uid`, \
       1998 as userdb_gid, \
       concat('*:storage=',cast(`mailbox`.`quota` as char charset latin1),'M') AS `userdb_quota_rule` \
       from  `mailbox` join `address` on `address`.`id` = `mailbox`.`address_id` join `domaines` on `domaines`.`id` = `address`.`domain_id` where (`address`.`enabled` = 1) and `domaines`.`domaine`='%d' and `address`.`address`='%n';

Services démarrés par Dovecot

Dans le fichier 10-director.conf, on peut retrouver quels services seront démarrés par Dovecot et avec quelles permissions.

Donc c'est généralement là qu'on configure la disponibilité d'IMAP, POP3 et LMTP par exemple si on subdivise le stockage en plusieurs machines (LMTP permet de réacheminer un courriel à l'autre machine qui est réellement destinataire pour le stocakge)

Donc dans le fichier, on pourra y voir surtout des blocs de configuration dénotés par service comme pour l'authentification SASL mise en place pour que Postfix puisse retrouver le socket unix: 

service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
  unix_listener auth-master {
    mode = 0600
    user = vmail
  }
}

Ou alors pour IMAP. Dans l'exemple plus bas, AlternC ajoute une définition pour un script qui doit être exécuté après chaque login (c'est ça qui met à jour la date de dernier login pour les boîtes courriels): 

service imap {
  # tell imap to do post-login lookup using a socket called "imap-postlogin"
  executable = imap postlogin
  vsz_limit = 2048M
}

# The service name below doesn't actually matter.
service postlogin {
  # all post-login scripts are executed via script-login binary
  executable = script-login /usr/lib/alternc/popimap-log-login.sh

  # this UNIX socket listener must use the same name as given to imap executable
  unix_listener postlogin {
  }
}

On peut voir également plus haut une option pour IMAP pour permettre au service d'avoir jusqu'à 2Gb de mémoire virtuelle. C'est une option qu'on a due augmenter avec les années pour éviter que notre service ne manque de mémoire.

En plus de la configuration sous 10-director.conf, les services ont également des configurations dans le fichier 10-master.conf. Celles-ci définissent plutôt comment les protocoles exposés se comportent. Par exemple: 

service imap {
  # Most of the memory goes to mmap()ing files. You may need to increase this
  # limit if you have huge mailboxes.
  #vsz_limit = $default_vsz_limit
  vsz_limit = 1024M
  process_min_avail = 16

  # Max. number of IMAP processes (connections)
  process_limit = 1024
}

La séparation entre les deux fichiers semble un peu arbitraire..

SSL/TLS

On ne peut plus vivre sur Internet sans offrir des services qui n'ont pas d'encryption pendant l'échange d'information sur réseau. Pour configurer le TLS, on utilise le fichier 10-ssl.conf. On y retrouve surtout deux options, l'emplacement des fichiers de certificat et de clef privée: 

ssl_cert = /etc/letsencrypt/live/pop.koumbit.net/fullchain.pem
ssl_key = /etc/letsencrypt/live/pop.koumbit.net/privkey.pem

Le même certificat sera utilisé pour tous les protocoles avec encryption.

Emplacement sur disque des boîtes courriels

Dans le fichier 10-mail.conf, on spécifie où Dovecot peut trouver dans le filesystem les boîtes courriels et aussi comment est nommé le répertoire par défaut des boîtes et comment on représente une séparation de répertoire dans les noms des répertoires: 

mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_plugins = zlib
namespace inbox {
  inbox = yes
  prefix = INBOX.
  separator = .
}

Ici on peut voir mail_location qui indique que les utilisateurs locaux à la machine ont un stockage sous format mbox (qui dans notre cas n'a pas été configuré comme format par défaut) dans le fichier mail sous le répertoire maison de chaque utilisateur. L'option spécifie également un répertoire INBOX qui se trouve sous /var/mail/nomdeuser (le %u se fait remplacer automatiquement par le nom d'utilisateur).

On remarque également la définition du répertoire INBOX en tant que boîte de réception par défaut.

Le séparateur configuré ici est ., donc sur disque comme on utilise le format Maildir par défaut, on va retrouver sous les répertoires de stockage des mails des répertoires nommés selon le nom des répertoires de courriels.

L'option prefix ne semble pas trop être utilisée dans le cas des Maildir -- en tout cas sur homere.

Dans le cas d'un Maildir, le répertoire par défaut est toujours le répertoire Maildir lui-même.

Dans le cas de Maildir, chaque répertoire de boîte de courriel contiendra trois répertoires:

Si par exemple une personne a créé dans sa boîte de courriels un répertoire nommé achalemoipas, et si sous ce répertoire là la personne a également créé un sous-répertoire nommé ahpaslui, on va retrouver les répertoires suivant dans le Maildir: 

# tree -a
├── cur
├── new
├── tmp
├── subscriptions
├── dovecot.index
├── dovecot.index.cache
├── dovecot.index.log
├── dovecot.index.log.2
├── dovecot-keywords
├── dovecot.mailbox.log
├── dovecot.mailbox.log.2
├── dovecot-uidlist
├── dovecot-uidvalidity
├── .achalemoipas
│   ├── cur
│   ├── dovecot.index
│   ├── dovecot.index.cache
│   ├── dovecot.index.log
│   ├── dovecot-keywords
│   ├── dovecot-uidlist
│   ├── maildirfolder
│   ├── new
│   └── tmp
├── .achalemoipas.ahpaslui
│   ├── cur
│   ├── dovecot[.*]
│   ├── maildirfolder
│   ├── new
│   └── tmp
├── .Sent
│   ├── cur
│   ├── dovecot[.*]
│   ├── maildirfolder
│   ├── new
│   └── tmp
└── .Trash
    ├── cur
    ├── dovecot[.*]
    ├── maildirfolder
    ├── new
    └── tmp

NOTE: L'ordre des fichiers est un peu modifié dans l'exemple plus haut pour aider à comprendre ce qui va ensemble. Aussi, comme les fichiers d'index et log de dovecot se retrouvent dans chaque sous-répertoire ceux-ci ont été abrégés par [.*].

Donc l'inbox c'est cur, new et tmp au premier niveau. On retrouve également un fichier spécial nommé subscriptions: c'est là dedans que dovecot inscrit à quels répertoires la personne s'est incrite et donc lesquels seront affichés par les clients de courriels. On y retrouve également quelques fichiers avec un nom qui commence par dovecot et ceux-ci sont pour utilisation interne à Dovecot par exemple pour créer un index des fichiers de courriels pour accélérer la consultation et pour conserver certaines erreurs dans un log.

Ensuite le répertoire achalemoipas s'appelle sur disque .achalemoipas. Ce répertoire là contient lui aussi cur, new et tmp et différents fichiers ajoutés par dovecot.

Le sous-répertoire achalemoipas/ahpaslui se nomme .achalemoipas.ahpaslui. Notez qu'il ne se trouve pas sous le répertoire .achalemoipas mais bien au premier niveau lui aussi. C'est les points dans le nom du répertoire qui représentent des sous-répertoires pour la mailbox et non des sous-répertoires dans le filesystem. Encore une fois on y retrouve les mêmes choses que dans les autres cas, donc cur, new, tmp et des fichiers doveot.

Finalement on a aussi deux répertoires spéciaux qui sont créés automatiquement: .Sent et .Trash. Un certain nombre de ces répertoires spéciaux sont créés par Dovecot lors de la création d'une boîte courriel et on s'attend donc à ce qu'ils soient toujours présent. Ceux-ci contiennent les mêmes choses que les répertoires détaillés plus haut.

Plugins

Les fonctionnalités additionnelles de Dovecot sont assurées par des plugins. Le fichier 90-plugins.conf déclare quelques options globales pour les plugins. Par exemple, sur homere on a: 

plugin {
  zlib_save = gz
  zlib_save_level = 6

  quota_rule = *:storage=100M

  # Sieve plugin (http://wiki.dovecot.org/LDA/Sieve) and ManageSieve service
  #
  # Location of the active script. When ManageSieve is used this is actually
  # a symlink pointing to the active script in the sieve storage directory.
  sieve=~/.dovecot.sieve
  #
  # The path to the directory where the personal Sieve scripts are stored. For
  # ManageSieve this is where the uploaded scripts are stored.
  sieve_dir=~/sieve
  sieve_before = /var/lib/dovecot/sieve/before.sieve

}

qui défini donc le type de compression désiré pour les emails, une règle de quota de stockage et des informations sur comment trouver les script Sieve pour le filtrage.

On peut également définir un liste globale de plugins. Ceux-ci seront utilisés pour tous les protocoles. Etrangement, cette déclaration se trouve dans 10-mail.conf au lieu de 90-plugin.conf -- c'est peut-être pour que la liste de plugins soit déjà disponible dans certaines déclarations traitées avant 90-plugin.conf?

La définition de quel plugin est utilisé pour chaque protocole se fait dans la configuration de chaque protocole, donc dans un fichier pour chaque protocole. Par exemple, 20-imap.conf déclare les informations pour le protocole IMAP: 

protocol imap {
  # Support for dynamically loadable plugins. mail_plugins is a space separated
  # list of plugins to load.
  mail_plugins = $mail_plugins quota imap_quota imap_zlib
  #mail_plugin_dir = /usr/lib/dovecot/modules/imap
  #mail_max_userip_connections = 500
}

Donc on voit ici qu'en plus des plugins globaux (définis dans $mail_plugins) on utilise les plugins quota, imap_quota et imap_zlib.

D'autres fichiers qui définissent des protocoles sont par exemple 20-managesieve.conf et 20-pop3.conf

Certains plugins comme quota ont besoin de ressources additionnelles pour stocker et retrouver de l'information. Pour ça, il faut configurer un bloc de configuration dict. Celui-ci n'est pas présent par défaut mais on peut l'ajouter par exemple dans le fichier 90-plugin.conf. Dans le cas d'AlternC comme pour toutes les autres configurations, on retrouve ce bloc là sous le fichier 95_alternc.conf: 

dict {
  quotadict = mysql:/etc/dovecot/alternc-dict-quota.conf
}

Donc dans ce cas là, les quotas sont stockés puis retrouvés à l'aide de MySQL selon les informations de connexion et de requêtes dans le fichier /etc/dovecot/alternc-dict-quota.conf

Rétrospective

Pendant un maximum de 15 minutes, les participant.e.s sont invité.e.s à partager les éléments qui ont bien ou moins bien fonctionnés et les idées qui pourraient survenir pour des manières d'améliorer le processus.

Quelques éléments qui peuvent faire partie de la rétrospective, dépendant de la grosseur du projet ou de la formation:

  • Sommaire collectif (e.g. résumé rapide en termes que tout le collectif peut comprendre)

    • Pas trop utile pour les projets vraiment simples ou les formations.

  • Chronologie des événements marquant pour le projet

    • Surtout utile pour les projet qui se sont étalés sur plusieurs jours ou plus ou bien quand beaucoup de choses se sont produites simultanément, ce qui a rendu la compréhension des influences de chaque événement complexe.

  • Les bons coups -- qu'est-ce qui a bien fonctionné et qu'on veut tenter de reproduire
  • Les problèmes
    • échecs -- avec l'aide de la chronologie (si elle a été faite), tenter de situer les échecs dans un contexte selon ce qui était connu des participant.e.s aux moments qui ont mené à l'échec
    • problèmes techniques
    • manques de ressources
    • perturbations externes
  • Une liste d'actions à court et/ou à plus long terme pour améliorer les choses telles que soulignées pendant les points précédents
    • Transférer les actions dans redmine pour qu'elles puissent être suivies!

N'hésitez pas à partager les échecs à l'extérieur de l'équipe puisqu'on peut apprendre beaucoup de ceux-ci, mais surtout évitez de les formuler comme un blâme sur la/les personne(s) ayant échoué.

Une rétrospective est surtout utile quand on la partage: ça permet aux autres d'apprendre de nos erreurs et aussi de nos idées d'améliorations. On peut par exemple envoyer une forme écrite par email, ou bien sauvegardée comme page wiki.

Information complémentaire

CategoryFormation CategoryFormationPublique

FormationDovecot (last edited 2023-06-28 12:03:25 by virgile)