5.3.1. Étude de cas : SMTP, protocole de transfert de courrier simple Dans l'exemple 5.7. illustre une transaction SMTP (Simple Mail Transfer Protocol), qui est décrite dans la spécification RFC 2821. Dans cet exemple, les lignes commençant par C: sont envoyées par le transport de courrier

5.24 Protocole ARP Avant qu'un datagramme ne soit transféré d'un système LAN à un autre, il sera encadré par un en-tête et une fin de trame. La trame est délivrée à l'adaptateur réseau dont l'adresse physique correspond à l'adresse de destination physique de

8.9 Protocole RIP Le protocole IGP le plus largement utilisé est RIP, dérivé du protocole de routage Xerox Network System (XNS). La popularité de RIP repose sur sa simplicité et sa disponibilité. RIP a été initialement implémenté dans le système d'exploitation TCP/IP.

8.17 BGP Le Border Gateway Protocol (BGP) est largement utilisé sur Internet. La version actuelle du protocole est BGP-4 Dans l'Internet d'aujourd'hui, il existe de nombreux fournisseurs interconnectés à la manière d'un réseau d'interconnexion. Lors d'un déplacement vers un point

14.6 Protocole FTP Les concepts suivants sont associés au protocole FTP : ? Les commandes et leurs paramètres sont-ils envoyés via la connexion de contrôle ? Codes numériques renvoyés en réponse à la commande ? Format de transfert de données Le jeu de commandes FTP est décrit ci-dessous. Elles sont transmises au gestionnaire.

15.17 Protocole NFS La dernière implémentation de NFS est la version 3, bien que les implémentations de la version 2 continuent à être couronnées de succès. Le programme serveur NFS porte le numéro 100003 et, par convention, NFS saisit un

16.9 Commandes SMTP Le script de la section 16.6.1 contient les commandes SMTP les plus couramment utilisées. L'ensemble complet des commandes SMTP est présenté dans le Tableau 16.1 Tableau 16.1 Commandes SMTP Commande Description HELO Identifie l'expéditeur au destinataire. MAIL FROM Démarrez une transaction de messagerie et pointez vers

16.12.2 Boîte de dialogue SMTP améliorée L'exemple suivant montre comment l'agent de transfert de courrier amélioré construit une transaction pour envoyer un message MIME au format 8 bits : ? Le destinataire annonce ses capacités améliorées, y compris 8BITMIME. ? La commande MAIL FROM a

Programmes qui implémentent un serveur SMTP sur un système Sendmail Linux. Le serveur de messagerie le plus populaire, sendmail, est souvent intégré à un système Linux. Ce package fournit de nombreuses fonctionnalités et de nombreux programmes supposent qu'il est installé par défaut.

Particularités du serveur SMTP Les sections suivantes décrivent les différentes caractéristiques du serveur de messagerie définies lors de sa configuration. Afin de ne pas décrire ces caractéristiques pour chaque serveur, nous les considérerons

Aujourd'hui, nous vous parlerons en détail des protocoles les plus utilisés sur Internet - POP3, IMAP et SMTP. Chacun de ces protocoles a un objectif et une fonctionnalité spécifiques. Essayons de comprendre.

Protocole POP3 et ses ports

Post Office Protocol 3 (POP3) est un protocole de messagerie standard créé pour recevoir des e-mails d'un serveur distant à un client de messagerie. POP3 vous permet d'enregistrer un message électronique sur votre ordinateur et même de le lire lorsque vous êtes hors ligne. Il est important de noter que si vous choisissez d'utiliser POP3 pour vous connecter à votre compte de messagerie, les e-mails qui ont déjà été téléchargés sur votre ordinateur seront supprimés du serveur de messagerie. Par exemple, si vous utilisez plusieurs ordinateurs pour vous connecter au même compte de messagerie, POP3 peut ne pas être le meilleur choix dans cette situation. D'autre part, le courrier étant stocké localement, sur le PC d'un utilisateur particulier, cela permet d'optimiser l'espace disque côté serveur de messagerie.

Par défaut, le protocole POP3 utilise les ports suivants :

• Le port 110 est le port de protocole POP3 par défaut. Ce n'est pas sûr.
• Port 995 - Ce port doit être utilisé si vous souhaitez établir une connexion sécurisée.

Protocole et ports IMAP

Internet Message Access Protocol (IMAP) est un protocole de messagerie conçu pour accéder au courrier à partir d'un client de messagerie local. IMAP et POP3 sont les protocoles les plus populaires sur Internet utilisés pour recevoir des e-mails. Ces deux protocoles sont pris en charge par tous les clients de messagerie modernes (MUA - Mail User Agent) et les serveurs WEB.

Alors que POP3 n'autorise l'accès au courrier qu'à partir d'une seule application, IMAP autorise l'accès à partir de plusieurs clients. Pour cette raison, IMAP est plus adaptable dans les cas où l'accès à un compte de messagerie est nécessaire pour plusieurs utilisateurs.

Par défaut, le protocole IMAP utilise les ports suivants :

• Port 143 est le port par défaut. Pas sécurisé.
• Port 993– port pour une connexion sécurisée.

Protocole SMTP et ses ports

Le protocole SMTP (Simple Mail Transfer Protocol) est le protocole standard pour envoyer des messages électroniques Sur internet.

Ce protocole est décrit dans les RFC 821 et RFC 822, publiées pour la première fois en août 1982. Dans le cadre des données RFC, le format d'adresse doit être au format nom d'utilisateur@nom de domaine. La livraison du courrier est similaire au travail d'un service postal régulier : par exemple, une lettre à l'adresse [courriel protégé], sera interprété comme suit : ivan_ivanov est l'adresse et merionet.ru est le code postal. Si le nom de domaine du destinataire diffère du nom de domaine de l'expéditeur, le MSA (Mail Submission Agent) enverra l'e-mail via le Mail Transfer Agent (MTA). L'idée principale de MTA est de rediriger les lettres vers une autre zone de domaine, de la même manière que le courrier traditionnel envoie des lettres vers une autre ville ou région. Le MTA reçoit également du courrier d'autres MTA.

Le protocole SMTP utilise les ports suivants.

SMTP(Simple Mail Transfer Protocol - un protocole de transfert de courrier simple) est un protocole réseau conçu pour transférer des e-mails sur des réseaux TCP/IP. ESMTP(eng. Extended SMTP) - une extension évolutive du protocole SMTP. Actuellement, le "protocole SMTP" fait généralement référence à ESMTP et à ses extensions. SMTP utilise les ports TCP 25.

Le protocole SMTP utilise de simples commandes de texte ASCII et renvoie des réponses codées à trois caractères avec des messages texte. Le protocole SMTP est décrit dans Internet Request For Comment (RFC) numéro 821, qui a été développé par l'Internet Engineering Task Force (IETF) et publié le 21 août 1982. Depuis, il a subi plusieurs modifications, mais en général, les principales commandes du protocole n'ont pas changé.

Commandes client SMTP de base

L'équipe HELO

Par définition, les commandes du protocole SMTP comportent quatre caractères. Le message d'accueil envoyé par le client au serveur est la commande HELO. Le format de la commande est le suivant :

Nom de domaine HELO

Le but de la commande HELO est de présenter le client au serveur SMTP. Malheureusement, cette méthode d'accès a été développée au stade initial du développement d'Internet, alors qu'il n'y avait pas encore autant de tentatives de pénétration non autorisée dans les systèmes informatiques. Comme vous pouvez le voir, le client peut s'appeler n'importe quel nom sur la ligne de commande. Cela a conduit au fait que la plupart des serveurs SMTP utilisent désormais cette commande de manière purement formelle. S'ils essaient vraiment d'identifier le client, un mécanisme de recherche DNS inversé entre en jeu pour déterminer le nom d'hôte réel du client en fonction du système de noms de domaine à partir de son adresse IP. Généralement, pour des raisons de sécurité, les serveurs SMTP refusent de se connecter aux hôtes dont l'adresse IP ne correspond pas à un nom d'hôte correspondant. En envoyant cette commande, le client notifie au serveur qu'il veut établir une connexion avec lui. En réponse à cette commande, le serveur notifie à son tour qu'une nouvelle connexion a été établie avec le client et qu'il est prêt à accepter d'autres commandes de sa part.

Lorsque vous travaillez avec le protocole SMTP, une distinction doit être faite entre les clients SMTP. Les utilisateurs clients et les hôtes clients ne sont pas la même chose. Lors de la création d'un message électronique, l'utilisateur du système de messagerie est également un client de son hôte local. Une fois le message électronique envoyé, il n'est plus un client du processus SMTP. Désormais, son ordinateur hôte local gère le processus de livraison des messages et agit lui-même comme un client SMTP. Lorsqu'un hôte local se connecte à un hôte distant pour envoyer un message à l'aide du protocole SMTP, il agit en tant que client du processus SMTP. La commande HELO déclare comme client le nom de l'hôte local, et non l'utilisateur réel qui a envoyé le message. Assez souvent, ces concepts sont confus, ce qui complique la résolution des problèmes qui se posent dans les systèmes de messagerie.

Commande AUTH

L'extension de la conversation SMTP avec la commande AUTH est décrite dans la RFC 4954.

PLAIN (utilise l'encodage Base64.)

CONNEXION (utilise l'encodage Base64.)

GSSAPI (interface de programme d'application de services de sécurité générique)

DIGEST-MD5 (Authentification d'accès Digest)

La seule différence entre PLAIN et LOGIN est que dans la première variante, le login + mot de passe est transmis sur une ligne, et dans la deuxième variante - d'abord le login, puis le mot de passe. Mais tous doivent être encodés en Base64 .

Commande COURRIER

La commande MAIL est utilisée pour établir une session de messagerie avec le serveur après l'envoi de la commande HELO. Il indique de qui provient le message. Le format de la commande MAIL est le suivant :

MAIL chemin inverse

L'argument reverse-path spécifie non seulement l'expéditeur du message, mais également la route par laquelle le message peut être renvoyé s'il ne peut pas être livré. Si l'expéditeur est l'utilisateur de l'ordinateur client qui a lancé la session SMTP, le format de la commande est :

COURRIER DE: [courriel protégé]

Notez que le champ FROM contient l'adresse e-mail de l'expéditeur du message, y compris le nom complet de l'ordinateur hôte client. Cette information doit être présente dans le champ FROM du message électronique (mais nous en reparlerons plus tard). Si le message électronique est passé par plusieurs nœuds sur le chemin de l'expéditeur au destinataire, chacun d'eux ajoutera des informations sur lui-même au champ . De cette façon, le chemin du message transitant par les serveurs de messagerie est documenté. Très souvent, les e-mails provenant de clients de réseaux privés doivent passer par plusieurs serveurs de messagerie avant d'atteindre Internet. Les informations contenues dans le champ de chemin inverse sont souvent utiles lors du dépannage des systèmes de messagerie ou de la détection des serveurs de messagerie qui tentent de dissimuler leur identité en envoyant des messages via des serveurs SMTP inconnus.

L'équipe RCPT

La commande RCPT spécifie les destinataires du message. Plusieurs utilisateurs peuvent recevoir le même message. En règle générale, chaque destinataire est spécifié sur une ligne distincte avec la commande RCPT. Le format de la commande RCPT est le suivant :

Chemin avant RCPT

L'argument forward-path spécifie où le courrier électronique est dirigé. En règle générale, il s'agit de l'adresse e-mail complète, mais il peut également s'agir du nom d'utilisateur du serveur SMTP local. Considérez la commande suivante comme exemple :

RCPT À : haley

Cette commande spécifie que le message doit être dirigé vers l'utilisateur haley sur le serveur SMTP qui traite les messages. De la même manière, vous pouvez envoyer des messages aux utilisateurs d'autres ordinateurs qui ne sont pas des utilisateurs du serveur SMTP auquel le message est envoyé. Considérez, par exemple, la commande suivante :

RCPT À : [courriel protégé]

Une commande envoyée à un serveur SMTP nommé shardrach.smallorg.org force la décision de remettre le message à ce serveur. Étant donné que l'utilisateur n'est pas connecté au serveur shardrach local, le serveur devra déterminer quoi faire avec le message ensuite. Dans ce cas, il existe trois options pour l'hôte shardrach. Regardons-les de plus près.

L'hôte shardrach PEUT transmettre le message au destinataire et renvoyer une réponse affirmative (OK) à l'expéditeur. Dans ce cas, il ajoute son nom dans le champ MAIL pour l'inclure dans le chemin du message si nécessaire pour notifier l'expéditeur.

L'hôte shardrach est incapable de transférer le message et notifie l'expéditeur, tout en confirmant en même temps que l'adresse de l'hôte meshach.smallorg.org est correcte. Ainsi, l'expéditeur peut tenter de resoumettre le message directement à meshach.smallorg.org.

L'hôte shardrach ne peut pas transférer le message et envoie une notification indiquant que cette opération ne peut pas être effectuée avec ce serveur. Ensuite, les raisons de ce qui s'est passé doivent être analysées par l'administrateur système.

Au début d'Internet, la pratique consistait à envoyer des messages électroniques à l'aveugle entre des ordinateurs du monde entier en utilisant l'algorithme de diffusion d'origine.

Commande DATA

Cette commande est la principale du protocole SMTP. Après traitement des commandes MAIL et RCPT, la commande DATA est utilisée pour envoyer la partie information du message. Le format de la commande DATA est le suivant :

Tout ce qui suit cette commande est interprété comme un message à envoyer. Le serveur SMTP remplit généralement l'en-tête du message avec un horodatage et des informations sur le chemin de retour. Le programme client marque la fin du message en transmettant une chaîne avec un seul point. Le format de cette chaîne est :

.

A réception de cette séquence, le serveur SMTP "sait" que la transmission du message est terminée et doit renvoyer un code de réponse qui notifie au client que son message a été reçu.

Commande ENVOYER

La commande SEND est utilisée pour envoyer des messages électroniques directement au terminal d'un utilisateur système enregistré. Cette commande n'est exécutée que lorsque l'utilisateur est connecté et est généralement un message contextuel similaire à la commande d'écriture UNIX. Cette commande présente un sérieux inconvénient : elle peut être utilisée par un utilisateur externe pour déterminer facilement qui est actuellement connecté au système. Cette "opportunité" a longtemps été activement exploitée par les pirates pour obtenir des identifiants d'utilisateurs sur Internet auprès de victimes sans méfiance qui se trouvent dans le système. Pour des raisons de sécurité, la plupart des progiciels SMTP n'incluent plus cette commande.

Commande RSET

La commande RSET est l'abréviation de reset. Si le client est confus au sujet des réponses qu'il reçoit du serveur, ou décide que la connexion a été perdue, il peut envoyer une commande RSET et ramener la session à son point de départ, en émettant la commande HELO. Dans ce cas, toutes les commandes envoyées précédemment - MAIL, RCPT et DATA seront annulées. Très souvent, cette commande est utilisée en "dernier recours" lorsque le client a soit perdu la séquence de commandes, soit reçu une réponse inattendue du serveur.

VRFY

La commande VRFY est l'abréviation de vérifier. Il peut être utilisé pour déterminer si le serveur de messagerie peut livrer le courrier à un destinataire spécifique avant d'émettre la commande RCPT. Le format de cette commande est :

nom d'utilisateur VRFY

Lors de la réception de cette commande, le serveur SMTP détermine s'il a un utilisateur avec le nom donné sur le serveur local. Si un tel utilisateur est trouvé, le serveur renverra une réponse avec l'adresse e-mail complète de l'utilisateur. S'il n'y a pas d'utilisateur de ce type sur le serveur local, le serveur SMTP peut soit renvoyer une réponse négative au client, soit indiquer qu'il transmettra tous les messages à l'utilisateur distant. Cela dépend si le serveur SMTP transmet les messages au client distant.

La commande VRFY peut être un outil efficace lors du dépannage des e-mails. Très souvent, lors de l'envoi de messages électroniques, les utilisateurs orthographient mal l'adresse ou le nom d'hôte et se demandent ensuite pourquoi leurs messages n'ont pas été reçus. Bien sûr, la première chose qu'ils feront est de se plaindre auprès de l'administrateur du système de messagerie du travail dégoûtant du système de messagerie. En tant qu'administrateur du système de messagerie, vous pouvez vérifier la santé des adresses e-mail de deux manières. Tout d'abord, utilisez la commande DNS host, qui vous permet de déterminer l'exactitude du nom de domaine et la présence d'un serveur de messagerie desservant le domaine. Et deuxièmement, vous pouvez telnet au port 25 du serveur de messagerie, puis émettre la commande VRFY, qui déterminera le nom d'utilisateur correct. Le Listing 5.3 montre un exemple d'utilisation de la commande VRFY pour valider les noms d'utilisateur.

Les lignes 8 à 13 affichent la sortie de la commande VRFY. La ligne 8 tente de VRFY l'utilisateur local riche. La réponse du serveur SMTP à la ligne 9 confirme qu'un utilisateur portant ce nom existe dans le système et l'adresse e-mail complète est renvoyée au client. La ligne 10 montre une autre version de la commande VRFY. Ici, le client essaie d'exécuter une commande VRFY pour un utilisateur sur un ordinateur distant. La réponse reçue sur la ligne 11 du système shadrach est différente de la réponse reçue sur la ligne 9. Dans la section "Réponses du serveur", les significations des codes renvoyés par le serveur sont discutées plus en détail. Dans notre cas, notez que le système shadrach notifie au client que le courrier sera transmis à l'utilisateur prez sur le serveur distant meshach.smallorg.org. La ligne 12 montre une tentative de recherche d'un nom inexistant dans le système meshach. La réponse du serveur SMTP à la ligne 13 est explicite.

Vérifiez l'existence de l'utilisateur à l'aide de bash et curl. $ écho -e "VRFY [courriel protégé]\nQUITTER"| curl telnet:// mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 [courriel protégé] example.com 221 2.0.0 Au revoir

L'équipe NOOP

La commande NOOP est l'abréviation de aucune opération. Cette commande n'a aucun effet sur le serveur SMTP, sauf que le serveur lui renvoie un code de réponse positif. Il est utilisé lors du test d'une connexion sans transmettre de message.

Équipe QUITTER

La commande QUIT fait exactement ce qu'elle signifie. indique au serveur SMTP que l'ordinateur client a terminé sa session en cours et souhaite fermer la connexion. Le serveur SMTP doit répondre à cette commande, puis initier et fermer la connexion TCP. Si le serveur reçoit une commande QUIT pendant un transfert de courrier, toutes les données transmises pendant la session doivent être détruites et n'atteindront pas le destinataire.

Format de message (courriel)

Champs d'en-tête standard, conformément à la RFC 822

La RFC 822 permet de diviser le message en deux parties. La première partie s'appelle l'en-tête. Il contient toutes les données qui identifient le message. La deuxième partie est appelée le corps du message. L'en-tête se compose de champs de données qui sont utilisés selon les besoins pour ajouter des informations supplémentaires au message. Les champs d'en-tête et le corps du message doivent être séparés par une ligne vide. Il n'y a pas d'ordre spécifique pour les champs d'en-tête, c'est-à-dire les champs d'en-tête peuvent être placés dans n'importe quel ordre. De plus, les champs d'en-tête peuvent être répétés dans le même message. La figure montre une vue générale d'un message électronique conforme aux exigences de RFC 822.

Format de message, selon RFC 822

Champ d'en-tête reçu

Le format du champ d'en-tête Received : est le suivant :

Reçu : du nom d'hôte par nom d'hôte via un chemin physique avec l'ID de protocole ID de message pour la destination finale de l'e-mail

Le champ d'en-tête Received est utilisé pour identifier les serveurs SMTP qui ont participé à la livraison du message de l'expéditeur au destinataire. Chaque serveur ajoute son propre champ Reçu au message électronique, indiquant des informations spécifiques sur lui-même. Les sous-champs du champ Reçu indiquent le chemin, le protocole et les ordinateurs impliqués dans la transmission du message.

Champ d'en-tête Return-Path

Le format de ce champ d'en-tête est le suivant :

Chemin de retour : route

Le dernier serveur SMTP de la chaîne de transfert ajoute un champ Return-Path au message. Son but est de déterminer la route par laquelle le message est parvenu au destinataire. Si le message a été envoyé directement au serveur du destinataire, une seule adresse sera affichée dans ce champ. Sinon, la liste complète des serveurs par lesquels le message est passé pour atteindre la destination sera affichée ici. Peut être différent de MAIL FROM (c'est-à-dire que l'adresse de retour peut être spécifiée différemment de l'adresse de l'expéditeur).

Champ d'en-tête de l'expéditeur

Le champ Expéditeur spécifie l'adresse de l'expéditeur du message. Ces informations sont très utiles dans les situations où les messages ont été rejetés plusieurs fois par des réseaux privés avant d'atteindre Internet. Le format de ce champ est le suivant :

Répondre à l'adresse

Le champ Originator n'est qu'un petit champ d'assistance dans les champs d'en-tête multicolores. Il peut être utilisé comme chemin plus simple pour les petits paquets SMTP. Cela élimine le besoin de champs d'en-tête plus complexes qui identifient l'expéditeur.

Renvoyer le champ d'en-tête

Le champ d'en-tête Resent identifie un message électronique qui, pour une raison quelconque, aurait dû être renvoyé par le client. Le format de ce champ est le suivant :

Renvoyer-Répondre-À : adresse

Champs d'en-tête authentiques

Ces champs d'en-tête identifient l'expéditeur du message électronique. Format des champs authentiques :

De : nom d'utilisateur Expéditeur : nom d'utilisateur

Le champ De : identifie l'auteur du message. En règle générale, les champs De : et Expéditeur : correspondent au même utilisateur. Par conséquent, un seul de ces champs est réellement requis. Dans le cas où l'expéditeur du mail n'est pas l'auteur du message, mais qu'il n'est envoyé qu'à partir de son adresse, les deux champs doivent tout de même être renseignés - cela garantit que le message est renvoyé à l'expéditeur si la remise au destinataire était impossible . Champs d'en-tête renvoyés authentiques

Les champs Resent-authentic identifient l'expéditeur d'un message qui a été retransmis par le client pour une raison quelconque. Le format de ces champs est le suivant :

Resent-From: date-time Resent-Sender: date-time Les champs Resent-From: et Resent-Sender: fonctionnent comme les champs From: et Sender:. Ils reflètent seulement que le message a été retransmis par le client pour une raison inconnue.

Champs d'en-tête de dates

Les champs de l'en-tête Dates sont utilisés pour placer un horodatage sur le message lors de sa transmission du client au serveur. Le format des champs Dates est le suivant :

Date : date-heure Resent-Date : date-heure Le champ Date : (Date) transmettra les informations d'en-tête du message exactement comme le message d'origine. Ce paramètre peut être utile lors du suivi des temps de réponse, en particulier des réponses multiples.

Champs d'en-tête de destination

Les champs de l'en-tête Destination contiennent les adresses e-mail des destinataires du message. Ces champs sont purement informatifs. Dans tous les cas, le serveur SMTP n'enverra pas de message à la boîte aux lettres de l'utilisateur tant qu'il n'aura pas reçu une commande RCPT émise pour cet utilisateur (voir la section "Commandes de base du client SMTP"). Le format de ces champs est le suivant :

To : adresse Resent-To : adresse CC : adresse Resent-CC : adresse BCC : adresse Resent-BCC : adresse

Les champs À :, CC : et CCI : définissent l'algorithme standard de traitement des e-mails. La plupart des packages de messagerie utilisent cette terminologie pour classer les destinataires d'un message. Le champ CC : est similaire à un mémo, et les destinataires prévus doivent recevoir une « copie » du message. Un autre nouveau concept introduit par les systèmes de messagerie est BCC : ou copie carbone invisible. Le champ "copie invisible" indique également le destinataire d'une copie du message, mais son adresse n'est pas visible pour les personnes extérieures (ce n'est pas tout à fait éthique). Il y a eu des discussions sur l'éthique informatique en relation avec cette option, mais aujourd'hui, presque tous les programmes de messagerie électronique prennent en charge cette fonctionnalité.

Champs d'en-tête facultatifs

Facultatifs sont les champs qui identifient plus spécifiquement le message au serveur SMTP, mais selon RFC 822 peuvent ne pas être présents dans le message. Cependant, ces domaines sont désormais très répandus et vous serez nombreux à devoir y faire face. Certains d'entre eux ont le format suivant :

Message-ID : message-id Resent-Message-ID : message-id In-Reply-To : message-id Références : message-id Mots clés : texte - liste Objet : texte Commentaires : texte Chiffré : mot

Le plus utile et le plus couramment utilisé de cet ensemble est le champ Objet :. La plupart des programmes de messagerie permettent à l'expéditeur de saisir un objet de message sur une seule ligne qui décrit le contenu du message au destinataire. Cette ligne de texte est souvent utilisée par le client de messagerie lors de la génération de listes de messages reçus. Un autre champ facultatif permet également d'identifier le message électronique. Ce champ est Message-ID : (ID de message). Ce champ attribue un numéro d'identification unique au message, qui peut ensuite être affiché dans le message renvoyé. Le champ Crypté : cryptage spécial indique si le message a été crypté pour des raisons de sécurité, et dans Mots-clés : vous pouvez définir des mots-clés qui peuvent être utilisés lors de la recherche de texte spécifique trouvé dans le message (messages).

Données binaires et MIME

L'algorithme de codage MIME prend en compte le type de binaire en cours de conversion et transmet également des informations supplémentaires sur le fichier au décodeur. L'algorithme MIME permet de placer des données binaires directement dans un message électronique standard, conformément à la RFC 822. Cinq nouveaux champs d'en-tête ont été créés pour décrire les données binaires intégrées dans un message au format RFC 822. Les programmes de messagerie prenant en charge le standard MIME doivent gérer correctement tous ces nouveaux types d'en-têtes.

Champ d'en-tête MIME-Version

Le premier des champs d'en-tête facultatifs contient la version MIME utilisée par l'expéditeur lors de l'encodage du message. Actuellement, ce champ est toujours 1.0.

Champ Contenu-Transfert-Encodage

Le champ d'en-tête Content-Transfer-Encoding spécifie comment les données binaires doivent être placées dans un message au format texte ASCII. Il existe actuellement sept façons différentes d'encoder des données binaires, mais l'encodage base64 est le plus courant. Avec cette méthode de codage, des blocs de 6 bits de données binaires sont convertis en blocs de 8 bits qui sont perçus comme du texte ASCII.

Champ Content-ID

Ce champ d'en-tête est utilisé pour identifier les sessions MIME avec un ID spécifique lorsque le contenu est complexe.

Champ Contenu-Description

Le champ d'en-tête Content-Description est utilisé pour fournir une description textuelle ASCII des données placées dans le message électronique. Ceci est utile lors de l'envoi de documents créés avec un traitement de texte ou de graphiques qui ne sont pas différents lorsqu'ils sont encodés en base64.

Champ d'en-tête Content-Type

Champ d'en-tête Content-Type

C'est dans ce champ de la rubrique que se déroule l'action principale de notre pièce. Ce champ identifie les données contenues dans le message MIME. Il existe actuellement sept classes de données principales identifiées dans MIME. Chaque classe a ses propres sous-classes qui caractérisent plus en détail le type de données contenues dans le message.

Le type de données texte identifie les données ASCII à lire telles quelles. Il existe également deux sous-classes ici - texte brut, c'est-à-dire texte ASCII non formaté et texte enrichi, qui comprend des éléments de formatage similaires au format de texte enrichi. Les derniers programmes de messagerie peuvent même fonctionner avec le format RTF (Rich Text Format).

Le type de données message permet à un expéditeur d'envoyer des messages simples au format RFC 822. Les sous-classes de ce type sont : rfc822, qui indique que la pièce jointe est un message RFC 822 normal ; partial, qui vous permet de diviser de longs messages en plusieurs parties, et external-body, qui vous permet de mettre un pointeur sur un objet qui ne fait pas partie du message.

Le type de données image définit une pièce jointe au message de données binaires qui représente une image graphique. Il existe actuellement deux sous-classes définies pour ce type, jpeg et gif.

Le type de données vidéo spécifie en conséquence que les données intégrées dans le message sont des données vidéo. Actuellement, une seule sous-classe est définie pour ce type, le format mpeg.

Le type de données audio désigne le contenu du message en tant que données audio (fichiers audio). Ici aussi, une seule sous-classe, de base, est définie jusqu'à présent, qui correspond à un canal RNIS avec une fréquence d'échantillonnage de 8 kHz.

Le type de données de l'application correspond aux données binaires attachées au message qui est l'application (par exemple, des feuilles de calcul Microsoft Excel ou des documents créés avec le traitement de texte Microsoft Word). À ce jour, deux sous-classes de ce type de données ont été définies - postscript et octet-stream. Assez souvent, la sous-classe de flux d'octets est utilisée pour joindre des données d'application, telles que des documents Microsoft Word ou des feuilles de calcul Microsoft Excel, à un message.

Le type de données en plusieurs parties identifie les messages contenant plusieurs types de données différents. Ce format est assez courant dans les programmes de messagerie qui prennent en charge la sortie d'un message de plusieurs manières, telles que le texte ASCII, le texte HTML ou un fichier audio. L'identificateur de frontière sépare différents types de données. Dans le même temps, chaque type de données est identifié par un champ d'en-tête de type de données spécifique. Le type de données multipart a quatre sous-classes.

La sous-classe mixte indique que chacune des parties du message est indépendante et doit être présentée au destinataire dans l'ordre dans lequel elles ont été insérées par l'expéditeur. La sous-classe parallèle spécifie que chacune des parties du message est indépendante et que toutes peuvent être présentées au destinataire dans n'importe quel ordre. La sous-classe alternative suivante spécifie que toutes les parties du message sont les mêmes données, mais présentées sous une forme différente. Dans ce cas, le destinataire peut choisir le meilleur moyen de visualiser les données reçues. La sous-classe digest est similaire à bien des égards à la sous-classe mixte, mais spécifie que le corps du message est toujours représenté au format RFC822.

1 $ telnet localhost 25 2 Essayer 127.0.0.1... 3 Connecté à localhost. 4 Le caractère d'échappement est "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3 ; Mon, 30 Aug 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Bonjour localhost, ravi de vous rencontrer 8 MAIL DE : [courriel protégé] 9 250 [courriel protégé] Expéditeur ok 10 RCPT TO:rich 11 250 rich... Destinataire ok 12 DATA 13 354 Entrez mail, terminez par "." sur une ligne à part 14 From:"Rich Blum" 15 À : "riche" 16 Objet : Test de message texte formaté 17 Version MIME : 1.0 18 Type de contenu : multipart/alternative ; border=bounds1 19 20 --bounds1 21 Content-Type: text/plain; charset=us-ascii 22 23 Il s'agit de la partie en clair du message qui peut être lue par de simples lecteurs de courrier électronique. 25 26 --bounds1 27 Type de contexte : texte/enrichi 28 29 C'est le texte riche version de la MÊME message. 30 31 --limites1-- 32 . 33 250 MAA04305 Message accepté pour livraison 34 QUIT 35 221 shadrach.smallorg.org fermeture de la connexion 36 Connexion fermée par un hôte étranger. 37 Vous avez un nouveau courrier dans /var/spool/mail/rich $38

Liste 5.6. Exemple de session SMTP avec plusieurs pièces jointes MIME (html, txt) L'exemple de message présenté dans le Listing 5.6 est un message MIME composé de deux parties. La ligne 18 indique le type de données du message. Le type multipart/alternative indique qu'il existe différents types de données dans le message, qui sont séparés par le délimiteur de limite bounds1. Le premier type de données commence à la ligne 21 et est un texte ASCII brut qui peut être lu par presque n'importe quel programme de messagerie.

Le deuxième type de données commence à la ligne 27 et est un texte formaté à l'aide d'un format de texte enrichi.

Étant donné que le type MIME spécifié pour le message est multipart/alternative, il appartient entièrement à l'expéditeur de décider quelle version de la pièce jointe afficher.

Protocole SMTP avancé

Depuis sa création en 1982, le protocole SMTP a fait un excellent travail d'envoi de messages entre ordinateurs sur Internet. Cependant, au fil du temps, les limitations prévues dans le protocole sont devenues perceptibles. Puis, au lieu de remplacer le protocole standard, largement utilisé à cette époque, il a été décidé d'améliorer certaines fonctions du protocole SMTP. Dans le même temps, une décision a été prise, laissant toutes les spécifications SMTP dans leur forme d'origine, en leur ajoutant uniquement de nouvelles fonctionnalités.

En 1995, la RFC 1869 voit le jour, qui définit une méthode d'extension des capacités du protocole SMTP appelée "Extended SMTP Services".

Le SMTP étendu (SMTP étendu) est implémenté comme suit. Au démarrage d'une session SMTP, la commande HELO est remplacée par la commande d'invitation - EHLO. La réception par le serveur SMTP d'une telle commande signifie que le client peut lui envoyer des commandes SMTP étendues. Le Listing 5.7 montre un exemple de session utilisant EHLO , ainsi que des commandes supplémentaires.

1 $ telnet localhost 25 2 Essayer 127.0.0.1... 3 Connecté à localhost. 4 Le caractère d'échappement est "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3 ; Lundi 30 août 1999 16:36:48 -050 6 EHLO localhost 7 250-shadrach.smallorg.org Bonjour localhost, ravi de vous rencontrer 8 250-EXPN 9 250-VERB 10 250-8BITMIME 11 250-SIZE 12 250-DSN 13 250-ONEX 14 250-ETRN 15 250-XUSR 16 250 AIDE 17 AIDE DSN 18 214-MAIL DE : [ RET=( COMPLET || HDRS) ] [ ENVID= ] 19 214-RCPT À : [ NOTIFY=(JAMAIS,SUCCÈS,ÉCHEC,DÉLAI) ] 20 214- [ ORCPT= ] 21 214- Notifications d'état de livraison SMTP. 22 214-Descriptions : 23 214- RET Renvoie soit le message complet, soit uniquement les en-têtes. 24 214- ENVID "Identifiant de l'enveloppe" de l'expéditeur pour le suivi. 25 214- NOTIFY Quand envoyer un DSN. Plusieurs options sont OK, 26 214- délimitées par des virgules. JAMAIS doit apparaître seul. 27 214- ORCPT Destinataire d'origine. 28 214 Fin de l'info HELP 29 HELP ETRN 30 214-ETRN [ | @ | #] 31 214 - Exécute la file d'attente pour le , ou 32 214- tous les hôtes au sein d'un , ou un 33 214- spécialement nommé (spécifique à la mise en œuvre). 34 214 Fin des informations d'AIDE 35 QUIT 36 221 shadrach.smallorg.org fermeture de la connexion 37 Connexion fermée par un hôte étranger. 38 $

La ligne 6 spécifie la commande EHLO SMTP pour se connecter au serveur SMTP. Les lignes 7 à 16 affichent la réponse du serveur. Notez que le serveur signale que d'autres commandes sont disponibles, c'est-à-dire la session est en mode "amélioré". L'un des nouveaux groupes de commandes s'appelle Options de notification d'état de livraison. Ces options peuvent être utilisées avec les commandes MAIL et RCPT pour afficher l'état de livraison d'un message électronique particulier. Cependant, pour nous, en tant qu'administrateurs du système de messagerie, l'équipe ETRN est du plus grand intérêt.

La commande TURN a déjà été mentionnée auparavant. Cette commande est assez efficace, mais malheureusement pas sûre. Pour compenser cette lacune, la RFC 1985 définit une nouvelle implémentation de la commande TURN qui offre une plus grande sécurité. La commande ETRN permet à un client SMTP d'émettre une requête vers un serveur SMTP afin d'initier une autre connexion SMTP avec le client afin de lui envoyer des messages. La seule différence entre ETRN et TURN est que la demande n'est pas d'utiliser une connexion existante, mais d'ouvrir une nouvelle session SMTP. Ainsi, un serveur SMTP peut se connecter à un ordinateur client en utilisant les algorithmes de résolution de noms DNS normaux. Dans ce cas, l'ouverture d'une nouvelle connexion n'est pas basée sur le nom sous lequel le poste client est enregistré sur le serveur, mais sur le nom d'hôte réel du client. Dans ce cas, si un pirate établit une connexion SMTP non autorisée et utilise la commande ETRN, le serveur SMTP établira simplement une nouvelle connexion avec le vrai client et lui transmettra l'e-mail. En conséquence, il n'y a pas eu de victimes. Le format de la commande ETRN est le suivant :

Ici, le rôle de name peut être soit un nom d'hôte, soit un nom de domaine (si une demande est reçue pour recevoir du courrier pour l'ensemble du domaine). L'équipe ETRN est une très bonne aide pour l'administrateur de messagerie. Si le courrier de votre serveur de messagerie est stocké par le fournisseur d'accès Internet, cette commande vous permet de l'informer qu'il est prêt à recevoir le courrier collecté pour vous. Il existe plusieurs manières d'implémenter un tel algorithme. La première consiste à utiliser le programme Perl spécial fourni avec le programme sendmail. Ce qu'il fait, c'est qu'après avoir établi une connexion avec un FAI, il émet une commande ETRN avec votre nom de domaine comme argument. Dès réception de cette commande, le serveur SMTP du FAI initie une autre connexion SMTP à votre serveur SMTP local (sur la même connexion PPP) et distribue tout le courrier destiné à votre domaine qu'il a dans sa file d'attente d'envoi.

Les commandes sont des lignes de texte terminées par une séquence. La commande, en tant que telle, est une chaîne de lettres (généralement 4 lettres) terminée par un espace (si des options sont données) ou. Il est conseillé aux destinataires SMTP de tolérer les espaces avant la séquence de fin.

Liste des commandes du protocole SMTP :

Les commandes sont explicitement indiquées dans la RFC 5321 :

• EHLO (ou standard - HELO) Ouvre une invitation d'un client. Ces commandes sont utilisées pour présenter un client SMTP à un serveur SMTP. Le champ argument contient le FQDN du client SMTP, si un tel nom est disponible. Dans les cas où le client SMTP n'a pas de nom de domaine significatif (par exemple, lorsque l'allocation d'adresse est dynamique et qu'aucune recherche inversée n'est disponible), les clients DEVRAIENT envoyer l'adresse complète. Bien que les serveurs doivent répondre à ces deux commandes, il est préférable d'utiliser la commande EHLO, car les serveurs qui ne prennent pas en charge les services SMTP étendus renvoient toujours un message d'erreur en réponse à EHLO.

Exemple:
HELO orsi1.rsmc.ru

• MAIL - Identifie l'expéditeur du message. Le champ arguments contient le chemin de retour et peut inclure des options supplémentaires. En fait, cette commande définit l'expéditeur de la lettre (MAIL FROM)

Exemple:
COURRIER DE:

• RCPT - Spécifie les destinataires du message. Plusieurs utilisateurs peuvent recevoir le même message. En règle générale, chaque destinataire est spécifié sur une ligne distincte avec la commande RCPT.

Exemple:
RCPT À : [courriel protégé] site

• DATA - Spécifie le début du message. Ne prend pas en charge les paramètres. Après traitement des commandes MAIL et RCPT, la commande DATA est utilisée pour envoyer la partie information du message. Tout ce qui suit cette commande est interprété comme un message à envoyer. La voici, notre lettre ! 

Exemple:
LES DONNÉES

• RSET - Réinitialiser la connexion SMTP pa. Ne prend pas en charge les paramètres. Rétablit la session au moment où la commande HELO (EHLO) a été émise, avec toutes les commandes MAIL, RCPT et DATA précédemment envoyées considérées comme annulées.
• VRFY - Vérifie le nom d'utilisateur du système. Si le serveur de messagerie a un utilisateur local avec le nom donné, le serveur renverra son adresse de messagerie complète. S'il n'y a pas d'utilisateur local de ce type, un message d'erreur sera renvoyé ou un message indiquant que le serveur transmettra les lettres plus loin. Dans le cas du nom spécifié dans l'exemple, nous recevrons très probablement un message d'erreur.

Exemple:
VRFY kyrytch

• EXPN - Demande une liste de diffusion et des alias de messagerie.

Exemple:
Liste de diffusion EXPN

• AIDE - Demande une liste des commandes prises en charge par le serveur. Si vous spécifiez un nom de commande en paramètre, le serveur renvoie une aide sur la syntaxe de cette commande.

Exemple:
AIDE VRFY

• NOOP - Aucune opération - Ne rien faire.

Exemple:
NOOP

• QUITTER - Termine la session SMTP. Ne prend pas en charge les paramètres.

Exemple:
QUITTER

Autres commandes :

• ENVOYER - Envoie un message au terminal de l'utilisateur enregistré. Cette commande n'est exécutée que si l'utilisateur est connecté et ressemble généralement à un message contextuel. Pas l'équipe la plus populaire.
• SOML - Si les destinataires du message sont connectés au système, alors SOML fonctionne comme une commande SEND. S'il n'est pas connecté, alors en tant que commande MAIL. En raison de l'insécurité de cette commande, elle est rarement implémentée sur le serveur.
• SAML - envoie un message au terminal de l'utilisateur s'il est connecté et place simultanément ce message dans sa boîte aux lettres.
• TURN - Rôles inversés dans SMTP (le client devient le serveur). En règle générale, SMTP est conçu pour envoyer des messages dans une seule direction sur une seule connexion TCP. Le but de la commande TURN est d'organiser un échange bidirectionnel de messages électroniques entre deux ordinateurs via une connexion TCP existante. En raison de la popularité de cette commande parmi les attaquants, son implémentation n'est pas souvent vue sur le serveur.
• AUTH - Affiche le mécanisme d'authentification au serveur. RFC 4954 (remplacé RFC 2554).

• Effronté

Ajouter un commentaire

Alors que d'autres agents de transfert de messages utilisent SMTP pour envoyer et recevoir des messages électroniques, les applications clientes de messagerie au niveau de l'utilisateur n'utilisent généralement SMTP que pour envoyer des messages au serveur de messagerie pour le relais. Pour recevoir des messages, les applications clientes utilisent généralement POP (eng. Protocole postal- protocole postal), ou IMAP (eng. Protocole d'accès aux messages Internet ), ou des systèmes propriétaires (tels que Microsoft Exchange et Lotus Notes/Domino) pour accéder à votre compte de boîte aux lettres sur le serveur.

Récit

Dans les années 1960, diverses formes de communication électronique ont été utilisées. Les gens communiquaient entre eux à l'aide de systèmes conçus pour des mainframes spécifiques. Au fur et à mesure que de plus en plus d'ordinateurs se connectaient, en particulier sur le réseau du gouvernement américain, ARPANET, des normes ont été développées afin que les utilisateurs de différents systèmes puissent s'écrire des messages électroniques. Ces normes, développées dans les années 1970, sont devenues la base de SMTP.

Les racines de SMTP remontent à deux implémentations décrites en 1971, le protocole de boîte aux lettres et SNDMSG, qui a été "inventé" par Ray Tomlinson de BBN Technologies pour les ordinateurs TOPS-20/TENEX qui envoyaient des messages via l'ARPANET (à l'époque moins de 50 hôtes).

D'autres implémentations incluent FTP Mail et Mail Protocol développés en 1973. Le développement s'est poursuivi tout au long des années 1970 jusqu'à ce qu'ARPANET évolue vers l'Internet moderne vers 1980. La même année, Jon Postel a proposé le protocole de transport de courrier, grâce auquel FTP a cessé d'être la base. pour le transfert de courrier. SMTP publié dans la RFC 821 (également écrite par Postel) en août 1982.

La norme SMTP a été développée à peu près au même moment que Usenet, un réseau de données présentant certaines similitudes avec SMTP. SMTP est devenu largement utilisé au début des années 1980. À l'époque, il s'agissait d'un module complémentaire du programme de messagerie Unix Copy Program (UUCP) basé sur Unix, qui était plus adapté à la gestion de la transmission de messages électroniques entre des appareils connectés périodiquement. D'autre part, SMTP fonctionne très bien lorsque les appareils d'envoi et de réception sont connectés au réseau à tout moment. Les deux appareils utilisent un mécanisme de stockage et de retransmission et sont des exemples de technologie push. Bien que les groupes de discussion Usenet se propagent toujours entre les serveurs utilisant UUCP, le courrier UUCP a effectivement disparu avec la route "bang path" (la séquence de machines hôtes sur le réseau par laquelle un message doit atteindre sa destination) qui étaient utilisées comme en-têtes de routage. L'article Sender Rewrite fournit des informations techniques générales sur l'historique des premiers routages SMTP et source avant la RFC 1123.

Étant donné que ce protocole était à l'origine une interface texte (ASCII), il ne fonctionnait pas bien avec les fichiers binaires et les caractères de nombreuses langues autres que l'anglais. Des normes telles que les extensions de messagerie Internet polyvalentes (MIME) ont été développées pour coder les fichiers binaires à transmettre via SMTP. Les agents de transfert post-Sendmail implémentent généralement également l'option 8 bits pure, de sorte qu'une stratégie alternative "envoyer simplement huit" peut être utilisée pour envoyer des données texte arbitraires (dans n'importe quel codage de caractères de type ASCII à huit bits) via SMTP. Cependant, il y avait toujours un problème de krakozyabr , causé par l'affichage différent des jeux de caractères par les fabricants, bien que les adresses postales elles-mêmes permettaient toujours l'utilisation exclusivement de l'ASCII. Aujourd'hui, les agents de transfert 8 bits purs prennent généralement en charge l'extension 8BITMIME, ce qui rend le transfert de fichiers binaires presque aussi simple que le texte brut. L'extension SMTPUTF8 a été récemment créée pour prendre en charge le texte encodé en UTF-8, ce qui permet d'inclure du contenu international et des adresses à l'aide de scripts tels que le cyrillique ou le chinois.

De nombreuses personnalités ont contribué à la spécification SMTP de base, notamment Jon Postel, Eric Allman, Dave Crocker, Ned Fried, Randall Jellens, John Klensin et Keith Moore.

Modèle de traitement du courrier

Le courrier électronique est présenté par un client de messagerie (MUA, agent d'utilisateur de messagerie) à un serveur de messagerie (MSA, agent de soumission de courrier) en utilisant SMTP sur le port TCP 587. De là, le MSA livre le courrier à ses MTA, agent de transfert de courrier). Souvent, ces deux agents ne sont que des instances différentes du même logiciel exécuté avec des paramètres différents sur le même appareil. Le traitement local peut être effectué à la fois sur une machine séparée et réparti entre différents appareils; dans le premier cas, les processus impliqués partagent des fichiers, dans le second cas, SMTP est utilisé pour transférer le message en interne, chaque hôte étant configuré pour utiliser le périphérique suivant comme hôte intermédiaire. Chaque processus est un MTA en soi, c'est-à-dire un serveur SMTP.

Le MTA périphérique doit trouver l'hôte cible. Il utilise le système de noms de domaine (DNS) pour rechercher les enregistrements de l'échangeur de messagerie (MX) pour le domaine du destinataire (la partie de l'adresse à droite du symbole @). L'enregistrement MX de courrier renvoyé contient le nom de l'hôte cible. Le MTA se connecte ensuite au serveur Exchange en tant que client SMTP.

Une fois que la cible MX reçoit un message entrant, elle le transmet à un agent de distribution de courrier (MDA) pour livrer le message localement. MDA offre la possibilité d'enregistrer des messages dans le format de boîte aux lettres approprié. La réception du courrier, encore une fois, peut être effectuée par plusieurs ou par un seul ordinateur - l'image montre les deux boîtes aux lettres les plus proches pour chaque cas. MDA peut livrer des messages directement au stockage ou les transférer sur le réseau en utilisant SMTP ou tout autre moyen, y compris le protocole de transfert de courrier local (LMTP), un dérivé de SMTP conçu à cet effet.

Après livraison au serveur de messagerie local, le message est stocké pour une recherche par lots par des clients de messagerie authentifiés (MUA). Le message est récupéré par les applications de l'utilisateur final (clients de messagerie) à l'aide du protocole Internet Message Access Protocol (IMAP, qui facilite l'accès aux messages et gère le courrier stocké), ou à l'aide du protocole Post Office (POP), qui utilise généralement le fichier mbox traditionnel. ou des systèmes propriétaires tels que Microsoft Exchange/Outlook ou Lotus Notes/Domino. Les clients de messagerie réseau peuvent utiliser l'une ou l'autre méthode, mais le protocole de recherche n'est souvent pas conforme aux normes officielles.

SMTP définit la transmission d'un message, pas son contenu. Ainsi, il spécifie l'enveloppe de message et ses paramètres (tels que l'expéditeur de l'enveloppe), mais pas l'en-tête ou le corps du message lui-même. STD 10 et RFC 5321 définissent SMTP (le wrapper), tandis que STD 11 et RFC 5322 définissent le message (en-tête et corps), officiellement appelé format de message Internet.

Présentation du protocole

SMTP est un protocole de texte nécessitant une connexion par lequel l'expéditeur d'un message communique avec le destinataire en émettant des lignes de commande et en recevant les données nécessaires sur un canal fiable, qui est généralement une connexion TCP (Transmission Control Protocol - protocole de contrôle de transmission). Une session SMTP se compose de commandes envoyées par le client SMTP et des réponses correspondantes du serveur SMTP. Lorsqu'une session est ouverte, le serveur et le client échangent ses paramètres. Une session peut inclure zéro ou plusieurs opérations SMTP (transactions).

Une opération SMTP se compose de trois séquences de commande/réponse (voir l'exemple ci-dessous). Description des séquences :

• COURRIER DE- définit l'adresse de retour (c'est-à-dire Return-Path, 53121.From, mfrom). Il s'agit de l'adresse e-mail de retour.

• RCPT À- définit le destinataire de ce message. Cette commande peut être donnée plusieurs fois, une pour chaque destinataire. Ces adresses font également partie du shell.

• LES DONNÉES- pour envoyer le texte du message. C'est le contenu de la lettre elle-même, par opposition à sa coquille. Il se compose d'un en-tête de message et d'un corps de message séparés par une ligne vide. DATA, en fait, est un groupe de commandes, et le serveur répond deux fois : la première fois à la commande DATA elle-même, pour notifier qu'il est prêt à accepter du texte ; et une deuxième fois après la fin de la séquence de données pour accepter ou rejeter l'intégralité du message.

En plus des réponses intermédiaires pour la commande DATA, chaque réponse du serveur peut être positive (code de réponse 2xx) ou négative. Ce dernier, à son tour, peut être permanent (code 5xx) ou temporaire (code 4xx). L'échec du serveur SMTP à envoyer un message est une erreur permanente ; dans ce cas, le client doit envoyer un e-mail rebondi. Après la réinitialisation - une réponse positive, le message sera très probablement rejeté. Le serveur peut également indiquer que des données supplémentaires sont attendues du client (code 3xx).

L'hôte initial (client SMTP) peut être soit un client de messagerie d'utilisateur final (fonctionnellement défini comme un agent de messagerie - MUA) ou un agent de transfert de messages (MTA) sur le serveur, c'est-à-dire le serveur agit en tant que client dans la session correspondante pour relayer le message. Des serveurs entièrement fonctionnels maintiennent des files d'attente de messages pour retransmettre un message en cas d'erreur.

Le MUA connaît le serveur SMTP pour le courrier sortant à partir de ses paramètres. Le serveur SMTP, agissant en tant que client, c'est-à-dire transmettant les messages, détermine à quel serveur se connecter en recherchant la ressource d'enregistrement DNS MX (Mail eXchange) pour le domaine de chaque destinataire. Dans le cas où un enregistrement MX n'est pas trouvé, les MTA compatibles (pas tous) se rabattent sur un simple enregistrement A. Les redirecteurs peuvent également être configurés pour utiliser des hôtes intelligents.

Le serveur SMTP, agissant en tant que client, établit une connexion TCP avec le serveur sur le port 25, conçu pour SMTP. Le MUA doit utiliser le port 587 pour se connecter au Message Delivery Agent (MSA). La principale différence entre MTA et MSA est que l'authentification SMTP n'est requise que pour ce dernier.

SMTP et récupération de messages

SMTP n'est qu'un protocole de livraison. Il ne peut pas récupérer les messages d'un serveur distant à la demande. D'autres protocoles tels que POP et IMAP ont été développés pour la récupération du courrier et la gestion des boîtes aux lettres. Cependant, SMTP offre la possibilité de démarrer le traitement de la file d'attente des messages sur un serveur distant, grâce auquel le système demandeur peut recevoir tous les messages qui lui sont adressés (voir Démarrage de la file d'attente des messages à distance ci-dessous). POP et IMAP sont préférables lorsque l'ordinateur de l'utilisateur n'est pas toujours allumé ou est temporairement connecté à Internet.

Démarrage de la file d'attente des messages à distance

Le démarrage à distance de la file d'attente des messages est une fonctionnalité SMTP qui permet à un hôte distant de commencer à traiter la file d'attente des messages du serveur afin qu'il puisse recevoir les messages qui lui sont destinés à l'aide de la commande TURN. Cependant, cette fonctionnalité était considérée comme non sécurisée et a été étendue dans la RFC 1985 par l'équipe ETRN, qui fonctionne de manière plus sécurisée avec une méthode d'authentification basée sur les informations DNS.

Relais de messagerie à la demande

ODMR (On-Demand Mail Relay - relais de messagerie à la demande) est une extension SMTP normalisée dans la RFC 2645 qui permet de relayer un message à un utilisateur authentifié.

Internationalisation

De nombreux utilisateurs dont le jeu de caractères diffère du latin sont confrontés à l'exigence d'une adresse e-mail en latin. Pour résoudre ce problème, la RFC 6531 a été créée, fournissant des capacités d'internationalisation pour SMTP - une extension de SMTPUTF8. La RFC 6531 prend en charge les caractères multioctets et non ASCII dans une adresse postale, par exemple : δοκιμή@παράδειγμα.δοκιμή ou 测试@测试.测试. La prise en charge actuelle est limitée, mais il existe un vif intérêt pour l'adoption généralisée de la RFC 6531 et des RFC associées dans les pays ayant de grandes bases d'utilisateurs qui n'ont pas le latin comme écriture native.

Serveur SMTP sortant

Le client de messagerie doit connaître l'adresse IP du serveur SMTP, qui est donnée dans le cadre de la configuration (généralement sous la forme d'un nom DNS). Le serveur délivrera les messages sortants au nom de l'utilisateur.

Restrictions d'accès au serveur de courrier sortant

Les administrateurs de serveur doivent contrôler quels clients peuvent utiliser le serveur. Cela leur permet de lutter contre les abus tels que les spams. Deux solutions sont couramment utilisées :

• Dans le passé, de nombreux systèmes introduisaient des restrictions sur l'emplacement du client, n'autorisant l'utilisation que de ceux dont l'adresse IP faisait partie de celles contrôlées par les administrateurs.
• Les serveurs modernes offrent généralement un système alternatif qui nécessite que les clients soient authentifiés pour pouvoir y accéder.

Restreindre l'accès par emplacement

Dans ce cas, le serveur SMTP du FAI n'autorisera pas l'accès aux utilisateurs "en dehors" du réseau du FAI. Plus précisément, le serveur ne peut accepter que les utilisateurs dont l'adresse IP est fournie par le FAI, ce qui revient à exiger une connexion Internet via ce FAI. Un utilisateur mobile peut souvent être sur un réseau différent de celui de son FAI, et par conséquent aucun message ne sera envoyé.

Ce système a plusieurs variétés. Par exemple, le serveur SMTP d'une organisation peut n'accorder l'accès qu'aux utilisateurs du même réseau, tout en bloquant les autres utilisateurs. Le serveur peut également effectuer une série de vérifications sur l'adresse IP du client. Ces méthodes étaient couramment utilisées par les organisations et les institutions, telles que les universités, pour une utilisation interne du serveur. Cependant, la plupart d'entre eux utilisent désormais les méthodes d'authentification décrites ci-dessous.

En restreignant l'accès à certaines adresses, les administrateurs du serveur peuvent facilement déterminer l'adresse de tout intrus. Si l'utilisateur peut utiliser différents FAI pour se connecter à Internet, ce type de restriction devient peu pratique et la modification de l'adresse du serveur SMTP sortant configuré est peu pratique. Il est hautement souhaitable de pouvoir utiliser des informations de paramètres client qui n'ont pas besoin d'être modifiées.

Authentification des clients

Au lieu de la restriction d'emplacement décrite précédemment, les serveurs SMTP modernes exigent généralement que les utilisateurs soient authentifiés avant d'avoir accès. Ce système, tout en étant plus flexible, prend en charge les utilisateurs mobiles et leur fournit un choix fixe de serveur de courrier sortant configuré.

relais ouvert

Un serveur accessible au réseau étendu et qui ne fournit pas ces types de restrictions d'accès est appelé un relais ouvert. Maintenant, ces serveurs sont considérés comme de mauvaises manières.

Ports

Les administrateurs de serveur choisissent le port que les clients utiliseront pour relayer le courrier sortant - 25 ou 587. Les spécifications et de nombreux serveurs prennent en charge les deux ports. Bien que certains serveurs prennent en charge le port 465 pour le SMTP sécurisé, il est préférable d'utiliser les ports standard et les commandes ESMTP si une session sécurisée est requise entre le client et le serveur.

Certains serveurs sont configurés pour rejeter tous les relais sur le port 25, mais les utilisateurs authentifiés sur le port 587 sont autorisés à transférer des messages vers n'importe quelle adresse valide.

Certains FAI interceptent le port 25, redirigeant le trafic vers leur propre serveur SMTP, quelle que soit l'adresse de destination. Ainsi, leurs utilisateurs ne peuvent pas accéder au serveur en dehors du réseau du FAI sur le port 25.

Certains serveurs prennent en charge l'accès authentifié sur un port supplémentaire autre que 25, permettant aux utilisateurs de s'y connecter même si le port 25 est bloqué.

Un exemple de session SMTP simple

C : - client, S : - serveur