Conclusions

Nous avons une configuration de messagerie opérationnelle, qui fonctionnera:

1. correctement pour tous les messages entrants, avec un filtrage plutôt efficace des spams,
2. sans présenter un relai ouvert pour les malveillants (aussi longtemps que l'hôte ne sera pas compromis…),
3. à peu près correctement pour l'envoi de messages. Les adresses IP de l'hôte pouvant se retrouver dans des listes noires un peu trop totalitaires par exemple. Gmail pour sa part réclame une validation de la propriété du domaine. Cette validation peut se présenter sous la forme d'un enregistrement TXT dans la zone DNS (encore un de plus) Le contenu de ce texte peut s'obtenir à partir de la «google-search-console».

Nous ne gérons qu'un seul domaine, avec des comptes d'utilisateurs de type «système», mais qui n'ont pas accès à un shell pour des raisons de sécurité. D'autres solutions sont possibles, en créant un fichier de même structure que le fichier passwd du système.

Si l'on a en vue de gérer plusieurs domaines, alors la méthode de virtualisation est à envisager. Dans ce cas les comptes peuvent avantageusement être stockés dans une base de données SQL.

Nous n'avons pas abordé «Sieve» qui offre l'avantage de trier les messages entrants suivant des règles qui peuvent être très fines. Le véritable intérêt de cet outil n’apparaît que si chaque utilisateur a la possibilité d'aménager ses propres filtres. Dans notre configuration, ce n'est pas réellement possible, bien que le LDA de Dovecot le permette. Il faut en effet d'une part configurer Dovecot pour utiliser le plugin sieve et d'autre part créer un fichier contenant les règles de filtrage dans le répertoire de l'utilisateur.

Le Webmail «roundcube» n'a pas été installé. Il nécessite de nombreuses dépendances, dont un serveur HTTP, un interpréteur PHP, une base de données SQL… Notons qu'il sait gérer Sieve si besoin, mais tout ceci est en dehors de notre cahier des charges.