La messagerie électronique Exemple de la messagerie Internet

La messagerie électronique Exemple de la messagerie Internet
Ce cours est consacré à la messagerie électronique. Si, à ses débuts, cette application des réseaux a été très confidentielle et a pu paraître futile par rapport à d’autres applications des réseaux jugées plus nobles, son importance aujourd’hui est tellement indiscutable qu’il n’est pas nécessaire d’argumenter. L'utilisation massive de la messagerie dans le grand public fait qu’une forte proportion de la population a maintenant des notions non négligeables de cet outil. Depuis maintenant plus d'une trentaine d'années, il a existé de nombreuses variantes de messageries électroniques. Différents éditeurs de logiciels ont voulu occuper un marché porteur en créant des approches propriétaires. Par ailleurs deux grandes approches de standardisation ont été développées: l ‘a messagerie Internet et la messagerie OSI X400 En fait, dans ce cours, nous prendrons nos exemples presque exclusivement dans la messagerie Internet en raison de sa diffusion qui est quasiment monopolistique..

Plan du cours messagerie
Introduction 1 Architecture de la messagerie Internet 2 Les protocoles SMTP et ESMTP 3 Le format des messages MIME 4 Les protocoles de relève de courrier : pop3 et imap4. 5 Implantations de la messagerie Internet Conclusion Nous suivrons le plan suivant. En introduction nous présenterons essentiellement des définitions générales relatives aux services de messagerie. Nous consacrerons le premier chapitre aux architectures de systèmes de messagerie et en particulier à l'architecture de la messagerie Internet. Nous présenterons ensuite le principal protocole de communication de messagerie Internet, le protocole SMTP ce qui signifie ‘ Simple Mail Transfer Protocol ’. C’est en fait un protocole client serveur d ’échange de courriers entre serveurs de messageries dans le réseau Internet. Nous présenterons les principales caractéristiques de l'extension majeure de ce protocole baptisé ESMTP E voulant dire extended. Au chapitre 3, nous traiterons des formats de messages échangés dans la messagerie Internet. Ces formats sont regroupés depuis les années 1990 sous la terminologie de format MIME ce qui veut dire Multimédia Internet Mail Extensions. Nous parlerons ensuite au chapître 4 des protocoles Internet POP et IMAP de relève de courrier. Pop est un acronyme pour Post Office Protocol et IMAP pour Internet Mail Access Protocol. Avant de conclure nous dirons quelques mots sur les différentes implantations et produits de messagerie Internet.

Introduction Pour commencer nous rappelons en introduction quelques définitions relatives à la messagerie électronique. Ces définitions sont pour la plupart maintenant largement connues, même dans le grand public, mais il est assez important de repréciser certains aspects.

Notion de service de messagerie
A la base un service d’échange de textes courts (un transfert électronique de fichiers caractères ASCII). Extension à des transferts de fichiers quelconques (en structure et en contenu) le plus souvent avec une limitation sur la taille du fichier. le plus souvent par un encodage en format caractère. Transmission asynchrone : l’émetteur et le récepteur n’ont pas a être connecté en même temps. Terminologie : courrier électronique, courriel, mèl (‘mail, ’). L’objectif de base d’une messagerie électronique est de transmettre, au moyen d’un réseau d’ordinateurs, des textes courts en mode caractère. Les documents transmis sont donc en fait des fichiers plats c'est à dire des fichiers non structurés de caractères ASCII. Sur cette base, la plupart des messageries ont progressivement étendu leurs fonctionnalités à la transmission des fichiers quelconques. Comme une messagerie traite de textes courts, un agent de messagerie généralement limite la taille des fichiers transmis. Selon des options de dimensionnement, on peut rencontrer des limites de taille des messages à deux méga octets ou à cinq méga octets. Le plus souvent des fichiers quelconques sont transmis en utilisant des techniques de transcodage de fichiers binaires en fichiers caractères pour retrouver le format standard des messages de texte. Un aspect important de la gestion du courrier est que la lecture d’un courrier doit pouvoir se faire quand l'usager destinataire en a le temps c'est à dire de façon dissociée de l'opération de transmission du courrier. Il faut donc qu’un courrier électronique soit stocké par le logiciel de messagerie en mémoire stable c’est-à-dire sur disque jusqu’à ce que le destinataire décide de le relever. On a donc un fonctionnement très asynchrone du courrier électronique qui nécessite différents types de files d’attente de courriers. Dans le domaine de la messagerie on parle de boites à lettres. La terminologie en matière de courrier électronique n'est pas complètement stabilisée en français. Le terme que l'on rencontre maintenant assez souvent est courriel. Il n'est pas sur que ce terme ait une véritable durabilité car on pourrait tout simplement parler de courrier pour le courrier électronique comme en anglais on utilise le plus souvent mail pour . Qui se souvient qu'un courrier est d'abord la personne qui transporte en courant (ou à cheval) un message.

Fonctions d’un service de messagerie
Fonctions de désignation: définition d’un système d’adressage, envoi à un destinataire ou à un groupe. Fonctions de composition de courrier. Fonctions d’émission du courrier. Fonctions de lecture du courrier : notion de files d’attente de courriers ou boites à lettres. Fonctions de gestion des archives de courriers. Les fonctions principales d’une messagerie sont bien sur d’émettre et de recevoir des courriers et pour cela on doit définir au départ un système de désignation des entités qui s’échangent du courrier: permettant de définir le destinataire ou de savoir qui est l'émetteur. En général, les systèmes de messageries prévoient aussi les listes de diffusion c'est à dire que le système de désignation doit prévoir les groupes de destinataires. Pour faciliter le travail des utilisateurs à l'émission, les logiciels de messagerie proposent des outils de composition des textes à transmettre. On doit bien sur fournir une interface pour l'émission des courriers et pour la transmission de fichiers joints si la messagerie permet l’attachement de fichiers. Symétriquement il faut définir des fonctions de récupération du courrier et d'affichage ce qui peut être assez complexe quand les courriers comportent des attachements multimédia. Un logiciel de messagerie offre aussi généralement des fonctions de gestion des archives de courrier c'est à dire de classement des courriers selon différents critères dans des boites à lettre différentes.

Service de messagerie et service de transfert de fichiers
Distinction entre un service de messagerie et un service de transfert de fichiers. En fait des similitudes ou des distinctions selon toutes les fonctions : de transmission asynchrone, de transmission en binaire ou en caractères, de composition des documents (courriers/fichiers), de taille des données échangées, de désignation, de gestion des archives. Sur ce transparent nous comparons les services de messagerie aux services de transfert de fichiers. Les services d'une messagerie comportent des services de transfert de fichier. Réciproquement on a vu des échanges de courriers réalisés par des transferts de fichiers. Les similitudes sont donc assez grandes entre les deux applications. Il reste néanmoins des différences non négligeables. La principale différence est la suivante. La transmission d'un fichier en transfert de fichier se fait de façon immédiate (synchrone), c’est à dire que si le site distant n’est pas opérationnel la transmission ne peut avoir lieu. En messagerie on peut récupérer de manière asynchrone les messages et par suite les fichiers joints. Autre différence significative, un transfert de fichier ne propose pas de facilités de composition de fichiers. Dans un transfert de fichiers, les fichiers sont de taille quelconque et de type quelconque alors qu'une messagerie limite souvent la taille des fichiers transportés et souvent ne transporte que des fichiers de caractères. Les systèmes de désignation sont également différents. Dans un cas on désigne un fichier dans une arborescence sur une machine dans l'autre un message dans une boite à lettre. Dans un transfert de fichiers, les fichiers sont transférés en binaire sans être convertis. En général les messages sont émis et reçus à partir d'un répertoire unique (une boite à lettre en émission ou une boite à lettre en réception).

Service de messagerie et service de communication en mode message
Distinction entre un service de messagerie et un service de communication orienté messages (MOM middleware orienté messages). En fait des similitudes ou des distinctions selon toutes les fonctions de désignation, de composition de messages, d’émission et de réception …. de transmission asynchrone, de transmission en binaire ou en caractères, de composition des documents (courriers/messages), de taille des données échangées, de désignation, de gestion des archives. Situons maintenant les services de messageries par rapport aux services de communication en mode message asynchrone. Nous considérons tout de suite plus particulièrement le mode files de messages. Un service de files de messages (MOM 'Message Oriented Middleware') comme le produit IBM MQ Series 'Message Queue Series' ou le produit Microsoft équivalent Microsoft Message Queues) définit un service de niveau application de type communication en mode message asynchrone. Il apparaît donc à la base comme similaire à un service de transport. La notion de MOM ajoute un service de journalisation des messages transmis et il assure la délivrance des messages même si le destinataire n’est pas disponible au moment de l’émission. On a donc comme dans une messagerie la possibilité d'une relève asynchrone des messages. Similitudes : Transmission de messages (de textes courts) et délivrance asynchrone, la relève d’un message MOM comme celle d’un courrier électronique sont à l’initiative du destinataire. Différences : Dans un MOM, il n’y a pas de transcodage d'un message quelconque en mode caractère, de facilité de composition de messages, de gestion d’archives de messages. Un MOM transfère des messages de façon similaire à un protocole de transport en assurant la persistance des messages alors qu’une messagerie transfère plutôt des fichiers.

1 Architecture des systèmes de messagerie
Ce premier chapitre est consacré à une présentation assez rapide des architectures de systèmes de messagerie.

Architectures de messagerie : I) Stockage et retransmission
MTA3 MTA2 Usager MUA MTA1 MTA4 MTA6 MTA5 Usager MUA Réseau maillé de MTA On a distingué historiquement deux grandes catégories d'architectures de systèmes de messagerie électronique. Sur ce transparent nous commençons par les messageries en stockage et retransmission. Ces messageries sont constituées d'un ensemble de systèmes usagers de la messagerie et d'un ensemble de commutateurs de courriers qui acheminent les courriers électroniques comme sont acheminés des paquets dans un réseau à commutation de paquets. Sur le dessin on a porté en gras le chemin emprunté par un courrier électronique qui est ici relayé successivement par les commutateurs MTA 1, MTA2, MTA3, MTA4. Les deux principaux types d'appareils figurant sur ce dessin sont baptisés MUA et MTA. Nous les définissons au transparent suivant. La messagerie réalise l'acheminement des courriers comme le fait un réseau à commutation de paquets.

Compléments: Stockage et retransmission
Notion de serveur de messagerie et commutateur de courriers: agent de transfert de messages MTA ('Mail Transfer Agent'). Notion de client de messagerie : agent utilisateur de messagerie ou MUA (‘Mail User Agent’). Exemple de messagerie avec commutation : la messagerie normalisée OSI MHS 'Message Handling System' ou norme ITU X400. Dans la terminologie X400 un serveur de messagerie est baptisé agent de transfert de messages ou en anglais MTA Mail Transfer Agent. C’est donc tout d’abord un composant matériel/logiciel qui transfere du courrier pour le compte d'un client. C'est également un commutateur de courriers. On dit encore souvent aussi qu'il relaye du courrier. Un client de messagerie est un ensemble matériel logiciel qui offre à un usager l’interface d’accès au système de messagerie. Il est appelé agent d'utilisateur de messagerie ou en anglais MUA ‘Mail User Agent’. L'exemple type d’une messagerie avec commutation en stockage et retransmission est la messagerie normalisée par l'ITU 'International Telecommunication Union' selon la norme X400. La même norme est définie par l'OSI sous l'appellation MHS 'Message Handling System'. Cette messagerie a connu un développement significatif au moment de son adoption mais elle a été ensuite marginalisée par le développement de la messagerie Internet.

Architectures de messagerie : II) Acheminement de bout en bout
Réseau (Internet) MUA émetteur MUA destinataire MTA MTA Le serveur de messagerie MTA achemine directement un message entre un émetteur et un destinataire. Pour cela il utilise un service de transport existant (typiquement TCP). Un courrier est acheminé comme segments de niveau transport). Exemple : la messagerie Internet SMTP (forme de base). La seconde grande catégorie de messagerie est constituée par les messageries avec acheminement de bout en bout. La terminologie MUA, MTA des messageries normalisées X400 a été conservée dans les messageries en acheminement de bout en bout. Dans cette architecture chaque client de messagerie (chaque MUA) dialogue avec un serveur de messagerie de rattachement (son MTA, le MTA de son entreprise). Au départ MUA et MTA étaient sur la même machine (le grand système de l'entreprise). Ils sont maintenant sur des postes de travail différents. Le dialogue entre les MTA n'est pas réalisé comme précédemment par routage à l'intérieur du système de messagerie mais par un acheminement direct (de bout en bout) entre le MTA de rattachement de l'émetteur et le MTA de rattachement du destinataire. Pour pouvoir acheminer ainsi directement un courrier un MTA utilise un service de transport existant qui est typiquement dans l’Internet le protocole TCP. Un courrier électronique est donc acheminé comme des segments de niveau transport. Comme le protocole de transport de niveau 4 utilise un protocole de réseau de niveau 3 sous-jacent (typiquement IP), c’est ce niveau réseau qui effectue des opérations de commutation si elles sont nécessaires. L'exemple type de cette architecture est offert par la messagerie Internet et son protocole d'échange de messages SMTP ('Simple Mail Transfer Protocol') utilisé dans sa forme de base. On peut cependant noter des maintenant que la messagerie Internet SMTP permet également de faire du relayage de courriers. Il faut pour cela qu’un MTA Internet accepte de fonctionner en relais ouvert. Dans ce cas un MTA qui reçoit un courrier d’un autre MTA le relaye vers son destinataire comme s’il venait de recevoir ce courrier d’un client ou il le relaye vers un autre MTA s’il est configuré pour retransmettre ainsi tout ses courriers en sortie. Il peut enfin relayer un courrier vers un autre MTA s'il trouve dans le courrier des informations de routage.

Comparaison des deux approches
Acheminement de bout en bout Un serveur de courrier utilise une connexion de bout en bout (transport) pour remettre ses messages => fiable et simple (si l’on dispose d’une couche transport fiable comme TCP). Stockage et retransmission Problème de routage des messages et aussi contrôle d’erreur à régler (le bruit sur les liaisons ou les pannes des MTA intermédiaires peuvent provoquer des pertes de messages). Un atout : facilite l’interconnexion avec d’autres systèmes de messagerie comme CSNET, BITNET, ... Situation actuelle: triomphe de la solution de bout en bout (avec la messagerie Internet). Ce transparent présente quelques éléments très rapides de comparaison des deux architectures. On peut dire que la solution de l’acheminement de bout en bout est certainement beaucoup plus simple pour développer une messagerie. Si le protocole de transport est fiable (comme TCP) on élimine ainsi pratiquement tous les problèmes de reprise sur erreur. La solution avec stockage et retransmission impose de résoudre au niveau d’une messagerie, des problèmes de routage et éventuellement aussi de contrôle d’erreur dans la mesure ou le bruit ou les pannes de commutateurs intermédiaires peuvent faire perdre des courriers. Un atout de la solution avec stockage et retransmission consistait à faciliter la construction des passerelles entre systèmes de messagerie. Cependant comme on est arrivé à une unification presque complète autour de la messagerie Internet, ça ne constitue plus un avantage réel des messageries à stockage et retransmission comme X400.

Architecture modulaire d’un système de messagerie Internet
MUA émetteur MTA Etape 1: composition du message Etape 2: envoi Etape 3: Transmission destination MDA MAA Etape 4: Réception du message Etape 5: Stockage Etape 6: Restitution des messages Etape 7: Lecture des messages PO3, IMAP4 Etape 8: Consultation des messages SMTP Boite à lettres Mail Delivery Agent Access Ce schéma donne une vision modulaire plus détaillée d’une architecture de système de messagerie que l’on rencontre actuellement sur l’Internet. Un tel découpage modulaire permet de considérer un système de messagerie comme un ensemble de modules que l’on peut placer sur différents calculateurs d’un système réparti. On peut également remplacer des modules par d’autres pour adapter au mieux les outils d’une entreprise à ses besoins. On peut également de façon plus souple rajouter de nouveaux composants à cette architecture comme des anti-virus des anti spams etc. On voit apparaître sur ce schéma cinq éléments principaux, c’est à dire trois modules nouveaux par rapport aux deux modules déjà présentés. Le schéma comporte deux parties associées à l’émetteur et au destinataire, les parties sont encadrées par des rectangles. En plus de la notion de MUA ou client de messagerie et de MTA serveur de messagerie on introduit sur le destinataire la notion de MDA ce qui veut dire Mail Delivery Agent. Un MDA est un logiciel chargé du stockage des courriers sur le site destinataire. Sur le schéma on a représenté la fonction boite aux lettres du destinataire c’est-à-dire la fonction de stockage des messages avant relève du courrier. Il apparaît ensuite la notion de MAA ou Mail Access Agent qui est un module chargé de répondre aux requêtes d’accès à la boite à lettre de courrier. On a porté sur les flèches huit étapes principales dans le cycle de vie d’un message. Nous allons les détailler dans les transparents suivants. On a également porté sur certaines flèches le nom du protocole utilisé comme SMTP, POP ou IMAP. Ils sont détaillés également dans la suite. Cette architecture générique tend à s’imposer. On peut peut-être encore trouver d’autres découpages avec des modes de fonctionnement propriétaires. A condition de respecter le protocole SMTP entre MTA et le format des courriers échangés, une messagerie propriétaire peut participer à la messagerie Internet tout en faisant ce qu'elle veut coté émetteur et coté destinataire.

Détail des étapes (1) Etape 1: Un usager compose,avec l’aide de son client de messagerie (MUA) un message. Etape 2: Le message est transmis au MTA de l’usager ( son serveur de messagerie en SMTP). Etape 3: Le message est transmis au serveur de messagerie du destinataire (SMTP). Etape 4: Le serveur transmet le message à un agent: notion d’agent MDA ‘Mail Delivery Agent’. Nous reprenons une par une les étapes définies dans le transparent précédent: Etape 1 : La composition d’un courrier est réalisée à l’aide du client de messagerie MUA. Elle doit permettre de fournir les informations essentielles d’un courrier: adresse source, adresse destinataire, objet, contenu. En fait les courriers sont souvent composés directement dans le format standard des courriers Internet mais ce n’est pas obligatoire. On peut passer par des formats propriétaires et transcoder au moment de l’émission. Le message composé peut déjà être stocké une première fois dans des files d’attentes (celles du MUA) si son expédition n’est pas immédiatement possible. Etape 2 : Des que possible, le message est transmis par le client de messagerie à son serveur de messagerie (son MTA de rattachement) en utilisant le protocole SMTP. Etape 3 : Le message est transmis par le MTA de rattachement de l’émetteur au MTA de rattachement du destinataire toujours en utilisant SMTP. On peut trouver à ce niveau une nouvelle file d’attente de courriers qui permet, en cas d'échec d'une première tentative, de tenter de joindre à différentes reprises le MTA destinataire pendant un laps de temps prédéfini (éventuellement plusieurs heures) avant de déclarer le destinataire inaccessible. Etape 4 : Le MTA destinataire transmet le message reçu à un agent qui est en fait un agent chargé de le stocker. C’est la fonction de MDA ou mail delivery Agent.

Détail des étapes (2) Etape 5: Le MDA stocke le courrier dans la boite à lettres du destinataire. Etape 6: 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’). Etape 7: Les messages sont transmis au client de messagerie utilisateur (protocoles POP ou IMAP). Il sont stockés dans des boites à lettre client. Etape 8: Le destinataire consulte ses messages en utilisant son client de messagerie (MUA). Nous continuons l’examen des étapes suivies par un courrier: Etape 5 : Le MDA stocke le courrier qui vient d’arriver dans la boite à lettre du destinataire. Il existe des formats standards de boites à lettre sur disque dont nous dirons quelques mots au dernier chapitre. Etape 6 : Le destinataire relève son courrier en utilisant un protocole de relève POP ou IMAP. Ces protocoles comportent différents échanges requête réponse. La principale requête est celle de l’accès à un courrier et la réponse est la fourniture du courrier. Dans ce mode client serveur on appelle MAA pour Mail Access Agent le logiciel serveur qui reçoite les requêtes, accède aux boites aux lettres pour fournir des réponses. Etape 7 : Le message est transmis par le protocole de relève vers le MUA destinataire, le client de messagerie du destinataire. Celui ci les stocke dans des boites à lettre du poste client. Etape 8 : Le destinataire peut consulter les messages présents dans les boites a lettre de son MUA.

Les protocoles de messagerie de l’Internet
Simple Mail Transfer Protocol (SMTP) (RFC 821) : Le protocole basé sur des messages de format textes qui définit les échanges entre serveurs de messagerie. Extended Simple Mail Transfer Protocol (ESMTP) (RFC 1869) : Une évolution de SMTP qui définit des commandes supplémentaires. Post Office Protocol (POP) : Un protocole de base de relève de courrier pour le dialogue entre un client de messagerie MUA et un serveur de messagerie dans sa partie MAA. Internet Message Access Protocol (IMAP): Un autre protocole de relève qui offre des possibilités plus larges que POP (gestion des archives de courrier, limitation des volumes de données échangées …) Finalement la messagerie Internet comporte quatre protocoles principaux que l'on a déjà un peu évoqué pour trois d'entr'eux. Simple Mail Transfer Protocol (SMTP) est le protocole de base de la messagerie. Maintenant ancien basé il utilise des messages de format caractères pour réaliser les transferts de courriers entre MTA. Normalisé au départ sous la référence RFC 82, il a subi depuis de nombreuses améliorations. L’une des améliorations principale , en fait une révision majeure du protocole SMTP est constituée par le protocole Extended Simple Mail Transfer Protocol (ESMTP) (RFC 1869) qui définit des commandes supplémentaires, des possibilités d’échanges de courriers de types plus variés. Post Office Protocol (POP) est un protocole de base pour la relève de courrier. Son mode de fonctionnement principalement visé est le transfert des courriers entre un client de messagerie MUA et un serveur de messagerie dans sa partie MAA suivi d'une destruction du courrier par le MAA. Le courrier n'est alors plus conservé que sur le MUA client de messagerie du destinataire. Internet Message Access Protocol (IMAP) est un autre protocole de relève qui offre des possibilités plus larges que POP (gestion des archives de courrier, limitation des volumes de données échangées …). Son mode de fonctionnement privilégie la gestion des archives de courrier par le MAA destinataire c'est à dire sur le serveur de messagerie destinataire et pas sur le poste client du destinataire. Nous reviendrons dans les derniers chapitres de ce cours sur les différences entre POP et IMAP.

2 Le protocole SMTP (‘Simple Mail Transfer Protocol’)
Après ces quelques généralités nous entrons dans plus de détail en commençant par le principal protocole fédérateur de la messagerie Internet : le protocole SMTP Simple Mail Transfer Protocol. Nous présentons ensuite quelques éléments du protocole ESMTP.

Les adresses ‘ globales ’ de courrier électronique Internet (RFC 2821 et 2822)
Les adresses dans le service de messagerie (émetteurs ou destinataires) sont des couples : (Nom de boîte aux lettres , Nom du domaine DNS ou est gérée la boite à lettre). Le système de noms de domaines (DNS) permet de déterminer les serveurs de courrier d’un domaine (enregistrement de type MX). Les noms utilisables pour les boites aux lettres sont quelconques (taille inférieure à 64 octets). Boîte aux lettres Domaine DNS Avant de parler du protocole SMTP, nous devons dire quelques mots du système de d'adressage de la messagerie Internet. On va donc dire comment est résolu dans cette messagerie le problème de désignation c’est-à-dire la construction des noms ou adresses, puis la liaison c’est-à-dire le moyen de retrouver un destinataire. On distingue deux types d'adresses: tout d'abord les adresses globales de messagerie. Ce sont des adresses pour un émetteur ou un destinataire qui sont valides n'importe ou dans l‘Internet. De manière plus précise une telle adresse ne comporte pas de chemin pour atteindre le destinataire. Une adresse globale de courrier électronique Internet est composée de deux parties: une partie locale qui est un nom de boite à lettre et une partie désignation en univers réparti de la localisation de la boite à lettre. Il s'agit dans le réseau Internet d'un nom de domaine DNS. Le séparateur est le fameux caractère arobas. En étant choisi pour apparaître dans les adresses de courrier ce caractère bizarre est devenu symbolique de l'informatique pour le grand public et a acquis une grande gloire car il était auparavant assez ignoré dans les alphabets ascii. Le nom de domaine d’un utilisateur du courrier est le nom du domaine DNS ou se trouve défini le MTA de rattachement d'un usager émetteur ou destinataire. Cette partie d'une adresse de courrier électronique doit donc être construite selon les règles qui président à la construction des FQN DNS. En terme de liaison, ce nom permet en fait de déterminer l’adresse IP du MTA de rattachement de l’usager. On peut revoir à ce propos le cours DNS avec les types d'enregistrements en particulier le type MX qui permet de connaître le ou les MTA serveurs de courriers d’un domaine car ils peuvent être redondés. On rappelle que cette stratégie permet de distinguer les noms des serveurs de courrier du nom de domaine utilisé dans la désignation des destinataires. Dans la rfc smtp initiale la talle du nom de domaine est limitée à 64 octets. Le nom d’une boite à lettre est une chaîne de caractère (limitée à 64 octets) qui identifie une structure de donnée pouvant archiver des files d'attentes de courriers électroniques. La chaîne de caractère identifiant une boite, est quelconque et n’a a priori aucun rapport avec la notion d’identificateur de login. Cependant assez souvent on a utilisé les mêmes identificateurs pour le login et pour la boite à lettre pour des raisons de simplification évidente de l'administration et pour des raisons de facilité de mémorisation. Par exemple lors de l'arrivée des premiers systèmes Unix chaque usager avait un login basé sur son prénom ce qui donne un nom de boite à lettre comme gerard et une adresse de courrier

Syntaxe des adresses globales
cnam.fr : La forme la plus simple : Avec des guillemets pour délimiter la chaîne de caractères boite à lettres. gerard (Gérard : Une chaîne entre parenthèses est un commentaire donc ignorée. Gérard Florin : En fait seul compte ce qui est entre < et >. Le reste est ignoré. : Forme d ’adresse dite littérale avec directement codée l ’adresse IP du serveur. Il existe différentes syntaxes pour les adresses globales de courrier électronique. La forme la plus simple comme a été vue au transparent précédent. Ajoutons qu'on peut mettre des espaces à l'intérieur d'une adresse (entre les différents champs). On peut aussi utiliser des délimiteurs guillemets pour isoler la chaîne de caractères associée au nom de boite à lettre et mettre dans cette chaîne des caractères spéciaux. Dans beaucoup de cas on a des problèmes pour associer un nom de boite à lettre à une personne précise. En conséquence les adresses de messagerie prévoient plusieurs syntaxes permettant de rajouter des textes comme l'ensemble prenom.nom. On peut mettre dans une adresse un commentaire entre parenthèses ce qui permet de rajouter une forme prénom nom plus intuitive que le nom de la boite à lettre On peut utiliser les délimiteurs plus petit et plus grand pour délimiter une adresse. Tout ce qui est à l'extérieur de ces délimiteurs est ignoré du point de vue de l'adresse. En quelque sorte il s'agit d'une autre forme de commentaire. Remarquons au passage qu'une adresse de la forme <> est une adresse vide. On peut l'utiliser par exemple en position d'adresse émetteur pour définir une adresse à laquelle on ne peut pas répondre. On peut enfin donner l'adresse IP en numérique du serveur de courrier du destinataire. Cette forme est déconseillée car elle élimine de fait le DNS et ses enregistrements de type MX qui permettent de rendre plus rationnelle la liaison avec le serveur distant.

Adresses avec ‘ relayage ’ explicite (routage par la source)
Envoyer un courrier à gerard au CNAM en le faisant passer par le serveur de courrier de ibp.fr tout d’abord puis par celui de uvsq.fr. Deux syntaxes possibles : <gerard % cnam.fr % ibp.fr> Sur ce transparent on montre qu'on peut définir des adresses non globales au sens ou elles ne sont définies que par rapport à un chemin à suivre obligatoirement pour atteindre le destinataire. Par exemple on peut définir une adresse qui spécifie qu'un courrier doit être envoyé à ibp.fr, qui doit le faire suivre à uvsq.fr, qui l'envoie finalement à Les adresses avec routage explicite sont très fortement déconseillées. En effet, les serveurs de messagerie sont généralement configurés pour ne pas relayer un courrier qui provient d'une source qui n'est pas dans leur domaine. Ceci de façon à limiter le SPAM. Dans ce cas le mécanisme de routage par la source n'est pas appliqué. Il y a deux syntaxes différentes : Avec devant chaque serveur intermédiaire relais, et deux points avant l'adresse destinataire proprement dite. L’autre forme qui serait mieux reconnue par es implantations smtp selon certains auteurs utilise des pourcents comme délimiteurs. On met la liste des relais en partant de la fin.

Le mode client-serveur en SMTP (RFC 821)
Commandes SMTP MTA Client MTA Serveur Réponses SMTP Files d’attente de courriers SMTP (‘Simple Mail Transfer Protocol’): un protocole client serveur entre deux MTA. Le client souhaite transmettre un courrier au serveur pour qu’il le distribue. Le point important à fixer au départ d'un exposé sur SMTP est que SMTP est un protocole client serveur entre deux MTA. L'un des MTA joue le rôle de client, c'est l'émetteur d'un message. L'autre MTA joue le rôle de serveur. C'est le destinataire d'un message. En fait tous les MTA sont à la fois clients et serveurs et l'algorithmique réparti d'échange des courriers électroniques est très symétrique. En ce sens on pourrait dire que c'est une forme de communications de données entre égaux (peer to peer). Sur le schéma on a rappelé que chaque MTA travaille en relation avec des files d'attentes de courriers qu'il émet ou reçoit. En fait dans ce chapitre nous allons nous préoccuper essentiellement des commandes et des réponses permettant de transmettre un courrier.

Exemple type de transmission d'un courrier
sun% mail -v Connecting to artemis.ibp.fr (TCP)... 220 artemis.ibp.fr Sendmail 3.2/SMI-3.2 ready at Sun, 4 Mar 99 17:24:07 PST >>> HELO litp.ibp.fr 250 artemis.ibp.fr HELO litp.ibp.fr, pleased to meet you >>> MAIL 250 Sender ok >>> RCPT 250 Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> Ceci est un essai . 250 Mail accepted >>> QUIT 221 artemis.ibp.fr delivering mail Sent sun% On présente sur ce transparent une immersion brutale dans le protocole SMTP sous la forme d’un exemple de fonctionnement du protocole SMTP. Cet exemple est celui d’une utilisation maintenant ancienne de la messagerie Internet avec la commande mail de Unix sur un sun. Avec l ’option -v on a sélectionné un mode verbeux de fonctionnement qui permet de tracer les messages SMTP échangés. Dans la ligne de lancement commande on a indiqué l’adresse de courrier électronique du destinataire qui est ici lo arobas artemis.fr. On voit tout d ’abord sur les deux premières lignes le compte rendu de la phase de connexion en TCP au serveur de messagerie de l ’utilisateur distant. SMTP fonctionne au dessus de TCP donc le sun émetteur a lancé une commande de connexion en TCP à la machine du destinataire artemis. Le MTA qui tourne sur le serveur artemis est la version sendmail très répandue encore sur les systèmes UNIX. On voit que la connexion est acceptée avec la réponse de code 220 et un texte en clair d'explication. On voit ensuite des lignes qui ont été renforcées en gras et qui commencent après des ensemble de trois caractères >. Ce sont les messages du protocole SMTP, émis par le sun pour réaliser la commande mail. Remarquons que chaque message du protocole SMTP est en fait une ligne de texte donc une suite de caractères terminée par un retour charriot, passage à la ligne. En général chaque message de requête client donne lieu à un message de réponse serveur qui est également en format caractère. Chaque message du MTA client est typé par un mot clé que l ’on a porté en gras. Chaque réponse est typée par un code numérique et expliquée par un message en clair.

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). HELO <SP> <domaine> <CRLF> L’ouverture de session entre le client et le serveur (le message contient le nom de domaine FQDN du client). MAIL <SP> FROM: <route-retour> <CRLF> Définit l'adresse mail de l'émetteur (utilisé pour le retour éventuel d'erreurs). 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_3) DATA <CRLF> Définit l'enveloppe (l'entête) et le corps (le texte) du message. QUIT <CRLF> Termine un courrier. On confirme et précise un peu les différents types de messages SMTP vus sur l'exemple précédent. Chaque requête est associé à une ligne de texte terminée par CRLF (‘ carriage return ’ code 13 et ‘ line feed code ’ 10). Le message de type HELO <SP> <domaine> <CRLF> demande l'ouverture d'une session d'échange de courrier entre le client et le serveur. Le message contient en paramètre le nom de domaine DNS le FQDN du domaine client. Le message de type MAIL <SP> FROM: <route-retour> <CRLF> définit l'adresse mail de l'émetteur. Cette information n'est pas authentifiée donc on peut mettre n'importe quoi. Elle est utilisée pour le retour éventuel de comte rendu d'erreur. Le message de type RCPT <SP> TO: <route-aller> <CRLF> permet de définir l'adresse mail du destinataire. On a vu qu'on peut définir un routage en donnant une liste de MTA à visiter par le courrier. DATA <CRLF> Définit l'enveloppe (l'entête) et le corps (le texte) du message. Le type de message DATA introduit la phase de transmission du message proprement dit dont nous verrons qu'il est composé d'une entête et d'un corps. Le type de message QUIT <CRLF> ferme une session de transmission de courrier.

Différents types de requêtes annexes
RSET : Commande pour abandonner le courrier en cours de transmission et restaurer la connexion. VRFY : Commande pour vérifier une adresse de destinataire sans lui transmettre de courrier (utilisable pour déterminer la cause d’un problème). NOOP : Commande vide qui oblige simplement le serveur à répondre 200 OK. EXPN : Expansion d’une liste de diffusion (‘mailing list’). TURN : Inversion des rôles client et serveur pour envoyer du courrier dans l’autre sens sans ouvrir une nouvelle connexion TCP. Il existe un nombre assez limité de types de messages en SMTP. Nous trouvons sur ce second transparent l'essentiel des différents autres types de messages qui ont par rapport à ceux de la page précédente un rôle assez annexe Le type de message RSET est une demande pour abandonner le courrier en cours de transmission et restaurer la connexion. Le type de message VRFY permet de vérifier une adresse de destinataire sans lui transmettre de courrier. C'est utilisable pour déterminer la cause d’un problème. Le type de message NOOP oblige simplement le serveur à répondre. C'est une requête qui permet de savoir si un serveur distant est toujours opérationnel. Le type de message EXPN demande l'expansion d’une liste de diffusion (‘mailing list’). Le type de message TURN permet d'inverser les rôles client et serveur pour envoyer du courrier dans l’autre sens c’est à dire du serveur vers le client sans ouvrir une nouvelle connexion TCP. On pourrait rajouter à cette liste des messages Help demande d'information au site distant concernant une commande. SEND,SOML, and SAML (Send, send or mail et send and mail qui remplacent la commande MAIL et permettent toute combinaison de délivrance directe sur le terminal du destinataire lorsque celui-ci est connecté (logged in), ou d'envoi sur sa boite à lettre. Ces dernières commandes sont rarement implantées.

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, a suivre 2yz: Requête satisfaite 5yz: Réponse négative 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). On présente maintenant quelques détails sur les messages de réponses émises par le serveur vers le client. Pour chaque message client on a un code retour sous une forme numérique de trois chiffres décimaux et une explication complémentaire en clair qui est non normalisée et qui dépend donc de l’implantation. Cette codification des réponses à eu de nombreuses suites les protocoles d'application Internet avec des formes similaires (par exemple en HTTP). Le transparent donne une vue très partielle des valeurs possibles. Pour des détails il faut consulter les RFC ou les manuels de proudits de messagerie. On cite ici en première position le code 1 qui indique un travail en cours qui se poursuit, 2 qui indique une requête complètement et correctement exécutée alors que 5 indique le contraire. En seconde position 0 concerne la syntaxe d'un courrier, 2 l'état d'une connexion et 5 l'état global du système de messagerie. Il faut toujours aller regarder de près le contenu d'un diagnostic de non délivrance d'un message. On peut ainsi savoir de façon assez précise ce qui s'est passé et si le problème parait assez grave le signaler.

Une liste des principales réponses
211 System status, or system help reply 214 Help message [Information on how to use] 220 <domain> Service ready 221 <domain> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 354 Start mail input; end with <CRLF>.<CRLF> 421 <domain> Service not available, closing channel 451Requested action aborted: local error in processing 452 Requested action not taken: insufficient storage 500 Syntax error, command unrecognized 501Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 551 User not local; please try <forward-path> 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction failed On a fait sur ce transparent un coupé collé d'une liste des réponses les plus fréquentes trouvée sur le web. Par exemple le code 250 indique que tout s'est bien passé. On l'avait vu sur la trace en mode verbeux de l'exécution de la commande mail. On lit au hasard une autre ligne, par exemple, avant dernière ligne, le code 553 indique une erreur de syntaxe dans le nom d'un boite à lettres.

Approfondissement: le protocole ESMTP (Extended SMTP) (1)
EHLO <SP> <domaine> <CRLF> (RFC 1651) Ouverture de session entre un client et un serveur en mode ESMTP. Réponse : liste des extensions supportées par le serveur. 8BITMIME (RFC 1652) Définit un encodage en caractères 8 bits au lieu de 7: MAIL FROM: <adresse> BODY=8BITMIME. CHUNKING : (RFC 1830) Permet de transmettre par morceaux. BINARYMIME (RFC 1830) Permet de transmettre des données binaires. Exemple : BODY=BINARYMIME le courrier est en binaire et est introduit par BDAT au lieu de DATA. ETRN (RFC 1985) Permet d’envoyer un message sur plusieurs connexions TCP successives. Pour terminer ce court exposé du protocole SMTP, nous donnons sur ce transparent et le suivant les principales différences entre SMTP et son extension majeure ESMTP maintenant très utilisé Le message de type EHLO <SP> <domaine> <CRLF> (RFC 1651) définit l'ouverture de session entre un client et un serveur en mode ESMTP. On voit la différence avec le message HELO de SMTP. La réponse définit la liste des extensions supportées par le serveur car les extensions étant quand même assez variées et complexes, elles ne sont pas forcément toutes implémentées. Le paramètre BODY = 8BITMIME (RFC 1652) dans le message mail from définit un encodage dans un alphabet 8 bits au lieu de l'usasci 7 bits. Nous reviendrons sur ce point à propos du format MIME. Les valeurs du paramètre BODY qui sont CHUNKING ou BINARYMIME (RFC 1830) permettent de transmettre par morceaux ou avec des données binaires. Par exemple MAIL FROM: xxx BODY=BINARYMIME permet de transmettre dans un courrier n'importe quelle donnée . Le corps du message est en binaire. Sa valeur est introduite par le message BDAT (binary data) au lieu de DATA. Le type de message ETRN permet d’envoyer un message sur plusieurs connexions TCP successives, donc on peut ainsi émettre des courriers longs en ayant un éventuelle rupture de connexion en cours.

Approfondissement: le protocole ESMTP (Extended SMTP) (2)
DSN (RFC 1891, 1892, 1894) (Delivery Service Notification) Définit un système d’accusé de réception pour les courriers électroniques MAIL FROM: xxx RET=portion_retournée ENVID=ident RCPT TO: yyy NOTIFY=motif ORCPT=adresse retour SIZE (RFC 1870) Définit une taille pour un courrier MAIL FROM: xxx SIZE=nnnnn PIPELINING (RFC 2197) Pour enchaîner plusieurs commandes SMTP sans attendre la réponse. AUTH (RFC 2554) Introduit une authentification de l’émetteur d’un message. CHECKPOINT (RFC 1845) Permet de créer des transactions de transmission de courrier reprenables en cas de panne MAIL FROM: xxx TRANSID=yyyyy En ESMTP on a introduit le mode DSN qui veut dire delivery service notification. Dans ce mode on a défini un système d’accusé de réception assez sophistiqué pour les courriers électroniques Le message MAIL FROM comporte deux paramètres RET=retour ENVID=ident. Le paramètre retour indique la portion du message émis que l'accusé doit retourner. Avec FULL on retourne l'intégralité du message, et avec headers HDRS on ne retourne que les en-têtes. Le paramètre envid définit un identificateur qui sera retourné pour permettre d'apparier un message et son accusé de réception. Receipt to comporte deux paramètres notify et adresse du destinataire de l'accusé de réception. Le paramètre notifiy définit le motif qui doit conduire à une notification. SUCCESS quand le courrier a été délivré. FAILURE quand il n'a pas pu être délivré. DELAY quand il est en attente de délivrance dans une file. NEVER pas de compte rendu. Le paramètre ORCPT contient normalement la même adresse que celle de l'émetteur mais on peut souhaiter qu'elle soit différente. De plus certains relais de courrier peuvent modifier l'adresse. Le paramètre SIZE (RFC 1870) permet de définir la taille d'un courrier. Le mode PIPELINING (RFC 2197) permet d'enchaîner plusieurs commandes SMTP sans attendre la réponse. Le mode AUTH (RFC 2554) introduit la possibilité d'authentifier l'émetteur d'un courrier. Le client de messagerie devrait alors prouver à son MTA qu'il est bien l'auteur du courrier qu'il demande de transmettre. de même un MTA qui demanderait le relayage d'un message à un autre MTA devrait s'authentifier ce qui limiterait un peu les possibilités de SPAM. En fait les modes vraiment sécuritaires de fonctionnement du courrier sont réellement traités avec S-MIME mais aussi avec PGP. Le mode CHECKPOINT (RFC 1845) permet de créer des transactions de transmission de courrier avec reprise en cas de panne MAIL FROM: xxx TRANSID=yyyyy

3 Le format des courriers et le format MIME
Nous passons maintenant à l'examen des différentes structures de données de courriers échangés. Dans cette messagerie on est parti d'une définition de base assez simple de la structure d'un courrier électronique. Mais sous l'influence des besoins de transmission d'une grande variété de types de données (images, pages web) on est passé à une définition beaucoup plus large connue sous le nom de format MIME.

Le format de base (RFC 822) Nom_de_zone: Valeur_de_zone
Un courrier est composé de lignes de caractères US- ASCII sur 7bits selon la définition du NVT Telnet. Chaque ligne fait au maximum 1000 caractères et est terminée par CR LF. Les courriers sont en deux partie : une entête et un corps séparés par une ligne vide. L’entête est une liste de lignes précisant les caractéristiques du message sous la forme Nom_de_zone: Valeur_de_zone Le corps contient les données effectivement échangées. Le format de base des courriers électronique Internet est connu par sa RFC originelle qui est la RFC 822. Cette RFC a été remodelée en versions successives jusqu'à la version actuelle qui est la 2822. Ce transparent rappelle les grandes lignes de la structure d'un courrier. Dans la version de base un courrier électronique Internet est composé de lignes de caractères de l'ASCII américain sur 7bits selon la même définition que celle du terminal virtuel Telnet NVT Network Virtual Terminal. Chaque ligne fait au maximum 1000 caractères et est terminée par retour chariot CR saut de ligne LF. Les courriers sont en deux partie : une entête et un corps séparés par une ligne vide. L’entête est une liste de lignes de texte précisant les caractéristiques du message sous la forme : Nom_de_zone: Valeur_de_zone Le corps contient les données effectivement échangées. Nous allons revenir plus en détail sur ces différents points.

Un premier exemple simple
Delivered-To: Date: Thu, 21 Mar :15: From: Bruno Traverson Organization: EDF-DER X-Accept-Language: fr MIME-Version: 1.0 To: Cc: TRAVERSON Bruno Subject: Un premier retour sur le modèle Corps du courrier électronique Sur ce premier exemple simple on voit apparaitre les deux parties principales d'un courrier. - Tout d'abord les lignes d'entête qui contiennent différentes informations ou directives permettant l'interprétation d'un courrier. Ces lignes d'entête, nous l'avons dit sont de la forme type de la ligne suivie de deux points suivi d'une valeur ou de paramètres avec des valeurs. On comprend assez facilement le sens de toutes ces informations, delivered to, date, from, organization, to, cc qui veut dire carbon copy, subject. - Ensuite la partie indiquée comme le corps du courrier électronique contient le texte proprement dit du courrier.

L’entête Au moins trois lignes obligatoires : From: adresse émetteur
To: adresse destinataire Date: date de création du message Nombreuses autres possibilités normalisées mais facultatives : Possibilité de créer des entêtes propriétaires à condition de les faire précéder de X- Les directives d'entête appartiennent à trois catégories. - Les entêtes obligatoires : il s'agit de from avec l'adresse de l'émetteur, to avec l'adresse du destinatire et de date avec la date de création du message. - On trouve ensuite un ensemble directives normalisées mais facultatives. - On trouve enfin des lignes d'entête propriétaires qui peuvent être crées par un logiciel de messagerie mais qui ne sont pas standards et ne correspondent pas à une définition partagées. Ces entêtes ne seront donc pas reconnues ni utilisées dans de nombreux cas.

Quelques champs de l’entête
Entêtes normalisées facultatives Received : Une information sur le chemin suivi. Reply-To : Une adresse pour la réponse. Subject: Le sujet du message. Message-ID: un identifiant unique du message. Entêtes privées (commençant par x-) X-Phone : Un numéro d’appel. X-Mailer : L’identifiant du logiciel de gestion de courrier (Lotus Notes Release …..). - Sur ce transparent on a porté quelques entêtes normalisées et quelques entêtes privées qui commencent par x-. - Il existe un trop grand nombre d'entêtes pour en faire une liste exhaustive dans le cadre de ce cours. Nous avons choisi quelques exemples. - received est une entête intéressante car elle permet de connaître le chemin suivi par un courrier. Chaque MTA visité rajoute une entête received donc si un courrier a été relayé on voit apparaître autant de ligne d'entête received que de MTA ayant relayé le courrier. - Reply-to permet de définir l'adresse à laquelle une réponse doit être envoyée. Ce n'est pas forcément l'adresse de l'émetteur et c'est différente des mécanismles d'accusé de réception. - Subject défini le thème général du courrier. - Message-ID donne un identifiant unique du courrier ce qui utile pour archiver et ensuite faire état de l'existence ou même éventuellement utiliser juridiquement un courrier. Dans le domaine des entêtes privées nous avons cité: - X-phone qui permet d'ajouter une numéro d'appel téléphonique utilisable concernant le courrier électronique. - X-Mailer qui donne le nom du logiciel ayant créé le courrier.

Le format (MIME ‘Multipurpose Internet Mail Extensions’)
Insuffisance du format RFC 822 : Apparition du format MIME (RFC 1341 et 1342 Juin 1992). MIME introduit quelques nouvelles entêtes ayant surtout pour objet de décrire le format des corps de courriers. Améliorations successives des spécifications de MIME : RFC 1521, 1522 … RFC 2045 à 2049 (Novembre 1996) RFC 2822 (Avril 2001) - Inévitablement la messagerie Internet a du être retouchée au fur et à mesure du constat de ses insuffisances. C'est probablement surtout son succès qui a révélé différents problèmes. - Par exemple dans les années 1980 les utilisateurs français, généralement des informaticiens, s'accommodaient de n'avoir pour rédiger leurs courriers que l'ascii américain. Avec l'arrivée d'un ensemble très vaste d'utilisateurs en France s'est posé le problème de l'utilisation des accents et autres signes diacritiques du français. Le problème s'est posé dans de nombreuses autres langues. - Nous en restons la pour les insuffisances car nous allons détailler dans les transparents qui suivent, les différentes fonctionnalités nouvelles qui ont été introduites et donc nous allons voir d'autres critiques qui ont amené d'autres extensions au format RFC 822. - Toutes ces extensions on été rassemblées sous l'appellation MIME pour multipurpose internet mail extensions. - Mime s'intéresse essentiellement au format des corps de message. - Les améliorations successives du format MIME sont constantes. Elles ont conduit à la RFC 2822 de 2001 et il est probable que ce n'est pas fini.

Les objectifs de MIME Besoin élémentaire: transmettre des messages textuels qui utilisent des jeux de caractères autres que l'US-ASCII (par exemple ISO-Latin) De manière beaucoup plus générale : permettre la définition d'un système très général de typage pour des documents multimédia : textes, images, sons, tableurs, …) Permettre de transmettre des corps de message comportant plusieurs parties (message avec plusieurs attachements). - Nous revenons plus en détail sur les objectifs qui ont présidé à la définition du format MIME. En fait avec MIME on a cherché à s'affranchir de la forme simpliste des coprs de messages du début de la messagerie Internet (uniquement du texte ASCII US). - Nous avons déjà vu comme problème assez important à une époque, la possibilité d'utiliser des alphabets différents de l'US-ASCII. Par exemple pour le français, pouvoir échanger des courriers dans l'alphabet ISO latin 1. - Mais ce problème s'est généralisé rapidement à de nombreux autres types de coprs de messages possibles. Et l'un des deux problèmes majeurs de MIME a été de créer un véritable système de typage pour des données multimédia. La variété des formes de documents a échanger par mail est énorme et l'on doir pouvoir les typer pour déterminer quelle application les prend en charge. Par exemple un format d'image est traité par un afficheur donné, un format de tableau est traité par le tableur correspondant. - Un autre problème est apparu en même temps qui consiste à pouvoir attacher un fichier auxilliaire à un courrier. Ce problème a été légèrement généralisé en considérant tout simplement qu'un corps de message pouvait comporter plusieurs parties et que cette décomposition pouvait être hiérarchique.

Les types principaux de données MIME: données ‘discretes’
Cinq types de données ‘discrets’ (avec sous types) Type texte: données lisibles. text/rfc822 ; text/plain [RFC2646] ; text/html [RFC2854] . Type image: différents codages image image/jpeg ; image/gif. Type son: différents codages ‘ Audio ’ audio/basic (MIC mu Hz 8 bits). Type vidéo : images animées. video/mpeg Type application : les données qui restent. application/octet-stream ; application/PostScript - Les types principaux de données MIME sont répertoriées en trois catégories: les données discrètes, les données composites et les données messages. - Dans ce transparent on commence par lister les principaux types de données discrètes qui sont des données homogènes au sens ou elles correspondent à une structure de données unique comme une image, un son. - On a cinq principaux types de données discrètes, chacun de ces types comportant de nombreux sous types: - Le type texte définit les données textuelles comme du texte en us-ascii selon la norme rfc822, du texte non formaté défini dans un alphabet donné text/plain ou du document textuel avec indications de structuration comme les formats HTML, XML, etc - Le type image définit dans ses sous types les différents standards de codage d'image comme jpeg, gif etc ... - De même pour le type son qui peut être basique ou mp3 etc - On peut aussi échanger des vidéos dont le volume serait compatible avec la taille des courriers électroniques. On a donc différents types de vidéos qui correspondent aux différents codages. - Enfin le type application regroupe tout ce qui ne rentre pas dans la classification précédente. Par exemple du bianire pur est défini comme de l'octet stream mais on peut aussi trouver des données structurées selon le format postscript.

Les types principaux de données MIME: données composites
Données composites ou assemblées ("multipart") :plusieurs types de données sont combinés en un seul corps. Cinq principaux types: de syntaxe identique mais de sémantique différente. multipart/mixed : les données assemblées sont indépendantes. multipart/alternative : les données sont des alternatives d'une même information (pour l'affichage le meilleur sur un destinataire). multipart/digest : la forme par défaut text/plain est la forme textuelle la plus simple d’un message soit text/rfc822 => permet de transférer une suite de messages ou une boite à lettre. multipart/parallel : les données sont présentées en parallèle. multipart/related : les données sont reliées (comme un document HTML qui comprendrait des images incluses). Ce transparent présente maintenant les données MIME composites. Dans le langage MIME on dit multipart soit encore en français multi-partie qui serait possible. Une donnée composite est associée à la réunion dans un même corps de courrier de plusieurs données de type différents. Il est assez naturel d'assembler des données discrètes c’est-à-dire des textes avec des images ou du son. C’est donc fait typiquement pour transférer des données en attachement. Mais on autorise également en MIME, l’assemblage des données discrètes avec d'autres données composites. Donc un corps de courrier MIME composite possède dans le cas général une structure d'arbre. Chaque partie peut contenir des parties et ainsi de suite. Il n'y a qu'une seule forme de données composites (une seule syntaxe) qui définisse la réunion dans un même corps de plusieurs types de données discrètes ou composites. Par contre on peut donner des sens différents (des sémantiques différentes) à cette structuration. Avec le sous type mixed, les différentes structures de données assemblées sont indépendantes (c'est à dire quelconques et sans relation). Par exemple on a un texte avec un attachement sous la forme d'un document word. L'ordre des données dans le corps d'un courrier peut être significatif. Le sous type alternative correspond à des données représentant la même information mais de forme syntaxique différente ce qui peut se comprendre quand on a différentes possibilités d'affichage avec des afficheurs de qualité différente. Typiquement on peut avoir une présentation banale de texte brut text/plain associée à une présentation plus graphique de la même chose comme text/html. Dans ce mode l'ordre n'a pas grande importance. C'est plutôt l'existence d'un afficheur pour les différents types de données qui joue. Le sous type digest n'est pas très évident à comprendre. Il est identique au type mixed mais avec la différence que dans toutes les parties le type par défaut (lorsque content type n'est pas mentionné) est text/rfc822 plutôt que text/plain. Le sous type parallèle indique que les différentes données assemblées sont présentées simultanément à l'utilisateur. Par exemple on transporte un fichier texte associé à un fichier son. Le texte et le son sont affichés simultanément. On pourrait imaginer aussi une image et un texte servant de légende pour cette image qui seraient affichés ensembles. Le sous-type multi-part related est assez récent. Il définit des données reliées. L'exemple type est celui d'un document HTML qui comprend des documents inclus de nature différente un document de base et des images incluses).

Les types principaux de données MIME: données ‘ message ‘
Le type message est défini pour transporter dans un corps de courrier électronique un autre courrier électronique. Utilisation qui justifie le type message: une erreur dans un courrier qui nécessite le renvoi de ce courrier dans un courrier de diagnostic. Le troisième type MIME est le type message. Le type message permet d'encapsuler un courrier avec toutes ses informations d'entête, de corps dans un autre courrier. Il associe à un courrier électronique une structure de donnée rassemblant toutes les informations de ce courrier. L’utilisation du type courrier est claire. On peut envoyer dans un courrier un autre courrier en attachement. Par exemple, si un premier courrier a donné lieu à une erreur. On peut transmettre en réponse un courrier de rapport d'erreur contenant le diagnostic de l'erreur et en attachement le courrier original ayant provoqué une erreur.

MIME: la représentation des contenus, l’encodage (RFC 2045)
Pour transférer des données quelconques (des suites d’octets), MIME définit cinq formats de codage: - Format texte 7 bits - Format Quoted-Printable - Format Base 64 - Format 8 bits - Format binaire Existence d’autres formats ayant été définis mais non normalisés MIME : binhex (apple), uuencode, xxencode, (unix) ... - On s'intéresse maintenant à la représentation des données transférées dans les courriers. Ces données peuvent être quelconques or les courriers sont a priori en us ascii 7 bits (american standard code for information interchange). - L'IETF a donc normalisé cinq procédés pour transférer des données quelconques struturées en octets. Nous allons étudier rapidement dans les transparents suivants le format texte 7 bits, le format Quoted-Printable, le format Base 64, le format 8 bits, le format binaire. - Ce qui veut dire aussi que les très nombreux autres formats d'encodage de données binaires en format caractère comme le binhex qui avait été utilisé par apple ou l'uuencode défini en Unix ne sont plus normalisés.

1 Format texte 7 bits, US-ASCII
L’encodage par défaut si rien d’autre n’est spécifié. Le standard initial de la messagerie Internet (RFC822). Chaque caractère est codé en US-Ascii 7 bits. Jeu de caractère du Network Virtual Terminal Telnet. Uniquement pour les textes anglais: besoin d’autres formats. - Pour mémoire, on retrouve comme l'un des cinq formats, le format de base de la RFC 822 qui consiste à transmettre les corps de message comme des caractères en ascii 7 bits. - C'est l'encodage par défaut, c'est à dire que si l'on ne spécifie rien de précis pour un message c'est ce format qui est pris. - On a déjà que ce jeu est celui défini pour le NVT de telnet. - C'est parfait pour les messages de base en format texte en anglais mais ça pose des problèmes des que l'on sort de cette hypothèse.

2 Format Quoted-Printable
On code un texte d’un alphabet de caractères 8 bits (ex ASCII ISO Latin) en US-ASCII 7 bits. Les caractères standards (code 33 à 127 sauf le 61 caractère =) sont codés en US-ASCII 7 bits. Les caractères spéciaux 8 bits (ex en iso latin: é, è, ç , à ...) sont codés par une séquence =NM ou N et M sont en code ASCII les deux chiffres hexadécimaux des 8 bits à représenter (espace code ascii 32 =20 ). On peut donc utiliser différents alphabets nationaux à condition de définir lequel est utilisé. A utiliser s’il y a peu de différences avec l’us ascii. - Nous présentons dans ses grandes lignes le format quoted printable. - L'objectif du quoted printable comme celui des cinq formats d'encodage est de coder des octets, mais on prend comme hypothèse que ces octets appartiennent à un code caractère 8 bits donné. Il est a priori différent de l'Us ascii sinon ca ne sert à rien mais il ne pas non plus pas être très différent sinon le format quoted printable n'est pas très efficace. Typiquement il s'agit d'un alphabet d'une langue nationale européenne comme l'iso latin pour le français. - On suppose qu'il y a des caractères communs au code caractère 8 bits et au code us-ascii. Ceux ci sont codés directement en us -ascii. Il s'agit des lettres de l'alphabet qui ne comportent pas de signes diacritiques, des chiffres et de certains signes. Une exception est faite pour le caractère = dont on va voir plus loin qu'il sert de caractère d'échappement. De manière précise il s'agit des codes 33 à 127 de l'us-asscii.. - Les caractères spéciaux 8 bits (par exemple en iso latin: é, è, ç , à ...) sont codés par une séquence de trois caractères =NM . L'idée essentielle est que l'octet à représenter est divisé en deux parties de 4 bits soient deux chiffres héxadécimaux 0, 1, 2, 9, A, B, C, D, E, F. N et M sont la représentation en code ASCII des deux chiffres. On codera ainsi un espace dont le code us-ascii est 32 par les trois caractères =20. Autre exemple une tabulation code ascii 9 sera codée par les trois caractères =09. - Ce codage permet donc typiquement de résoudre le problème des caractères spéciaux dans les alphabets nationaux. Il faut indiquer quelque part dans le courrier quel alphabet est utilisé pour afficher correctement les caractères spéciaux. - Ce codage est donc surtout utilisé lorsque le nombre de caractères incompatibles avec l’us ascii n ’est pas très élevé et que ces caractères ne sont pas très fréquents. Le seuil cité est de 1/8 au maximum de caractères spéciaux. Ca marche pour le français avec l'alphabet iso latin. - Beaucoup de détails seraient à rajouter pour décrire un fonctionnement réel (par exemple les lignes en quoted printable font toujours au plus 76 caractères).

3 Format Base 64 Coder tout type de données 8 bits en caractères US-ASCII en augmentant pas trop le volume. Des groupes de 3 octets quelconques soient 24 bits sont codés par 4 caractères US-ASCII. On choisit dans l’US-ASCII 64 symboles différents pour représenter 6 bits (un caractère us ascii pourra coder un groupe de 6 bits): ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz /. On augmente le volume de 1/3. - Nous présentons maintenant le format base 64. Son objectif est de coder n’importe quelle donnée binaire au format 8 bits en utilisant uniquement une représentation en caractères us ascii 7bits. Par rapport au codage 'quoted printable' le codage base 64 fait l'hypothèse qu'au moins un huitième des caractères transmis n'est pas compatible avec le jeux des caractères 7 bits américains. - L'idée de base consiste à prendre des groupes de trois octets quelconques soient 24 bits. Si un texte n'est pas de longueur multiple de 3 on le complète par des caractères =. On code les groupes de 24 bits par quatre caractères us ascii. Chaque caractère doit donc coder 6 bits. - Il faut donc retenir 64 symboles différents dans le jeu us ascii pour coder des configurations quelconques sur 6 bits. Le transparent montre les 64 symboles retenus 26 majuscules, 26 minuscules, 9 chiffres et trois caractères spéciaux + / . - Le volume est des données est augmenté d'un tiers. Finalement on produit des lignes de 54 caractères us ascii. - C'est la représentation d'octets quelconques en format caractères maintenant la plus utilisée puisqu'elle est normalisée par MIME.

4 Format caractères 8 bits
Pour transporter des données en format caractères 8 bits dans les corps de messages sans les transcoder en US-ASCII. Définir dans l’entête l’alphabet utilisé (content type + char set). Nécessite des modifications au format standard des courriers. Ces modifications sont définies dans le cadre du protocole ESMTP (option 8BITSMIME). Ce transparent est consacré au format caractère 8 bits. Avec ce format, MIME se propose de transporter des caractères d ’un jeu quelconque de caractères 8 bits. Il existe énormément de jeux de caractères différents associés aux différents langues écrites. - Un tel jeu de caractère jeu de caractère doit bien sur être pré défini et normalisé. Comme on l'a déjà dit, son utilisation doit être indiquée par une entête content type comportant la directive charset, tout simplement pour qu'il puisse être affiché correctement par le destinataire. - Cependant si on utilise n'importe quel alphabet on peut donc supposer que pour coder les lettres, les signes diacritiques d'une langue, il pourra faire usage de n'importe quelle configuration 8 bits. Or certains caractères spéciaux dans le jeu ascii américain sont utilisés pour les besoins des protocoles de courrier électronique (ne serait ce que des délimiteurs comme . ; : / ). Ces codes spéciaux pouvant être utilisés dans un texte de courrier utilisant un alphabet quelconque peuvent créer des problèmes d'interprétation des messages et peuvent certainement générer des erreurs. - Il est donc nécessaire de faire quelques modifications dans les formats de messages du protocoles SMTP. Ces modifications sont en fait définies dans le cadre de l'extension ESMTP. Nous ne détaillons pas plus avant ce point ce qui nécessiterait trop de détails.

5 Format binaire Possible en MIME mais pose des problèmes avec le format standard (utilisation du type application/octet-stream). Problème : longueur des lignes (RFC 822, une ligne doit faire moins de 1000 cars). Problème: déterminer la fin du message par un délimiteur approprié. Nécessite d’utiliser les extensions ESMTP (Binary). Un dernier transparent sur le format binaire prévu par MIME. - Transmettre du binaire est possible en MIME avec le type application/octet-stream mais son utilisation pose de multiples problèmes si l’on se place dans le format de base de la messagerie électronique Internet telle que définie par la RFC 822. -En effet les lignes en RFC 822 ne doivent pas faire plus de 1000 caractères ce qui oblige pour transmettre du binaire à rajouter des CRLF de temps en temps à bon escient. - Autre détail, la délimitation de la fin d ’un corps de message en binaire sous la forme d ’un point en début de ligne pose des problèmes de transparence puisque le caractère point peut apparaître dans le binaire - Il faut donc trouver des solutions si l'on veut transmettre des flots d'octets (octet stream) autrement que recodés en format base64. Comme pour le format caractère 8 bits et de façon similaire, des solutions sont proposées dans le cadre des extensions du protocole SMTP, ESMTP.

Complément: codage des champs d’entête
Problème: Existence de données d’autres alphabets que l’us ascii dans les entêtes. Règle d’encodage =?charset?encodage?valeur?= charset: le jeu de caractère, encodage: Q pour quoted et B pour base64, valeur: résultat d’encodage Exemple: Pour transmettre une entête comme Subject: Bonjour Gérard En fait on transmet (par exemple): Subject: Bonjour =?iso ?Q?G=E9rard?= - On doit aussi régler le problème des textes qui sont codées autrement qu’en ascii américain dans les entêtes. Par exemple dans un nom de destinataire, dans le sujet d ’un courrier électronique on peut faire apparaître des accents graves ou aigus en français. - La règle d’encodage qui a été définie pour transmettre et imprimer correctement de tels caractères est la suivante: on cadre par des caractères égal = trois champs séparés par des points d ’interrogation. . Le champ charset définit le jeu de caractère utilisé par exemple pour le français l ’iso-latin 1 est codifié iso On choisit ensuite entre l ’encodage quoted printable lettre Q et l ’encodage base64 lettre B. . On donne enfin la valeur de la chaîne encodée. - Par exemple si dans un courrier on met comme sujet bonjour Gérard on devra en fait transmettre en us ascii Gérard comme de l ’iso latin codé en quoted printable lettre Q majuscule et le é accent aigu de gérard apparaîtra comme=E9.

Directives d’entête spécifiques de MIME
MIME utilise des directives d’entête décrivant le corps d’un message pour permettre son interprétation à l’arrivée. Champs spécifiques de MIME Mime-version : la version utilisée actuellement 1.0 Content-type : le type et les sous-type des données. Paramètre charset : le jeu de caractères utilisé. Content-Tranfer-Encoding : l’encodage utilisé (quoted-printable , base64) Content-ID : Identificateur unique de partie de message. Content-Description : Informations complémentaires sur le contenu. - Dans ce transparent et les suivants on donne quelques éléments sur les directives spécifiques du format MIME que l’on trouve dans les entêtes de courriers électroniques. Ces entêtes définissent les types des données échangées, les formats de caractères utilisés, les règles d’encodage de façon à permettre la transmission sans problèmes et l’édition correcte des courriers par les clients de messagerie. - On voit sur le transparent cinq entêtes nouvelles spécifiques de MIME. - Mime-version définit la version de MIME utilisée. Actuellement on est sur la version 1. - Content-type définit le type et les sous-type des données comme text/html. Un autre paramètre définit si nécessaire le jeu de caractères utilisé dans le corps du message. - Content-Tranfer-Encoding définit l’encodage utilisé qu'on choisit entre quoted printable ou base 64 - Content-ID définit un identificateur unique pour une partie d'un corps de courrier composite. - Content-Description définit des informations complémentaires sur le contenu.

Exemples de format MIME (1)
Exemple d’un courrier en français encodé en format base 64 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO Content-transfer-encoding: base64 Commentaires : Les données transportées sont des caractères ISO Le codage du corps est effectué en base64. - Pour finir deux exemples d'entêtes associées au format MIME. Sur ce transparent le premier exemple est celui d’un courrier en caractère ISO-latin et donc adapté au français. On choisit de l'encoder en format base 64. - On trouve tout d'abord une directive qui ne change guère c'est la version de MIME qui jusqu'à présent est la seule: MIME-Version: 1.0. - On indique ensuite sur la seconde ligne d'entête que le contenu est du texte caractère mais codé en ascii ISO latin 1 l'alhabet ASCII - On donne enfin l'encodage avec l'entête Content-transfer-encoding qui déclarée en base64

Exemples de format MIME (2) Courrier composite multipart
MIME-Version: 1.0 Content-type: multipart/alternative; boundary="simple limite" --simple limite Content-Type: text/plain; charset=ISO Content-transfer-encoding: quoted-printable Bonjour G=E9rard Content-Type: text/html; charset=ISO <HTML> <BODY> <H1> Bonjour G=E9rard </H1></BODY></HTML> Sur ce second exemple on présente un contenu composite soit selon le terminologie MIME un format multipart. Il va donc y avoir plusieurs parties. - Après le rappel de la version MIME, le champ Content-Type décrit ici un courrier de type multipart alternative. On rappelle que la directive alternative permet de transmettre différentes versions d'un même document qui sont affichables par des afficheurs différents. On peut ainsi avoir une qualité plus ou moins bonne d'affichage en fonction de la disponibilité des afficheurs sur le site destinataire. - La directive content type comporte aussi un paramètre "boundary" qui spécifie la chaîne de caractère servant de délimitation entre les différentes parties. On peut la redéfinir de façon différente dans chaque courrier composite. Avec assez peu d'imagination on a défini comme chaîne de caractère entre les différentes parties la chaîne simple limite. La ligne de délimitation commence toujours par deux tirets ou deux signes moins. - Après content type et avant le délimiteur qui est ici simple limite on pourrait mettre du texte par exemple des commentaires. Donc ce document comprend deux versions de la même chose: - La première version du document est du texte en format caractère français. Nous avons déjà vu les lignes d'entête de définition d'un tel document au transparent précédent avec cette petite différence qu'on choist ici un codage en format quoted printable. - La seconde version du document est un document HTML. On peut afficher le courrier par un client de messagerie capable d'interprèter du HTML. L'utilisation du format HTML en messagerie est de plus en plus fréquente en raison des avantages de présentation graphique que l'on peut retirer du HTML.

Conclusion : Format Mime
Le format par excellence de transmission de fichiers de données multimédia. Utilisé pour de très nombreux formats de données (des centaines de types différents). Un mécanisme d’extension permettant d’intégrer en permanence de nouveaux formats. MIME est utilisé avec des modifications très mineures par le protocole HTTP du WEB pour ses propres échanges de données multimédia. Définition de mécanismes de sécurité pour les échanges de courrier: SMIME (‘Secure MIME’). Quelques mots de conclusion sur le format MIME. - On peut tout d'abord dire que créé à partir des besoins de la gestion de documents multimédia pour la messagerie, ce format a pris une importance considérable dans la définition des formats d'échanges de données. C'est devenu Le format par excellence de transmission de fichiers de données multimédia. - Il incorpore pratiquement tous les formats de données: des centaines de types de données différents sont identifiés dans les RFC MIME. - Le format MIME dispose d'un mécanisme d’extension permettant d’intégrer en permanence de nouveaux formats. Par exemple le format MIME ne disposait pas d'un format d'échange pour les données typées habituelles des programmes (entiers, flottants). Un tel format ayant été défini dans le cadre de XML avec les web services (le format XML schéma) rien n'empèche maintenant d'échanger par courrier électronique des valeurs de types de données générées par des programmes et ceci selon un standard ouvert. - MIME est utilisé avec des modifications très mineures par le protocole HTTP du WEB pour ses propres échanges de données multimédia. - Enfin dans le cadre de MIME ont été définis des mécanismes de sécurité pour les échanges de courrier. Ils forment l'ensemble des normes SMIME (‘Secure MIME’).

4 Les protocoles de relève de courrier : POP et IMAP
Nous présentons maintenant les deux prtocoles de relève de courrier dans la messagerie Internet, les protocoles POP et IMAP.

Introduction Des protocoles dérivés du protocole SMTP.
Spécialisés pour offrir des fonctions spécifiques de relève du courrier dans une boite à lettre. Fonctions de transfert de courrier d’un serveur de messagerie vers un client de messagerie. Fonctions de gestion des archives de courrier (liste de messages en attente dans une boite, destruction de message …) - Au départ on utilisait des systèmes de messagerie avec tous les modules localisés sur la même machine MUA, MTA? MDA, MAA. - Avec le temps les différentes fonctions ont été réparties et l'on eu besoin d'un protocle pour accèder à partir d'un client de messagerie MUA aux boites à lettres d'un serveur de messagerie. - Ce protocole de transfert de courrier aurait pu être SMTP mais on a très vite défini des fonctions plus précises associées à la relève de courrier. Par exemple faire la liste des courrriers arrivés pour un usager afin de transférere éventuellement sélectivement les courriers. - C'est ainsi qu'ont été dérivés deux protcoles de relève de courriers. - Ils réalisent essentiellement des fonctions de transfert du courrier d'un serveur de messagerie vers un client de messagerie. Mais ils réalisent des fonctions de gestion des archvies de courrier comme la liste des messages en atente dans une boite ou la destruction d'un courrier quand celui-ci a été lu et ne sert plus à rien.

POP3 ‘Post Office Protocol’ RFC 1939
Le protocole de relève le plus simple. Le plus souvent utilisé en transfert définitif des messages d’une boite à lettre d’un serveur de messagerie vers un client de messagerie. Ne gère pas les archives de courrier sur le serveur. Convient bien à l’utilisation à partir du même poste client de messagerie. POP (Post Office Protocole) est le protocole de relève le plus ancien et le plus simple. Son domaine d'utilisation par exceellence est le suivant. Un client demande une lkiste des messages en instance (qui sont arivés et qui n'ont pas été lus). Il transfère ces courriers un par un du serveur de messagerie vers le client de messagerie. Il détruit les versions des courriers sur le serveur de messagerie puisque ces courriers sont maintenant consultables sur le poste client. - Ce mode de fonctionnement est donc caractèrisé par la règle suivant: les courriers ne sont gérés sur le serveur et donc de manière encore plus gébnérale il n'ya pas de gestion d'archives de courriers par un usager sur le serveur de messagerie. - Par contre, toutes les manipulations du courrier reçu sont effectuées sur le poste client de l'usager ce qui est possible si l'usager interroge toujours du même poste) mais ce qui pose problème si l'usager souhaite consulter son courrier à partie de postes différents car il aura des archives de courriers distribuées sur tous les postes qu'il utilise en consultation.

Messages POP3 principaux
USER Fourniture du nom de la boite à lettre PASS Fourniture du mot de passe en clair APOP Fourniture cryptée du mot de passe STAT Nombre de messages dans la boite LIST Liste des messages présents RETR Transfert du message n DELE Marquage message pour la suppression LAST Numéro du dernier message consulté RSET Annulation des actions d’une session QUIT Fin de session. Ce transparent donne une liste des principales commandes de POP. USER Ouvre une session de relève en donnant le nom de la boite à lettre à relever. PASS Donne le mot de passe en clair pour l'accès à la boite à lettre. Le courrier étant privatif ne peut être relevé que par le propriétaire de la boite. La méthode est néanmoins très rustique puisque le mot de passe circule en clair. APOP est une méthode d'authentifcation plus sérieuse avec circulation cryptée du mot de passe. STAT donne le nombre de courriers dans la boite LIST donne la liste des courriers présents dans la boite (non détruits avec un numéro d'ordre). RETR retrieve transfere le courrier numéro N vers le client de messagerie DELE delete marque un courrier pour la suppression LAST donne le numéro du dernier courrier consulté RSET annule les actions d’une session en particulier les courriers qui ont été marqués pour la destruction QUIT termine une session. C'est à ce moment que les courriers marqués pour la destruction sont effectivement détruits. De sorte qu'avec POP il est possible qu'une session de grand menage dans une boite à lettre qui ne s'est pas bien terminée pour cause de plantage ne donne aucun effet car les messages sont restés non effectivement détruits.

IMAP4 ‘Internet Message Access Protocol’ RFC 2060
Protocole le plus complet. Gère les archives de courrier sur le serveur (dossier de base INBOX pour les nouveaux messages, primitives de création de dossiers et de transferts entre dossiers). Minimise les échanges de données sur le réseau. Le plus souvent utilisé en laissant les courriers dans la boite à lettre du serveur de messagerie. Un protocole adapté à la consultation à partir de différents poste clients - Le protocole IMAP4 ‘Internet Message Access Protocol’ dans sa version 4 est le protocole de relève de courrier le plus récent et le plus complet. Il peut faire tout ce que fait pop3 mais il peut faire des choses en plus. Il faut cependant être bien conscient que IMAP4 est une boite à outils assez riche mais l'utilisation des outils dépend d'une implantation de client de messagerie et des options définies par un usager. Autrement dit, si un client de messagerie utilise IMAP dans ses fonctions identiques à POP il ne fera pas plus avec IMAP que ce que fait POP. - L'avantage principal de IMAP par rapport à POP est celui de la gestion d'archives de courriers sur le site serveur de messagerie. L'objectif principal de cette fonctionalité est de faire gérer les courriers pour les différents utilisateurs dans le serveur de messagerie. - Chaque usager disposant d'une boite à lettre peut créer différents dossiers d'archives de courriers. IL reçoit ses courriers dans un dossier par défaut nommé INBOX. A partir de ce doissier il peut ventiler ses courriers dans ses différents autres dossiers. - Remarquons aussi que améliorer les performances (l'occupation du réseau et le temps de réponse) IMAP permet à un utilisateur de récupérer l'entête d'un message sans transférer le corps ce qui diminue les données échangées. De même IMAP permet dans un un document composite (multipart) de transférer une partie seulement en laissant les autres sur le serveur. - Enrésumé IMAP est un protocole concçu pour permettre la gestion des courriers sur le serveur de messagerie de l'entreprise et ainsi il rend très aisée la consultation des courriers à partir de différents postes clients.

Messages IMAP4 principaux
AUTHENTICATE : Mécanisme d’authentification choisi. LOGIN : Usager mot de passe. LOGOUT : Fin de session IMAP. CREATE/DELETE/RENAME : Nom de boite à lettre. SELECT/EXAMINE : Nom de boite à lettre. LIST/LSUB/STATUS : Etat de la boite à lettre. EXPUNGE/CLOSE : Détruit les messages marqués (et ferme). SEARCH : Recherche de message sur différents critères. FETCH : Récupération des données concernant un courrier. COPY : Recopie d’un message d ’une boite à lettre dans une autre. CAPABILITY : Liste des fonctions implantées d’un serveur. NOOP : Opération vide. On énonce sur ce transparent une liste de quelques types de message IMAP4 sans beaucoup de détails. L'ensemble des primitives est plus riche que dans POP et pour chaque directive les variantes possibles sont souvent multiples. Pour plus de détails de IMAP4 il faut voir directement la RFC 2060. - Donc en IMAP4 on a une procédure d'ouverture et de fermeture de session avec login, logout et choix d'un mécanisme d'authentification (on peut par exemple sélectionner une authentification avec Kerberos). - On peut surtout gérer différentes boites à lettre pour un même usager avec des primitives create delete rename de boite à lettre. - On peut faire de la gestion de courrier dans une boite à lettre avec différentes primitives de sélection de la boite à lettre sur laquelle on travaille, liste status de l'état d'une boite à lettre, search de recherche dans une boiteselon différents critères. - fetch réalise la transmission des données, - copy recopie un courrier d'une boite dans une autre boite. - On a différentes fonctions annexes comme capability qui donnent les fonctions imap implantées par un serveur. On aussi une opération vide no operation.

5 Les implantations de la messagerie Internet
Nous terminons ce cours par un bref survol des différents logiciels de messagerie Internet.

Serveurs de messagerie libres (MTA) (1)
Sendmail (depuis 1980), Auteur principal Eric Allman, version en septembre 2003, 40%, problèmes de sécurité et de configuration (fichier sendmail.cf) Postfix (depuis 2001) Auteur principal Vietse Venema, projet IBM Vmailer, 5%, configuration assez simple. Exim (depuis 1995) Auteur Principal Philippe Hazel, 5% Qmail (depuis 1997) Auteur Dan Bernstein 8%. Considérés comme meilleurs : Postfix et Qmail Nous nous intéressons tout d'abord aux versions libres (open source) des serveurs de messagerie MTA. - Pendant longtemps les serveurs de messagerie ont été basée sur l'implantation sous UNIX baptisée sendmail. Cette implantation a été de nombreuses fois améliorée. Elle est réputée difficile à configurer (le fichier des directives de configuration d'un serveur sendmail qui s'appelle sendmail.cf est compliqué à produire. On rapporte également des problèmes liés à la sécurité. Cette implantation représente encore une part importante du marché. C'est encore le logiciel MTA le plus déployé. - Postfix est une implantation de MTA récente et donc considérée comme encore un peu jeune. Elle est réputée beaucoup plus facile à configurer que sendmail. - Citons encore exim et qmail. Q mail est réputé pour être bien sécurisé. - On considère actuellement que les deux MTA les meilleurs sont postfix et qmail.

Serveurs de messagerie propriétaires (MTA) (2)
Logiciels de messagerie d’entreprise le plus souvent intégrés dans des suites bureautiques ou serveurs WEB. Exchange/Internet Information Service (MTA commun Microsoft à la mesagerie exchange et au serveur web IIS) 20% Lotus Notes/Domino (IBM) 2% IMAIL (Ipswitch) 7% - Dans les messageries propriétaires on rencontre les messageries implantées dans les grandes suites bureautiques intégrées de microsoft (exchange) et IBM lotus notes / domino. On note que microsoft a fusionné ses MTA développés dans le cadre de la messagerie exchange et dans le cadre du serveur web IIS. - Ipswitch propose un logiciel de messagerie assez bon marché qui évolue vers une suite bureautique.

Serveurs de délivrance de messages (MDA)
Gestion de boite à lettres (stockage), filtrage des messages, envoi de message de réponse automatique. Différentes versions: procmail (logiciel libre le plus répandu), deliver, mailfilter, maildrop. Des MDA sont aussi intégrés aux grands logiciels de messagerie intégrés (Exim, Exchange). Existence de standards de boite aux lettres mbox/mailbox , maildir. Les MDA incorporent aussi les outils de protection contre les virus et le SPAM (très grande variété de produits SpamAssassin, Vipul ’s Razor). - On rappelle que les serveurs de délivrance de messages assurent la gestion des boites à lettres, le filtrage des messages entrants et éventuellement les envois de réponse ou d'accusés de réception automatiques. - On a un certain nombre de versions de logiciels libres MDA comme procmail, deliver, mailfilter, maildrop. Par ailleurs les grandes suites bureautiques comprenant des messageries ont également des implantations de MDA. - Notons au passage qu'il existe aussi des formats standards de boite à lettre mbox le premier format défini avec sendmail a évolué un peu avec mailbox puis on a le format maildir. - Enfin c'est au niveau du MDA que l'entreprise peut installer des filtres de sécurité généraux. Les filtres anti spam protègent contre le courrier non sollicité et les filtres anti virus cherchent à éliminer les virus connus. Il y a une très grande variété de filtres anti spam et anti virus.

Serveurs d’accès aux messages (MAA)
Permettre à un MUA d’accèder à une boite à lettre. Versions protocole propriétaire et surtout version POP ou IMAP. Quelques versions: qpopper (protocole POP3), courrier_imap (POP et IMAP), uw_Pop et uw_IMAP (université de Washington). - Les serveurs d'accès au courrier permettent à un client de messagerie MUA d'accéder à une boite à lettre en supportant un protocole de communication pour la relève des messages. On peut trouver des protocoles de relève propriétaires dans le cadre de messageries propriétaires mais on trouve sutout des maa qui sont des répondeurs POP ou IMAP. - Nous cions sur ce transparent quelques produits spécialisés dans la fonction MAA, qpopper, courrier impa et un produit d'assez bonne réputation développé par l'université de Washington en version POP et en version IMAP.

Clients de messagerie (MUA)
Clients lourds: Nécessite l’installation d ’une application particulière sur le poste client. Quelques versions: Outlook Express, Netscape Messenger puis Mozilla Thenderbird, Eudora, Incredi mail, foxmail … Clients légers (clients WEB WEBMAIL): Pour consulter du courrier avec une application client serveur WEB. Quelques exemples: sqWebMail, IMP, SquirrelMail, ... - Les clients de messagerie MUA se répartissent entre les clients lourds qui nécessitent le déploiement d'un logiciel particulier de messagerie et clients légers qui sont basés sur le web. - On fait entrer dans ce cas des clients lourds les clients de messagerie intégrés à des navigateurs WEB. Le plus répandu des clients lourds est outlook express car il est diffusé avec windows. On a aussi des clients autonomes comme Eudora, Incredi mail ou foxmail. Beaucoup d'usagers utilisent les clients intégrés dans les navigateurs de la classe Netscape/Mozilla mais netscape messenger n'est plus entretenu donc seul subsiste le client de mozilla. - Dans le domaine des clients légers ou webmail on fait entrer toutes les versions de clients développés sous la forme de page web dynamique. Ce sont des codes pas trop difficile à développer et il en existe une cinquantaine. On a extrait sqWebmail, IMP et squirrel mail.

Conclusion: messagerie Internet
Venons en à la conclusion générale de ce cours consacré à la messagerie.

Importance de la messagerie et de la messagerie Internet
Un moyen de communication majeur dans l’entreprise, entre entreprises ou entre particuliers. Une attente de plus en plus importante vis à vis de la messagerie: intégration de la circulation d’information, outils de travail coopératifs. Une évolution permanente des messageries standards ou propriétaires vers les standards Internet. Internet est devenue la seule messagerie fédératrice. Une des applications les plus importante de l’Internet. En conclusion on peut commencer par revenir sur l'importance majeure qu'a prise la messagerie dans l'entreprise. - La messagerie et plus précisément la messagerie Internet est devenue un moyen de communication essentiel pour les entreprises, pour les relations clientèle ou fournisseur ou entre particulier. Certes la messagerie n'est peut être pas aussi importante que le courrier papier et bien sur que le téléphone mais elle se place comme un compétiteur de ces outils alors qu'à ses débuts elle était conçue comme un divertissement pour universitaires. - On a donc une attente de plus en plus réelle vis à vis des systèmes de messagerie en tant qu'outil de communication qui permet une forme de circulation d'information entre individus ou entre programmes très utile dans le cadre de l'intégration d'applications ou de travail coopératif. - Pour terminer cet exposé on peut dire que si une messagerie normalisée OSI a été définie (la messagerie X400), si de très nombreux systèmes de messagerie propriétaires ont été développés, on constate aujourd'hui une convergence très importante vers les standards de messagerie Internet. Actuellement la messagerie Internet est devenue la seule messagerie fédératrice c'est à dire permettant à d'autres messageries de communiquer. Les autres systèmes de messagerie qui subsistent sont des fonctionnalités intégrées dans des plate-formes comme la messagerie notes. Ces messageries propriétaires communiquent en Internet. - La messagerie est avec le WEB l'une des applications les plus importante du réseau Internet.

Difficultés de la messagerie Internet
Problèmes de sécurité de la messagerie Sécurisation en confidentialité, intégrité, authentification (S-MIME) Vulnérabilité de ce média aux différentes attaques (virus). Problèmes de l’engorgement par le courrier non sollicité (‘ spam ’). Pour finir quelques difficultés actuelles de la messagerie Internet. - De par son importance et sa possibilité de pénétration, la messagerie est devenue un enjeu important de sécurité. On a tout d'abord les problèmes classiques de la sécurité en confidentialité intégrité et authentification des courriers. Des solutions classqiues de sécurité ont été développées dans le cadre des normes SMIME mais elles ne sont pas très utilisées car elles nécessitent la définition d'une politique de sécurité et elles sont lourdes à administrer. - Un autre problème est que la messsagerie est devenue un vecteur privilégie des attaques par virus. D'ou la mise en oeuvre de filtres anti virus à différents niveaux de la messagerie. - Enfin une dernier problème assez grave est associé au volume de circulation de publicités sous la forme de courriers non sollicités. Ce courrier parasite monopolise des ressources importantes et un temps de travail non négligeable pour y faire face. D'ou la nécessité de filtres efficaces et de modification de la réglementation.

La messagerie électronique Exemple de la messagerie Internet

Présentations similaires

Présentation au sujet: "La messagerie électronique Exemple de la messagerie Internet"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

La messagerie électronique Exemple de la messagerie Internet

Présentations similaires

Présentation au sujet: "La messagerie électronique Exemple de la messagerie Internet"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back