Probleme envoi email depuis Hosted Exchange 2016 = Remote Server returned '550 5.1.1 :

E-mails
1

Bonjour à toutes et à tous,

Notre nom de domaine est : www.stereoleap.com
Nous utilisons l'offre : Hosted Exchange 2016

Nous rencontrons la problématique suivante :

Tous les mails que nous adressons depuis notre boite messagerie@stereoleap.com à différents contacts nomducontact@vs-factory.com sont rejetés et reviennent avec une erreur :

Remote Server returned '550 5.1.1 nomducontact@vs-factory.com: Recipient address rejected: User unknown'

C'est systématique. Notre contact n'a pas de soucis avec ses autres correspondant et de notre côté non plus, c'est la première fois que nous avons ce soucis en quelques années d'utilisation.
A priori le client est sur Office 365, c'est tout ce que je sais. Nous pouvons en recevoir de sa part mais pas lui en envoyer.

Tous les sujets que j'ai consulté sur le forum pour l'instant sont soit sans solution, sans réponse, sans piste de résolution fiable, certains parfois très anciens avec une problématique similaire…
Je suis coincé et sollicite votre aide !

Les seules infos que j'ai trouvées sont de :

1. Bien vérifier que le nom de domaine "www.stereoleap.com" est en non-autoritatif, c'est bien le cas depuis le debut :

4c33e2df62dd414fad14d36b45c2c6cb50674f89.png955×162 13.1 KB


1. Passer le serveur MX à `mx1.mail.ovh.net`
par défaut c'était `mx4.mail.ovh.net` mais comme nous avons d'autres comptes mails en mutualisé, je m'y suis conformé comme le stipule l'aide en infobox sur le côté (si j'ai bien compris) :

c35cfc9f0b835b1235ca1858dbae9d37287ce0de.png692×489 60.2 KB


Merci par avance pour votre aide précieuse :slight_smile:
Bon weekend.



PS : ci-dessous le message d'erreur complet :

Informations de diagnostic pour les administrateurs :

Serveur de génération : DAG7EX2.indiv3.local

nomducontact@vs-factory.com
in72.mail.ovh.net
Remote Server returned '550 5.1.1 : Recipient address rejected: User unknown'

En-têtes de message d'origine :

Received: from DAG7EX1.indiv3.local (172.16.2.13) by DAG7EX2.indiv3.local
(172.16.2.14) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.17; Fri, 27 Jan
2023 18:24:26 +0100
Received: from DAG7EX1.indiv3.local ([fe80::2d52:4efe:9cc8:a799]) by
DAG7EX1.indiv3.local ([fe80::2d52:4efe:9cc8:a799%7]) with mapi id
15.01.2507.017; Fri, 27 Jan 2023 18:24:26 +0100
From: messagerie
To: nomducontact
Subject: Essai mail
Thread-Topic: Essai mail
Thread-Index: AQHZMnQzQqsQLhTUCUmhWU+cJ6puBA==
Date: Fri, 27 Jan 2023 17:24:24 +0000
Message-ID: <09088F8D-71C7-409D-8297-1F45D9BF9E3C@stereoleap.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [90.3.55.71]
Content-Type: multipart/alternative;
boundary="000_09088F8D71C7409D82971F45D9BF9E3Cstereoleapcom"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: DAG7EX2.indiv3.local
X-CrossPremisesHeadersFilteredByDsnGenerator: DAG7EX2.indiv3.local

2

Bonjour,


A priori le client est sur Office 365,

a priori votre client à un problème de configuration et/ou a des boites mails chez OVH.

<br /><a href="vs-factory.com." target="_blank" rel="nofollow noopener">1factory.com.factory.com.</a> 3600 IN MX 1 mx1.mail.ovh.net.<br /><a href="vs-factory.com." target="_blank" rel="nofollow noopener">1factory.com.factory.com.</a> 3600 IN MX 0 1com0e.mail.protection.outlook.com.com0e.mail.protection.outlook.com.<br /><a href="vs-factory.com." target="_blank" rel="nofollow noopener">1factory.com.factory.com.</a> 3600 IN MX 100 mx3.mail.ovh.net.<br /><a href="vs-factory.com." target="_blank" rel="nofollow noopener">1factory.com.factory.com.</a> 3600 IN MX 5 mx2.mail.ovh.net.<br />
Là vous n'allez pas pouvoir faire grand choses, c'est au détenteur de "1factory.comfactory.com" de faire le ménage dans sa configuration et surtout sur son compte OVH car si le domaine est encore inscrit dans le système mail OVH, OVH va en priorité essayé de chercher la dite boite mail sur ces propres serveur, sauf si le gestionnaire de "1factory.comfactory.com" a également activé le mode "non-autoritatif".

Cordialement, janus57

3

Merci beaucoup @janus57 pour votre réactivité.


Là vous n'allez pas pouvoir faire grand choses, c'est au détenteur de "1factory.comfactory.com" de faire le ménage dans sa configuration […]


Pas de soucis pour le guider et trouver une solution, qu'elle soit chez nous ou chez lui, car c'est très contraignant pour échanger. Je note donc avec vos explications que c'est bien de son côté qu'il faut modifier la configuration.


[…] sur son compte OVH car si le domaine est encore inscrit dans le système mail OVH, OVH va en priorité essayé de chercher la dite boite mail sur ces propres serveur, sauf si le gestionnaire de "1factory.comfactory.com" a également activé le mode "non-autoritatif"


Pouvez-vous m'expliquer cette partie svp ?
Si je comprends bien, lorsque le mail "part de chez nous" (= de notre serveur mail OVH smtp), le serveur cherche la boite @1factory.comfactory.com parmis les serveurs OVH et ne la trouve pas, d'où l'erreur ?

Que faudrait-il faire de leur côté pour résoudre le soucis ?



sauf si le gestionnaire de "1factory.comfactory.com" a également activé le mode "non-autoritatif".


Cela suffirait-il à leur serveur de mail de bien vouloir accepter nos messages entrants ?

C'est curieux à priori il n'ont pas ce soucis avec leurs autres contacts, et j'imagine facilement que d'autres doivent être aussi chez OVH…

Merci bcp par avance :wink:

4

Bonjour,


Pouvez-vous m'expliquer cette partie svp ?
Si je comprends bien, lorsque le mail "part de chez nous" (= de notre serveur mail OVH smtp), le serveur cherche la boite @1factory.comfactory.com parmis les serveurs OVH et ne la trouve pas, d'où l'erreur ?

d'après les entête (partiel ?) que vous avez posté => oui


Que faudrait-il faire de leur côté pour résoudre le soucis ?

vérifier s'il a toujours un service mail d'actif chez OVH.


et j'imagine facilement que d'autres doivent être aussi chez OVH…

ne jamais s'imaginer ce que font les autres, certains fuient le service mail de OVH comme la peste à cause du manque de support/fonctionnalités/mise en spam.

L’entreprise ou je travail, on a 70% de nos clients chez Office365, le reste soit ils ont leur serveur chez eux soit on ne gère pas leur partie mail. Les rares qui avais leur mails chez OVH ont demandé une prestation de migration vers Offiice365 (comme ce que votre client semble avoir fait au vu de sa configuration MX qui est mauvaise).

Cordialement, janus57

5

ne jamais s'imaginer ce que font les autres, certains fuient le service mail de OVH comme la peste


Ok, je trouvais juste surprenant qu’ils n’aient pas d’autres contacts avec des mails chez OVH comme nous. Mais comme vous dites, difficile d’imaginer.


Les rares qui avais leur mails chez OVH ont demandé une prestation de migration vers Offiice365


Pour ma culture perso, lorsqu’un ancien client mails OVH migre vers Office365, c’est du coup géré directement chez Microsoft ? Ou alors OVH propose une offre 365 il me semble ? Est-ce juste une licence fournie par OVH mais tout est stocké/traité en dehors ?

Merci !
6

Bonjour,


Pour ma culture perso, lorsqu’un ancien client mails OVH migre vers Office365, c’est du coup géré directement chez Microsoft ?

pour la partie mail ? => oui


Ou alors OVH propose une offre 365 il me semble ?

oui et non OVH propose des licence pour les logiciels Office (word/excel etc), tout ce qui est relié à Microsoft est théoriquement coupé.

Note : jamais utilisé la solution OVH sur cette partie.

Cordialement, janus57

7

Merci à nouveau pour les réponses !


1factory.com.factory.com. 3600 IN MX 1 mx1.mail.ovh.net.
1factory.com.factory.com. 3600 IN MX 0 1com0e.mail.protection.outlook.com.com0e.mail.protection.outlook.com.
1factory.com.factory.com. 3600 IN MX 100 mx3.mail.ovh.net.
1factory.com.factory.com. 3600 IN MX 5 mx2.mail.ovh.net.


Du coup, qu’est-ce qui cloche dans l’extrait ci-dessus ?
Que faudrait-il obtenir d’autre / de different idéalement après la mise en conformité du côté de notre client ?

8

1factory.comfactory.com


Bonjour,

Je pense qu'il y a 2 problèmes:
1) La configuration de 1factory.comfactory.com est fausse.
2) même si elle était juste, peut-être que le problème subsiste

il serait nécessaire d'avoir la totalité du message d'erreur (avant et après Remote Server returned '550 5.1.1 nomducontact@vs-factory.com: Recipient address rejected: User unknown')

Je m'explique:
1) le MX est faux:
**1factory.com.factory.com. 3600 IN MX 100 mx3.mail.ovh.net.**
1factory.com.factory.com. 3600 IN MX 0 1com0e.mail.protection.outlook.com.com0e.mail.protection.outlook.com.
**1factory.com.factory.com. 3600 IN MX 5 mx2.mail.ovh.net.**
**1factory.com.factory.com. 3600 IN MX 1 mx1.mail.ovh.net.**
SPF:
1factory.com.factory.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"

Si vs-factory est passé sur Office365, dans ce cas il ne fallait pas laisser traîner les MX de OVH.

2) Vous êtes hébergé sur le serveur ex3.mail.ovh.net.
vs-factory possède aussi un hébergement mail chez OVH, peut-être aussi sur le serveur ex3, avec au moins une adresse valable postmaster@ ...
Il est probable que votre message à destination de vs-factory ne quitte pas le serveur d'OVH (et ne respecte donc pas le MX)
- avec le message d'erreur complet, on en saurait plus.
- demandez à vs-factory de supprimer les 3 enregistrements SPF excédentaires, il pourraient perdre des mails autre que les vôtres.
- si le problème subsiste, faites un ticket à OVH en vous plaignant que les mails à ce destinataire ne doivent pas être traités en local sur ex3, mais doivent suivre le MX.
- Enfin c'est aussi la faute de vs-factory qui laisse traîner un hébergement mail inutilisé.
.
9

Que faudrait-il faire de leur côté pour résoudre le soucis ?



vérifier s'il a toujours un service mail d'actif chez OVH.


J'ai vérifié. Si je présente un mail au serveur d'OVH, en disant que le destinataire est: 1factory.comfactory.com , OVH accepte cette adresse.

Si vs-factory n'utilise plus du tout les mails chez OVH ils devraient supprimer cet hébergement mail, qui est peut-être sur le même serveur Exchange que vous (ex3 d'après votre SRV)

Le serveur Exchange semble avoir contacté le serveur in72.mail.ovh.net et celui-ci a dit : Recipient address rejected: User unknown

Exchange est peut-être assez malin de se dire que parmi les MX moins prioritaires de vs-factory, il y en a qui sont locaux à OVH , et donc Office365 n'est jamais sollicité.


Merci à nouveau pour les réponses !



janus57:
1factory.com.factory.com. 3600 IN MX 1 mx1.mail.ovh.net.
1factory.com.factory.com. 3600 IN MX 0 1com0e.mail.protection.outlook.com.com0e.mail.protection.outlook.com.
1factory.com.factory.com. 3600 IN MX 100 mx3.mail.ovh.net.
1factory.com.factory.com. 3600 IN MX 5 mx2.mail.ovh.net.

Du coup, qu’est-ce qui cloche dans l’extrait ci-dessus ?


vs-factory devrait absolument retirer les 3 MX qui ciblent OVH, c'est une erreur, et ils pourraient très bien perdre d'autres mails que les vôtres.
10

Merci beaucoup @Fritz2cat pour ton expertise, qui complète bien la réponse de @janus57.


Si vs-factory n'utilise plus du tout les mails chez OVH ils devraient supprimer cet hébergement mail, qui est peut-être sur le même serveur Exchange que vous (ex3 d'après votre SRV)


Je vais effectivement me rapprocher d'eux pour savoir s'ils utilisent encore ou non des services mails d'OVH. Si ce n'est plus le cas, suppression. Mais si, comme pour nous, d'autres comptes mails (d'autres salariés par exemple) sont encore mutualisés, me confirmez-vous qu'il faut bien qu'ils conservent les MX renseignés en "cohabitation" avec celui de Microsoft365 ?


Le serveur Exchange semble avoir contacté le serveur in72.mail.ovh.net et celui-ci a dit : Recipient address rejected: User unknown


Alors, pour le nom du serveur contacté `in72.mail.ovh.net`, c'est un peu la loterie : parfois c'est celui là, parfois d'autres dans les réponses automatiques. J'ai vu passer aussi par exemple `in48.mail.ovh.net`, `in32.mail.ovh.net`, etc. Ce n'est pas fixe, mais peut-être est-ce un fonctionnement normal ?


Exchange est peut-être assez malin de se dire que parmi les MX moins prioritaires de vs-factory, il y en a qui sont locaux à OVH , et donc Office365 n'est jamais sollicité.


C'est tout le propos du problème actuel tel qu'exposé par @janus57 précédemment, si j'ai bien compris.

A priori, les "vestiges" de serveurs MX OVH non-utilisés par vs-factory, mais toujours renseignés, captent nos mails sortant, à la place de leur système Microsoft365. Puisque les comptes utilisateurs ne sont plus actifs sur ces serveurs, les serveurs MX OVH nous renvoient les messages d'erreur avec des utilisateurs inconnus (Recipient address rejected: User unknown) et notre client ne reçoit rien.

J'ai tout bon ?


vs-factory devrait absolument retirer les 3 MX qui ciblent OVH, c'est une erreur, et ils pourraient très bien perdre d'autres mails que les vôtres.


C'est une réflexion que je partageais un peu plus haut : OVH étant quand même un acteur majeur de ce type de service en FR, vs-factory pourrait avoir les mêmes soucis avec d'autres partenaires ayant choisi comme nous OVH pour leur gestion de mail.

Je vais faire le point avec eux et vous tenir informés de la résolution de l'incident dès que possible, merci encore pour votre aide à tous les 2 ! :wink:

Une dernière chose :
Dans le cas d'un hébergement mail fantôme laissé à l'abandon, cela signifie que chez OVH il n'y a pas de système automatisé de suppression (partielle type standby ou totale) en cas d'inactivité ?
Par exemple, si pas de mails émis ou reçus en 1 an, on pourrait imaginer un système qui met en retrait automatiquement les serveurs MX de la config de l’utilisateur, avec un petit mail d'info au proprio avant ou après expliquant la raison ?

11

Bonjour,


Mais si, comme pour nous, d'autres comptes mails (d'autres salariés par exemple) sont encore mutualisés, me confirmez-vous qu'il faut bien qu'ils conservent les MX renseignés en "cohabitation" avec celui de Microsoft365 ?

non c'est faux.
Vous devez avoir un MX vers une seule entité:

* OVH si vous faites usage du mode non-autoritatif qui vous est proposé chez OVH ;
* ou M365 si vous faites usage d'un "connecteur" chez M365 pour renvoyer ce qui n'est pas hébergé chez M365.

Sachez quand même, que dans le premier cas j'ai constaté que l'expéditeur ne reçoit aucun message d'erreur si la boîte n'existe pas chez OVH ni chez le 2è partenaire dont le MX est désigné en regard du non-autoritatif.

Sachea aussi que je n'ai pas d'expérience avec m365 donc je n'ai jamais vu comment configurer ces connecteurs.

in72.mail.ovh.net, c'est un peu la loterie


C'est exact, c'est un grand pool de serveurs qui reçoivent les mails adressés à des clients OVH, toutes plateformes confindues (et pas seulement Exchange). Ces serveurs valident l'existence de l'adresse mail du destinataire et dispatchent vers la plateforme appropriée (MX, Pro, Exchange …)


Puisque les comptes utilisateurs ne sont plus actifs sur ces serveurs, les serveurs MX OVH nous renvoient les messages d'erreur avec des utilisateurs inconnus (Recipient address rejected: User unknown) et notre client ne reçoit rien.


C'est exact.
Vous avez dit:
> Serveur de génération : DAG7EX2.indiv3.local
> nomducontact@1factory.comfactory.com
> in72.mail.ovh.net
> Remote Server returned '550 5.1.1 factory.com>: Recipient address rejected: User unknown'

C'est bien un serveur OVH DAG7EX2.indiv3.local qui n'a pas pu envoyer le message car il a discuté avec un autre serveur OVH (le fameux dispatcher mentionné plus haut). Le message d'erreur "User unknown" indique qu'un hébergement mail existe pour ce domaine chez OVH. S'il n'y avait pas eu d'hébergement mail, le message d'erreur aurait été: Relaying denied.

Une dernière chose :
Dans le cas d'un hébergement mail fantôme laissé à l'abandon,


Non. Ceci n'est pas dans votre contrat, donc OVH n'a pas le droit de le faire.

avec un petit mail d'info au proprio


à qui l'envoyer puisqu'il ne lit pas ses mails ?

12

Bonjour,


me confirmez-vous qu'il faut bien qu'ils conservent les MX renseignés en "cohabitation" avec celui de Microsoft365 ?

non il faut JAMAIS conserver des MX de plusieurs fournisseurs.


OVH étant quand même un acteur majeur de ce type de service en FR

euh non, OVH a même de manière générale mauvaise réputation pour les services mails.


on pourrait imaginer un système qui met en retrait automatiquement les serveurs MX de la config de l’utilisateur, avec un petit mail d'info au proprio avant ou après expliquant la raison ?

légalement c'est touché aux données du clients, peut d'hébergeur FR s'y risquerais si un contrat (==service) est toujours actif.
Un service actif mais non utilisé reste un service utilisé sauf si le contrat indique une contrainte de temps en cas de non-utilisation.

Cordialement, janus57