FIXME : Effectuer une relecture en condition réelles (sous 15 jours) FIXME : Rerédaction complète pour une meilleure présentation (depuis Word vers optimisé pour Gandi Wiki) (en cours) ====== Installation d'un serveur mail avec backend OpenLDAP ====== À travers ce tutoriel, je vous présenterai, étape par étape, le processus de création d'un serveur mail complet, et ce à partir de vos ressources Gandi Hébergement. Ce tutoriel traite de : - La création de votre serveur sur Gandi - L'installation d'un serveur LDAP ainsi que des utilitaires clients (OpenLDAP) - L'installation d'un serveur de messagerie électronique (Postfix) - L'installation de binaires pour l'authentification SMTP (Cyrus-SASL) - L'installation d'un serveur IMAP et POP3 (Dovecot) Ce tutoriel ne traite pas de : * L'installation d'un serveur web de gestion (hors-sujet, car nécessitant l'installation d'un autre type de serveur (web)) * La sécurisation SSL (cela sera traité dans un second volet à venir) * La sécurisation du serveur LDAP et la gestion des permissions (cela sera également traité dans un second volet à venir) * La gestion avancée des comptes mails (quotas, ...) (cela sera également traité dans un second volet à venir) ===== Installation d’OpenLDAP ===== Pour stocker les adresses email, utilisateurs, mots de passe et alias, le choix entre un annuaire LDAP ou un serveur SQL est possible. SQL offre un stockage performant, toutefois, la solution LDAP a été choisie pour plusieurs raisons : * En terme de stockage d'utilisateurs, LDAP offre de meilleurs performances que SQL pour une raison simple, LDAP est fait pour stocker des utilisateurs, c'est son rôle, alors que le rôle de SQL est de stocker des données quelconques. Pour faire une rapide analogie, comparer LDAP et SQL pour le stockage d'utilisateurs, c'est comme comparer un champion olympique de natation et un champion olympique de triathlon sur un 50 mètres. Les deux sont de très bons nageurs et ont de très bonnes performances, toutefois, le champion olympique de natation sera meilleur. De la même façon, pour stocker les utilisateurs, les performances de SQL et de LDAP seront très bonnes, toutefois, les performances de LDAP seront meilleures. * LDAP, comme son nom l'indique (D = Directory = répertoire, annuaire) permet de bénéficier de fonctionnalités d'annuaires. En le configurant correctement, vous pourrez l'utiliser avec des messageries comme Thunderbird, ou bien Outlook pour accéder à la liste des adresses email. Ainsi, pour ces deux raisons, le choix se portera sur LDAP ==== Installation et configuration de base ==== === Installation === Pour installer OpenLDAP, rien de compliqué : exécutez la commande suivante : apt-get install –y slapd L'outil de configuration vous demande alors le mot de passe de l'administrateur. Choisissez un mot de passe complexe, et si possible différent du mot de passe root de votre machine. Une fois que vous avez validé votre choix, l'installation devrait se poursuivre et se terminer sans aucune intervention nécessaire de votre part === Configuration de base === Une fois l'installation terminée, il est nécessaire de rensigner plus d'aspects dur la configuration de votre serveur. Pour se faire, entrez la commande suivante : dpkg-reconfigure slapd * Le premier écran vous proposera de rénoncer à la configuration de LDAP. Répondez Non * Le second écran vous demande le DNS. Il est préférable d'utiliser uniquement votre domaine (à savoir domaine.tld) en n'incluant pas le nom d'hôte (et non pas ldap.domaine.tld) * Le troisième écran vous demande le nom de l'organisation. Il ne sera pas utile pour suivre ce tutoriel, mettez ce que vous désirez * Le quatrième écran vous demande le mot de passe administrateur. Attention, il ne s'agit pas du même compte que celui de la première étape. Alors que le compte concernant la première étape aura les droits sur l'arborescence de la configuration, cet administrateur aura les droits sur l'arborescence de votre domaine. Si tout n'est pas très clair pour le moment, c'est normal. Choisissez juste un mot de passe, vous comprendrez normalement mieux par la suite * Le cinquième écran vous demande le moteur de base de données que vous souhaitez utiliser. Choisissez HDB. * Le sixième écran vous demande si la suppression de slapd doit être accompagnée de la suppression des données stockées par le serveur. Répondez non, cela pourra être pratique si vous désinstallez par erreur (oui, ça peut arriver) * Pour le septième écran, laissez la valeur par défaut et donc répondez Yes. * Le huitième et dernier écran vous demande si vous souhaitez activer le protocole LDAPv2, devenu obsolète. Si vous souhaitez, par la suite, interroger votre annuaire avec d'ancienne versions de Windows et/ou Outlook (qui ne supportent pas la version 3 du protocole), répondez Yes. Dans le cas contraire, aucun intérêt à l'activer. Voilà, la première configuration de base est terminée. ==== Configuration supplémentaires ==== Une mise à jour d'OpenLDAP a revu entièrement la configuration d'OpenLDAP, celle ci se faisant avant au moyen d'un fichier (/etc/ldap/slapd.conf) et s'effectuant maintenant au moyen d'une entrée dans le serveur (cn=config). Certains utilitaires permettent (slaptest pour citer le plus utilisé), permettent d'effectuer directement la conversion de fichiers écrits suivant le modèle de cet ancien fichier, vers des fichiers LDIF (permettant d'ajouter/modifier des entrées dans l'annuaire). Beaucoup de tutoriels effectuent toutes la configuration du serveur à l'aide de slaptest. Dans ce tutoriel, le choix a été de n'utiliser slaptest que dans son but premier, à savoir la migration d'anciens fichiers de configuration vers le nouveau format. Ainsi, pour la configuration des accès, ce tutoriel vous indiquera comment effectuer directement les modifications dans l'annuaire. Quant à l'ajout de l'extension du schémas, proposée par Courier et non mise à jour pour ce nouveau format de configuration, vous passerez par l'utilitaire slaptest pour effectuer la mise à jour de la configuration des schémas. Ainsi, pour pouvoir communiquer avec l'annuaire, vous aurez besoin des utilitaires clients d'OpenLDAP : apt-get install -y ldap-utils === Modification des règles d'accès === Premièrement, vérifiez si, en vous connectant de manière anonyme à la branche principale votre annuaire, vous parvenez à accéder aux données de cette dernière : ldapsearch -x -h localhost -b "dc=uncertaindomaine,dc=net" -LLL "dc=uncertaindomaine" dn Le résultat qui devrait apparaître suita à cela est : dn: dc=uncertaindomaine,dc=net Ce résultat indique qu'il est possible, pour un utilisateur anonyme, d'accéder aux données de cette branche votre annuaire (avec certaines limitations tout de même, vous n'aurez pas accès par exemple au hash des password utilisateurs en anonyme). Il serait tout de même préférable de ne pas autoriser l'accès aux données de cette branche de notre annuaire par un utilisateur anonyme. L'arborescence de cn=config est très fournie. Lister toutes les données de cette branche fournirait un résultat inexploitable, de part la quantité importante d'informations qu'il nous renverrait. Il faut savoir aussi ce que nous allons chercher, car l’arbre de la configuration est très fourni, donc nous allons devoir effectuer un filtre de recherche pour n’avoir que l’entrée que nous désirons. ** Apprendre à pêcher plutôt qu'offrir le poisson ** Pour savoir où se situe, dans votre annuaire, certaines données spécifiques, vous pouvez vous rendre sur la documentation de OpenLDAP, très complète sur le sujet. Tout d'abord, vérifier la version de votre serveur OpenLDAP : slapd -V Cette commande devrait vous renvoyer un résultat comparable au suivant : @(#) $OpenLDAP: slapd 2.4.23 (Jun 15 2011 13:31:57) $ @incagijs:/home/thijs/debian/p-u/openldap-2.4.23/debian/build/servers/slapd Une fois que vous connaîtrez la version de votre serveur (ici, 2.4.23), rendez-vous sur la [[http://www.openldap.org/doc/index.html|liste des documentations OpenLdap]], et choisissez la documentation correspondant à votre version (ici, la documentation choisie sera celle concernant la version 2.4) Dans cette documentation, vous devriez trouver une partie sur la configuration de slapd (la cinquième partie pour la documentation de la version 2.4). Vous trouverez dans cette partie toute la structure de l'arborescence cn=config, ainsi que le rôle de chacune des entrées, et le rôle de chacun des attributs. Selon la documentation d'OpenLDAP, il apparaît que les entrées contenant la configuration d'une arborescence sont contenues dans des entrées de type olcDatabaseConfig, et que le DN (Nom Distinct, ayant le sens de référence unique) de l'arborescence est contenue dans l'attribut olcSuffix. Nous allons donc afficher les données de l'arborescence cn=config en appliquant le filtre correspondant. Pour comprendre parfaitement la syntaxe des filtres dans ldapsearch, je vous conseille fortement [[http://download.oracle.com/docs/cd/E19199-01/816-6696-10/cmdline.html#LDAP%20Search%20Filters|LDAP Search Filters par Oracle]]. La partie affichée ne concerne que les filtres, mais la page entière donne de nombreuses informations sur ldapsearch, ainsi que de nombreux exemples. Ainsi donc, voici la commande nous permettant d'afficher les informations sur la configuration de notre arborescence : ldapsearch -Y EXTERNAL -H ldapi:// -b cn=config "(&(objectClass=olcDatabaseConfig)(olcSuffix=dc=uncertaindomaine,dc=net))" Une fois la commande exécutée, vous devriez avoir un résultat semblable à : SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=olcDatabaseConfig)(olcSuffix=dc=uncertaindomaine,dc=net)) # requesting: ALL # # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=uncertaindomaine,dc=net olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=uncertaindomaine,dc=net olcRootPW: {SSHA}votrePassEncodé olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Dans cette entrée, les entrées intéressantes sont les trois attributs olcAccess ainsi que leurs valeurs respectives. En particulier, voici la traduction de la dernière de ces trois lignes : * to * (sur l'ensemble de l'arborescence) * by self write (lorsque votre authentification correspond à une entrée de l'annuaire, vous avez les droits en écriture sur cet objet) * by dn="cn=admin,dc=uncertaindomaine,dc=net" write (l'administrateur possède les droits en écriture sur toute l'arborescence) * by * read (tout le monde a accès en lecture à l'arborescence) Comme vous pouvez vous en douter, la partie qui pose problème est la dernière partie (by * read), qu'il faudra remplacer par (by * none). Pour se faire, nous allons utiliser un autre outil du paquet ldap-utils, à savoir ldapmodify. **ATTENTION** : La manipulation de la configuration d'une arborescence est critique, en particulier en ce qui concerne les règles d'accès. Une mauvaise manipulation pourrait vous supprimer les accès à votre arborescence. Soyez donc très vigilant, et nous vous recommandons, sur notre modèle, d'effectuer les copier/coller depuis vos propres résultats (qui peuvent éventuellement différer) obtenus précédemment, et non depuis l'exemple donné dans ce tutoriel. ** No bullshit ** Nous allons donc modifier l'attribut olcAccess. Comme vous avez pu le remarquer, cet attribut est répété plusieurs fois pour cette entrée, afin de définir plusieurs règles d'accès. Il y a bien entendu moyen de modifier uniquement la dernière ligne de ces trois attributs, mais lorsque je m'y suis essayé, cela produisait des erreurs chez moi. Normalement, j'aurais du me contenter de vous présenter le code suivant : dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {2}to * by self write by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * read - add: olcAccess olcAccess: {2}to * by self write by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none - Toutefois, en appliquant ce dernier chez moi, j'obtiens une erreur m'indiquant que la ligne que je cherche à supprimer n'existe pas. Ainsi, je vous présenterai ici la seule solution de contournement que j'ai trouvée, supprimer tous les attributs olcAccess pour tous les rajouter. Ceci n'est pas la bonne méthode, j'en suis conscient, et elle a en plus l'inconvénient de rendre la manipulation plus dangereuse que ce qu'elle était, mais c'est la seule solution que j'ai trouvée pour le moment. Si quelqu'un me donne la raison pour laquelle je rencontre cette erreur, je corrigerai le tutorial en fonction. ** Une autre solution ** Pour contourner cela, j'ai simplement ouvert le fichier concerné dans un éditeur de texte pour le modifier. Voici, en l’occurrence les commandes que j'ai exécutées : nano /etc/ldap/slapd.d/cn_config/olcDatabase={1}hdb.ldif Le contenu du ficher d'affiche. Je modifie la ligne concernée (by * read devient by * none). Je sauvegarde la modification en fermant le fichier. Je redémarre le service : /etc/init.d/slapd restart Le test ci-dessous est OK. Le tour est joué. Notez que pour les allergiques à la ligne de commande, cette modification est aussi accessible par une interface graphique type Virtualmin qui propose un explorateur de fichier (voir installation [[http://wiki.gandi.net/fr/hosting/gandi-expert/panel/virtualmin|ici]]). Ceci est une alternative à la solution proposée ci-dessous, chacun choisira selon ses goûts. Exécutez la commande suivante pour créer donc notre fichier temporaire (encore une fois, exécutez les copier/coller depuis vos résultats, et non pas depuis ce tutorial : cat > changeAccess.ldif << EOF dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess - add: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none - add: olcAccess olcAccess: {1}to dn.base="" by * read - add: olcAccess olcAccess: {2}to * by self write by dn="cn=admin,dc=uncertaindomaine,dc=net" write by * none - EOF Comme vous pouvez le remarquer, la seule modification apportée est le remplacement de read par none à la fin du dernier attribut. Une fois ce fichier créé (pour lequel vous vérifierez plutôt deux fois qu’une le contenu), vous pouvez appliquer les modifications de ce fichier dans votre base : ldapmodify -c -Y EXTERNAL -H ldapi:/// -f changeAccess.ldif Le résultat devrait être semblable à ça : SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}hdb,cn=config" Une fois ceci fait, vérifions que nous n'avons bien plus accès à notre base en anonyme : ldapsearch -x -c -h localhost -b dc=uncertaindomaine,dc=net Le résultat devrait être semblable à celui-ci : # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 Le no such object indique que la configuration est bonne. Le serveur indique qu'il n'y a pas d'objet dc=uncertaindomaine,dc=net. Ce qui est tout à fait logique puisque les règles empêchent un anonyme d'accéder à cette arborescence. Essayons maintenant en nous connectant en administrateur ldapsearch -c -h localhost -b dc=uncertaindomaine,dc=net -D "cn=admin,dc=uncertaindomaine,dc=net" -W Une fois que vous avez renseigné le mot de passe, vous devriez avoir un résultat semblable à celui-ci : # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # uncertaindomaine.net dn: dc=uncertaindomaine,dc=net objectClass: top objectClass: dcObject objectClass: organization o: UnCertainDomaine dc: uncertaindomaine # admin, uncertaindomaine.net dn: cn=admin,dc=uncertaindomaine,dc=net objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: passwordHashé # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Nous voyons bien nos résultats. Ainsi, nous pouvons considérer que la configuration de notre arborescence est bonne. Seconde petite modification de la configuration, nous allons étendre le schéma actuel pour qu’il soit en adéquation avec les fonctionnalités de Postfix. Bien que nous n’utiliserons pas Courier comme serveur POP/IMAP, nous allons tout de même nous servir des extensions de schéma LDAP qu’il propose, dans le sens où il est très complet, documenté dans des RFC, et donc meilleur pour la portabilité. apt-get install –y courier-ldap La première (et dernière) question vous propose d’installer les répertoires nécessaires à l’administration web. Étant donné que nous n’utiliserons pas Courier, vous pouvez répondre non pour en installer le minimum. Nous allons donc extraire l’archive gzip contenant le schéma en question, et copier ce dernier dans le répertoire contenant les schémas ldap. gunzip /usr/share/doc/courier-authlib-ldap/authldap.schema.gz cp /usr/share/doc/courier-authlib-ldap/authldap.schema /etc/ldap/schema Nous allons voir maintenant une seconde méthode pour modifier la configuration de OpenLDAP, à savoir l’utilisation de slaptest. Mais avant ceci, nous avons besoin de savoir quels sont les schémas que OpenLDAP intègre déjà. Pour se faire, nous allons parcourir la base cn=schema,cn=config de notre arbre, et nous allons nous limiter à l’attribut cn (Common Name) car les entrées correspondant aux schémas étant très fournies, le résultat en serait vite indigeste. Toujours dans le souci de rendre le schéma plus digeste et de vous en faire connaître d’avantage sur ldapsearch, nous allons également utiliser –LLL qui va nous permettre de supprimer les commentaires et versions Ldif. Ainsi, notre commande sera : ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=schema,cn=config" -LLL "(objectClass=*)" cn Le résultat devrait être semblable à celui-ci : SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=schema,cn=config cn: schema dn: cn={0}core,cn=schema,cn=config cn: {0}core dn: cn={1}cosine,cn=schema,cn=config cn: {1}cosine dn: cn={2}nis,cn=schema,cn=config cn: {2}nis dn: cn={3}inetorgperson,cn=schema,cn=config cn: {3}inetorgperson Ainsi, de notre résultat, nous pouvons en conclure qu’openLDAP intègre quatre schémas (dans cette configuration), à savoir core, cosine, nis et inetorgperson. Il nous faudra également ajouter l’extension courier que nous venons d’ajouter au répertoire /etc/ldap/schema Créons donc un fichier qui inclura tous ces schémas (ceux déjà présents, ainsi que courier). mkdir /tmp/ldapConfig cat > /tmp/ldapConfig/schemaInclude.conf << EOF include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/authldap.schema EOF Maintenant, nous allons exécuter notre commande slaptest, qui va nous convertir ce fichier (qui correspond au format des anciens fichiers de configuration LDAP) au format ldif pour pouvoir l’inclure à notre configuration. Mais avant cela (no bullshit, je viens de le faire et de rencontrer un bug, que je vous évite donc en le corrigeant avant), nous allons éditer le fichier authldap.schema qui contient une petite erreur (en tout cas dans ma version). Dans ce fichier, on nous décrit l’objet de type CourierMailAccount, en nous indiquant qu’il peut éventuellement contenir un attribut de type mailhost. Or la description de cet attribut, qui se situe juste au-dessus dans le code est commenté. Nous avons donc deux possibilités, supprimer cet attribut de CourierMailAccount, ou bien dé-commenter la partie décrivant cet attribut. De manière purement arbitraire et sans réelle raison motivant ce choix, j’ai choisi cette dernière option. Je vous invite donc à éditer le fichier /etc/dap/schema/authldap.schema, et à supprimer les # devant les 4 premières lignes commentées décrivant cet attribut (attention, la ligne qui commence par Objects : 1.3.6[…] est, quant à elle, bel et bien un commentaire à garder. Une fois ceci fait, nous pouvons exécuter notre commande slaptest comme suit : slaptest -f /tmp/ldapConfig/schemaInclude.conf -F /tmp/ldapConfig Cette commande doit normalement vous renvoyer un message de succès. La commande slaptest nous a créé, dans le répertoire /tmp/ldapConfig toute une arborescence, correspondant à l’arborescence de configuration de LDAP. Je vous encourage à vous rendre dans le répertoire contenant nos schémas et à en observer le contenu : cd /tmp/ldapConfig/cn=config/cn=schema ls –l Vous pourrez constater la présence d’un fichier cn={x]authldap.ldif (où x est un entier variable, chez moi par exemple, c’est 4). Nous allons effectuer quelques modifications à ce fichier. Ouvrez le avec votre éditeur préférez via l’une des deux commandes suivantes : vi cn={*}authldap.ldif Ou bien nano cn={*}authldap.ldif Le premier éditeur (vi) est vraiment un éditeur puissant, et qui de plus sera installé par défaut sur n’importe quelle machine tournant sous Linux. Quant à nano, il s’agit d’une alternative très intuitive pour les non-initiés, que vous trouverez installé par défaut sur toutes les distributions Debian et dérivées (Ubuntu, …). La navigation est très intuitives (flèches) de même que l’édition. Toutefois, nano montrera ses limites dès que vous aurez à faire des éditions complexes. Un exemple ? Vous allez le voir par l’édition qui suit : Ligne 1 et ligne 3, supprimez les parties {x} (crochets inclus). En fait, il s’agit de nombres que votre serveur va attribuer automatiquement, en fonctions des dépendances, nous ne souhaitons pas intervenir là-dessus. Sur la première ligne, complétez le nom du chemin, en ajoutant : ,cn=schema,cn=config Maintenant, rendez-vous à la fin du fichier (avec vi, tapez G, avec nano, pas d’autre choix que de garder la flèche bas pressée le temps de défiler tout le fichier) Nous allons supprimer les 7 dernières lignes, qui sont là aussi des lignes que notre serveur LDAP va générer automatiquement. Vu que vous êtes à la fin du fichier, monter de 6 lignes (indispensable uniquement sur vi, 6k) Maintenant, supprimer les 7 dernières lignes. Pour se faire gardez la touche Retour arrière enfoncée sur nano (ou Suppr si vous êtes monté de 6 lignes comme indiqué précédemment). Bon courage. Sur vi, tapez simplement 7dd. Enregistrez puis quittez (Ctrl+O, puis Entrée, puis Ctrl + X sous nano, Echap, puis :wq sous vi) Pour terminer cette parenthèse sur les éditeurs, sachez que je vous encourage vivement à utiliser Vi. Tout simplement parce qu’après des débuts difficiles (et oui, comme toute nouvelle notion, il faut un temps d’adaptation), sa force vous sera évidente et vous ne pourrez rapidement plus vous en passer. Bon, revenons à la configuration. À l’heure actuelle, vous avez votre fichier cn={x}authldap.ldif, prêt à être importé dans votre configuration LDAP. Pour se faire, exécutez la commande ldapadd, dont la syntaxe est assez proche de ldapsearch et ldapmodify. ldapadd -Y EXTERNAL -H ldapi:// -f /tmp/ldapConfig/cn=config/cn=schema/cn={4}authldap.ldif Normalement, si tout se passe bien, cette commande devrait vous confirmer qu’une entrée a été ajoutée. Nous allons vérifier ça par nous-même en exécutant la commande précédente : ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=schema,cn=config" -LLL "(objectClass=*)" cn Normalement, dans le retour renvoyé, vous devriez voir le schéma authldap. Voilà, il ne nous reste plus qu’à supprimer les packages installés lorsque nous avons installé courier-ldap, à savoir : apt-get purge –y courier-ldap courier-authlib courier-authlib-ldap courier-base courier-doc Nous reviendrons plus tard sur la configuration, afin d’ajouter le SSL à notre annuaire. J’entends déjà les remarques : « Pourquoi ne pas le faire maintenant ». Et bien tout simplement, parce que si vous choisissez un certificat Gandi plutôt qu’un certificat auto-signé, il faudra que l’adresse admin@domaine.tld existe, et ce n’est pas encore le cas vu que l’on doit configurer notre serveur de mail avant. Donc maintenant, avant d’installer Postfix, nous allons créer des entrées correspondant aux adresses email que l’on souhaite créer initialement. Afin que tous les schémas possibles soit explorés, j’ai décidé d’opter pour la configuration suivante : vargisj(AROBASE)uncertaindomaine.net vargisj(AROBASE)uncertaindomaine.com vargisj(AROBASE)uncertaindomaine.org Ces trois adresses seront les mêmes. J’entends par là que je veux avoir la possibilité de me connecter avec les login (qui seront les adresses email vu que l’on est dans le cadre d’un serveur multi-domaines) de ces trois adresses, et les courriers envoyés, iront vers la même boite aux lettres. Pour configurer cela, nous créerons trois comptes mails différents, mais avec le même répertoire pour le stockage des mails. J’aurais pu choisir d’avoir plusieurs attributs mail par entrée (ce qui fonctionne très bien), le seul soucis étant que, dans un esprit de logique, avec une arborescence sous les domaines, je préfère avoir une entrée différente pour chacun des comptes mails, afin de voir directement dans chacun des domaines, la liste des emails existantes. admin(AROBASE)uncertaindomaine.net admin(AROBASE)uncertaindomaine.com Il s’agira de créer un nouveau compte pour cette adresse mail. all(AROBASE)uncertaindomaine.net Comme son nom l’indique, cette adresse email servira à envoyer un mail à tout le monde. Ainsi, lorsque vous enverrez un mail à all(AROBASE)uncertaindomaine.net, cela enverra un mail à admin(AROBASE)uncertaindomaine.net, vargisj(AROBASE)uncertaindomaine.net (les deux autres vargisj ne nous intéressent pas, vu qu’un courrier à vargisj(AROBASE)uncertaindomaine.net leur transmettra également automatiquement le courrier) J’ai créé, dans mon arborescence principale, une arborescence mail qui contiendra le tout. Pourquoi ? Tout simplement parce que peut-être que nous serons amenés à avoir d’autres choses dans notre annuaire. Ainsi, avoir une arborescence mail nous permet d’avoir un meilleur tri si besoin est pour l’avenir. Ensuite, dans cette arborescence mail, j’ai choisi d’avoir une entrée par domaine. Certains (prenons l’exemple de iRedAdmin pour n’en citer qu’un) stockent tous les domaines dans une arborescence, et tous les comptes emails dans une autre. Mon choix s’est uniquement porté sur l’aspect Annuaire de LDAP. En effet, je souhaite, par la suite, restreindre l’accès à cet annuaire par domaine. Ainsi, les utilisateurs d’un domaine n’auront accès en lecture qu’aux données concernant les utilisateurs de leur propre domaine. Si vous ne souhaitez pas pousser les permissions aussi loin, nous vous recommandons d’avoir, d’un côté, la liste des domaines, de l’autre côté, la liste des emails. En effet, mon classement présente l’inconvénient de multiplier les entrées. Il faut donc une bonne raison pour opter pour ce classement. Ensuite, dans chaque domaine, j’ai décidé de séparer les comptes mail des alias mail. Ceci n’a aucune utilité autre qu’humaine, à savoir qu’il est plus facile, lorsque vous parcourez l’annuaire, de rapidement savoir, pour un email, s’il s’agit d’un alias ou d’un véritable compte. Ceci présente plusieurs inconvénients : multiplication des entrées, … Qu’à cela ne tienne… N.B. : Vous trouverez, dans mon fichier ldif, au niveau des mots de passe utilisateurs, la chaîne {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD que je vous déconseille d’utiliser (il s’agit du hash du password 0000). Pour générer un hash des mots de passe (afin de ne pas stocker en clair le mot de passe de vos utilisateurs), vous pouvez utiliser la commande suivante (la seconde ligne étant le retour) : slappasswd -s 0000 -h {SSHA} {SSHA}H8v4t6NnK4/rtR3IMwsCIRAgttkJkGZ+ Ainsi donc, trève de beau discours, voici le fichier ldif en question (pour info, stockée dans mon répertoire /root sous le nom addingFirstValues.ldif) **ça va sans dire, mais ça va mieux en le disant (pour les étourdis comme moi).** Je précise que ne suis pas l'auteur original de ce tuto et que je me suis fait avoir ;-). Les //(AROBASE)// du fichier ci-dessous (comme ceux du test telnet plus loin) doivent être remplacés par les véritables caractères @. Gaëtan H. : Oui, en effet, à la base, j'avais mis mon propre domaine, et les adresses mail sur le net, ça occasionne du spam ;) D'où la substitution # # Création d'une arborescence mail qui contiendra l'ensemble # dn:dc=mail,dc=uncertaindomaine,dc=net dc: mail o: mail objectClass: top objectClass: dcObject objectClass: organization # # Création des entrées pour les domaines à prendre en charge # Je créée également, dans chaque domaine, une arborescence # mailAlias, et une arborescence mailAccount, afin d'avoir un # meilleur classement # dn:dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net o: uncertaindomainenet dc: uncertaindomaine.net description: virtualDomain userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net dc: mailAccount o: mailAccount objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net dc: mailAlias o: mailAlias objectClass: top objectClass: dcObject objectClass: organization dn:dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net o: uncertaindomainecom dc: uncertaindomaine.com description: virtualDomain userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net dc: mailAccount o: mailAccount objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAlias,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net dc: mailAlias o: mailAlias objectClass: top objectClass: dcObject objectClass: organization dn:dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net o: uncertaindomaineorg dc: uncertaindomaine.org description: virtualDomain userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net dc: mailAccount o: mailAccount objectClass: top objectClass: dcObject objectClass: organization dn:dc=mailAlias,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net dc: mailAlias o: mailAlias objectClass: top objectClass: dcObject objectClass: organization # #Création des comptes mails # dn:mail=vargisj(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net cn:vargisj(AROBASE)uncertaindomaine.net mail:vargisj(AROBASE)uncertaindomaine.net sn: VARGIS givenName: Julien displayName: Julien VARGIS mailbox: uncertaindomaine.net/vargisj/ homeDirectory: /home/vmail/ objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAccount userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD dn:mail=vargisj(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net cn:vargisj(AROBASE)uncertaindomaine.com mail:vargisj(AROBASE)uncertaindomaine.com sn: VARGIS givenName: Julien displayName: Julien VARGIS mailbox: uncertaindomaine.net/vargisj/ homeDirectory: /home/vmail/ objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAccount userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD dn:mail=vargisj(AROBASE)uncertaindomaine.org,dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net cn:vargisj(AROBASE)uncertaindomaine.org mail:vargisj(AROBASE)uncertaindomaine.org sn: VARGIS givenName: Julien displayName: Julien VARGIS mailbox: uncertaindomaine.net/vargisj/ homeDirectory: /home/vmail/ objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAccount userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD dn:mail=admin(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net cn:admin(AROBASE)uncertaindomaine.net mail:admin(AROBASE)uncertaindomaine.net sn: Administrator displayName: Administrator mailbox: uncertaindomaine.net/admin/ homeDirectory: /home/vmail/ objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAccount userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD dn:mail=admin(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net cn:admin(AROBASE)uncertaindomaine.com mail:admin(AROBASE)uncertaindomaine.com sn: Administrator displayName: Administrator mailbox: uncertaindomaine.com/admin/ homeDirectory: /home/vmail/ objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAccount userPassword: {SSHA}cbPM32CCzgLXhxnpSq6W7OJdg7hq+zqD dn:mail=all(AROBASE)uncertaindomaine.net,dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net cn:all(AROBASE)uncertaindomaine.net mail:all(AROBASE)uncertaindomaine.net maildrop:admin(AROBASE)uncertaindomaine.net,vargisj(AROBASE)uncertaindomaine.net sn: Everybody displayName: Everybody objectClass: top objectClass: inetOrgPerson objectClass: CourierMailAlias Une fois votre fichier créé, vous pouvez l’ajouter à votre annuaire par la commande suivante : ldapadd -D "cn=admin,dc=uncertaindomaine,dc=net" -W -h localhost -f /root/addingFirstValues.ldif Voilà, le retour, en cas de succès, devrait être semblable à celui-ci : adding new entry "dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAlias,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "dc=mailAlias,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=vargisj(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=vargisj(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=vargisj(AROBASE)uncertaindomaine.org,dc=mailAccount,dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=admin(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=admin(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net" adding new entry "mail=all(AROBASE)uncertaindomaine.net,dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net" Comme je suis presque persuadé que vous aurez des erreurs (allez, rassurez-moi, dites-moi que je ne suis pas le seul à avoir du repasser plusieurs fois sur mon fichier), et que je ne suis pas trop vache, voici une commande pour tout réinitialiser (à adapter selon l’arborescence de votre serveur) : ldapdelete -D "cn=admin,dc=uncertaindomaine,dc=net" -W -h localhost -v -r "dc=mail,dc=uncertaindomaine,dc=net" Cette commande vous sera utile dans le sens où elle vous supprimera votre arborescence mail ainsi que tout son contenu. En effet, si vous avez des erreurs dans votre fichier, et que vous le corrigez, pour ensuite exécuter ldapadd, ce dernier vous renverra une erreur, vous indiquant qu’il n’a pas pu créer l’entrée mail, qui existe déjà. Bon, vous voulez une bonne nouvelle ? On en a fini avec LDAP (pour le moment, rassurez-vous) ===== III] Installation de Postfix ===== Bon, rassurez-vous, la configuration de Postfix sera plus rapide que celle de OpenLDAP. Bon, déjà l’installation, qui, comme pour tout logiciel sous Debian ou presque, est on ne peut plus facile : apt-get install -y postfix postfix-ldap Bon, pour le premier écran, pas d’alternative, choisissez OK. Pour le second écran, il nous demande quel type de configuration nous souhaitons installer. Plusieurs choix sont possibles et génèreront des configurations différentes, celle se rapprochant le plus de notre besoin étant Internet Site, qui est déjà présélectionnée par défaut. Pour le system mail name, il vous propose tout simplement votre hostname. Postfix est connu pour être assez capricieux si cette valeur n’est pas renseignée comme il faut. Je vous conseille donc TRES VIVEMENT, de laisser cette valeur par défaut. Ne faîtes pas attention aux indications, qui ne nous concernent pas (car nous n’utiliserons que des domaines virtuels). Bon, voilà, vous avez maintenant un serveur SMTP. Bon, cela ne nous est pas très utile pour le moment, dans le sens où il va falloir le configurer. Avant de rentrer vraiment dans la configuration à proprement parler, nous allons créer l’utilisateur que Postfix utilisera pour traiter les messages. Le nom de cet utilisateur est vmail (comme précisé dans le fichier de configuration master.cf, l’importance étant toute relative, je n’entrerai pas dans plus de détails sur ce fichier). Histoire de faire simple, nous créerons un groupe du même nom, à savoir vmail, dont fera partie cet utilisateur. C’est parti (les id du groupe et de l’utilisateur ont été choisi purement arbitrairement parmi des id disponibles) : groupadd -g 2000 vmail useradd -u 2000 -g 2000 -d /home/vmail -s /bin/false -m vmail Nous allons maintenant nous amuser un petit peu avec le fichier de configuration principal de postfix, qui a un nom plus qu’explicite, à savoir /etc/postfix/main.cf smtpd_banner est sans importance ou presque ! Il s’agit du message d’accueil lorsque les clients vont se connecter en telnet. Nous vous recommandons vivement de changer le message par défaut. En effet, il a l’inconvénient de présenter à la fois le serveur utilisé (Postfix) ainsi que le système hôte (Debian). Pour des raisons de sécurité, il se peut que vous ne désiriez pas laisser ces informations publiques à tous. Le contenu a aucune importance, l’officiel « mail.uncertaindomaine.net ESMTP Server ready » fera l’affaire. Comme nous l’avons fait pour l’annuaire LDAP, nous reviendrons sur la configuration SSL plus tard. Ainsi, commentez (ajoutez un # devant) toutes les lignes commençant par smtpd_tls_ et smtp_tls Ensuite, ajoutez les lignes suivantes, que je vous ai commentées, à la fin du fichier main.cf : //Pour un soucis de clarté, quelques définitions de nos commentaires. Un utilisateur virtuel est un utilisateur qui n’existe pas sur la machine serveur. Dans notre configuration, tous les utilisateurs possédant un compte email sont virtuels (ils ne possèdent pas de compte utilisateur sur notre machine) alors que le seul compte non virtuel, est celui que nous avons créé, à savoir vmail.// # Ici, nous indiquons le fichier contenant la liste des domaines # que l’on peut prendre en charge (/etc/postfix/ldap-domains.cf) # le préfixe ldap: sert à préciser qu’il s’agit de fichiers contenant # des paramètres d’accès à l’annuaire virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf # Ici, nous indiquons le répertoire dans lequel sera contenu toutes # les mailbox virtual_mailbox_base = /home/vmail # Ici, nous indiquons le fichier contenant la liste des # correspondances entre adresses email et répertoire de stockage virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf # Ici, sans entrer dans les détails, il s’agit de correspondances # entre adresse mail virtuelle et utilisateur réel. Ici le static # indique que cet utilisateur sera toujours le même, indépendamment de # l’adresse mail. L’uid et le gid renseigné sont ceux que l’on a # choisi lors de la création de ces utilisateurs virtual_minimum_uid = 100 virtual_gid_maps = static:2000 virtual_uid_maps = static:2000 # Ici, nous indiquons le fichier contenant la liste des # correspondances entre alias mail et adresse réelle virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf Comme vous l’avez vu, nous utilisons des fichiers pour établir les différentes correspondances. Il est donc tant de créer ces fichiers : //server_host contient le serveur sur lequel se trouve ldap. Nous utilisons un DNS, plutôt que localhost, afin d’avoir de meilleures possibilités d’évolution si besoin par la suite. Si, par la suite, votre serveur venait à devenir important et que vous souhaiteriez déménager le serveur LDAP sur un serveur dédié uniquement à ce rôle, vous auriez juste à changer le DNS, en le faisant pointer vers notre nouvelle machine, sans avoir à configurer toutes les applications qui l’utilisent. server_port, comme son nom l’indique, indique le port sur lequel nous allons nous connecter. Pour le moment, nous n’avons pas activé le SSL, donc nous utilisons le port par défaut, ainsi 389. search_base nous permet de dire dans quelle arborescence nous souhaitons effectuer notre requête. query_filter, comme son nom l’indique, indique le filtre de recherche result_attribute contient le nom de l’attribut dont la valeur fera office de résultat bind, bien que je ne maîtrise pas toute la portée de cet attribut, je sais qu’il faut mettre yes pour notre type de connection bind_dn contient le chemin du compte utilisateur bind_pw contient le mot de passe (en clair) de cet utilisateur version indique la version de LDAP que nous souhaitons utiliser, ici 3 // Créons ainsi notre premier fichier. cat > /etc/postfix/ldap-domains.cf << EOF server_host = ldap.uncertaindomaine.net server_port = 389 search_base = dc=mail,dc=uncertaindomaine,dc=net query_filter = (&(description=virtualDomain)(dc=%s)) result_attribute = dc bind = yes bind_dn = cn=admin,dc=uncertaindomaine,dc=net bind_pw = version = 3 EOF Ce fichier, comme nous l’avons vu précédemment, sert à indiquer les domaines existants. Comme pour chacun des fichiers que nous créerons par la suite, il serait bon de vérifier que tous les paramètres entrés sont corrects. Cela nous permettra d’éviter tout problème par la suite. Voici la commande à exécuter pour vérifier que tout est bon : [query_filter], seule petite modification à apporter, remplacer %s par * La commande pour vérifier notre fichier est la suivante : ldapsearch -h [server_host] -p [server_port] -b "[search_base]" -D "[bind_dn]" -w "[bind_pw]" -P [version] -LLL "[query_filter]" [result_attribute] Si l’on remplace par les valeurs indiquées, cette commande deviant : ldapsearch -h ldap.uncertaindomaine.net –p 389 –b "dc=mail,dc=uncertaindomaine,dc=net" -D "cn=admin,dc=uncertaindomaine,dc=net" -w "" –P 3 -LLL "(&(description=virtualDomain)(dc=*))" dc Vous pouvez considérer que votre fichier est bien configure si cette commande vous renvoit tous les domaines. À savoir, chez moi, le résultat est : dn: dc=uncertaindomaine.net,dc=mail,dc=uncertaindomaine,dc=net dc: uncertaindomaine.net dn: dc=uncertaindomaine.com,dc=mail,dc=uncertaindomaine,dc=net dc: uncertaindomaine.com dn: dc=uncertaindomaine.org,dc=mail,dc=uncertaindomaine,dc=net dc: uncertaindomaine.org J’ai donc bien la liste de tous les domaines. Mon fichier est donc correctement configuré, je peux passer au suivant. (ces vérifications vous paraissent peut-être futiles, sachez néanmoins que c’est grâce à elles que vous limiterez par la suite le nombre d’erreurs. Ainsi, si par la suite, vous avez une erreur, vous êtes capable de vérifier si elle provient de ces fichiers ou non). Passons au fichier suivant : cat > /etc/postfix/ldap-accounts.cf << EOF server_host = ldap.uncertaindomaine.net server_port = 389 search_base = dc=mail,dc=uncertaindomaine,dc=net query_filter = (&(objectClass=CourierMailAccount)(mail=%s)) result_attribute = mailbox bind = yes bind_dn = cn=admin,dc=uncertaindomaine,dc=net bind_pw = version = 3 EOF Et de la même façon, la commande suivante doit vous lister la liste des répertoires dans lesquels sont stockés les mails (avec en dn, l’affichage du mail correspondant) : ldapsearch -h ldap.uncertaindomaine.net -p 389 -b "dc=mail,dc=uncertaindomaine,dc=net" -D "cn=admin,dc=uncertaindomaine,dc=net" -w "" -P 3 -LLL "(&(objectClass=CourierMailAccount)(mail=*))" mailbox dn: mail=vargisj(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mai l,dc=uncertaindomaine,dc=net mailbox: uncertaindomaine.net/vargisj/ dn: mail=vargisj(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mai l,dc=uncertaindomaine,dc=net mailbox: uncertaindomaine.net/vargisj/ dn: mail=vargisj(AROBASE)uncertaindomaine.org,dc=mailAccount,dc=uncertaindomaine.org,dc=mai l,dc=uncertaindomaine,dc=net mailbox: uncertaindomaine.net/vargisj/ dn: mail=admin(AROBASE)uncertaindomaine.net,dc=mailAccount,dc=uncertaindomaine.net,dc=mail,d c=uncertaindomaine,dc=net mailbox: uncertaindomaine.net/admin/ dn: mail=admin(AROBASE)uncertaindomaine.com,dc=mailAccount,dc=uncertaindomaine.com,dc=mail,d c=uncertaindomaine,dc=net mailbox: uncertaindomaine.com/admin/ Allez, créons et vérifions notre troisième, et dernier fichier, qui va indiquer nos alias : cat > /etc/postfix/ldap-aliases.cf << EOF server_host = ldap.uncertaindomaine.net server_port = 389 search_base = dc=mail,dc=uncertaindomaine,dc=net query_filter = (&(objectClass=CourierMailAlias) (mail=%s)) result_attribute = maildrop bind = yes bind_dn = cn=admin,dc=uncertaindomaine,dc=net bind_pw = version = 3 EOF ldapsearch -h ldap.uncertaindomaine.net -p 389 -b "dc=mail,dc=uncertaindomaine,dc=net" -D "cn=admin,dc=uncertaindomaine,dc=net" -w "" -P 3 -LLL "(&(objectClass=CourierMailAlias) (mail=*))" maildrop dn: mail=all(AROBASE)uncertaindomaine.net,dc=mailAlias,dc=uncertaindomaine.net,dc=mail,dc=ru shonthemoon,dc=net maildrop: admin(AROBASE)uncertaindomaine.net,vargisj(AROBASE)uncertaindomaine.net Voilà, nous avons donc créé nos trois fichiers, et vérifier leur contenu afin de prévenir toute erreur (ou un maximum). Bon, vous souhaitez une bonne nouvelle ? La configuration de Postfix est terminée. Il nous reste plus qu’à vérifier que nous n’avons fait aucune erreur (la commande suivante ne doit renvoyer aucun retour) : postfix check Si tout est bon, nous pouvons recharger Postfix afin qu’il prenne en charge notre nouvelle configuration : postfix reload postfix/postfix-script: refreshing the Postfix mail system Pour vérifier qu’il fonctionne correctement, rien de mieux qu’un petit telnet (à éventuellement installer, apt-get install –y telnet): La première adresse mail n’a aucune importance (celle après MAIL FROM:), mais pour notre test, la seconde (RCPT TO :) doit être l’une des adresses emails que nous avons créé. On débute le mail en commençant par DATA, et on le termine avec le signal . (point). Ensuite, la commande quit pour quitter le serveur. telnet mail.uncertaindomaine.net 25 Trying xxx.xxx.xxx.xxx... Connected to mail.uncertaindomaine.net. Escape character is '^]'. 220 mail.uncertaindomaine.net ESMTP Server ready ehlo uncertaindomaine.net 250-uncertaindomaine 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM:toto@titi.com 250 2.1.0 Ok RCPT TO:vargisj(AROBASE)uncertaindomaine.net 250 2.1.5 Ok DATA 354 End data with . Subject: Premier Test Here is my test . 250 2.0.0 Ok: queued as 0EDFC21428 quit 221 2.0.0 Bye Connection closed by foreign host. Maintenant, pour verifier que cela fonctionne, rendez-vous dans le repertoire /home/vmail. Le répertoire correspondant à l’attribut mailbox de l’utilisateur à qui vous avez envoyé l’email doit avoir été créé. De plus, dans ce répertoire, vous devez avoir un répertoire new, contenant un fichier. Le contenu de ce fichier doit correspondre au mail que vous venez de vous envoyer. Tout est bon ? Très bien, il ne nous reste plus qu’à configurer les dns et vous aurez un serveur capable de recevoir des mails. Voici ce que vous devrez rajouter (ou adapter, ou remplacer), dans l’onglet « experte » de la gestion de vos zones DNS (nous modifions ici notre domaine principal, à savoir uncertaindomaine.net) : mail 300 IN A xxx.xxx.xxx.xxx @ 300 IN MX 10 mail.uncertaindomaine.net. La première ligne indique que le sous-domaine mail (donc le DNS mail.uncertaindomaine.net) correspondra à l’adresse IP xxx.xxx.xxx.xxx La seconde entrée indique que pour le domaine uncertaindomaine.net (@ signifie qu’il s’agit du domaine, sans préfixe), nous devons contacter le serveur mail.uncertaindomaine.net, dont nous avons défini l’adresse IP (ne pas oublier le . à la fin du DNS du serveur mail). Les 300, sont les TTL (Time to live pour les intimes). Ces TTL indiquent la durée (en secondes) pendant laquelle il n’est pas nécessaire de réintéroger le serveur DNS. Il est conseillé de mettre une durée relativement courte (300, soit 5 minutes) lorsque vous êtes en phase de test comme c’est le cas à présent, ceci pour des raisons pratiques (si vous devez modifier une entrée, cela prendra 5 minutes au maximum à être pris en compte). Une fois votre phase de test terminée, il est conseillé de mettre une durée plus longue (classiquement 10800, soit 3 heures), ce pour un gain de performances. En effet, pour résoudre un DNS de votre domaine, un client n’interrogera le serveur qu’une fois toutes les 3 heures. Ceci occasionne un gain de performances pour lui (il n’a pas à contacter le serveur DNS durant ces 3 heures), tout autant que pour le propriétaire du serveur DNS (qui reçoit du coup moins de requêtes). Une fois ceci fait, il vous faudra attendre plus ou moins (suivant les précédents enregistrements de votre domaine, et les TTL qui y étaient indiqués). Pendant ce temps, on va faire un peu de hors-sujet, en vous présentant un outil de diagnostic dns, qui s’appelle dig. Cet outil est présent dans le package Debian dnsutils. Ainsi : apt-get install –y dnsutils Une fois ceci fait, je vais vous présenter ici qu’une maigre partie de dig, qui va nous permettre de connaitre le champs MX record d’un domaine : dig uncertaindomaine.net mx La réponse devrait être semblable à celle-ci (précédées de cinq ; (soit ;;;;;), il s'agit de mes commentaires) : ;;;;;Toutes les parties commençant par ; ne sont que des indications ; <<>> DiG 9.7.3 <<>> uncertaindomaine.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48267 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; QUESTION SECTION: ;uncertaindomaine.net. IN MX ;; ANSWER SECTION: ;;;;;Ici, nous retrouvons notre enregistrement MX. À noter, le second champ (183) est forcément inférieur au TTL, et indique pendant combien de temps le client (donc vous) va garder cette correspondance en cache avant de réintéroger le serveur de nom. Ici 183 secondes. uncertaindomaine.net. 183 IN MX 10 mail.uncertaindomaine.net. ;; AUTHORITY SECTION: ;;;;;Ici, il s’agit des serveurs de noms concernant le DNS. J’ai pour le moment gardé les serveurs Gandi. Qui sait, peut-être que je vais changer sous peu ? uncertaindomaine.net. 10683 IN NS b.dns.gandi.net. uncertaindomaine.net. 10683 IN NS a.dns.gandi.net. uncertaindomaine.net. 10683 IN NS c.dns.gandi.net. ;; ADDITIONAL SECTION: ;;;;;Ici, il s’agit des correspondances entre les noms de domaines des serveurs de noms, et l’adresse IP des machines. Notez que AAAA correspond aux adresses IPv6. a.dns.gandi.net. 197 IN A 173.246.97.2 a.dns.gandi.net. 197 IN AAAA 2604:3400:a::2 b.dns.gandi.net. 1012 IN A 217.70.184.40 c.dns.gandi.net. 1012 IN A 217.70.182.20 ;; Query time: 0 msec ;; SERVER: 217.70.184.225#53(217.70.184.225) ;; WHEN: Mon Jul 18 01:40:19 2011 ;; MSG SIZE rcvd: 190 De la même façon, la commande suivante vous renseignera sur la correspondance IP (A) du DNS mail.uncertaindomaine.net (le retour étant à peu de choses près semblable, nous ne l’afficherons pas ici. dig mail.uncertaindomaine.net a N.B. : ces informations, fournies par dig, sont à prendre en considérant qu’il ne s’agit que de votre client. Ainsi, si vous n’avez jamais interrogé mail.uncertaindomaine.net auparavant, vous devriez avoir les entrées correspondant à celles actuellement sur votre serveur DNS. Toutefois, si un autre client a interrogé auparavant le DNS mail.uncertaindomaine.net et qu’avant, ce DNS avait un TTL de 3 heures, alors il faudra attendre la valeur de ce dernier TTL avant de considérer que votre domaine est à jour partout. La seule méthode pour savoir si un client a interrogé le DNS mail.uncertaindomaine.net avant est d’avoir une approche logique de la question. Utilisiez-vous auparavant le service mail de Gandi ? Avez-vous eu auparavant un quelconque service sur mail.uncertaindomaine.net qu’un client aurait pu contacter ? Si vous répondez non aux deux questions précédentes, alors vous pouvez considérer les valeurs renvoyées par dig comme argent comptant (façon de parler) Une fois que vous êtes à peu près certain de votre DNS, envoyez (depuis un client neutre, comme par exemple un webmail type Gmail ou Yahoo) un mail à l’adresse all(AROBASE)uncertaindomaine.net. Si votre configuration DNS est bonne, alors vous devriez avoir reçu un nouveau répertoire, à savoir /home/vmail/uncertaindomaine.net/admin de créé. Si c’est le cas, alors bravo, vous avez configuré votre SMTP. Comme toujours, j’ai envie de dire … enfin, presque… Qu’est-ce qu’est capable de faire votre serveur SMTP ? D’envoyer n’importe quel mail à n’importe qui si on le contacte en local (parfait pour un webmail qui serait sur la même machine par exemple), ainsi que d’envoyer des mails à n’importe quel contact géré par votre serveur (ceux de votre annuaire LDAP) si on le contacte depuis l’extérieur. Il serait peut-être bon d’ajouter la possibilité, depuis l’extérieur, de pouvoir s’authentifier sur le serveur SMTP afin de pouvoir envoyer, par le biais de ce serveur, des mails à n’importe quel contact, quand bien même on y accèderait depuis l’extérieur. Ceci nous permettra par la suite de configurer un client mail tel que Thunderbird ou Outlook, et pouvoir se servir de ce serveur pour l’envoi de mails. ===== IV] Installation de Cyrus SASL ===== Ceci sera possible en utilisant le mécanisme d’authentification SASL. À l’heure de la rédaction de cet article, seul les implémentations SASL de Cyrus et Dovecot sont prises en charge par Postfix. Lors de l’installation de Postfix, Debian a également installé libsasl2-2, qui contient la bibliothèque SASL de Cyrus. C’est pourquoi, nous opterons pour l’utilisation de Cyrus. Bien que les bibliothèques SASL de Cyrus soient installés, nous aurons besoin de deux package supplémentaires. Le premier contenant le démon d’authentification SASL, et le second le plugin d’authentification LDAP. apt-get install –y sasl2-bin libsasl2-modules-ldap Nous allons donc éditer le fichier /etc/default/saslauthd pour la configuration du démon. Première chose à éditer, passer START à yes (ce qui va permettre le démarrage automatique du démon en cas de redémarrage de la machine. Nous allons également changer MECHANISMS, que nous allons passer à ldap. Une fois ceci fait, vous pouvez enregistrer. Comme on peut le voir dans les commentaires, la configuration pour le mécanisme ldap se fait dans le fichier /etc/saslauthd.conf, que nous allons donc modifier immédiatement. Quitter l’édition de /etc/default/saslauthd et éditez /etc/saslauthd.conf (ce fichier doit être créé) : cat > /etc/saslauthd.conf << EOF ldap_servers: ldap://ldap.uncertaindomaine.net:389/ ldap_search_base: dc=mail,dc=uncertaindomaine,dc=net ldap_timeout: 10 ldap_filter: (&(description=virtualDomain)(dc=%u)) ldap_bind_dn: cn=admin,dc=uncertaindomaine,dc=net ldap_password: ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind EOF Autant l’avouer : NO BULLSHIT. C’est ma plus grosse difficulté. J’ai éprouvé énormément de difficulté à avoir un login contenant un @ pour le service SMTP. Du coup, j’ai choisi une solution de contournement que l’on pourra trouver limite, à savoir qu’on s’authentifie en SMTP en utilisant comme login le nom de domaine, avec le mot de passe renseigné dans l’attribut userPassword de l’entrée du domaine. Il s’agit d’une grosse limitation, j’en suis conscient, mais je ne suis pas arrivé à trouver la solution. Si quelqu’un la trouve, qu’il la partage dans les commentaires, j’apprécierais (et sûrement d’autres également) énormément. //N.B. : il est beaucoup plus propre d’utiliser l’uid ainsi que le mot de passe d’un utilisateur, si vous avez opté pour un serveur qui ne sera pas multi-domaine, et pour lequel, donc, vous pouvez utiliser le préfixe de l’email comme uid.// Maintenant, nous devons créer le fichier /etc/postfix/sasl/smtpd.conf pour indiquer à Postfix les méthodes d’authentification que nous proposons (plain et login), ainsi que la méthode de vérification des mots de passe (saslauthd) : cat > /etc/postfix/sasl/smtpd.conf << EOF pwcheck_method: saslauthd mech_list: plain login EOF Enfin, dans /etc/postfix/main.cf (encore lui), nous allons ajouter la configuration SASL. Les champs et leur valeur étant assez explicite, je ne donnerai pas de commentaire dessus. Ajoutez les lignes suivantes à la fin de /etc/postfix/main.cf : # SASL Support smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_limit = 100 smtpd_helo_restrictions = reject_invalid_hostname smtpd_sender_restrictions = reject_unknown_address smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unknown_sender_domain, reject_unknown_client, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, permit Bon, nous avons bientôt terminé, à un detail près. Dans la configuration du démon, nous avons jusque-là ignoré les options du démon (les paramètres envoyés lors du lancement du démon). Nous allons corriger ça tout de suite. Éditez le fichier /etc/default/saslauthd et rendez-vous à la dernière ligne : OPTIONS="-c -m /var/run/saslauthd" L’option –c autorise le stockage en cache des données de connexion. Cela évite de réintéroger l’annuaire LDAP à de nombreuses reprises pour des mêmes login/password. Supprimez cette option si vous pensez que vous serez amené à changer régulièrement vos mots de passe et les comptes existants. L’option –m indique un réprtoire alternatif pour l’exécution de saslauthd. Il faut savoir que Postfix est exécutez dans un environnement chroot (il travaille dans un répertoire qu’il considère comme racine). Le répertoire chroot de Postfix est /var/spool/postfix. Ainsi, nous indiquerons pour saslauthd comme répertoire alternatif, le répertoire déjà renseigné (/var/run/saslauthd) mais dans l’environnement chroot de Postfix ; soit /var/spool/postfix/var/run/saslauthd. Cette ligne devient donc : OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" Maintenant, nous allons supprimer créer le repertoire /var/run/saslauthd dans l’environnement chroot de postfix. De plus, nous allons créer un lien symbolique dans du répertoire saslauthd qui se trouve dans l’environnement chroot de postfix dans le répertoire /var/run Nous allons changer le groupe auquel appartient enfin ce répertoire pour qu’il soit sasl (afin que sasl puisse y accéder). Dernier point, nous allons ajouter l’utilisateur postfix au groupe sasl, afin qu’il ait les permissions d’accès nécessaires. mkdir -p /var/spool/postfix/var/run/saslauthd ln -s /var/spool/postfix/var/run/saslauthd /var/run chgrp sasl /var/spool/postfix/var/run/saslauthd adduser postfix sasl Bon, cette fois, c’est terminé. Nous n’avons plus qu’à démarrer saslauthd, puis redémarrer Postfix /etc/init.d/saslauthd start Starting SASL Authentication Daemon: saslauthd. /etc/init.d/postfix restart Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix. Nous allons maintenant vérifier que cela fonctionne. Avant tout, lorsque nous allons nous logguer, le serveur SMTP attendra que les logins et mot de passe que nous lui envoyons soient encodés en base64. Sur votre serveur, exécutez les commandes suivantes : printf 'uncertaindomaine.net' | openssl base64 cnVzaG9udGhlbW9vbi5uZXQ= printf '' | openssl base64 PE1vdERlUGFzc2VEdURvbWFpbmU+ C’est parti, nous pouvons nous connecter depuis n’importe quel ordinateur relié à internet à notre serveur en telnet. Voici un exemple dans une fenêtre DOS sous Windows : //Rappelez-vous que, si vous avez suivi notre configuration, le login est le nom de domaine, et le mot de passe, le champs userPassword de l'entry correspondante// C:\> telnet mail.uncertaindomaine.net 25 220 mail.uncertaindomaine.net ESMTP Server ready ehlo uncertaindomaine.net 250-uncertaindomaine 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH LOGIN 334 VXNlcm5hbWU6 cnVzaG9udGhlbW9vbi5uZXQ= 334 UGFzc3dvcmQ6 PE1vdERlUGFzc2VEdURvbWFpbmU+ 235 2.7.0 Authentication successful MAIL FROM:vargisj(AROBASE)uncertaindomaine.net 250 2.1.0 Ok RCPT TO:mailExterne@domaine.tld 250 2.1.5 Ok DATA 354 end data with . From:vargisj(AROBASE)uncertaindomaine.net To: mailExterne@domaine.tld Subject:Here is my first test Hey, Voici le premier mail envoyé depuis mon serveur SMTP. . 250 2.0.0 Ok: queued as EE8B621464 quit 221 2.0.0 Bye Connection to host lost. C:\> Bon, vous souhaitez une bonne nouvelle : la configuration de votre serveur SMTP est terminée pour le moment. Il nous restera plus qu’à le passer en SSL au moment venu. Bon, nous pouvons maintenant envoyer des mails, et en recevoir. Ce qui serait bien, et ce sera le dernier point, ce serait de pouvoir les lire. ===== V] Installation de Dovecot ===== Bon, une petite explication sur le choix de Dovecot. En effet, si Postfix a une situation de quasi-monopole en terme d’agent de transport de courrier électronique (MTA pour les intimes, mais j’avais envie de faire un peu de promotion à la langue de Molière), concernant les choix de serveur pop/imap, nous avons le choix. Nous ne retiendrons le choix qu’entre 3 possibles, à savoir Dovecot, Cyrus et Courier (les autres étant plutôt mineurs et peu utilisés). Le choix de Dovecot a été tout simplement effectué car, s’il a des performances équivalentes à Cyrus, il est plus utilisé. Ainsi, en cas de difficulté, il sera plus aisé de trouver des informations concernant Dovecot que Cyrus. Un second critère de choix est que Dovecot possède un (très) grand nombre de binaires créés pour nous simplifier la vie. Les détracteurs vous diront que cela augmente la difficulté, à savoir qu’il faut connaître un grand nombre de binaires pour pouvoir tout effectuer, les défenseurs vous diront que ce sont tous ces binaires qui permettent de faire des opérations directement et simplement, qui sous Cyrus nécessiteraient plusieurs étapes. Mon choix s’est essentiellement fait concernant l’utilisation plus que très répandue de Dovecot. Quant à Courier, il joue un peu le rôle d’outsider. Très simple à mettre en place (vraiment très simple), il montre ses limites dès que l’on souhaite effectuer des opérations de maintenances un poil poussé (comme par exemple la migration de boites mails, la prise en charge du protocole NFS, etc…). Voilà, fin du petit paragraphe sur le choix de Dovecot. Comme toute belle histoire sous Debian, celle-ci commençait par un petit coup d’aptitude : apt-get install -y dovecot-imapd dovecot-pop3d Bon, comme précédemment, nous allons modifier le fichier de configuration principale. Pour peu que vous soyiez à l’aise avec la langue de Shakespeare, ce fichier de configuration est une véritable mine d’or de par le nombre de commentaires dont il regorge. Étant donné que ce fichier de configuration est purement et simplement un roman, nous allons voir une par une les instructions que nous allons modifier : Ligne 53 : disable_plaintext_auth = no Par défaut Dovecot ne permet pas l’authentification plaintext pour les clients se connectant sur un port autre que SSL. Étant donné que nous configurerons plus tard le SSL, nous désactivons temporairement cette restriction. Ce n’est pas vraiment conseillé mais bon … ainsi soit-il, ce n’est que temporaire ! Ligne 183 : login_greeting = UnCertainDomaine : server ready Encore une fois, nous ne souhaitons pas indiquer, pour des raisons de sécurité, le logiciel utilisé. Ligne 230 : mail_location = /home/vmail/%d/%n Nous indiquons le répertoire à utiliser comme boite mail. Ligne 305 : mail_uid = 2000 Nous renseignons ici l’uid number de l’utilisateur vmail, qui accèdera aux emails Ligne 306 : mail_gid = 2000 De la même façon le gid number Ligne 893 : mechanisms = plain login Nous indiquons que nous souhaitons également utiliser le mécanisme d’authentification login Ligne 926 : #passdb pam { Nous n’utiliserons que l’authentification LDAP. Nous pouvons donc commenter la partie concernant l’authentification pam Ligne 960 : #} Il s’agit de commenter la fermeture du crochet, car nous avons commenté son ouverture ligne 926 Ligne 1008 : passdb ldap{ Nous allons simplement décommenter la section, donc trois lignes sur les 4 (la seconde restant un commentaire). Ceci afin d’activer la possibilité de login via LDAP. Ligne 1039 : #userdb passwd { Comme vu précédemment, nous n’utiliserons que LDAP, nous pouvons donc commenter cette partie Ligne 1046 : #} Il s’agit de commenter la fermeture du crocket, car nous avons commenté son ouverture ligne 1039 Ligne 1086 : userdb ldap{ De la même façon, nous allons décommenter la section de 4 lignes, excepté la seconde. Voilà, ce sera tout pour les modifications concernant ce fichier. Comme vous pouvez vous en douter, nous allons maintenant éditer le fichier /etc/dovecot/dovecot-ldap.conf (là aussi, on peut s’apercevoir que dovecot n’est pas radin en commentaires). Nous avons configuré plusieurs fichiers avec accès à LDAP. Je ne pense donc pas qu’il soit utile d’expliquer les lignes que j’ai modifiées. Ligne 17 : hosts = ldap.uncertaindomaine.net Ligne 25 : dn = cn=admin,dc=uncertaindomaine,dc=net Ligne 28 : dnpass = Ligne 85 : ldap_version = 3 Ligne 89 : base = dc=mail,dc=uncertaindomaine,dc=net Ligne 106 : user_attrs = uidNumber=2000,gidNumber=2000 Ligne 113 : user_filter = (&(objectClass=CourierMailAccount)(mail=%u)) Ligne 131 : pass_filter = (&(objectClass=CourierMailAccount)(mail=%u)) Ligne 135 : default_pass_scheme = SSHA Bonne nouvelle, la configuration de l’ensemble de votre serveur mail est terminée, dans le sens où l’ensemble est fonctionnel. Il ne vous reste qu’à redémarrer Dovecot. /etc/init.d/dovecot restart Attention, pour vous connecter à votre compte en POP et/ou IMAP, le répertoire de mailbox du compte doit exister. Pour se faire, rien de plus simple, envoyez juste un mail à l’adresse en question. Postfix va automatiquement créer les répertoires dont vous avez besoin. Dernière petite vérification. Nous allons redémarrer tous les démons, afin de vérifier qu’ils sont tous à même de redémarrer et qu’il n’y a aucune erreur : /etc/init.d/slapd restart && /etc/init.d/saslauthd restart && /etc/init.d/postfix restart && /etc/init.d/dovecot restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. Stopping SASL Authentication Daemon: saslauthd. Starting SASL Authentication Daemon: saslauthd. Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix. Restarting IMAP/POP3 mail server: dovecot. Bon, et bien je crois que je vous ai menti, nous ne configurerons pas le SSL dans ce tutorial. Pourquoi ? Parce que je pense que celui-ci est déjà bien long, et que nous sommes en possession d’un serveur de mail pleinement fonctionnel. Du coup, je pense que je vais écrire un second tutoriel. Dans ce second tutoriel, j’aborderai les notions de sécurité que nous avons quelque peu ignoré. Pour commencer, définir des utilisateurs avec des accès bien spécifiques, tant pour dovecot que pour Postfix ou Cyrus Sasl. Ensuite, nous verrons également comment configurer tous nos services pour qu’ils utilisent le protocole SSL/TLS, et notamment STARTTLS pour le SMTP. Enfin, je pourrai aborder également des parties que vous me suggèrerez en commentaire.