mise en place d'un système de messagerie sécurisée pour une pme/pmi

UNIVERSITE GASTON BERGER DE SAINT-LOUIS

UFR DE SCIENCES APPLIQUEES ET DE TECHNOLOGIE

SECTION INFORMATIQUE

MEMOIRE DE MAITRISE INFORMATIQUE

MISE EN PLACE D’UN SYSTEME DE MESSAGERIE SECURISEE POUR UNE

PME / PMI

PRESENTE ET SOUTENU PAR :

Papa Cheikh CISSE et Mactar Ndiaga SECK

Sous la direction de :

M. TRAORE Mahamadou

Année Académique 2009/2010 Numéro d’ordre : 29

Présenté et soutenu par : Papa Cheikh CISSE et Mactar Ndiaga SECK Page | 2

Dédicaces Je dédie ce mémoire:

A Allah le tout puissant par qui le savoir a un sens,

A ma chère mère Rokhaya BADIANE qui, de par sa bravoure, a su faire de moi l’homme que je suis devenu. Maman, tu n’as jamais baissé les bras dans la difficulté et tu as toujours cru en ton fils aîné. Ce travail t’est dédié.

A mon défunt et regretté père Ibrahima CISSE qui, de son vivant, n’a cessé d’inculquer en moi l’art de bien faire et celui de ne jamais laisser tomber devant une difficulté. Je lui dois cette réussite.

A mes très respectueux petits frères Mamadou Lakhassane et Papa Ali CISSE.

A ma chère sœur Aissatou Cisse sans qui ce mémoire n’aurait pas pu être rédigé. Tu comprendras.

A ma tante Ndeye Seyni Badiane qui m’a accompagné à devenir un homme.

A mes oncles Saër Badiane, Mamadou Lakhassane Cisse qui me sont si chères et à qui je suis très reconnaissant.

A tata Mary et à tata Ndeye Marème Diakhaté.

Enfin à toute ma famille, mes amis, voisins, camarades de classe et toute personne qui de près ou de loin n’a cessé de me soutenir durant mon parcours.

Papa Cheikh CISSE

Au nom de Dieu clément et miséricordieux

Ce travail fruit de dur labeur est dédié à ma famille au sens africain du terme

En tête mon défunt père Pape Thioro Gor Seck qui a semé et entretenu la plante que je suis et qui n’a

pas eu le temps de voir les fruits de celle-ci.

A ma chouette mère Awa Niang qui a toujours été mon dernier rempart, ses prières me donnent

l’énergie et la force pour avancer.

A mes aimables frères et sœur pour tout le soutien moral et l’amour qu’ils me portent.

A mon homonyme Ndiaga Seck et à toute la famille Seck

A ma tante Adjara Niang et toute la famille Niang et Kamara

A mes amis d’enfance à khombole

A mes amis de l’université Gaston berger de Saint-Louis

Et à toute personne qui a participé de près ou de loin à la réussite de ce travail.

Mactar Ndiaga SECK


Remerciements

Ce travail a été réalisé à l’Université Gaston Berger de Saint Louis. Nos remerciements vont à

l’endroit de tout le corps administratif et professoral qui a assuré notre formation,

notamment à:

La direction de l’UFR de Sciences Appliquées et de Technologies

La section informatique de l’UGB

M. TRAORE Mahamadou, notre encadreur, pour ses bonnes directives.

Mme DIOP Aichetou du service technique de l’UFR SAT

M. AMEKOUDI Stefano Komla A. du Centre d’Accès à l’information de Saint Louis

(Agence Universitaire de la Francophonie) pour sa disponibilité et ses bons conseils.

Nous lui sommes très reconnaissants

M. FALL Ibrahima du Centre d’Accès à l’information de Saint Louis et à tout le

personnel de ce service pour son accueil et sa convivialité.

Notre reconnaissance ensuite à nos proches, amis et à toutes les personnes de bonne

volonté qui nous ont aidé tout au long de notre parcours.


Table des matières

Dédicaces 1

Remerciements 3

Table des matières 4

Liste des tableaux 6

Liste des figures 7

Liste des sigles 8

Introduction 9

Partie 1: Présentation générale 10

1.1 Besoins d’une PME/PMI en termes de TIC 10

1.2 Apports d’un système de messagerie à une PME/PMI 10

1.3 Enjeux et objectif de sécurité pour un tel système 11

Partie 2: Mise en place du système de messagerie 12

2.1 Des concepts clés de la messagerie électronique 12

2.1.1 Les agents de la messagerie 12

2.1.1.1 Le MTA (Mail Transfert Agent) 11

2.1.1.2 Le MUA (Mail User Agent) 12

2.1.1.3 Le MDA (Mail Delivery Agent) 12

2.1.2 Les protocoles 14

2.1.2.1 Protocole SMTP 13

2.1.2.1 Protocoles POP3 et IMAP 15

2.1.2.2 Protocole Telnet 16

2.2 Architecture et principe de fonctionnement 18

2.2.1 Architecture de fonctionnement 18

2.2.2 Principe de fonctionnement 21

2.3 Etapes pour mettre en place un système de messagerie 22

2.3.1 Mise en place des services préalables 22

2.3.2 Mise en place du service de messagerie 32

Partie 3: Sécuriser le système de messagerie 47

3.1 Authentification SMTP avec SASL 47

3.1.1 Principes et objectifs de SASL 47


3.1.2 Configurer Postfix et Dovecot pour SASL 48

3.2 Sécurisation des communications 51

3.2.1 Protection contre l’Open-Relay et le spam 51

3.2.2 Les certificats SSL 53

3.2.3 Chiffrement des communications IMAP et SMTP avec OpenSSL 55

3.2.4 Configuration d’un firewall 57

3.3 Gérer l’intégrité des données 59

3.3.1 Filtrage de contenu avec Amavis 59

3.3.2 Intégration d’un antivirus : ClamAV 60

3.3.3 Intégration d’un Anti Spam : Spamassassin 61

3.3.4 Tri des messages avec SIEVE 65

Bibliographie / Webographie 69

Conclusion 70

Annexes 71


Liste des tableaux

Tableau 1 : Récapitulatif des principales commandes SMTP__________________________71

Tableau 2 : Principales commandes POP3 et leurs descriptions_______________________73


Liste des figures Figure 1 : Architecture de fonctionnement des différents éléments du système de messagerie____ 19

Figure 2 : Menu d’installation d’Ubuntu Server 10.04 LTS__________________________________ 23

Figure 3 : choix d’une adresse IP fixe pour le serveur______________________________________24

Figure 4 : Sélection de services à installer en même temps qu’Ubuntu-Server__________________25

Figure 5 : Ecran de première connexion au serveur_______________________________________ 26

Figure 6 : Première étape de la configuration de Postfix___________________________________ 35

Figure 7 : Interface de configuration de RoundCube (RoundCube Installer) ____________________42

Figure 8 : Interface de connexion du RoundCube Webmail_________________________________43

Figure 9 : Boite aux lettres d’un utilisateur______________________________________________43


Liste des sigles

TIC: Technologies de l’Information et de la Communication

SMTP/ESMTP: Simple Mail Transfer Protocol / Extended Simple Mail Transfer Protocol

POP/POP3: Post Office Protocol / Post Office Protocol 3

IMAP: Internet Message Access Protocol

SSL/TLS: Secure Socket Layer / Transport Layer Security

SSH: Secure Shell

MTA: Mail Transfer Agent

MUA: Mail User Agent

MDA: Mail Deliver Agent

TCP/IP: Transmission Control Protocol / Internet Protocol

FTP: File Transfer Protocol

HTML/ XHTML: HyperText Markup Language / eXtensible HyperText Markup Language

HTTP: HyperText Transfer Protocol

LTS: Long Term Support

PME/PMI: Petite et Moyenne Entreprise / Petite et Moyenne Industrie

DNS: Domain Name System

UID: User IDentifier

GID: Group IDentifier

GPL: General Public License

AJAX: Asynchronous JavaScript And XML.

SOAP: Simple Object Access Protocol

LDAP: Lightweight Directory Access Protocol

CSS: Cascade Style Sheets

MIME: Multipurpose Internet Mail Extensions

SASL: Simple Authentication and Security Layer

FQDN: Fully Qualified Domain Name

CRLF: Carriage Return Line Feed

FAI: Fournisseur d’Accès à Internet

UFW : Uncomplicated FireWall


Introduction

Il ne fait désormais plus aucun doute que les technologies de l'information et de la

communication représentent la révolution la plus importante et la plus innovante qui a

marqué la vie de l'humanité en ce siècle passé. En effet, elles viennent nous apporter de

multiples conforts à notre mode de vie en révolutionnant le travail des individus par leur

capacité de traitement d'information, d'une part, et de rapprochement des distances d'une

autre.

Parmi ces technologies, la messagerie électronique, aussi appelée «electronic-mail» ou «e-

mail», est assez développée dans les organisations aux cours de ces dix dernières années,

grâce à sa facilité d'utilisation et son utilité perçue.

Il est devenu l'un des outils les plus répandus dans l'internet des entreprises ou des

particuliers. C'est un service gratuit qui constitue un moyen de communication privilégié

entre des personnes à travers Internet. Utilisé pour des applications très variées -

personnelles, professionnelles, associatives, politiques, etc., celui-ci occupe une place de

plus en plus prépondérante par rapport aux moyens de communication traditionnels. Outre

son faible coût, la messagerie électronique a l'avantage d'optimiser la communication et la

diffusion d'informations ce qui la rend indispensable au sein d’une PME/PMI.

Dès lors, cette forte utilisation de la messagerie électronique constitue l’une de ses

principales faiblesses, dans la mesure où elle attire les spammeurs et autres polluposteurs

de l’internet. Ceux-ci non seulement en profitent pour promouvoir des produits de tout

genre, mais peuvent aller jusqu’à intercepter quelques messages circulant sur le réseau.

C’est à cause de cela que le courrier des utilisateurs est devenu la ressource la plus sensible

d’un système informatique obligeant les entreprises à sécuriser leurs systèmes de

messagerie internes.

Ainsi, nous allons dans le cadre de ce mémoire, indiquer comment un système de

messagerie, de par sa mise en place et sa sécurisation pourrait répondre aux besoins en

termes de TIC d’une PME/PMI. Pour cela après avoir éclairci sur ces quelques apports, nous

expliquerons le fonctionnement d’un système de messagerie électronique, avant de passer à

sa mise en place pour la PME/PMI pour enfin terminer par sa sécurisation.


Partie 1: Présentation générale

1.1 Besoins d’une PME/PMI en termes de TIC

Internet entraîne des changements de taille dans la nature des pratiques commerciales. Bon

nombre de ces changements se traduiront par des avantages concurrentiels pour la plupart

des entreprises, en particulier les PME. Internet donne accès à tout un monde de nouveaux

marchés et il est aussi facile d'y entrer que de transmettre un message par courrier

électronique. Il s'agit peut-être là de l'avantage le plus évident que les entreprises pourraient

en retirer.

Les entreprises veulent trouver de nouveaux clients dans leur environnement immédiat,

dans la province voisine ou sur un autre continent. Cela s’explique que le courrier

électronique a été adopté par presque tous les organismes qui ont besoin de communiquer

avec le reste du monde, en grande partie parce qu'il coûte infiniment moins cher.

1.2 Apports d’un système de messagerie à une PME/PMI

Le système de messagerie est aujourd'hui le moyen de communication le plus populaire sur

Internet. C'est également l’un des moins chers à mettre en œuvre, parce que simple, rapide

et fiable. En raison de sa popularité, le courrier électronique permet de communiquer avec

un vaste auditoire. Il tend à prendre une place de plus en plus prépondérante par rapport

aux moyens de communication traditionnels. Bien qu'il puisse incorporer des graphiques,

des fichiers sonores et visuels, il sert principalement à l'envoi de textes avec ou sans

documents annexés. Grâce au courrier électronique, les PME/PMI peuvent communiquer

avec leurs clients et fournisseurs dans le but d'échanger des renseignements commerciaux,

relatifs à leurs activités quotidiennes, y compris des renseignements sur les ventes, la prise

de rendez-vous, le soutien à la clientèle, la diffusion de documents, la prise de commandes,

l'envoi des factures et la vérification des comptes en souffrance. La messagerie électronique


permet de réduire le nombre d'appels internes et externes, de rencontres entre direction et

personnel. Il est aussi un excellent moyen de coordination d'une équipe ou d'un service. On

peut citer d’autres cas que l’utilisation de la messagerie favorise:

Un texte expédié par un système de messagerie électronique sera non seulement lu par

son destinataire mais il pourra également être stocké dans un fichier.

La grande majorité des systèmes actuels permettent d'envoyer des fichiers attachés à

vos messages. Ces fichiers peuvent être, par exemple, des données spécifiques à une

application de votre client ou fournisseur. C'est aussi souvent des fichiers de l'un des

tableurs ou système de traitement de textes présents sur le marché.

La transmission est immédiate, et votre interlocuteur pourra avoir accès à son courrier

en déplacement ou depuis son domicile.

Des filtres sélectifs peuvent être programmés pour trier les messages adressés à un

destinataire.

1.3 Enjeux et objectif de sécurité pour un tel système

La messagerie électronique est devenue le système critique d’une entreprise puisque c’est le

cœur de toutes communications entre employés. Le fonctionnement de ce service impactera

directement sur l’activité de votre compagnie. Les responsables de certaines entreprises

croient parfois à tort que, les données qu’ils abritent n’étant pas confidentielles, l’enjeu de la

sécurité est nul pour leur entreprise. Pour autant, accepteraient-ils une indisponibilité de

leurs ressources 80% du temps pour cause de réinstallation suite à une compromission ?

Supporteraient-ils que l’accès réseau, qu’ils payent fort cher chaque mois, soit utilisé à 99 %

pour un site «warez» et se trouve indisponible pour leurs propres besoins ? Se satisferaient-

ils d’être mis en liste noire par leurs correspondants pour avoir négligé un serveur de

messagerie qui autorise le relais ? On pense tous que non. D’où la raison pour une PME/PMI

d’investir en sécurité de sa messagerie.


Partie 2: Mise en place du système de

messagerie

2.1 Des concepts clés de la messagerie électronique

2.1.1 Les agents de la messagerie

Un système de messagerie électronique est l’ensemble des éléments contribuant à

transmettre un courriel de l’émetteur au récepteur.

2.1.1.1 Le MTA (Mail Transfert Agent)

Le MTA est un programme qui permet d’envoyer le message d’un serveur à un autre. Ce

logiciel est situé sur chaque serveur de messagerie. Il est composé d’un agent de routage et

d’un agent de transmission. Il envoie le message via un protocole sortant. Notons que les

protocoles sortants permettent de gérer la transmission du courrier entre les systèmes de

messagerie et le plus utilisé est le Simple Mail Transfert Protocol (SMTP). Les messages sont

transférés au MTA du destinataire, sauf si celui-ci est le MTA traitant actuellement le mail :

dans ce cas le message est transféré à un MDA. Lorsqu'un MTA veut transférer un message à

un MTA qui est indisponible, il met ce message dans sa file d'attente : il essaiera plusieurs

fois de retransmettre le message, jusqu'à ce que le MTA destinataire soit à nouveau

disponible. Au-delà d'un certain nombre d'essais infructueux (ou d'une certaine durée selon

la configuration), le message sera rejeté par le MTA. Il peut rejeter un message reçu pour

une de ces raisons :

serveur non concerné : les MTA sont en général configurés pour n'accepter que des

messages expédiés par des personnes appartenant à un certain réseau (par exemple

celui des clients pour un FAI) et/ou que des messages destinés à certaines adresses.


expéditeur en liste noire : les serveurs connus comme étant utilisés par les

spammeurs sont répertoriés dans des listes noires ; certains MTA rejettent les

messages expédiés depuis ces serveurs

Le rejet d'un message provoque généralement l'envoi d'un email à l'expéditeur l'informant

que le message a été refusé. Cependant, cela est de moins en moins systématique en raison

de l'engorgement des réseaux et de la multiplication des virus et spammeurs qui indiquent

une fausse adresse d'expéditeur.

Il existe plusieurs MTA et les plus côtoyés sur internet sont : Sendmail, Postfix, Exim4, Qmail.

2.1.1.2 Le MUA (Mail User Agent)

C’est un logiciel client de messagerie qui fournit un environnement pour la gestion des

courriels (saisie, suppression, réception). Il est également capable d’expédier le message au

MTA le plus proche.

Il faut faire la distinction entre le MUA installé sur le système de l’utilisateur qui est appelé

client de messagerie (par exemple Mozilla Thunderbird, Microsoft Outlook, Eudora Mail,

Incredimail) et celui accessible via un navigateur appelé webmail. Ce dernier est un site web

(Hotmail, LaPoste…) qui remplit les mêmes fonctions que le client de messagerie mais qui ne

nécessite pas d’installer quoi que ce soit sur son ordinateur pour gérer son courrier, un

simple navigateur (Mozilla, Internet Explorer) étant suffisant. Un avantage de webmail d’une

telle méthode de consultation est la possibilité de le faire à partir de n’importe quelle

machine connectée au réseau dans le monde, le courrier restant en permanence sur le

serveur. Un désavantage du webmail est un possible ralentissement si trop d’utilisateurs

travaillent simultanément.

2.1.1.3 Le MDA (Mail Delivery Agent)

Le MDA est un agent qui est en charge de la gestion des boites aux lettres. Il prélève le

courrier dans les files d’attentes du MTA et le dépose dans le répertoire de boites aux lettres


de l’utilisateur. Pour cela il est souvent considéré comme le point final d’un système de

messagerie. Il est possible de placer des fonctions de sécurité à ce niveau : appels antivirus

et ou anti spam.

Par exemple dans le MDA on peut appliquer à tous les mails :

des filtres anti-spam qui permettent de se débarrasser des courriers indésirables.

des filtres anti-virus pour contrôler les virus.

Le MDA est l’outil de personnalisation des fonctions de sécurité. Si l’utilisateur souhaite

régler lui-même les paramètres de fonctionnement des outils de sécurité, c’est là que

l’opération doit se faire. De ce fait il est possible des filtres personnalisés pour trier les mails

dans différents dossiers.

Il existe plusieurs serveurs MDA, les plus courants sont Cyrus, Procmail, Maildrop, Dovecot.

2.1.2 Les protocoles

Un protocole est une méthode standard qui permet la communication entre des processus

(s'exécutant éventuellement sur différentes machines), c'est-à-dire un ensemble de règles et

de procédures à respecter pour émettre et recevoir des données sur un réseau. Il en existe

plusieurs selon ce que l'on attend de la communication.

On les classe généralement en deux catégories:

Les protocoles orientés connexion: Il s'agit des protocoles opérant un contrôle de

transmission des données pendant une communication établie entre deux machines.

Les protocoles non orientés connexion: lorsqu’aucune connexion n’est établie entre la

machine émettrice et celle réceptrice.

2.1.2.1 Protocole SMTP

Le Simple Mail Transfer Protocol (littéralement «Protocole simple de transfert de courrier»),

généralement abrégé SMTP, est un protocole de communication utilisé pour transférer le


courrier électronique vers les serveurs de messagerie électronique en connexion point à

point.

C’est un protocole de la suite TCP/IP qui fonctionne en mode connecté et qui est d'une

utilisation assez simple.

Sendmail est l'un des premiers serveurs de messagerie électronique à utiliser SMTP. Depuis,

la plupart des clients de messagerie peuvent l'utiliser pour envoyer les messages.

Lors d'un envoi SMTP, on commence par spécifier l'expéditeur du message puis, le ou les

destinataires, puis, en général après avoir vérifié leur existence, le corps du message est

transféré. Il est possible de tester un serveur SMTP en utilisant la commande telnet sur le

port 25 d'un serveur distant.

Procédure d'un envoi SMTP :

Lors de l'ouverture de la session SMTP, la première commande à envoyer est la

commande HELO suivie d'un espace et du nom de domaine de votre machine (afin de

dire "bonjour je suis telle machine"), puis valider par entrée. Depuis avril 2001, les

spécifications du protocole SMTP imposent que la commande HELO soit remplacée par la

commande EHLO.

La seconde commande est "MAIL FROM:" suivie de l'adresse email de l'expéditeur. Si

la commande est acceptée le serveur renvoie le message "250 OK"

La commande suivante est "RCPT TO:" suivie de l'adresse email du destinataire. Si la

commande est acceptée le serveur renvoie le message "250 OK"

La commande DATA est la troisième étape de l'envoi. Elle annonce le début du corps du

message. Si la commande est acceptée le serveur renvoie un message intermédiaire

numéroté 354 indiquant que l'envoi du corps du mail peut commencer et considère

l'ensemble des lignes suivantes jusqu'à la fin du message repéré par une ligne contenant

uniquement un point. Le corps du mail contient éventuellement certains des en-têtes

suivants :

Date

Subject

Cc

Bcc

From


Exemple d'un envoi SMTP, (C) désigne le client et (S) le serveur :

(C) telnet mail.minfo.sn 25

(S) 220 mail.minfo.sn SMTP ready

(C) EHLO mail.minfo.sn

(S) 250 mail.minfo.sn

(C) MAIL FROM : <[email protected]>

(S) 250 OK

(C) RCPT TO: <[email protected]>

(S) 250 OK

(C) DATA

(S) 354 Start mail input; end with <CRLF>.<CRLF>

(C) Subject: Salut !

(C) Bonjour,

(C) Ceci est juste un test.

(C) Ciao!

(C) .

(S) 250 OK

(C) QUIT

(S) 221 mail.minfo.sn closing transmission

Il existe ainsi une syntaxe précise pour envoyer des messages et une série de codes retour

pour indiquer le statut de la demande.

Pour les codes de retour, émis par le serveur, il est possible de se repérer facilement à l’aide

du premier chiffre du code :

Code 2 : La demande a été exécutée sans erreur.

Code 3 : La demande est en cours d’exécution

Code 4 : Indique une erreur temporaire

Code 5 : La demande n’est pas valide et n’a pas pu être traitée. Vérifiez votre

syntaxe.

Voir en annexe un récapitulatif des principales commandes SMTP ainsi que les différents

codes de retour du protocole SMTP et leurs significations.

Cependant, le protocole SMTP ne permet pas la récupération de mails, d’où l’utilité des

protocoles tels que POP3 et IMAP.


2.1.2.2 Protocoles POP3 et IMAP

Les protocoles POP (Post Office Protocol) et IMAP (Internet Message Access Protocol)

permettent d'aller récupérer du courrier sur un serveur distant.

Tout comme dans le cas du protocole SMTP, le protocole POP fonctionne grâce à des

commandes textuelles envoyées au serveur POP. Chacune des commandes envoyées par le

client (validée par la touche « Entrée ») est composée d'un mot-clé, éventuellement

accompagné d'un ou plusieurs arguments et est suivie d'une réponse du serveur POP

composée d'un numéro et d'un message descriptif.

Le protocole POP3 gère ainsi l'authentification à l'aide d'un nom d'utilisateur et d'un mot de

passe, il n'est par contre pas sécurisé car les mots de passe, au même titre que les mails,

circulent en clair sur le réseau. D'autre part le protocole POP3 bloque la boîte aux lettres

lors de la consultation, ce qui signifie qu'une consultation simultanée par deux utilisateurs

d'une même boîte aux lettres est impossible.

En annexe, un tableau récapitulatif des commandes POP3.

Le protocole IMAP (Internet Message Access Protocol) est un protocole alternatif au

protocole POP3 mais beaucoup plus complet et offrant beaucoup plus de possibilités :

IMAP permet de gérer plusieurs accès simultanés.

IMAP permet de gérer plusieurs boîtes aux lettres.

IMAP permet de trier le courrier selon plus de critères.

Le protocole IMAP permet de répondre beaucoup mieux à des besoins de déplacement. Il

minimise également les échanges de données sur le réseau. La plupart des clients de

messagerie implémentent le protocole IMAP puisque celui-ci est largement utilisé par les

différents fournisseurs d'accès à Internet.

2.1.2.3 Protocole Telnet

Le protocole Telnet est un protocole standard permettant à un ordinateur de se connecter à

distance à un autre ordinateur, via l'Internet, en mode caractère uniquement. C’est un

protocole proposant l'interfaçage de terminaux et d'applications à travers Internet. Il fournit


les règles de base pour permettre de relier un client (système composé d'un affichage et

d'un clavier) à un interpréteur de commande (côté serveur). Dès que la connexion est

établie, tout se passe comme si l'utilisateur Telnet se trouvait aux commandes de

l'ordinateur distant; il peut alors utiliser le langage de commande disponible sur l'hôte

distant et lancer l'exécution de programmes qui s'exécuteront sur cet hôte.

Le protocole Telnet s'appuie sur une connexion TCP pour envoyer des données au format

ASCII entre lesquelles s'intercalent des séquences de contrôle Telnet. Il fournit ainsi un

système orienté communication, bidirectionnel. C’est un protocole de base, sur lequel

s'appuient certains autres protocoles de la suite TCP/IP (FTP, SMTP, POP3, ...). Ainsi, Telnet

permet de transférer des fichiers FTP, de lire le courrier électronique, de visionner des

documents HTML, de consulter des catalogues de bibliothèques ou de banques de données

qui rendent leur logiciel de consultation de catalogue accessible. Les spécifications de Telnet

ne mentionnent pas d'authentification car Telnet est totalement séparé des applications qui

l'utilisent (le protocole FTP par exemple définit une séquence d'authentification au-dessus

de Telnet). De ce fait, Telnet est un protocole de transfert de données non sûr, c'est-à-dire

que les données qu'il véhicule circulent en clair sur le réseau (de manière non chiffrée).

Lorsque le protocole Telnet est utilisé pour connecter un hôte distant à un serveur, c’est le

port 23 qui est utilisé.

2.2 Architecture et principe de fonctionnement

2.2.1 Architecture de fonctionnement

Les différents éléments d’un système de messagerie sont agencés selon une architecture

logique, pour en assurer le fonctionnement. L’architecture d’un système de messagerie peut

être représentée de la sorte :


Figure 1 : Architecture de fonctionnement des différents éléments du système de messagerie

Dans ce système on distingue quatre éléments fondamentaux :

Le MUA (Mail User Agent). C’est l’outil qui est directement en interaction avec

l’utilisateur dans un système de messagerie. Il peut être soit un webmail, comme

RoundCube, SquirrelMail, Gmail, Yahoo ou bien d’autres, soit un client de messagerie tel

que Mozilla Thunderbird, Outlook Express, etc. Dans le premier cas on parlera de client

de messagerie léger et pour le second, il s’agit d’un client de messagerie lourd. Le MUA

est donc un logiciel ou un service web qui fournit un environnement pour la gestion du

courrier électronique. Il offre à l’internaute les services les plus essentiels pour un

courriel tel que la saisie, l’envoi, la réception et la suppression de messages. Les plus

modernes d’entre eux intègrent encore plus de fonctionnalités et permettent même le

filtrage des messages reçus selon les besoins de l’utilisateur.

Le MTA pour Mail Transfert Agent est l’agent de messagerie qui permet d’acheminer le

courriel d’un serveur à un autre. C’est un programme doté d’une fonction de routage et


d’une fonction de transport. Lorsque par exemple [email protected] envoie un

mél à [email protected], les deux se trouvant sur deux domaines différents,

c’est le MTA du domaine minfo.sn qui se charge de la transmission du message. Pour

cela, il établit un canal de transmission avec le MTA du domaine miage.sn par

émissions successives de requêtes bidirectionnelles. Dans le cas d’un système de

messagerie interne l’émetteur et le récepteur du courriel sont dans la plupart des cas

dans un même domaine et le serveur MTA est le même pour ces deux utilisateurs. Ainsi,

pour pouvoir assurer cette fonction de transport de courriel, les MTA implémentent un

protocole sortant tel que le protocole SMTP (Voir chapitre sur protocole SMTP). Ces

protocoles sortants permettent de gérer la transmission du courrier entre les systèmes

de messagerie. Parmi les MTA les plus en vue sur internet figurent Sendmail, Postfix

utilisé dans notre cas, Exim4 et Qmail.

Le serveur de protocoles entrants encore appelé serveur IMAP/POP3 est un outil

assurant la réception et la distribution du courriel. C’est lui qui se charge d’aller

récupérer le courriel sur le MTA. Pour cela, comme pour le serveur MTA avec les

protocoles sortants, le serveur de protocoles entrants comme son nom l’indique

implémente un protocole entrant qui est la plupart du temps le POP3 (Post Office

Protocol version 3) et le protocole IMAP pour Internet Message Access Protocol. Dans un

système de messagerie, il est d’une nécessité d’avoir un serveur de protocoles entrants.

Dans notre cas, c’est Dovecot qui est configuré pour jouer ce rôle.

Le MDA (Mail Delivery Agent) est un programme qui est en charge de la gestion des

boîtes aux lettres. Il assure la livraison du courriel dans la boîte à messages du

destinataire. C’est lui qui récupère le courriel du serveur IMAP/POP3, et le met à

disposition du MUA. Pour cela, il est souvent considéré comme le point final d'un

système de messagerie. Dans le MDA, il est possible de filtrer les courriels et aussi de

supprimer les spams. Il existe plusieurs serveurs MDA et parmi les plus courants figurent

Dovecot, Procmail, Maildrop et Cyrus. Ici, nous avons choisi Dovecot, intégré dans la

version serveur de Ubuntu 10.04 LTS, comme notre MDA.


2.2.2 Principe de fonctionnement

Le fonctionnement d’un système messagerie est décomposé en au moins deux étapes

significatives et indépendantes: l’envoi et la réception. Nous allons étudier la manière dont

un est délivré un message électronique provenant de [email protected] vers

[email protected] par exemple. L’utilisateur user envoie via son Mail User Agent

(MUA), qui n’est rien d’autre qu’un logiciel de messagerie (Mozilla Thunderbird par

exemple), un message électronique en passant par le serveur mail de son domaine. Pour la

soumission du message, c’est le Simple Mail Transfert Protocole (SMTP) qui est utilisé. Le

serveur mail est appelé Mail Transfert Agent(MTA), son rôle est de relayer les mails ou de les

accepter s’ils sont destinés au domaine courant.

C’est donc ce que fait le serveur SMTP du domaine minfo.sn, il doit transmettre le

message de user vers [email protected]. Le mécanisme de fonctionnement de SMTP

est qu'il commence d'abord par vérifier l'existence de l'expéditeur et du ou des destinataire

(s), indiqués dans l'entête du message avant de transmettre le contenu.

Pour connaître l’adresse du serveur de mail du domaine ugb.sn, le MTA fait une requête

DNS de type MX sur le domaine cible.

En réponse, il obtient la liste des serveurs de messagerie de ugb.sn capables d’accepter les

mails pour le domaine. L’échange entre ces deux serveurs (les deux MTA) se fait via le

protocole SMTP. Le MTA d’ugb.sn, après réception du courriel, doit procéder à son envoi. Il

sait cependant que ce domaine est local, il ne lui reste plus qu’à délivrer son message dans la

boîte aux lettres de l’utilisateur correspondant à [email protected].

C’est alors à l’utilisateur de se connecter à sa boîte aux lettres via le protocole IMAP ou POP3

et de récupérer ses mails. Ces différents protocoles sont détaillés un peu plus en haut.


2.3 Etapes pour mettre en place un système de messagerie

2.3.1 Mise en place des services préalables

2.3.1.1 Ubuntu-Server 10.04 LTS

Un serveur peut reposer sur différents types de systèmes d’exploitation. Pour en mettre un

en place, il faut procéder à deux étapes:

Installation et configuration du système d'exploitation.

Installation et configuration du ou des applications adaptées aux services désirés.

Dans le cas d'Ubuntu, n'importe quelle variante peut donc servir de base pour mettre en

place un serveur. Cependant, ceux-ci sont très souvent configurés pour avoir une efficacité

maximale.

Ainsi, la variante serveur d'Ubuntu version 10.04, en plus d’être gratuite, possède

un noyau optimisé et est dépourvue d'environnement graphique qui est la plupart du temps

gourmand en ressources et superflu dans le cas d'un serveur amené à être manipulé assez

rarement. Cette variante est donc la plus adaptée pour la mise en place de notre serveur

pour une PME/PMI.

L’édition serveur d’Ubuntu 10.04 propose à l’installation la plupart des services dont on

pourrait avoir besoin dans un réseau d’entreprise et facilite leur configuration. Cette version

intègre Postfix et Dovecot pour le service mail et vous propose sa configuration au moment

de l’installation du système. Il intègre aussi Samba pour un serveur de fichier et

d’impression, Apache (avec des modules PHP, Perl, Python), MySQL, PostgreSQL, pour un

serveur web ainsi que Java et Ruby.

Ces quelques captures montrent les principales étapes de l’installation d’Ubuntu-Server

10.04 LTS.

Lorsqu’on boote avec un CD ou une image d’Ubuntu Server 10.04 LTS, nous avons le joli

écran ci-dessous :


Figure 2 : Menu d’installation d’Ubuntu Server 10.04 LTS

Nous allons choisir, l’option Installer Ubuntu Server. Il s’en suivra le choix de nos paramètres

régionaux puis celui de l’agencement de notre clavier. Nous allons devoir choisir notre pays,

notre langage, etc.

Après cela, le programme d’installation d’Ubuntu Server va passer à la configuration du

réseau. Cela suppose que nous avons sur notre futur serveur tous les matériels réseaux

nécessaires à sa bonne marche. Choisissons l’option Configurer vous-même le réseau. Ainsi

apparait par la suite un écran qui nous invite à choisir pour notre futur serveur une adresse

IP comme ceci :


Figure 3 : choix d’une adresse IP fixe pour le serveur

Nous mettrons ensuite le bon masque de sous-réseau. Dans notre cas, le masque choisi est

255.255.255.0. Comme passerelle, nous laissons le champ vide, et pour l’adresse du

serveur de noms, nous mettons 192.168.10.1. Cela est du fait que, le serveur sur lequel

on installe ce système d’exploitation jouera en même temps le rôle de serveur de noms (Voir

chapitre suivant pour la configuration d’un serveur DNS).

On passera, après cela, aux choix des noms de machine (ou hostname) et de domaine qui

mettront fin aux étapes de configuration du réseau. Voici les valeurs choisies dans notre cas :

Nom de machine : mail

Domaine : minfo.sn

Ceci veut dire que le serveur sera mail.minfo.sn. C’est-à-dire la machine qui s’appelle

mail dans le domaine minfo.sn.

Après ces étapes, le setup va passer à la détection des disques et autres périphériques sur

notre serveur. Ceci nous amènera par la suite au partitionnement. Cependant, nous ne nous

attarderons pas sur ce point. Dans notre présent cas, nous avons juste choisi :

Une partition / pour le système de fichiers racine.

Une autre /home de taille suffisamment grande car c’est dans ce répertoire que l’on

choisira par la suite de garder les courriels des utilisateurs du système (Voir configuration

du serveur IMAP).


Une partition /boot juste pour le démarrage du système.

Et enfin un espace d’échange « swap ».

Après le formatage des partitions et l’installation du système de base, on aura à créer un

compte d’utilisateur pour le système et à choisir son mot de passe. Arrive enfin, l’étape du

choix des services réseaux à installer en même temps que notre système d’exploitation.

Figure 4 : Sélection de services à installer en même temps que Ubuntu-Server

Ainsi comme le montre la capture précédente, nous avons juste choisi de mettre en place les

serveurs DNS, LAMP et Mail. Pour le DNS, le système va installer le programme bind, pour

LAMP on aura Apache, MySQL et PHP d’installé et enfin pour le serveur Mail, le système va

mettre Postfix en place. Faut aussi savoir que tous ces outils peuvent être installés bien

après la mise en place du système d’exploitation (Voir les chapitres suivants concernant les

installations et configurations des différents services).

L’installation de notre système d’exploitation va se poursuivre pour enfin terminer avec la

configuration de ces différents services.


Toutes ces précédentes étapes réussies, notre serveur est enfin prêt à être exploité. Nous

aurons l’écran suivant représentant le shell de première connexion. Il indique en première

ligne, la version du système d’exploitation du serveur (Ubuntu 10.04 LTS), le nom de la

machine (mail) et le terminal actif (tty1). En deuxième ligne, le système vous invite à mettre

votre login pour l’authentification système.

Figure 5 : Ecran de première connexion au serveur.

2.3.1.2 Installation et configuration d’un service DNS

Le DNS pour Domain Name System est l'ensemble des règles utilisées par les machines et les

logiciels pour établir, entre autres choses, la correspondance entre les noms de machines et

les adresses IP, dont chaque machine sur internet est pourvue. Le serveur de noms permet

d'associer une adresse IP à un nom. Dans un réseau, chaque machine se voit attribuer une

adresse IP unique qui permet de l'identifier. C'est un peu comme une adresse postale, qui


permet d'identifier une maison de façon certaine. Mais si une adresse chiffrée est plus facile

à manipuler par un ordinateur, elle est difficile à mémoriser par un humain. Ainsi, on se

souvient facilement de www.ugb.sn, mais plus difficilement de 196.1.99.13. Le serveur

de noms va permettre de trouver l'adresse IP à partir d'un nom (ou inversement), que

l'ordinateur pourra ensuite interroger. Pour résoudre un nom en adresse IP, la méthode la

plus simple consiste à mettre tous les noms d'hôtes et leurs adresses associées dans le

fichier etc/hosts. Cette méthode peut se révéler fastidieuse à la longue : chaque fois

qu'on veut insérer une nouvelle machine dans le réseau, il faut modifier le

fichier /etc/hosts de chaque machine. Le DNS a été conçu pour résoudre ce problème.

Nous allons ainsi configurer un service de résolution de noms.

D’abord, nous devons avoir ceci dans le fichier etc/resolv.conf:

# Liste des serveurs à contacter pour résoudre un nom. Il faut mieux

# mettre en premier le serveur de noms local, pour éviter de passer par

# internet pour une machine du réseau local. On peut mettre

# jusqu'à 3 adresses. Ici 192.168.10.1 qui est l’adresse ip de notre

# serveur de noms

nameserver 192.168.10.1

nameserver xxx.xxx.xxx.xxx

Dans etc/host.conf, il doit être indiqué quels services de conversion de noms sont

disponibles, et dans quel ordre il faut les appliquer :

# On indique le nom de notre domaine local.

domain minfo.sn

# Liste des domaines à chercher

search minfo.sn

# Valeurs possibles: hosts, bind.

order hosts, bind

Nous pouvons passer à la propre mise en place du DNS en lançant, avec les privilèges de

super-utilisateur, la commande suivante :


# apt-get install bind9

Ceci nous permettra d’installer bind, un outil permettant la configuration d’un serveur de

noms sous linux.

Lorsque l’installation réussit, nous aurons dans le répertoire /etc/bind/ les principaux

fichiers de configuration que nous allons adapter à notre cas. Nous allons suivre les étapes

suivantes :

Edition du fichier de configuration principal /etc/bind/named.conf. Dans ce fichier

nous allons indiquer à bind d’autres fichiers à consulter pour la résolution simple (file

"minfo.sn") et la résolution inverse (file "minfo.sn.rev") de noms. Ces fichiers

sont appelés fichiers de zone. Notre fichier named.conf devra ressembler à ceci :

[…]

include "/etc/bind/named.conf.options";

include "/etc/bind/named.conf.local";

include "/etc/bind/named.conf.default-zones";

zone "0.0.127.in-addr-arpa"{

type master;

file "named.local";

};

zone "10.168.192.in-addr.arpa"{

type master;

file "minfo.sn.rev";

};

zone "minfo.sn"{

type master;

file "minfo.sn";

};

type master pour indiquer à bind, qu’il s’agit ici d’un serveur DNS primaire ayant autorité

sur la zone déclarée.


Création des fichiers "minfo.sn" et "minfo.sn.rev". Dans le répertoire

/etc/bind/, nous irons créer ces deux fichiers. Pour cela nous ferons un vi

<nom_fichier_à_créer> à chaque fois. Voici les contenus de chacun des deux

fichiers.

minfo.sn

$TTL 604800

@ IN SOA mail.minfo.sn. root.mail.minfo.sn. (

2 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

minfo.sn. IN NS mail.minfo.sn.

mail IN A 192.168.10.1

www IN CNAME mail

minfo.sn IN MX 10 mail.minfo.sn.

minfo.sn.rev

$TTL 604800

@ IN SOA mail.minfo.sn. root.mail.minfo.sn. (

2 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

@ IN NS mail.minfo.sn.

@ IN A 192.168.10.1

1 IN PTR mail.minfo.sn.


Dans le fichier /etc/bind/named.conf.options, nous allons remplacer la ligne

directory "var/cache/bind "; par directory "/etc/bind";. Ceci pour

indiquer à bind l’emplacement des fichiers de zone.

Après ces trois étapes, nous avons un DNS fonctionnel que nous pourrons tester de cette

manière :

# nslookup //commande nslookup

> set type=any //requête du client

> minfo.sn //requête du client

Server: 192.168.10.1 //début de la réponse du serveur

Address: 192.168.10.1#53

minfo.sn

origin = mail.minfo.sn

mail addr = root.mail.minfo.sn

serial = 2

refresh = 604800

retry = 86400

expire = 2419200

minimum = 604800

minfo.sn nameserver = mail.minfo.sn //fin réponse serveur

> mail.minfo.sn

Server: 192.168.10.1

Address: 192.168.10.1#53

Name: mail.minfo.sn

Address: 192.168.10.1

> 192.168.10.1

Server: 192.168.10.1

Address: 192.168.10.1#53

1.10.168.192.in-addr.arpa name = mail.minfo.sn

>

Ce test montre que notre serveur de noms de domaines est bien configuré et qu’il peut

résoudre une adresse ip à partir d’un nom et vice-versa.


2.3.1.3 Installation et configuration d’un service web (Apache)

Nous avons vu que pour consulter ses messages et pour en envoyer, l’utilisateur avait le

choix entre utiliser un client lourd de messagerie tel que Mozilla Thunderbird, Outlook parmi

tant d’autres, ou utiliser un webmail, c’est-à-dire un client léger. Ce webmail n’est rien

d’autre qu’une sorte de site web. De ce fait, il n’est accessible que via un navigateur web tel

que Firefox de Mozilla, Internet Explorer, etc.

Ainsi, lorsque l’utilisateur, via un quelconque poste client, accède à son compte de

messagerie grâce à un navigateur, cela suppose qu’il y’a en plus du service de messagerie, un

service web disponible sur le serveur mail. Dès lors, pour que les employés d’une structure

telle qu’une PME/PMI puissent de n’importe quelle manière accéder à leurs messages

électroniques, il nous faudra installer et configurer un service web.

Pour installer un serveur web (serveur HTTP), nous allons utiliser une application bien

connue des administrateurs réseaux : Apache.

Lorsque le choix du système d’exploitation devant héberger le serveur est porté sur la

version 10.04 d’Ubuntu, l’installation d’Apache peut se faire directement lors de l’installation

du système en cochant LAMP (Voir chapitre sur Ubuntu Server 10.04 LTS). Si par contre, tel

n’est pas le cas, il nous suffira juste de lancer la commande suivante pour procéder à

l’installation d’un serveur web :

# apt-get install apache2 mysql-server php5 php5-mysql

D’autres configurations d’Apache concernant son fonctionnement avec les autres outils du

système de messagerie seront faites par la suite au niveau des sections concernées.


2.3.2 Mise en place du service de messagerie

2.3.2.1 Mise en place du MTA

2.3.2.1.1 Etude comparative de différents serveurs MTA

Pour la mise en place de notre système de messagerie nous disposons de plusieurs serveurs,

tous ayant une certaine particularité. Le choix du type serveur de mail à utiliser est encore

un sujet houleux. Un mauvais choix peut signifier une perte de temps et d’argent, diminuer

la sûreté et accroitre les risques du réseau. Un bon choix peut, dépendre de l’architecture

de votre système de messagerie, demeurer substantiellement inchangé pour des années. Le

choix d’un MTA nécessite d’abord la comparaison des caractéristiques de chacun. De ce fait

on peut analyser certaines caractéristiques comme :

Une bonne sécurité

Habilité à manipuler pour une grande quantité de messages

Interaction avec les bases de données sur plusieurs formats.

Pouvoir de dialoguer avec beaucoup de variantes SMTP utilisées

Qualité de la tierce documentation utilisable.

Parmi les plus utilisés nous avons :

Sendmail :

Sendmail est le doyen de tous les serveurs de messagerie. Son code est ouvert et fut à une

époque la plus répandu sur les réseaux grâce à ses bonnes performances et une grande

publicité par les universités. Sendmail est un programme très flexible supportant un large

éventail de moyens de transfert et de livraison de courriers électroniques, incluant le

populaire SMTP. La première version de Sendmail a été écrite au début des années 1980 par

Eric Allman (Université de Berkeley), qui avait également écrit Deliver Mail.


Sendmail est très critiqué pour sa lenteur, sa complexité et sa maintenance difficile en

comparaison avec d'autres Mail Transfert Agent (MTA) tels que Qmail et Postfix Toutefois, il

reste le MTA le plus populaire sur Internet, ce qui est certainement dû à sa mise en œuvre

par défaut dans les différentes variantes d'Unix – à titre d'exemple, Sendmail a été présent

dans Mac OS X avec les versions 10.0 à 10.3.

Qmail :

Qmail est un serveur de messagerie électronique pour Linux et autres dérivés d'Unix, créé

par le cryptologue Daniel J. Bernstein. A la différence de Sendmail, Qmail n’est pas

monolithique. Le système Qmail se compose de plusieurs programmes tournant sous des

UID/GID différents et non nuls rendant difficile toute tentative d’intrusion. Qmail présente

un haut niveau de sécurité grâce à sa structure « éclatée » et de très bonnes performances

grâce à une gestion de queue très rapide. Sa configuration très simple via un ensemble de

fichiers de contrôle et de variables d'environnement, domaines virtuels. Qmail de par sa

taille et son architecture, pas de vulnérabilité depuis quelques années, et une architecture

vraiment sécurisée pour éviter même en cas de problèmes, la perte de messages ou encore

même corruption de messages en cas crash système.

Postfix :

Postfix est un serveur de messagerie électronique développé par le célèbre spécialiste en

sécurité Wietse Venema et a tout axe sur l’écriture d’un remplaçant et sécurisé de Sendmail.

Il a été conçu comme une alternative plus rapide, et plus facile à administrer et plus

sécurisée. Il est le serveur de courriel par défaut dans plusieurs systèmes de type UNIX,

comme Mac OS X, NetBSD, diverses distributions GNU/Linux. Postfix permet de gérer

presque tous les cas d'une utilisation professionnelle. Utilisé avec une liste publique anti-

spam, il permet d'éviter bon nombre de spams sans même devoir scanner les contenus de

message. Objectif réussi puisque Postfix est devenu l’une des références grâce à la qualité du

programme et son architecture modulaire. Enfin il dispose de nombreuses fonctionnalités et

également d’une syntaxe « humaine ». De plus il est un peu gourmand en ressource

système.


Exim :

Exim est un serveur de messagerie électronique utilisé sur de nombreux systèmes de type

UNIX. La première version a été écrite en 1995 par Philip Hazel pour le service informatique

de l'Université de Cambridge: le nom était alors l’acronyme de EXperimental Internet Mailer

(gestionnaire de mail internet expérimental). Basé au départ sur Sendmail, il a largement

évolué pour devenir l'un des MTA les plus flexibles et robustes.

Exim4 a été développé autour d’une architecture monolithique (c’est-à-dire qu’il n’y a qu’un

seul gros programme qui tourne plutôt que plusieurs petits programmes avec des privilèges

différents), son auteur Philip Hazel avait pourtant essayé de le rendre modulaire de la même

façon que Postfix mais cette séparation entrainait une forte duplication de codes pour gérer

toutes les fonctionnalités disponibles. Il faut tout de même relativiser : l’architecture

monolithique du programme ne facilite pas une approche sécuritaire mais le logiciel est

l’œuvre d’une seule personne en grande partie, le code est donc cohérent et tous les points

critiques sont connus de son auteur. Même si la sécurité n’est pas aussi forte que sous

Postfix, son auteur s’est attaché à ne pas reproduire le passé de Sendmail. Dernier point et

non des moindres, Exim est le seul MTA à être sous licence GPL, contrairement à Qmail.

2.3.2.1.2 Installation et configuration de Postfix

Postfix est l’agent de transfert courrier (MTA) par défaut d’Ubuntu. Il est dans les dépôts

main, donc il reçoit les mises à jour de sécurité. Cette partie décrit son installation et sa

configuration pour en faire un serveur SMTP.

L’installation du serveur SMTP proprement dite est très simple. Il suffit d’installer le paquet

Postfix, si ce n’est déjà fait lors de l’installation du système d’exploitation, avec la

commande :

# apt-get install postfix

Cette ligne permettra d’installer postfix comme serveur mail, à nous de le configurer en

faisant :


# dpkg-reconfigure postfix

Viendra un écran (capture ci-contre) où on aura à fournir le type de configuration. Dans ce

cas, on choisira l’option "Site Internet" :

Figure 6 : Première étape de la configuration de Postfix

Viendra après le choix du nom du serveur. Nous mettrons simplement le nom de domaine

principal de notre serveur à savoir minfo.sn. Ensuite, pour que des courriels à destination de

« root » et de « postmaster » soient redirigés vers le compte utilisateur de l’administrateur

système, nous mettrons /etc/aliases pour le choix suivant, puis on indiquera la liste des

domaines, séparés par des virgules, que notre serveur reconnaitra comme lui appartenant.

Dans notre cas on pourra choisir :

minfo.sn, mail.minfo.sn, localhost

Nous allons après cette étape indiquer les réseaux pour lesquels notre serveur pourra

relayer le courriel. On aura comme information dans ce champ les adresses 127.0.0.0/8

et 192.168.10.0/24 séparées par un espace. Postfix va par la suite nous demander si

nous voulons choisir Procmail pour la distribution locale. Nous choisissons de refuser (No)

car nous mettrons par la suite notre propre agent de distribution à savoir Dovecot (Voir

chapitres sur Dovecot).


Les autres options qui suivent peuvent être laissées par défaut. Elles indiquent

successivement la taille maximale des boites aux lettres à choisir (celle-ci sera illimitée c’est-

à-dire laissée à 0), le caractère d’extension des adresses locales (+) et les versions d’ip à

utiliser (nous choisirons l’option tous).

Après toutes ces modifications nous avons un serveur mail bien configuré avec Postfix.

Voici une liste de tous les choix faits lors de l’installation du serveur mail :

Site internet

minfo.sn

/etc/aliases

minfo.sn, mail.minfo.sn, localhost.minfo.sn, localhost

127.0.0.0/8 192.168.10.0/24

No

0

+

tous

2.3.2.2 Mise en place du MUA

2.3.2.2.1 Etude comparative de différents MUA

Les courriels ne sont autres que des fichiers envoyés de serveurs à serveurs, un peu comme

si une lettre ou un colis était envoyé du bureau de Poste de chez vous au bureau de Poste du

destinataire. Par ailleurs, il existe ce que l’on appelle des clients mail, qui permettent de

traiter ce courrier. Ces clients peuvent être en ligne, c’est à dire que vous y accédez via un

site web (Hotmail et Gmail sont typiquement des clients mail en ligne) ou client léger, ou

bien, il existe également des applications que vous installez sur votre ordinateur, et qui vont

régulièrement synchroniser votre espace de stockage de mails sur votre ordinateur avec le

contenu du serveur de mail que vous utilisez. Là, on sera davantage dans des logiciels type

Mozilla Thunderbird ou Microsoft Outlook.


Client léger

Un client léger est une application cliente entièrement gérée par un serveur, de la gestion au

stockage des données. Les utilisateurs de l’application auront accès aux données par un

portail sécurisé depuis leur navigateur (Internet Explorer, Firefox…).

Pour les systèmes en client léger, l’installation est beaucoup plus simple. On a tendance à

penser que les applications Web sont moins sécurisées. Pourtant elles permettent de

réduire les risques à un seul serveur. Bien entendu, la sécurisation de celui-ci est

primordiale, surtout lors d’un partage de l’application sur Internet.

On peut distinguer quelques types de client léger :

SquirrelMail :

SquirrelMail est une application qui permet de consulter son courrier électronique, stocké

sur un serveur, grâce à un simple navigateur. SquirrelMail est écrit en PHP. Les fonctions de

base peuvent être étendues par des plugins.

RoundCube Webmail:

RoundCube est le projet le plus récent et dont l’objectif est de réaliser un Webmail utilisant

les technologies XHTML et CSS 2 pour offrir à l’utilisateur une ergonomie la plus proche

possible de celle d’un logiciel de messagerie classique installé sur son PC.

L’installation est simple et nécessite une base de données MySQL ou PostgreSQL. La

connexion à un annuaire LDAP est également possible. A l’usage RoundCube se révèle très

agréable, simple et complet.

Zimbra

Zimbra est un logiciel serveur collaboratif qui permet à ses utilisateurs de stocker, organiser

et partager rendez-vous, contacts, courriels, liens, documents et plus. Il logiciel développé

sur un mode "Web service" : Son interface entièrement en AJAX est chargée à la première

connexion, puis les interactions et ajouts/modifications d'informations sont envoyés au


serveur par le protocole SOAP. Zimbra propose aussi un logiciel client utilisable en mode

déconnecté : le Yahoo! Zimbra Desktop.

Client lourd

Le terme « client lourd », par opposition au client léger, désigne une application cliente

graphique exécutée sur le système d'exploitation de l'utilisateur. Un client lourd possède

généralement des capacités de traitement évoluées et peut posséder une interface

graphique sophistiquée. Néanmoins, ceci demande un effort de développement et tend à

mêler la logique de présentation (l'interface graphique) avec la logique applicative (les

traitements).

La mise en place d’un système de type client lourd nécessitera une installation de

l’application sur chaque poste. Il faudra donc prévoir des ressources à l’arrivée de chaque

nouveau collaborateur pour l’installation du logiciel sur le nouveau poste de travail.

Les applications du type client lourd sont généralement plus sécurisées si elles ne

concernent que quelques utilisateurs. Il faut cependant que tous les postes qui utilisent

l’application soient sécurisés car une partie des données est stockée sur les postes des

différents collaborateurs. Cela peut donc multiplier les risques.

2.3.2.2.2 Installation et configuration de RoundCube Webmail

Pour permettre l’accès aux boites IMAP depuis n’ importe où, l’installation d’un Webmail

s’impose. De nombreux webmails Open Source sont disponibles mais celui qui sort du lot en

ce moment, c’est RoundCube. Il est encore très jeune mais offre de gros atouts coté

ergonomie, notamment grâce à l’utilisation d’AJAX. L’interface est très soignée, claire et

simple. Techniquement, ça reste très classique, c’est du PHP et ça s’installe très facilement.

Parmi ses fonctionnalités, on peut noter l’utilisation possible (grâce à AJAX) du glisser-

déposer, le multilinguisme, un carnet d’adresse, le blocage automatique des images

distantes, la recherche automatique en cours de frappe dans le carnet d’adresse lors de

l’ajout de destinataire, l’utilisation de comptes multiples pour l’envoi de messages, le

support MIME, la création de dossier ainsi que la sélection des dossiers affichés.


Installation de RoundCube :

Pour que RoundCube fonctionne correctement, il faut bien entendu que la machine héberge

un serveur Apache et un serveur MySQL fonctionnels. La configuration du serveur web est

décrite ci-dessous.

Tout d’abord télécharger RoundCube (version complète) sur le site www.roundcube.net et

l’extraire dans un répertoire.

# tar xzf roundcubemail-0.3.1.tar.gz

Il est plus pratique de le renommer après l’avoir copié dans la racine web:

# cp roundcubemail-0.3.1 /var/www

# mv /var/www/roundcubemail-0.3.1 /var/www/webmail

Ensuite, il faut donner les droits au serveur d’écrire dans les répertoires temp/ et logs/ :

# chmod -R 777 /var/webmail/temp/ var/webmail/logs

Préparation de la base de données de RoundCube

Il faut créer une base de données qui sera utilisée par RoundCube, avec son propre

utilisateur. Pour cela, démarrons MySQL en tant qu’administrateur (le login et le mot de

passe ont été choisis lors de la configuration de MySQL) :

# mysql –u root –p<mon_mot_de_passe>

Ensuite, nous créerons une base de données en faisant:

mysql> CREATE DATABASE webmail;

Query OK, 1 row affected (0.00 sec)

On accorde à l’utilisateur user toutes les privilèges sur toutes les tables de la base de

données webmail:


mysql> GRANT ALL PRIVILEGES ON webmail.* TO user@localhost IDENTIFIED BY

'mon_mot_de_passe';

Query OK, 0 rows affected (0.01 sec)

Maintenant notre base de données est prête à accueillir RoundCube.

Configuration d’Apache pour RoundCube:

La base de données configurée, il nous faut créer un VirtualHost qui décrit à Apache le site

qu’il doit héberger, c'est-à-dire le nom du site sur lequel il répond en http, et les répertoires

qui doivent être accessibles, etc.

Notre VirtualHost permettra :

d’afficher le site contenu dans /var/www/webmail lorsqu’une requête arrive sur le

port 443 (http), c’est-à-dire quand je tape http://mail.minfo.sn dans un

navigateur ;

d’interdire l’accès aux répertoires config, temp et logs.

NameVirtualHost *:443

<VirtualHost *:80>

ServerName mail.minfo.sn

</VirtualHost>

<VirtualHost *:443>

DocumentRoot /var/www/webmail

ServerName mail.minfo.sn

<Directory /var/www/webmail/>

Options FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

</Directory>

<Directory /var/www/webmail/config>


Options -FollowSymLinks

AllowOverride None

</Directory>

<Directory /var/www/webmail/temp>


AllowOverride None

</Directory>

<Directory /var/www/webmail/logs>


AllowOverride None

Order allow,deny

Deny from all

</Directory>

ErrorLog /var/log/apache2/webmail_error.log

CustomLog /var/log/apache2/webmail_access.log combined

</VirtualHost>

Ce fichier est à écrire dans /etc/apache2/sites-available/ dans un fichier nommé

comme notre site par exemple, webmail.

Il faut ensuite l’activer :

# a2ensite webmail

Et recharger Apache :

# /etc/init.d/apache2 reload

Configuration de RoundCube :

Il ne reste plus qu’à configurer RoundCube. Une interface assez explicite a été développée

dans RoundCube pour cela. Grâce à un navigateur nous allons rentrer l’URL suivant

http://mail.minfo.sn/installer/ après avoir fait de telle sorte que l’on puisse se

connecter sur le serveur. Les différentes étapes de la configuration sont décrites ici :


L’étape 1 (Check environment) :

Celui-ci devrait bien se passer à part quelques modules optionnels dont on n’aura pas besoin

ici. Nous avons la capture ci-contre :

Figure 7 : Interface de configuration de RoundCube (RoundCube Installer).

Pour l’étape 2 (create config) :

Renseignons le champ product_name correspondant au titre des pages

souhaité ;


Activons ip_check;

Désactivons enable_spellcheck (sinon tous nos mails seront envoyés à

Google) ;

Renseigner les données pour l’accès à la base de données (que nous avons créée

tout à l’heure) ;

Dans la partie IMAP, renseigner uniquement le champ default_host par la

valeur localhost;

Laissez par défaut le reste de la partie IMAP et la partie SMTP (vu que les mails

sont sur la même machine).

Lors de la validation, deux fichiers seront générés. Il faut les télécharger et les placer dans le

répertoire /var/www/webmail/config/. Il s’agit des principaux fichiers de

configuration de RoundCube db.inc.php et main.inc.php.

L’étape 3 (Test config)

Il permet de tester que tout est OK. Il nous faudra cliquer sur Initialise Database.

Une fois ces étapes effectuées, rendons-nous sur l’adresse du webmail pour vérifier que ça

fonctionne. Nous pouvons dès lors nous connecter en tant qu’utilisateur du système de

messagerie. Si tout est ok, supprimez ou renommer le répertoire /var/www/installer/

pour qu’il ne soit plus accessible via l’extérieur:

Voilà deux captures montrant respectivement l’interface de connexion et la boîte aux lettres

d’un utilisateur :


Figure 8 : Interface de connexion de RoundCube Webmail

Figure 9 : Boite aux lettres d’un utilisateur


2.3.2.3 Mise en place de Dovecot comme MDA et serveur IMAP

Comme vu un peu plus haut dans ce document, la mise en place d’un MDA est plus que

nécessaire dans un système de messagerie. En effet, c’est un outil situé sur le serveur de

messagerie et qui a en charge la livraison des messages dans la bonne boîte aux lettres. En

plus du MDA, un serveur IMAP/POP3, aussi appelé serveur de protocoles entrants est à

mettre en place. Son rôle à lui sera d’aller récupérer le message situé dans la boite aux

lettres suite à la quête de celui-ci. Dovecot est un outil qui de par son efficacité pourra jouer

ces deux rôles. Ainsi, c’est lui que nous avons choisi d’utiliser pour ces différentes tâches.

Dès lors, nous allons comparer différents MDA existants avant de passer à la configuration

de notre outil.

2.3.2.3.1 Étude comparative de différents MDA

Il existe différents MDA dans le monde des serveurs. Parmi ceux-là, on peut citer Dovecot,

Procmail, Maildrop, Deliver, Mailfilter et Cyrus. Chacun d’entre eux présente des avantages

et des inconvénients. Des MDA sont aussi intégrés aux grands logiciels de messagerie

intégrés (Exim par exemple). Ils assurent la gestion de boite à lettres, le filtrage des

messages , l’envoi de message de réponse automatique.

2.3.2.3.2 Installation et configuration de Dovecot

Nous allons dans cette partie procéder à l’installation et à la configuration de Dovecot. Pour

installer Dovecot, nous avons à lancer la commande suivante :

# aptitude install dovecot-imapd dovecot-pop3d

Ainsi tous les modules nécessaires au bon fonctionnement de Dovecot seront installés. Il

suffira par la suite simplement redémarrer le service en faisant :

# etc/init.d/dovecot restart


Grâce à ces quelques commandes, nous venons d’installer les serveurs IMAP et POP3 (car

Dovecot les intègre tous les deux).

Nous pouvons passer à son test en faisant un telnet sur le port 143 (port correspondant à

une communication utilisant le protocole IMAP) et un autre sur le port 110 (port

correspondant à une communication utilisant le protocole POP3). Nous les avons ci-contre :

# telnet mail.minfo.sn 143

Trying 192.168.10.1 …

Connected to mail.minfo.sn.

Escape character is ‘^]‘.

* OK Dovecot Ready.

# telnet mail.minfo.sn 110

Trying 192.168.10.1 …

Connected to mail.minfo.sn.

Escape character is ‘^]‘.

+ OK Dovecot Ready.

Il est aussi possible de mettre imap à la place de 143 ou pop3 à la place de 110. Ceci montre

que notre serveur imap et pop3 est maintenant fonctionnel.

Toute la configuration de notre outil se fait cependant dans un fichier d’environ 1280 lignes :

/etc/dovecot/dovecot.conf. Juste les paramètres par défaut suffiront à faire

fonctionner Dovecot. Sauf que pour des besoins de sécurité et de filtrage, il nous faudra

parcourir ce fichier et l’adapter à nos besoins. Cette configuration sera expliquée dans les

différentes sections concernées.


Partie 3: Sécuriser le système de

messagerie

La sécurité du serveur de mails se situe à plusieurs niveaux. Elle réside sur la sécurisation des

communications, l’authentification des utilisateurs et l’intégrité des données.

Les communications sont généralement sécurisées en utilisant un chiffrage avec OpenSSL,

l’authentification est assurée à l’aide de SASL et les données sont analysées par un antivirus

et un anti-spam.

Ainsi, pour apporter de la sécurité en matière de courrier électronique, on peut agir sur deux

éléments : les MTA et les MUA ou autrement dit coté serveur et coté client. Il est d’abord

primordial de ne plus transmettre de mots de passe en clair ensuite on pourra se concentrer

sur la validité des données.

3.1 Authentification SMTP avec SASL

3.1.1 Principes et objectifs de SASL

SASL pour Simple Authentication and Security Layer est une méthode qui offre un support

d’authentification à des protocoles orientés connexion. SASL inclut des commandes pour

identifier et authentifier un utilisateur sur un serveur et pour éventuellement négocier la

protection des interactions du protocole. Si son utilisation aboutit, une couche de sécurité

est insérée entre le protocole et la connexion.

Si l’on utilise Dovecot comme serveur IMAP, il est maintenant possible d’utiliser son démon

d’authentification pour réaliser l’authentification SMTP via SASL. Nous allons passer à la

configuration des serveurs SMTP et IMAP/POP3 dans la section qui suit.


3.1.2 Configurer Postfix et Dovecot pour SASL

La première étape dans la configuration de SASL est l’édition des fichiers

/etc/postfix/main.cf et de /etc/postfix/master.cf.

A travers ces fichiers nous indiquerons à Postfix qu’il faut utiliser l’authentification SMTP

pour tous les utilisateurs qui désirent envoyer un mail, sauf s’ils font partie de mynetworks.

Avec la configuration suivante, on interdit également les connexions anonymes :

# Active l’authentification SASL dans le serveur SMTP de Postfix

smtpd_sasl_auth_enable = yes

#Type de plug-in SASL que le serveur SMTP doit utiliser pour

l’authentification

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

# Active l’interopérabilité avec des clients de Microsoft qui implémentent

AUTH de manière obsolète

broken_sasl_auth_clients = yes

# Interdit les méthodes qui autorisent l'authentification anonyme

smtpd_sasl_security_options = noanonymous

# Par défaut cette valeur est vide

smtpd_sasl_local_domain =

Nous allons maintenant modifier le fichier /etc/postfix/master.cf en éditant l’option

smtpd_sasl_auth_enable pour activer l’authentification avec SASL pour Postfix :

smtps inet n - - - - smtpd

-o smtpd_tls_wrappermode =yes

-o smtpd_sasl_auth_enable =yes

Après cela, il nous reste à configurer Dovecot pour qu’il réponde aux requêtes

d’authentification de Postfix. Ceci se fait dans le ficher /etc/dovecot/dovecot.conf, il

suffit de rajouter les lignes suivantes dans la section socket listen :


auth default {

[...]

socket listen {

[...]

# Client for postfix SASL

client {

path = /var/spool/postfix/private/auth

mode = 0660

user = postfix

group = postfix

}

}

[...]

}

Bien entendu, pour que les modifications soient prises en compte, il faut redémarrer les

services avec les commandes suivantes :

# /etc/init.d/dovecot restart

# /etc/init.d/postfix restart

Il est maintenant possible de tester l’authentification en faisant une connexion SMTP en

telnet. Il faut préalablement préparer la chaîne d’authentification encodé en base64. Pour

cela nous utiliserons mimencode qui est une part des programmes metamail. Nous aurons

les commandes suivantes:

# aptitude install metamail

# printf "\0user\0minfo" | mimencode

AHVzZXIAbWluZm8=

La syntaxe est printf "\0<nom_utilisateur>\0<mot_de_passe>" et c’est cette

chaîne générée qui sera utilisée avec la commande SMTP AUTH PLAIN pour envoyer le


couple login/password au serveur. On peut maintenant commencer la session telnet comme

indiquée ci-dessous:

(C) # telnet mail.minfo.sn 25

(S) 220 mail.minfo.sn ESMTP Postfix (Ubuntu)

(C) EHLO mail.minfo.sn

(S) 250- mail.minfo.org

(S) 250- PIPELINING

(S) 250- SIZE 10240000

(S) 250- VRFY

(S) 250- ETRN

(S) 250- STARTTLS

(S) 250- AUTH PLAIN

(S) 250- AUTH=PLAIN

(S) 250- ENHANCEDSTATUSCODES

(S) 250 -8 BITMIME

(S) 250 DSN

(C) AUTH PLAIN AHVzZXIAbWluZm8=

(S) 235 2.0.0 Authentication successful

(C) quit

(S) 221 2.0.0 Bye

(C) correspond à une requête du client et (S) à une réponse du serveur.

La session ci-dessus présente une authentification réussie sur le serveur mail.minfo.sn

avec le couple login/mot_de_passe <user/minfo> pour l’authentification. On remarque

dans cette session que le mot de passe est encodé en base64, il n’est donc pas lisible

directement, il est par contre déchiffrable (avec mimencode -u). Cette méthode n’offre

donc aucune sécurité et il est ainsi de voir le mot de passe d’une personne en analysant les

trames réseaux. La solution la plus répandue pour contourner ce problème est de chiffrer

toutes les communications avec SSL, c’est l’objet du paragraphe suivant.


3.2 Sécurisation des communications

3.2.1 Protection contre l’Open-Relay et le spam

On parle d’Open-Relay lorsqu’on est en face d’un serveur SMTP qui autorise tous les

messages électroniques entrants à transiter par lui pour atteindre d’autres domaines. Il

s’agit d’un mécanisme qui consiste à accepter de transmettre un message à un destinataire

quelconque. C’est le comportement par défaut de plusieurs serveurs SMTP. Cependant

plusieurs spammeurs ont par la suite commencé à abuser de cette fonctionnalité pour

causer des dégâts ; ce qui a poussé les administrateurs réseaux et systèmes à contrôler les

flux entrants et à empêcher le relais pour leurs serveurs afin de ne pas se retrouver

« blacklisté ».

Ainsi pour augmenter la sécurité de notre serveur de mail, il est important de contrôler les

échanges avec les serveurs SMTP ouverts (Open Relay). Ces serveurs sont utilisés pour

envoyer des messages électroniques non sollicités, connus sous le nom de spam. Pour cela, il

existe des listes d’adresses IP correspondant aux machines qui fonctionnent comme des

serveurs SMTP ouverts. On peut donc demander à Postfix de consulter ces listes avant

d’accepter un message entrant. Ceci est réalisé grâce à la directive

smtpd_client_restrictions dans le fichier /etc/postfix/main.cf. Enfin pour

éviter que notre serveur devienne lui-même ouvert, il faut limiter les accès de façon très

stricte. Par exemple, on peut rejeter le mail si les en-têtes sont incomplètes, si le message

est mal formé, etc. Par contre, mes messages provenant des réseaux connus

(my_networks) ou des personnes authentifiées (sasl_authenticated) seront toujours

acceptés.

Nous devons modifier notre fichier /etc/main.cf de façon à avoir les lignes suivantes :

# Attend la commande RCPT TO avant d’évaluer les restrictions

smtpd_delay_reject = yes

# Impose au client SMTP de démarrer la session SMTP par une commande HELO

# ou EHLO

smtpd_helo_required = yes


# Requiert que les adresses reçues avec les commandes SMTP "MAIL FROM" et

# "RCPT TO" soient

# encadrées par <>. Ceci stoppe le courrier des logiciels mal écrits.

strict_rfc821_envelopes = yes

# Restrictions d'accès du serveur pour les requêtes de connexion au

# service SMTP

smtpd_client_restrictions =

permit_mynetworks ,

permit_sasl_authenticated ,

reject_rbl_client bl.spamcop.net ,

reject_rbl_client dnsbl.njabl.org ,

reject_rbl_client cbl.abuseat.org ,

reject_rbl_client sbl -xbl.spamhaus.org ,

reject_rbl_client list.dsbl.org ,

permit

# Restrictions que le serveur SMTP de Postfix applique dans le contexte de

# la commande HELO.

smtpd_helo_restrictions =

permit_mynetworks ,


reject_non_fqdn_hostname,

reject_invalid_hostname,

permit

# Restrictions que le serveur SMTP de Postfix applique dans le contexte

# des commandes MAIL FROM

smtpd_sender_restrictions =

permit_mynetworks ,


reject_non_fqdn_sender ,

reject_unknown_sender_domain ,

permit

# Restrictions que le serveur SMTP de Postfix applique dans le contexte

# d'une commande RCPT TO

smtpd_recipient_restrictions =

permit_mynetworks,

permit_sasl_authenticated,


reject_non_fqdn_recipient,

reject_unknown_recipient_domain,

reject_unauth_destination,

permit

Notons que ce type de règles permet de diminuer sensiblement la charge de la machine

dans le sens ou le mail est rejeté avant d’être analysé par les outils de filtrage de contenu

(Amavis, ...) qui sont souvent très consommateurs de ressources. On pourra également

observer un léger gain de bande passante puisque seuls les en-têtes des messages

indésirables seront échangés sur le réseau, en aucun cas les corps de message ou les pièces

jointes.

La configuration ci-dessus autorise toujours le relais pour les personnes authentifiées grâce à

la directive permit_sasl_authenticated.

3.2.2 Les certificats SSL

Comme nous l’avons vu plus haut, les services de messagerie (SMTP et IMAP) demandent

une authentification de la part des utilisateurs. Dans ce cas, ce dernier va fournir un couple

login/mot de passe qui devra transiter sur le réseau entre le client et le serveur. Pour que

ces identifiants ne circulent pas en clair, la plupart des services offrent la possibilité de

chiffrer les échanges à l’aide d’OpenSSL.

Pour cela, chaque service doit disposer d’un certificat SSL qui permettra de s’assurer de son

authenticité et de chiffrer/déchiffrer les communications.

Le fichier de configuration ci-dessous permettra de générer le certificat du serveur SMTPS.

On peut par exemple l’enregistrer dans /etc/ssl/smtpd.cnf.

[ req ]

default_bits = 2048

default_keyfile = privkey.pem

distinguished_name = req_distinguished_name

prompt = no

string_mask = nombstr


x509_extensions = server_cert

[ req_distinguished_name ]

countryName = SN

stateOrProvinceName = Senegal

organizationName = MINFO

organizationalUnitName = SMTP Server

commonName = mail.minfo.sn

emailAddress = [email protected]

[ server_cert ]

basicConstraints = critical, CA:FALSE

subjectKeyIdentifier = hash

keyUsage = digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth, clientAuth

nsCertType = server

nsComment = "SMTP Server"

Nous allons ensuite générer le certificat et restreindre les privilèges sur la clé privée. Il nous

suffira de lancer les commandes suivantes :

# openssl req -x509 -new \

-config /etc/ssl/smtpd.cnf \

-out /etc/ssl/certs/smtpd.pem \

-keyout /etc/ssl/private/smtpd.key \

-days 730 -nodes -batch

# chmod 600 /etc/ssl/private/smtpd.key

Lors de la configuration du certificat, le champ "commonName" est très important. Il doit

toujours correspondre au FQDN (Fully Qualified Domain Name ; mail.minfo.sn dans notre

cas) qui sera utilisé pour accéder au service. Dans le cas contraire, la plupart des clients vont

générer une alerte à chaque négociation TLS avec le serveur.

Nous avons terminé la génération du certificat du serveur SMTP, nous devons faire la même

chose pour le serveur IMAP. Cependant, la génération du certificat pour ce dernier est tout à

fait similaire, il suffit de modifier légèrement le fichier de configuration en remplaçant


smtp" par "imap" et de le renommer par /etc/ssl/imapd.cnf. On appliquera ces

mêmes modifications sur la commande de génération vue précédemment.

3.2.3 Chiffrement des communications IMAP et SMTP avec OpenSSL

Dovecot offre la possibilité de sécuriser les communications IMAP et SMTP avec OpenSSL :

IMAPS et SMTPS. Il est souvent préférable de n’utiliser que cette déclinaison du protocole

afin qu’aucun mot de passe ne passe en clair sur le réseau.

Pour activer le support de l’IMAPS dans Dovecot, il faut dans un premier temps disposer

d’un certificat pour ce service, ce qui a été fait dans le paragraphe précédent. Il suffit ensuite

d’éditer le fichier /etc/dovecot/dovecot.conf pour modifier les paramètres suivants :

protocols = imaps

ssl_cert_file = /etc/ssl/certs/imapd.pem

ssl_key_file = /etc/ssl/private/imapd.key

Notons que le paramètre protocols ne devra contenir que la valeur imaps, les autres

protocoles de relève de courrier étant bannis. Avec cette configuration, les clients peuvent

maintenant se connecter au serveur IMAP uniquement sur le port 993 et toutes les

communications seront chiffrées.

Il reste simplement à redémarrer le serveur avant de faire un premier test en ligne de

commande:


# openssl s_client -connect mail.minfo.sn:993

---

* OK Dovecot ready.

. login user minfo

. OK Logged in.

. logout

* BYE Logging out

. Logout completed.


Pour le cas de SMTPS, la configuration d’OpenSSL se fera dans ses principaux fichiers de

configuration. Il nous suffira d’abord de modifier les lignes suivantes dans

/etc/postfix/main.cf:

smtpd_tls_security_level = may

smtpd_tls_loglevel = 1

smtpd_tls_cert_file = /etc/ssl/certs/smtpd.pem

smtpd_tls_key_file = /etc/ssl/private/smtpd.key

puis enlever le commentaire affecté à ces trois lignes dans le fichier /etc/postfix/master.cf

smtps inet n - - - - smtpd

-o smtpd_tls_wrappermode = yes

-o smtpd_sasl_auth_enable = yes

Nous pourrons redémarrer avec un :

# etc/init.d/postfix restart

avant de vérifier le fonctionnement de SMTPS comme le montre le test ci-contre :

# openssl s_client -connect mail.minfo.sn:465

[...]

---

220 mail.minfo.sn ESMTP Postfix (Ubuntu)

EHLO minfo.sn

250 mail.minfo.sn

MAIL FROM: <[email protected]>

250 2.1.0 Ok

RCPT TO: <[email protected]>

250 2.1.5 Ok

DATA

354 End data with <CR ><LF >.<CR ><LF >


Hello !!

.

250 2.0.0 Ok: queued as 8EF8730102C3

quit

221 2.0.0 Bye

3.2.4 Configuration d’un firewall

Le but d’un firewall est d’empêcher que des programmes puissent communiquer sur le

réseau sans votre accord.

Les iptables représentent le plus célèbre firewall utilisé sous Linux. Il permet d’établir un

certain nombre de règles pour dire par quels ports on peut se connecter à votre ordinateur,

mais aussi à quels ports vous avez le droit de vous connecter. On peut aussi filtrer par IP

mais nous ne détaillerons pas cela ici.

Par exemple, si nous voulons empêcher toute connexion FTP, nous pouvons souhaiter

bloquer le port 21 (utilisé par FTP). Nous utiliserons les iptables pour mettre en place notre

firewall.

En général, la technique d’un pare feu ne consiste pas à bloquer certains ports, mais plutôt à

bloquer par défaut tous les ports et à en autoriser seulement quelques-uns.

Pour bloquer tous les ports :

# iptables -P INPUT DROP

# iptables -P OUTPUT DROP

# iptables -P FORWARD DROP

Ainsi notre serveur refusera tout trafic entrant (INPUT DROP), sortant (OUTPUT DROP) ou

qui doit juste passer par lui (FORWARD DROP).

Nous allons ensuite autoriser le trafic sur l’interface de loopback locale. Ceci car le serveur a

quelquefois besoin de communiquer avec lui-même. Dans la configuration retenue ici, il faut

ouvrir uniquement les ports suivant en entrée :


25 (SMTP) : pour que le serveur puissent recevoir les mails provenant des autres

serveurs de mails.

465 (SMTPS) : pour que les utilisateurs authentifiés puissent envoyer des mails en

mode crypté (SSL).

993 (IMAPS) : pour que les utilisateurs authentifiés puissent recevoir des mails en

mode crypté (SSL) en utilisant IMAP.

2000 (MANAGESIEVE) : pour que les utilisateurs authentifiés puissent éditer les règles

de filtrage.

Pour réaliser cela, nous exécuterons les commandes suivantes:

# iptables -A INPUT -i lo --source 127.0.0.1 --destination 127.0.0.1

-j ACCEPT

# iptables -A INPUT --dport 25 -j ACCEPT




Cela fait, nous allons autoriser les requêtes de type ICMP, ne serait-ce que pour pouvoir

s’assurer que notre serveur est toujours en vie, grâce à cette commande :

# iptables –A INPUT –p icmp –j ACCEPT

Ainsi, nous venons de configurer notre pare feu avant d’éviter toute intrusion indésirable

dans notre système. Ceci grâce aux iptables. Il existe en guise d’information, depuis la

version 8.04 LTS d’Ubuntu, un autre outil, aux commandes assez simples, très puissant et qui

permet de configurer un pare feu, constituant ainsi une alternative aux iptables : il

s’agit de UFW (Uncomplicated FireWall).

Cependant, avoir un firewall ne prémunit pas contre les dangers. En revanche, cela rend la

tâche particulièrement difficile aux pirates qui voudraient accéder à notre serveur.


3.3 Gérer l’intégrité des données

Ce volet de la sécurité des serveurs mails concerne le contenu des messages. En effet

maintenant que les communications sont chiffrées et que les utilisateurs sont authentifiés

avant toute opération, il reste à s’assurer que le contenu des messages n’est pas malveillant.

3.3.1 Filtrage de contenu avec Amavis

Afin de centraliser toutes les opérations de filtrage de contenu, il faut mettre en place un

démon SMTP qui sera capable de recevoir un mail, d’en extraire le contenu pour analyse

puis de le renvoyer sous certaines conditions : c’est le rôle d’Amavis. Ce n’est pas un

antivirus mais un outil qui fonctionne conjointement avec Postfix pour fournir le contenu du

mail à des scanners tels que ClamAV.

L’installation d’Amavis se fait à partir de la commande suivante :

# aptitude install amavisd-new

Postfix prévoit une directive spécifique pour le filtrage de contenu: content_filter. Pour

analyser le contenu avant de délivrer le message, il faut donc simplement indiquer à Postfix

le transport à utiliser pour faire cette analyse dans le fichier /etc/postfix/main.cf:

content_filter = amavis:[127.0.0.1]:10024

Ainsi, Postfix transmet le message à l’outil de transport d’Amavis sur le port 10024 de la

machine locale. Il faut maintenant configurer ce transport dans le fichier

/etc/postfix/master.cf. Cette modification peut-être simplement réalisée à l’aide de

la commande suivante :

# postfix -add -filter amavis 10025


Cette commande a permis de modifier le fichier master.cf afin d’indiquer le routage des

messages. Le message sera maintenant analysé par Amavis puis, si le contenu n’est pas

indésirable, il sera retransmis à Postfix sur le port 10025.

Amavis est maintenant en place il suffit de redémarrer les services pour que les

modifications soient prises en compte.

# /etc/init.d/amavis restart

# /etc/init.d/postfix restart

3.3.2 Intégration d’un antivirus : ClamAV

Il existe de nombreux antivirus mais beaucoup sont distribués sous des licences

propriétaires. Dans le monde de l’Open, il existe ClamAV qui fait très bien son boulot. Pour

qu’Amavis puisse faire du filtrage antivirus, il faut donc installer ClamAV ainsi que quelques

librairies de compression (pour analyser les archives). L’installation peut se faire à partir de

la commande suivante:

# aptitude install clamav clamav-daemon gzip bzip2 unzip unrar zoo arj

ClamAV est l’antivirus qui va lire le contenu des mails puis le valider et le transmettre à

Postfix ou le rejeter. Pour que tout se passe correctement, il faut maintenant s’assurer que

l’utilisateur "clamav" fasse partie du groupe "amavis".

# adduser clamav amavis

Activation du support antivirus pour Amavis dans le fichier /etc/amavis/conf.d/15-

content_filter_mode :

@bypass_virus_checks_maps=(\%bypass_virus_checks,\@bypass_virus_checks_acl,

\$bypass_virus_checks_re);


Configuration d’Amavis dans /etc/amavis/conf.d/20-debian_defaults

$final_virus_destiny = D_BOUNCE;

Redémarrage des services

# /etc/init.d/clamav-daemon restart


Pour vérifier le bon fonctionnement de l’antivirus, on peut utiliser des sites prévus à cet effet

comme GFI Email Security Test. Ces sites permettent d’envoyer des mails infectés avec un

virus de test (non dangereux) vers votre serveur. En fonction des paramètres de notification

qui ont été choisi, la réception de ce mail devrait, ou non, déclencher une alerte à

l’administrateur du serveur.

3.3.3 Intégration d’un Anti Spam : Spamassassin

Le but de Spamassassin est de filtrer le trafic des courriels pour éradiquer les courriels

reconnus comme pourriels ou courriels non sollicités.

Face à l'augmentation importante du spam, ce logiciel connaît un engouement important et

est adaptable sur de nombreux serveurs de courriels dont Sendmail, Postfix, Exim, Qmail ; il

peut être installé sur la plupart des systèmes basés sur Linux, Windows et Mac OS X.

Spamassassin est un programme écrit en Perl qui fait passer un certain nombre de tests au

message. En fonction du résultat de ces tests, il attribue un score au courriel.

Si le score dépasse un certain seuil, le courriel est alors considéré comme du Spam.

Spamassassin modifie alors le titre du message (il l'encadre par ***** SPAM *****). De plus,

Spamassassin positionne deux nouveaux en-têtes au message : X-Spam-Status et X-Spam-

Level.

Ces deux en-têtes permettent alors de créer des filtres dans votre client de messagerie pour

orienter le message (par exemple le mettre dans la corbeille).


Tous les messages doivent donc passer par Spamassassin pour être traités, avant d’arriver

dans leur dossier définitif.

Pour installer Spamassassin et des outils anti-spam :

# aptitude install spamassassin libnet -dns -perl razor pyzor

Activation de la cron Spamassassin dans /etc/default/spamassassin. Ceci permet de

mettre à jour les règles chaque nuit.

CRON =1

Mise à jour des règles Spamassassin :

# sa -update

La configuration de Spamassassin se fait dans le fichier /etc/spamassassin/local.cf.

Ce fichier doit être édité comme ceci :

report_safe 0

lock_method flock

# Bayes -related operations

use_bayes 1

use_bayes_rules 1

bayes_auto_learn 1

bayes_auto_expire 1

bayes_path /var/lib/amavis /.spamassassin /bayes

bayes_file_mode 0777

# External network tests

dns_available yes

skip_rbl_checks 0

use_razor2 1

use_pyzor 1

# Use URIBL (http :// www.uribl.com/about.shtml)

urirhssub URIBL_BLACK multi.uribl.com. A 2


body URIBL_BLACK eval: check_uridnsbl (’URIBL_BLACK ’)

describe URIBL_BLACK Contains an URL listed in the URIBL

blacklist

tflags URIBL_BLACK net

score URIBL_BLACK 3.0

urirhssub URIBL_GREY multi.uribl.com. A 4

body URIBL_GREY eval: check_uridnsbl (’URIBL_GREY ’)

describe URIBL_GREY Contains an URL listed in the URIBL

greylist

tflags URIBL_GREY net

score URIBL_GREY 0.25

# Use SURBL (http:// www.surbl.org/)

urirhssub URIBL_JP_SURBL multi.surbl.org. A 64

body URIBL_JP_SURBL eval: check_uridnsbl (’URIBL_JP_SURBL ’)

describe URIBL_JP_SURBL Has URI in JP at http://

www.surbl.org/lists.html

tflags URIBL_JP_SURBL net

score URIBL_JP_SURBL 3.0

Configuration de razor en utilisant l’utilisateur amavis

# su - amavis

$ razor -admin -d --create

$ razor -admin -register

$ razor -admin -discover

Configuration de pyzor en utilisant l’utilisateur amavis

# su - amavis

$ pyzor disposer

Il faut ensuite activer le support anti-spam pour Amavis dans le fichier

/etc/amavis/conf.d/15-content_filter_mode. Il faut seulement enlever les

commentaires des deux lignes suivants:


@bypass_spam_checks_maps = (\% bypass_spam_checks,\ @bypass_spam_checks_acl

,\ $bypass_spam_checks_re );

Il faut maintenant définir le comportement d’Amavis lorsque Spamassassin a terminé

d’analyser le message. Comme indiqué précédemment, Spamassassin affecte un score au

message. Amavis va maintenant comparer ce score au seuil défini par la variable FIXME. Si le

score est supérieur à cette valeur, Amavis va appliquer les règles destinées aux messages

indésirables. Le score affecté par Spamassassin n’étant jamais fiable à cent pour cent, il faire

prendre beaucoup de précautions lors de la définition des règles d’Amavis. Par exemple :

il ne vaut mieux pas modifier le sujet du message en ajoutant "***SPAM***" : si le

message est marqué par erreur, l’utilisateur final aura un message désirable dont le sujet

commencera par ***SPAM*** ;

il est fortement recommandé de ne pas supprimer directement les messages marqués

comme spam;

la méthode la plus sûr, est sans doute d’inscrire le score dans les en-têtes et de ne pas

toucher au reste du message. Il suffit ensuite d’utiliser les différentes méthodes de

filtrage pour que les spams soient délivrés dans un dossier spécifique.

Toute cette configuration se fait dans le fichier /etc/amavis/conf.d/20-

debian_defaults :

# $sa_spam_subject_tag = ’*** SPAM *** ’;

$sa_tag_level_deflt = undef;

$sa_tag2_level_deflt = 6.00;

$sa_kill_level_deflt = 6.00;

$final_banned_destiny = D_BOUNCE;

$final_spam_destiny = D_PASS;

$final_bad_header_destiny = D_PASS;

Notons qu’avec la configuration ci-dessus, les en-têtes de spam seront ajoutées sur tous les

messages, quel que soit le score obtenu. Par ailleurs, tous les messages atteignant un score

supérieur à 6.0 seront considérés comme Spam.


Comme toujours, les modifications ne seront prises en compte qu’après un redémarrage

d’Amavis :


3.3.4 Tri des messages avec SIEVE

Dovecot est conçu en favorisant toujours les aspects de sécurité. Il est activement développé

et implémente de nombreuses fonctionnalités. L’un des atouts intéressant de Dovecot est la

gestion des filtres SIEVE. SIEVE est un langage permettant de traiter les messages à leur

arrivée sur le serveur : il est par exemple possible de rediriger un message vers un dossier

particulier ou de mettre en place un répondeur automatique de vacance.

SIEVE agit donc de manière comparable à Procmail mais apporte une fonctionnalité très

intéressante: MANAGESIEVE. MANAGESIEVE est un protocole permettant de gérer les scripts

de filtrage depuis l’application de messagerie cliente : plus besoin de se connecter en SSH

pour éditer son script de filtrage !

Bien entendu, le support SIEVE est disponible uniquement si la livraison des messages est

réalisée par le LDA de Dovecot.

Configuration du plugin

Pour activer le plugin SIEVE il faut éditer le fichier /etc/dovecot/dovecot.conf comme

suit :

protocol lda {

[...]

# sieve_global_path =

mail_plugins = [...] cmusieve

[...]

}

Pour activer la gestion des filtres SIEVE, il ne reste plus qu’à redémarrer le service :



Édition d’un script de base dans /home/<user_name>/.dovecot.sieve:

require "fileinto ";

if address :is "from" " [email protected]" {

fileinto "user";

}

Exemple de script pour mettre en place un répondeur automatique de vacance :

require [" fileinto", "vacation "];

if header :contains "X-Spam -Flag" "YES" {

fileinto "Junk ";

} else {

vacation

# Répondre uniquement 1 fois par jour au même expéditeur

:days 1

# Sujet de la réponse automatique

:subject "Message automatique de vacance"

# Liste des adresses de destination pour lesquelles il faut envoyer le

message

# de vacance automatique

:addresses [" [email protected]", " [email protected]"]

"Nous insérons ici le message de vacance

Cordialement";

}

Filtres globaux

Dovecot supporte les filtres globaux pour permettre à tous les utilisateurs de partager un

script de filtrage. Attention cependant, le script global défini par la variable

sieve_global_path ne sera exécuté uniquement s’il n’y a aucun filtre personnel pour

l’utilisateur.

Dans /etc/dovecot/dovecot.conf :


protocol lda {

[...]

sieve_global_path = /etc/dovecot/ global_script /dovecot.sieve

mail_plugins = [...] cmusieve

[...]

}

Création du répertoire :

# mkdir /etc/dovecot/global_script

Exemple de script pour trier les mails marqués par Spamassassin :

require "fileinto ";

if header :contains "X-Spam -Flag" "YES" {

fileinto "Junk ";

}

Modification des droits:

# chown -R vmail:mail/etc/dovecot/global_script/

# chmod -R 770 /etc/dovecot/global_script/

Pour appliquer la configuration, il ne reste plus qu’à redémarrer le service :


Edition des scripts : MANAGESIEVE

Comme indiqué précédemment, Dovecot gère maintenant le protocole MANAGESIEVE. Ce

support n’est pas encore officiel mais est disponible sous forme de patch. Coté Debian, le

patch est inclus dans les paquets depuis la version 1.0.12.


Pour activer le démon managesieve, il suffit simplement de l’ajouter dans la directive

protocols du fichier /etc/dovecot/dovecot.conf :

protocols = imaps managesieve

[...]

protocol managesieve {

sieve =~/. dovecot.sieve

sieve_storage =~/ sieve

}

Malheureusement, les clients capables de gérer correctement le protocole MANAGESIEVE

sont très rares :

Il existe un plugin pour RoundCube mais qui ne fonctionne pas sur la version stable

actuelle.

Le plugin Thunderbird fonctionne maintenant correctement depuis sa version 0.1.5. Ce

plugin permet de gérer le protocole MANAGESIEVE mais malheureusement l’édition des

scripts doit encore se faire manuellement.

Ainsi, notre système de messagerie est fin prêt, opérationnel avec une sécurité, nous ne

dirons pas inviolable, mais que le pirate ou hacker aura beaucoup de mal à mettre hors de

portée.


Bibliographie / Webographie

Raphaël MARICHEZ, « Sécurité des Systèmes d’informations et des Réseaux », ENST Paris Mars 2006

Abdalla ALTUNAIJI, Hugo ETIEVANT, Remy FABREGES, Benoît MAYNARD, Jean-François RODRIGUEZ, Yohan VALETTE, «Mise en place d'un réseau sécurisé - R5 », Maîtrise IUP Génie Informatique Réseau, Université Claude Bernard - Lyon 1, Novembre 2002.

Guillaume SIGUI, « Mise en place d'un système de messagerie électronique sous Linux ».

http://doc.ubuntu-fr.org/

http://www.commentcamarche.net/contents/networking/

http://trac.roundcube.net/wiki/RoundCube

http://www.howtoforge.com/howtos/linux/ubuntu

http://fr.wikipedia.org/wiki/Portail:Sécurité_informatique

http://postfix.traduc.org/index.php

http://www.vogelweith.com/home/index.php

http://prendreuncafe.com/

http://www.linux-france.org/article/memo/dns/dns.html

http://www.alsacreations.com/tutoriels/622-Securite-firewall-iptables.html

http://www.postfix.org/

http://wiki.dovecot.org/

http://www.system-linux.eu/index.php?tag/roundcube

http://www.tbs-internet.com/

http://www.nbs-system.com/blog/howto-iptables/

http://doc.ubuntu-fr.org/

http://www.commentcamarche.net/contents/networking/

http://trac.roundcube.net/wiki/RoundCube

http://www.howtoforge.com/howtos/linux/ubuntu

http://fr.wikipedia.org/wiki/Portail:Sécurité_informatique

http://postfix.traduc.org/index.php

http://www.vogelweith.com/home/index.php

http://prendreuncafe.com/

http://www.linux-france.org/article/memo/dns/dns.html

http://www.alsacreations.com/tutoriels/622-Securite-firewall-iptables.html

http://www.postfix.org/

http://wiki.dovecot.org/

http://www.system-linux.eu/index.php?tag/roundcube

http://www.tbs-internet.com/

http://www.nbs-system.com/blog/howto-iptables/


Conclusion Au terme de ce mémoire, nous avons pu exploiter nos connaissances théoriques et pratiques

pour mettre en place un système de messagerie sécurisée pour une PME/PMI.

D’abord, nous avons analysé quelles motivations pourraient avoir une entreprise de la sorte

à mettre en place ce système puis quels pourraient être les risques.

Nous avons tout au long de ce travail voulu offrir au lecteur la possibilité de mettre son

propre serveur mail grâce aux différentes directives qu’on lui a présenté.

C’est ainsi que l’on a articulé notre travail autour d’abord d’une partie théorique expliquant

les outils qui ont été utilisés et comment les utiliser, ensuite d’une autre partie mettant tout

cela en pratique pour mettre en place le serveur mail. Vu les risques qu’on a bien dégagés,

on a senti obligatoire pour la PME/PMI de sécuriser tout ce système déjà mis en place. D’où

la partie sur comment sécuriser qui divise la sécurisation en trois parties essentielles.

Ce mémoire a été pour nous l’occasion d’une émulation intellectuelle dans le domaine de la

messagerie électronique. Nous avons pu apprendre à travailler en groupe mais aussi à

persévérer quelques difficultés qui se sont présentées à nous.

Cependant, la sécurité des services réseaux constitue un domaine assez large de

l’informatique qui grâce à ce mémoire nous a séduit, et qui demande encore beaucoup de

travaux de la communauté informatique.


ANNEXES


Récapitulatif des principales commandes SMTP

Commande Exemple Description

HELO (devenu EHLO) EHLO 121.12.54.75

Identification à l'aide de

l'adresse IP ou du nom de

domaine de l'ordinateur

expéditeur

MAIL FROM: MAIL FROM:

[email protected]

Identification de l'adresse de

l'expéditeur

RCPT TO: RCPT TO:

[email protected]

Identification de l'adresse du

destinataire

DATA DATA message Corps du mail

QUIT QUIT Sortie du serveur SMTP

HELP HELP Liste des commandes SMTP

supportées par le serveur

Tableau 1 : Récapitulatif des principales commandes SMTP


Différents codes de retour SMTP et leur signification.

211 État système, ou réponse d'aide système

214 Message d'aide [Informations sur l'utilisation d'un récepteur ou signification d'une commande

non standard particulière ; utile seulement pour un utilisateur humain]

220 <domaine> Service disponible

221 <domaine> Canal de transmission en cours de fermeture

250 Action de messagerie effectuée, succès

251 Utilisateur non local ; réémission vers <route-directe> (avec relais automatique)

354 Début du corps du message ; arrêt par <CRLF>.<CRLF>

421 <domaine> Service non disponible, canal en fermeture [Réponse à émettre sur tous les canaux

lorsque le système exécute une séquence d'arrêt]

450 Action non effectuée : boîte aux lettres non disponible [Ex. : boîte aux lettres occupée]

451 Action arrêtée : erreur de traitement

452 Action non effectuée : manque de ressources système

500 Erreur de syntaxe, commande non reconnue [y compris des erreurs de type "ligne de

commande trop longue"]

501 Erreur de syntaxe dans les paramètres ou arguments

502 Commande non implémentée

503 Mauvaise séquence de commandes

504 Paramètre de commande non implémenté

550 Action non effectuée : boîte-aux-lettres non disponible [Ex : boîte aux lettres non trouvée, pas

d'accès]

551 Utilisateur non local ; essayer <route-directe> (sans relais automatique)

552 Action annulée : manque de ressources de stockage

553 Action non effectuée : nom de boîte-aux-lettres non autorisée [Ex : erreur de syntaxe dans le

nom de boîte]

554 Transaction échouée


Principales commandes POP3 et leurs descriptions :

Commande Description

USER identifiant

Cette commande permet de s'authentifier. Elle doit être suivie du nom de

l'utilisateur, c'est-à-dire une chaîne de caractères identifiant l'utilisateur sur

le serveur. La commande USER doit précéder la commande PASS.

PASS mot_de_passe La commande PASS, permet d'indiquer le mot de passe de l'utilisateur dont

le nom a été spécifié lors d'une commande USER préalable.

STAT Informations sur les messages contenus sur le serveur.

RETR Numéro du message à récupérer.

DELE Numéro du message à supprimer.

LIST [msg] Numéro du message à afficher.

NOOP Permet de garder les connexions ouvertes en cas d'inactivité.

TOP <message_ID> <n>

Commande affichant n lignes du message, dont le numéro est donné en

argument. En cas de réponse positive du serveur, celui-ci renvoie les en-

têtes du message, puis une ligne vierge et enfin les n premières lignes du

message.

UIDL [msg]

Demande au serveur de renvoyer une ligne contenant des informations sur

le message éventuellement donné en argument. Cette ligne contient une

chaîne de caractères, appelée listing d'identificateur unique, permettant

d'identifier de façon unique le message sur le serveur, indépendamment de

la session. L'argument optionnel est un numéro correspondant à un

message existant sur le serveur POP, c'est-à-dire un message non effacé).

QUIT

La commande QUIT demande la sortie du serveur POP3. Elle entraine la

suppression de tous les messages marqués comme effacés et renvoie l'état

de cette action.

Tableau 2 : Principales commandes POP3 et leurs descriptions

mise en place d'un système de messagerie sécurisée pour une pme/pmi

Documents

donnentlnergie et

saint louis et

amis et toutes

difficult et tu

architecture et principe

son accueil et

sciences appliquees

sciences appliques et