Résumé

  • Le SMTP de 1982 permettait à un serveur de recevoir un message destiné à un autre serveur, puis de devenir l'expéditeur du trajet suivant.
  • Le RFC 2505 de 1999 a exigé qu'un logiciel de transfert puisse refuser ce service aux inconnus : HELO et MAIL FROM étaient des déclarations faciles à falsifier, pas des permis de transport.

Le serveur de courrier se croyait peut-être serviable. Un inconnu se présentait, déposait un sac de lettres, donnait un nom à l'accueil et demandait qu'on expédie le tout ailleurs. À la fin des années 1990, cette générosité technique pouvait faire d'un ordinateur et de sa réputation le chauffeur gratuit d'une campagne de messages indésirables.

Le relais était pourtant un métier normal du courrier électronique. Dans le RFC 821 d'août 1982, un serveur SMTP qui reçoit un message destiné plus loin peut accepter ou refuser de le relayer. S'il accepte, il devient lui-même émetteur pour la prochaine étape. Le texte distingue l'adresse finale de la route suivie entre machines. Acheminer un message à travers plusieurs systèmes faisait partie de la capacité du réseau à relier ses différents milieux.

Le problème tenait donc à l'entrée du garage : qui pouvait réquisitionner le véhicule ? Le RFC 2505 de février 1999, publié comme Best Current Practice 30, qualifiait l'utilisation non autorisée d'un relais de captation de ses ressources et de risque pour la réputation de son exploitant. Sa consigne allait droit au guichet : un logiciel de transfert devait pouvoir contrôler et refuser ce relais. L'ancienne possibilité de transporter restait ; l'autorisation devenait explicite.

Le document examine quatre éléments d'une conversation SMTP et ne leur accorde pas la même confiance. Le nom annoncé dans HELO peut être inventé. L'adresse déclarée dans MAIL FROM aussi. RCPT TO désigne le destinataire visé ; la machine voit également l'adresse réseau du correspondant. Confier le droit de relayer aux deux premières chaînes de caractères revenait à donner les clés du camion à celui qui avait simplement prononcé le nom du patron.

La règle proposée regarde plutôt les obligations propres du serveur. Il peut accepter les messages destinés à un domaine qu'il dessert ou pour lequel il assure réellement le transfert. Il peut aussi transporter le courrier d'un correspondant autorisé par son adresse IP ou, si l'exploitant fait confiance au DNS, par son nom d'hôte. Dans les autres cas, il refuse le relais. Une courte règle transforme une faveur anonyme en service délimité par les clients et les destinations dont l'opérateur répond.

Même cette courte règle demandait de connaître les vieilles ruses de l'adresse. Le RFC 2505 mentionne les routes de la forme @a,@b:, les détours avec % et les chemins UUCP utilisant !. Un contrôle naïf pouvait y voir un destinataire local tandis que le message préparait encore un voyage. À l'inverse, des passerelles légitimes employaient des écritures inhabituelles. Le texte demandait de répertorier les chemins utilisés avant de fermer la barrière. Pour vérifier la destination, encore fallait-il savoir la lire.

Quelques mois plus tard, le RFC 2635 de juin 1999, DON'T SPEW, s'adressait notamment aux fournisseurs d'accès. Il recommandait de fermer les relais ouverts aux inconnus, de formuler une politique d'usage, de vérifier les abus avant de sanctionner un compte et de tenir de vraies boîtes abuse et postmaster. Le logiciel pouvait refuser une transaction au bon endroit. Les plaintes, les contrats et les erreurs d'accusation réclamaient toujours des humains derrière la machine.

Le RFC 5321 d'octobre 2008 montre ce que cette barrière n'avait pas simplifié. Le courrier électronique repose sur une vieille attente : remettre un message ou signaler son échec. Le courrier indésirable avait rendu certains rejets et abandons nécessaires dans la pratique, alors qu'une disparition silencieuse pouvait miner la confiance dans le service. Autoriser correctement un relais répond à la question « qui peut utiliser cette machine ? ». Le trajet d'un message et le compte rendu de sa perte restent des responsabilités distinctes.

Le serveur n'avait donc pas à renoncer à conduire. Il devait savoir pour quels destinataires et pour quels expéditeurs autorisés il travaillait. En 1982, relayer était une tâche possible ; en 1999, prendre un inconnu sur parole pour la lui confier était devenu une mauvaise affaire. Le chauffeur gardait la clé. Le passager cessait de rédiger lui-même le permis.