Meilleur auteur de réponses
EXCHANGE 2013 - Réception de mails aléatoire

Question
-
Bonjour à tous,
J'ai récemment refais à neuf l'infrastructure de notre petite SSII, profitant de cette occasion pour installer Exchange 2013 Standard.
Nos serveurs sont virtualisés avec Hyper-V sur du Windows Server 2012 R2 Standard (même OS pour Exchange). Un reverse proxy sous Debian est en place pour rediriger notamment le port 443 selon le sous domaine.
Nous possédons un domaine en ".fr" hébergé chez Online. La zone DNS de ce dernier dispose de trois enregistrements MX :
- exchange.domaine.fr - Priorité 10
- mx.online.net - Priorité 20
- mx-cache.online.net - Priorité 30
Evidemment, un type A pour exchange.domaine.fr pointant vers notre IP publique.
D'autre part, nous avons une redirection de mail "catch-all" permettant de recevoir les mails de tous les comptes non existants.
C'est donc grâce à cette adresse mail "catch-all" que nous nous sommes aperçus du problème !
Effectivement, nous avons découverts plusieurs dizaines de mails de nos clients ou autres que nous n'avons pas reçus dans nos boîtes mails respectives...
Du coup, je me tourne vers des outils de diagnostic, notamment mxtoolbox. Et là, pas mal de warnings !
Un reverse DNS qui ne correspond pas, je l'ai donc modifié chez mon FAI. Un problème de SMTP Banner résolu en ligne de commande en appliquant le bon reverse DNS sur le connecteur de réception par défaut. Un temps de transaction dépassant les 8 secondes, résolu en modifiant le "tarpit interval" à 0. Un souci de TXT Record : ajout d'un enregistrement de valeur "v=spf1 a mx ~all".
Après toutes ces modifications, la session transcript retourne :
Transcript: Connecting to xxx.xxx.xxx.xxx 220 exchange.domaine.fr Microsoft ESMTP MAIL Service ready [733 ms] EHLO MXTB-PWS3.mxtoolbox.com 250-Exchange.domaine.local Hello [xxx.xxx.xxx.xxx] 250-SIZE 2146435072 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-X-ANONYMOUSTLS 250-AUTH NTLM 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250 XRDST [764 ms] MAIL FROM: <supertool@mxtoolbox.com> 250 2.1.0 Sender OK [764 ms] RCPT TO: <test@example.com> 550 5.7.1 Unable to relay [764 ms] MXTB-PWS3v2 4961ms
Donc à priori cela fonctionne. Reste deux warnings "Does not support TLS." des deux MX d'Online et un autre pour "A Valid SPF Record was not found".
D'autre part, j'ai également désinstallé l'antispam Exchange que j'avais mis en place au préalable et effectué la mise à jour cumulative 3.
J'utilise alors le "Remote Connectivity Analizer" Microsoft pour tester ma configuration et aucun problème n'en retourne.
Super ! Hélas, joie de courte durée. Le lendemain, après un check de la messagerie catch-all, de nouveaux mails sont présents...
Après les quelques heures passées à fouiller le fin fond de Google, je me suis résigné à appeler la hotline Microsoft qui m'a renvoyé bouler car le problème concerne notre infrastructure et non celle de nos clients...
Je me tourne donc vers le Social Technet qui m'a souvent apporté de bonnes pistes pour la résolution des problèmes.
Je vous remercie par avance pour votre aide.
- Modifié Antoine.R lundi 5 mai 2014 09:10 Finalement non résolu
Réponses
Toutes les réponses
-
Je pense qu'il faudrait expliciter ce que sont les deux autres MX
Si je comprend bien le premier MX pointe sur votre Exchange, par contre les deux autres MX pointent vers votre hébergeur, qui fournis un service de messagerie et de catch-all? Un serveur va tenter de se connecter au MX le plus faible, si il n'y arrive pas, il essaye le MX suivant, etc.
Dans votre cas, si exchange.domaine.fr n'est plus joignable, les emails sont envoyés sur mx.online.net, puis mx-cache.online.net. Par contre, existe-t-il sur online.net une redirection vers votre infrastructure, ou seulement une adresse catch-all ?
Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr
-
Effectivement, Online fournit un service de messagerie que nous n'utilisons plus sauf pour le catch-all.
Ce que l'on souhaite, c'est utiliser notre messagerie Exchange par défaut (d'où la priorité 10 de notre MX) et en cas de panne réseau ou autre, que nos mails tombent dans la messagerie catch-all.
Alors, est-ce qu'il y a besoin des MX d'Online pour cela ? Je pourrais peut-être me rapprocher d'eux pour en savoir plus...
En tout état de cause, avec une configuration telle quelle, les mails doivent passer par le MX d'Exchange, non ?
-
-
-
Bonjour,
Nous avons reçu encore des dizaines de mails cette nuit.
Est-ce la réception d'un grand nombre de mails d'un coup pourrait engendrer ce problème ?
Est-il est possible qu'une personne m'aide à vérifier ma configuration Exchange 2013. Il est vrai qu'il y a quelques changements par rapport à la version 2010, notamment les 5 connecteurs de réception.
Je vous en remercie grandement d'avance.
-
Nous avons opté pour la suppression des enregistrements MX de Online et donc l'arrêt de l'utilisation du service catch-all.
Il semblerait qu'il existe un cache qui garde en mémoire le dernier MX valide.
Cette discussion peut en intéresser d'autres :
http://community.spiceworks.com/topic/374700-incoming-email-not-using-priority-mx-record
-
Finalement, nous nous sommes réjouis trop vite...
Nous nous sommes aperçus que certains mails n'arrivaient toujours pas après la suppression des MX d'Online. J'en ai donc remis un, et là, de nombreux mails sont tombés dans la boîte catch-all...
Une vraie prise de tête cet Exchange...
Des avis ?
-
Vous avez un problème dans votre infrastructure dans la réception des emails. Cela peut venir d'Exchange, du réseaux, d'un autre composant.
Vous pouvez utiliser un service de monitoring en ligne pour vérifier par exemple que votre service SMTP est disponible sur Internet d'une part, d'autre part si il ne l'est pas, les serveurs distants sont sensés conserver les emails et renter à intervalle régulier la remise des emails pendant plusieurs jours.
Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr
-
Nous avons effectivement un outil de monitoring en ligne et nous avons disposé un capteur sur le TCP 25. Aucun problème n'a été détecté (si ce n'est à la suite d'un redémarrage d'Exchange).
Est-il possible que le problème provienne du serveur de messagerie des émetteurs suite à une interruption prolongée de notre Exchange ? Car nous avons constaté qu'une majorité des mails non reçus émanent d'un même domaine...
Peut-il y avoir un cache qui associe le MX d'Online comme dernier enregistrement MX valide ? -
Bonjour,
Après un contact avec l'hébergeur mail de nos clients, nous avons trouvé une piste sur la cause de nos problèmes.
Lorsque nous effectuons un traceroute vers notre serveur de messagerie, nous recevons à chaque fois un timeout après un routeur de notre FAI.
Affaire à suivre. -