Embed Size (px)
Citation preview
2015
5GTEL – 2015/2016
09/11/2015
NORME ET PROTOCOLE
Publié par
MAX BENANA
ECOLE NATIONALE SUPERIEURE POLYTECHNIQUE CAMEROUN
DEPARTEMENT DE GENIE ELECTRIQUE ET
TELECOMMUNICATION
5GTEL – 2015/2016 1
NORME ET PROTOCOLE
Table des matières LISTE DES FIGURES...................................................................................................................... 3
LISTE DES TABLEAUX .................................................................................................................. 4
INTRODUCTION .......................................................................................................................... 5
I. Le DNS ................................................................................................................................ 6
1. DEFINITION ...................................................................................................................... 6
2. HISTORIQUE ..................................................................................................................... 6
3. QUELQUES NOTIONS FONDAMENTALES ........................................................................ 8
3.1. Notion de domaine .................................................................................................. 8
3.2. Notion d'hôte ........................................................................................................... 8
3.3. Notion de zone ......................................................................................................... 8
4. ARCHITECTURE DE FONCTIONNEMENT SUR INTERNET.................................................. 9
4.1. Architecture logique de fonctionnement ................................................................ 9
4.2. Principe de nommage de domaine ........................................................................ 12
4.3. Principe des zones .................................................................................................. 13
4.4. Type de serveurs et autorités ................................................................................ 16
4.5. La diffusion des modifications ............................................................................... 20
4.6. Recherche de ressources ....................................................................................... 20
5. La sécurité ..................................................................................................................... 33
5.1. Fragilité du DNS ...................................................................................................... 33
5.2. Sécurisation du DNS ............................................................................................... 33
II. SMTP ................................................................................................................................. 34
1. DEFINITION .................................................................................................................... 34
2. Introduction Au Courrier Electronique ......................................................................... 34
3. Architecture modulaire d’un système de messagerie Internet .................................... 38
4. Principes d'envoi ........................................................................................................... 39
5. Comparaison avec HTTP ................................................................................................ 43
6. Format du courrier électronique ................................................................................... 45
7. Les Différents Types De Requêtes Client SMTP ............................................................ 46
8. Différents Types De Réponses Serveur ......................................................................... 46
9. Quelques Spécificités Du Protocol SMTP ......................................................................... 47
5GTEL – 2015/2016 2
NORME ET PROTOCOLE
III. LE PROTOCOLE IMAP ........................................................................................................ 48
1. DEFINITION .................................................................................................................... 48
2. LE PRINCIPE D’IMAP ...................................................................................................... 49
3. LES AVANTAGES D’IMAP ............................................................................................... 49
4. LES INCONVENIENTS D’IMAP ........................................................................................ 50
IV. LE PROTOCOLE POP .......................................................................................................... 50
1. DEFINITION .................................................................................................................... 50
2. LE PRINCIPE DE POP ...................................................................................................... 50
3. AVANTAGES DU PROTOCOLE POP ................................................................................ 50
4. INCONVENIENTS DU PROTOCOLE POP : ....................................................................... 51
5. Le protocole POP3 : ....................................................................................................... 51
6. Quelques commandes : ................................................................................................. 52
7. Différences entre POP et IMAP : Lequel choisir entre POP et IMAP ............................... 53
V. MIME ................................................................................................................................ 54
1. Definition : ........................................................................................................................ 54
2. Présentation et généralité ............................................................................................ 54
3. Structure d’une entête MIME ....................................................................................... 56
3.1. MIME-Version ........................................................................................................ 56
3.2. Content-Type ......................................................................................................... 56
3.3. NContent-Transfer-Encoding ................................................................................. 57
4. Notion d’encodages : .................................................................................................... 58
5. Notion de message à plusieurs parties : Multipart message ........................................ 59
6. Sous-types ..................................................................................................................... 60
6.1. Mixed ..................................................................................................................... 61
6.2. Digest multipart/digest est la manière simple d'. ................................................. 61
6.3. Related ................................................................................................................... 61
6.4. Report .................................................................................................................... 62
6.5. Signed ..................................................................................................................... 62
6.6. Encrypted ............................................................................................................... 62
6.7. Form Data............................................................................................................... 62
6.8. Explication et description du message capturé : ................................................... 65
CONCLUSION ............................................................................................................................ 67
REFERENCES ............................................................................................................................. 68
5GTEL – 2015/2016 3
NORME ET PROTOCOLE
LISTE DES FIGURES
Figure 1: Jon Postel..................................................................................................................... 7
Figure 2: Paul Mockapetris ......................................................................................................... 7
Figure 3: Architecture logique du fonctionnement du DNS. ..................................................... 9
Figure 4: Architecture explicite de fonctionnement du DNS. .................................................... 9
Figure 5:Répartition des noms de domaine en zones. ............................................................. 10
Figure 6:Nommage par analogie avec le système de fichier Windows. .................................. 13
Figure 7: Formation d'une zone. .............................................................................................. 14
Figure 8: Structure de l'entête DNS. ........................................................................................ 21
Figure 9: Les différents champs d'un RR. ................................................................................. 24
Figure 10: Schéma illustrant le mode itératif de requête. ....................................................... 29
Figure 11: Schéma illustrant le mode récursif d'une requête.................................................. 30
Figure 12: Système de messagerie Internet. ............................................................................ 35
Figure 13: Architecture modulaire d’un système de messagerie Internet .............................. 38
Figure 14: Principe d'envoi via SMTP ....................................................................................... 39
Figure 15: Principe d'envoi d'un Mail. ...................................................................................... 41
Figure 16: Processus détaillé d'envoi en comparaison avec le protocole HTTP. ..................... 44
Figure 17: Avantage de laisser les messages sur le serveur..................................................... 49
Figure 18: Différence entre POP et IMAP ................................................................................. 53
Figure 19: Corps du message (Multipart message) .................................................................. 59
Figure 20: Message capturé (MIME ) ....................................................................................... 64
5GTEL – 2015/2016 4
NORME ET PROTOCOLE
LISTE DES TABLEAUX
Tableau 1: Liste des TLDs générique. ....................................................................................... 12
Tableau 2: La nomenclature des treize serveurs de racine du DNS présentée par une lettre de
l'alphabet comprise entre a et m et placé à gauche des labels. ............................................. 18
Tableau 3: Type de données est utilisé dans le RR .................................................................. 25
Tableau 4: Les classes de protocole possible ........................................................................... 25
Tableau 5: Exemple de requête. .............................................................................................. 27
Tableau 6: Réponse à la requête. ............................................................................................. 28
Tableau 7: Représentation d'une requête inverse................................................................... 32
Tableau 8: Quelques commandes pour POP. ........................................................................... 52
5GTEL – 2015/2016 5
NORME ET PROTOCOLE
INTRODUCTION
Dans un réseau, un protocole est un ensemble de règles et de procédures de communication
utilisées de part et d’autre par toutes les stations qui échangent des données sur le réseau. Il
existe de nombreux protocoles mais ils n’ont pas tous ni le même rôle, ni la même façon de
procéder, certains fonctionnement au niveau de plusieurs couches du modèle OSI et d’autres
peuvent être spécialisés dans la réalisation d’une tâche correspondante à une seule couche.
Ainsi le thème qui à été soumis à notre étude porte sur les protocoles de messageries à savoir
SMTP, IMAP, POP et MIME et une étude du système DNS.
5GTEL – 2015/2016 6
NORME ET PROTOCOLE
I. Le DNS
1. DEFINITION
DNS (Domain Name System, système de noms de domaine) est un système de noms pour
les ordinateurs et les services réseau organisé selon une hiérarchie de domaines. Le système
DNS est utilisé dans les réseaux TCP/IP tels qu'Internet pour localiser des ordinateurs et des
services à l'aide de noms conviviaux. Lorsqu'un utilisateur entre un nom DNS dans une
application, les services DNS peuvent résoudre ce nom en une autre information qui lui est
associée, par exemple une adresse IP.
La plupart des utilisateurs préfèrent en effet un nom convivial
comme exemple.microsoft.com pour accéder à un ordinateur tel qu'un serveur de messagerie
ou un serveur Web dans un réseau. Un nom convivial est plus facile à retenir. Cependant, les
ordinateurs utilisent des adresses numériques pour communiquer sur un réseau. Pour faciliter
l'utilisation des ressources réseau, des systèmes de noms comme DNS fournissent une
méthode qui établit la correspondance entre le nom convivial d'un ordinateur ou d'un service
et son adresse numérique.
2. HISTORIQUE
Jusqu'en 1984, la résolution de nom de domaine se faisait grâce à un fichier texte
appelé hosts, local à chaque ordinateur qui comportait les correspondances entre les noms
de domaine et des adresses IP. Sous UNIX et ses dérivés, il se trouve dans le répertoire /etc.
Sous Windows, il se trouve, par défaut, dans %SystemRoot%\system32\drivers\etc, lequel
était transmis par Ftp à tous les hôtes. Il n'était à l'époque pas compliqué de stocker les
adresses puisque le nombre de machines était très réduit. Par ailleurs, avec la croissance
exponentielle d'Internet il a fallu trouver une autre solution, car les problèmes se sont
multipliés :
- La mise à jour des fichiers : En effet il fallait retransmettre le fichier de mise à jour à
tous les hôtes, ce qui encombrait fortement la bande passante du NIC.
- L'autonomie des organismes : Avec l'évolution de l'Internet, les architectures ont été
transformées, ainsi des organismes locaux ont eu la possibilité de créer leur propres
noms et adresses, et ils étaient alors obligés d'attendre que le NIC prenne en compte
leurs nouvelles adresses avant que les sites ne puissent être visibles par tous sur
5GTEL – 2015/2016 7
NORME ET PROTOCOLE
Internet. Le souhait était alors que chacun puisse gérer ses adresses avec une certaine
autonomie.
- Le risque de collision des noms.
Tous ces problèmes ont fait émerger des idées sur l'espace des noms et sa gestion. Les
propositions ont été diverses, mais l'une des tendances émergentes a été celle d'un espace de
noms hiérarchisé, et dont le principe hiérarchique s'appuierait autant que possible sur la
structure des organismes eux-mêmes, et où les noms utiliseraient le caractère "." pour
marquer la frontière entre deux niveaux hiérarchiques.
En 1983-1984, Paul Mockapetris et John Postel proposent et développent une solution qui
utilise des structures de base de données distribuée : les Domain Name System, les RFCs 882
et 883 devenues obsolètes par la RFC 1034. Les spécifications des Dns ont été établies en
1987.
Contrairement à son prédécesseur, le DNS offre les possibilités suivantes:
• Système hiérarchisé et distribué
• Il s'agit d'un modèle en arborescence (similaire à l'arborescence d'un système de
fichiers avec ses répertoires)
• Gestion décentralisée des bases de données. (chaque site est maître de ses données)
• Informations complémentaires : relais de messagerie, ...
• Correspondance dynamique
• Limitation des risques de collisions de noms
Figure 1: Paul Mockapetris Figure 2: Jon Postel
5GTEL – 2015/2016 8
NORME ET PROTOCOLE
3. QUELQUES NOTIONS FONDAMENTALES
3.1. Notion de domaine
Un domaine est un ensemble d'ordinateurs reliés dans un réseau, par exemple internet et
possédant une caractéristique commune. Le domaine est identifié à un nom, appelé nom de
domaine. Ce nom est constitué d'au moins un mot appelé label.
Dans une famille, tous les enfants ont dans leur nom complet, un nom qui vient du père. C'est
la même logique pour le nom de domaine, où même un domaine, porte dans son nom le nom
du domaine supérieur dont il appartient.
Dans la nomenclature d'un nom de domaine, le domaine supérieur est écrit à droite, et le
caractère point (.) sépare le nom du domaine supérieur du nom du domaine inférieur.
Un domaine appartenant à un autre est aussi appelé sous-domaine de ce domaine.
3.2. Notion d'hôte
Chaque domaine contient des ordinateurs ou des serveurs. Ce sont eux les hôtes. Les hôtes
sont les points finaux de la chaîne. Leurs noms sont qualifiés de Fully Qualified Domain Name
(FQDN), c'est-à-dire Nom de Domaine Totalement Qualifié.
La taille maximale du FQDN est de 255 caractères.
3.3. Notion de zone
Une zone est une portion d'un domaine dont l'administration est déléguée à une entité
faisant partie ou non de l'organisation.
Le concept de zone est purement au niveau administratif. La déclaration des machines dans
un domaine se fait dans les zones. Le fichier qui contient les enregistrements des machines
d'une zone est appelée fichier de zone.
5GTEL – 2015/2016 9
NORME ET PROTOCOLE
4. ARCHITECTURE DE FONCTIONNEMENT SUR INTERNET
Le fonctionnement d'internet est assuré par plusieurs serveurs DNS qui interagissent entre
eux. Tous les serveurs (web, messagerie, téléchargement, etc.) sont à la base étiquetés avec
leur adresse IP. La facilité d'accéder avec un nom commode est donnée par l'interaction des
différents serveurs DNS à travers le monde. Alors comment fonctionnent ils ?
4.1. Architecture logique de fonctionnement
D'un point de vue logique, les noms de domaine sont agencés dans une arborescence, voire
une hiérarchie. On a au sommet une racine, et une arborescence de nœuds.
third-level node
second-level node second-level node
top-level node
third-level node third-level node
second-level node
top-level node
second-level node second-level node
top-level node
The root node
""
Figure 1: Architecture logique du fonctionnement du DNS.
Figure 2: Architecture explicite de fonctionnement du DNS.
5GTEL – 2015/2016 10
NORME ET PROTOCOLE
Figure 3:Répartition des noms de domaine en zones.
La racine est un point. Elle est gérée par l'ICANN (Internet Corporation for Assigned Names
and Numbers). Tous les nœuds fils de la racine sont administrés par cette organisation. Ces
nœuds sont appelés Top Level Domain ou TLD. En français, ça donne : domaine de premier
niveau.
On distingue trois principaux types de TLD :
• le TLD spécial .arpa
• les TLD géographiques ou nationaux
• les TLD génériques
- Le TLD spécial : c'est un domaine exploité exclusivement pour à des fins techniques.
ARPA signifie Address and Routing Parameters Areas, qui veut dire zone des
paramètres d'adressage et de routage.
- Les TLD géographiques ou nationaux (cTLD= Country TLD): ce sont des TLD propres à
chaque pays du monde. Tous les pays en possèdent un. De façon nationale, ils sont
gérés par des bureaux accrédités.
- Les TLD génériques ou gTLD (Generic TLD): ce sont les autres TLD. On les considère
comme 'libres' contrairement aux précédents. Ils sont généralement utilisés par les
structures internationales telles que les multinationales, les institutions, les
5GTEL – 2015/2016 11
NORME ET PROTOCOLE
organismes non gouvernementales, etc.
La liste totale des TLD génériques valides en Avril 2009 est présentée dans le tableau
ci-dessous. Il y en a 15.
TLD Généralement utilisé par
.com les entreprises à vocation commerciale, mais devenu le plus utilisé, même par
d'autres types de structures
.edu les organismes éducatifs (universités, écoles, etc.)
.gov les organismes gouvernementaux
.int les organisations et institutions internationales
.mil les organismes militaires
.net les organismes travaillant dans le réseau, mais devient de plus en plus utilisé
comme le .com
.org les structures à but non lucratif
.aero les industries aéronautiques
.biz les entreprises commerciales
.museum les musées
.name les noms de personnages historiques, contemporains ou imaginaires
.info les organisations travaillant dans le secteur de l'information
.coop les coopératives
.pro les professions libérales
5GTEL – 2015/2016 12
NORME ET PROTOCOLE
4.2. Principe de nommage de domaine
Les labels portés par les nœuds font entre 0 et 63 octets, sachant que l'identifiant de
longueur zéro est réservé à la racine. Deux nœuds " frère " ne peuvent pas porter le même
identifiant, néanmoins, deux nœuds peuvent avoir le même label dans le cas où ils n’ont aucun
lien de " fratrie ". Le nom de domaine d'un nœud est constitué des identifiants situés entre ce
nœud à la racine de l'arborescence. Lorsqu'un utilisateur doit entrer un nom de domaine, la
longueur de chaque identifiant est omise et les identifiants devront être séparés par des points
("."). Un nom de domaine complet atteignant toujours la racine, la forme écrite exacte de tout
domaine entièrement qualifié se termine par un point. Nous utiliserons cette propriété pour
distinguer les cas :
- d'une chaîne de caractères représentant un nom de domaine complet (souvent appelé
"absolu" ou "entièrement qualifié"). Par exemple, "www.camtel.cm"
- d'une chaîne de caractères représentant les premiers identifiants d'un nom de
domaine incomplet, et devant être complété par l'application locale avec un
complément absolu (expression appelée "relative"). Par exemple, "www", à utiliser
relativement au domaine camtel.cm.
Le nom absolu correspondant donc à l'ensemble des étiquettes des nœuds d'une
arborescence, séparées par des points, et terminé par un point final, est appelé
adresse FQDN (Fully Qualified Domain Name, soit Nom de Domaine Totalement Qualifié). La
profondeur maximale de l'arborescence est de 127 niveaux et la longueur maximale d'un nom
FQDN est de 255 caractères. L'adresse FQDN permet de repérer de façon unique une machine
sur le réseau des réseaux. Ainsi yahoo.com.au. représente une adresse FQDN.
Si on fait donc une analogie avec le système de fichier de Windows on obtient donc le schéma
suivant :
.tel
les accès simples et centralisés aux coordonnées d'une structure ou même d'un
individu (le plus récemment crée : ouvert au grand public depuis le 24 Mars
2009).
Tableau 1: Liste des TLDs générique.
5GTEL – 2015/2016 13
NORME ET PROTOCOLE
com netau
com netorg id
google yahoomicrosoft
C:
Program
FilesTempWindows
System32 FontsCache Media
dllcache spooldrivers
4.3. Principe des zones
La base de données est divisée en sections appelées zones, lesquelles sont distribuées sur
l'ensemble des serveurs de noms. De plus, elle est divisée selon deux méthodes : en classes et
par "découpage" de l'espace des noms de domaines.
La partition en classes est assez simple. La base de données est organisée, déléguée, et
maintenue séparément pour chacune des classes. Comme par convention, l'espace de noms
est identique quel que soit la classe, la séparation par classe peut conduire à voir l'espace de
yahoo.com.au. C:\windows\system32\drivers\
Nommage d’un domaine Nommage d’un dossier
Figure 4:Nommage par analogie avec le système de fichier Windows.
5GTEL – 2015/2016 14
NORME ET PROTOCOLE
domaines comme un tableau d'arbres de noms parallèles. Notez que les données attachées
aux nœuds des arbres seront différentes dans chaque arbre.
Figure 5: Formation d'une zone.
4.3.1. Principes des zones
Dans une classe, des "coupes" dans l'espace de noms peuvent être faites entre deux nœuds
adjacents quelconques. Un fois toutes les coupes définies, chaque groupe de nœuds
interconnectés devient une zone indépendante. La zone est alors définie comme étant la
"sphère d'autorisation" pour tout nom à l'intérieur de la zone. Notez que les "coupes" dans
l'espace de noms peuvent être à des endroits différents de l'arbre suivant la classe, les
serveurs de noms associés peuvent être différents, etc.
5GTEL – 2015/2016 15
NORME ET PROTOCOLE
Ces règles signifient que chaque zone doit avoir au moins un nœud, et donc un nom de
domaine, pour lequel il est "autorisé", et que tous les nœuds d'une zone particulière sont
connectés. Du fait de la structure d'arbre, chaque zone contient un nœud "de plus haut
niveau" qui est plus proche de la racine que tous les autres nœuds de cette zone. Le nom de
ce nœud est souvent utilisé pour identifier la zone elle-même.
Selon ce concept, il est possible, bien que pas forcément utile, de découper l'espace de noms
de telle façon que chaque nom de domaine se retrouve dans une zone séparée ou au contraire
que tous les nœuds se retrouvent dans une zone unique.
4.3.2. Description techniques pour les zones
Les données qui décrivent chaque zone sont organisées en quatre parties :
- Les données générales sur chaque nœud de la zone
- Les données qui définissent le nœud supérieur de la zone
- Les données qui décrivent les sous-zones
- Les données qui permettent d'accéder aux serveurs de noms qui gèrent les sous-zones
Toutes ces données sont stockées dans des RRs, donc une zone peut être entièrement décrite
par un jeu de RRs. Les informations sur des zones entières peuvent donc être transmises d'un
serveur à l'autre, tout simplement en échangeant ces RRs.
Les plus importants des RRs sont ceux qui décrivent le nœud principal d'une zone. Ils sont de
deux sortes : des RRs qui répertorient l'ensemble des serveurs de noms de la zone, et un RR
de type SOA qui décrit les paramètres de gestion de la zone.
Les RRs contenant des informations sur les sous zones sont de type NS. Il faut des informations
pour connaître l'adresse d'un serveur dans la sous zone, ceci pour pouvoir y accéder. Ce genre
de données est conservé dans d'autres RRs. Tout est fait pour que dans la structure en zones,
toute zone puisse disposer localement de toutes les données nécessaires pour communiquer
avec les serveurs de noms de chacune de ses sous-zones.
5GTEL – 2015/2016 16
NORME ET PROTOCOLE
4.4. Type de serveurs et autorités
4.4.1. Les serveurs de noms
Les machines appelées serveurs de nom de domaine permettent d'établir la correspondance
entre le nom de domaine et l'adresse IP des machines d'un réseau.
Chaque domaine possède un serveur de noms de domaines, appelé « serveur de noms
primaire » (primary domain name server), ainsi qu'un serveur de noms secondaire (secondary
domaine name server), permettant de prendre le relais du serveur de noms primaire en cas
d'indisponibilité.
Chaque serveur de nom est déclaré dans à un serveur de nom de domaine de niveau
immédiatement supérieur, ce qui permet implicitement une délégation d'autorité sur les
domaines. Le système de nom est une architecture distribuée, où chaque entité est
responsable de la gestion de son nom de domaine. Il n'existe donc pas d'organisme ayant à
charge la gestion de l'ensemble des noms de domaines.
Les serveurs correspondant aux domaines de plus haut niveau (TLD) sont appelés « serveurs
de noms racine ». Il en existe treize, répartis sur la planète, possédant les noms « a.root-
servers.net » à « m.root-servers.net ».
5GTEL – 2015/2016 17
NORME ET PROTOCOLE
Nom Adresse IPv4 Localisation Société Logiciel
a.root-servers.net 198.41.0.4 Dulles (Virginie / États-
Unis) VeriSign BIND
b.root-servers.net 192.228.79.201 Marina Del Rey
(Californie / États-Unis) VeriSign BIND
c.root-servers.net 192.33.4.12 trafic distribué par
anycast
Cogent
Communications BIND
d.root-servers.net 128.8.10.90 College Park (Maryland /
Etats-Unis)
Université du
Maryland BIND
e.root-servers.net 192.203.230.10 Mountain View
(Californie / Etats-Unis) NASA BIND
f.root-servers.net 192.5.5.241 trafic distribué par
anycast ISC BIND
g.root-servers.net 192.112.36.4 Columbus (Ohio / Etats-
Unis)
Defense Information
Systems Agency BIND
h.root-servers.net 128.63.2.53 Aberdeen (Maryland /
Etats-Unis)
U.S. Army Research
Lab NSD
i.root-servers.net 192.36.148.17 trafic distribué par
anycast Autonomica BIND
j.root-servers.net 192.58.128.30 trafic distribué par
anycast VeriSign BIND
k.root-servers.net 193.0.14.129 trafic distribué par
anycast RIPE-NCC NSD
5GTEL – 2015/2016 18
NORME ET PROTOCOLE
Tableau 2: La nomenclature des treize serveurs de racine du DNS présentée par une lettre de l'alphabet comprise entre a et m
et placé à gauche des labels.
Un serveur de noms définit une zone, c'est-à-dire un ensemble de domaines sur lequel le
serveur a autorité. Le système de noms de domaine est transparent pour l'utilisateur,
néanmoins il ne faut pas oublier les points suivants :
- Chaque ordinateur doit être configuré avec l'adresse d'une machine capable de
transformer n'importe quel nom en une adresse IP. Cette machine est appelée Domain
Name Server. Pas de panique: lorsque vous vous connectez à internet, le fournisseur
d'accès va automatiquement modifier vos paramètres réseau pour vous mettre à
disposition ces serveurs de noms.
- L'adresse IP d'un second Domain Name Server (secondary Domain Name Server) doit
également être définie : le serveur de noms secondaire peut relayer le serveur de noms
primaire en cas de dysfonctionnement.
Le serveur le plus répandu s'appelle BIND (Berkeley Internet Name Domain). Il s'agit d'un
logiciel libre disponible sous les systèmes UNIX, développé initialement par l'université de
Berkeley en Californie et désormais maintenu par l'ISC (Internet Systems Consortium).
Par le découpage en zone on a trois types de serveurs de noms.
4.4.2. Le serveur primaire
Le serveur primaire est serveur d'autorité sur sa zone : il tient à jour un fichier appelé "fichier
de zone", qui établit les correspondances entre les noms et les adresses IP des hosts de sa
zone. Chaque domaine possède un et un seul serveur primaire.
l.root-servers.net 199.7.83.42 trafic distribué par
anycast ICANN NSD
m.root-servers.net 202.12.27.33 trafic distribué par
anycast WIDE Project BIND
5GTEL – 2015/2016 19
NORME ET PROTOCOLE
4.4.3. Le serveur secondaire
Un serveur de nom secondaire obtient les données de zone via le réseau, à partir d'un autre
serveur de nom qui détient l'autorité pour la zone considérée. L'obtention des informations
de zone via le réseau est appelé transfert de zone. Il est capable de répondre aux requêtes de
noms IP(partage de charge), et de secourir le serveur primaire en cas de panne. Le nombre de
serveurs secondaires par zone n'est pas limité. Ainsi il y a une redondance de l'information. Le
minimum imposé est un serveur secondaire et le pré requis mais pas obligatoire est de le
situer sur un segment différent du serveur primaire.
Un serveur qui effectue un transfert de zone vers un autre serveur est appelé serveur maître.
Un serveur maître peut être un serveur primaire ou un serveur secondaire. Un serveur
secondaire peut disposer d'une liste de serveurs maîtres (jusqu'à dix serveurs maîtres). Le
serveur secondaire contacte successivement les serveurs de cette liste, jusqu'à ce qu'il ait pu
réaliser son transfert de zone.
4.4.4. Le serveur cache
Le serveur cache ne constitue sa base d'information qu'à partir des réponses des serveurs de
noms. Il inscrit les correspondances nom / adresse IP dans un cache avec une durée de validité
limitée (TTL) ; il n'a aucune autorité sur le domaine : il n'est pas responsable de la mise à jour
des informations contenues dans son cache, mais il est capable de répondre aux requêtes des
clients Dns.
De plus on peut distinguer les serveurs racines : ils connaissent les serveurs de nom ayant
autorité sur tous les domaines racine. Les serveurs racine connaissent au moins les serveurs
de noms pouvant résoudre le premier niveau (.com, .edu, .fr, etc.) C'est une pierre angulaire
du système Dns : si les serveurs racine sont non opérationnels, il n'y a plus de communication
sur l'Internet, d'où multiplicité des serveurs racines (actuellement il y en a 14). Chaque serveur
racine reçoit environ 100 000 requêtes par heure.
Un serveur de nom, en terme de physique, peux très bien jouer le rôle de plusieurs de ces
fonctions. On trouvera par exemple, beaucoup d'entreprise qui héberge leur domaine sur le
5GTEL – 2015/2016 20
NORME ET PROTOCOLE
serveur Dns primaire servant aussi de cache pour les requêtes sortantes des utilisateurs
interne.
4.5. La diffusion des modifications
Pour chaque zone Dns, le serveur servant de référence est le Dns maître ou Dns primaire. Les
Dns esclaves ou secondaires servant cette zone vont récupérer les informations du Dns maître.
Cette récupération d'information est appelée transfert de zone. Seuls les Dns secondaires ont
besoin d'être autorisés à effectuer cette opération, mais assez souvent aucune restriction
n'est présente. Ceci permettant à n'importe qui de se connecter et d’afficher le contenu de la
zone.
Lorsque des changements apparaissent sur une zone, il faut que tous les serveurs qui gèrent
cette zone en soient informés. Les changements sont effectués sur le serveur principal, le plus
souvent en éditant un fichier. Après avoir édité le fichier, l'administrateur signale au serveur
qu'une mise à jour a été effectuée, le plus souvent au moyen d'un signal (SIGINT). Les serveurs
secondaires interrogent régulièrement le serveur principal pour savoir si les données ont
changé depuis la dernière mise à jour. Ils utilisent un numéro constitué de la date au format
américain: année, mois, jour; version du jour, il est donc toujours incrémenté. Donc pour la
mise à jour ils comparent le champ SERIAL du RR SOA de la zone donnée par le serveur
principal contenant le numéro à celui qu'ils connaissent. Si ce numéro a augmenté, ils chargent
les nouvelles données.
Lorsqu'un serveur primaire est indisponible, le serveur secondaire ne reçoit pas de réponse à
ses interrogations sur le numéro de version du fichier de zone. Il continue ses tentatives
jusqu'à expiration de la validité des enregistrements de son fichier de zone ('Expire Time').
Lorsqu'un serveur primaire redevient disponible, aucun mécanisme de synchronisation entre
le fichier de zone des serveurs secondaires et celui du serveur primaire n'a été normalisé.
4.6. Recherche de ressources
4.6.1. Les formats des paquets DNS
4.6.1.1. Le transport
- Utilisation d'UDP
5GTEL – 2015/2016 21
NORME ET PROTOCOLE
Le port serveur utilisé pour l'envoi des datagrammes en UDP est 53. Les datagrammes Dns en
UDP sont limités à 512 octets (valeur représentant les données sans l'entête UDP et IP). Les
datagrammes plus longs doivent être tronqués à l'aide du champ Tc.
L'utilisation d'UDP n'est pas recommandée pour les transferts de zone, mais uniquement pour
les requêtes standards.
- Utilisation de TCP
Le port serveur utilisé pour l'envoi des datagrammes en TCP est 53. Le datagramme inclus
alors un champ de deux octets nommé "longueur", il permet de spécifier la longueur totale
des données indépendamment de la fragmentation. La longueur est calculée sans les 2 octets
de ce même champ.
4.6.1.2. L'entête
Voici la structure de l'entête Dns basé sur 12 octets.
Figure 6: Structure de l'entête DNS.
- Id
Codé sur 16 bits, doit être recopié lors de la réponse permettant à l'application de départ de
pouvoir identifier le datagramme de retour.
- Qr
5GTEL – 2015/2016 22
NORME ET PROTOCOLE
Sur un 1 bit, ce champ permet d'indiquer s'il s'agit d'une requête (0) ou d'une réponse (1).
- Opcode
Sur 4 bits, ce champ perme de spécifier le type de requête :
0 - Requête standard (Query)
1 - Requête inverse (Iquery)
2 - Status d'une requête serveur (Status)
3-15 - Réservé pour des utilisations futures
- Aa
Le flag Aa, sur un bit, signifie "Authoritative Answer". Il indique une réponse d'une entité
autoritaire.
- Tc
Le champ Tc, sur un bit, indique que ce message a été tronqué.
- Rd
Le flag Rd, sur un bit, permet de demander la récursivité en le mettant à 1.
- Ra
Le flag Ra, sur un bit, indique que la récursivité est autorisée.
- Z
Le flag Z, sur un bit, est réservé pour une utilisation future. Il doit être placé à 0 dans tout les
cas.
- Rcode
Le champ Rcode, basé sur 4 bits, indique le type de réponse.
0 - Pas d'erreur
1 - Erreur de format dans la requête
5GTEL – 2015/2016 23
NORME ET PROTOCOLE
2 - Problème sur serveur
3 - Le nom n'existe pas
4 - Non implémenté
5 - Refus
6-15 – Réservés
- Qdcount
Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Question".
- Ancount
Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Réponse".
- Nscount
Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Autorité".
- Arcount
Codé sur 16 bits, il spécifie le nombre d'entrée dans la section "Additionnel".
4.6.1.3. Les RR
La base de données des serveurs de noms (fichier de domaine et fichiers de résolution inverse)
est constituée "d'enregistrements de ressources", "Ressource Records" (RRs). Ces
enregistrements sont répartis en classes. La seule classe d'enregistrement usuellement
employée est la classe Internet (IN). L'ensemble d'informations de ressources associé à un
nom particulier est composé de quatre enregistrements de ressources séparés (RR). Voici les
différents champs d'un RR que vous pouvez aussi retrouver dans la Rfc 1035 au chapitre 3.2.1
:
5GTEL – 2015/2016 24
NORME ET PROTOCOLE
Figure 7: Les différents champs d'un RR.
- Nom
Nom du domaine où se trouve le RR. Ce champ est implicite lorsqu'un RR est en dessous d'un
autre, auquel cas le champ owner est le même que celui de la ligne précédente.
- Type
Ce champ type, codé sur 16 bits, spécifie quel type de données est utilisé dans le RR. Voici les
différents types disponibles:
Entrée Valeur Désignation
A 01 Adresse de l'hôte
NS 02 Nom du serveur de noms pour ce domaine
MD 03 Messagerie (obselete par l'entrée MX)
MF 04 Messagerie (obselete par l'entrée MX)
CNAME 05 Nom canonique (Nom pointant sur un autre nom)
SOA 06 Début d'une zone d'autorité (informations générales sur la zone)
MB 07 Une boite à lettre du nom de domaine (expérimentale)
MG 08 Membre d'un groupe de mail (expérimental)
MR 09 Alias pour un site (expérimentale)
5GTEL – 2015/2016 25
NORME ET PROTOCOLE
NULL 10 Enregistrement à 0 (expérimentale)
WKS 11 Services Internet connus sur la machine
PTR 12 Pointeur vers un autre espace du domaine (résolution inverse)
HINFO 13 Description de la machine
MINFO 14 Groupe de boite à lettres
MX 15 Mail exchange (Indique le serveur de messagerie. Voir [Rfc-974] pour
plus de détails
TXT 16 Chaîne de caractère
Tableau 3: Type de données est utilisé dans le RR.
- Classe
Une valeur encodée sur 16 bits identifiant une famille de protocoles ou une instance d'un
protocole. Voici les classes de protocole possible :
Entrée Valeur Désignation
In 01 Internet
Cs 02 Class Csnet (obsolète)
Ch 03 Chaos (chaosnet est un ancien réseau qui historiquement a eu une
grosse influence sur le développement de l'Internet, on peut
considérer à l'heure actuelle qu'il n'est plus utilisé)
Hs 04 Hesiod
Tableau 4: Les classes de protocole possible
- Ttl
C'est la durée de vie des RRs (32 bits, en secondes), utilisée par les solveurs de noms lorsqu'ils
ont un cache des RRs pour connaître la durée de validité des informations du cache.
- Longueur
Sur 16 bits, ce champ indique la longueur des données suivantes.
- Données
5GTEL – 2015/2016 26
NORME ET PROTOCOLE
Données identifiant la ressource, ce que l'on met dans ces champs dépend évidemment du
type de ressources que l'on décrit.
A : Pour la classe IN, une adresse IP sur 32 bits. Pour la classe CH, un nom de domaine suivi
d'une adresse octale Chaotique sur 16 bits.
Cname : un nom de domaine.
Mx : une valeur de préférence sur 16 bits (la plus basse possible) suivie d'un nom d'hôte
souhaitant servir d'échangeur de courrier pour le domaine de l'owner.
Ptr : Une adresse IP sous forme d'un nom.
Ns : Un nom d'hôte.
Soa : Plusieurs champs.
4.6.2. Les Résolveurs
Les "résolveurs" sont des programmes qui interfacent les applications utilisateur aux serveurs
de noms de domaines. En effet, ce n'est pas l'utilisateur qui effectue les requêtes directement.
Dans le cas le plus simple, un résolveur reçoit une requête provenant d'une application (ex.,
applications de courrier électronique, Telnet, Ftp) sous la forme d'un appel d'une fonction de
bibliothèque, d'un appel système etc., et renvoie une information sous une forme compatible
avec la représentation locale de données du système.
Le résolveur est situé sur la même machine que l'application recourant à ses services, mais
devra par contre consulter des serveurs de noms de domaines sur d'autres hôtes. Comme un
résolveur peut avoir besoin de contacter plusieurs serveurs de noms, ou obtenir les
informations directement à partir de son cache local, le temps de réponse d'un résolveur peut
varier selon de grandes proportions, depuis quelques millisecondes à plusieurs secondes.
L'une des raisons les plus importantes qui justifient l'existence des résolveurs est d'éliminer le
temps d'acheminement de l'information depuis le réseau, et de décharger simultanément les
serveurs de noms, en répondant à partir des données cachées en local. Il en résulte qu'un
5GTEL – 2015/2016 27
NORME ET PROTOCOLE
cache partagé entre plusieurs processus, utilisateurs, machines, etc., sera incomparablement
plus efficace qu'une cache non partagé.
4.6.3. Les Requêtes
La principale activité d'un serveur de noms est de répondre à la requête standard. La requête
et sa réponse sont toutes deux véhiculées par un message standardisé décrit dans la Rfc 1035.
La requête contient des champs QTYPE, QCLASS, et QNAME, qui décrivent le(s) type(s) et les
classes de l'information souhaitée, et quel nom de domaine cette information concerne. Les
requêtes sont des messages envoyés aux serveurs de noms en vue de consulter les données
stockées par le serveur. Par exemple avec Internet, on peut utiliser aussi
bien Udp que Tcp pour envoyer ces requêtes.
4.6.4. Structure des requêtes
Parmi les champs fixes on trouve 4 bits très importants appelé code d'opération (OPCODE). Le
code d'opération permet de donner des informations sur la nature du message (requête,
réponse, ...). Les quatre possibilités sont :
- Question, Contient la question (nom d'hôte ou de domaine sur lequel on cherche des
renseignements et type de renseignements recherchés).
- Answer, Contient les RRs qui répondent à la question.
- Authority, Contient des RRs qui indiquent des serveurs ayant une connaissance
complète de cette partie du réseau.
- Additional, Contient des RRs supplémentaires pouvant être utiles pour exploiter les
informations contenues dans les autres sections.
Voici un exemple de requête où l'on souhaite connaître le nom du serveur de courrier
s'occupant de frameip.com :
Header OPCODE=SQUERY
Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer vide
Authotity vide
Additionnal vide
Tableau 2: Exemple de requête.
5GTEL – 2015/2016 28
NORME ET PROTOCOLE
La réponse obtenue est :
Header OPCODE=SQUERY, RESPONSE, AA
Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer ISI.EDU MX 10 VENERA.ISI.EDU MX 10 VAXA.ISI.EDU
Authotity vide
Additionnal VENERA.ISI.EDU A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU A 10.2.0.27 A
128.9.0.33
Tableau 6: Réponse à la requête.
4.6.5. Le mode Itératif
Ce mode est le plus simple du point de vue du serveur. Les serveurs répondent directement à
la requête sur la base seule de ses informations locales. La réponse peut contenir la réponse
demandée, ou bien donne la référence d'un autre serveur qui sera "plus susceptible " de
disposer de l'information demandée. Il est important que tous les serveurs de noms puissent
implémenter ce mode itératif et désactive la fonction de récursivité.
5GTEL – 2015/2016 29
NORME ET PROTOCOLE
Figure 8: Schéma illustrant le mode itératif de requête.
Les avantages d'une résolution itérative :
- Dans le cas d'une implémentation simplifiée d'un résolveur qui ne sait exploiter
d'autres réponses qu'une réponse directe à la question.
- Dans le cas d'une requête qui doit passer à travers d'autres protocoles ou autres
"frontières" et doit pouvoir être envoyée à un serveur jouant le rôle d'intermédiaire.
- Dans le cas d'un réseau dans lequel intervient une politique de cache commun plutôt
qu'un cache individuel par client.
Le service non-récursif est approprié si le résolveur est capable de façon autonome de
poursuivre sa recherche et est capable d'exploiter l'information supplémentaire qui lui est
envoyée pour l'aider à résoudre son problème.
4.6.6. Le mode Récursif
Le mode récursif une fois est plus simple du point de vue du client. Dans ce mode, le premier
serveur prend le rôle de résolveur.
5GTEL – 2015/2016 30
NORME ET PROTOCOLE
Figure 9: Schéma illustrant le mode récursif d'une requête.
L'utilisation du mode récursif est limité aux cas qui résultent d'un accord négocié entre le client
et le serveur. Cet accord est négocié par l'utilisation de deux bits particuliers des messages de
requête et de réponse :
- Le bit Ra (Récursion admissible), est marqué ou non par le serveur dans toutes les
réponses. Ce bit est marqué si le serveur accepte à priori de fournir le service récursif
au client, que ce dernier l'ait demandé ou non. Autrement dit, le bit RA signale la
disponibilité du service plutôt que son utilisation.
- Les requêtes disposent d'un bit Rd (pour "récursion désirée"). Ce bit indique que le
requérant désire utiliser le service récursif pour cette requête. Les clients peuvent
demander le service récursif à n'importe quel serveur de noms, bien que ce service ne
puisse leur être fourni que par les serveurs qui auront déjà marqué leur bit RA, ou des
serveurs qui auront donné leur accord pour ce service par une négociation propriétaire
ou tout autre moyen hors du champ du protocole Dns.
5GTEL – 2015/2016 31
NORME ET PROTOCOLE
Le mode récursif est mis en œuvre lorsqu'une requête arrive avec un bit RD marqué sur un
serveur annonçant disposer de ce service, le client peut vérifier si le mode récursif a été utilisé
en constatant que les deux bits Ra et Rd ont été marqués dans la réponse.
Notez que le serveur de noms ne doit pas utiliser le service récursif s'il n'a pas été
explicitement demandé par un bit RD, car cela interfère avec la maintenance des serveurs de
noms et de leurs bases de données. Lorsque le service récursif est demandé et est disponible,
la réponse récursive à une requête doit être l'une des suivantes :
- La réponse à la requête, éventuellement préfacée par un ou plusieurs RR CNAME qui
indiquent les alias trouvés pendant la recherche de la réponse.
- Une erreur de nom indiquant que le nom demandé n'existe pas. Celle-ci peut inclure
des RR CNAME qui indiquent que la requête originale pointait l'alias d'un nom qui
n'existe pas.
- Une indication d'erreur temporaire.
Si le service récursif n'est pas requis, ou n'est pas disponible, la réponse non-récursive devra
être l'une des suivantes :
• Une réponse d'erreur "autorisée" indiquant que le nom n'existe pas.
• Une indication temporaire d'erreur.
• Une combinaison :
- Des RR qui répondent à la question, avec indication si les données sont extraites
d'une zone ou d'un cache.
- D'une référence à un serveur de noms qui gère une zone plus "proche" du nom
demandé que le serveur qui a été contacté.
• Les RR que le serveur de nom pense être utile au requérant pour continuer sa
recherche.
4.6.7. Les Requêtes inverses
Dans le cas d'une requête inverse, le solveur envoie une demande à un serveur de noms afin
que celui-ci renvoie le nom d'hôte associé à une adresse Ip connue. C'est utile surtout pour
5GTEL – 2015/2016 32
NORME ET PROTOCOLE
des questions de sécurité, pour savoir avec qui on échange. La mise en place de la résolution
inverse est un peu plus compliquée, car l'adressage par nom est basé sur la notion de domaine
qui souvent n'a rien à voir avec la structure des adresses Ip. Par conséquent, seule une
recherche approfondie portant sur tous les domaines peut garantir l'obtention d'une réponse
exacte. Deux moyens existent pour convertir une adresse IP en nom d'hôte : l'usage de
requêtes Dns inversées (Au sens Opcode=Iquery où Iquery = 1) ou les requêtes Dns de type
Ptr (Classe IN et Opcode=Query).
En effet, dans le premier cas, on envoie un message Dns contenant une réponse et on
demande toutes les questions pouvant conduire à cette réponse, alors que les requêtes Ptr
posent la question de façon explicite : Qui est l'adresse a.b.c.d ?
Une requête Dns inversée a la particularité d'avoir le champ Question vide, et de contenir une
entrée dans le champ Answer. Pour que le serveur Dns comprenne le sens de la requête, le
champ Opcode des en-têtes du message Dns doit être à la valeur Iquery. Voici une
représentation extraite de la Rfc 1035 :
Header OPCODE=IQUERY, ID=997
Question "EMPTY"
Answer "ANYNAME" A IN 10.1.0.52
Authotity "EMPTY"
Additionnal "EMPTY"
Tableau 7: Représentation d'une requête inverse.
Pour répondre aux requêtes inverses en évitant des recherches exhaustives dans tous les
domaines, un domaine spécial appelé in-addr.arpa a été créé. Une fois le domaine in-
addr.arpa construit, des enregistrements de ressources spéciaux sont ajoutés pour associer
les adresses IP aux noms d'hôte qui leur correspondent. Il s'agit des enregistrements pointeurs
(PTR), ou enregistrements de références. Par exemple pour connaître le nom de la machine
dont l'adresse est 137.194.206.1, on envoie une requête dont la question contient
QNAME=1.206.194.137.IN-ADDR.ARPA.
5GTEL – 2015/2016 33
NORME ET PROTOCOLE
5. La sécurité
5.1. Fragilité du DNS
Sans le Dns, la majorité des applications d'Internet s'arrêtent! De plus le DNS est souvent la
cible favorite des dénis de service (Dos) des pirates. Il y a aussi un exemple simple avec le
système de requêtes inversées vu précédemment qui entraîne une fuite d'information (ceci
représentant la partie découverte de l'attaque). Jusqu'ici, nous n'avons utilisés les requêtes
Dns inversées que pour faire la correspondance entre une adresse Ip et l'hostname associé
(Requête de classe IN et de type A). Or, nous pouvons faire des recherches inversées sur
d'autres types de ressources. Par exemple, nous pourrions émettre une requête inverse au
sujet des champs HINFO1 pour se chercher toutes les machines tournant sous une version
vulnérable d'un certain système d'exploitation. En effet, le champs Hinfo est sensé contenir le
type et version du Système d'Exploitation de la machine.
5.2. Sécurisation du DNS
Les normes de sécurisation du Dns portent sur la certification de l'origine des données,
l'authentification des transactions et des requêtes. Elles ne portent pas sur la confidentialité
des informations : les données échangées ne sont pas chiffrées avant d'être transportées par
le réseau et n'apporte aucune protection aux en-têtes des messages Dns, ou aux trames de
commandes (requêtes Dns).
La sécurisation du Dns doit assurer l'authentification d'une transaction, c'est à dire que le
Resolver reçoit une réponse provenant bien du serveur à qui il a envoyé une requête, qu'il
s'agit de la réponse correspondant effectivement à sa requête, que la trame n'a pas été
"diddled" (dupé) lors de son transport par le réseau.
L'authentification de transaction est assurée par le rajout d'un "Enregistrement de Signature"
(SIG RR) à la fin de la trame de réponse. La signature est créée à partir d'une concaténation
entre la réponse du serveur et la requête du client. La clef privée utilisée pour la signature
appartient au serveur qui émet le message signé, et non à la zone. Les clefs publiques utilisées
dans les mécanismes de sécurisation du Dns sont contenues dans des "Enregistrements de
Clefs" (Key RR) stockés dans la base de données du Dns. Ces clefs publiques peuvent être
5GTEL – 2015/2016 34
NORME ET PROTOCOLE
destinées à une zone, à un host ou autre. Un KEY RR est authentifié par un SIG RR comme
n'importe quel autre enregistrement.
II. SMTP
1. DEFINITION
Simple Mail Transfer Protocol (SMTP, littéralement « protocole simple de transfert de
courrier ») est un protocole de communication utilisé pour transférer le courrier électronique
(courriel) vers les serveurs de messagerie électronique.
2. Introduction Au Courrier Electronique
Le courrier électronique a toujours existé depuis le début de l'Internet. Il a été
l’application le plus populaire quand l'Internet venait de voir le jour [Segaller 1,998]. Il est
devenu de plus en plus élaboré et puissants au fil des années. Il reste l'un des applications les
plus importantes et utilisées de Internet.
Comme avec le courrier postal ordinaire, e-mail est une moyenne de communication
asynchrone. Les individus envoi et lire les messages quand il est commode pour eux, sans avoir
à coordonner avec les horaires d'autres personnes. En contraste avec le courrier postal, le
courrier électronique est rapide, facile à distribuer, et peu coûteux. L’e-mail modern a de
nombreuses fonctionnalités puissantes, y compris les messages avec pièces jointes, des
hyperliens, au format HTML et photos intégrées.
Dans cette section, nous examinons les protocoles de couche application qui sont au cœur de
l'Internet e-mail. Mais avant de sauter dans une discussion approfondie de ces protocoles,
nous allons prendre un aperçu du système de messagerie Internet et de ses principales
composantes.
Le figure ci-dessous présente une vue fonctionnel du système de messagerie Internet. Nous
voyons de ce schéma qu'il a trois grandes composantes: les agents utilisateurs (User Agent en
anglais), serveurs de messagerie (Mail Servers en anglais), et le
5GTEL – 2015/2016 35
NORME ET PROTOCOLE
Simple Mail Transfer Protocol (SMTP).
Nous décrivons maintenant chacune de ces composantes dans le contexte d'un expéditeur,
Alice, qui envoie un message e-mail à un destinataire, Bob.
Les User Agent, UA (agents d’utilisateurs) permettent aux utilisateurs de lire, répondre,
transférer, enregistrer et composer des messages. Microsoft Outlook et Apple Mail sont des
exemples d'agents utilisateurs pour l’e-mail.
Quand Alice fini de composer son message, son UA envoie le message à son serveur de
messagerie, où le message est placé dans le message sortant du serveur de messagerie la file
Figure 10: Système de messagerie Internet.
5GTEL – 2015/2016 36
NORME ET PROTOCOLE
d'attente. Quand Bob veut lire un message, son agent utilisateur récupère le message à partir
de sa boîte aux lettres dans son serveur de messagerie.
Les serveurs de messagerie forment le noyau de l'infrastructure d’e-mail. Chaque destinataire,
tel que Bob, a une boîte aux lettres qui se trouve dans l'un des serveurs de messagerie. La
boîte aux lettres de Bob gère et maintient les messages qui ont été envoyés à lui. Un message
typique commence son voyage dans l'agent utilisateur de l'expéditeur, se déplace vers le
serveur mail de l'expéditeur, et voyages vers le serveur de messagerie du destinataire, où il
est déposé dans la boîte aux lettres du destinataire.
Quand Bob veut accéder aux messages dans sa boîte aux lettres, le serveur de messagerie
contenant sa boîte aux lettres authentifie Bob (avec les noms d'utilisateur et mots de passe).
Le serveur de messagerie de l’expéditeur Alice doit aussi faire face à des défaillances dans le
serveur de messagerie de Bob. Si le serveur d'Alice ne peut pas livrer le courrier au serveur de
Bob, le serveur d'Alice détient le message dans un message la file d'attente et les tentatives
de transférer le message plus tard. Retente sont souvent effectuées chaque 30 minutes ou
plus; en l'absence de succès après plusieurs jours, le serveur supprime le message et avise
l'expéditeur (Alice) avec un message e-mail.
SMTP est un protocole de couche application pour le courrier électronique Internet. Il utilise
le service de transfert de données fiable de TCP pour transférer le courrier à partir du serveur
mail de l'expéditeur pour le serveur de messagerie du destinataire. Comme avec la plupart
des protocoles de la couche application, SMTP a deux faces: un côté client, qui exécute sur le
serveur de messagerie de l'expéditeur, et un côté serveur, qui exécute sur le serveur de
messagerie du destinataire. Les côtés client et le serveur de SMTP existent sur chaque serveur
de messagerie. Quand un serveur de messagerie envoie un message à un autre les serveurs
de messagerie, il agit comme un client SMTP. Quand un serveur de messagerie reçoit le
courrier des autres les serveurs de messagerie, il agit comme un serveur SMTP
Les User Agent, UA (agents d’utilisateurs) permettent aux utilisateurs de lire, répondre,
transférer, enregistrer et composer des messages. Microsoft Outlook et Apple Mail sont des
exemples d'agents utilisateurs pour l’e-mail.
5GTEL – 2015/2016 37
NORME ET PROTOCOLE
Quand Alice fini de composer son message, son UA envoie le message à son serveur de
messagerie, où le message est placé dans le message sortant du serveur de messagerie la file
d'attente. Quand Bob veut lire un message, son agent utilisateur récupère le message à partir
de sa boîte aux lettres dans son serveur de messagerie.
Les serveurs de messagerie forment le noyau de l'infrastructure d’e-mail. Chaque destinataire,
tel que Bob, a une boîte aux lettres qui se trouve dans l'un des serveurs de messagerie. La
boîte aux lettres de Bob gère et maintient les messages qui ont été envoyés à lui. Un message
typique commence son voyage dans l'agent utilisateur de l'expéditeur, se déplace vers le
serveur mail de l'expéditeur, et voyages vers le serveur de messagerie du destinataire, où il
est déposé dans la boîte aux lettres du destinataire.
Quand Bob veut accéder aux messages dans sa boîte aux lettres, le serveur de messagerie
contenant sa boîte aux lettres authentifie Bob (avec les noms d'utilisateur et mots de passe).
Le serveur de messagerie de l’expéditeur Alice doit aussi faire face à des défaillances dans le
serveur de messagerie de Bob. Si le serveur d'Alice ne peut pas livrer le courrier au serveur de
Bob, le serveur d'Alice détient le message dans un message la file d'attente et les tentatives
de transférer le message plus tard. Retente sont souvent effectuées chaque 30 minutes ou
plus; en l'absence de succès après plusieurs jours, le serveur supprime le message et avise
l'expéditeur (Alice) avec un message e-mail.
SMTP est un protocole de couche application pour le courrier électronique Internet. Il utilise
le service de transfert de données fiable de TCP pour transférer le courrier à partir du serveur
mail de l'expéditeur pour le serveur de messagerie du destinataire. Comme avec la plupart
des protocoles de la couche application, SMTP a deux faces: un côté client, qui exécute sur le
serveur de messagerie de l'expéditeur, et un côté serveur, qui exécute sur le serveur de
messagerie du destinataire. Les côtés client et le serveur de SMTP existent sur chaque serveur
de messagerie. Quand un serveur de messagerie envoie un message à un autre les serveurs
de messagerie, il agit comme un client SMTP. Quand un serveur de messagerie reçoit le
courrier des autres les serveurs de messagerie, il agit comme un serveur SMTP.
5GTEL – 2015/2016 38
NORME ET PROTOCOLE
3. Architecture modulaire d’un système de messagerie Internet
- Un usager compose, avec l’aide de son client de messagerie (MUA-Mail User Agent)
un message.
- Le message est transmis au MTA (Mail Transfer Agent) de l’usager (son serveur de
messagerie en SMTP).
- Le message est transmis au serveur de messagerie du destinataire (SMTP).
- Le serveur transmet le message à un agent: notion d’agent MDA ‘Mail Delivery Agent’.
- Le MDA stocke le courrier dans la boite à lettres du destinataire.
- Sur requête du destinataire dans le cadre d’un protocole de relève POP ou IMAP les
messages sont extraits de la boite à lettre par un agent: MAA (‘Mail Access Agent’).
- Les messages sont transmis au client de messagerie utilisateur (protocoles POP ou
IMAP). Ils sont stockés dans des boites à lettre client.
Figure 11: Architecture modulaire d’un système de messagerie Internet
5GTEL – 2015/2016 39
NORME ET PROTOCOLE
- Le destinataire consulte ses messages en utilisant son client de messagerie (MUA).
4. Principes d'envoi
Le transfert de messages entre serveurs de messagerie électronique se fait généralement sur
le port 25 qui est le port standard enregistré auprès de l'IANA. Les serveurs utilisent les
enregistrements MX des serveurs DNS pour acheminer le courrier.
Les clients de messagerie utilisaient aussi le port 25 (SMTP) pour soumettre des messages en
utilisant le protocole SMTP. Mais la nécessité de mieux contrôler les envois des clients, en
particulier par l'authentification, a conduit à l'attribution du port 587 (submission).
Les administrateurs de serveur peuvent choisir si les clients utilisent le port TCP 25 (SMTP) ou
le port 587 (soumission), tel que formalisé dans la RFC 6409 (RFC 2476 précédemment), pour
relayer le courrier sortant vers un serveur de messagerie. Les spécifications et de nombreux
serveurs supportent les deux. Bien que certains serveurs prennent en charge le port 465
Figure 12: Principe d'envoi via SMTP
5GTEL – 2015/2016 40
NORME ET PROTOCOLE
(historique) pour le SMTP sécurisé en violation des spécifications, il est préférable d'utiliser
les ports standards et les commandes ESMTP (Extended SMTP) standard selon la RFC 3207, si
une session sécurisée doit être utilisée entre le client et le serveur.
Pour illustrer le fonctionnement de base de SMTP, nous allons marcher à travers un scénario
commun. Supposons qu'Alice souhaite envoyer un message Bob ASCII simple.
1. Alice invoque son agent utilisateur pour le courrier électronique, fournit l'adresse e-mail de
Bob (pour Ainsi, [email protected]), compose un message, et charge l'agent utilisateur
pour envoyer le message.
2. agent utilisateur d'Alice envoie le message à son serveur de messagerie, où il est placé dans
un Message Queue.
3. Le côté client du protocole SMTP, fonctionnant sur le serveur de messagerie d'Alice, voit
dans le message la file de messages. Il ouvre une connexion TCP vers un serveur SMTP,
fonctionnant sur Le serveur de messagerie de Bob.
4. Après quelques poignées de main SMTP initiale, le client SMTP envoie le message d'Alice
dans la connexion TCP.
5. A le serveur de messagerie de Bob, le côté serveur SMTP reçoit le message. Bob
serveur de messagerie met alors le message dans la boîte aux lettres de Bob.
6. Bob invoque son agent utilisateur pour lire le message à sa convenance.
Le scénario est résumé dans la figure ci –dessous:
5GTEL – 2015/2016 41
NORME ET PROTOCOLE
Il est important d'observer que SMTP n’utilise pas normalement une poste intermédiaire
serveurs pour l'envoi de courrier, même lorsque les deux serveurs de messagerie sont situés
aux extrémités du monde. Si le serveur d'Alice est à Hong Kong et le serveur de Bob est à St.
Louis, la connexion TCP est une connexion directe entre les serveurs de Hong Kong et de Saint-
Louis. En particulier, si le serveur de messagerie de Bob est en baisse, le message reste dans
le serveur de messagerie de Alice et attend une nouvelle tentative; ses messages ne sont pas
placés dans un certain serveur intermédiaire mail.
Prenons maintenant un regard de plus près comment SMTP transfère un message à partir d'un
serveur de messagerie d'envoi à un serveur de messagerie de réception. Nous allons voir que
le protocole SMTP a de nombreuses similitudes avec les protocoles qui sont utilisés pour
l'interaction humaine en face-à-face.
Tout d'abord, le client SMTP (en cours d'exécution sur l'hôte du serveur de messagerie
d'envoi) demande à TCP d’établir une connexion sur le port 25 du serveur SMTP (fonctionnant
sur l'e-mail de réception hôte du serveur). Si le serveur est en panne, le client essaie à nouveau
plus tard. Une fois que cette connexion est établie, le serveur et le client exercent une forme
de « handshaking » au niveau de la couche application (poignées de main), tout comme les
Figure 13: Principe d'envoi d'un Mail.
5GTEL – 2015/2016 42
NORME ET PROTOCOLE
humains se présentent souvent avant le transfert de l'information d'un à l'autre, les clients
SMTP et les serveurs se présentent avant le transfert de l'information. Pendant cette phase
handshaking SMTP, le SMTP client indique l'adresse e-mail de l'expéditeur (la personne qui a
généré le message) et l'adresse e-mail du destinataire. Une fois cette étape terminé, le client
envoie le message.
SMTP peut compter sur le service de transfert de données fiable de TCP de faire passer le
message au serveur sans erreurs. Le client répète ensuite ce processus sur la même Connexion
TCP si elle a d'autres messages à envoyer au serveur; sinon, il instruit TCP de fermer la
connexion. Jetons maintenant un cours d’œil à un exemple de messages échangés entre un
client SMTP (C) et un serveur SMTP (S). Le nom d'hôte du client est crepes.fr et le nom d'hôte
du serveur est hamburger.edu. Les Lignes de texte ASCII préfacé par C: sont exactement les
lignes envoyées par le client dans son Socket TCP, et les lignes de texte ASCII préfacé avec S:
sont exactement les lignes le serveur envoie dans son socket TCP. La transcription suivante
commence dès que le Connexion TCP est établie.
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Bonjour crepes.fr, heureux de vous rencontrer
C: MAIL FROM: <[email protected]>
S: 250 [email protected] ... ok expéditeur
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... ok bénéficiaire
C: DATA
S: 354 Entrez courrier, avec fin sur une ligne par lui-même "."
C: Vous aimez le ketchup?
C: Que diriez-vous des cornichons?
C:.
S: 250 message accepté pour la livraison
C: QUIT
S: connexion de fermeture de 221 hamburger.edu
5GTEL – 2015/2016 43
NORME ET PROTOCOLE
Dans l'exemple ci-dessus, le client envoie un message ("Aimez-vous le ketchup?
Que diriez-vous des cornichons? ") à partir du serveur de messagerie crepes.fr au courrier
électronique du serveur hamburger.edu.
Dans le cadre du dialogue, le client a émis cinq commandes: HELO (une abréviation pour
BONJOUR), MAIL FROM, RCPT TO, DATA et QUIT. Ces commandes sont explicites.
Le client envoie également une ligne constituée d'une seule période, ce qui indique la fin du
message au serveur. (Dans le jargon ASCII, chaque message se termine par CRLF.CRLF, où CR
et LF représentent « carriage return » et « line feed », respectivement.) Le serveur répond à
chaque commande, chaque réponse ayant un code de réponse et certains (optionnel) sont
expliquer en anglais. Nous mentionnons ici que SMTP utilise les connexions persistantes: Si le
serveur de messagerie d'envoi a plusieurs messages à envoyer au même serveur de
messagerie de réception, il peut envoyer tous les messages
sur la même connexion TCP. Pour chaque message, le client commence le processus avec une
nouvelle MAIL FROM: crepes.fr, désigne la fin de message avec le point(.), et envoi QUIT
seulement après que tous les messages ont été envoyés.
Rappelons qu’il est fortement recommandé que vous utilisez Telnet pour mener un dialogue
direct avec un serveur SMTP. Pour ce faire, envoi; telnet serverName 25
Où ServerName est le nom d'un serveur de messagerie local. Lorsque vous faites cela, une
connexion TCP est établir tout simplement entre votre hôte local et le serveur de messagerie.
Après avoir tapé cette ligne, vous devez immédiatement recevoir la réponse 220 du serveur.
Puis, émettre des commandes SMTP HELO, MAIL FROM, RCPT TO, DATA, CRLF.CRLF, et QUIT
aux moments appropriés.
5. Comparaison avec HTTP
Voyons maintenant une comparaison brève entre SMTP avec HTTP. Les deux protocoles sont
utilisés pour transférer les fichiers d'un hôte à un autre: HTTP transfert de fichiers (également
appelées objets) à partir d'un site Web serveur à un client Web (généralement un navigateur);
SMTP transfert de fichiers (généralement les courriers électroniques) d'un serveur de
messagerie à un autre serveur de messagerie. Lors de transfert des fichiers, HTTP et SMTP
5GTEL – 2015/2016 44
NORME ET PROTOCOLE
utilisent des connexions persistantes. Ainsi, les deux protocoles ont des caractéristiques
communes. Cependant, il y a des différences importantes.
• Premièrement, HTTP est principalement un protocole de traction; quelqu'un charge
des informations sur un serveur Web et les utilisateurs utilisent le protocole HTTP
pour tirer les informations à partir du serveur à leur convenance. En particulier, la
connexion TCP est initiée par la machine qui souhaite recevoir le fichier. D'autre part,
SMTP est essentiellement un protocole-de serveur d'envoi dit ‘push protocol’; il
pousse le fichier vers le serveur de messagerie de réception. En particulier, la
connexion TCP est initiée par la machine qui veut envoyer le fichier. Ceci est illustré
dans la figure ci-dessous:
• Une deuxième différence, ce qui nous avons fait allusion plus tôt, est que SMTP
requiert chaque message, y compris le corps de chaque message, à être au format
ASCII 7 bits. Si le message contient des caractères qui ne sont pas ASCII 7 bits (par
exemple, les caractères accentués en français) ou contient des données binaires
(comme un fichier image), alors le
message doit être codé en ASCII 7 bits. Données HTTP ne l'impose pas restriction.
Figure 14: Processus détaillé d'envoi en comparaison avec le protocole HTTP.
5GTEL – 2015/2016 45
NORME ET PROTOCOLE
• Une troisième différence importante concerne la façon dont un document constitué
de texte et images (ainsi éventuellement d'autres types de médias) est manipulé.
D’une part, HTTP encapsule chaque objet dans son propre message de réponse HTTP
et d’autre part la messagerie Internet place tous les objets du message dans un seul
message.
6. Format du courrier électronique
Quand Alice écrit une lettre par courrier postal ordinaire à Bob, elle peut inclure toutes sortes
de informations d'en-tête périphérique en haut de la lettre, comme l'adresse de Bob, son
propre adresse de retour, et la date. De même, quand un message e-mail est envoyé d'une
personne à une autre, un en-tête contenant des informations périphérique précède le corps
du message lui-même. Cette information périphérique est contenue dans une série de lignes
d'en-tête, qui sont définies dans la norme RFC 5322. Les lignes d'en-tête et le corps du
message sont séparés par une ligne blanche (c’est à dire, par CRLF). RFC 5322 spécifie le format
exact des lignes d'en-tête de courrier ainsi que leurs interprétations sémantiques. Comme
avec HTTP, chaque ligne d’en-tête contient un texte lisible, constitué d'un mot-clé suivi par un
deux-points, (:), suivi par une valeur. Certains mots-clés sont tenus (doit toujours apparaitre)
et d'autres sont optionnels. Chaque en-tête doit avoir une ligne d’instruction From: et une
ligne d’instruction TO; un en-tête peut inclure une ligne Objet: ainsi que d'autres lignes d'en-
tête selon le besoin. Il est important de noter que
ces lignes d'en-tête sont différents des commandes SMTP que nous avons étudiés dans la
section précédente (même si elles contiennent certains mots courants tels que «FROM» et
«TO»). Il s’agissait des commandes de protocole de prise de contact SMTP. Les lignes d'en-
tête examiné dans cette section font partie du message électronique lui-même. Un en-tête de
message typique ressemble à ceci:
FROM: [email protected]
Subject: à la recherche du sens de la vie.
Après l'en-tête du message, une ligne blanche suit; puis le corps du message (en ASCII) suit.
Vous devriez utiliser Telnet pour envoyer un message à un serveur de messagerie qui contient
une certaine ligne d'en-tête, y compris la ligne Objet: d'en-tête. Pour ce faire, question telnet
serverName 25, tel que discuté à la section précédente.
5GTEL – 2015/2016 46
NORME ET PROTOCOLE
7. Les Différents Types De Requêtes Client SMTP
Chaque requête (un message du protocole SMTP) correspond à une ligne de texte terminée
par CRLF (‘ carriage return ’ code 13 et ‘ line feed code ’ 10).
1. HELO<SP> <domaine><CRLF> L’ouverture de session entre le client et le serveur (le message
contient le nom de domaine FQDN du client).
2. MAIL <SP> FROM: <route-retour><CRLF> Définit l'adresse mail de l'émetteur (utilisé pour
le retour éventuel d'erreurs).
3. "RCPT <SP> TO: <route-aller><CRLF> Définit l'adresse d’un destinataire (le routage du
courrier est possible en donnant une liste de MTA à visiter : routage par la
source @Hote_1,@ Hote_2:usager@ Hote_3)
4. "DATA <CRLF> Définit l'enveloppe (l'entête) et le corps (le texte) du message.
5. "QUIT<CRLF> Termine un courrier.
6. RSET : Commande pour abandonner le courrier en cours de transmission et restaurer la
connexion.
7. "VRFY : Commande pour vérifier une adresse de destinataire sans lui transmettre de
courrier (utilisable pour déterminer la cause d’un problème).
8. "NOOP : Commande vide qui oblige simplement le serveur à répondre 200 OK.
9. "EXPN : Expansion d’une liste de diffusion (‘mailing list’).
10. "TURN : Inversion des rôles client et serveur pour envoyer du courrier dans l’autre sens
sans ouvrir une nouvelle connexion TCP.
8. Différents Types De Réponses Serveur
Code réponse (trois chiffres décimaux) et explication textuelle. xyz <SP> <texte> <CRLF>
xyz: Type de réponse en numérique
1yz: Positif, à suivre
2yz: Requête satisfaite
5yz: Réponse négative
5GTEL – 2015/2016 47
NORME ET PROTOCOLE
x0z: Syntaxe
x2z: Etat de la connexion
x5z: Etat du système de messagerie texte: Explications en clair
En cas de problème dans un courrier, interpréter le code d’erreur et son explication. Si le
problème est sérieux, faire suivre à l’administrateur de courrier (postmaster).
Une liste des principales réponses
1. 211 System status, or system help reply
2. 214 Help message [Information on how to use]
3. 220 <domain> Service ready
4. 221 <domain> Service closing transmission channel
5. 250 Requested mail action okay, completed
6. 251 User not local; will forward to <forward-path>
7. 354 Start mail input; end with <CRLF>.<CRLF>
8. 421 <domain> Service not available, closing channel
9. 451 Requested action aborted: local error in processing
10. 452 Requested action not taken: insufficient storage
11. 500 Syntax error, command unrecognized
12. 501 Syntax error in parameters or arguments
13. 502 Command not implemented
14. 503 Bad sequence of commands
15. 504 Command parameter not implemented
16. 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access]
17. 551 User not local; please try <forward-path>
18. 552 Requested mail action aborted: exceeded storage allocation
19. 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax
incorrect]
20. 554 Transaction failed
9. Quelques Spécificités Du Protocol SMTP
Le SMTP commence à être largement utilisé au début des années 1980. Il est alors un
complément à l'UUCP, celui-ci étant plus adapté pour le transfert de courriers électroniques
5GTEL – 2015/2016 48
NORME ET PROTOCOLE
entre des machines dont l'interconnexion est intermittente. Le SMTP, de son côté, fonctionne
mieux lorsque les machines qui envoient et reçoivent les messages sont interconnectées en
permanence.
• SMTP est un protocole assez simple (comme son nom l'indique). On commence par
spécifier l'expéditeur du message, puis le ou les destinataires d'un message, 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.
• SMTP utilise TCP pour le transfert des données.
• SMTP ne permet pas de récupérer à distance des courriels arrivés dans une boîte aux
lettres sur un serveur. Les standards Post Office Protocol (POP) et IMAP ont été créés
dans ce but.
• Le logiciel Sendmail est l'un des premiers, sinon le premier serveur de messagerie
électronique à utilis1er SMTP. Depuis, la plupart des clients de messagerie peuvent
utiliser SMTP pour envoyer les messages. Certains nouveaux serveurs sont apparus,
comme Postfix, Qmail de Daniel J. Bernstein, Exim et Exchange de Microsoft.
• Comme le protocole utilisait du texte en ASCII (7 bits), il ne fonctionnait pas pour
l'envoi de n'importe quels octets dans des fichiers binaires. Pour pallier ce problème,
des standards comme MIME ont été développés pour permettre le codage des fichiers
binaires au travers de SMTP. Aujourd'hui, la plupart des serveurs SMTP acceptent le
MIME sur 8 bits, ce qui permet de transférer des fichiers binaires presque aussi
facilement que du texte simple.
III. LE PROTOCOLE IMAP
1. DEFINITION
IMAP signifie Internet Message Access Protocol (protocole internet d’accès aux messages).
Ce protocole permet comme son nom l’indique d’accéder aux messages. (Ce n’est pas un
protocole de relève de message). Alors quelle est la différence ?
5GTEL – 2015/2016 49
NORME ET PROTOCOLE
2. LE PRINCIPE D’IMAP
• vous prenez le courrier
• vous lisez le courrier directement sur place,
• vous faites le tri,
• vous jetez les mails lus que vous ne souhaitez pas garder (ou les pubs)
• vous remettez les courriers que vous voulez garder dans la boite aux lettres,
• Après votre passage, votre boite aux lettres n’est pas vide, mais le courrier est trié.
Ce protocole est de plus en plus utilisé, pourquoi ?
Et bien tout simplement, parce qu’en laissant les mails sur le serveur, on peut y avoir accès de
n’importe où (ordinateur à la maison, Webmail en vacances, smartphone, tablette, …).
L’avantage, c’est que quel que soit l’équipement utilisé pour voir les mails, vous voyez la
même chose, car il ne s’agit que d’une vue du contenu du serveur.
Figure 15: Avantage de laisser les messages sur le serveur.
3. LES AVANTAGES D’IMAP
• Le lieu est unique : c’est toujours dans la boite.
• Simplicité : Il n’y a pas à chercher où est le courrier : tout est toujours dans la boite.
• Pas de risque de perte lié à un problème chez vous (feu, inondation).
5GTEL – 2015/2016 50
NORME ET PROTOCOLE
4. LES INCONVENIENTS D’IMAP
• Il faut toujours aller à la boite
• Il faut que la boite soit bien fermée et sécurisée, sinon tout le monde peut accéder à tout votre
courrier.
IV. LE PROTOCOLE POP
1. DEFINITION
Le POP (Post Office Protocol littéralement le protocole du bureau de poste) est un protocole
standard, qui permet de réceptionner des emails situés sur le serveur de messagerie.
2. LE PRINCIPE DE POP
Si le protocole défini dans le serveur de messagerie est le POP:
• Votre client de messagerie se connecte au serveur de messagerie.
• Il copie les nouveaux messages présents sur la boite mail sur le disque dur de votre
ordinateur.
• Il efface les messages du serveur après réception sur l'ordinateur.
Le protocole POP vous permet de vous connecter brièvement à Internet pour copier vos
messages sur votre ordinateur. La connexion Internet peut alors être interrompue, la lecture
et la gestion des emails se fait hors connexion (off-line).
3. AVANTAGES DU PROTOCOLE POP
• Votre boite aux lettres est vidée à chaque fois.
• Vous lisez votre courrier tranquillement chez vous, et vous n’êtes pas devant votre
boite aux lettres.
• Les messages sont chez vous, vous les stockez où vous voulez dans votre domicile.
5GTEL – 2015/2016 51
NORME ET PROTOCOLE
4. INCONVENIENTS DU PROTOCOLE POP :
• Il vous faut un autre emplacement chez vous pour conserver les courriers que
vous voulez conserver.
• Si vous êtes dehors, vous êtes obligé de repasser chez vous pour lire votre
courrier.
• Si vous avez un problème chez vous (feu, inondation, …) : vous perdez tout.
5. Le protocole POP3 :
Le protocole POP3 est une évolution du protocole pop. Cette version permet aux logiciels de
relève de mails de fonctionner comme de l’IMAP. C’est une évolution importante, mais il faut
penser à l’indiquer au logiciel de relève de mails
5GTEL – 2015/2016 52
NORME ET PROTOCOLE
6. Quelques commandes :
Tableau 8: Quelques commandes pour POP.
5GTEL – 2015/2016 53
NORME ET PROTOCOLE
Figure 16: Différence entre POP et IMAP
7. Différences entre POP et IMAP : Lequel choisir entre POP et IMAP
Vous venez de le voir, le fonctionnement des protocoles était différent à l’origine mais
maintenant le fonctionnement de POP3 peut ressembler beaucoup à celui d’IMAP si on laisse
les messages sur le serveur.
Toutefois, le protocole IMAP est nativement parfaitement adapté aux relèves multiples
(ordinateurs, smartphone, tablettes, …). De plus il fonctionne en mode bi-directionnel.
Si vous avez le choix, je vous conseille d’utiliser le protocole IMAP.
5GTEL – 2015/2016 54
NORME ET PROTOCOLE
V. MIME
1. Definition :
un standard Internet est une spécification technique normalisée par l'IETF (Internet
Engineering Task Force ) et applicable au réseau Internet.
Les requests for comments (RFC), littéralement « demande de commentaires », sont
une série numérotée de documents officiels décrivant les aspects techniques d'Internet, ou
de différents matériels informatiques (routeurs, serveur DHCP). Peu de RFC sont des
standards, mais tous les documents publiés par l'IETF sont des RFC.
Multipurpose Internet Mail Extensions (MIME) ou Extensions multifonctions du
courrier Internet est un standard internet qui étend le format de données des courriels pour
supporter des textes en différents codage de caractères autres que l'ASCII, des contenus non
textuels, des contenus multiples, et des informations d'en-tête en d'autres codages que
l'ASCII. Les courriels étant généralement envoyés via le protocole SMTP au format MIME, ces
courriels sont souvent appelés courriels SMTP/MIME.
À l'origine, SMTP avait été prévu pour ne transférer que des fichiers textes (codés en
ASCII). Avec l'apparition du multimédia et l'utilisation croissante des applications
bureautiques, le besoin s'est fait sentir d'échanger, en plus des fichiers textes, des fichiers
binaires (format des applications bureautiques, images, sons, fichiers compressés).
Les types de contenus définis par le standard MIME peuvent être utilisés à d'autres fins
que l'envoi de courriels, dans les protocoles de communication comme le HTTP pour le World
Wide Web.
2. Présentation et généralité
Le protocole de base de transmission de courriels, SMTP, ne supporte que les caractères ASCII
7-bits. Cela limite les courriels aux messages qui n'incluent que ces caractères, soit un petit
nombre de langages comme l'anglais. Les autres langages basés sur l'alphabet latin incluant
5GTEL – 2015/2016 55
NORME ET PROTOCOLE
des diacritiques ne sont pas supportés par l'ASCII 7-bits, ces messages ne peuvent donc pas
être correctement représentés dans des courriels basiques.
MIME définit des mécanismes pour l'envoi d'autre sortes d'informations dont des textes dans
des langages autres que l'anglais utilisant des codages de caractères autres que l'ASCII et des
données binaires comme des fichiers contenant des images, des sons, des films ou des
programmes informatiques. MIME est également un composant fondamental des protocoles
de communications comme HTTP, qui requièrent l'envoi de données dans le même contexte
que l'envoi de courriels, même si ces données ne sont pas des courriels. L'intégration ou
l'extraction des données au format MIME est généralement automatiquement effectuée par
le client de messagerie ou par le serveur de messagerie électronique quand le courriel est
envoyé ou reçu.
Le format de base des courriels est défini dans la RFC 2822 qui est une mise à jour de la RFC
822. Ces standards spécifient le format des en-têtes et du corps des courriels contenant du
texte, ainsi que les règles d'en-têtes générales comme "To:", "Subject:", "From:" ou "Date:".
MIME définit un ensemble d'attributs additionnels d'en-têtes de courriels pour le type de
contenu du message, et son codage. Le codage étant la façon de traduire en ASCII 7-bits, les
données 8 bits du message. MIME définit également des règles spécifiques pour encoder des
caractères non ASCII dans les en-têtes de messages, pour, par exemple, autoriser des
caractères accentués dans le sujet d'un courriel.
MIME est extensible. Sa définition inclut une méthode pour enregistrer de nouveaux types de
contenus ou d'autres valeurs d'attributs.
Un des autres buts explicites de la définition de MIME est de ne pas avoir à changer les
serveurs de messagerie électronique préexistants, et de permettre le fonctionnement correct
des courriels de base avec les clients préexistants. Ce but est réalisé par le fait que les attributs
de messages MIME sont optionnels et que le comportement par défaut est la création d'un
message textuel sans MIME qui peut être interprété correctement par un client.
5GTEL – 2015/2016 56
NORME ET PROTOCOLE
3. Structure d’une entête MIME
3.1. MIME-Version
La standard MIME est une extension des protocoles d'échanges de messages électroniques,
pour permettre aux applications de reconnaître un email MIME, le champ MIME-Version est
obligatoire dans l'entête. Aujourd'hui la seule version possible est 1.0.donc l'en-tête apparait
comme MIME-Version: 1.0
3.2. Content-Type
La présence de cet en-tête indique le type de média internet du contenu du message,
consistant en un type et un sous-type, par exemple : Content-Type: text/plain.Sa structure
générale est la suivante :
Content-Type : type/sous-type : [paramètres].
Les paramètres dépendent du type et du sous-type de message. Les champs sont ensuite suivis
d’une ligne blanche comme pour un e-mail standard, mais le corps utile du message ne débute
ici qu’avec la première ligne boundary.
Avec l'utilisation d'un type multipart, MIME permet aux messages d'avoir plusieurs parties
organisées sous forme d'une structure arborescente où les nœuds feuilles sont des contenus
non multipart et les nœuds internes sont de type multipart. Ce mécanisme supporte
notamment :
• les messages en texte simple avec text/plain (la valeur par défaut de l'en-tête Content-
Type:)
• le texte avec des pièces jointes (multipart/mixed avec une partie text/plain et d'autres
parties non textuelles). Un message MIME incluant un fichier joint indique
généralement le nom d'origine du fichier avec l'en-tête Content-disposition: donc le
type du fichier est identifié par le type MIME et son extension de nom de fichier
5GTEL – 2015/2016 57
NORME ET PROTOCOLE
• les contenus alternatifs : chaque message est envoyé avec plusieurs contenus (texte
simple et HTML par exemple), le receveur (ou son client de messagerie) choisit le
format sous lequel il veut visualiser le message.
Note : Voir en annexe un ensemble de types de contenus.
3.3. NContent-Transfer-Encoding
La spécification du MIME définit un ensemble de méthodes pour représenter des données
binaires sous forme de texte ASCII. L'en-tête MIME Content-Transfer-Encoding indique la
méthode utilisée. Comme méthodes on a :
• Appropriées pour l'usage avec le SMTP :
o 7bit - jusqu'à 998 octets par ligne dans la gamme 1...127 avec CR et LF (retour
chariot et défilement de ligne - codes 13 et 10 respectivement) autorisés
uniquement pour une fin de ligne CRLF. C'est la valeur par défaut.
o Quoted-Printable - utilisé pour encoder des séquences d'octets dans un
format qui satisfait les règles de l'encodage 7bit. Étudié pour être efficace et
lisible par un humain quand il est utilisé pour encoder des données
comportant majoritairement du texte avec des caractères ASCII avec
quelques caractères non ASCII.
o Base64 - utilisé pour encoder des données arbitraires dans une forme
satisfaisant les règles de l'encodage 7bit. Sa taille est fixe par rapport à la
taille des données initiales. Il est utilisé pour les données non textuelles ou
des textes à base non ASCII.
• Appropriées pour les serveurs SMTP qui supportent le transport 8BITMIME comme
extension SMTP :
o 8bit - jusqu'à 998 octets par ligne avec CR et LF (retour chariot et défilement
de ligne - codes 13 et 10 respectivement) autorisés uniquement pour une fin
de ligne CRLF.
• Non approprié avec SMTP :
5GTEL – 2015/2016 58
NORME ET PROTOCOLE
o binary - séquence quelconque d'octets. Non utilisable avec les courriels
SMTP.
Aucun encodage n'est spécialement spécifié pour l'envoi de données binaires arbitraires par
les transports SMTP avec l'extension 8BITMIME. base64 ou quoted-printable (avec leurs
inefficacités respectives) doivent être utilisées.
4. Notion d’encodages :
Les noms des en–têtes de messages et leurs valeurs sont toujours en caractères ASCII. Les
valeurs qui contiennent des données non ASCII doivent utiliser la syntaxe encoded-word de
MIME à la place des valeurs textuelles standards. Cette syntaxe utilise des chaines de
caractères ASCII aussi bien pour préciser l'encodage original des caractères (charset) que le
content-transfer-encoding utilisé pour faire correspondre les données du codage des
caractères aux caractères ASCII.
La forme est: "=?charset?encodage?texte?=".
• charset peut être n'importe quel jeu de caractères enregistré par l'IANA (Internet
Assigned Numbers Authority). Typiquement, c'est le même jeu d'encodage que le corps
du message.
• encodage peut être soit "Q" pour Q-encoding qui est similaire à l'encodage Quoted-
Printable ou "B" pour l'encodage Base64.
• texte est le texte encodé par le Q-encoding ou le base64.
Différence entre Q-encodage et quoted-printable
Les codes ASCII pour le point d'interrogation (?) et le signe égal (=) ne devraient pas être
représentés directement puisqu'ils sont utilisés pour délimiter les mots encodés. Le code ASCII
pour le caractère espace ne devrait pas être non plus utilisé car il peut provoquer des erreurs
sur les anciens encodeurs comme une séparation de mot non désirée. Pour rendre l'encodage
plus léger et plus aisé à lire, le caractère underscore (_) est utilisé pour représenter l'espace.
Par conséquent, le caractère underscore ne peut plus être représenté directement.
5GTEL – 2015/2016 59
NORME ET PROTOCOLE
L'utilisation de mots encodés dans certaines parties des en-têtes impose des restrictions sur
les caractères à représenter directement.
Par exemple, Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?= est interprété comme "Subject: ¡Hola,
señor!".
Le format des mots encodés n'est pas utilisé pour les noms des en-têtes (par exemple Subject).
Ces noms d'en-têtes sont toujours en anglais dans le message. Quand le message est visualisé
sur un client de courriels non anglophone, les noms d'en-têtes peuvent être traduits par le
client.
5. Notion de message à plusieurs parties : Multipart message
Un message MIME multi-partie contient une séparation dans l'en-tête "Content-type:". Cette
séparation, qui ne doit être présente dans aucune des autres parties, est placée entre les
parties et au début et à la fin du corps du message comme suit :
Figure 17: Corps du message (Multipart message)
5GTEL – 2015/2016 60
NORME ET PROTOCOLE
Chacune de ces parties consiste en sa propre en-tête de contenu (zéro, un ou plusieurs champs
d'en-tête Content-) et un corps. Des parties multiples peuvent être incluses dans d'autres
parties multiples avec pour chacune leur propre frontière (boundary) définit. Le champ
content-transfer-encoding d'un type à parties multiples doit être "7bit", "8bit" ou "binary"
pour éviter les problèmes de décodage des différentes couches de parties multiples. Le bloc
multi parties n'a pas de jeu de caractères, les caractères non ASCII dans les en-têtes sont
traités par le système des mots encodés et les corps peuvent avoir un jeu de caractères
spécifié approprié à leur contenu.
Notes :
• La zone se trouvant avant le premier séparateur est ignorée par les clients MIME.
Cette zone est généralement utilisée pour stocker un message à l'attention des client
ne supportant pas MIME.
• Le choix du séparateur de parties revient au programme client. Celui-ci doit le choisir
de façon à éviter toute collision avec le contenu des différents contenus.
Généralement, le séparateur est généré à partir d'une longue chaine de caractères
aléatoires.
6. Sous-types
Le standard MIME définit plusieurs sous types de messages multiparties pour en spécifier la
nature des différentes parties du message et leurs relations avec les autres parties. Le sous
type est spécifié par l'en-tête Content-type du message englobant. Par exemple, un message
MIME multi parties utilisant le sous-type digest devrait avoir son en-tête Content-Type à
multipart/digest. La RFC définit initialement quatre sous types : mixed, alternate, digest et
parallel. Une application qui implémente le minimum de cette spécification doit supporter les
types mixed et digest, les autres sous types sont optionnels. Les sous types additionnels,
comme signed ou form-data ont été définis dans d'autres RFCs.
Les sous types suivants sont ceux principalement utilisés :
5GTEL – 2015/2016 61
NORME ET PROTOCOLE
6.1. Mixed
multipart/mixed est utilisé pour envoyer des fichiers avec différentes en-têtes Content-type
(comme attachements). Si les fichiers sont facilement lisibles ou sont des images, la plupart
des clients de courriels affichent ces fichiers directement dans le contenu du message (à moins
qu'un en-tête Content-disposition ne la spécifie). Sinon les fichiers sont vus comme des pièces
jointes. Le type de contenu par défaut de ces parties est text/plain.
La RFC spécifie également que tous les sous-types de multipart non reconnus par une
implémentation doivent être traités de la même manière que multipart/mixed.
6.2. Digest multipart/digest est la manière simple d'.
Comme un client ne veut généralement pas envoyer un contenu plus significatif que le texte
brut, celui-ci est envoyé en premier, ce qui permet de simplifier le traitement par les clients
ne comprenant pas le multipart car c'est la partie visible en premier.
L'utilisation principale du type multipart/alternative est l'envoi de courriels au format HTML
avec son équivalent au format texte pour conserver la lisibilité du message pour un client
courriel ne pouvant afficher de HTML (client texte).
Bien que chaque partie du message est censée représenter le même contenu, rien ne le
garantit. Par exemple, il est plus facile pour un filtre anti pourriel d'analyser la partie texte pur
d'un message plutôt que la partie HTML; alors que l'éditeur de pourriel va plutôt construire
un message HTML avec son contenu publicitaire et un message en texte pur anodin ou sans
rapport avec sa publicité.
6.3. Related
multipart/related est utilisé pour préciser que les différentes parties ne devraient pas être
traitées individuellement mais comme un tout. Le message consiste en une partie racine (la
première, par défaut) qui référence les autres parties, qui peuvent aussi référencer d'autres
parties. Les parties de messages sont souvent référencées par leur identifiant de contenu (en-
5GTEL – 2015/2016 62
NORME ET PROTOCOLE
tête Content-ID). La syntaxe des références n'est pas spécifiée, elle est laissée à l'intention du
protocole utilisé.
Un des usages courant de ce sous type est l'envoi d'une page web avec ses images en un seul
message. La partie racine contient le document HTML et les images sont stockées dans les
parties suivantes.
6.4. Report
multipart/report est un type de message qui contient des données formatées pour être lues
par un serveur de courriels. Il est séparé entre un text/plain (ou tout autre contenu facilement
lisible) et un message/delivery-status qui contient les données formatées pour le serveur de
courriels.
6.5. Signed
multipart/signed est utilisé pour attacher une signature numérique à un message. Il est
composé de deux parties : le corps du message et la partie signature. L'ensemble de la partie
corps du message, y compris les en-têtes MIME, est utilisé pour générer la signature.
Différents types de signatures sont possibles comme application/pgp-signature ou
application/x-pkcs7-signature.
6.6. Encrypted
multipart/encrypted est utilisé pour envoyer un contenu chiffré. Sa première partie définit les
informations nécessaires pour décrypter la seconde partie (application/octet-stream).
6.7. Form Data
multipart/form-data est utilisé pour envoyer les données d'un formulaire. Défini à l'origine
comme une partie de HTML 4.0, il est plus couramment utilisé pour envoyer des fichiers via
HTTP.
Note :
5GTEL – 2015/2016 63
NORME ET PROTOCOLE
Une des applications du format MIME est utilisée pour mettre sur pied un système de
messagerie beaucoup plus sécurisé. Il s’agira du protocole S/MIME (Secure / Multipurpose
Internet Mail Extensions) est une norme de cryptographie et de signature numérique de
courriel encapsulés en format MIME. Elle assure l'intégrité, l'authentification, la non-
répudiation et la confidentialité des données.
- Le message lui-même
- Une pièce jointe : le fichier au format « .txt » nommé « ModeEmpl.txt »
- Une pièce jointe : le fichier au format « .doc » nommé « Tableau.doc »
5GTEL – 2015/2016 64
NORME ET PROTOCOLE
Figure 18: Message capturé (MIME )
5GTEL – 2015/2016 65
NORME ET PROTOCOLE
6.8. Explication et description du message capturé :
Return-Path : Adresse qui sera utilisée :
- Soit pour la réponse
- Soit pour renvoi du message s’il ne peut arriver à son destinataire
Received : Chaque MTA qui reçoit le message y inscrit le nom du MTA qui le lui a envoyé, ainsi
que le sien. On obtient la route complète suivie par le message, de l’expéditeur jusqu’au
destinataire, en utilisant les Zones « Recieved » de bas en haut.
Note : Ces indications ont l’inconvénient de révéler une partie de l’architecture de la
messagerie.
X-…. : Champs non « officiels » - Extensions spécifiques aux différents composants de la
messagerie (MUA, MTA, Serveur POP , …).
Message-ID : Identifiant unique de message. Il est attribué par le premier MTA qui reçoit le
message.
Date : Date d’émission donnée par le MUA de l’expéditeur
From : Adresse de l’expéditeur. Cette information peut être facilement usurpée.
MIME-Version : Version du mode de codage de données.
To : Adresse du/des destinataire(s)
Subject : Object du message
Content-Type : le message comprend plusieurs parties.
Boundary = séparateurs de parties du message
Ce message contient plusieurs parties.
-------------= : séparateur, partie message
Content-Type : Type de contenu.
Charset : jeu de caractères utilisé
Content-Transfer-Encoding : Codage (ici sur 8 bits)
5GTEL – 2015/2016 66
NORME ET PROTOCOLE
( le texte du message)
--------------------= : séparateur, pièce jointe format « .txt »
La pièce jointe en format « .txt »
------------------= : séparateur, pièce jointe format « .doc »
La pièce jointe en format « .doc » illisible (base64)
-----------= : séparateur, fin du fichier message.
5GTEL – 2015/2016 67
NORME ET PROTOCOLE
CONCLUSION
Au terme de notre travail ou il était question de présenter le système DNS et les protocoles
de messagerie tels que SMTP (Simple Mail Transfer Protocol, littéralement « protocole simple
de transfert de courrier »), IMAP (Internet Message Access Protocol , littéralement protocole
internet d’accès aux messages), POP(Post Office Protocol littéralement le protocole du bureau
de poste) et MIME (Multipurpose Internet Mail Extensions ou Extensions multifonctions du
courrier Internet), il en ressort que l’acheminement des courriels est régi par plusieurs
standards entre autre le SMTP dédié à l’envoi d’un message et les protocoles POP et IMAP
qui servent à rapatrier des messages pour leur lecture. En outre le DNS fait partie intégrante
de tous les protocoles présents sur internet en particulier les protocoles de messagerie car
doté de sa fonction de résolution de nom, le système DNS facilite le transfert des messages
électroniques.
5GTEL – 2015/2016 68
NORME ET PROTOCOLE
REFERENCES
• Service de noms (DNS) Cours de Réseaux, DANG NGOC Université de Cergy-
Pontoise2012–2013
• SECURITE DU SYSTEME D’INFORMATION (SSI) 3 IAG
• RFC 882-DNS1
• RFC 883-DNS2
• RFC 1034-DNS3
• RFC 1035-DNS4
• RFC 1591-DNS5
• RFC 6195-DNS6
• RFC 1870 – SMTP Service Extension for Message Size Declaration
• RFC 2505 – Anti-Spam Recommendations for SMTP MTAs
• RFC 2920 – SMTP Service Extension for Command Pipelining
• RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME
Messages
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 3461 – Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status
Notifications (DSNs)
• RFC 3463 – Enhanced Mail System Status Codes
5GTEL – 2015/2016 69
NORME ET PROTOCOLE
• RFC 3464 – An Extensible Message Format for Delivery Status Notifications
• RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
• RFC 4954 – SMTP Service Extension for Authentication
• RFC 5068 – Email Submission Operations: Access and Accountability Requirements
• RFC 5321 – Simple Mail Transfer Protocol
• RFC 5322 – Internet Message Format
• RFC 6409 – Message Submission for Mail
• RFC 3501 - spécifications du protocole IMAP, version 4, révision 1
• RFC 2595 - utilisation de TLS (SSL) avec les protocoles POP3 et IMAP4
• RFC 5228 (2008) Sieve: An Email Filtering Language
• RFC 3501 (2003), INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
• RFC 1847 -Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
• RFC 2045 -MIME Part One: Format of Internet Message Bodies.
• RFC 2046 -MIME Part Two: Media Types.
• RFC 2047 -MIME Part Three: Message Header Extensions for Non-ASCII Text.
• RFC 4288 -MIME Part Four: Media Type Specifications and Registration Procedures.
• RFC 4289 -MIME Part Four: Registration Procedures
• RFC 2049 -MIME Part Five: Conformance Criteria and Examples.
• RFC 2231 -MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations..
• RFC 2387-The MIME Multipart/Related Content-type
• www.wikipedia.org
• www.commentcamarche.fr
• www.frameip.com
• www.developpez.com
