Implémenter le serveur de

messagerie
Sommaire
1. Présenter le service de messagerie
2. Installation et configuration de postfix
3.
4.
5.

1. Présenter le service de messagerie.

1.1. Introduction
Le courrier électronique, courriel, e-mail, mail est un service de transmission de
messages écrits et de documents envoyés électroniquement via le réseau Internet dans la
boîte aux lettres électronique d’un destinataire choisi par l’émetteur.
Pour émettre et recevoir des messages par courrier électronique, il faut disposer
d’une adresse électronique et d’un client de messagerie ou d’un web mail permettant
l’accès aux messages via un navigateur Web.
1.2. Courrier électronique
La boîte aux lettres se présentait sous la forme d'un fichier dans le répertoire
personnel d'un utilisateur que seul ce dernier pouvait lire. Les applications de messagerie
primitives ajoutaient des nouveaux messages de texte au bas du fichier et l'utilisateur devait
parcourir tout le fichier qui ne cessait de grandir, afin de retrouver tout message spécifique.
Ce système ne pouvait envoyer de messages qu'aux utilisateurs d'un même système.
1.3. Protocoles de courrier électronique
Au fil du temps, les systèmes de messagerie électronique basés sur des protocoles
réseau standardisés ont évolué de telle manière qu'ils font désormais partie des services les
plus couramment utilisés sur l'Internet.
1.3.1. Protocoles de transfert de courrier électronique
La livraison de courrier d'une application cliente au serveur et d'un serveur d'origine
à un serveur de destination est traitée par le protocole nommé Simple Mail Transfer
Protocol (ou SMTP).
L'objectif primaire de SMTP consiste à transférer le courrier électronique entre les
serveurs de messagerie. Toutefois, il a également une importance critique pour les clients de
messagerie. Afin d'envoyer un email, le client envoie le message électronique à un serveur
de messagerie sortant, qui à son tour contacte le serveur de messagerie de destination pour
la livraison du message.
Il est important de noter ici que le protocole SMTP n'a pas besoin d'authentification
pour fonctionner. Ainsi, quiconque utilisant l'Internet peut envoyer des emails à toute autre
personne ou même à de grands groupes de personnes. C'est cette caractéristique de SMTP
qui permet l'envoi de pourriel (aussi appelé junk email) ou de spam. Les serveurs SMTP
modernes essaient néanmoins de minimiser ce comportement en n'autorisant que les hôtes
connus à accéder au serveur SMTP. Les serveurs n'imposant pas ce genre de restriction sont
appelés serveurs open relay.
 1.3.2. Protocoles d'accès au courrier
Pour récupérer le courrier électronique stocké sur les serveurs de messagerie, les
applications client de messagerie utilisent deux protocoles primaires :
 Post Office Protocol (ou POP) ;
 Internet Message Access Protocol (ou IMAP).
Contrairement à SMTP, ces deux protocoles exigent des clients qui se connectent de
s'authentifier au moyen d'un nom d'utilisateur (aussi appelé identifiant) et d'un mot de
passe. Par défaut, les mots de passe pour les deux protocoles sont transmis à travers le
réseau de manière non-cryptée.
1.3.2.1. POP
Lors de l'utilisation d'un serveur POP, les messages électroniques sont téléchargés
par des applications client de messagerie. Par défaut, la plupart des clients de messagerie
POP sont configurés automatiquement pour supprimer les messages sur le serveur une fois
le transfert effectué ; toutefois, cette configuration peut souvent être modifiée.
Le protocole POP est compatible à 100 % avec des normes de messagerie Internet
importantes, telles que Multipurpose Internet Mail Extensions (ou MIME), qui permet l'envoi
de pièces jointes.
Le protocole POP est le plus approprié pour les utilisateurs disposant d'un système
sur lequel ils peuvent lire leurs courriers électroniques. Il fonctionne également bien pour
des utilisateurs n'ayant pas de connexion continue à l'Internet ou à un réseau sur lequel le
serveur de messagerie se trouve. Malheureusement, pour les utilisateurs ayant des
connexions réseau lentes, POP requiert que les programmes client, après authentification,
téléchargent la totalité du contenu de chaque message. Cette opération peut être longue si
certains messages contiennent des pièces jointes.
La version la plus courante du protocole POP standard est POP3.
Pour une sécurité accrue, il est possible d'utiliser le cryptage Secure Socket Layer
(SSL) pour l'authentification des clients et pour les sessions de transfert de données.
1.3.2.2. IMAP
Lors de l'utilisation d'un serveur de messagerie IMAP, le courrier électronique est
conservé sur le serveur où les utilisateurs peuvent lire et supprimer les emails. IMAP permet
également aux applications client de créer, renommer ou supprimer des répertoires de
messagerie sur le serveur afin d'organiser ou de stocker le courrier électronique.
Le protocole IMAP est utile tout particulièrement pour les utilisateurs accédant à leur
courrier électronique au moyen d'ordinateurs multiples. Ce protocole est également
pratique pour les utilisateurs se connectant au serveur de messagerie par le biais d'une
connexion lente, car seule l'information d'en-tête du message est téléchargée jusqu'à ce
qu'il soit ouvert, économisant ainsi de la largeur de bande. En outre, l'utilisateur peut
également supprimer des messages sans devoir les lire ou les télécharger.
Par commodité, les applications IMAP client peuvent mettre en cache localement des
copies des messages afin que l'utilisateur puisse naviguer parmi des messages déjà lus même
lorsqu'il n'est pas directement connecté au serveur IMAP.
IMAP, tout comme POP, est compatible à 100 % avec des normes de messagerie
Internet importantes, telles que MIME (Multipurpose Internet Mail Extensions) pour
permettre l'envoi de pièces jointes.
Pour une sécurité accrue, il est possible d'utiliser le cryptage SSL/TLS pour l'authentification
des clients et pour les sessions de transfert de données.

1.4. Présenter les différents agents de messagerie

D'une manière générale, toutes les applications de messagerie électronique font
partie d'au moins un des trois types d'applications. Chaque type joue un rôle bien précis
dans le processus de déplacement et de gestion des messages électroniques. Bien que la
plupart des utilisateurs ne connaissent que le programme de courrier électronique qu'ils
utilisent pour recevoir et envoyer des messages, chacun de ces trois types d'applications est
important pour assurer que les messages arrivent à la bonne destination.
1.4.1. Agents de messagerie
La figure ci-dessous présente les composants du serveur de messagerie, ainsi que le
flux du courrier électronique via ces composants.

Le courrier électronique est transmis via les composants du serveur de messagerie comme
suit :
1. Dans son application MUA, l'expéditeur crée un courrier électronique et clique sur
Envoyer.
2. L'application MUA utilise SMTP pour envoyer le courrier électronique à un agent
MTA.
3. L'agent MTA relaie et achemine le courrier électronique vers un MTA dans le
domaine du destinataire.
4. L'agent MTA du domaine du destinataire envoie le courrier électronique à un MDA
du système du destinataire.
5. Le MDA stocke le courrier électronique dans une zone MSA.
6. L'application MUA du destinataire interroge un MSS.
 7. Le MSS utilise IMAPv4 ou POP pour extraire le courrier électronique pour le
destinataire à partir de la zone MSA.
8. Le MSS renvoie le courrier électronique à l'application MUA.
9. Dans son application MUA, le destinataire lit le courrier électronique envoyé par
l'expéditeur.
1.4.2. Description d’Agents de messagerie
Le tableau ci-dessous répertorie chaque composant du serveur de messagerie, décrit
chaque composant et fournit quelques exemples de chaque composant.
Composants Description
Mail User Agent Application sur un système client, permettant aux utilisateurs de
(MUA) créer, d'afficher, d'envoyer et de recevoir du courrier électronique.
Mail Transfer Sert à transférer des messages électroniques entre des hôtes utilisant
Agent (MTA) SMTP. Un message peut requérir l'utilisation de plusieurs MTA lors de
sa progression vers sa destination finale
Mail Delivery Utilisé par le MTA pour distribuer « Enregistrer » le courrier arrivant
Agent (MDA) dans la boîte aux lettres de l'utilisateur approprié « Zone MSA ». Il se
peut que ce programme effectue des tâches supplémentaires telles
que le filtrage de courrier électronique ou la distribution de
courrier électronique aux sous-dossiers.
Mail Storage Système ou serveur local dans lequel l'application MTA stocke du
Area (MSA) courrier électronique. Il s'agit également de l'emplacement à partir
duquel le serveur MSS extrait du courrier électronique à la demande de
l'application MUA.
Mail Storage Application permettant d'extraire du courrier électronique de la zone
Server (MSS) MSA et de le renvoyer à l'application MUA.

1.4.3. Implémentation des Agents de messagerie

Composants Implémentation
Mail User Agent  Microsoft Outlook Express
(MUA)  Mozilla Thunderbird
 Squirrelmail (Web Mail)
 RoundCube (Web Mail)
 Mutt E-Mail Client
Mail Transfer  Postfix
Agent (MTA)  Sendmail
 Qmail
 Zxim
 Lotus Domino Server (IBM)
 Microsoft Exchange (Microsoft)
Mail Delivery Les applications Postfix, Dovecot et Cyrus implémentent chacune
Agent (MDA) une partie ou l'ensemble des fonctions de l'agent MDA.
 Procmail, l'un des plus connus, surtout pour ses capacités de
filtrage
 Maildrop.
 Fetchmail.
Mail Storage Area  Mbox
(MSA)  Maildir
 /var/mail/spool/nom_utilisateur/
Mail Storage  Dovecot
 Server (MSS)  Cyrus
Conjointement avec les applications de serveur de messagerie et les clients de courrier
électronique, vous pouvez utiliser d'autres applications pour le traitement préalable et le post-
traitement du courrier électronique. Par exemple, vous pouvez utiliser des applications de
filtrage, des logiciels antivirus ou des applications anti SPAM.

2. Installation et configuration de Postfix

2.1. Introduction
Postfix est un serveur mail, et plus exactement un MTA. Il se charge de la livraison de
courriers électroniques (courriels) en utilisant le protocole SMTP et a été conçu comme une
alternative plus rapide, plus facile à administrer et plus sécurisée que l'historique Sendmail.
Il est le serveur de courriel par défaut dans plusieurs systèmes de type UNIX, comme
Mac OS X, NetBSD2, diverses distributions GNU/Linux, etc.
2.2. Prérequis
Il faut obligatoirement disposer d’un ou de plusieurs noms de domaines valide enregistrés
dans votre serveur qui va accueillir le serveur de messagerie tel que ismontic.ma ou
ofppt.ma.
A partir des machines cliente, vérifier la configuration DNS des domaines pour lesquels on
souhaite gérer le courrier, comme ceci.
$ host -t mx ismontic.ma
$ host mail.ismontic.ma
$ host ismontic.ma
$ host @IP
Les enregistrements de serveur de messagerie dans le fichier de zone DNS :
mail IN A @IP_de_Serveur
servername IN MX 10 mail

2.3. Installation
Postfix est inclus dans une installation minimale de CentOS. S’il n’est pas présent sur
le système, on peut l’installer comme ceci.
# rpm -ihv postfix-2.6.6-8.el6.x86_64.rpm
On installera également la commande mail (paquet mailx) et le client mutt pour
pouvoir tester et gérer les mails en ligne de commande directement sur le serveur.
# rpm -ihv mutt-1.5.20-8.20091214hg736b6a.el6.x86_64.rpm
# rpm -ihv tokyocabinet-1.4.33-6.el6.x86_64.rpm
# rpm -ihv urlview-0.9-7.el6.x86_64.rpm
# rpm -qa | grep mailx
mailx-12.4-8.el6_6.i686

2.4. Configuration initiale

Les fichiers de configuration utilisés par Postfix se situent dans /etc/postfix/.
 Le fichier master.cf gère la configuration du démon master de Postfix. Dans la plupart
des configurations de base, on n’aura pas à intervenir sur ce fichier.
 Le fichier main.cf contient les paramètres de contrôle des démons de Postfix. C’est
celui que l’on modifiera le plus souvent.
 Le fichier main.cf fourni par défaut fait près de 680 lignes, la plupart étant des
commentaires. On peut commencer par faire un sauvegarde de ce fichier, puis enlever les
commentaires « les lignes qui commence par # » pour ne garder que les directives.
# cd /etc/postfix
# cp main.cf main.cf.orig
# grep -vE "^#|^$" main.cf.orig > main.cf
# cp master.cf master.cf.orig
# grep -vE "^#|^$" master.cf.orig > master.cf
On obtient un fichier beaucoup plus lisible (sans commentaire).
# cat /etc/postfix/main.cf
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
inet_interfaces = localhost
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
Si un paramètre n’est pas présent dans « main.cf », Postfix utilisera sa valeur par
défaut. Pour la plupart, ces valeurs sont définies « en dur » dans le code source de Postfix,
tandis que certaines sont initialisées à la compilation et quelques-unes au moment du
lancement du programme.
Le programme postconf est très utile pour examiner les valeurs courantes et par défaut du
fichier « main.cf ». Pour afficher les valeurs de certains paramètres de configuration, il suffit
de les fournir en argument.
# postconf inet_interfaces
inet_interfaces = localhost
 L’option -d affichera la valeur par défaut des paramètres demandés.
# postconf -d inet_interfaces
inet_interfaces = all
Editez le fichier /etc/postfix/main.cf, et nous allons supprimer la plupart des paramètres
redondants ou autrement inutiles, pour commencer avec quelques directives de base.
#vim /etc/postfix/main.cf
# Désactiver l'IPv6
# On force postfix à utiliser le protocole IPv4
inet_protocols = ipv4
# Message affiché à la connexion
smtpd_banner = $myhostname ESMTP $mail_name (CentOS)
# Nom d'hôte pleinement qualifié du serveur FQDN
myhostname = servername.ismontic.ma
# Ou myhostname = servername.$mydomain
# Nom de domaine du serveur
mydomain = ismontic.ma
# Le serveur Mail va écouter sur toutes les interfaces
inet_interfaces = all
# Domaine pour qualifier les adresses sans partie domaine
myorigin = $myhostname
# Liste des domaines principaux dont on accepte le courrier
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
# Indique les réseaux dont on accepte d'acheminer les emails
mynetworks = 127.0.0.0/8, 192.168.3.0/24
# Permet d'indiquer un autre serveur SMTP pour l'envoi des emails
# Utilisé si on ne peut pas envoyer directement les emails
relayhost =
# L’emplacement ou les mails sont stocké
home_mailbox = Maildir/
# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
# Commande de débogage
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
# Chemins des commandes
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
# Documentation
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
Quelques remarques :
 Si l’IPv6 est désactivé au niveau du système, il faudra également le faire ici grâce à la
directive inet_protocols.
 smtpd_banner définit la chaîne de caractères avec laquelle Postfix s’identifie auprès
d’un autre MTA.
 myhostname est censé contenir le nom d’hôte pleinement qualifié du serveur, c’est-
à-dire le résultat de la commande hostname --fqdn.
  myorigin définit le domaine auquel sont associés des mails envoyés localement. Par
défaut, myorigin a la même valeur que myhostname.
 mydestination fournit la liste des domaines pour lesquels les messages reçus doivent
être stockés dans une boîte mail locale. Même si Postfix gère plusieurs domaines,
mydestination ne doit spécifier que le domaine principal. Les domaines virtuels
seront gérés par la directive virtual_alias_domains, que nous verrons plus loin.
 mynetworks définit les adresses depuis lesquelles Postfix accepte les mails sans
authentification via SMTP. Sur un serveur dédié public, il est impératif de définir
uniquement l’hôte local pour mynetworks.
 relayhost définit le MTA auquel on est censé transférer les mails qui ne doivent pas
être acheminés localement. Dans notre configuration, cette directive doit rester vide.
On l’utilisera sur un serveur de réseau local pour transférer les mails à un MTA public
sur Internet.
 Le format de stockage par défaut de Postfix, c’est mbox. On préférera le format
Maildir/, bien plus adapté pour une configuration IMAP.
 alias_maps définit l’emplacement de la table de correspondance, et alias_database
la base de données correspondante. Certaines informations ne peuvent pas être
facilement représentées dans main.cf. Les tables de correspondance permettent de
les stocker dans des fichiers externes. Postfix n’utilise pas directement les fichiers
texte, ce serait trop lent. Au lieu de cela, les tables de correspondance de type hash
(ou “tables de hachage) servent pour construire des fichiers indexés, grâce à la
bibliothèque Berkeley DB.
o Le programme postmap est utilisé pour construire les fichiers indexés.
o Pour mettre à jour les alias, on utilisera la commande newaliases.
Éditer la table de correspondance « Map » /etc/aliases :
# vim /etc/aliases
# Basic system aliases -- these MUST be present.
mailer-daemon: postmaster
postmaster: root
# General redirections for pseudo accounts.
bin: root
daemon: root
adm: root
...
# trap decode to catch security attacks
decode: root
# Person who should get root's mail
root: user01
Construire le fichier indexé.
# newaliases

2.5. Premier test

Activer et démarrer Postfix.
# service postfix start
# chkconfig postfix on
Vérifier si Postfix tourne correctement.
# service postfix status
# cat /var/log/maillog
... starting the Postfix mail system
... daemon started -- version 2.10.1, configuration /etc/postfix
Basculer vers un compte utilisateur normal (# su - user01) et envoyer un mail vers un compte
mail externe auquel on a accès. Un point «. »  sur une ligne à part marque la fin du message.
# su - user01
user01$ mail user02@ismontic.ma
Subject: Test Postfix
Ceci est un test.
.
EOT
User01$
Se connecter au compte mail externe et vérifier si le message a bien été envoyé, puis
répondre à ce message. Si tout se passe bien, le répertoire utilisateur contient un nouveau
répertoire ~/Maildir, qui ressemble à ceci.
User02$ tree Maildir/
Maildir/
├── cur
├── new
│   └── 1497093622.V802I148M893901.serveur01.ismontic.ma
└── tmp
3 directories, 1 file
Le nouveau mail est un simple fichier texte, que l’on peut afficher avec less par exemple.
$ less Maildir/new/1497093622.V802I148M893901.serveur01.ismontic.ma
2.5.1. Gérer les mails avec Mutt
Mutt est un MUA (Mail User Agent) en ligne de commande. On peut l’utiliser sur des
machines dépourvues d’interface graphique.
Avant de lancer Mutt, éditer le fichier de configuration ~/.muttrc.
# touch ~/.muttrc
# chmod 700 ~/.muttrc
# vim ~/.muttrc
set ssl_starttls=yes
set ssl_force_tls=yes

set imap_user = 'change_this_user_name@gmail.com'

set imap_pass = 'PASSWORD'

set from='change_this_user_name@gmail.com'
set realname='Your Name'

set folder = imaps://imap.gmail.com/

set spoolfile = imaps://imap.gmail.com/INBOX
set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"

set header_cache = "~/.mutt/cache/headers"

set message_cachedir = "~/.mutt/cache/bodies"
set certificate_file = "~/.mutt/certificates"
set smtp_url =
'smtp://change_this_user_name@gmail.com:PASSWORD@smtp.gmail.com:465/'

set move = no
set imap_keepalive = 900

Lancer Mutt:
# mutt -s "Test Email" user@example.com < /dev/null
Ou
# mutt
La fenêtre principale de Mutt affiche la boite de réception. Les nouveaux mails sont marqués
par un N. Une barre d’état en haut de l’écran affiche les principaux raccourcis. En règle
générale, Mutt fonctionne avec les mêmes raccourcis que Vim. Pour lire un message, il suffit
de le sélectionner et d’appuyer sur Entrée.

2.6. Créer les comptes Linux pour la messagerie

Bien sûr, c’est plus élégant de créer des comptes virtuels gérés par une base de
données. Pour commencer, nous allons procéder d’une manière très simple par des comptes
Linux traditionnels.
Dans l’exemple qui suit, nous gérons le courrier de domaine ismontic.ma, avec les adresses
mail suivantes.
 user01.tri1@ismontic.ma
 user01.tri2@ismontic.ma
 user01.tri3@ismontic.ma
 user01.tri4@ismontic.ma
 user01.tri5@ismontic.ma
Dans un premier temps, nous allons créer des comptes Linux traditionnels, un par compte
mail, en respectant les conventions de nommage classiques.
# useradd -c "user01 tri1" -s /sbin/nologin user01.tri1
# useradd -c "user01 tri2" -s /sbin/nologin user01.tri2
# useradd -c "user01 tri3" -s /sbin/nologin user01.tri3
# useradd -c "user01 tri4" -s /sbin/nologin user01.tri4
# useradd -c "user01 tri5" -s /sbin/nologin user01.tri5
Deux remarques :
 Les utilisateurs n’ont pas de Shell de connexion, c’est-à-dire qu’ils ne pourront pas se
connecter directement au serveur.
 Un utilisateur peut disposer de deux comptes distincts, un pour chaque adresse mail.
Pour ne pas avoir à inventer des mots de passe raisonnablement compliqués pour
chaque utilisateur, on peut utiliser l’outil « pwgen ». Voici un exemple pour créer un mot de
passe aléatoire long de huit caractères, composé de chiffres et de lettres majuscules et
minuscules.
# pwgen -n -N 1
On va créer notre propre « base de données » sous forme de simple fichier texte mails.txt.
Nom Mail Login Pass
=================================================================
user01 tri1 user01.tri1@ismontic.ma user011 iesch6Ah
user01 tri2 user01.tri2@ismontic.ma user012 nai7abYi
user01 tri3 user01.tri3@ismontic.ma user013 axr2aeNu
user01 tri4 user01.tri4@ismontic.ma user014 aeFphk3t
user01 tri5 user01.tri5@ismontic.ma user015 Psaelie3
Étant donné qu’il contient des informations sensibles, on va le stocker dans un
endroit approprié, à l’abri des regards curieux.
# ls -l /root/mails.txt
-rw-------. 1 root root 466 11 juil. 10:07 /root/mails.txt
2.6.1. Les alias
Un alias est un nom supplémentaire pour recevoir du courrier électronique. En
réalité, les mails sont acheminés vers un compte qui existe déjà. Les alias sont définis dans le
fichier /etc/aliases.
...
# Person who should get root's mail
root: user01

# Utilisateurs
user011: user01.tri1
user012: user01.tri2
user013: user01.tri3
user014: user01.tri4
user015: user01.tri5
 Fait suivre le mail reçu à l'adresse « user011@ismontic.ma » au compte local
« user01.tri1 ».
 D’autres exemples d’alias :
# Fait suivre le mail reçu à l'adresse < user012@ismontic.ma >
# à l'adresse <nom.prenom@gmail.com > :
user012: nom.prenom@gmail.com
# Fait suivre le mail reçu à l'adresse < user013@ismontic.ma  >
# aux comptes "user01" et "user02" et à l'adresse <nom.prenom@exemple.org> :
user013: user1,user2, nom.prenom@exemple.org
# A la réception d'un mail à l'adresse < user014@ismontic.ma >,
# exécuter le scripte deleteTrash.sh :
user014: "|/chemin/vers/deleteTrash.sh"
Explication :
 La définition d’un alias dans le fichier d’entrée des alias à la forme ci-après :
nom: valeur1, valeur2, ...
o Le nom est une adresse locale (pas une partie de domaine).
o La valeur contient un ou plusieurs mots ci-après :
 Adresse email: Le mail est transféré à l’adresse email.
 /file/name: Le mail est ajouté à /file/name. L’envoi n’est pas limité à
un fichier courant. Par exemple, pour se débarrasser du courrier
indésirable, renvoyez-le à /dev/null.
 |commande : Le mail est «tuyauté» dans la commande
« commande ».
  :include:/file/name : Un mail est envoyé aux destinations listées
dans le fichier nommé. Les lignes dans le fichier :include: ont la même
syntaxe que le côté droit des entrées d’alias.
 Une destination peut être n’importe quelle destination qui est décrite
ci-dessus. Cependant, livré à "|command" et « /file/name » est
désactivé par défaut. Pour l’activer, éditez les configurations des
paramètres « allow_mail_to_commands » et « allow_mail_to_files ».
À chaque modification de ce fichier, il faut reconstruire /etc/aliases.db, la base
de données des alias avec :
# newaliases
2.6.2. Définir les destinataires autorisés
Dans la configuration par défaut, tous les comptes Linux peuvent recevoir du
courrier, y compris les comptes système comme root, named ou nobody si l’on utilise le
fichier /etc/aliases fourni par défaut. Dans notre configuration, c’est l’utilisateur user01 qui
recevra les mails pour les comptes système.
Pour tester ce comportement, on peut créer un utilisateur « user_test » avec
useradd, et à partir de cette adresse en envoie un mail à l’adresse « user01@ismontic.ma ».
On constate alors que « user01 » reçois le mail.
# tree /home/user01/Maildir/
/home/user01/Maildir/
├── cur
├── new
│   └── 1489396170.V803I1c00037M362342.ismontic.ma
└── tmp
On va donc instaurer quelques restrictions pour éviter de spammer notre système mail. Pour
ce faire, on va créer un fichier /etc/postfix/local-recips avec la liste de tous les destinataires
autorisés, en suivant la syntaxe suivante.
# vim /etc/postfix/local-recips
user011 x
user012 x
user013 x
user014 x
user015 x
user01 x
À partir de ce fichier, on va générer une base de données dans un format lisible pour Postfix.
# cd /etc/postfix
# postmap local-recips
Nous pouvons vérifier si le fichier a été généré correctement.
# postmap -s hash:local-recips
user01 x
user011 x
user012 x
user013 x
user014 x
user015 x
À chaque modification de local-recips, il faudra réinvoquer # postmap local-recips pour
reconstruire le fichier de base de données local-recips.db.
Pour prendre en compte les nouvelles restrictions, éditer /etc/postfix/main.cf et ajouter le
paramètre suivant.
# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
Prendre en compte les modifications.
# service postfix restart
À partir de là, seuls les utilisateurs explicitement définis dans local-recips pourront recevoir
du courrier.
2.6.3. Comptes Linux et adresses de messagerie
La prochaine étape consiste à faire correspondre les comptes Linux et les adresses de
messagerie. Pour ce faire, on va créer un fichier /etc/postfix/canonical.
# vim /etc/postfix/canonical
user01.tri1 user01.tri1@ismontic.ma
user01.tri2 user01.tri2@ismontic.ma
user01.tri3 user01.tri3@ismontic.ma
user01.tri4 user01.tri4@ismontic.ma
user01.tri5 user01.tri5@ismontic.ma
Convertir le tableau en un format lisible pour Postfix.
# cd /etc/postfix/
# postmap canonical
Définir le paramètre correspondant dans /etc/postfix/main.cf.
# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical
2.6.4. Domaines virtuels avec des utilisateurs
distincts
Commençons par quelques notions de base sur les domaines de messagerie que
Postfix peut gérer. Postfix distingue trois types de domaines :
2.6.4.1. Domaines locaux
Un utilisateur local est simplement un utilisateur système normal, répertorié dans le
fichier /etc/passwd.
 Cela signifie que tous les utilisateurs du système recevront des courriels pour tous les
domaines locaux.
 Le paramètre de configuration «mydestination» répertorie tous les domaines locaux.
2.6.4.2. Domaines de boîtes aux lettres virtuelles 
Un domaine « Mailbox virtuelle » est également un domaine utilisé pour recevoir des
courriers électroniques (est le plus important).
 Vous n'utilisez pas les utilisateurs du système (/etc/passwd) pour spécifier des
adresses électroniques valides dans ce domaine.
 A la place, vous indiquez explicitement à Postfix quelles adresses sont valides (sans
les créer).
  Un moyen simple de configurer de tels domaines et utilisateurs consiste à utiliser
des fichiers texte.
Example de "virtual_mailbox_maps" A revoir
Utilisateur virtuel Emplacement de la boîte virtuelle
john@example.org /var/mail/doe.org/john/Maildir
jack@example.org /var/mail/doe.org/jack/Maildir
jack@example.com /var/mail/foo.org/jack/Maildir

Vous avez deux domaines : example.org et example.com. Il faut d'abord informer Postfix de
l'existence de ces domaines. Ceci est effectué en mettant l'indication :
virtual_mailbox_domains = example.org example.com
Dans votre configuration de Postfix, vous devez ensuite informer Postfix des adresses mails
pour lesquelles vous êtes prêt à recevoir du courrier et de l'endroit sur le disque où il doit
ranger les courriers pour ces adresses.
Le fichier devant recevoir ces informations devrait être /etc/postfix/virtual_mailbox_users et
son contenu devrait ressembler à ceci :
john@example.org /var/vmail/example.org/john/Maildir
jack@example.org /var/vmail/example.org/jack/Maildir
jack@example.com /var/vmail/example.com/jack/Maildir
 Chaque entré est de la forme suivant :
o LHS pour « left hand side» (qui signifie côté main gauche): Adresses mail
o RHS pour « right hand side » (côté main droite) : Emplacements sur le
disque où stocker les emails pour chaque destinataire.
 Un tel fichier avec deux colonnes est appelé mapping ou hash table.
Dans le cas de nombreux domaines, la configuration « virtual_mailbox_domains » n'est pas
faisable. Donc c’est mieux d’utiliser un fichier de mapping pour configurer les domaines. Par
exemple /etc/postfix/virtual_mailbox_domains, il devra contenir les lignes suivants :
example.org OK
example.com OK
 La raison est qu'un fichier de hachage doit toujours avoir deux colonnes. Dans ce
cas d'un fichier de hachage concernant des données « uni-dimentionnelles »
(une liste de domaines) Postfix ne s'occupe pas de la seconde colonne.
 Celle-ci pourrait contenir n'importe quoi à la place de la mention « OK », mais elle
doit exister.
Si vous décidiez que ce système de fichiers texte est suffisant pour vos besoins il
faudra encore les compiler en utilisant la commande postmap comme ceci :
# postmap /etc/postfix/virtual_mailbox_domains
# postmap /etc/postfix/virtual_mailbox_users
 La commande créera des fichiers supplémentaires portant les mêmes noms que
ces fichiers mais avec un suffixe « .db ».
 N'oubliez pas de lancer la commande « postmap » après chaque modification
d'une table de hachage.
Pour que Postfix connaisse l'existence de ces fichiers vous devez rajouter ces lignes à son
fichier de configuration main.cf :
virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_users
 Testez la configuration.
 2.6.4.2.1. MailBox virtuelles avec MySQL 
Une table de hachage est simplement un moyen d'associer une valeur à une autre.
Tout ce que vous avez à faire est donc de demander à Postfix de prendre les deux colonnes
de cette table de hachage dans deux colonnes d'une table d'une base de données
Relationnel. On fait cela avec des fichiers de configuration en .cf .
Voici par exemple un fichier virtual_mailbox_maps.cf contenant :
# Informations de connexion au serveur MySQL
user = someone
password = some_password
hosts = 127.0.0.1

# Nom de la base MySQL à laquelle se connecter

dbname = mailserver

# La requête SQL à lancer

query = SELECT mailbox_path FROM virtual_users WHERE email_address='%s'
 En premier, vous devez créer une table de nom « virtual_users » qui va être composé
de deux colonnes.
o Le LHS est la colonne « email_address ».
o Le RHS est la colonne «mailbox_path».
 La requête SQL ci-dessus récupère le « mailbox_path » à partir d'une adresse de
courrier « email_address ».
 Les caractères « %s » représentent le garde place par lequel est transmis à la requête
la valeur du LHS à rechercher et qui est fournie par Postfix lors de chaque relève de
courrier.
Note : ici une recherche ne doit retourner qu'une ligne de la base de données. Postfix
n'a besoin que de savoir où se trouve le dossier de courrier d’un utilisateur donné. Il existe
d'autres tables de hachage qui peuvent renvoyer plusieurs valeurs RHS pour une valeur de
LHS donnée, donc plusieurs lignes de la base de données pour une requête, comme par
exemple dans la recherche d'alias virtuels.
Pour pouvoir utiliser le fichier de configuration ci-dessus vous devez le déclarer dans le
fichier main.cf de Postfix :
virtual_mailbox_maps = mysql:virtual_mailbox_maps.cf
 Si par la suite vous trouvez que cette table de hachage ne fait pas ce que vous
attendiez qu'elle fasse, vous pouvez utiliser la commande « postmap -q » pour
demander à Postfix quelle valeur de colonne droite correspond à une valeur de
colonne de gauche donnée.
 Disons que vous voulez connaître la valeur du champ « mailbox_path » pour
l'adresse john@example.org :
# postmap -q john@example.org mysql:virtual_mailbox_maps.cf
o Postfix va alors lancer la requête SQL ci-dessus avec votre argument «
john@example.org » :
SELECT mailbox_path FROM virtual_users WHERE
email_address='john@example.org'
Le résultat devrait être :
/var/mail/example.org/john/Maildir
2.6.4.3. Domaines d'alias virtuels
 Quand le domaine de l'adresse mail n'est pas celui de la machine, on passe par un
mécanisme d'adresses virtuelles pour faire correspondre ces adresses mail à des comptes
locaux, à d'autres adresses mail ou encore à des commandes à exécuter.
Les domaines d'alias virtuels sont utilisés pour transférer le courrier électronique
d'une adresse électronique vers une ou plusieurs autres adresses électroniques.
 Les domaines d'alias virtuels ne peuvent cependant pas recevoir de courrier
électronique et les enregistrer sur le disque de votre serveur. Ils ne font que
transférer le courrier ailleurs.
 Le mappage « virtual_alias_maps » contient les redirections (source, destination)
d'utilisateurs ou de domaines vers d'autres adresses électroniques ou des domaines
entiers.
 Incidemment, « virtual_alias_maps » est soumis à tout courrier électronique reçu.
Ainsi, dans la plupart des cas, vous n'avez pas vraiment besoin de domaines d'alias
virtuels, car vous pouvez déclarer tous les domaines en tant que domaines
« Mailbox virtuelles » et utiliser des mappes d'alias virtuels à des fins de transfert.
 Définir techniquement un domaine en tant que domaine d'alias virtuel amène Postfix
à accepter l'e-mail de ce domaine, mais vous avez toujours besoin d'une entrée dans
le mappage « virtual_alias_maps » pour indiquer à Postfix où transférer l'e-mail.
Créer un fichier /etc/postfix/virtual avec un tableau qui fait correspondre chaque
adresse mail d’un domaine virtuel à un compte Linux.
1ér exemple :
# /etc/postfix/virtual
user03@example.org user04@example.com
 Vous avez la source «user03@example.org» et la destination
«user04@example.com» du transfert.
 user03 ne recevra jamais l'e-mail.
2éme exemple :
# /etc/postfix/virtual
user03@example.org user04@example.com
user03@example.org user03@example.org
 user04 va recevoir le courrier, et user03 va recevoir une copie de ce courrier.
3éme exemple :
# /etc/postfix/virtual
@example.org user04@example.com
 Postfix acceptera le courrier électronique de tout utilisateur du domaine
« example.org » et le transmettra à l'adresse « user04@example.com »
Pour rendre ce fichier lisible pour Postfix.
# postmap virtual
Adapter /etc/postfix/main.cf pour prendre en compte les domaines virtuels.
# Domaines locaux
mydestination = $myhostname, localhost.$mydomain, localhost

# Domaines virtuels
virtual_alias_domains = ismontic.ma,ofppt.ma
...
# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = hash:/etc/postfix/virtual
Il ne reste qu’à recharger Postfix pour prendre en compte la nouvelle configuration.
# service postfix restart

En résume :
Le fichier /etc/aliases est implémenté par « alias_maps ». De l'autre côté, postfix a « virtual_maps »
et « virtual_alias_maps » pour gérer l'alias de messagerie. Alors, quelle est la différence entre eux?
 Paramètre « alias_maps » :
o Utilisé uniquement pour la livraison locale.
o Selon la classe d'adresse dans le suffixe, l'e-mail sera livré par local (Démon de
livraison des mails de Postfix) si les noms de domaine destinataires sont répertoriés
dans « mydestination »
o L'entrée de recherche (Appelé nom dans le manuel) était uniquement des parties
locales provenant d'adresses de messagerie complètes (par exemple, myuser de
myuser@example.com). Il supprime les parties de domaine du destinataire.
o Le résultat de la recherche peut contenir un ou plusieurs des éléments suivants:
 adresse e-mail: l'e-mail sera transféré à l'adresse e-mail
 /fichier/nom: l'e-mail sera ajouté à /fichier/nom
 |commande: courrier redirigé vers la commande
 :inclure:/fichier/nom: inclure l'alias de /fichier/nom
 Paramètre « virtual_alias_maps » :
o Utilisé par livraison virtuelle
o Toujours invoqué la première fois avant toute autre classe d'adresse.
o Peu importe que le domaine destinataire soit répertorié dans mydestination,
« virtual_mailbox_domains » ou ailleurs. Il remplacera l'adresse/l'alias défini à
d'autres endroits.
o L'entrée de recherche a un certain format :
 user@domain: il correspondra littéralement à user@domain
 utilisateur: il correspondra à « utilisateur@site » lorsque le site est égal à
$myorigin, lorsque le site est répertorié dans $mydestination, ou lorsqu'il
est répertorié dans $inet_interfaces ou $proxy_interfaces.
 Cette fonctionnalité chevauche avec la fonctionnalité de la base de
données d'alias locaux.
 @domain: il correspondra à tout e-mail destiné au domaine,
indépendamment des parties locales
o Le résultat de la recherche doit être :
 Adresse e-mail valable
 utilisateur sans domaine.
o Postfix ajoutera $myorigin si « append_at_myorigin » est défini sur yes (Valeur par
défaut).
Questions/Réponses :
 Pourquoi avons-nous besoin de /etc/alias lorsque le courrier électronique à l'intérieur de la
carte des alias virtuels semble le remplacer?
 o Comme vous pouvez le voir ci-dessus, alias_maps (/etc/aliases) a quelques
fonctionnalités supplémentaires (à côté du transfert) comme la canalisation à
commander. Cela contraste avec « virtual_alias_maps » qui ne fait que transférer
des e-mails.
 Quel est le but de disposer de ces 2 alias distincts et quand décidons-nous quand utiliser
quoi?
o L’inconvénient d'alias_maps est que vous ne pouvez pas différencier si le
destinataire d'origine à la forme « root@example.com » ou « root@example.net ».
Les deux seront mappés à l'entrée « root » dans alias_maps.
o D’autre part, vous pouvez définir différentes adresses de transfert avec
« virtual_alias_maps ».
 Pourquoi fail2ban (qui est configuré pour envoyer un e-mail à root@localhost) va-t-il
d'abord suivi l'adresse e-mail indiquée dans « alias_maps » (/etc/aliases) et a ensuite décidé
de l'ignorer une fois « virtual_alias_maps » ajouté?
o Avant l'ajout de « virtual_alias_maps »: root@localhost était aliasé par alias_maps
parce que localhost était répertorié dans mydestination.
o Après la définition de « virtual_alias_maps »: l'entrée root (dans virtual_alias_maps)
n'a pas de parties de domaine et localhost a été répertorié dans mydestination, donc
il correspondra à root me@example.com.
 Pourquoi tous les services ne lisent-ils pas les alias de messagerie mentionnés dans
/etc/aliases et ne fonctionnent-ils que lorsque les alias de messagerie sont ajoutés dans la
carte d'alias virtuels?
o La commande « mail root » enverra un courrier électronique à root. En raison du
manque de parties de domaine, Postfix trivial-rewrite (Démon de réécriture et de
résolution d'adresses Postfix) ajoutera $myorigin aux parties de domaine. Ainsi, le
courrier sera envoyé à root@myorigin.
 Avant l'ajout de « virtual_alias_maps »: Malheureusement, myorigin n'est
pas répertorié dans mydestination, il ne sera donc pas alias par alias_maps.
 Après l'ajout de « virtual_alias_maps »: L’entrée de root (dans
virtual_alias_maps) n'a pas de parties de domaine et myorigin (évidemment)
identique à myorigin, donc

2.6.5. Configuration utils

2.6.5.1. Changement de port SMTP
Le port 25 était à l’origine, utilisable pour émettre un nouveau message vers son
serveur de messagerie, que pour les échanges entre les serveurs mails eux même. Du coup,
un problème s’est posé avec l’arrivée des virus sur les ordinateurs personnels au début des
années 2000 : des « PC zombies » se sont mis à émettre du spam en masse, souvent à l’insu
de leur propriétaire.
En conséquent, les FAI tentent de lutter contre ce phénomène, et ont opté une
méthode radicale : empêcher leurs clients de se connecter à des serveurs sur le port 25, sauf
lorsqu’il s’agit des serveurs SMTP du FAI en question, et que donc la connexion pourra être
contrôlée et filtrée.
A cet égard, le protocole SMTP prévoit un deuxième numéro de port, le 587, destiné
lui exclusivement à l’envoi de nouveau message par l’utilisateur, après une phase
d’identification sécurisée par login et mot de passe.
 Sa variante, le port 465, est destinée aux connexions intégralement cryptées par SSL
(connexions dites « SMTPS »).
Il suffit donc d’utiliser l’un de ces deux numéros de port (587 ou 465) pour
contourner le blocage du port 25 par votre FAI.
(A noter que sur le port 587, le début de la communication avec le serveur se fait en clair,
mais qu’il est souvent possible de basculer sur un mode crypté grâce à l’activation d’une
commande spécifique : « STARTTLS », que la plupart des serveurs supportent.)
Pour changer le numéro de port de Serveur Postfix, ouvrez le fichier
/etc/postfix/master.cf
# /etc/postfix/master.cf
smtp inet n - n - - smtpd
Remplacer le mot « smtp » par le numéro de port 587, la ligne devient :
587 inet n - n - - smtpd
Puis redémarrer le service Postfix :
# service postfix restart
2.6.5.2. Changement de la taille maximale de
message
Si la taille d’un message électronique dépasse la taille maximum configurée dans
Postfix, cela a pour conséquence de bloquer l'envoi des mails qui ont une pièce jointe un peu
trop grande. Voici comment corriger ce problème.
Dans un premier temps, lancez cette commande pour connaître la taille maximum autorisée
dans Postfix :
# postconf -d | grep message_size_limit
message_size_limit = 10240000
 La limite est de 10240000 octets (10.24 Mo).
Pour augmenter cette valeur, il suffit d'utiliser postconf de la manière suivante :
# postconf -e 'message_size_limit = 20240000'
 -e : Édite le fichier de configuration main.cf.
 Les paramètres et les valeurs sont spécifiés depuis la ligne de commande.
 Utilisez les guillemets correctement afin d’inhiber les méta-caractères du SHELL
ainsi que les espaces blancs.
 Vérifier l’ajout de paramètre :
# egrep "message_size_limit" /etc/postfix/main.cf
message_size_limit = 20240000
Puis, on recharge la configuration du serveur :
# service postfix reload
3. Installation et configuration de Dovecot
3.1. Introduction
Dovecot est un serveur IMAP et POP3 pour les systèmes d'exploitation Unix et
dérivés, conçu avec comme premier but la sécurité. Dovecot est distribué en double licence
MIT et GPL version 2.
Alors que Postfix sert de serveur SMTP et de relais, Dovecot servira de serveur IMAP
pour récupérer les messages stockés sur l'hôte mail. Dovecot inclut également une
implémentation SASL qui peut être utilisée par Postfix pour authentifier les utilisateurs

3.2. Fonctionnalités
Dovecot gère les formats de boîte de messagerie mbox et Maildir. Les quotas
Maildir++ sont également gérés. Il prend en charge de manière complète IMAP4 révision 1 et
POP3.
Les méthodes d'identifications offertes sont CRAM-MD5, DIGEST-MD5, APOP, NTLM
de Microsoft, GSSAPI (Kerberos v5), LDAP, Base de données RPA, LOGIN, à l'aide d'un
compte anonyme, OTP et SKEY.
 Dovecot offre aux administrateurs de nombreux outils de migration des serveurs
Uw-IMAP, Uw-POP3, Linuxconf, VIMAP, Courier IMAP et POP3 ainsi que Cyrus IMAP et POP3.
Dovecot inclus également un MDA, avec un support optionnel des filtres Sieve « Un
langage de filtrage de courrier électronique.
L'IPv6, SSL et TLS sont pris en charge.
Les systèmes d'exploitation pris en charge sont GNU/Linux, Solaris, FreeBSD,
OpenBSD, NetBSD et MacOSX.

3.3. Modules
Dovecot propose également des modules qui permettent d'augmenter le nombre de
fonctionnalités.
 Module quota pour l'application et le suivi des quotas.
 Module imap_quota pour interroger l'état actuel des quotas.
 Module acl pour le contrôle des accès aux boîtes de messagerie.
 Module convert pour passer d'un modèle de boîte de messagerie à l'autre à la
connexion de l'utilisateur.
 Module trash afin d'effacer les emails du répertoire Trash quand l'utilisateur dépasse
son quota.
 Module lazy_expunge afin de faire que les commandes EXPUNGE et DELETE ne
fassent que déplacer les mails à un autre endroit.
 Module expire qui permet d'effacer les courriels au bout d'un certain nombre de
jours.
 Module zlib qui permet un accès en lecture seule aux boîtes de messagerie
compressées au format gzip.
 Module mail_log afin d'enregistrer des actions des emails.
Également disponibles des modules externes.

3.4. Installation et configuration

Les paquets Dovecot peuvent être installés à partir du dépôt CentOS.
# rpm -ihv dovecot-2.0.9-22.el6.x86_64.rpm
Les fichiers de configuration de Dovecot est se situer dans /etc/dovecot/ et
/etc/dovecot/conf.d
On va créer un simple serveur POP3/IMAP à partir de fichier de configuration se situant
sous /etc/dovecot/dovecot.conf, on l’édite comme suit :
# Décommenter la ligne suivant pour activer les protocoles
protocols = imap pop3
# Ajouter la ligne suivante concernant la boîte mail
mail_location = maildir:~/Maildir
On démarre Dovecot :
# service dovecot start
On test et affiche la configuration final :
# doveconf -n
# 2.0.9: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-696.el6.x86_64 x86_64 CentOS release 6.9 (Final)
mail_location = maildir:~/Maildir
mbox_write_locks = fcntl
passdb {
driver = pam
}
protocols = imap pop3
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
userdb {
driver = passwd
}
 Pour les utilisateurs et la méthode d’authentification, on va utiliser la base de
données du système (Par défaut sur Dovecot).
Affiche les ports ouverts sur votre serveur :
# netstat -tunlp | egrep "master|dovecot" # egrep = grep -E
 -t : Les connections TCP.  -u : Les connections UDP.
 -n : Affiche les adresses en format numérique.
 -l : Affiche les processus qui sont à la demande de connexion (Serveur).
 -p : Affiche le nom et le PID des processus propriétaires.
Rappel:
Voici la configuration des ports par défaut :
Sans SSL/TLS Avec SSL/TLS
SMTP Port 25 ou 587 Port 465
POP Port 110 Port 995
IMAP Port 143 Port 993

3.5. Teste de la configuration

On va tester la réception de mails via le client Thunderbird :
$ echo "Je confirme le RDV aujourd'hui à 12h." | mail -s "Ma voiture" user02@domain.ma
On peut envoyer une pièce jointe avec l’émail via la commande mutt « Pas encore tester »:
$ echo "Ci-joint la photo de ma voiture" | mutt -s "Ma voiture" -a Voiture.jpg --
tri2a@domain.ma
Remarque : Vous pouvez envoyer vos emails avec « Thunderbird ». A condition que vous
changez le type de compte, pour faire ça :
1. Ouvrir la session de l’utilisateur « user01 » depuis le serveur.
2. Ouvrir la session de l’utilisateur « user011 » depuis une machine cliente.
3. Allez au Menu de Thunderbird  Préférences  Paramètres de comptes.
4. Ensuite, cliquez sur « Gestion de comptes » et choisir « Ajouter un compte de
messagerie ».
5. N’oublier pas de supprimer l’ancien compte UNIX.
4. Récupérer les méls d'un serveur POP3/IMAP
4.1. Fetchmail
Le programme fetchmail permet de récupérer ses méls d'un serveur POP ou IMAP
distant. On peut vouloir utiliser un tel programme si on n'a pas de connexion permanente à
l'Internet (avec un modem, par exemple), ou si on veut redistribuer les courriers pour tout
un réseau local. 
Pour préciser les paramètres à utiliser, il faut écrire un fichier ~/.fetchmailrc. Voici ce
fichier ~/.fetchmailrc :
set bouncemail
poll pop.gmail.com port 995 with protocol pop3
user "email_distant@gmail.com" there password "xxxxxxx" is
"compte_local@destination.ma" here options ssl fetchall mda "/usr/bin/procmail -Y -d
compte_local"

poll mail.domain-local.ma port 995 with protocol pop3

user "compte_local" there password "xxxxxx" is "compte_local_dest" here options
ssl fetchall mda "/usr/bin/procmail -Y -d compte_local_dest"
A chaque appel de fetchmail, ce fichier sera lu. Les méls seront récupérés du
serveur pop.domain.tld, qui est le serveur POP du fournisseur d'accès.
 Le login sur ce serveur POP est email_distant@gmail.com,
 Pour mot de passe « xxxxxxx ».
 Les méls récupérés par fetchmail seront déposés dans la boîte aux lettres de
l'utilisateur compte_local_dest.
 Il faut penser à rendre le fichier ~/.fetchmailrc en lecture seule pour l'utilisateur, pour
que le mot de passe ne puisse être lu par d’autres utilisateurs.
 On peut mettre autant de serveurs que l'on veut en rajoutant une ligne poll par
serveur.
Pour vérifier que la syntaxe de notre fichier ~/.fetchmailrc  est bonne, taper simplement :
$ fetchmail --version
Deux options intéressantes peuvent rajoutées dans ce fichier : 
 keep, qui précise que les méls récupérés doivent également rester sur le serveur POP,
 fetchall, qui demande de récupérer tous les méls, y compris ceux déjà lus.
Pour commencer, on peut tester fetchmail avec l'option -k, qui précise que les méls
récupérés doivent également rester sur le serveur POP. Cette option peut aussi être définie
dans le fichier de configuration ~/.fetchmailrc.
$ fetchmail -v -v
On peut aussi lancer fetchmail en mode démon pour récupérer à intervalles réguliers le
courrier :
$ fetchmail -d 120 -t 20
 Pour récupérer les méls toute les 120 secondes, en abandonnant si aucune réponse
n'est donnée au bout de 20 secondes.
Au démarrage de la machine, on peut également mettre :
su user01 -c fetchmail -d 120 -t 20
 Pour lancer la récupération des méls pour l'utilisateur user01.
Les courriers seront transmis via SMTP.
 On peut forcer fetchmail à appeler directement l'agent de livraison MDA des
courriers en utilisant l'option -m (ou mda si on le met dans le fichier de configuration). Par
exemple, on peut mettre -m /usr/bin/procmail -d %T.