Portail officiel de la sécurité informatique - ANSSI - République française

Le pourriel est une nuisance reposant sur un usage abusif du courrier électronique. Pour bien comprendre ce phénomène et les techniques pour s’en protéger, il peut être utile de rappeler le fonctionnement du courrier électronique sur l’internet.

MTA — MUA

Le courrier électronique sur l’internet est transmis au travers du protocole SMTP et ses évolutions. La mise en œuvre de ce protocole fait appel à deux types de logiciel :
 le MUA : Mail User Agent est l’outil utilisé pour saisir, lire, sauvegarder des courriers électroniques (Des logiciels comme Outlook ou Thunderbird, par exemple, sont des MUA) ;
 le MTA : Mail Transfert Agent est le logiciel chargé de l’acheminement du courrier électronique (Des logiciels comme postfix, sendmail ou Exchange, par exemple, sont des MTA).

Le transfert du courrier entre deux internautes se passe de la façon suivante.

Alice utilise un logiciel client de messagerie, un MUA. C’est le programme qui lui permet de lire, d’écrire et d’envoyer des courriers électroniques. Alice écrit un message pour Bob. Au moment d’envoyer ce message, le MUA d’Alice contacte le MTA local.

Le rôle d’un MTA est d’acheminer le courriel, en l’aiguillant dans la bonne direction ou d’avertir si le courriel n’a pas pu, pour une raison ou une autre, être délivré à son destinataire.

Lorsque le MUA contacte le MTA, il doit se passer deux choses :
 le MUA doit se présenter auprès du MTA et recevoir l’autorisation d’envoyer du courrier ;
 le MUA doit décrire au MTA à qui le message est destiné et transmettre au MTA le contenu du message.

Dans notre exemple, lorsque Alice désire envoyer son message, le MUA d’Alice se connecte au MTA local. Le MTA local lit l’adresse du destinataire du courriel et découvre qu’il ne s’agit pas d’une adresse locale pour laquelle il suffit de déposer le courriel dans une boîte aux lettres (BAL). Le destinataire du courriel est hors du domaine local. Le MTA local aiguille le courriel vers le MTA de l’entreprise.

Le MTA de l’entreprise découvre que le courriel est destiné à une autre entreprise. Le MTA de l’entreprise a-b.tld cherche à savoir quel est le MTA de l’entreprise c-d.tld (qui est le serveur de messagerie qui accepte de recevoir du courrier pour ce domaine ?). Pour cela il utilise le protocole DNS pour demander le champ MX (voir la section "le MX Record" de cette fiche) du domaine c-d.tld. Avec la réponse du DNS, le MTA de a-b.tld peut s’adresser au MTA de c-d.tld pour lui transmettre le courrier.

Le MTA de c-d.tld reçoit le message et découvre que celui-ci est destiné à Bob et achemine le message électronique vers le serveur de messagerie le plus proche de ce dernier. Arrivé dans le bon service, le message est délivré dans la boîte aux lettres de Bob. Bob consulte son courriel en utilisant un protocole de consultation des boîtes aux lettres, comme par exemple POP3 ou IMAP.

Le protocole SMTP et son extension ESMTP sont utilisés pour la communication entre le MUA et le MTA puis de MTA en MTA.

Relais de messagerie

Un client de messagerie ne s’adresse pratiquement jamais au client de messagerie. En général, le message est convoyé de serveur de messagerie en serveur de messagerie. Un serveur de messagerie qui accepte un courrier pour le transmettre à un autre serveur de messagerie est appelé un relais de messagerie.

Normalement un relais de messagerie est conçu pour acheminer le message à l’intérieur d’une organisation, ou de l’intérieur de celle-ci vers l’extérieur ou de l’extérieur vers l’intérieur.

On dit qu’un serveur de messagerie est ouvert lorsqu’il accepte de relayer des messages issus de n’importe quel domaine (ou plus exactement n’importe quelle plage d’adresses IP) vers n’importe quel domaine (par exemple un serveur de messagerie ouvert en .gouv.fr accepterait du courrier venant des plages d’adresses IP de wanadoo.fr pour l’envoyer vers hotmail.com).

Le protocole SMTP

Le protocole SMTP est décrit dans le document RFC 821. Cette note d’information présente une vision très simplifiée de ce protocole. Il s’agit d’illustrer les points nécessaires à la compréhension de la lutte contre le pourriel.

Transaction SMTP

| MTA de |  | MTA de |  |
| a-b.com |  | c-d.com |  |
|  | EHLO a-b.com |  | le MTA de a-b.com  |
|  | ------> |  | s'identifie   |
|  |  |  |  |
|  | 250-c-d.com |  | le MTA de c-d.com répond |
|  | 250-PIPELINING |  |  |
|  | 250-SIZE 10240000 |  |  |
|  | 250-VRFY |  |  |
|  | 250-ETRN |  |  |
|  | 250-STARTTLS |  |  |
|  | 250 8BITMIME |  |  |
|  | <------ |  |  |
|  |  |  |  |
|  | MAIL FROM: alice@a-b.com |  | le MTA de a-b.com |
|  | ------> |  | précise qui est l'émetteur déclaré |
|  |  |  |  |
|  | 250 Ok |  |  |
|  | <------ |  |  |
|  |  |  |  |
|  | RCPT TO: bob@c-d.com |  | qui est le destinataire |
|  | ------> |  |  |
|  |  |  |  |
|  | 250 Ok |  |  |
|  | <------ |  |  |
|  |  |  |  |
|  | DATA |  |  |
|  | ------> |  |  |
|  |  |  |  |
|  | 354 End data with . |  |  |
|  | <------ |  |  |
|  |  |  |  |
|  | Date: Wed, 28 Sep 2005 11:31:06 +0200 |  | le corps du message  |
|  | From: Alice  |  |  |
|  | To: Bob  |  |  |
|  | Subject: Important! |  |  |
|  | Message-Id: <20050928113106.5b42ecd6.alice@a-b.com> |  |   |
|  | Organization: a-b |  |   |
|  | Mime-Version: 1.0 |   |    |
|  | Content-Type: text/plain; charset= US-ASCII |  |  |
|  | Content-Transfer-Encoding: 7bit |  |  |
|  |  |  |  |
|  | Le texte du message |  |  |
|  | . |  |  |
|  | ------> |  |  |
|  |  |  |  |
|  | 250 Ok: queued as EC967A4C09 |  | le message est accepté |
|  | <------ |  |  |
|  |  |  |  |
|  | QUIT |  |  |
|  | ------> |   |  |
|  |  |  |  |
|  | 221 Bye |  |  |
|  | <------ |  |  |

En particulier, pour toutes les commandes du protocole SMTP, il existe des codes d’erreurs destinés à l’émetteur.

 2xx : les codes commençant par 2 sont des codes montrant que l’opération s’est déroulée correctement ;
 3xx : les codes commençant par 3 signalent des erreurs temporaires...

Quelques autres commandes SMTP

Deux autres commandes SMTP ont une influence notable sur le pourriel. Ce sont :
 VRFY : la commande VERIFY sert à vérifier la présence d’un utilisateur ou d’une boîte aux lettres ;
 EXPN : la commande EXPAND sert à vérifier la présence d’une liste de diffusion et d’obtenir la liste de tous les abonnés de la liste.

Ces deux commandes permettent à un émetteur de pourriel de vérifier ou de confirmer des adresses de courriels.

L’entête d’un message

C’est l’information qui est attachée au message et qui précise les conditions de son acheminement.

Return-Path: 
X-Original-To: bob
Delivered-To: bob@c-d.tld
Received: from a-b.tld (unknown [192.168.100.100])
       by c-d.tld (Postfix) with SMTP id D2FBEA4C09
       for ; Wed, 28 Sep 2005 11:37:10 +0200 (CEST)
Date: Wed, 28 Sep 2005 11:31:06 +0200
From: Alice 
To: bob@c-d.tld
Subject: Important !
Message-Id: <20050928113106.5b42ecd6.alice@a-b.tld>
Organization: CERTA
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status:

Le texte du message

Le champ d’entête Reply-To :

Normalement quand le destinataire souhaite répondre à un message, il utilise la valeur donnée dans le champ From : de l’entête. Cependant, dans certains cas on peut souhaiter que la réponse ne soit pas acheminée à l’émetteur. Pour cela, le champ Reply-To : de l’entête permet de spécifier le ou les destinataires de la réponse au courriel.

Que se passe-t-il en cas de non délivrance d’un message ?

Si, pour une raison quelconque, le courriel ne peut pas être acheminé jusqu’à son destinataire, une bonne pratique, appuyée par une norme RFC, veut que le MTA retourne un message d’erreur sous la forme d’un courriel qui explique pourquoi le message n’a pas pu être acheminé.

Ce type de message d’erreur est appelé DSN, Delivery Status Notification. C’est très utile pour :

 d’un point de vue technique, comprendre les erreurs dans une architecture ou dans la configuration d’un système de messagerie ;
 pour informer l’émetteur que le destinataire n’a pas eu la possibilité de lire le courriel qui lui était destiné.

Pour éviter des boucles (un courriel de d’erreur en réponse à un courriel d’erreur), souvent le courriel d’erreur peut ne pas avoir d’adresse de retour (cf. RFC 821) : MAIL FROM : <>.

Le MX Record

Le champ MX (abréviation de Mail eXchange), identifie dans le DNS le ou les serveurs responsables du traitement des messages pour un domaine particulier.

certa_mail