Je suis actuellement en train de préparer une prochaine migration du serveur d’une structure ayant environ (100 comptes de messagerie) et utilisant Exchange sur un Windows serveur 2008 SBS + AD.
Je suis à la recherche d’une procédure complète afin de réaliser cette migration au mieux, à savoir que la messagerie et l’agenda partagé est leur principal outil de travail.
Clients utilisés : Outlook, splanner (android)
Sur le prochain serveur : Windows serveur 2012
Plusieurs vm seront installées (dont une pour Bluemind)
J’ai déjà fait des tests sur mon serveur perso l’envoi des mails sont ok mais pas la réception, je suppose que cela est dû au fait que je n’ai pas fait de redirection de mon FAI (OVH) qui héberge mon domaine vers mon serveur.
j’ai installé et configurer Bind avec les MX de OVH.
J’utilise Centos 7 comme OS hôte.
Merci de l’intérêt que vous porterez à ma demande.
Le TLD .local n’existe pas dans l’arborescence des DNS public.
Si vous souhaitez pouvoir recevoir des mails depuis l’extérieur, il vous faut un domaine officiel, avec un TLD officiel (.fr, .en, .com…). Vous pouvez en acheter un chez n’importe quel vendeur de domaine - registar (gandi, nordnet…).
Ensuite, dans le DNS de ce domaine, il vous faut déclarer un champs de type MX qui pointe vers un nom, et ce nom doit résoudre vers l’IP publique de votre serveur BlueMind. Ceci afin de permettre aux autres de trouver le serveur mail de votre domaine.
En sortie, ça fonctionne, mais avec un tel domaine, vos mails vont très certainement être classés comme SPAM.
D accord donc c est bien ce que je pensais parcontre pour éviter d être classer comme spam j ai vu qu il y avais d autres type de déclarations autres que MX qui pouvait être utilisé mais j ai un doute la dessus c est un peu flou…
Es qu une doc à été rédiger par l équipe de bluemind sur ce sujet ?
Es que la déclaration du serveur sur le dns de l héberger du domain et sur le dns du serveur loc suffit ?
Le champs MX est nécessaire et obligatoire pour que les autres domaines sachent à quel serveur ils doivent transmettre les mails destinés à votre domaine. Par d’alternative.
Par contre, vous pouvez aussi avoir mettre en place:
[list=*] ]le SPF: chaine de caractère à générer - il y a des sites - qui indique aux destinataires si l’IP qui essaye d’envoyer un mail provenant de votre domaine est un émetteur légitime ou pas de votre domaine. Vous pouvez configurer votre serveur pour qu’il réalise ça avec les mails provenant de tiers/] ]DKIM: plus complexe à mettre en oeuvre, mais permet de s’assurer qu’un mail provient bien de votre serveur - signature dans les en-têtes/]
[/list]
Nous n’avons pas de documentation précisent à ce sujet, mais vous en trouverez beaucoup sur internet.