Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Standard

Niveau :      
Résumé : TP NTP

Avant, il y avait l'heure

Le time protocol est un protocole permettant de se mettre à l'heure en se comparant avec l'heure d'une autre machine. Ce protocole est infiniment simple : on se connecte sur le serveur (port 37), le serveur répond un temps en 32 bits et c'est fini. Ceci marche en tcp et en udp comme indiqué dans la RFC 868.

Bon évidemment la simplicité se paye, la précision d'un tel protocole est très réduite, de plus il ne permet pas réellement la synchronisation entre plusieurs serveurs. De plus 32 bits c'est un peu léger pour représenter une date, on a une précision à la seconde.

Finalement, mauvaise idée, ce protocole ne sert qu'à avoir l'heure.

Avant, il y avait l'horloge

Il existe un autre protocole nommé ICS (internet clock service) décrit ici dans la RFC 778. La méthode reste assez simple. Il s'agit de mesurer les temps d'aller et de retour des paquets dans la communication avec un serveur ics. Grâce aux différences entre les différents temps on peut en déduire le décalage avec le serveur et donc le corriger.

Le service utilise des entiers de 32 bits avec une précision à la milliseconde, donc un décalage maximum de 25 jours.

Après il y eu le réseau

Un nouveau protocole est apparu, nommé NTP (network time protocol), capable de donner la date et l'heure mais aussi le décalage avec l'horloge locale. Il se base sur le même principe qu'ICS, mais en utilisant 2 fois 32 bits (pour former un nombre 64 bits à virgule fixe). On peut donc avoir une précision énorme (1/2^32 s) tout en ayant une échelle de temps suffisante pour avoir la date (136 ans).

De plus, ses évolutions permettent une synchronisation entre des réseaux de serveurs (strates) pour conserver au mieux une heure précise à l'intérieur de ce réseau.

La dernière rfc à ce sujet est pour NTPv3 RFC 1305.

Aujourd'hui le protocole en est à sa version 4 (non rfcisé) et la version 5 est en cours de développement.

À bientôt pour un nouvel article sur la configuration de ntp.

Niveau :      
Résumé : Submission

Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.

Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP. Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.

La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.

La différence se fera donc au niveau des vérifications faites sur le serveur.

Un serveur servant à recevoir des mails devra vérifier :

  • que le destinataire est valide et accepté localement

Un serveur submission doit :

  • fournir de nouveaux codes d'erreur pour que le client mail puisse mieux interpréter les problèmes
  • envoyer des mails contenant uniquement des domaines valides dans l'enveloppe
  • vérifier si possible que les adresses d'envoi fournies sont valides

Un serveur submission devrait :

  • répondre par un code d'erreur en cas de rejet et non par un mail au return path
  • vérifier que l'émetteur est valide et reconnu comme utilisateur par le serveur (voire l'authentifier) et donc que le chemin de retour est valable
  • rejeter les mails avec des adresses connues comme invalides
  • loguer les erreurs

D'autre part, du fait de sa position privilégiée, un serveur submission peut :

  • vérifier les droit d'envoi des utilisateurs
  • demander une authentification
  • vérifier la validité du contenu du mail
  • modifier les en-têtes du mail : champ date, sender, message-id ...

L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.

Niveau :      
Résumé : RFC 2822

Un mail est composé d'en-têtes et d'un corps. Les en-têtes sont de 2 types. Les en-têtes d'enveloppes et les autres. Un serveur qui ne fait que faire transiter un mail devrait toujours ajouter une en-tête d'enveloppe au tout début des en-têtes et ne pas toucher du tout au reste du mail. Ces en-têtes précisent par où et à quelle heure le mail est passé, elles se lisent de bas en haut.

Les autres en-têtes sont celles écrites par l'émetteur. Seul l'émetteur et le récepteur ainsi que les serveurs de mailing-list (qui sont les 2 à la fois) devraient toucher à ces en-têtes. De nos jour, cela inclue aussi les serveurs qui font de l'antispam et/ou antivirus.

Les en-têtes obligatoires :

  • From: Savez vous que vous pouvez mettre plusieurs from ! Dans ce cas, il Faut préciser Sender:
  • Date: devinez

Les quasi-indispensables :

  • To:
  • Cc:
  • Subject:
  • Bcc: Sisi il existe, donc vous devez être au courant quand vous êtes destinataires d'un Bcc. Mais pourquoi les clients mail ne le précisent-ils pas ? Cela éviterait les bourdes.

Les utiles :

  • Reply-To:

Les indispensables mais incompris :

  • Message-ID: de la forme <truc@machin> doit être universellement unique
  • In-Reply-To: donne uniquement le parent (duplique l'information du suivant)
  • References: donne tout le fil parent (important pour suivre les conversations)

Les inconnus:

  • Comments: Mais qui les liraient ?
  • Keywords: C'est pas comme si vos mails étaient indexés
  • Resent-From:
  • Resent-Date:
  • Resent-Message-ID:

Les en-têtes d'enveloppe :

  • Return-Path: Indique où renvoyer les mails d'erreur (MAIL FROM: du protocole SMTP)
  • Received: date, heure, lieu de réception par le serveur

Les autres :

Les en-têtes commençant par X- permettent à leurs utilisateurs de créer les en-têtes qui leur semblent utile. En voici quelques exemples :

  • X-Mailer:
  • X-Spam-Level:
  • X-Loop:

Et comme toujours, les détails dans la RFC 2822

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.

Niveau :      
Résumé : IMAP

Ceci est le début d'une série sur le mail.

Comment tester un serveur IMAP qu'on vient juste d'installer ? Il suffit de connaître les bases du protocole IMAP.

Tout d'abord, chaque commande IMAP est précédée d'un identififant permettant au client de repérer à quelle requête correspond la réponse donnée par le serveur, ceci car le protocole peut être asynchrone. La plupart des client mettent des numéros, mais vous pouvez aussi les remplacer simplement par des '.'.

Tentons une connexion de base avec création d'un répertoire (les lignes que vous tapez sont précédées de > ):

> $ telnet imap.net.net 143
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  * OK Dovecot ready.
> 1 LOGIN user password
  1 OK Logged in.
> 2 CREATE toto
  2 OK CREATE completed
> 3 LOGOUT
  * BYE Logging out
  3 OK Logout completed.
  Connection closed by foreign host.

Passons à quelque chose de plus sérieux. On sélectionne le répertoire INBOX, puis on liste les messages de 1 à la fin (1:*) et on récupère un message.


continue reading...

Niveau :      
Résumé : http://linux-attitude.fr/

Une URL est un Uniform Resource Locator, un descripteur qui donne une localisation unique de quelque chose.

Une URL a la forme longue suivante :

protocole://user:pass@f.q.d.n:port/chemin

Dans le cas du http, on peut détailler


http://user:pass@f.q.d.n:port/fichier?parametres#position

Mais il existe bien d'autres cas particuliers. Par exemple on peut définir des URL pour l'accès aux bases de données. Chacun a ses spécificités mais ne s'éloigne que très peu du premier cas.

Un FQDN est un fully qualified domain name. C'est un nom complet, comprenant le nom de domaine et le nom local. Exemple www.toto.net.

Une URI est un Universal Resource Identifier. En pratique une URI a la même forme qu'une URL (bien qu'il serait étonnant qu'on y trouve un login et un mot de passe). La différence entre les deux vient de leur utilisation. Une URI sert à identifier de façon unique un document. Ce qui veut dire qu'il n'y a pas nécessairement de document au bout de l'URL correspondante, même si c'est possible, ce n'est qu'un identifiant. Notez que les URI qui ne sont pas des URL sont appelée des URN (Uniform Resource Name)

Étant donné qu'on peut garantir qu'un fdqn appartient à une personne (physique ou morale) de façon unique, on peut être sur qu'elle est capable de gérer elle-même l'unicité des URI qu'elle crée. C'est ainsi qu'on garantit le côté unique des URI.

Et accessoirement si le document en question est public, il est possible de le mettre à disposition sur l'URL correspondante.

Plus d'information à ce propos sur la RFC 2396.

Niveau :      
Résumé : telnet www.net http

Il existe toujours de bonnes raisons pour connaître les protocoles ou tout au moins connaitre les commandes de base. Dans le cas du HTTP, c'est assez simple. Le protocole HTTP 1.0 peut être résumé en une ligne :

$ telnet www.com http
> GET /toto.html

Et c'est tout, la page http://www.com/toto.html est renvoyée telle quelle.

Pour quelques options supplémentaires, il faut préciser la version de http désirée (HTTP/1.0 ou HTTP/1.1).

Le HTTP 1.0 est tout de même dépassé de nos jours. Les sites web étant très souvent mutualisés sur les mêmes serveurs, il vous faut connaître le HTTP 1.1. La base reste assez simple (attention au dernier retour à la ligne) :

$ telnet www.com http
> GET /toto.html HTTP/1.1
> Host: www.com
>

Et voilà, vous avez quasiment le même résultat précédé de quelques en-têtes. Ou un résultat différent s'il y avait plusieurs sites différents hébergés sur www.com. N'oubliez pas ce petit truc, c'est bien pratique pour tester un site dont l'entrée DNS n'est pas encore déclarée correctement. Il suffit de faire le telnet directement sur l'ip.

Notez qu'avec wget vous pouvez faire l'équivalent :

$ wget --header="Host: www.com" "http://127.0.0.1/toto.html"

continue reading...