Aller au contenu principal

3. Les procédures SMTP : aperçu (The SMTP Procedures: An Overview)

Cette section fournit un aperçu des opérations SMTP, notamment l'initiation de session, les transactions de courrier, la vérification d'adresse, le relais, le passage par passerelle et la terminaison de session.

3.1. Initiation de session (Session Initiation)​

Une session SMTP (SMTP session) est initiée lorsque le SMTP émetteur (client) établit un canal de transmission bidirectionnel avec le SMTP récepteur (serveur). Le canal est entièrement asynchrone et il n'y a pas de restriction sur le flux de données. Après avoir complété la connexion TCP, le serveur envoie normalement une réponse "220 Service ready" (service prêt). Le client commence normalement les opérations après avoir reçu cette salutation.

3.2. Initiation du client (Client Initiation)​

Après que le service de transport ait fourni le canal d'initiation et que le serveur ait envoyé la salutation 220 service prêt, le client envoie normalement la commande EHLO (EHLO command) pour s'identifier et demander au serveur de l'informer des extensions de service disponibles. Si le serveur ne prend pas en charge les extensions, il répondra avec une erreur 500 à EHLO, et le client DEVRAIT (SHOULD) revenir à la commande HELO (HELO command).

Exemple de commande EHLO :

S: 220 smtp.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 HELP

3.3. Transactions de courrier (Mail Transactions)​

Une transaction de courrier (mail transaction) comprend une série de commandes du client vers le serveur pour transférer un message. Une transaction de courrier inclut :

  1. Commande MAIL - Identifie l'expéditeur du message
  2. Une ou plusieurs commandes RCPT - Identifie le(s) destinataire(s) du message
  3. Commande DATA - Envoie le contenu du message

Exemple de transaction complète :

C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C: 
C: This is a test message.
C: .
S: 250 Ok: queued as 12345

La commande MAIL initie la transaction de courrier. L'achèvement réussi de cette commande fait que le récepteur efface tous les tampons et tables d'état et se prépare à recevoir les commandes RCPT.

La commande RCPT identifie un destinataire individuel de ce courrier. Plusieurs commandes RCPT peuvent être émises pour un message particulier. Chaque commande RCPT réussie ajoute un destinataire au tampon.

La commande DATA fait que les lignes suivantes soient traitées comme du texte de message plutôt que comme des commandes. Le message est terminé par une ligne contenant uniquement un point (.).

3.4. Transfert pour correction ou mise à jour d'adresse (Forwarding for Address Correction or Updating)​

Certains serveurs peuvent souhaiter transférer le courrier vers une adresse corrigée ou mise à jour plutôt que vers l'adresse du destinataire d'origine. SMTP fournit les codes de réponse 251 et 551 (response codes) à cette fin. Ces codes permettent au serveur d'informer le client que l'adresse de l'utilisateur a changé, mais que le serveur tentera de transférer le message (251) ou ne peut pas le transférer (551).

3.5. Commandes de débogage d'adresse (Commands for Debugging Addresses)​

3.5.1. Aperçu (Overview)​

SMTP fournit deux commandes pour vérifier les noms d'utilisateur et les listes de diffusion :

  • VRFY - Vérifie un nom d'utilisateur ou une boîte aux lettres
  • EXPN - Étend une liste de diffusion

Ces commandes sont principalement destinées au débogage et de nombreux serveurs les désactivent ou les restreignent pour des raisons de sécurité et de confidentialité.

3.5.2. Réponse normale VRFY (VRFY Normal Response)​

Une réponse réussie à la commande VRFY est normalement le code 250 suivi d'un texte contenant le nom complet de l'utilisateur et l'adresse de la boîte aux lettres.

Exemple :

C: VRFY Jones
S: 250 Fred Jones <[email protected]>

3.5.3. Signification de la réponse de succès VRFY ou EXPN (Meaning of VRFY or EXPN Success Response)​

Une réponse réussie aux commandes VRFY et EXPN ne garantit pas que l'adresse pourra recevoir du courrier ou que le courrier sera livré. Elle indique simplement que l'adresse est connue du serveur et est syntaxiquement valide.

3.5.4. Sémantique et applications d'EXPN (Semantics and Applications of EXPN)​

La commande EXPN est utilisée pour étendre une liste de diffusion ou un alias. Elle retourne toutes les adresses dans la liste.

Exemple :

C: EXPN staff
S: 250-Alice <[email protected]>
S: 250-Bob <[email protected]>
S: 250 Charlie <[email protected]>

3.6. Relais et routage du courrier (Relaying and Mail Routing)​

3.6.1. Routes sources et relais (Source Routes and Relaying)​

Le routage par source (source routing) (spécifier explicitement un chemin via des hôtes intermédiaires) est déprécié dans le SMTP moderne. Le routage du courrier DEVRAIT (SHOULD) s'appuyer sur les enregistrements MX DNS.

3.6.2. Enregistrements d'échange de courrier et relais (Mail eXchange Records and Relaying)​

Le système d'enregistrements MX (Mail eXchanger) DNS est utilisé pour identifier les serveurs de courrier responsables de l'acceptation du courrier pour un domaine. Lors de la livraison de courrier :

  1. Rechercher les enregistrements MX pour le domaine de destination
  2. Trier par priorité (nombre inférieur = priorité supérieure)
  3. Tenter la livraison aux serveurs par ordre de priorité
  4. Si tous les enregistrements MX échouent, tenter la livraison directe aux enregistrements A/AAAA

Exemple d'enregistrements MX DNS :

example.com.  IN MX 10 mail1.example.com.
example.com.  IN MX 20 mail2.example.com.
example.com.  IN MX 30 mail3.example.com.

3.6.3. Serveurs de soumission de messages comme relais (Message Submission Servers as Relays)​

Les agents de soumission de messages (Message Submission Agents, MSAs) fonctionnent comme des relais spéciaux qui :

  • Acceptent le courrier des agents utilisateurs de courrier (Mail User Agents, MUAs)
  • Appliquent les politiques de soumission
  • Ajoutent les en-têtes nécessaires
  • Authentifient les expéditeurs
  • Transmettent aux MTAs appropriés

3.7. Passerelle de courrier (Mail Gatewaying)​

Une passerelle de courrier (mail gateway) connecte l'infrastructure SMTP à d'autres systèmes de courrier (par exemple, X.400, UUCP). Les passerelles traduisent entre les protocoles et les formats.

3.7.1. Champs d'en-tête dans la passerelle (Header Fields in Gatewaying)​

Les passerelles DOIVENT (MUST) préserver les champs d'en-tête obligatoires et PEUVENT (MAY) ajouter des champs spécifiques à la passerelle. La traduction DOIT (MUST) maintenir l'équivalence sémantique lorsque cela est possible.

3.7.2. Lignes reçues dans la passerelle (Received Lines in Gatewaying)​

Les passerelles DOIVENT (MUST) ajouter des champs d'en-tête Received pour suivre le chemin du message :

  • Identification de la passerelle
  • Horodatage
  • Informations sur le protocole

3.7.3. Adresses dans la passerelle (Addresses in Gatewaying)​

La traduction des adresses est complexe et spécifique à la passerelle. Les passerelles DEVRAIENT (SHOULD) :

  • Préserver les informations d'adresse d'origine
  • Fournir un mappage d'adresse bidirectionnel
  • Documenter les règles de traduction

3.7.4. Autres champs d'en-tête dans la passerelle (Other Header Fields in Gatewaying)​

Les passerelles DOIVENT (MUST) gérer correctement divers champs d'en-tête :

  • From, To, Cc, Bcc (champs d'adresse)
  • Subject, Keywords (champs de texte)
  • Date (conversion d'horodatage)
  • Message-ID (préservation d'identifiant unique)

3.7.5. Enveloppes dans la passerelle (Envelopes in Gatewaying)​

Les enveloppes SMTP (MAIL FROM et RCPT TO) peuvent différer des adresses d'en-tête. Les passerelles DOIVENT (MUST) gérer correctement les deux.

3.8. Terminaison des sessions et connexions (Terminating Sessions and Connections)​

Une session SMTP est terminée avec la commande QUIT :

C: QUIT
S: 221 smtp.example.com closing connection

Après avoir envoyé la réponse 221, le serveur ferme la connexion TCP. Le client DEVRAIT (SHOULD) attendre la réponse 221 avant de fermer, mais DOIT (MUST) être prêt pour que le serveur ferme en premier.

Terminaison anormale : En cas d'erreur grave, l'une ou l'autre partie peut fermer immédiatement la connexion. Le serveur PEUT (MAY) utiliser le code de réponse 421 pour indiquer que le service n'est pas disponible avant de fermer.

3.9. Listes de diffusion et alias (Mailing Lists and Aliases)​

3.9.1. Alias (Alias)​

Un alias (alias) est un nom de boîte aux lettres qui, lorsqu'il est résolu, se réfère à un ou plusieurs autres noms de boîte aux lettres. L'expansion d'alias est transparente pour l'expéditeur.

Exemple : [email protected] pourrait être un alias pour [email protected]

3.9.2. Listes (Lists)​

Une liste de diffusion (mailing list) est similaire à un alias mais a généralement :

  • Gestion par logiciel de liste
  • Permet l'abonnement/désabonnement
  • Peut modifier les messages (ajouter des en-têtes, pieds de page)
  • Maintient une base de données d'abonnés

Lorsque le courrier est envoyé à une liste, il est étendu et livré à tous les abonnés. Le logiciel de liste généralement :

  • Ajoute des en-têtes spécifiques à la liste (List-ID, List-Unsubscribe)
  • Peut nécessiter une modération
  • Gère les rebonds
  • Maintient des archives
Dernière mise à jour le