Connaître le protocole SMTP
Suivez cet article sur http://linux-attitude.fr/post/Connaitre-le-protocole-SMTP
Niveau :
Résumé : SMTP
Connaitre 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 :
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 le 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 http://www.ietf.org/rfc/rfc2821.txt
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 http://www.ietf.org/rfc/rfc0822.txt
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.
Niveau :
Résumé : SMTP
Connaitre 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 :
$ 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 le 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 http://www.ietf.org/rfc/rfc2821.txt
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 http://www.ietf.org/rfc/rfc0822.txt
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.