Linux Attitude

Niveau :      
Résumé : SMTP

Connaître le protocole SMTP est indispensable. Cela permet de faire quelque blagues, mais surtout de comprendre en quoi le protocole contient fondamentalement des failles et comment le spam fonctionne.

Le protocole est extrêmement simple, une session se résume en quelques commandes. Les codes de retour sont un peu les mêmes que FTP et HTTP , ainsi un 2xx indique une réussite. Voici une session typique (les lignes que vous tapez sont précédées de > ) :

> $ telnet smtp.mail.net 25
  220 smtp.mail.net ESMTP ; Wed, 1 Aug 2007 14:44:41 +0200
> EHLO toto
  250-smtp.mail.net Hello localhost [127.0.0.1], pleased to meet you
> MAIL FROM: ben@fr.fr
  250 ben@fr.fr... Sender ok
> RCPT TO: bob@fr.fr
  250 bob@fr.fr... Recipient ok
> DATA
  354 Enter mail, end with "." on a line by itself
> Coucou !
> .
  250 OAA25287 Message accepted for delivery
> QUIT
  221 smtp.mail.net closing connection 

Le EHLO devrait être suivi par le fqdn de l'émetteur. De plus en plus souvent le serveur vérifie ce qu'il contient. Il peut être évité ou remplacé par un HELO sur les serveurs mails qui font peu de vérifications.

MAIL FROM et RCPT TO doivent être indiqué dans cet ordre, ils indiquent la personne de qui vient le mail (non vérifié) et à qui il est destiné (le vrai destinataire). La norme suggère de mettre les adresses mail entre <> et certains serveurs l'exigent.

Enfin la commande DATA indique le contenu du mail. Lequel ne se termine que pas un '.' seul sur une ligne. Ce mail peu contenir absolument tout ce que vous voulez. Le serveur le transférera tel quel à la boite du destinataire avec quelques en-tête supplémentaires. Éventuellement il peut le faire passer par un antispam, antivirus, serveur de mailing-list ...

Pour plus de détails Lisez la RFC 2821

Vous aurez compris que les failles se situent dans les vérifications. Dans les champs, seul RCPT TO est toujours vérifié et entièrement validé seulement si le destinataire est local. Le mail lui-même n'est pas vérifié. Le format est (potentiellement) libre. Le mail étant lu par le client final, il est tout de même préférable qu'il respecte la RFC 822

On peut donc spécifier un destinataire ou un émetteur différent dans le corps et dans les informations données au serveur.

Il vous faudra attendre l'article suivant pour pouvoir écrire un mail complet.