À 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 :

1. La création de votre serveur sur Gandi
2. L'installation d'un serveur LDAP ainsi que des utilitaires clients (OpenLDAP)
3. L'installation d'un serveur de messagerie électronique (Postfix)
4. L'installation de binaires pour l'authentification SMTP (Cyrus-SASL)
5. 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)

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

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.

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.

slapd -V

@(#) $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

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.

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 <cn=config> 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.

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
-

nano /etc/ldap/slapd.d/cn_config/olcDatabase={1}hdb.ldif

/etc/init.d/slapd restart

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 <dc=uncertaindomaine,dc=net> 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 <dc=uncertaindomaine,dc=net> 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)

#
# 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)

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 = <PasswordEnClair>
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 "<PasswordEnClair>" –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 = <PasswordEnClair>
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 "<PasswordEnClair>" -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 = <PasswordEnClair>
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 "<PasswordEnClair>" -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 <CR><LF>.<CR><LF>
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.

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: <PasswordEnClair>
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 '<MotDePasseDuDomaine>' | 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 <CR><LF>.<CR><LF>
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.

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 = <PasswordEnClair>
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.