Résumé

  • La RFC 5383 signalait que des hôtels et d’autres réseaux interceptaient parfois les connexions sortantes au port 25, quelle que soit la machine visée, exposant potentiellement des communications à un serveur tiers inconnu.
  • Le port 587 rend la soumission distincte du relais SMTP. Il ne remplace pas les preuves d’identité TLS, d’autorisation, d’acceptation en file, de relais ou de remise au destinataire.

Le faux confort d’un guichet ouvert

Une coupure est franche : le client ne se connecte pas et l’incident devient visible. L’interception décrite en 2008 est plus trompeuse. Le terminal compose l’adresse de son fournisseur de messagerie, un équipement de chemin détourne le flux destiné au port 25, puis un serveur répond correctement au protocole. L’indicateur passe au vert alors que le correspondant a changé.

La RFC 5383 ne nomme ni hôtel, ni fournisseur, ni taux de prévalence actuel. Elle ne démontre pas davantage qu’un identifiant ou un message précis a été volé. Son apport est la mise à nu du mécanisme : une preuve de joignabilité peut coexister avec l’échec de fidélité à la destination. L’opérateur de transport devient, sans annonce, sélectionneur du service applicatif.

Cette substitution est particulièrement grave pour le courrier, car le premier échange peut contenir des identifiants, des métadonnées d’expéditeur et de destinataire, voire le message. Un serveur qui sait parler SMTP n’acquiert pas pour autant le mandat de les recevoir.

Deux services, deux responsabilités

Le port 25 s’est historiquement attaché au transfert de courrier entre agents. La soumission par un utilisateur constitue une autre relation : le client remet un nouveau message à un service qui authentifie éventuellement le compte, applique une politique et accepte ou refuse la prise en charge.

La RFC 2476 a formalisé cette séparation, la RFC 4409 l’a révisée et la RFC 6409 en porte aujourd’hui la version courante. Le port 587 matérialise le guichet de soumission. Pour Lemonade, la RFC 5383 exigeait que le client puisse l’atteindre et recommandait son usage par défaut, précisément parce que le port 25 était filtré, intercepté et difficile à faire évoluer avec de nouvelles extensions.

Le choix est donc moins une astuce de connectivité qu’un découpage de l’autorité. Le service de soumission peut publier ses méthodes d’authentification, ses extensions, ses limites et ses reçus. Le service de transfert conserve son rôle inter-domaines. Le pare-feu peut décider explicitement lequel il autorise.

Mais la séparation ne vaut pas sceau d’authenticité. N’importe quel processus accessible peut écouter sur un numéro donné. Le port annonce le service attendu ; il ne prouve pas l’organisation qui répond.

La preuve doit conserver toutes ses marches

Une exploitation sérieuse doit distinguer au moins sept constats. Le client a configuré un nom. Le DNS a fourni une adresse. Le réseau a conduit la connexion vers un pair observé. TLS a, ou non, protégé le canal et validé l’identité de référence. Le serveur a, ou non, authentifié un principal. SMTP a accepté la transaction. Enfin, d’autres systèmes ont relayé et remis le message.

La RFC 8314 recommande plus tard TLS pour l’accès et la soumission et documente le service submissions sur le port 465, tout en reconnaissant le chemin STARTTLS établi sur 587. Cette évolution évite un contresens : le progrès ne vient pas du seul changement de numéro, mais d’un canal protégé dont l’identité est réellement vérifiée.

Le journal utile conserve donc le nom prévu, l’adresse résolue, le pair TCP, le mode TLS, le certificat, le résultat de validation, les capacités SMTP, le mécanisme d’authentification, le principal, la réponse du serveur et l’identifiant de file. Si tout est réduit à « connexion réussie », l’enquête perd précisément la différence que l’interception exploite.

Refuser vaut mieux que réussir sous une fausse identité

Un réseau peut avoir de bonnes raisons de bloquer le port 25 : lutte contre les machines compromises, contrôle du spam ou politique de sécurité. La question n’est pas le droit de refuser. Elle est de savoir si le réseau transforme silencieusement le refus en service de substitution.

Le blocage explicite est coûteux mais honnête. Le client peut essayer le service de soumission prévu, informer l’utilisateur ou solliciter l’assistance. L’interception produit une réussite contrefaite. Elle transfère le contenu et la confiance tout en laissant le fournisseur choisi paraître responsable d’un échange qu’il n’a jamais vu.

Les pare-feu applicatifs qui ne comprennent qu’une partie des extensions SMTP ajoutent une autre source de dérive. Une négociation peut sembler admise d’un côté et être mutilée de l’autre, créant un échec tardif. Cette analyse ne répète pas les Articles BTW consacrés à la transparence générale des pare-feu ou au transport sur HTTP. Elle garde une question plus étroite : qui a effectivement répondu à la soumission ?

Le reçu de soumission n’est pas l’accusé de lecture

Même le bon serveur, correctement authentifié, ne peut attester que ce qui relève de lui. Une réponse positive peut signifier que le service a accepté la responsabilité de la transaction. Elle ne prouve ni chaque relais ultérieur, ni l’écriture en boîte, ni l’affichage, ni la lecture.

Dans une enquête, il faut joindre des reçus bornés : choix du point de soumission, identité du canal, authentification du compte, acceptation de l’enveloppe et du contenu, garde dans la file, réponses des relais, état de destination. L’interception casse cette chaîne au début ; le numéro de file obtenu peut appartenir au système substitué et n’avoir aucun équivalent chez le fournisseur attendu.

Le test minimal répète la connexion depuis plusieurs réseaux d’accès, compare l’adresse choisie au pair réellement atteint et force des cas négatifs : certificat inattendu, absence de STARTTLS, bannière nouvelle, capacités retranchées, blocage explicite. Le client doit échouer de façon intelligible, jamais effacer une erreur d’identité pour préserver un voyant vert.

Sources