none
Impossible d'envoyer des emails générés par des script avec Exchange 2016 RRS feed

  • Discussion générale

  • Bonjour,

    On a un DAG Exchange 2016, récemment migré de la version 2010. Et tout fonctionne bien. Et un serveur SMTP (installé sur Windows Server 2016) utilisé pour les applications et les systèmes embarqués et les notifications...

    Sauf que, aujourd'hui, on a essayé d'implémenter un script qui fait la vérification d'une tâche administrative, et ce script est supposé envoyer le résultat de son travail par email.

    Ce script donne le résultat suivant:

    Exception lors de l'appel de « Send » avec « 1 » argument(s) : « Boîte aux lettres non disponible. La réponse du serveu
    r était : 5.7.1 Unable to relay xxxxx@xxx<com»
    Au niveau de C:\folder\PS\task.ps1 : 56 Caractère : 11
    + $smtp.Send <<<< ($message)
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : DotNetMethodException

    Alors que mon adresse est bien correcte

    Je voudrais savoir ce qu'on doit faire pour corriger ce probleme?

    Cordialement,


    jeudi 30 juillet 2020 13:16

Toutes les réponses

  • Bonjour Lotfi B,

    'Unable to Relay' peut indiquer plusieurs choses, inclus une corruption de la base de données Exchange. Pouvez-vous verifier les erreurs dans le journal des événements de l’application? Utilisez-vous par hazard un connecteur de connexion anonyme?

    Je vous conseille de publier votre question dans le forum anglais/américain puisque ils ont une rubrique dédiée au scripting - https://social.technet.microsoft.com/Forums/scriptcenter/en-US/home?category=scripting.

    Je vous remercie par avance pour votre retour.

    Cordialement,

    Biliana



    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    vendredi 31 juillet 2020 11:03
  • Pourquoi tes applications n'envoie pas en direct via ton serveur Exchange.

    Le relais SMTP doit être autorisé pour fonctionner. Problème de sécurité oblige.

    vendredi 31 juillet 2020 13:22
  • @Vincent:

    Pour des raisons des sécurité, on ne fait jamais le relai directement vers les serveurs Exchange, sauf le traffic Outlook/OWA

    Pour l'autorisation du serveur SMTP, il l'est dans un des Connecteurs de réception.

    @Biliana:

    Svp, comment puis-je savoir si la base de données contient des erreurs dans ses fichiers logs??

    Cordialement,

    vendredi 31 juillet 2020 20:51
  • Bonsoir,

    ce type d'erreur survient lorsque l'expéditeur n'est pas connu/authentifié au moment du dépot du message, et que le destinataire n'est pas une boite dans l'annuaire Exchange.

    => C'est ce que l'on appelle un relais "ouvert" qui peut potentiellement envoyer de n'importe qui à n'importe qui.

    Généralement, on crée un connecteur de réception spécifique sur Exchange, qui n'autorise cela QUE pour l'adresse IP du serveur SMTP Windows. Idéalement, la connexion est authentifiée entre ce serveur et Exchange. Le connecteur de réception doit être configuré pour accepter "AnySender" et "AnyRecipient" (ce qui équivaut à un relais ouvert).

    =>  Sur le serveur SMTP Windows, on n'autorisera QUE les adresses IP des serveurs autorisés à déposer des messages.

    De la même manière, si l'on veut éviter tout risque de problème de relais refusé, chaque application/serveur se connectera de manière authentifiée, avec une adresse de messagerie d'expéditeur CONNUE dans l'annuaire Exchange.

    A noter que cette configuration complexe est nécessaire uniquement pour les messages sortant vers Internet, les messages destinés à des boites Exchange n'ont aucun besoin de ce type de configuration.

    A part le fait de centraliser et simplifier la configuration, l'utilisation d'un serveur Windows SMTP intermédiaire n'améliore pas vraiment la sécurité, sauf à installer un outil de scan des messages. En revanche, cela peut permettre de soulager Exchange lors d'envoi en masse de message, surtout si l'on peut éviter de passer par Exchange.

    A bientôt,


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    vendredi 31 juillet 2020 21:56
    Modérateur
  • Bonjour Lofti B,

    tout serveur SMTP (MX) bien configuré comme tu l'as dit, ne doit jamais - non jamais - être open relay. C'es tune faille de sécurité majeure.

    Dans ces conditions, quand on (un script) doit envoyer un mail au MX, que ce soit vers des utilisateurs internes ou externes, peu importe, le dit script doit utiliser des crédentials d'un compte autorisé pour ce faire.

    Le compte qui exécute le script doit

    1. disposer d'une boite mailpour envoyer le mail de report
    2. avoir suffisamment de privilèges pour faire ce que doit faire le script.
    3. Et éventuellement, avoir suffisamment de privilèges pour faire touner une tâche planifiée (si tu envisages de planifier l'exécution du script).

    Local System ? Répond au point 3, mais pas au 1 et probablement pas au 2.

    Un simple compte de domaine, avec une BAL donc, répond au point 1, mais il doit avoir encore suffisamment de privilèges pour répondre aux point 2 et 3. Un compte spécifiquement défini pour jouer ce rôle (c'est à dire : Domain User, + membre groupes AD necessaires pour jouer ce que doit faire le script), ce compte dans une OU sépcifique sur laquelle s'applique une GPO définissant "Password never expires, Don't logon interactively, act as a service" et tu auras un compte qui le fait.

    Ca pourrait le faire avec un compte d'administration - pour peu qu'il ai une BAL - mais à chaque changement de mot de passe, ta tâche planifiée va tomber. On ne fait jamais tounrer une tâche planifier avec un compte d'administration mais avec un compte dédié pour ça. 

    Si cela se trouve, tu as déjà un compte spécifique pour faire tourner les tâches planfiées. Vérifies alors que ce compte a bien une BAL, et qu'il a bien le sprivilèges nécessaires pour faire ce que ton script doit faire.

    cordialement

    Olivier

    samedi 1 août 2020 17:58
  • Bonjour Lotfi B,

    Regardez dans Event Viewer quelles sont les erreurs d’exchange afin de pouvoir les analyser.

    Vous trouverez un example comment accéder aux erreurs d’xchange ici .

    Je vous remercie par avance pour votre retour.

    Cordialement,

    Biliana


    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    lundi 3 août 2020 09:12