Chapitre 7
La messagerie électronique
Lecture : 29 minQuiz de 5 questions
## Objectifs et prérequis
**Objectifs** : À la fin de ce chapitre, l’élève sera capable de :
- Définir précisément ce qu’est un message électronique et en distinguer les différents champs (en‑tête, corps, pièces jointes).
- Expliquer le rôle des protocoles SMTP, POP3 et IMAP ainsi que leurs ports associés.
- Configurer un compte de messagerie sur un client (ex. Thunderbird, Outlook) ou via une interface web.
- Lire et interpréter les en‑têtes d’un courriel (From, To, Date, Subject, Message‑ID, Received, etc.).
- Évaluer la taille maximale d’un message en fonction des pièces jointes et des limites du serveur.
- Identifier les principales menaces (spam, phishing, malware) et mettre en œuvre les mesures de base de sécurité (filtrage, authentification SPF/DKIM/DMARC, chiffrement TLS).
- Utiliser les bonnes pratiques de gestion de la boîte de réception (dossiers, règles, archivage, quotas).
**Prérequis** :
- Notions de base des réseaux informatiques (adresse IP, modèle client‑serveur, protocole TCP/IP).
- Connaissance du fonctionnement d’un navigateur web et de la saisie d’URL.
- Savoir manipuler des fichiers (création, renommage, téléchargement).
- Familiarité avec l’orthographe et la rédaction d’un texte court en français.
> **Définition clé** : Un *message électronique* (ou *e‑mail*) est un texte numérique transmis d’un expéditeur à un ou plusieurs destinataires par l’intermédiaire d’un serveur de messagerie utilisant le protocole SMTP pour l’envoi et POP3/IMAP pour la réception.
## Introduction contextualisée
Depuis l’invention du premier système de messagerie électronique en 1971 par Ray Tomlinson (qui a introduit le symbole « @ » pour séparer le nom d’utilisateur du nom d’hôte), le courriel est devenu le pilier de la communication professionnelle et personnelle. Au Cameroun, selon les données de l’Agence de Régulation des Télécommunications (ART) publiées en 2023, plus de 68 % des entreprises utilisent quotidiennement le courriel pour échanger des documents administratifs, des factures ou des correspondances avec leurs partenaires internationaux.
Le courriel présente plusieurs avantages : il est asynchrone (le destinataire peut lire le message lorsqu’il est disponible), il permet de joindre des fichiers de divers types (texte, image, vidéo, archive) et il laisse une trace écrite facilement archivable. Toutefois, son usage implique la maîtrise de concepts techniques (protocoles, formats d’en‑tête, limites de taille) et de bonnes pratiques de sécurité afin de se prémunir contre le spam, le phishing ou la diffusion de logiciels malveillants.
Ce chapitre propose une étude complète de la messagerie électronique, conforme au programme officiel du MINESEC/IGE pour la classe de 3ᵉ, en adoptant une approche par compétences : l’élève ne se contente pas de mémoriser des définitions, il apprend à *décrire*, *expliquer*, *mettre en œuvre* et *évaluer* des situations réelles liées au courriel.
## Développement
### I. Principes de base de la messagerie électronique
#### 1. Structure d’une adresse électronique
Une adresse e‑mail respecte la forme **local‑part@domain** où :
- *local‑part* (ou *boîte aux lettres*) est une chaîne de caractères autorisée par la RFC 5322 (lettres, chiffres, points, tirets).
- *domain* est un nom de domaine entièrement qualifié (ex. : `example.cm`) correspondant à un ou plusieurs enregistrements MX (Mail Exchange) dans le DNS.
> **Règle de validation** : Selon la RFC 5322, le *local‑part* ne peut pas commencer ou finir par un point, ne peut pas contenir deux points consécutifs, et ne peut pas dépasser 64 octets. Le *domain* ne peut pas dépasser 255 octets.
**Démonstration** : Prenons l’adresse `jean.dupont@univ-yaounde.cm`.
- Le *local‑part* `jean.dupont` comporte 11 caractères, aucun point en début/fin, pas de double point → valide.
- Le *domain* `univ-yaounde.cm` comporte 18 caractères, chaque étiquette séparée par un point respecte la limite de 63 octets → valide.
**Exemple 1 (simple)** : Vérifier la validité de `user.name@sub.domain.cm`.
- *local‑part* = `user.name` (9 caractères, pas de point initial/final, pas de double point) → OK.
- *domain* = `sub.domain.cm` (3 étiquettes : `sub` = 3, `domain` = 6, `cm` = 2 → toutes ≤ 63) → OK.
Conclusion : adresse valide.
**Exemple 2 (délicat)** : Vérifier `..bad..@.invalid.`.
- *local‑part* commence par un point → violation.
- *domain* commence par un point → violation.
Conclusion : adresse non valide.
#### 2. En‑tête d’un message électronique
L’en‑tête (header) d’un courriel est constitué de champs *name: value* séparés par un saut de ligne. Les champs les plus courants sont :
| Champ | Signification | Exemple |
|------------------|--------------------------------------------|--------------------------------------|
| `From` | Adresse de l’expéditeur | `From: alice@example.cm` |
| `To` | Adresse(s) du(des) destinataire(s) | `To: bob@school.cm, carol@univ.cm` |
| `Cc` | Copie carbone | `Cc: admin@domain.cm` |
| `Bcc` | Copie carbone aveugle | `Bcc: secret@partner.cm` |
| `Date` | Date et heure d’envoi (format RFC 5322) | `Date: Tue, 21 Nov 2025 14:35:00 +0100` |
| `Subject` | Objet du message | `Subject: Devoir de mathématiques` |
| `Message-ID` | Identifiant unique du message | `Message-ID: <20251121143500.12345@server.cm>` |
| `Received` | Chaîne de relais serveur (ajoutée à chaque hop) | `Received: from mail.provider.cm (mail.provider.cm [196.45.12.78]) by mx.example.cm (Postfix) with ESMTPS id 3B7C9F1A23 for <bob@school.cm>; Tue, 21 Nov 2025 14:35:00 +0100` |
| `MIME-Version` | Version du protocole MIME (multipurpose) | `MIME-Version: 1.0` |
| `Content-Type` | Type du corps (texte/plain, texte/html, multipart/…) | `Content-Type: text/plain; charset=UTF-8` |
| `Content-Transfer-Encoding` | Codage du transfert (7bit, quoted‑printable, base64) | `Content-Transfer-Encoding: base64` |
> **Propriété importante** : Les champs `Received` sont ajoutés *en tête* à chaque relais SMTP ; en les lisant de bas en haut, on reconstruit le chemin parcouru par le message.
**Exemple 1 (lecture d’en‑tête)** :
Soit l’en‑tête suivant extrait d’un message reçu :
```
Received: from mail.google.com (mail.google.com [209.85.220.41])
by mx.school.cm (Postfix) with ESMTPS id A1B2C3D4
for <eleve@school.cm>; Mon, 20 Nov 2025 09:12:05 +0000
Received: from [192.168.1.45] (unknown [192.168.1.45])
by mail.google.com with ESMTPS id 5F6G7H8I9J
for <eleve@school.cm>; Mon, 20 Nov 2025 09:10:12 +0000
From: professeur@univ-yaounde.cm
To: eleve@school.cm
Subject: Rappel du contrôle continu
Date: Mon, 20 Nov 2025 09:10:00 +0000
Message-ID: <20251120091000.54321@univ-yaounde.cm>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
```
- Le premier `Received` (en bas) montre que le message provient de l’adresse IP locale `192.168.1.45` (probablement le poste de l’expéditeur) et a été accepté par `mail.google.com`.
- Le deuxième `Received` indique que `mail.google.com` a relayé le message vers `mx.school.cm`.
- Ainsi, le chemin est : poste expéditeur → serveur Gmail → serveur scolaire.
**Exemple 2 (détection d’anomalie)** :
Un message prétend venir de `banque@securite.cm` mais l’en‑tête `Received` montre :
```
Received: from unknown [185.12.34.56] (helo=spam-host.net)
by mx.provider.cm with SMTP id 9Z8Y7X6W5V
for <client@provider.cm>; Fri, 15 Nov 2025 03:22:10 +0000
```
L’adresse IP `185.12.34.56` appartient à un réseau connu pour diffuser du spam (liste noire Spamhaus). Le champ `From` usurpe donc une identité légitime → probable tentative de phishing.
#### 3. Corps du message et encodage MIME
Le corps peut être :
- **texte simple** (`text/plain`) – lisible tel quel.
- **texte enrichi** (`text/html`) – permet mise en forme, images intégrées.
- **multipart** – combinaison de plusieurs parties (ex. texte + HTML + pièce jointe).
Le codage de transfert (`Content-Transfer-Encoding`) assure que les données binaires (images, PDF) traversent sans altération les relais qui ne supportent que l’ASCII 7 bits. Les schémas les plus utilisés sont :
- `7bit` : texte ASCII uniquement.
- `quoted-printable` : texte contenant quelques caractères non‑ASCII, encodés par `=` suivi de deux chiffres hexadécimaux.
- `base64` : transforme tout flux binaire en chaîne ASCII composée de A‑Z, a‑z, 0‑9, +, /, avec remplissage `=`.
> **Formule de taille base64** : Si le fichier original occupe *S* octets, sa représentation base64 occupe environ $\lceil \frac{4S}{3} \rceil$ octets (car 3 octets → 4 caractères).
**Exemple 1 (calcul de taille)** : Une pièce jointe PDF de 1 500 000 octets (≈ 1,43 Mo) est encodée en base64.
Taille approximée : $\lceil \frac{4 \times 1\,500\,000}{3} \rceil = \lceil 2\,000\,000 \rceil = 2\,000\,000$ octets ≈ 1,91 Mo.
Ainsi, le message gagnera environ 0,48 Mo dû à l’encodage.
**Exemple 2 (décodage quoted‑printable)** : La chaîne `=E9` représente le caractère accentué « é » (code ISO‑8859‑1 = 0xE9). Dans un corps `quoted-printable`, on retrouve `=E9` → après décodage on obtient `é`.
### II. Protocoles de transfert et d’accès
#### 1. SMTP (Simple Mail Transfer Protocol) – envoi
SMTP fonctionne sur le port TCP 25 (ou 587 pour la soumission authentifiée, 465 pour SMTPS). Il repose sur un échange de commandes texte entre le client (expéditeur) et le serveur (MTA – Mail Transfer Agent).
**Séquence typique** :
1. **Connexion TCP** : client → serveur (SYN, SYN‑ACK, ACK).
2. **Bannière serveur** : `220 smtp.example.cm ESMTP Postfix`.
3. **HELO/EHLO** : client s’identifie (`EHLO client.cm`).
4. **MAIL FROM** : indique l’expéditeur (`MAIL FROM:<alice@example.cm>`).
5. **RCPT TO** : indique chaque destinataire (`RCPT TO:<bob@school.cm>`).
6. **DATA** : annonce le début du corps du message.
7. **Contenu du message** : lignes se terminant par `<CR><LF>.<CR><LF>` (un point seul sur une ligne termine le DATA).
8. **QUIT** : termine la session.
> **Règle fondamentale** : Chaque commande SMTP doit être suivie d’une réponse numérique à trois chiffres du serveur (ex. : `250 OK`, `354 Start mail input`, `550 Mailbox unavailable`).
**Démonstration de la fiabilité** : SMTP utilise TCP, donc il garantit la livraison ordonnée et sans perte des octets. Si un segment est perdu, TCP le retransmet avant que l’application SMTP ne le traite.
**Exemple 1 (session SMTP simplifiée)** :
Supposons que nous voulons envoyer un message de `alice@school.cm` à `bob@provider.cm`.
```
C: EHLO school.cm
S: 250-smtp.provider.cm
S: 250-PIPELINING
S: 250 SIZE 10485760
C: MAIL FROM:<alice@school.cm>
S: 250 OK
C: RCPT TO:<bob@provider.cm>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: alice@school.cm
C: To: bob@provider.cm
C: Subject: Test SMTP
C:
C: Ceci est un test de connexion SMTP.
C: .
S: 250 OK: queued as 12345
C: QUIT
S: 221 Bye
```
- Après `DATA`, le serveur répond `354` indiquant qu’il attend le corps.
- Le point seul sur une ligne (`C: .`) termine le DATA.
- Le serveur confirme l’acceptation avec `250 OK`.
**Exemple 2 (erreur de taille)** :
Un serveur limite la taille des messages à 5 Mo (`SIZE 5242880`). Si un client tente d’envoyer un message de 6 Mo, la séquence sera :
```
C: MAIL FROM:<alice@school.cm>
S: 250 OK
C: RCPT TO:<bob@provider.cm>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: [6 Mo de données]
C: .
S: 552 5.3.4 Message size exceeds fixed maximum message size
```
Le serveur refuse le message avec le code `552`.
#### 2. POP3 (Post Office Protocol version 3) – réception en mode « download‑and‑delete »
POP3 fonctionne sur le port TCP 110 (ou 995 pour POP3S avec TLS). Il permet à un client de récupérer les messages depuis une boîte aux lettres située sur le serveur, puis généralement de les supprimer du serveur (selon la configuration).
**Commandes essentielles** :
| Commande | Description | Réponse typique |
|----------|------------------------------------------|-----------------|
| `USER` | Nom d’utilisateur | `+OK` |
| `PASS` | Mot de passe | `+OK` |
| `STAT` | Nombre de messages et taille totale | `+OK n m` |
| `LIST` | Taille de chaque message | `+OK scan listing follows`<br>`1 1200`<br>`2 3450`<br>`.` |
| `RETR n` | Récupère le message numéro *n* | `+OK n octets`<br>`[contenu]`<br>`.` |
| `DELE n` | Marque le message *n* pour suppression | `+OK` |
| `QUIT` | Termine la session et effectue les suppressions marquées | `+OK` |
> **Propriété** : Après un `QUIT`, les messages marqués `DELE` sont définitivement supprimés du serveur. Si le client se déconnecte sans envoyer `QUIT`, aucun message n’est supprimé (les marques sont perdues).
**Exemple 1 (relevé simple)** :
Un client se connecte à `pop3.mail.cm` et veut relever ses deux messages.
```
C: USER alice
S: +OK
C: PASS secret123
S: +OK
C: STAT
S: +OK 2 4800
C: LIST
S: +OK scan listing follows
S: 1 2100
S: 2 2700
S: .
C: RETR 1
S: +OK 2100 octets
S: [contenu du message 1]
S: .
C: DELE 1
S: +OK
C: RETR 2
S: +OK 2700 octets
S: [contenu du message 2]
S: .
C: DELE 2
S: +OK
C: QUIT
S: +OK
```
À la fin, les deux messages sont supprimés du serveur.
**Exemple 2 (conservation sur le serveur)** :
Le même scénario, mais le client omet les commandes `DELE`. Après `QUIT`, les messages restent sur le serveur et pourront être relevés à nouveau par un autre client.
#### 3. IMAP (Internet Message Access Protocol version 4) – réception en mode synchronisé
IMAP utilise le port TCP 143 (ou 993 pour IMAPS avec TLS). Contrairement à POP3, IMAP laisse les messages sur le serveur et permet de gérer plusieurs dossiers, des drapeaux (lu, répondu, marqué) et des recherches côté serveur.
**Commandes principales** (préfixées par une étiquette client, ex. : `a001`) :
| Commande | Description |
|----------|-------------|
| `a001 LOGIN user password` | Authentification |
| `a002 SELECT INBOX` | Sélection de la boîte de réception |
| `a003 FETCH 1 (FLAGS BODY[HEADER.FIELDS (FROM TO SUBJECT DATE)])` | Récupération d’en‑têtes sélectives |
| `a004 STORE 1 +FLAGS (\Seen)` | Marquer un message comme lu |
| `a005 COPY 2 INBOX.Archive` | Copier un message dans un autre dossier |
| `a006 LOGOUT` | Terminer la session |
> **Propriété importante** : IMAP permet à plusieurs clients de voir le même état (ex. : si un message est marqué comme lu sur un client, les autres clients le voient également lu après synchronisation).
**Exemple 1 (lecture sélective d’en‑tête)** :
Un client veut connaître l’expéditeur et l’objet des trois premiers messages de la boîte `INBOX`.
```
C: a001 LOGIN alice secret123
S: a001 OK LOGIN completed
C: a002 SELECT INBOX
S: * 22 EXISTS
S: * 0 RECENT
S: a002 OK [READ-WRITE] SELECT completed
C: a003 FETCH 1:3 (FLAGS BODY[HEADER.FIELDS (FROM SUBJECT)])
S: * 1 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS (FROM SUBJECT)] {84}
S: From: professeur@univ-yaounde.cm
S: Subject: Devoir de mathématiques
S: )
S: * 2 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS (FROM SUBJECT)] {78}
S: From: admin@school.cm
S: Subject: Planning du semestre
S: )
S: * 3 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS (FROM SUBJECT)] {92}
S: From: ami@domain.cm
S: Subject: Sortie ce weekend
S: )
S: a003 OK FETCH completed
```
Le serveur renvoie uniquement les champs demandés, réduisant la bande passante.
**Exemple 2 (gestion de dossiers)** :
Un utilisateur veut archiver le message numéro 5 dans le dossier `Archive`.
```
C: a004 COPY 5 Archive
S: a004 OK COPY completed
C: a005 STORE 5 +FLAGS (\Deleted)
S: a005 OK STORE completed
C: a006 EXPUNGE
S: * 5 EXPUNGE
S: a006 OK EXPUNGE completed
C: a007 LOGOUT
S: a007 OK LOGOUT completed
```
Après `EXPUNGE`, le message est définitivement supprimé de `INBOX` mais une copie demeure dans `Archive`.
### III. Sécurité, bonnes pratiques et gestion
#### 1. Menaces courantes
- **Spam** : messages non sollicités, souvent publicitaires.
- **Phishing** : tentative d’obtention d’informations confidentielles (identifiants, coordonnées bancaires) en se faisant passer pour une entité de confiance.
- **Malware** : pièces jointes contenant des virus, chevaux de Troie ou ransomware.
- **Usurpation d’identité (spoofing)** : falsification de l’adresse `From` pour faire croire que le message provient d’une source légitime.
#### 2. Mesures de protection
**a. Authentification de l’expéditeur**
- **SPF (Sender Policy Framework)** : enregistrement DNS spécifiant quels serveurs sont autorisés à envoyer du courriel pour un domaine.
- **DKIM (DomainKeys Identified Mail)** : signature cryptographique ajoutée à l’en‑tête, vérifiable via la clé publique publiée en DNS.
- **DMARC (Domain-based Message Authentication, Reporting & Conformance)** : politique qui indique au receveur comment traiter les messages qui échouent à SPF ou DKIM (none, quarantine, reject) et fournit des rapports.
> **Exemple d’enregistrement SPF** : `v=spf1 ip4:196.45.12.0/24 include:_spf.google.com ~all`
> Cela autorise les adresses IP du réseau `196.45.12.0/24` et les serveurs de Google à envoyer du courriel pour le domaine, tout autre serveur entraîne un `~all` (soft fail).
**b. Chiffrement du transport**
- **TLS (Transport Layer Security)** : utilisé sur les ports 587 (SMTP soumis avec STARTTLS), 465 (SMTPS), 995 (POP3S) et 993 (IMAPS). Il chiffre la totalité de la session TCP, empêchant l’écoute passive.
**c. Chiffrement de bout en bout**
- **PGP/GPG** ou **S/MIME** : chiffrement du corps du message (et éventuellement des pièces jointes) avec la clé publique du destinataire ; seul le détenteur de la clé privée peut le déchiffrer.
**d. Filtrage anti‑spam et anti‑malware**
- Listes noires (RBL) basées sur l’adresse IP du relais.
- Analyse de contenu (Bayesien, règles heuristiques).
- Analyse d’URL dans le corps pour détecter des liens vers des sites de phishing.
> **Règle de base** : Jamais ouvrir une pièce jointe provenant d’un expéditeur inconnu sans l’avoir préalablement scannée avec un antivirus à jour.
#### 3. Bonnes pratiques de gestion
- **Organisation** : créer des dossiers/thèmes (ex. : `Projets`, `Factures`, `Personnel`) et utiliser des règles de filtrage automatique (ex. : déplacer tous les messages contenant le mot « facture » dans le dossier `Factures`).
- **Quotas** : surveiller l’espace utilisé (souvent limité à 2 Go ou 5 Go selon le fournisseur) ; archiver ou supprimer les anciens messages.
- **Sauvegarde** : exporter périodiquement la boîte aux lettres au format `mbox` ou `eml` afin de disposer d’une copie hors ligne.
- **Déconnexion** : toujours se déconnecter (`QUIT` pour POP3/IMAP, fermeture sécurisée de la session web) après utilisation sur un poste partagé.
#### 4. Calcul de la taille maximale d’un message
La taille maximale autorisée par un serveur de messagerie est souvent définie par le paramètre `size_limit` dans la configuration du MTA (ex. : Postfix `message_size_limit`). Cette limite s’applique à la taille totale du message **après** encodage MIME (c’est‑à‑dire le nombre d’octets transmis sur le réseau).
> **Formule** :
> \[
> T_{\text{max}} = L_{\text{server}} - \bigl( H_{\text{headers}} + O_{\text{MIME}} \bigr)
> \]
> où :
> - $L_{\text{server}}$ = limite imposée par le serveur (en octets).
> - $H_{\text{headers}}$ = taille approximée des en‑têtes (souvent entre 500 et 2000 octets).
> - $O_{\text{MIME}}$ = surcharge due au codage (ex. : base64 ajoute ≈ 33 %).
**Exemple 1** : Un serveur fixe `message_size_limit = 10 Mo` (= 10 485 760 octets). On estime les en‑têtes à 1 500 octets et on prévoit d’utiliser du base64 pour une pièce jointe.
On veut connaître la taille maximale du fichier original *S* que l’on peut joindre.
La taille totale après encodage base64 est :
\[
T = H_{\text{headers}} + \bigl\lceil \tfrac{4S}{3} \bigr\rceil
\]
On impose $T \le L_{\text{server}}$ :
\[
\bigl\lceil \tfrac{4S}{3} \bigr\rceil \le L_{\text{server}} - H_{\text{headers}} = 10\,485\,760 - 1\,500 = 10\,484\,260
\]
En négligeant le plafond pour une première approximation :
\[
\tfrac{4S}{3} \le 10\,484\,260 \;\Longrightarrow\; S \le \tfrac{3}{4} \times 10\,484\,260 \approx 7\,863\,195\text{ octets} \approx 7,5\text{ Mo}
\]
Ainsi, on peut joindre en toute sécurité un fichier d’environ **7,5 Mo** (après encodage base64 le message fera ~10 Mo).
**Exemple 2 (vérification concrète)** :
On veut envoyer une archive ZIP de 8 Mo (8 388 608 octets).
Taille base64 : $\lceil \frac{4 \times 8\,388\,608}{3} \rceil = \lceil 11\,184\,810.\overline{6} \rceil = 11\,184\,811$ octets.
Ajout des en‑têtes (1 500 octets) → total ≈ 11 186 311 octets > 10 485 760 octets → le serveur refusera le message.
Il faudra soit réduire la taille de la pièce jointe, soit utiliser un serveur avec une limite plus élevée, soit envoyer le fichier via un service de partage de liens (ex. : WeTransfer, Google Drive) et ne mettre que le lien dans le courriel.
## Synthèse du chapitre
- **Adresse e‑mail** : `local-part@domain` ; validation selon RFC 5322 (longueur, caractères interdits).
- **En‑tête** : champs `From`, `To`, `Date`, `Subject`, `Message-ID`, `Received`, `MIME-Version`, `Content-Type`, `Content-Transfer-Encoding`. Les lignes `Received` permettent de tracer le chemin du message.
- **Protocoles** :
- **SMTP** (port 25/587) pour l’envoi, séquence `EHLO → MAIL FROM → RCPT TO → DATA → QUIT`.
- **POP3** (port 110/995) pour la réception en mode download‑and‑delete, commandes `USER`, `PASS`, `STAT`, `LIST`, `RETR`, `DELE`, `QUIT`.
- **IMAP** (port 143/993) pour la réception synchronisée, permet gestion de dossiers, drapeaux, recherche côté serveur.
- **Sécurité** : SPF, DKIM, DMARC pour l’authentification ; TLS pour le chiffrement de transport ; PGP/GPG ou S/MIME pour le chiffrement de bout en bout ; filtrage anti‑spam/anti‑malware ; vigilance face aux pièces jointes et aux liens suspects.
- **Bonnes pratiques** : organisation par dossiers, règles de filtrage, respect des quotas, sauvegarde régulière, déconnexion après usage.
- **Limites de taille** : taille totale du message (en‑têtes + corps encodé) doit rester inférieure à la limite du serveur (`message_size_limit`). Le codage base64 augmente la taille d’environ 33 %.
## Glossaire
| Terme | Définition |
|-------|------------|
| **Adresse e‑mail** | Chaîne de la forme `local-part@domain` identifiant de façon unique une boîte aux lettres électronique. |
| **SMTP** | Simple Mail Transfer Protocol, protocole utilisé pour le transfert de messages entre serveurs d’envoi et de réception. |
| **POP3** | Post Office Protocol version 3, protocole de relève de messages en mode download‑and‑delete (suppression optionnelle du serveur). |
| **IMAP** | Internet Message Access Protocol version 4, protocole de relève laissant les messages sur le serveur et permettant la gestion de dossiers et de drapeaux. |
| **MIME** | Multipurpose Internet Mail Extensions, norme permettant d’envoyer des données non‑texte (images, audio, vidéo) et du texte enrichi dans le courriel. |
| **SPF** | Sender Policy Framework, enregistrement DNS qui spécifie quels serveurs sont autorisés à envoyer du courriel pour un domaine. |
| **DKIM** | DomainKeys Identified Mail, méthode d’authentification basée sur une signature cryptographique ajoutée à l’en‑tête du message. |
| **DMARC** | Domain-based Message Authentication, Reporting & Conformance, politique qui indique comment traiter les messages échouant à SPF/DKIM et fournit des rapports de retour. |
| **TLS** | Transport Layer Security, protocole de chiffrement sécurisant la connexion TCP entre client et serveur (utilisé sur les ports 587, 465, 993, 995). |
| **Pièce jointe** | Fichier encapsulé dans un message MIME, généralement encodé en base64 pour garantir son intégrité lors du transfert. |
| **Quota** | Limite d’espace de stockage allouée à une boîte aux lettres sur le serveur de messagerie. |
| **Phishing** | Technique de fraude consistant à tromper l’utilisateur pour qu’il révèle des informations confidentielles en se faisant passer pour une entité de confiance. |
| **Spam** | Courriel non sollicité, généralement à caractère publicitaire ou malveillant, envoyé en masse. |
| **Encodage base64** | Méthode de transformation de données binaires en chaîne ASCII composée de 64 caractères, augmentant la taille d’environ 33 %. |
## Exercices d'application corrigés
### Exercice 1 – Validation d’adresse
**Énoncé** : Déterminer laquelle des adresses suivantes est valide selon la RFC 5322 :
a) `jean.dupont@univ-yaounde.cm`
b) `..bad..@.invalid.`
c) `user+tag@sub.domain.cm`
d) `user@domain..cm`
**Corrigé** :
- **a)** `jean.dupont@univ-yaounde.cm` :
- *local‑part* = `jean.dupont` (pas de point initial/final, pas de double point) → OK.
- *domain* = `univ-yaounde.cm` (étiquettes `univ-yaounde` = 12, `cm` = 2, toutes ≤ 63) → OK.
→ **Valide**.
- **b)** `..bad..@.invalid.` :
- *local‑part* commence par un point → violation.
- *domain* commence et finit par un point → violation.
→ **Non valide**.
- **c)** `user+tag@sub.domain.cm` :
- Le caractère `+` est autorisé dans le *local‑part* (RFC 5322 le considère comme un « special » autorisé lorsqu’il est entouré de caractères alphanumériques).
- Aucun point interdit, pas de double point.
- *domain* correct.
→ **Valide**.
- **d)** `user@domain..cm` :
- *domain* contient deux points consécutifs (`domain..cm`) → étiquette vide entre les points → non autorisé.
→ **Non valide**.
**Réponse** : Les adresses valides sont **a)** et **c)**.
---
### Exercice 2 – Lecture d’en‑tête et détection de spoofing
**Énoncé** : Voici un extrait d’en‑tête d’un message reçu :
```
Received: from unknown [203.0.113.45] (helo=mail.attacker.net)
by mx.provider.cm with SMTP id 4F3E2D1C
for <victime@provider.cm>; Thu, 14 Nov 2025 02:10:05 +0000
From: service@bank.cm
To: victime@provider.cm
Subject: Urgent : vérifiez votre compte
Date: Thu, 14 Nov 2025 02:09:58 +0000
Message-ID: <20251114020958.98765@bank.cm>
```
Déterminer si le champ `From` est probablement légitime ou s’il s’agit d’un spoofing. Justifier votre réponse à l’aide des informations présentes.
**Corrigé** :
- Le champ `Received` indique que le message provient de l’adresse IP **203.0.113.45**, associée au nom d’hôte `mail.attacker.net` (comme indiqué par le champ `helo=`).
- Cette adresse IP appartient à un bloc qui n’est **pas** associé au domaine `bank.cm` (qui serait vraisemblablement hébergé sur des serveurs de la banque ou de son prestataire de confiance).
- Le champ `From` prétend que l’expéditeur est `service@bank.cm`. Cependant, le serveur qui a effectivement transmis le message (`mx.provider.cm`) a reçu le courriel depuis une source extérieure au domaine de la banque.
- Dans une situation légitime, le premier `Received` (celui du bas) montrerait une adresse IP appartenant à l’infrastructure de `bank.cm` ou à un de ses prestataires autorisés (via SPF). Ici, aucune telle correspondance n’est visible.
- Par conséquent, le champ `From` est très probablement **spoofé** : l’expéditeur tente de se faire passer pour la banque alors que le message provient effectivement d’un serveur non autorisé.
**Conclusion** : Il s’agit d’une tentative de **phishing** (usurpation d’identité).
---
### Exercice 3 – Calcul de taille maximale d’une pièce jointe
**Énoncé** : Un serveur de messagerie impose une limite de taille de message de **20 Mo** (`message_size_limit = 20 Mo`). Les en‑têtes d’un message typique occupent environ **2 Ko**. On souhaite envoyer une pièce jointe encodée en **base64**. Quelle est la taille maximale du fichier original (en Mo) que l’on peut joindre sans dépasser la limite du serveur ?
**Corrigé** :
- Limite serveur : $L = 20\text{ Mo} = 20 \times 2^{20} = 20 \times 1\,048\,576 = 20\,971\,520$ octets.
- Taille des en‑têtes : $H = 2\text{ Ko} = 2 \times 2^{10} = 2\,048$ octets.
- Espace disponible pour le corps encodé : $L - H = 20\,971\,520 - 2\,048 = 20\,969\,472$ octets.
Soit $S$ la taille du fichier original en octets. Après encodage base64, la taille devient $\lceil \frac{4S}{3} \rceil$.
On impose :
\[
\Bigl\lceil \frac{4S}{3} \Bigr\rceil \le 20\,969\,472
\]
En négligeant le plafond pour une première estimation :
\[
\frac{4S}{3} \le 20\,969\,472 \;\Longrightarrow\; S \le \frac{3}{4} \times 20\,969\,472 = 15\,727\,104\text{ octets}
\]
Convertir en mégaoctets :
\[
\frac{15\,727\,104}{2^{20}} \approx \frac{15\,727\,104}{1\,048\,576} \approx 15,0\text{ Mo}
\]
En tenant compte du plafond, la taille maximale réelle est légèrement inférieure, mais la différence est négligeable (< 0,01 Mo).
**Réponse** : On peut joindre en toute sécurité un fichier d’environ **15 Mo** (taille originale) ; après encodage base64 le message fera près de 20 Mo.
---
### Exercice 4 – Configuration d’un compte IMAP
**Énoncé** : Un élève veut configurer son client de messagerie pour relever ses courriels sur le serveur `imap.school.cm` utilisant le port **993** (IMAPS) avec authentification par login/mot de passe. Décrire, étape par étape, les actions que le client effectue du point de vue du protocole IMAP (en incluant les étiquettes client) depuis la connexion jusqu’à la sélection de la boîte de réception `INBOX`.
**Corrigé** :
1. **Établissement de la connexion TCP** : le client ouvre une socket TCP vers `imap.school.cm:993` et effectue le handshake TLS (client hello, serveur hello, échange de clés, vérification du certificat). Une fois le canal TLS établi, la communication se poursuit en texte clair dessus.
2. **Bannière du serveur** : dès que la connexion TLS est prête, le serveur envoie une ligne de bienvenue, par exemple :
```
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE] IMAP4rev1 Service prêt
```
(Cette ligne commence par `*` et n’est pas une réponse à une commande spécifique.)
3. **Commande d’authentification LOGIN** : le client envoie une commande étiquetée, par exemple `a001` :
```
a001 LOGIN eleve@school.cm monMotDePasseSecret
```
Le serveur répond :
```
a001 OK LOGIN completed
```
Si le login ou le mot de passe est erroné, la réponse serait `a001 NO [AUTHENTICATIONFAILED] Authentification échouée`.
4. **Sélection de la boîte de réception** : le client envoie ensuite :
```
a002 SELECT INBOX
```
Le serveur répond avec plusieurs lignes d’information :
- `* 23 EXISTS` → il y a 23 messages dans la boîte.
- `* 0 RECENT` → aucun message récent depuis la dernière ouverture.
- `* FLAGS (\Answered \Flagged \Draft \Seen \Deleted)` → liste des drapeaux supportés.
- `* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Seen \Deleted)]` → indique quels drapeaux peuvent être modifiés de façon permanente.
- Enfin :
```
a002 OK [READ-WRITE] SELECT completed
```
La mention `READ-WRITE` indique que le client peut modifier les états des messages (ex. : les marquer comme lus).
5. **État** : À ce stade, le client est authentifié, la boîte `INBOX` est sélectionnée et prête à recevoir des commandes telles que `FETCH`, `STORE`, `SEARCH`, etc.
---
### Exercice 5 – Détection de spam basée sur une RBL
**Énoncé** : Un serveur de messagerie utilise la liste noire DNS `zen.spamhaus.org` pour filtrer les connexions SMTP. Lors de la tentative d’envoi d’un message, le serveur distant reçoit la réponse suivante après la commande `MAIL FROM` :
```
554 5.7.1 Service unavailable; Client host [185.12.34.56] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/ip/185.12.34.56
```
Expliquer ce qui se passe et quelle action le serveur distant doit entreprendre.
**Corrigé** :
- Après la commande `MAIL FROM`, le serveur distant effectue une recherche DNS inverse (ou directe) sur l’adresse IP du client expéditeur (`185.12.34.56`) dans la zone `zen.spamhaus.org`.
- La réponse DNS retourne une adresse (généralement `127.0.0.2` ou similaire) indiquant que l’IP est listée comme source de spam.
- Le serveur SMTP interprète cette réponse comme un signal de blocage et renvoie le code **554** (erreur de transaction) avec le message explicite indiquant que l’hôte client est bloqué par la liste `zen.spamhaus.org`.
- Selon les bonnes pratiques, le serveur distant doit **refuser** la transaction entière : il ne doit pas accepter les commandes suivantes (`RCPT TO`, `DATA`) et doit fermer la connexion après avoir envoyé le message d’erreur.
- L’administrateur du serveur expéditeur devrait investiguer pourquoi son adresse IP est listée (possibilité d’un compte compromis, d’un envoi de masse non autorisé, etc.) et prendre les mesures correctives (nettoyage, mise à jour du mot de passe, demande de retrait auprès de Spamhaus après résolution du problème).
---
### Exercice 6 – Utilisation d’une règle de filtrage côté client
**Énoncé** : Un étudiant souhaite que tous les messages contenant le mot « devoir » dans l’objet ou le corps soient automatiquement déplacés vers le dossier `Travaux`. Décrivez, en termes de protocole IMAP, comment le client peut mettre en place cette règle côté client (sans intervenir sur le serveur) et quelles commandes IMAP il devra exécuter pour chaque message entrant.
**Corrigé** :
Comme la règle est appliquée **côté client**, le serveur IMAP ne connaît pas la notion de « règle ». Le client doit donc :
1. **Surveiller l’arrivée de nouveaux messages** : soit en utilisant la commande `IDLE` (pour être notifié en temps réel lorsqu’un message arrive dans la boîte sélectionnée), soit en pollant périodiquement avec la commande `NOOP` ou en refaisant un `SELECT INBOX` suivi d’un `STATUS`.
2. **Lorsqu’un nouveau message apparaît** (supposons qu’on sache son numéro de séquence, par exemple `n`) :
- **Récupérer l’en‑tête et éventuellement le corps** pour analyser le contenu :
```
a001 FETCH n (BODY[HEADER.FIELDS (SUBJECT)] BODY[TEXT])
```
Le serveur renvoie les champs `Subject` et, si demandé, une partie du corps (souvent on limite à la première partie texte pour éviter de télécharger tout le message si ce n’est pas nécessaire).
- **Analyser localement** : le client examine la chaîne obtenue pour détecter la présence du mot « devoir » (insensible à la casse).
- **Si le mot est présent** :
- **Copier le message** dans le dossier destination `Travaux` :
```
a002 COPY n Travaux
```
Le serveur répond `a002 OK COPY completed` si le dossier existe ; sinon, le client doit d’abord créer le dossier avec `CREATE Travaux`.
- **Marquer le message original pour suppression** (optionnel, si l’on veut qu’il ne reste plus dans `INBOX`) :
```
a003 STORE n +FLAGS (\Deleted)
```
Puis, pour appliquer la suppression, envoyer `a004 EXPUNGE` (ou compter sur le client expunge automatique selon sa configuration).
- **Si le mot est absent** : aucune action supplémentaire n’est requise ; le message reste dans `INBOX`.
3. **Boucle** : le client répète ces étapes pour chaque nouveau signal reçu (via `IDLE` ou polling).
> **Note** : Cette approche consomme de la bande passante et du temps de traitement côté client, mais elle permet de mettre en place des règles personnalisées sans nécessiter de droits d’administration sur le serveur IMAP.
---
## Erreurs fréquentes
| Erreur fréquente | Pourquoi elle se produit | Comment l’éviter |
|------------------|--------------------------|------------------|
| **Confondre POP3 et IMAP** : croire que POP3 laisse les messages sur le serveur alors qu’il les supprime par défaut. | Méconnaissance du fonctionnement par défaut de POP3 (mode download‑and‑delete). | Vérifier la configuration du client : laisser l’option « Laisser une copie sur le serveur » activée si l’on veut conserver les messages, ou préférer IMAP lorsqu’on utilise plusieurs appareils. |
| **Ne pas vérifier l’en‑tête `Received`** : accepter un message uniquement en se fiant au champ `From`. | Le champ `From` peut être facilement falsifié ; l’en‑tête `Received` montre le véritable chemin. | Toujours examiner les lignes `Received` (de bas en haut) pour détecter une adresse IP ou un domaine inattendu avant de faire confiance à l’expéditeur. |
| **Oublier que le codage base64 augmente la taille** : penser qu’une pièce jointe de 10 Mo restera 10 Mo dans le message. | Le codage base64 transforme 3 octets en 4 caractères, ajoutant ~33 % de surcharge. | Avant d’envoyer une pièce jointe, calculer la taille après encodage (≈ 4/3 × taille originale) et la comparer à la limite du serveur. |
| **Cliquer sur une pièce jointe provenant d’un expéditeur inconnu sans la scanner** : confiance aveugle dans le nom du fichier. | Les pièces jointes peuvent contenir des exécutables déguisés (ex. : `facture.pdf.exe`). | Toujours faire analyser la pièce jointe par un antivirus à jour avant de l’ouvrir, voire préférer ouvrir les fichiers dans un environnement sandboxé. |
| **Ne pas mettre à jour le mot de passe du compte de messagerie** : garder le même mot de passe pendant des mois ou des années. | Un mot de passe compromis peut être utilisé pour envoyer du spam ou voler des données. | Changer le mot de passe régulièrement (au moins tous les 90 jours), utiliser une phrase de passe longue et unique, activer l’authentification à deux facteurs si disponible. |
| **Ignorer les quotas de la boîte aux lettres** : laisser la boîte atteindre sa limite, ce qui bloque la réception de nouveaux messages. | Lorsque la boîte est pleine, le serveur répond avec des erreurs `over quota` lors de la tentative de livraison. | Archiver ou supprimer périodiquement les anciens messages, activer la règle de suppression automatique des messages âgés de plus de X mois, surveiller l’utilisation via l’interface web ou le client. |
---
*Fin du cours de référence.*
Quiz du chapitre
5 questions — vérifie chaque réponse pour voir l'explication.