Comportement des relais SMTP dans Windows 2000, Windows XP et Exchange Server

Traductions disponibles Traductions disponibles
Numéro d'article: 304897 - Voir les produits auxquels s'applique cet article
Ancien nº de publication de cet article : F304897
Agrandir tout | Réduire tout

Sommaire

INTRODUCTION

Le relais Microsoft Simple Mail Transfer Protocol (SMTP) est une fonctionnalité permettant à un client SMTP d'utiliser un serveur SMTP pour le transfert des messages électroniques vers un domaine distant. Comme le décrit la RFC (Request for Comments) 282, sections 2.1 et 3.7, le serveur SMTP est conçu pour pouvoir relayer les messages électroniques.

Cependant, si le relais n'est pas contrôlé, un utilisateur malveillant peut s'en servir pour envoyer en masse des messages non sollicités. Un hôte non contrôlé est appelé hôte à « relais ouvert ». En envoyant ces messages non sollicités à l'hôte intermédiaire, l'utilisateur malveillant peut dissimuler son identité. Cette action peut également provoquer une utilisation excessive des ressources de l'hôte de relais et l'empêcher d'envoyer les messages électroniques valides. Par exemple, un utilisateur malveillant qui envoie des messages électroniques non sollicités peut envoyer le même message à plusieurs destinataires sans utiliser leur bande passante.

Par défaut, les produits Microsoft répertoriés dans la liste des produits concernés ne sont pas configurés pour le relais ouvert.

Plus d'informations

Lorsque vous utilisez des outils tiers pour tester le relais d'un serveur SMTP, ce test peut échouer et votre produit SMTP sembler être à relais ouvert, alors que ce n'est pas le cas. Ce résultat est dû au fait que le serveur SMTP peut ne pas rejeter immédiatement le message électronique. Au contraire, il le traite, puis envoie un rapport de non-remise (NDR). Pour plus d'informations sur la réponse du serveur SMTP au relais, reportez-vous à la section qui traite ce sujet. Pour plus d'informations sur la façon de tester le relais de votre serveur SMTP, reportez-vous à la section Test du relais.

Chaque adresse d'expéditeur ou de destinataire de conversation de protocole SMTP contient deux portions : la portion locale et la portion domaine. Si la portion domaine (celle qui est immédiatement suivie d'un signe @) n'est pas spécifiée, le message électronique est considéré comme local. Dans la mesure où certains utilisateurs configurent leur client SMPT pour utiliser uniquement un nom d'utilisateur comme adresse de messagerie, certains produits Microsoft SMTP y ajoutent le domaine local. En ajoutant le domaine local par défaut, le serveur Microsoft peut ajouter ce qui est le plus probablement le domaine local pour réduire les coûts de support.

Ce comportement se produit parce que certains produits Microsoft SMPT ne consultent pas l'annuaire avant d'accepter l'acheminement des messages électroniques SMPT. Ces produits vérifient uniquement si le domaine du destinataire est local ou explicitement autorisé. Si ce domaine n'est ni local, ni autorisé, le serveur SMTP affiche un message d'erreur semblable au suivant :
550 5.7.1 Relais interdit
La seule condition requise pour empêcher le relais est la vérification que la portion domaine de l'adresse du destinataire est locale. La vérification de la validité du destinataire dans l'annuaire du serveur de messagerie est facultative. Si un serveur de messagerie accepte un message et, par la suite, ne parvient pas à le distribuer, il doit générer un rapport de non-remise (NDR). Les produits Microsoft SMTP remplissent cette condition.

Remarque Microsoft Exchange Server 2003 peut exécuter des recherches dans l'annuaire pendant la conversation du protocole SMTP. Cette fonctionnalité peut être activée dans le Gestionnaire système. Pour plus d'informations sur le filtrage des destinataires dans Exchange Server 2003, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
823866 Comment faire pour configurer le filtrage de connexion de façon à utiliser des listes rouges en temps réel et pour configurer le filtrage de destinataires dans Exchange 2003

Pour vérifier les adresses, une recherche dans l'annuaire peut être effectuée pendant la conversation du protocole SMTP. Par conséquent, Microsoft vous recommande d'activer la fonctionnalité TarpitTime décrite dans l'article suivant de la Base de connaissances :
842851 Fonctionnalité Tar Pit du protocole SMTP pour Microsoft Windows Server 2003
Important Si vous effectuez des recherches dans l'annuaire durant la conversation du protocole SMTP, vous pouvez écrire un récepteur d'évènements du protocole SMTP de Microsoft Windows 2000. Pour plus d'informations, reportez-vous au site Web des évènements de serveurs SMTP du Kit de développement logiciel (SDK) de la plate-forme MSDN à l'adresse suivante (en anglais) :
http://msdn.microsoft.com/library/en-us/smtpevt/html/0e0c3b0d-5b08-42b5-8312-59a9f3cd8fd9.asp?frame=true

Réponse du serveur SMTP au relais :

La réponse compatible RFC recommandée est similaire à la suivante :
550 5.1.1 nom_utilisateur@nom_domaine.tld... Utilisateur inconnu
Dans les produits répertoriés dans les produits concernés, Microsoft n'effectue pas de recherches dans l'annuaire pendant la conversation du protocole SMTP pour les raisons suivantes :
  • Si le serveur SMTP affiche une erreur de type 5xx lorsqu'un utilisateur malveillant tente d'envoyer en masse des messages électroniques non sollicités, cet utilisateur connaîtra instantanément les adresses réelles. Si cet utilisateur envoie un dictionnaire de noms par l'intermédiaire du protocole SMTP, il peut facilement récupérer une liste d'adresses électroniques valides. Cela peut également constituer un danger pour vos utilisateurs locaux parce que leurs noms de compte sont souvent les mêmes que leurs adresses électroniques.
  • Un utilisateur malveillant peut utiliser les adresses des expéditeurs pour accéder sans autorisation à un système, puis utiliser le serveur de la victime pour envoyer des rapports de non-remise (NDR) au destinataire souhaité. Cette attaque, appelée usurpation, envahit simplement le serveur avec toutes les données que l'utilisateur malveillant lui envoie. En d'autres termes, si l'utilisateur malveillant souhaite envoyer 1 mégaoctet (Mo) de données à un tiers, il doit utiliser 1 Mo de sa largeur de bande pour envoyer 1 Mo de données au serveur SMTP. En général, il tente d'envoyer 1 Mo de données, mais une ou plusieurs victimes reçoivent des dizaines voire des centaines de Mo via Internet.
  • Si une recherche dans l'annuaire est effectuée pendant la conversation du protocole SMTP, cette dernière peut se retrouver considérablement ralentie. Lors de la publication de cet article, Microsoft partait de l'hypothèse que le serveur SMTP doit fonctionner aussi vite que possible pour empêcher le blocage des messages SMTP sur Internet ou sur les ordinateurs clients SMTP. Quelquefois, l'annuaire peut également être indisponible ou le relais d'un domaine spécifique peut être requis, mais aucune copie de l'annuaire n'est disponible. Ce comportement peut se produire dans l'environnement d'hébergement d'un fournisseur de services Internet.

Comment faire pour tester le relais

Vous pouvez tester votre serveur SMTP pour déterminer s'il est configuré pour le relais des messages électroniques. Dans les exemples suivants, les tests de relais de 1 à 5 ne sont pas acceptés par le serveur SMTP et sont immédiatement rejetés. Ce serveur accepte les tests 6 et 7, mais ne relaye pas le message électronique et finit par générer un rapport de non-remise (NDR).

Pour exécuter les tests de relais suivants, ouvrez d'abord une session Telnet et connectez-vous au port 25 de votre serveur SMTP :
  1. Démarrez une invite de commandes.
  2. Tapez telnet nom_serveur 25, où nom_serveur représente le nom du serveur SMTP ou l'adresse IP et 25 le numéro du port, puis appuyez sur ENTRÉE.
  3. Tapez EHLO, puis appuyez sur ENTRÉE.

Test de relais 1

Il s'agit du test standard du relais SMTP. Un client SMTP ne doit pas être autorisé à effectuer ce type de relais, sauf si l'administrateur l'autorise spécifiquement ou si le client s'authentifie au préalable. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:nom_utilisateur@nom_domaine.tld, où nom_utilisateur est le nom de l'utilisateur, nom_domaine celui du domaine et tld le domaine au niveau le plus élevé, par exemple .com ou .net.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.0 nom_utilisateur@nom_domaine.tld....Expéditeur OK
  3. Tapez RCPT TO:nom_destinataire@nom_domaine.tld, où nom_destinataire est l'adresse électronique du destinataire.

    La session telnet affiche un texte similaire à l'exemple suivant :
    550 5.7.1 Impossible d'effectuer le relais de nom_destinataire@ nom_domaine.tld

Test de relais 2

Ce test est presque identique au test 1, mais dans ce cas, l'expéditeur est un utilisateur local et non un utilisateur d'un domaine distant. Les adresses d'expéditeur étant généralement utilisées pour accéder sans autorisation à un système, le serveur ne doit pas relayer le message électronique. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:utilisateur_local, où utilisateur_local est un nom de message électronique local d'un compte d'utilisateur du domaine, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.0 utilisateur_local@nom_domaine.tld....Expéditeur OK
  3. Tapez RCPT TO:nom_destinataire@nom_domaine.tld

    La session telnet affiche un texte similaire à l'exemple suivant :
    550 5.7.1 Impossible d'effectuer le relais de nom_destinataire@nom_domaine.tld

Test de relais 3

Ce test concerne les adresses d'enveloppe d'expéditeur NULL ou vides. Les adresses d'enveloppe d'expéditeur des rapports de non-remise et autres notifications sont NULL. Cependant, les notifications ne doivent pas être relayées, sauf si l'adresse du destinataire appartient à un domaine local. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:<>, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.0 <>....Expéditeur OK
  3. Tapez RCPT TO:nom_destinataire@nom_domaine.tld

    La session telnet affiche un texte similaire à l'exemple suivant :
    550 5.7.1 Impossible d'effectuer le relais de nom_destinataire@nom_domaine.tld

Test de relais 4

Ce test est identique au test 2, mais le domaine local est explicitement ajouté à l'adresse électronique. Un serveur SMTP à relais fermé ne doit pas relayer ce message électronique. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:nom_utilisateur@nom_domaine.tld, où nom_domaine est le nom du domaine local, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.0 nom_utilisateur@nom_domaine.tld....Expéditeur OK
  3. Tapez RCPT TO:nom_utilisateur@nom_domaine.tld, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    550 5.7.1 Impossible d'effectuer le relais de nom_utilisateur@nom_domaine.tld

Test de relais 5

Ce test est également identique au test 2, mais l'adresse IP du serveur est utilisée à la place du nom de domaine. Bien que ce format d'adresse soit généralement accepté, le serveur ne doit pas accepter les relais vers un domaine distant. Dans plusieurs autres tests qui utilisent « localhost » ou le nom DNS (Domain Name System) du serveur dans l'adresse de l'expéditeur, le serveur ne doit pas relayer les messages électroniques utilisant cette approche. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:nom_utilisateur@10.10.10.10, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.0 nom_utilisateur@10.10.10.10....Expéditeur Ok
  3. Tapez RCPT TO:nom_utilisateur@nom_domaine.tld, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    550 5.7.1 Impossible d'effectuer le relais de nom_utilisateur@nom_domaine.tld

Test de relais 6

Ce test est spécialement destiné aux anciens serveurs UNIX qui acheminent les messages électroniques en ajoutant le domaine local et en remplaçant le signe @ par un symbole de pourcentage (%). Le serveur relaye alors le message électronique. Le symbole de pourcentage (%) étant un caractère valide dans la portion locale de l'adresse électronique, le serveur SMTP peut accepter le message, puis envoyer un rapport de non-remise si la recherche dans l'annuaire échoue. Les produits Microsoft SMTP ne sont pas vulnérables à ce type de relais parce que le message n'est pas transféré et un rapport de non-remise (NDR) est généré. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:nom_utilisateur, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    nom_utilisateur@nom_domaine.tld....Expéditeur OK
  3. Tapez RCPT TO:nom_utilisateur%nom_domaine.tld, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.1.5 nom_utilisateur%nom_domaine.tld@nom_domaine.tldnom_utilisateur@nom_domaine.tld
    Remarque Le domaine local est ajouté à celui du destinataire dans l'adresse électronique.

Test de relais 7

Ce test est une variante du test 6. Le guillemet (") étant un caractère valide dans la portion locale de l'adresse électronique, le serveur SMTP accepte le message, puis envoie un rapport de non-remise (NDR) si la recherche dans l'annuaire échoue. Les produits Microsoft SMTP ne sont pas vulnérables à ce type de relais parce que le message n'est pas transféré et un rapport de non-remise (NDR) est généré. Pour effectuer ce test, procédez comme suit :
  1. À l'invite de session Telnet, tapez RSET.

    La session telnet affiche un texte similaire à l'exemple suivant :
    250 2.0.0 Réinitialisation
  2. Tapez MAIL FROM:nom_utilisateur, puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    nom_utilisateur@nom_domaine.tld....Expéditeur OK
  3. Tapez RCPT TO:"nom_utilisateur@nom_domaine.tld", puis appuyez sur ENTRÉE.

    La session telnet affiche un texte similaire à l'exemple suivant :
    "nom_utilisateur@nom_domaine.tld"@nom_domaine.tld
    Remarque Le domaine local est ajouté à celui du destinataire dans l'adresse électronique.

Comment faire pour déterminer si votre serveur SMTP est fermé aux tests de relais 6 et 7

Lorsque vous exécutez les tests de relais 6 et 7 sur un ordinateur Exchange 2000, ils génèrent un message envoyé à un destinataire qui ne se résout pas, et des rapports de non-remise (NDR) sont reçus par la boite aux lettres spécifiée dans le Gestionnaire système Exchange. Vous pouvez configurer la boîte aux lettres pour les destinataires non résolus dans les propriétés du serveur SMTP virtuel par défaut dans la zone Transférer tous les messages dont les destinataires n'ont pas été résolus vers l'hôte dans l'onglet Messages du Gestionnaire système de Exchange.

Les rapports de non-remise (NDR) prouvent que les messages électroniques n'ont pas été relayés.

Références

Pour plus d'informations sur la façon de procéder lorsque vous exécutez Exchange Server 5.5 et que vous souhaitez configurer votre serveur de sorte qu'il ne soit pas à relais ouvert, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
196626 Restriction de routage dans le service Messagerie Internet
Pour plus d'informations sur la façon d'empêcher le relais dans Windows 2000, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
310356 COMMENT FAIRE : Empêcher le relais de messagerie dans le serveur SMTP IIS 5.0 dans Windows 2000
Il existe des tests courants que vous pouvez utiliser pour tester le relais des serveurs SMTP. Par exemple, vous pouvez utiliser les sites Web et les outils tiers suivants (en anglais) : Microsoft fournit les coordonnées de sociétés tierces afin de vous aider à trouver un support technique. Ces informations peuvent être modifiées sans préavis. Microsoft ne garantit en aucun cas l'exactitude des informations concernant les sociétés tierces.

Les produits tiers mentionnés dans le présent article proviennent de sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Propriétés

Numéro d'article: 304897 - Dernière mise à jour: mardi 23 janvier 2007 - Version: 10.1
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows XP Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professionnel
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange Server 5.5 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
Mots-clés : 
kbhowto kbwinservnetwork kbnetwork KB304897
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com