Envoi d'un courriel
la session SMTP
SMTP
Root » Serveurs » Index » Mail » Session SMTP
L'envoi d'un mail s'effectue par le protocole SMTP (Simple Mail Transfert protocol). Il y a 3 sortes de transferts de courriels possibles:
  1. Notre serveur qui envoie un message vers l'internet (à destination du serveur qui est associé au destinataire)
  2. Notre serveur qui reçoit un message de l'internet
  3. Notre serveur qui reçoit un message d'un utilisateur local
Vous verrez plus loin pourquoi les utilisateurs locaux doivent être traités différemment.

Nous ne détaillons pas le protocole POP ou IMAP (l'utilisateur qui vide sa boite au lettres chez le fournisseur d'accès).

-

-

Session SMTP sortante

Le message est envoyé du serveur local vers un serveur externe, qui a été désigné pour recevoir les courriels (enregistrement DNS MX). Mon serveur établit une connection avec les serveur récepteur. Voici la transaction en complet: 

SYSTEM          [05D8] 01:34:08 Client session DNS query 'pandora.be' 0 (1) [OK - 2]
SYSTEM          [05D8] 01:34:08 Client session Connecting to 'smtp-pandora.telenet-ops.be'
195.130.132.51  [05D8] 01:34:08 Client session Connected
195.130.132.51  [05D8] 01:34:08 Client session <<< 220 circe.telenet-ops.be ESMTP Postfix
195.130.132.51  [05D8] 01:34:08 Client session >>> EHLO mail.verfaillie.com
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 8BITMIME
195.130.132.51  [05D8] 01:34:08 Client session >>> MAIL From:<postmaster@idemdito.org> SIZE=1006
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok
195.130.132.51  [05D8] 01:34:08 Client session >>> RCPT To:<xxxx@pandora.be>;
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok
195.130.132.51  [05D8] 01:34:08 Client session >>> DATA
195.130.132.51  [05D8] 01:34:08 Client session <<< 354 End data with <CR><LF>.<CR><LF>
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok: queued as E630133E93
195.130.132.51  [05D8] 01:34:08 Client session *** <postmaster@idemdito.org> <xxxx@pandora.be> 1 OK
195.130.132.51  [05D8] 01:34:08 Client session >>> QUIT
195.130.132.51  [05D8] 01:34:08 Client session <<< 221 Bye
SYSTEM          [05D8] 01:34:08 Client session Disconnected
Notre serveur à un courriel à transmettre à xxxx@pandora.be. Le serveur recherche via une demande DNS quel serveur est habilité à recevoirs les messages pour telenet.be. Le serveur est smtp-pandora.telenet-ops.be. Mon serveur établit donc une connection avec ce serveur pour envoyer le message. "<<<" indique une commnde entrante, ">>>" une commande sortante.

On voit ici très bien la structure d'un échange SMTP:


EHLO mail.verfaillie.com
250...
MAIL FROM: ...
250...
RCPT TO: ...
250...
DATA
354...
250...

Nous indiquons d'abord qui nous sommes avec la commande HELO ou EHLO (extended HELO, car notre serveur utilise l'extended SMTP). Le serveur essaie premièrement avec EHLO, et si le destinataire ne comprend pas l'ordre, on essaie avec HELO.
Le nom indiqué coppespond au nom du serveur, comme indiqué dans les enregistrements DNS. Le destinataire peut controler le nom en utilisant la fonction reverse DNS. Le destinataire peut refuser le courriel si le nom ne correspond pas, ou s'il n'y a pas d'enregistrement PTR.

MAIL FROM: contient l'adresse de l'expéditeur. Cela n'est pas nécessairement l'adresse indiquée dans l'en-tête du message. Cela est par exemple le cas de listes de distribution.

  • Quand le message n'arrive pas à destination (destinataire inconnu), le message est réenvoyé à l'adresse indiquée dans la session SMTP (MAIL FROM:)
  • Quand le destinataire répond, le message est envoyé à l'adresse indiquée dans le message même (en-tête)

RCPT TO: est le destinataire effectif du message, et ne doit pas nécessairement correspondre à l'adresse dans le message. Quand une liste de distribution reçoit un message, elle va l'envoyer à tous les abonnés. Le message en lui-même n'est pas modifié (le message est donc toujours adressé à la liste), mais pour chaque destinataire le serveur va générer un message individuel avec un autre RCPT TO:

Le message est envoyé ensuite. Le message se termine par un point sur une seule ligne. L'expéditeur peut ensuite envoyer un nouveau message (MAIL FROM:) ou demander la fin de la communication (QUIT).

A chaque ligne (ordre), le serveur qui reçoit le message répond par un status: 220-identification, 250-ok, etc.

Session SMTP entrante

Nous nous plaçons maintenant du point de vue du serveur qui reçoit un message pour un des utilisateurs locaux. 

195.238.6.53    [0744] 02:15:06 Connected
195.238.6.53    [0744] 02:15:06 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 02:15:06 +0200
195.238.6.53    [0744] 02:15:06 <<< EHLO mailrelay003.isp.belgacom.be
195.238.6.53    [0744] 02:15:06 >>> 250-mail.verfaillie.com Hello mailrelay003.isp.belgacom.be [195.238.6.53]
195.238.6.53    [0744] 02:15:06 <<< MAIL FROM:<xxxx@skynet.be> SIZE=23529
195.238.6.53    [0744] 02:15:06 >>> 250 2.1.0 <xxxx@skynet.be>... Sender ok
195.238.6.53    [0744] 02:15:06 <<< RCPT TO:<marc@verfaillie.be>
195.238.6.53    [0744] 02:15:06 >>> 250 2.1.5 <marc@verfaillie.be>... Recipient ok
195.238.6.53    [0744] 02:15:06 <<< DATA
195.238.6.53    [0744] 02:15:06 >>> 354 Enter mail, end with "." on a line by itself
195.238.6.53    [0744] 02:15:10 *** <xxxx@skynet.be> <marc@verfaillie.be> 1 27095 00:00:04 OK ZKJ31306
195.238.6.53    [0744] 02:15:10 >>> 250 2.6.0 27095 bytes received in 00:00:04; Message id ZKJ31306 accepted
195.238.6.53    [0744] 02:15:15 <<< QUIT
195.238.6.53    [0744] 02:15:15 >>> 221 2.0.0 mail.verfaillie.com closing connection
195.238.6.53    [0744] 02:15:15 Disconnected
Nous avons reçu un message de quelqu'un qui a comme fournisseur d'accès skynet. C'est une transaction toute à fait normale. 


216.234.107.186 [0744] 00:00:25 Connected
216.234.107.186 [0744] 00:00:25 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 00:00:25 +0200
216.234.107.186 [0744] 00:00:25 <<< EHLO mail.electricalsalesco.com
216.234.107.186 [0744] 00:00:25 >>> 250-mail.verfaillie.com Hello mail.electricalsalesco.com [216.234.107.186]
216.234.107.186 [0744] 00:00:25 <<< MAIL FROM:<aw-confirm@eBay.com> SIZE=8776
216.234.107.186 [0744] 00:00:25 >>> 250 2.1.0 <aw-confirm@eBay.com>... Sender ok
216.234.107.186 [0744] 00:00:25 <<< RCPT TO:<marc@idemdito.org>
216.234.107.186 [0744] 00:00:26 >>> 250 2.1.5 <marc@idemdito.org>... Recipient ok
216.234.107.186 [0744] 00:00:26 <<< DATA
216.234.107.186 [0744] 00:00:26 >>> 354 Enter mail, end with "." on a line by itself
216.234.107.186 [0744] 00:00:26 *** <aw-confirm@eBay.com> <marc@idemdito.org> 1 8774 00:00:00 OK YGT12526
216.234.107.186 [0744] 00:00:26 >>> 250 2.6.0 8774 bytes received in 00:00:00; Message id YGT12526 accepted
216.234.107.186 [0744] 00:00:26 <<< QUIT
216.234.107.186 [0744] 00:00:26 >>> 221 2.0.0 mail.verfaillie.com closing connection
216.234.107.186 [0744] 00:00:26 Disconnected
A première vue, il s'agit d'une transaction normale. Mais mail.electricalsalesco.com n'a rien à voir avec ebay.com. Il s'agit d'un serveur utilisé par des hackers pour envoyer du spam (messages non sollicités). Mon serveur va décider de classifier ou non ce message comme spam et va le déplacer vers un répertoire séparé. 


74.75.87.244    [0744] 02:40:29 Connected
74.75.87.244    [0744] 02:40:29 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 02:40:29 +0200
74.75.87.244    [0744] 02:40:29 <<< EHLO cpe-74-75-87-244.maine.res.rr.com
74.75.87.244    [0744] 02:40:29 >>> 250-mail.verfaillie.com Hello cpe-74-75-87-244.maine.res.rr.com [74.75.87.244]
74.75.87.244    [0744] 02:40:29 <<< MAIL From:<spud@0hamilton.freeserve.co.uk>
74.75.87.244    [0744] 02:40:29 >>> 501 5.7.1 <spud@0hamilton.freeserve.co.uk>...
                                                Sender refused by the DNSBL sbl-xbl.spamhaus.org
74.75.87.244    [0744] 02:40:29 *** <spud@0hamilton.freeserve.co.uk> <> 0 0 00:00:00 INCOMPLETE-SESSION
74.75.87.244    [0744] 02:40:29 Disconnected
Il s'agit ici d'un message en provenance d'un serveur compromis (il laisse passer tous les messages ou envoie trop de spam). Il y a des organisations sur l'internet qui établissent une liste de serveurs compromis. Quand mon serveur est contacté par un serveur qui voudrait envoyer un message, il consulte la base de données (il fait cela pour toutes les connections). Si le serveur est présent dans la base de donnée, il refuse tout simplement la connection.

Session SMTP d'un utilisateur local

Les utilisateurs du système local doivent pouvoir s'identifier pour pouvoir utiliser le serveur et envoyer des messages. 

84.196.169.33   [0454] 08:11:00 Connected
84.196.169.33   [0454] 08:11:00 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sun, 21 Oct 2007 08:11:00 +0200
84.196.169.33   [0454] 08:11:00 <<< EHLO t415492
84.196.169.33   [0454] 08:11:00 >>> 250-mail.verfaillie.com Hello t415492 [84.196.169.33], pleased to meet you.
84.196.169.33   [0454] 08:11:00 <<< AUTH CRAM-MD5
84.196.169.33   [0454] 08:11:00 >>> 334 PDIwMDqSlT1qWzjNtTAwQG1haWwudmVyZmFpbGxpZS5jb20+
84.196.169.33   [0454] 08:11:00 <<< bWFyYyBiNjk3MzU4OWFjZTAej5w7XszK42RenzY7JiqlG9OlZQ==
84.196.169.33   [0454] 08:11:00 >>> 235 2.0.0 Authentication successful
84.196.169.33   [0454] 08:11:00 <<< MAIL FROM:<marc@verfaillie.be> SIZE=4419
84.196.169.33   [0454] 08:11:00 >>> 250 2.1.0 <marc@verfaillie.be>... Sender ok
84.196.169.33   [0454] 08:11:00 <<< RCPT TO:<xxxx@yyyy.be>
84.196.169.33   [0454] 08:11:00 >>> 250 2.1.5 <xxxx@yyyy.be>... Recipient ok
84.196.169.33   [0454] 08:11:00 <<< DATA
84.196.169.33   [0454] 08:11:00 >>> 354 Enter mail, end with "." on a line by itself
84.196.169.33   [0454] 08:11:00 *** <marc@verfaillie.be> <xxxx@yyyy.be> 1 4391 00:00:00 OK AQG46800
84.196.169.33   [0454] 08:11:00 >>> 250 2.6.0 4391 bytes received in 00:00:00; Message id AQG46800 accepted
84.196.169.33   [0454] 08:11:00 <<< QUIT
84.196.169.33   [0454] 08:11:00 >>> 221 2.0.0 mail.verfaillie.com closing connection
84.196.169.33   [0454] 08:11:00 Disconnected
L'utilisateur doit s'identifier avec la commande AUTH. Le serveur va envoyer un "challenge string" et l'utiisateur va répondre avec un "response string". Le mot de passe n'est jamais envoyé, mais est utilisé pour produire le code (CRAM: challenge-response authentification method). Une fois que l'utilisateur s'est identifié, il peut employer le serveur pour envoyer des messages.

Les utilisateurs de Skynet ou Telenet (Numéricable) ne doivent pas s'identifier: ils ont accès d'office au serveur parce qu'ils utilisent le réseau de Skynet. Un problème peut surgir quand un utilisateur utilise Numéricable à la maison et Skynet au boulot (avec le même laptop). Une fois qu'il est sur le mauvais réseau, le serveur va refuser la connection.

Dans notre exemple (petit serveur pour la maison ou pour une PME), les utilisateurs passent directement par le serveur du fournisseur d'accès pour envoyer les mails. Ce n'est que si nous avons de nombreux utilisateurs en voyage (roaming users) que nous devons configurer notre serveur pour accepter les messages sortants des utilisateurs locaux (cela est décrit dans les pages suivantes).

Accepter tous les messages n'est pas une option: les spammeurs auront vite fait de découvrir que ton serveur est "ouvert" et l'utiliseront pour envoyer du spam.

Publicités - Reklame

-