oracle7

@Jeff777 C'est vrai que c'est une piste intéressante pour ceux qui ont plusieurs NAS et/ou qui disposent de RPI à d'autres fins. Maintenant, mon soucis lorsque j'ai proposé cette procédure, était (et est toujours) que le maximum d'utilisateurs, entends par là parmi les utilisateurs qui n'ont qu'un seul NAS à leur disposition, puissent générer et renouveler ensuite leur certificat de façon totalement transparente. On n'est plus très loin du but d'après @bruno78 , perso je préfère le laisser terminer tranquillement ses tests. Cordialement oracle7😉

@Jeff777 Eh bien tant mieux ! En principe un certificat est indépendant du NAS vu qu'il concerne ton domaine, donc je ne vois pas pourquoi on ne pourrait pas le déployer sur plusieurs NAS. Je le fais déjà pour mon routeur. Cordialement oracle7😉

@TuringFan Bonjour, Parfait, je suis bien content que tu ais pu faire cette génération. Ces déclarations de variables d'environnement sont normalement à faire si on ne souhaite pas suivre les valeurs par défaut utilisées par ACME. Typiquement par défaut ACME utilise HTTP et port 5000 mais on pourrait très bien passer par HTTPS et port 5001. Le code interne de ACME prévoit cette possibilité. Cela dit, j'avoue ne pas l'avoir testée, mais ce qui est tout de même étonnant, vu ce que tu dis, c'est que cela ne marche pas. Peut-être un bug du code ? Pour SYNO_Hostename, j'ai repris cela depuis un tuto "US". Ils n'en disaient pas beaucoup plus sur l'usage exact mais j'ai cru comprendre que c'est pour désigner une autre machine sur laquelle on peut faire la génération. J'espère ne pas avoir mal interprété ! Dans notre cas et pour faire "simple", il vaut mieux rester sur la valeur par défaut "localhost". Au moins c'est sûr cela marche avec cette valeur. Cordialement oracle7😉

@vincentbls et @TuringFan Pour le coup, c'est une excellente information. Merci du tuyau. Comme quoi certains problèmes ne tiennent à pas grand chose. Il faut juste les voir ... Cordialement oracle7😉

@vincentbls Tu fais bien de préciser. Forcément que dans ce cas tu ne vois aucune différence, mais le jour où tu auras plusieurs certificats comme moi, ce ne sera plus du tout la même musique ... Ton nouveau certificat ne sera pas affecté (même après renouvellement) et tu auras des alertes de sécurité ... Pourquoi crois-tu que l'on soit plusieurs à plancher sur le problème ? Cordialement oracle7😉

@vincentbls Sauf que ce n'est pas suffisant ! Tu es quand même obligé de configurer manuellement les différents services qui utilisent ton nouveau certificat. Bien le retrouver est une chose mais je te renvoie à mon argumentaire ci-dessus. Cordialement oracle7😉 @bruno78 Nos réponses se sont croisées ... Par ailleurs, c'est une bonne nouvelle que tu nous annonces là ! 😀 Prends le temps qu'il te faut pour bien tester ... Cordialement oracle7😉

@vincentbls Bonjour, Effectivement, passer par un conteneur docker est une autre façon d'utiliser ACME. Pourquoi pas mais n'oublies pas que jouer avec "docker" n'est pas abordable à tout le monde ... Cela dit, et je ne voudrais pas passer pour un rabat joie, mais au final tu en es au même point que nous. Avec ta procédure qui reste la procédure "standard" d'utilisation d'ACME (même en passant par docker), tu es quand même obligé d'avoir une action manuelle. Pour le cas : trouver le bon répertoire "Ramdom PATH" afin d'assurer le déploiement du certificat. Ce que l'on recherche avec @bruno78 c'est une automatisation TOTALE du processus création, renouvellement et de déploiement du certificat LE. PS : Attention tu as 2 fois l'instruction "--dns dns_ovh" dans ta commande ! Cordialement oracle7😉

Bonjour, Je viens par curiosité, de contrôler mon non de domaine sur le site "zonemaster.net" et à ma grande surprise je constate des anomalies liées à DNSSEC (il ya d'autres warning mais qui semblent liés à ces anomalies) : Même si cela ne semblait pas me gêner jusqu'à présent, est-ce grave docteur ? Est-ce que par hasard cela pourrait influer sur la réception de MAIL avec mon serveur de messagerie ? Quelqu'un sait-il comment je peux résoudre cela ? Merci de vos réponses Cordialement oracle7😉

Bonjour, Objectif de ce tutoriel : Pouvoir gérer de façon centralisée votre propre messagerie électronique sur votre NAS Synology lorsque vous disposez d’une adresse IP externe dite « dynamique » chez un Fournisseur d’Accès Internet (FAI) tel que ORANGE. L’idée est donc de vous permettre de créer votre propre messagerie électronique sur la base de votre propre domaine « votredomaine.tld » afin que vous puissiez recevoir et envoyer des eMAILs vers tous les fournisseurs tels que GMAIL et autres sans que ces eMAILs ne puissent être déclarés comme du SPAM (courrier indésirable non sollicité). En clair être autonome de ce point de vue ! Pour cela (et surtout pour faire simple) nous allons utiliser un outil à notre disposition sur nos NAS Synology qui n’est autre que le package Synology « MailPus Server » (« MPS »). Avec ce package notre NAS devient alors un système de messagerie prenant en charge les protocoles « SMTP », « POP3 » et « IMAP ». Les comptes d'utilisateurs et les eMails y sont également gérés et archivés de manière centralisée ce qui répond déjà à une partie de l’objectif fixé. En outre, associé à ce serveur, le package « MailPlus » va fournir aux utilisateurs du NAS, un client de messagerie basé sur un navigateur facile à utiliser pour afficher, gérer et envoyer leurs messages. Alors pourquoi s’en priver ? Autant aussi être d’entrée très clair, vous constaterez que ce tutoriel présente beaucoup de similitudes avec l’excellent tutoriel « [TUTO] Serveur MailPlus DSM6 » proposé par @unPixel sur le présent forum. Ceci est normal : on va utiliser le même outil logiciel (à la version près, celle décrite ici est la dernière à la date de rédaction du présent tutoriel), c’est juste que le tutoriel de @unPixel ne s’adresse qu’aux « chanceux » possesseurs d’une @IP externe fixe, cette condition est expressément explicitée dès le début de celui-ci. En conséquence et théoriquement, ce tutoriel ne s’avère pas applicable aux possesseurs d’une @IP externe dite « dynamique ». Mais, et bien heureusement il y a un « MAIS », on peut contourner le problème de l’@IP externe fixe et ainsi s’en affranchir, pour disposer au final d’un serveur de messagerie bien opérationnel tout en utilisant une @IP dynamique. Il faut donc voir le présent tutoriel comme un complément qui répond à un autre besoin. Chacun, toujours selon son besoin, s’adaptera et suivra l’un ou l’autre de ces tutoriels. Oh, j’entends déjà d’ici des voix qui vont dire que le serveur de messagerie ainsi configuré, va tout au plus « marchoter » et que sans @IP fixe il n’y a point de salut viable. Eh bien, la configuration décrite ci-après devrait en prouver le contraire. Cela étant, il convient cependant en préalable, de garder en mémoire quelques points : Tous les NAS Synology ne sont pas compatibles avec le package « MPS ». Je vous invite donc avant toute chose, à contrôler que votre NAS figure bien dans la liste de compatibilité établie par Synology. Faute de quoi et j’en suis désolé pour vous, ce présent tutoriel ne sera pas applicable. Le package « MPS » ne fournit GRATUITEMENT en standard, la possibilité de créer que 5 @MAIL pour nos propres besoins. Il est vrai que c’est peu mais c’est déjà cela en termes de gratuit. Cependant, si vous souhaitez acquérir des @MAIL supplémentaires pour vos propres besoins, sachez que c’est possible mais que ces licences Synology ne sont disponibles que par lot de 5 ou lot de 20, à un prix que personnellement, je trouve prohibitif pour un particulier du moins. Si vous êtes un « Pro », c’est un autre débat ... En tous cas, voyez et jugez vous-même par exemple ICI (à la date de la présente rédaction) pour un simple lot de 5 licences (je vous laisse découvrir vous-même le coût de 20 licences !). Maintenant pour être complet, vous pouvez aussi vous rabattre sur l’ancienne version du package Synology « MailServer » qui est à ce jour encore disponible et opérationnelle et qui elle, certes, ne limite pas le nombre d’@MAIL créables. Cependant ses fonctionnalités sont bien moindres que celles de l’actuel « MPS ». Ceci dit, cet ancien package peut aussi très bien suffire à certains. À vous de voir selon vos besoins … En toute rigueur dans le processus de configuration de votre serveur de messagerie, il faudrait pouvoir paramétrer le « rDNS » d’Orange. Entendez par là, le « reverse DNS », c’est-à-dire la possibilité d’obtenir le nom de domaine correspondant à une @IP, ce que font automatiquement les serveurs d’Orange (mais aussi les autres FAI) pour vérifier que l'eMAIL émis, provient bien de l’enregistrement « MX » associé à ce domaine auquel cas l’eMAIL est rejeté. Or, cette inscription ne peut normalement se faire que chez le propriétaire de l’@IP externe en l’occurrence ici : Orange. Mais voilà, là c’est impossible chez eux (a priori, et à ma connaissance il semblerait que seul Free le permette). Bon, heureusement il semble qu’à l’usage ce ne soit finalement pas un problème bloquant dans notre affaire comme on le verra plus loin (au § 7 ci-dessous) lors du test « mail-tester.com ». Il faut juste le savoir. Il est également nécessaire que le port 25, qui est un port de communication entre serveurs MAIL, ne soit pas bloqué ni en entrée, ni en sortie. En fait chez Orange, il n’est pas bloqué comme on pourrait le croire et comme le croient certains, mais c’est juste qu’un serveur SMTP Orange ignore les connexions provenant d'un autre réseau si elles lui arrivent sur le port 25. Sachez que ce comportement est devenu le standard et tous les opérateurs appliquent ce type de restriction. Pour mémoire, Il semblerait que Free bloque aussi par défaut le port 25 mais au moins chez eux il serait possible toutefois, de débloquer cette fonction via l’interface de leur box. Donc au final, pour contourner ce « blocage » du port 25, il suffit et il est même impératif de passer par le serveur SMTP du FAI pour émettre des eMAILs et si on ne veut pas se les faire rejeter. Par conséquent et c’est là toute l’astuce que l’on va mettre en œuvre dans la configuration décrite ci-après, on va utiliser : · un serveur SMTP d’Orange (ce qu’on appellera par la suite un relais SMTP) où l’on a un compte, · via le protocole SSL avec le port 465 ou via le protocole TLS avec le port 587 qui servira pour la communication du client vers le serveur (c’est cette dernière solution que nous exploiterons ici), · et avec une authentification par mot de passe. C’est la condition sine qua non au bon fonctionnement de votre serveur de messagerie. De façon pratique, si vous faites des Copier/Coller de paramètres, d’instructions de commandes, etc … à partir du présent tutoriel, je vous invite expressément à passer par l’intermédiaire d’un fichier « .txt » afin de bien visualiser le contenu exact de la chaîne de caractères copiée. Cette disposition vous évitera notamment lors du « Copier » de prendre de façon aveugle des caractères parasites qui viendront immanquablement ensuite perturber les systèmes mis en œuvre dans leur analyse de ces paramètres et/ou commandes avec tous leurs cortèges de messages d’erreurs associés. Voilà, vous êtes prévenus … Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ... D’ores et déjà, je tiens aussi à remercier ici, @Thierry94 et @PiwiLAbruti qui, au cours de multiples échanges (que vous pourrez retrouver sur le présent forum), m’ont fourni de la matière pour alimenter et compléter un certain nombre d’explications que vous trouverez dans ce tutoriel. Ils se reconnaitront dans certains couplets que j’ai repris quasiment tels quels. Sinon pour une grande partie, toutes ces explications sont issues de synthèses de mes lectures sur la toile. Les « initiés » ne manqueront pas de corriger mes éventuels défauts d’interprétations. Voilà pour le discours préliminaire, on passe aux choses sérieuses … Prérequis : Vous devez disposer de : Un NAS Synology compatible et surtout sécurisé (voir le Tutoriel « [TUTO] Sécuriser les accès à son nas » de @Fenrir). Un nom de domaine personnalisé (« votredomaine.tld »). Un accès à la « zone DNS » de votre domaine chez votre fournisseur de domaine (pour l’exemple ici ce sera mon fournisseur : OVH). Un serveur DNS installé et configuré pour gérer votre domaine sur votre NAS ou sur votre Routeur Synology (voir le Tutoriel « [TUTO] DNS Server » de @Fenrir). Une @IP externe dynamique sur laquelle « pointe » un nom d’hôte qui n’est autre que « votredomaine.tld » et configurée sur votre NAS pour être prise en charge par un DDNS (pour l’exemple ici ce sera le DynDNS d’OVH). Optionnel mais recommandé : un reverse proxy configuré sur votre NAS (voir le Tutoriel « [TUTO] Reverse proxy » de @Kawamashi). Nota : Juste pour attirer votre attention sur le fait que par abus de langage en parlant d’@IP externe chez Orange, on réduit trop souvent à l’utilisation du qualificatif « dynamique ». En fait et en pratique (source Orange), en fonction du modèle de votre Livebox (Livebox 2, Livebox Play, Livebox 4) et de votre connexion (ADSL, VDSL2, Fibre), vous bénéficiez soit d’une @IP dite « dynamique », soit d'une @IP dite « préférentielle » telles que : Fibre et VDSL : IPv4 préférentielle, IPv6 dynamique, ADSL : IPv4 préférentielle ou dynamique selon éligibilité, Ipv6 dynamique selon éligibilité, LiveBox2 : IPv4 dynamique et uniquement en ADSL. Les différences entre les « @IP dynamiques » et les « @IP préférentielles » sont celles-ci : Les « @IP dynamiques » : elles sont modifiées périodiquement par Orange ou en cas de reconnexion de la Livebox. Les « @IP préférentielles » : elles sont stables dans la durée et ne changent qu'en cas de déconnexion de la Livebox supérieure à 7 jours. Toutefois, pour des raisons techniques, Orange peut procéder au renouvellement de votre adresse IPv4 si cela est nécessaire. Dans ce cas, ce renouvellement est activé lors de la prochaine connexion de la Livebox au réseau. L’« @IP préférentielle » quant à elle ne concerne que les adresses de type IPv4. C’est pour cela que l’on peut considérer/assimiler une « @IP préférentielle » à une « @IP fixe » compte tenu de son caractère stable dans le temps même si au final ce n’est pas complétement vrai je vous l’accorde. À titre d’exemple qui vaut ce qu’il vaut, j’ai une LiveBox4 en fibre et mon @IP externe n’a pas changé depuis bientôt 6 mois. Pourvu que cela dure … 1 Ajout des enregistrements DNS internes sur le NAS Peu importe que votre serveur DNS soit installé sur votre Routeur Synology ou sur votre NAS Synology, c’est la même application « DNS Server » que l’on va utiliser. Il est bien entendu que votre serveur DNS est déjà configuré sur votre NAS ou votre Routeur pour gérer votre domaine comme indiqué en prérequis. Rendez-vous sur l’application « DNS Server » et ouvrez-la à partir du bureau de DSM ou de SRM selon. On va créer deux (2) nouveaux enregistrements dans la zone master correspondante de votre domaine : - Un de type « A » afin de rediriger le client mail vers votre NAS. - Un de type « MX » pour que votre NAS puisse communiquer avec le serveur MAIL. Nota : Pour l’exemple et dans toute la suite du présent tutoriel : - l’@IP du NAS sera notée « 1.2.3.4 ». Bien évidemment il vous faudra remplacer cette valeur d’@IP par l’@IP locale « réelle » de votre NAS. - l’@IP externe de votre Box/Routeur sera notée « 10.20.30.40 » et de la même façon il vous faudra remplacer cette valeur d’@IP par l’@IP externe « réelle » de votre Box/Routeur. Pour cela : Dans le menu « Zones » sélectionnez la zone correspondante à votre domaine. 2xCliquez sur cette zone master OU dans le popup « Modifier » sélectionnez l’item « Enregistrement de ressources » Une fenêtre « Modifier un enregistrement de ressource » s’ouvre. Dans le popup « Créer » sélectionnez l’item « A Type » Saisissez ensuite tel que ci-après : Validez en cliquant sur « OK » Dans le popup « Créer » sélectionnez l’item « MX Type » Saisissez ensuite tel que ci-après : Validez en cliquant sur « OK » Dans la fenêtre « Modifier un enregistrement de ressource » vous devriez obtenir quelque chose comme ci-après : votredomaine.tld MX 3600 10 mail.votredomaine.tld mail.votredomaine.tld A 3600 1.2.3.4 Cliquez sur « Terminer » pour valider, vous pouvez ensuite quitter l’application « DNS Server » on en a fini avec elle. 2 Installation du package MailPlus Server et du client MailPlus 2.1 Installation de « MailPlus Server » Via le centre de paquets sur votre NAS Synology, on va maintenant installer le package « MPS ». Ne soyez pas surpris, en lançant l’installation de ce package, celle-ci nécessite l’installation concomitante de dépendances nécessaires au fonctionnement de « MPS » par le biais de deux autres packages qui sont respectivement : « Perl » et « Python Module ». Un message qu’il vous faudra valider vous en informe : ⚠ Il est possible à la fin de l’installation des trois paquets (durée 2 à 3 minutes), que vous receviez un message d’erreur signalant que l’installation a échoué et vous demandant de vous reconnecter à DSM. Ignorez ce message car en fait tout s’est bien passé. Il s’agit d’un bug lié au lancement automatique de « MPS » et de toute façon quittez DSM et reconnectez-vous. Donc après la phase d’installation vous devriez avoir ceci dans le centre de paquets : 2.2 Installation du client « MailPlus » Via le centre de paquets sur votre NAS Synology, on va maintenant installer le package « MailPlus ». Ne soyez pas surpris, en lançant l’installation de ce package, celle-ci nécessite l’installation concomitante de dépendances nécessaires au fonctionnement du client « MailPlus » par le biais de trois autres packages qui sont respectivement : « Node.js v8 », « Node.js v12 » et « Service d’application Synology ». Un message qu’il vous faudra valider vous en informe : 3 Pré configuration de MailPlus Server Donc suite à cette installation, on va maintenant effectuer un minimum de configuration/paramètrage de « MPS » afin de disposer des éléments nécessaires pour configurer plus loin aux § 4.2.3, § 4.2.4 et § 4.2.5 ci-dessous, la « zone DNS » de votre domaine chez OVH. Rassurez-vous on reviendra après cela pour finaliser la configuration et sécuriser le présent serveur de messagerie. Rendez-vous sur l’application « MPS » et ouvrez-la à partir du bureau de DSM (ou du centre de paquets). L’assistant de configuration de « MPS » propose de créer un nouveau système de messagerie. Validez en cliquant sur « Suivant ». Il vous faut alors saisir : Nom de domaine : « votredomaine.tld » Nom d’hôte (FQDN) : « votredomaine.tld » (FQDN : « Fully Qualified Domain Name » ou nom de domaine pleinement qualifié, est un nom de domaine qui donne la position exacte de son nœud dans l'arborescence DNS en indiquant tous les domaines de niveaux supérieurs). Validez en cliquant sur « Suivant ». L’assistant présente alors un résumé de la mise en place de votre domaine : Validez en cliquant sur « Appliquer ». L’assistant applique les différents paramètres : Validez en cliquant sur « Terminer ». Maintenant, on va générer une clé publique liée à votre domaine personnalisé qui va être utilisée plus loin (voir § 4.2.4 ci-dessous) lors de la configuration de la « zone DNS » de votre domaine chez OVH. Mais avant de générer cette clé, il est nécessaire de fixer la longueur de cette clé (à l’instar d’une clé de chiffrement de type RSA). Pour cela : Dans la section « SECURITE » sélectionnez l’onglet « Authentification ». Dans la fenêtre qui s’affiche alors : Nota : Bien que les définitions succinctes des trois notions citées ci-après soient données dans cette fenêtre, ces notions seront présentées plus en détail plus loin au §4.2 ci-dessous lors de la configuration de la « zone DNS » de votre domaine chez OVH. Cochez respectivement les cases qui vont permettre l’activation des processus de vérification « SPF » et « DKIM » et l’activation du processus « DMARC ». Sous SPF, laissez décochée la case « Rejeter les pannes souples SPF ». Dans la partie « DKIM », sélectionnez dans le popup la valeur « 2048 » pour fixer la longueur de votre clé publique. Validez en cliquant sur « Appliquer ». Dans la section « DOMAINE » sélectionnez la ligne correspondante de votre domaine : Cliquez sur le bouton « Modifier » OU 2xCliquez sur cette ligne. Le détail de votre domaine s’affiche : Profitez-en pour renseigner au passage la description de votre domaine, par exemple : « Messagerie associée à votredomaine.tld ». Au moins ce sera toujours cela de fait … 😀 Cliquez ensuite sur le bouton « Avancé ». Dans la fenêtre qui s’affiche alors : Cochez la case « DKIM » Saisissez pour « Préfixe du sélecteur DKIM » un terme quelconque composé de caractères et éventuellement de chiffres. Il est d’usage d’en limiter le nombre de caractères (entre 5 et 8 c’est bien). Mais dans tous les cas veillez à NE PAS utiliser de majuscules, ni de caractères « spéciaux » ou « exotiques » ; ceci afin de ne pas perturber les serveurs qui analyseront ce préfixe. Nota : Pour votre présente information mais on reverra cela plus loin dans la suite de ce tutoriel : Le sélecteur DKIM est spécifié dans l'en-tête de l’eMAIL contenant la signature DKIM. Il indique où la partie de la clé publique de la paire de clés DKIM se trouve dans le DNS. Le serveur de réception utilise quant à lui le sélecteur DKIM pour localiser et récupérer la clé publique afin de vérifier que le message électronique est authentique et n’a pas été altéré. Cliquez ensuite sur le bouton « Générer la clé publique ». Le message suivant s’affichera alors : Comme on a déjà précédemment fixé cette longueur de clé « DKIM », il est inutile de le refaire donc ignorez ce message et validez en cliquant sur « Oui ». Copiez et sauvegardez précieusement cette clé dans un fichier « .txt » sur votre PC/Mac. On va s’en resservir plus loin dans le présent tutoriel. À discuter mais je ne recommande pas d’activer la fonction « Catch-all ». En effet, avec cette fonction il vous est possible de recevoir des eMAILs ayant pour origine un utilisateur inconnu et surtout qui n’existe pas. Donc avec cette option activée c'est quelque part la porte ouverte aux usurpateurs. Il suffit ensuite d'une seconde d'inattention et un clic malheureux dans un eMail de ce genre pour se retrouver dans la panade. Voilà ce n’est que mon interprétation de cette fonction, elle vaut ce qu’elle vaut. Maintenant c’est vous qui voyez … Validez en cliquant sur « OK ». 4 Configuration de la zone DNS chez OVH Maintenant que l’on a tous les éléments nécessaires on peut procéder à la configuration de la zone DNS associée à votre domaine chez OVH. Pour cela : Connectez-vous à OVH avec votre identifiant principal et votre mot de passe. Rendez-vous sur le tableau de bord de votre domaine : menu « Web » / section « Domaines » / « votredomaine.tld ». 4.1 Optionnel : création d'une @MAIL de secours chez OVH Mais avant de configurer la zone DNS, il convient de régler un point qui reste toutefois tout à fait optionnel pour vous. Libre à vous de le suivre ou pas. En effet, si vous avez souscrit une offre « gold » (appelée aussi « Start10M ») lors de l'initialisation de votre abonnement pour un nom de domaine chez OVH, sachez qu’il vous est gracieusement offert avec cet abonnement la possibilité de gérer une @MAIL avec 5GO de stockage sur leurs serveurs ainsi qu’un hébergement web de 10 Mo. Aussi, à moins que ce ne soit déjà fait et auquel cas, passez directement au §4.2 ci-dessous, je vous invite à créer cette @MAIL et cet hébergement Web même si en fin de compte vous n’utiliserez pas ce dernier (quoique dans le futur, on ne sait jamais, cela pourrait être une bonne base pour bâtir votre propre site Web. Comme toujours à vous de voir …). Dans tous les cas, ce qui vous intéresse donc ici c’est l’@MAIL offerte car d’une part elle est gratuite donc pourquoi s’en priver ? En plus, elle peut toujours servir à autre chose. Mais d’autre part, c’est surtout que cette création d’@MAIL va pouvoir vous servir en quelque sorte d’@MAIL de secours. Nota : Si vous estimez avoir besoin de plus d’@MAIL, il vous faudra modifier votre abonnement OVH pour acheter des @MAIL supplémentaires. Pour cela : rendez-vous sur le tableau de bord de votre domaine : menu « Web » / section « Emails » / « votredomaine.tld » / Abonnement / Offre MXPLAN 1 hosting et cliquez sur le bouton cerclé « … » et choisissez l’offre qui vous convient En effet, toute l’astuce ici, est de définir cette @MAIL de façon identique à celle que l’on va configurer pour votre utilisateur « principal » dans votre serveur de messagerie « MPS» sur votre NAS. Ainsi, pour le cas où votre NAS ne serait plus joignable de l’extérieur ou qu’il ne réponde plus aux sollicitations externes (pour cause de panne, d’arrêt pour maintenance ou toute autre raison) vous pourrez continuer à pouvoir émettre et surtout recevoir des eMAILs sur cette @MAIL. Intéressant, non ? Seule contrainte, s’il en est, c’est qu’il vous faudra soit vous connecter directement à votre compte OVH pour gérer ces eMAILS, soit avoir installé et configuré un client MAIL comme décrit dans la phase n°3 du guide cité au point 2 ci-après. Donc, après vous être connecté sur votre compte OVH, rendez-vous sur le tableau de bord de votre compte client OVH : Activez votre offre d’hébergement gratuit « Start10M » en suivant les étapes de ce guide. A la fin de du guide vous trouverez un lien permettant de créer votre @MAIL gratuite. Cliquez sur ce lien (qui est rappelé ici) et suivez les étapes de ce second guide. Bien évidemment et c’est ce qui est important, vous créerez votre adresse eMAIL avec le nom de votre utilisateur principal que vous aurez choisi parmi les utilisateurs déjà déclarés ou que vous créerez pour l’occasion sur votre NAS. Au final, votre @MAIL sera donc du type : « utilisateurprincipal@votredomaine.tld ». 4.2 Configuration de la zone DNS chez OVH Si vous avez suivi l’étape précédente du §4.1 ci-dessus alors repositionnez-vous sur votre domaine menu « Web » / section « Domaines » / « votredomaine.tld » sinon ce n’est pas la peine vous y êtes déjà. 4.2.1 Enregistrements « A » · Vérifiez que vous n’avez pas d’enregistrements de type « A » associés à « mail.votredomaine.tld ». Si c’est le cas : supprimez-le ou les. 4.2.2 Enregistrements « MX » Deux cas de figure se présentent ici selon que vous ayez créé ou non une @MAIL de secours en suivant le processus décrit au §4.1 ci-dessus. Si vous n’en avez pas créée alors passez directement au point 2 ci-après. Si vous avez créé une @MAIL de secours « utilisateurprincipal@votredomaine.tld », alors normalement vous devriez trouver dans votre zone DNS, trois (3) enregistrements de type « MX » (ils ont été automatiquement ajoutés par OVH avec la création de l’@MAIL de secours) tels que : votredomaine.tld. 0 MX 1 mx1.mail.ovh.net. votredomaine.tld. 0 MX 5 mx2.mail.ovh.net. votredomaine.tld. 0 MX 100 mx3.mail.ovh.net. Ici les priorités (4ème champ de l’enregistrement) de ces serveurs d’OVH, sont définies de telle façon que ces derniers interviendront en premier pour gérer les flux d’eMAILs entrants et sortants de votre adresse @eMAIL « utilisateurprincipal@votredomaine.tld ». Nota : les priorités vont de la plus forte (1) à la plus faible (100 et plus). Afin que votre @MAIL devienne une @MAIL de secours, on va donc modifier ces priorités en les diminuant pour chacun des deux premiers enregistrements « MX » (mx1 et mx2) .Pour le serveur mx3, c’est inutile vue sa priorité déjà très faible. Pour réaliser cela : o À droite de chaque enregistrement « MX », cliquez sur le bouton cerclé « … » et sélectionnez dans le popup l’item « Modifier l’entrée ». o Dans le champ « Priorité », saisissez respectivement les valeurs suivantes : 5 puis 10. o Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS trois (3) enregistrements « MX » tels que : votredomaine.tld. 0 MX 5 mx1.mail.ovh.net. votredomaine.tld. 0 MX 10 mx2.mail.ovh.net. votredomaine.tld. 0 MX 100 mx3.mail.ovh.net. En premier lieu, vérifiez la présence dans votre zone DNS, d’un enregistrement « MX » tel que : votredomaine.tld. 0 MX 1 redirect.ovh.net. S’il existe effectivement, alors supprimez le purement et simplement. Cet enregistrement, créé par défaut par OVH lors de la mise en place de votre domaine, est inutile dans notre actuelle démarche de configuration de votre propre serveur de messagerie. On va maintenant créer un nouvel enregistrement « MX » qui va rediriger tout le flux d’eMAILs entrants et sortants de votre adresse @eMAIL « utilisateurprincipal@votredomaine.tld » vers votre serveur de messagerie « MPS » sur votre NAS tout en lui donnant la priorité maximum, c’est-à-dire : 1. De cette façon, si vous avez créé une @MAIL de secours « utilisateurprincipal@votredomaine.tld » comme décrit précédemment, alors les serveurs d’OVH tels que configurés au point 1, reprendront automatiquement la main dans le cas où votre NAS et donc implicitement votre serveur de messagerie « MPS », ne répondrait plus aux sollicitations externes. Le flux entrant de vos eMAILs serait alors redirigé automatiquement vers la boîte MAIL de secours chez OVH. Ceci pour tous les eMAILs qui sont adressés à votre @MAIL « utilisateurprincipal@votredomaine.tld » et uniquement pour ceux-là. Pour les autres @MAIL de vos autres utilisateurs définis sur le NAS (donc pour le cas où vous n’auriez pas ajouté d’autres @MAIL sur votre compte OVH), sachez que normalement lorsqu'un serveur MAIL n'arrive pas à joindre un autre serveur pour lui envoyer des eMAILs, le protocole d'échange prévoit que le serveur émetteur réessaye la connexion pendant 14 jours avant d'abandonner l’eMAIL. Donc, même si vous n’avez pas de solution de secours comme décrite ci-avant, le risque de perdre des eMAILs demeure assez limité. De plus, on peut penser que vous n’allez pas rester 14 jours sans réagir, Non ? Donc : o Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». o Cliquez dans la zone « Champs mails » sur « MX ». o Saisissez les informations suivantes : ▪ Sous-domaine : laissez vide ▪ TTL : 3600 ▪ Priorité : 1 ▪ Cible : « votredomaine.tld. » (N’oubliez pas le « . » à la fin, c’est important !) o Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « MX » tel que : votredomaine.tld. 3600 MX 1 votredomaine.tld. 4.2.3 Ajout d’un enregistrement TXT de type « SPF » Avant toutes choses, il convient de vous expliquer à minima ici de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « SPF » et à quoi il sert. Il est très important de bien comprendre tous les tenants et aboutissants de cette notion pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Rassurez-vous, il n’y a rien de bien compliqué en soi mais prenez bien le temps de bien lire ce qui suit pour en assimiler le concept. Donc : Le protocole Simple Mail Transfer Protocol (SMTP) utilisé pour le transfert du courrier électronique sur Internet ne prévoit pas de mécanisme de vérification de l'expéditeur, c'est-à-dire qu'il est facile d'envoyer un eMAIL avec une adresse d'expéditeur factice, voir usurpée. Pour réduire les possibilités d'usurpation, on va publier, dans la zone DNS de votre domaine, un enregistrement spécifique indiquant la liste de toutes les @IP qui sont autorisées à envoyer des eMAILs au nom de votre domaine (implicitement les autres @IP sont interdites). Cet enregistrement spécifique est nommé : « SPF » (Sender Policy Framework) ou enregistrement « SPF TXT ». « SPF » est un protocole d'authentification des eMAILs. Fonctionnement : Lorsqu'un expéditeur tente de transférer un eMAIL à un serveur de réception pour qu'il lui soit livré, le serveur de MAILs vérifie si l'expéditeur figure sur la liste des expéditeurs autorisés du domaine. Si c'est le cas, un lien a été établi entre l’eMAIL et le domaine de messagerie. Si ce n'est pas le cas, le serveur continue à traiter le courrier électronique comme d'habitude sans ce lien et là, l’eMAIL a toutes les chances d’être considéré comme du SPAM. La plupart du temps il est purement et simplement rejeté. Avec un enregistrement « SPF » en place, vous allez protéger ainsi votre domaine de messagerie contre les attaques de spoofing et de phishing en faisant savoir au monde entier quels sont les serveurs autorisés à envoyer des eMAILs authentifiés en votre nom. Il vous faut aussi savoir que les « RFC »(Request for Comments) sur le domaine « DNS » ont initialement introduit le type d’enregistrement « SPF » pour prendre en charge ce scénario. Pour prendre en charge des serveurs de noms plus anciens, elles autorisaient également l’utilisation du type d’enregistrement « TXT » pour spécifier les enregistrements « SPF ». Nota : Cet enregistrement « TXT » est aussi appelé « SPF TXT » car on utilise aussi les enregistrements de type « TXT » pour d’autres notions. Cette ambiguïté a entraîné une certaine confusion qui a été résolue par la norme RFC 7208. Celle-ci stipule notamment que les enregistrements « SPF » doivent être créés à l’aide du type d’enregistrement « TXT » (« SPF TXT »). Elle stipule également que le type d’enregistrement « SPF » est déprécié. L’ajout dans la zone DNS de votre domaine d’un enregistrement « SPF TXT » est l'un des mécanismes le plus important lorsqu'on met en place un serveur MAIL. Comme la configuration sur un NAS Synology est souvent faite avec un seul domaine et un seul serveur principal, l'adresse à définir correspond à l'enregistrement « MX » du domaine. L'intérêt de choisir cet enregistrement, est que l’enregistrement « SPF TXT » suivra implicitement les modifications de cet enregistrement « MX » qui pourraient intervenir par ailleurs ensuite. Donc dans le cas du présent tutoriel, l’enregistrement « SPF TXT » sera de la forme et syntaxe suivante : votredomaine.tld. 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all" Où : « v=spf1 » : indique la version du protocole SPF. « mx » : indique au mécanisme de contrôle d’examiner les @IP définies dans les enregistrements « MX ». « a :smtp.smtpout.orange.fr » : indique la liste des @IP autorisées à émettre des eMAILs pour le domaine. Ici cela correspond à votre serveur relais SMTP chez Orange. « include :mx.ovh.com » : indique la liste complémentaire d’@IP également autorisées à émettre des eMAILs pour le domaine. Ici cela correspond aux serveurs d’OVH que l’on utilise comme serveurs de secours. « -all » : indique la politique et la rigueur à appliquer lorsqu'un serveur récepteur détecte un serveur qui n'est pas répertorié (autorisé) dans votre enregistrement « SPF TXT ». Ici, la balise « all » comporte en préfixe l’option « - » qui signifie « échec » : les eMAILs non autorisés seront donc rejetés. Si vous êtes en phase de configuration ou de test de votre serveur, vous pouvez utiliser à la place l'opérateur "~" (tilde) qui signifie (soft fail) et qui vous évitera des blocages intempestifs. Dans ce cas, les eMAILs non autorisés seront acceptés mais marqués. Pour les plus curieux d’entre vous qui souhaiteraient aller plus loin, sachez que si vous utilisez plusieurs domaines et que votre enregistrement « SPF TXT » est identique pour tous ces domaines, la directive « redirect » permet de faire pointer l'enregistrement « SPF TXT » d'un domaine vers celui d'un autre domaine. Ainsi, en cas de modification de l’enregistrement « SPF TXT », la modification sera appliquée à tous les autres domaines. La syntaxe à employer est celle-ci : v=spf1 redirect=votredomaine.tld D'où la bonne pratique qui est de le faire même si vous ne possédez qu'un seul domaine afin d’anticiper l'acquisition d'autres domaines ultérieurement, la syntaxe de votre enregistrement « SPF TXT » pour votre domaine devient par exemple : votredomaine.tld 0 TXT "v=spf1 mx -all" autredomaineA.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineB.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineC.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineD.tld 0 TXT "v=spf1 redirect=votredomaine.tld" . . . Pour terminer cet aparté, sachez enfin que vous pouvez résoudre récursivement les enregistrements « SPF TXT » pour vérifier les hôtes autorisés. En voici un exemple avec « mx.ovh.com » : Dans une fenêtre de commande Windows ou d’un terminal Mac, tapez ceci : > nslookup -type=TXT mx.ovh.com mx.ovh.com text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" > nslookup mail-out.ovh.net Name: mail-out.ovh.net Address: 87.98.222.13 > nslookup mail.ovh.net Name: mail.ovh.net Address: 193.70.18.148 Le problème de la constitution et de la syntaxe de votre enregistrement « SPF TXT » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « SPF TXT » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, il y a deux façons : La première et la plus sage à mon sens, consiste à effectuer le contrôle avant de créer effectivement cet enregistrement « SPF TXT » dans la zone DNS de votre domaine. Vous verrez et comprendrez par la suite, que l’on perd moins de temps avec cette méthode. La seconde, consiste à créer directement l’enregistrement dans la zone DNS de votre domaine, ce qui va déclencher sa diffusion sur tous les serveurs DNS de la toile (sachant que la propagation complète de l’enregistrement est loin d’être instantanée) et ensuite de procéder au contrôle de l’enregistrement « SPF TXT » (vous verrez plus loin aussi que cette dernière méthode apporte une petite nuance, par rapport à la première méthode, qui vous sera explicitée). Vous avez donc le choix de la méthode à appliquer. C’est vous qui voyez … Néanmoins pour ce tutoriel, on va appliquer la première méthode. Ceci dit, vous trouverez plus loin, après la description du déploiement de l’enregistrement « SPF TXT », la description de la seconde méthode de contrôle suscitée. Soyez patient, chaque chose en son temps …. Donc pour contrôler la syntaxe de votre enregistrement « SPF TXT », on va utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « kitterman.com ». (Il en existe certes d’autres mais celui-là est réputé être très efficace). Dans la zone « Test an SPF record », saisissez les données suivantes dans les champs correspondants : IP address : 10.20.30.40 (votre @IP externe, i.e. celle de votre Box/Routeur). SPF Record v=spf1...://--> : v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all (la chaîne de paramètres SPF et sans les guillemets !) Mail From address: : utilisateurprincipal@votredomaine.tld HELO/EHLO Address://--> : votredomaine.tld Cliquez sur le bouton « Test SPF record ». Le résultat du contrôle s’affiche après quelques secondes : Input accepted, querying now... Mail sent from this IP address: 10.20.30.40 Mail from (Sender): utilisateurprincipal@votredomaine.tld Mail checked using this SPF policy: v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all Results - PASS sender SPF authorized Mail sent from this IP address: 10.20.30.40 Mail Server HELO/EHLO identity: votredomaine.tld HELO/EHLO Results - PASS sender SPF authorized « PASS sender SPF authorized » : Parfait, la syntaxe de votre enregistrement « SPF TXT » est validée et sans erreur, on va donc pouvoir créer effectivement ce fameux enregistrement « SPF TXT » dans la zone DNS de votre domaine. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : laisser vide TTL : laisser « Valeur par défaut » Valeur : « v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all » (sans les guillemets !) Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : votredomaine.tld. 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all" Nota : Dans la dernière fenêtre, juste avant de valider, vous avez certainement remarqué et lu l’avertissement suivant :« La modification sera immédiate dans la zone DNS, mais veuillez prendre en compte le temps de propagation (maximum 24h). ». Cet avertissement est loin d’être anodin. Il va falloir prendre votre mal en patience si je puis dire …Le temps de propagation vers tous les serveurs DNS de la toile est en effet assez long. Parfois, il semble rapide mais ce n’est que parfois. Pour suivre en quelque sorte l’avancement de ce déploiement, vous pouvez utiliser le moyen suivant : Dans un navigateur Web, rendez-vous sur le site « whatsmydns.net »: Saisissez l’intitulé de votre domaine : « votredomaine.tld ». Dans le popup à droite du champ domaine, sélectionnez l’item « TXT ». Cliquez sur le bouton « Search ». (Recliquez périodiquement jusqu’au déploiement complet). Lorsque la propagation complète sera achevée, vous aurez un affichage semblable à celui-ci : Une fois la propagation achevée, c’est là que vous pouvez appliquer la seconde méthode de contrôle de l’enregistrement « SPF TXT ». Différents sites sur la toile proposent des outils en ligne pour ce faire. Donc, dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com » (Il en existe certes d’autres mais celui-là est l’un des plus efficace et complet) Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail des @IP autorisées à émettre des eMAILs pour votre domaine vous est présenté. En l’occurrence pour le relais SMTP d’Orange que l’on a indiqué, on a la liste d’@IP suivante : A la suite, on trouve la liste des serveurs MAIL autorisés avec leur @IP : Enfin, on trouve l’enregistrement « SPF TXT » propre aux serveurs d’OVH que l’on a inclus afin de servir de serveurs de secours. Figurent également les @IP de ces serveurs qui sont autorisées à émettre des eMaILs avec/sur votre domaine. A ce stade, vous avez bien évidemment remarqué l’avertissement formulé à propos des serveurs d’OVH et qui soit dit en passant, n’avait pas été relevé lors du contrôle de l’enregistrement « SPF TXT » avec la première méthode précédente (c’est la fameuse nuance suscitée). En fait, cet enregistrement « SPF TXT » pour les serveurs d’OVH n’est pas obsolète. Il est parfaitement fonctionnel et valide, mais l’usage des balises d’instructions « PTR » qu’il fait, est simplement déconseillé au sens de la norme RFC 7208 citée précédemment. Techniquement, le mécanisme est intéressant en soi car il permet une double validation DNS du serveur d'expédition. Mais la résolution inverse pose des problèmes de performances et donc de fiabilité. En clair selon les « initiés » de ce forum, si cela posait vraiment des problèmes de fiabilité, on peut penser qu'OVH aurait déjà rectifié la chose. Et en l’occurrence ce qui n’est pas le cas. Maintenant si vous êtes vraiment gênés par cet avertissement, il existe une parade. Vous pouvez toujours créer un nouvel enregistrement « SPF TXT » dans votre zone DNS en ayant pris soin de remplacer les instructions « ptr » par un « a » et inclure celui-ci dans votre enregistrement « SPF TXT » principal. Ce qui donnerait quelque chose comme cela : ovh.domain.tld 0 TXT "v=spf1 a:mail-out.ovh.net a:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" votredomain.tld 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:ovh.domain.tld -all" Néanmoins sachez que le gros inconvénient de cette méthode est qu'elle est statique et donc non viable dans le temps. En effet, l'enregistrement « ovh.domain.tld » sera obsolète dès qu'OVH modifiera son enregistrement « SPF TXT », et cela vous ne pourrez le maîtriser. Au final les « initiés » de ce forum, préconisent de laisser tel quel l’enregistrement « SPF TXT » d'OVH même s'il n'est pas optimal. Je vous invite donc à suivre cette recommandation. De toute façon, on le reverra plus loin (voir § 8.1 ci-dessous) lors des tests de diffusion d’eMAILs avec votre serveur de messagerie « MPS », que ce n’est pas un point bloquant. Toutefois et comme toujours, c’est vous qui voyez … 4.2.4 Ajout d’un enregistrement TXT de type « DKIM » Comme pour l’enregistrement « SPF TXT », il convient aussi de vous expliquer à minima ici de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « DKIM » et à quoi il sert. La bonne compréhension de tous les tenants et aboutissants de cette notion est aussi très importante pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Donc : Domain Keys Identified Mail (DKIM) est l'une des méthodes d'authentification utilisée par les opérateurs de messagerie, permettant de déterminer l'identité d'un expéditeur et donc de l’authentifier. Comme « SPF », « DKIM » est une norme ouverte pour l'authentification des eMAILs utilisée pour ce qu’on appellera plus loin : « l‘alignement DMARC ». L’avantage de « DKIM » est qu’il peut survivre à la transmission, ce qui le rend supérieur à « SPF » et c’est une base pour sécuriser votre eMAIL. Fonctionnement : Les serveurs de MAILs sont configurés pour attacher en en-tête de chaque eMAIL qu’ils envoient, une signature dite « DKIM ». Cette signature « DKIM » contient des informations sur l'expéditeur et le message, nécessaires à la vérification qui sera effectuée en cours de route par les serveurs MAIL qui acheminent les MAILs vers leur destination finale. Cet en-tête de signature « DKIM » qui est ajouté à l'eMAIL, est sécurisé avec une paire de clés publique / privée dites clés « DKIM » et un certificat. La signature « DKIM » agit alors comme un filigrane pour les eMAILs afin que les destinataires de ces eMAILs puissent vérifier que chaque eMAIL provient bien du domaine indiqué et qu'il n'a pas été altéré voire falsifié. Ainsi selon leur propre méthode, les serveurs de MAILs établissent la réputation et la fiabilité d'un expéditeur, augmentant ou diminuant selon, de fait la délivrabilité des eMAILs de ce dernier. Cette signature « DKIM » contient également toutes les informations nécessaires à un serveur de messagerie pour qu’il puisse vérifier que la signature « DKIM » est bien réelle. Le serveur de messagerie d'origine possède ce qu'on appelle la «clé privée», qui peut être vérifiée par le serveur de messagerie ou le FAI récepteur avec l'autre moitié de la paire de clés, qui est appelée la «clé publique». La clé publique figure dans l’enregistrement « DKIM » inclus dans la zone DNS de votre domaine sous forme d’un enregistrement de type « TXT ». Afin de connecter et de déchiffrer ces signatures chiffrées, un « sélecteur DKIM » est utilisé. Le « sélecteur DKIM », tout comme la signature « DKIM », est aussi spécifié dans l'en-tête de l’eMAIL. Il indique où la partie de la clé « publique » de la paire de clés « DKIM » se trouve dans le DNS du domaine concerné. Le serveur MAIL de réception utilise alors le « sélecteur DKIM » pour localiser et récupérer cette clé « publique » afin de vérifier que l’eMAIL est authentique et n’a pas été altéré. Pour mémoire, lors de la pré configuration de votre « MPS » au § 3 ci-dessus, vous avez défini ce « sélecteur DKIM » sous forme d’un « préfixe » afin de pouvoir générer la partie « publique » de votre clé « DKIM ». Sachez qu’en même temps, la partie « privée » de votre clé « DKIM » a aussi été générée et ce de façon complétement transparente pour vous. Elle est stockée dans les arcanes de votre NAS. Je ne saurais vous dire où et peu importe, on n’en a pas besoin dans le cadre de ce tutoriel. Les plus curieux d’entre vous pourront toujours la rechercher mais je doute que cela leur apporte grand-chose … 🤔 Comme vous pouvez le constater, les éléments du puzzle commencent à s’imbriquer progressivement … 😀 Voilà pour les explications contextuelles préalables. Donc dans le cas du présent tutoriel, l’enregistrement « DKIM » sera de la forme et syntaxe suivante : prefixe._domainkey.votredomaine.tld. 0 TXT "v=DKIM1; q=dns; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" Où : « v=DKIM1 » : indique la version du protocole DKIM. « q=dns » : indique le type de requête. Ici « dns ». « p= xxxxxx…………xxxxxx » : votre clé « publique » encodée base64. Le problème de la constitution et de la syntaxe de votre enregistrement « DKIM » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « DKIM » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, on va utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com ». (Le même que précédemment vous l’aurez remarqué …). Saisissez l’intitulé de votre « prefixe » de sélecteur DKIM tel que vous l’avez défini au § 3 ci-dessus. Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle du dossier « DKIM » de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail du dossier est présenté. Il vous donne : la longueur de la clé de chiffrement utilisée et une explication de chacune des balises qui ont été utilisées. « Ceci semble être un dossier DKIM valide » Parfait, la syntaxe de votre enregistrement « DKIM » est validée et sans erreur, on va donc pouvoir procéder à la création de ce fameux enregistrement « DKIM » dans la zone DNS de votre domaine chez OVH. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : prefixe._domainkey (bien évidemment et pour rester cohérent, reprenez pour prefixe la valeur que vous aviez choisie précédemment au § 3 ci-dessus, et n’oubliez pas le « . » derrière, c’est important !) TTL : laissez « Valeur par défaut » Valeur : « v=DKIM1; q=dns; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx » (sans les guillemets !) en remplaçant xxxxxxxxxxxxxxxxxxxxxxxxxx par la valeur de votre clé « publique » précédemment sauvegardée. ⚠ Pour le coup, soyez très vigilant avec votre Copier/Coller !!! Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : prefixe._domainkey.votredomaine.tld. 0 TXT "v=DKIM1; q=dns; p=xxxxxxxx…………..xxxxxxxx" 4.2.5 Ajout d’un enregistrement TXT de type « DMARC » Vous l’aurez compris, comme pour les enregistrements « SPF TXT » et « DKIM », il convient aussi de vous expliquer à minima ici toujours de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « DMARC » et à quoi il sert. La bonne compréhension de tous les tenants et aboutissants de cette notion est elle aussi très importante pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Donc : Pour mémoire, l’eMAIL a été initialement créé sans une vraie protection, en se reposant sur le protocole SMTP pour sa diffusion. C’est pour cette raison que l’on a vu apparaître au fil des années, des protections destinées à améliorer la sécurité des échanges en SMTP. Les protocoles « SPF » et « DKIM » vus précédemment en font partie et sont efficaces chacun dans leur domaine. Je vous les rappelle succinctement : « SPF » (Sender Policy Framework) : permet de déclarer les@IP autorisées à envoyer des eMAILs au nom de votre domaine. Il peut, à lui seul, associer un eMAIL à un domaine. « DKIM » (Domain Keys Identified Mail) : permet grâce à une signature cryptographique de s’assurer que le message que vous envoyez/recevez ne va pas se faire altérer en cours de route. Par contre, à lui seul il n'est pas un moyen fiable d'authentifier l'identité de l'expéditeur de l'eMAIL et en plus il ne fait rien pour empêcher l'usurpation d'identité du domaine visible dans l'en-tête de cet eMAIL. En pratique, les protocoles « SPF » et « DKIM » viennent chacun vérifier dans l’entête de l’eMAIL, le « Mailfrom : », i.e. le domaine l’expéditeur extrait à partir de son @MAIL. Cependant, ils ne vont pas inspecter le « From : », qui correspond au vrai expéditeur de l’eMAIL. En fait, ces deux protocoles ne vérifient pas que ces informations concordent, ce qui rend au passage, un possible contournement par des malfaisants. Cela dit, les protocoles « SPF » et « DKIM » restent toutefois et sont deux protocoles de protections indispensables. Pour répondre à cette problématique de possible contournement, il a été mis en place le protocole « DMARC » (Domain-based Message Authentification Reporting and Conformance) qui est lui-même construit sur les protocoles « SPF » et « DKIM ». Sachant que les protocoles « SPF » et « DKIM » peuvent associer un eMAIL à un domaine, le protocole « DMARC » va lui, tenter de lier les résultats des protocoles « SPF » et « DKIM » au contenu de l’eMAIL lui-même et plus précisément au domaine figurant dans la voie de retour (« Return-Path: ») ou dans l'en-tête « From : » de cet eMAIL. C’est ce domaine trouvé dans l'en-tête « From : » qui va être l'entité commune à tous les traitements « DMARC ». Le schéma suivant (extrait de l’entête d’un eMAIL) vous sera peut-être plus parlant : Comme tout le monde peut acheter un domaine et mettre en place des enregistrements « SPF » et « DKIM » dans la zone DNS de son domaine (y compris les malfaiteurs), les résultats du traitement « SPF » et « DKIM » doivent donc être liés au domaine trouvé dans l'en-tête « From : » pour être pertinents pour le protocole « DMARC ». Ce concept de liaison s’appelle « l’alignement d’ identifiants ». Il vient ainsi agir sur les eMAILs là où les protocoles « SPF » et « DKIM » ont échoués. « L'alignement des identifiants » est donc la manière dont les technologies d'authentification existantes sont rendues pertinentes pour le contenu d'un eMAIL. L'alignement des identifiants constitue une grande partie du travail de déploiement de la norme « DMARC ». Ensemble, ces protocoles constituent ainsi la meilleure pratique pour éviter le spoofing d’eMAILs et rendre vos eMAILs plus fiables. Mais attention, le protocole « DMARC » ne fonctionne que si vous avez configuré un enregistrement « SPF » et « DKIM » dans la zone DNS de votre domaine. Fonctionnement : Durant le contrôle « DMARC », le contenu figurant dans le « Mailfrom : », et le « From : » figurants dans l’entête de l’eMAIL, est donc examiné. S’il est différent, alors le protocole « DMARC » peut traiter l’eMAIL de trois manières possibles (appelées aussi « politiques DMARC ») : DMARC policy none : On vient juste surveiller les résultats mais on ne prend aucune mesure concernant ces eMAILs. Vous les recevrez, mais un message sera envoyé à l’administrateur du domaine expéditeur pour le prévenir que l’alignement n’est pas respecté. DMARC policy quarantine : Tous les eMAILs qui échouent au respect des protections, sont mis en quarantaine, ils peuvent être traités ultérieurement. DMARC policy reject : Les eMAILs qui ne passent pas les vérifications de la norme, vont s’annuler directement pour qu’ils ne soient pas envoyés au destinataire. Encore un schéma qui résume bien le processus « DMARC » dans sa globalité : Ainsi, la norme « DMARC » permet de lutter plus efficacement contre le spam et le phishing. Si les renseignements de l’eMAIL respectent les contrôles « SPF » et « DKIM » et respectent l’alignement, alors l’eMAIL passera la protection DMARC. Cette norme est donc indispensable pour assurer une protection optimisée. Voilà pour les explications contextuelles préalables. Donc dans le cas du présent tutoriel, l’enregistrement « DMARC » sera de la forme et syntaxe suivante : _dmarc.votredomaine.tld. 0 TXT "v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" Où : « v=DMARC1 » : indique la version du protocole DMARC. « p=quarantine » : indique la politique à appliquer aux eMAILs qui échouent à la vérification DMARC Ici on souhaite que les eMAIL en échec soient placés en quarantaine afin de pouvoir les examiner. Néanmoins, vous pouvez modifier ce paramètre pour « none » ou « reject » comme expliqué précédemment. C’est vous qui voyez … « rua=mailto :utilsateurprincipal@votredomaine.tld » : indique une liste d’URI (Uniform Ressource Identifier) pour que les FAI envoient des commentaires XML. Vous noterez que ce n’est normalement pas une liste d’@MAIL. DMARC requiert simplement une liste d’URI de la forme «mailto:test@exemple.com». Ici, néanmoins j’ai fait le choix de mettre l’URL de l’utilisateur principal du NAS. Mais cela peut se discuter … « ruf=mailto :utilsateurprincipal@votredomaine.tld » : indique une liste d’URI (Uniform Ressource Identifier) pour que les FAI envoient des rapports légaux. Vous noterez que ce n’est normalement pas une liste d’@MAIL. DMARC requiert simplement une liste d’URI de la forme «mailto:test@exemple.com». Ici, néanmoins j’ai fait aussi le choix de mettre l’URL de l’utilisateur principal du NAS. Mais cela peut se discuter … « fo=1 » : indique de générer des rapports si DKIM ou SPF ne produit pas de résultat de réussite DMARC. Vous pouvez aussi utiliser les valeurs suivantes : « 0 » pour générer des rapports si DKIM et SPF échouent, « d » pour générer des rapports si DKIM a échoué ou « s » si SPF a échoué. C’est vous qui voyez … « adkim=s » : indique le « Mode d’alignement » pour les signatures DKIM, cela peut être « r » (Relâché) ou « s » (Strict). En mode Relâché, les domaines de signature DKIM authentifiés (d=) qui partagent un Domaine Organisationnel avec un domaine « From » d’eMails passeront la vérification DMARC. En mode Strict, une correspondance exacte est requise. Ici le mode strict est retenu. « aspf=s » : indique le « Mode d’alignement » pour SPF, cela peut être « r » (Relâché) ou « s » (Strict). En mode Relâché, également les domaines SPF authentifiés qui partagent un Domaine Organisationnel avec un domaine «From» d’eMAILs passeront la vérification DMARC. En mode Strict, une correspondance exacte est requise. Ici le mode strict est retenu. « pct=100 » : indique aux FAI d’appliquer uniquement la politique DMARC à un pourcentage d’eMAILs défaillants. « pct=50 » indiquera aux récepteurs d’appliquer la politique « p= » seulement 50% du temps contre les emails qui échouent à la vérification DMARC. Notez que ceci ne fonctionnera pas pour la politique « none », mais uniquement pour les politiques « quarantine » ou « reject ». Ici 100% soit tous les eMAILs sont traités. Adaptez la valeur à vos besoins … « ri=86400 » : indique l’intervalle de génération de rapports pour la fréquence à laquelle vous souhaitez recevoir des rapports XML cumulés. Ceci est une préférence et les FAI pourraient (et probablement vont) envoyer le rapport à différents intervalles (normalement ce sera chaque jour). Ici 86400 secondes soit un jour. Adaptez à vos besoins … « sp=reject » : indique la politique qui doit être appliquée aux eMAILs provenant d’un sous-domaine de ce domaine qui échouent à la vérification DMARC. En utilisant cette étiquette, les propriétaires de domaines peuvent publier une politique « générique » pour tous les sous-domaines. Ici on rejette les eMAILS concernés. Le problème de la constitution et de la syntaxe de votre enregistrement « DMARC » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « DMARC » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, on va encore utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com ». (Encore le même que précédemment, on ne change pas une équipe qui gagne … 🤣) Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle du dossier « DMARC » de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail du dossier est présenté. Il vous donne une explication de chacune des balises qui ont été utilisées. Dans le cas présent, le résultat du contrôle vous indique avoir trouvé un problème avec le dossier DMARC : « Info : Nous avons trouvé une adresse personnalisée dans votre dossier DMARC. Veuillez-vous assurer de faire suivre les rapports entrants à votre adresse personnalisée pour voir les statistiques dans . ». Rassurez-vous, cette « anomalie » n’est pas bloquante et vous pouvez considérer la syntaxe de votre enregistrement « DMARC » comme correcte. Un autre contrôle effectué via un autre site dédié tel que « mxtoolbox.com » vous en apportera la preuve si besoin en est. Donc, la syntaxe de votre enregistrement « DMARC » est validée et sans erreur, on va donc pouvoir procéder à la création de ce fameux enregistrement « DMARC » dans la zone DNS de votre domaine chez OVH. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : _dmarc TTL : laissez « Valeur par défaut » Valeur : « v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject» (sans les guillemets !) en remplaçant utilisateurprincipal@votredomaine.tld par la valeur d’@MAIL de votre utilisateur principal. Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : _dmarc.votredomaine.tld. 0 TXT "v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" 4.2.5 Ajout d’un enregistrement TXT de type « CNAME » pour « mail.votredomaine.tld » La configuration décrite ci-après n’est à réaliser que si et seulement si vous souhaitez pouvoir accéder à l’application « MailPlus » depuis l’extérieur (à l’aide de votre reverse proxy) en saisissant un simple « mail.votredomaine.tld » dans un navigateur Web. Elle est parfaitement optionnelle (voir § 7 ci-dessous). Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs de pointage » sur « CNAME ». Saisissez les informations suivantes : Sous-domaine : « mail » TTL : laissez « Valeur par défaut » Cible : « votredomaine.tld. » (N’oubliez pas le « . » à la fin, c’est important !) Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « CNAME » tel que : mail.votredomaine.tld. 0 CNAME votredomaine.tld. Voilà, on en a terminé avec la configuration de la « zone DNS » de votre domaine « votredomaine.tld ». Vous pouvez à présent normalement vous déconnecter de votre compte OVH. 5 Finalisation de la configuration de MailPlus Server Maintenant que la partie concernant la « zone DNS » de votre domaine est claire chez OVH, on va reprendre et finaliser la configuration de « MailPlus Sever » (« MPS ») tout en sécurisant ce dernier. Pour ce faire, on va passer en revue chaque section (pas forcément dans leur ordre d’affichage dans l’interface d’administration) pour paramétrer et/ou ajuster ce qui doit l’être dans celles-ci par rapport à la configuration par défaut mise en place automatiquement lors de l’installation du package « MPS ». Notez bien que cette revue de configuration ne va pas non plus, se substituer au guide de l’Administrateur Synology « MPS » qui lui vous fournira tous les détails nécessaires pour toutes les fonctions. Un grand nombre de réglages complémentaires resteront de votre libre arbitre. 5.1 Section « Administration du serveur » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de consulter le trafic de messagerie entrant/sortant ainsi que l'état du ou des serveurs de votre système de messagerie. 5.2 Section « Surv menace » Dans notre cas cette section n’a pas d’intérêt. Vous y trouverez des statistiques détaillées de divers types, sur les menaces liées aux eMAILs entrants et sortants et leurs sources. Ces informations vous sont présentées sous forme de graphiques clairs. Ainsi leur exploitation vous permettra d’ajuster les paramètres de « MPS » de manière appropriée pour une sécurité optimale. 5.3 Section « Domaine » En principe et dans un premier temps, il n’y a rien de plus à paramétrer dans cette section qui n’ait déjà été fait lors de la phase de pré configuration de « MPS » au § 3 ci-dessus. Par contre dans un second temps, vous pourrez ici ajouter de nouveaux utilisateurs à votre serveur de messagerie en ayant au préalable pris soin de les créer comme utilisateurs locaux de votre NAS avec le même identifiant/pseudo (c’est mieux !). Cela dit, vous pourrez tout aussi bien choisir d’utiliser des utilisateurs issus d’un annuaire Active Directory ou LDAP si votre NAS est associé à l’un d’entre eux. C’est ici aussi que vous pourrez selon vos propres besoins, affiner le paramétrage de chaque utilisateur, créer des alias de regroupement d’utilisateurs (appelées aussi listes de distribution) pour l’émission/réception d’eMAILs ou encore la création de règles BCC (Blind Copy Carbone) automatiques pour par exemple sauvegarder les messages importants et ainsi protéger la confidentialité du destinataire. 5.4 Section « Distribution » Dans cette section on va paramétrer notre « facteur Internet » à savoir le protocole « SMTP » (Simple Mail Transfer Protocol) qui a en charge d’assurer la livraison/distribution des eMAILs entrants et/ou sortants de votre serveur de messagerie. Partie « SMTP » : Normalement, le protocole « SMTP » utilise trois (3) ports de communication pour fonctionner. Dans « MPS », ils sont affichés comme : SMTP (numéro de port: 25), SMTP-SSL (Numéro de port: 465), SMTP-TLS (Numéro de port: 587). Dans le cas du présent tutoriel, l’utilisation du relai SMTP d’Orange nécessite uniquement l’activation des protocoles « SMTP » et « SMPT-TLS ». En conséquence : Cochez uniquement les deux cases correspondantes : « SMTP » et « SMTP-TLS ». Nota 1 : Pour mémoire, l’usage de« SMTP-TLS » nécessite une authentification. Celle-ci sera configurée dans la section « Remise de message » au § 5.5 ci-dessous. Nota 2 : Si vous avez configuré sur votre NAS (« Panneau de configuration DSM / Sécurité / Avancé ») le « Niveau de profil TLS / SSL » sur « Compatibilité moderne » , certains clients de messagerie (par ex., Outlook 2016) peuvent s'avérer incapables d'établir des connexions en raison de ce paramètre. Dans ce cas, pour assurer une meilleure compatibilité avec les clients de messagerie, fixez alors le « Niveau de profil TLS/SSL » à « Compatibilité intermédiaire ». Vérifiez que les affectations de ports correspondantes sont bien respectivement : 25 et 587. Partie « Interface réseau » : Vérifier que l’interface « LAN1 » avec l’@IP de votre NAS (« 1.2.3.4 ») soit sélectionnée. Partie « IMAP/POP3 » : Pour l’exemple de ce tutoriel, comme l’on va faire « simple » en utilisant le client de messagerie « MailPlus » de Synology, l’activation du service POP3 n’est donc pas nécessaire. Toutefois, si vous souhaitez utiliser un client de messagerie « tiers » tel que Microsoft Outlook ou Apple Mail pour récupérer vos MAILs, alors il vous faut cocher la case « Activer POP3 SSL/TLS » pour autoriser une connexion client POP3 protégée (chiffrée) avec SSL/TLS et ainsi permettre à vos utilisateurs d'extraire des eMAILs à partir de « MPS » vers ce client de messagerie. Cochez la case « Activer IMAP SSL/TLS » pour autoriser une connexion client IMAP protégée (chiffrée) avec SSL/TLS et ainsi permettre à vos utilisateurs d'extraire des eMAILs à partir de « MPS » vers le client de messagerie (que vous utilisez) et de gérer leur boîte de MAILs. « Partie recherche en texte intégral » : Cochez cette case pour activer la recherche par mots-clés à l’intérieur de vos eMAILs. C’est une fonction utile mais qui reste cependant une option pour vous. C’est vous qui voyez … Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5 Section « Remise de message » 5.5.1 Onglet « Général » Pour éviter que n’importe qui utilise votre serveur d’envoi de MAILs, il est nécessaire d’activer « l’authentification SMTP ». De toutes façons, cette activation est aussi implicitement requise du fait de l’usage du protocole « SMTP‑TLS » lui-même imposé par l’usage du serveur relai SMTP d’Orange nécessaire au bon fonctionnement de votre serveur de messagerie. Par ailleurs, les utilisateurs qui ne passent pas l'authentification ne pourront pas transférer leurs eMAILs. Cela empêchera ainsi votre serveur d'être inscrit sur les listes noires. Cochez la case « Activer l’authentification SMTP » Sans les identifiants de connexion, les clients d'un réseau local de « MPS » pourraient recevoir et envoyer directement des eMAILs en utilisant un terminal. Aussi par sécurité, Ignorez l'authentification pour les connexions réseau locales à partir d'un terminal. Ne cochez pas la case « Ignorer l'authentification pour les connexions réseau locales à partir d'un terminal ». Lors de l'envoi d'eMAILs, par sécurité il est préférable d’imposer à l'utilisateur connecté d’utiliser l’@MAIL d'un utilisateur qui appartient au compte de connexion et implicitement on n’ignorera pas la vérification de l’@MAIL de l’expéditeur pour voir s’il appartient au compte de connexion pour les eMAILs envoyés depuis des réseaux fiables. Cochez la case « Vérifier si les adresses e-mails des expéditeurs appartiennent aux comptes de connexion ». Ne cochez pas la case « Ignorer la vérification de l’@MAIL de l’expéditeur … ». Dans « MPS » le nom d'hôte doit être spécifié au format FQDN (« Fully Qualified Domain Name » ou nom de domaine pleinement qualifié, est un nom de domaine qui donne la position exacte de son nœud dans l'arborescence DNS en indiquant tous les domaines de niveaux supérieurs). Dans le cas du présent tutoriel il s’agit simplement de votre nom de domaine « votredomaine.tld ». « Nom d’hôte (FQDN) » : Saisissez « votredomaine.tld » Il est important ici de renseigner le champ « SMTP Banner ». Indépendamment du fait qu’il indique le texte qui s’affichera sur le terminal TELNET d’un client SMTP (information qui peut paraître optionnelle), il concourt à la note finale qui sera donnée à vos envois de MAILs lors du test final que l’on réalisera à l’issue de la configuration de « MPS » (voir § 8.1 ci-dessous). « SMTP Banner » : Saisissez « votredomaine.tld » Vous pouvez laisser tels quels (à leur valeur par défaut) les autres paramètres de nombre et de taille. Vous pouvez aussi les modifier et les adapter à vos besoins si vous savez ce que vous faites. Cliquez sur le bouton « Administrateur externe » Dans la fenêtre qui s’affiche : Cochez la case « Activer l’administrateur externe ». Il vous faut alors désigner un utilisateur (via son @MAIL) qui pourra recevoir les messages système envoyés au démon de messagerie par les administrateurs d'autres serveurs de messagerie. Sélectionnez à l’aide du popup, un utilisateur local. Cliquez sur « OK » pour valider. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5.2 Onglet « Delivery » Comme je vous l’ai indiqué au point 4 du préambule de ce tutoriel, le serveur SMTP Orange ignore les connexions provenant d'un autre réseau si elles lui arrivent sur le port 25, ce qui donne l’impression que ce port est bloqué. Donc, pour contourner ce pseudo « blocage » du port 25, et c’est l’astuce principale de ce tutoriel, on va donc ici utiliser la particularité de « MPS » qui lui permet d’envoyer des messages via d'autres serveurs de messagerie sans être lui-même exposé à Internet ou à d'éventuelles attaques. On va donc spécifier précisément à « MPS » passer par le serveur SMTP d’Orange pour émettre vos eMAILs. Ainsi, vous n’aurez aucun risque de vous les faire rejeter. Pour ce faire : Sélectionnez l’option « Tous les messages sont envoyés via un unique hôte actif » « Serveur : » : Saisissez « smtp.orange.fr » « Port : » : Saisissez « 587 » Cochez la case : « Authentification requise » « Compte : » :Saisissez « votreidentifiantdeconnexionOrange » « Mot de passe : » : Saisissez « votremotdepassedeconnexionOrange » Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5.3 Onglet « Relayer le contrôle » Dans notre cas cet onglet n’a pas d’intérêt. Au besoin, à vous de voir quoi en faire … 5.5.4 Onglet « Sécurité » Partie « Listes noires et blanches » : Paramétrez ou non ces listes selon vos éventuels besoins spécifiques. Partie « Stratégie de l’expéditeur » : Ici on va définir certains critères (appelés aussi « politiques ») pour rejeter les eMAILs reçus. Lorsque le nom de domaine de l'expéditeur « MAIL FROM » ne correspondra pas au format FQDN standard fixé par les RFC, les eMAILs seront rejetés. Cochez la case : « Rejeter les expéditeurs sans nom de domaine complet (FQDN) ». Lorsque « MPS » n'est pas le terminal de réception final et que le domaine de l'expéditeur de « MAIL FROM » ne correspond à aucun enregistrement DNS de type « A » ou « MX » ou lorsque l'enregistrement de type « MX » est incorrect, les eMAILs seront rejetés. Cochez la case : « Rejeter les expéditeurs utilisant des domaines inconnus ». Partie « Stratégie de connexion » : Ici on va paramétrer les critères pour rejeter les connexions client ou bloquer les adresses IP en raison d’un trop grand nombre de connexions simultanées, de messages envoyés sur une minute ou de connexions sur une minute au server de messagerie. Cochez la case : « Rejeter les noms d’hôtes de clients inconnus ». Cochez ou non les trois cases suivantes et ajustez les valeurs limites selon vos éventuels besoins spécifiques. Partie « Avancé » : Ici on va ajuster les paramètres de sécurité pour la distribution des eMAILs. Cochez la case : « Rejeter les demandes de conduite non autorisée ». Cochez la case : « Rejeter les noms d’hôtes HELO sans nom de domaine entièrement qualifiés (FQDN) ». Cochez la case : « Rejeter les noms d’hôtes HELO inconnus ». Cochez ou non les deux cases suivantes et ajustez les valeurs limites selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6 Section « Sécurité » Cette section est l’une des plus importante pour la mise en place d’une stratégie de sécurisation de votre serveur de messagerie et de ses clients. Toutefois, il convient d’être prudent et de ne pas tout activer immédiatement mais plutôt de procéder par étapes pour obtenir des réglages parfaitement ajustés à vos besoins spécifiques. En effet, des réglages d’emblée trop agressifs pourraient peut-être vous empêcher d’envoyer ou de recevoir des eMAILs de certaines personnes. Ce serait bien dommage et ce n’est pas le but de votre serveur de messagerie … On va donc ici n’activer qu’un minimum de règles d’analyses de vos eMAILs entrants. 5.6.1 Onglet « Spam » Donc à minima on va commencer par activer le moteur anti-spam. Pour mémoire, « MPS » utilise le moteur anti-spam « Rspamd » ainsi que les règles de la base de données « SpamAssassin ». Il filtre le spam en fonction de règles de correspondance du contenu et du seuil de score de spam. Lorsqu'un eMAIL correspond à une règle de détection prédéfinie, un point sera ajouté au score. Les eMAILs dépassant le seuil seront alors marqués comme « spam ». Cochez la case : « Activer le moteur anti-spam (recommandé) ». Modifiez l’intervalle de spam (en jours) ainsi que les paramètres anti-spam selon vos besoins spécifiques. Vous pouvez notamment utiliser « l’auto apprentissage » pour ajuster au mieux le seuil de score de spam. Lors de votre première activation du moteur anti-spam, la base de données des règles anti-spam a besoin d’être mise à jour manuellement. Programmez ensuite sa mise à jour automatique à l’heure de votre choix. Cochez la case : « Automatiquement mettre à jour les règles anti-spam ». Cliquez sur le bouton « Mise à jour manuelle ». L’encart « Information du le moteur » vous affichera par la suite la date de dernière mise à jour. Dans la lutte contre le SPAM il peut être aussi intéressant d’activer la protection postscreen en consultant des serveurs « DNSBL » (« DNS Black Listing ») même si ces derniers sont controversés du fait que leurs critères d’exclusion ne relèvent que de leur seul gestionnaire. Pour mémoire le « DNSBL » est une méthode permettant de consulter une liste noire d'émetteurs d’eMAILs en utilisant le protocole DNS. Aussi soyez vigilant avec l’usage de ce type de serveurs qui peuvent très bien, indépendamment de vous protéger, placer votre serveur de messagerie sur leur liste noire (vous blacklister) et donc vous empêcher d’émettre mais aussi de recevoir des eMAILs. C’est un choix donc à faire de façon très réfléchie. Encore une fois c’est vous qui voyez … Cochez la case : « Activer la protection postscreen contre les spam » et observez le comportement dans le temps et selon, décochez-la si nécessaire ensuite. Cochez ou non la case « Activer la liste grise … » selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.2 Onglet « Antivirus » Partie « Antivirus » : Il va de soi qu’il faut activer le moteur antivirus pour assurer une protection contre les menaces de logiciels malveillants qui auraient été introduits insidieusement dans les eMAILS que vous recevez. Cochez la case : « Activer le moteur antivirus ». Sélectionnez un moteur dans le popup. Pour votre information, « ClamAV » est le système antivirus par défaut de « MPS » et en plus il est gratuit contrairement à « McAfee » qui lui est payant et pour le quel il faut souscrire un abonnement. Le moteur antivirus « ClamAV » utilise des bases de données externes pour améliorer certaines fonctions. Si vous disposez de suffisamment de mémoire installée sur votre NAS, vous pourrez utiliser sans problème la base de données « Google SafeBrowsing » afin de détecter si vos eMAILs contiennent des liens malveillants. Notez qu’il vous est aussi possible d’utiliser d’autres bases de données du même type. Cochez ou non la case « Utiliser la base de données Google SafeBrowsing » selon la capacité mémoire de votre NAS. Lors de votre première activation du moteur antivirus, la base de données des définitions de virus a besoin d’être mise à jour manuellement. Programmez ensuite sa mise à jour automatique à l’heure de votre choix. Cochez la case : « Mettre à jour automatiquement les définitions de virus ». Cliquez sur le bouton « Mise à jour du manuel ». L’encart « Informations système sur le moteur antivirus » vous affichera par la suite la date de dernière mise à jour. Partie « Actions » : Paramétrez ou non ces actions selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.3 Onglet « Authentification » Le paramétrage de cet onglet a déjà été effectué et décrit au § 3 ci-dessus lors de la pré configuration de « MPS ». Il n’y a donc à faire de plus. 5.6.4 Onglet « Analyser le contenu » Partie « Filtre joint » : · Paramétrez ou non ces filtres selon vos éventuels besoins spécifiques. Partie « Analyser le contenu » : Là c’est évident et on n’y va pas par quatre chemins, à moins que vous ne voyiez un inconvénient à cela et donc libre à vous de faire autrement : Cochez les cases de toutes les options. Positionnez tous les popup sur la valeur « Rejeter ». Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.5 Onglet « Protection des données » Paramétrez ou non ces options selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.7 Section « File » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de vérifier tous les eMAILs en attente d'être envoyés à d'autres serveurs, ou à renvoyer à d'autres serveurs après qu’ils aient été rejetés pour X raisons. 5.8 Section « Audit en cours » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de visualiser et configurer tous les journaux d’activité de votre serveur de messagerie. Vous y verrez tous les mails passant par votre serveur. Ces journaux vous permettront de comprendre les éventuels problèmes que vous pourriez rencontrer et ainsi de leurs trouver une solution. Vous pourrez également y générer, selon vos besoins, des rapports statistiques d’utilisation du serveur « MPS ». 5.9 Section « Licence » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de visualiser le nombre de licences i.e. le nombre d’@MAILs que vous pouvez utiliser. C’est dans cette section que vous pourrez ajouter des licences supplémentaires le cas échéant. Par défaut vous y retrouvez les cinq (5) licences gratuites associées à « MPS ». « MPS » synchronise automatiquement l'état de vos licences avec votre compte Synology. Sachez aussi les restrictions/contraintes liées à l’usage de ces clés : Une clé de licence ne peut être appliquée qu’à un seul serveur DSM à la fois. Une clé de licence ne peut être distribuée ni fournie à un tiers. Si la clé de licence n’est pas activée et qu’elle est perdue, Synology ne vous fournira aucune clé de rechange. La clé de licence et les informations de votre NAS (N° de série, @MAC et nom de modèle) sont envoyées à Synology pour validation. 5.10 Section « Compte » Avant d’utiliser pleinement « MPS », vous devez activer les comptes utilisateurs locaux à DSM qui utiliseront votre service de messagerie. Mais avant, il est nécessaire de leur donner au préalable un certain nombre de droits sur les applications « MPS » et « MailPlus », mais aussi sur le répertoire partagé qui contiendra vos boites MAIL (« Volume1/MailPlus »), faute de quoi votre utilisateur ne pourra ni envoyer ni recevoir de MAILs : Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Utilisateur ». Créez un nouvel utilisateur OU sélectionnez et modifiez un utilisateur existant (pour l’exemple ici « oracle7 »). Dans l’onglet « Permissions », dans la colonne « Lecture/écriture » cochez la case en regard correspondante de « MailPlus ». Cliquez sur le bouton « OK » pour sauvegarder vos choix. Dans l’onglet « Applications », dans la colonne « Autoriser » cochez la case en regard correspondante à « MPS » et celle correspondante à « MailPLus ». Cliquez sur le bouton « OK » pour sauvegarder vos choix. On peut maintenant effectivement activer l’utilisateur. Pour cela : Rendez-vous dans « MPS » section « Compte » onglet « Utilisateur ». Dans la colonne « Activer » cochez la case en regard correspondante de votre utilisateur. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. Reproduisez la présente procédure pour chacun de vos utilisateurs en veillant bien à ne pas configurer plus d’utilisateurs que vous ne disposez de licences valides. De toutes façons, si vous dépassez le nombre d’utilisateurs possibles, les opérations de l'interface utilisateur de « MPS » seront restreintes et les services relatifs à la sécurité stoppés, tant que vous n'aurez pas suffisamment de clés de licence valides dans votre système de messagerie. Eh eh, ils ne sont pas idiots chez Synology … 😊 Nota : En matière de sécurité des comptes utilisateurs de « MPS », je vous renvoie vers le Tutoriel « [TUTO] MailPlus Server DSM6 » de @UnPixel qui propose une stratégie très intéressante (couplet en bleu dans le texte). Je ne vais pas vous la décrire ici mais je vous invite à la consulter voire même de l’appliquer. Pour mémoire, pour le présent tutoriel j’ai joué la carte de la simplicité en adoptant le même nom (identifiant) pour le compte eMAIL que celui-ci utilisé pour l’utilisateur local du NAS. A vous de voir et d’adapter le paramétrage des utilisateurs selon vos besoins spécifiques … Par ailleurs, si vous appliquez cette stratégie, veillez à rester cohérent avec les dispositions décrites au §4.1 ci-dessus pour la création d’une @MAIL dite de secours chez OVH. Sinon cela marchera beaucoup moins bien … 5.11 Section « Personnel » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de paramétrer les options liées au transfert d’eMAILs et de réponse automatique lors de la réception de ces deniers. 6 Configuration du pare-feu du NAS et de la Box/Routeur Encore une dernière chose à paramétrer et on en aura terminé pour la configuration. En effet, pour que tous ce qui précède fonctionne correctement sans blocages, il est nécessaire d’ouvrir les ports de communication adéquats sur votre NAS ainsi que sur la Box/Routeur. Vous l’aurez sûrement deviné et compris, il s’agit d’ouvrir respectivement des ports 25 (« SMTP »), 587 (« SMPTP-TLS ») et 993 (« IMAP SSL/TLS »). Pour cela : 6.1 Pare-feu du NAS Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Sécurité / Pare-feu ». Sélectionnez votre profil actif de pare-feu et cliquez sur le bouton « Modifier les règles ». Normalement, avec l’installation de « MPS » une règle intitulée « MailPlus Server » a déjà été créée dans le pare-feu. Sélectionnez cette règle et cliquez sur le bouton « Modifier » ou 2xCliquez sur celle-ci. Dans la nouvelle fenêtre, pour la partie « Ports », cliquez sur le bouton « Sélectionner » en regard de l’item « Sélectionner dans une liste d’applications intégrées ». Assurez-vous que les lignes correspondantes des ports 25, 587 et 993 pour l’application « MPS » sont bien activées (case cochée). Nota : Si vous utilisez un autre client MAIL que « MailPlus », et que celui-ci utilise le protocole « POP3 » pour récupérer les eMAILS, il vous faudra sans doute activer aussi les lignes correspondantes pour les ports 110 (« POP3 ») et 995 (« POP3 SSL/TLS »). Référez-vous au manuel de ce client MAIL pour plus de détails. Cliquez sur le bouton « OK » pour sauvegarder vos choix. 6.2 Pare-feu de la Box/Routeur 6.2.1 Cas de la LiveBox Si votre NAS est directement connecté derrière votre LiveBox : Connectez-vous à l’interface d’administration de la LiveBox en saisissant dans un navigateur Web l’URL : http://192.168.1.1. Rendez-vous dans le menu « Réseau » / onglet « NAT/PAT » et créez les trois (3) règles de transfert de ports suivantes : 6.2.2 Cas d’un routeur Synology Si votre NAS est directement connecté derrière votre Routeur Synology : Connectez-vous à l’interface d’administration du routeur en saisissant dans un navigateur Web l’URL : http://routeur.synology.com ou en saisissant directement son @IP comme URL. Rendez-vous dans le menu « Centre réseau » / Section « Transmission de port » et créez les trois (3) règles de transmission de ports suivantes : Nota : On ne crée pas ces règles directement dans le pare-feu car il n’y a pas besoin de leur affecter une quelconque localisation. 7 Configurer le Reverse Proxy sur le NAS C’est la dernière opération de configuration mais qui reste optionnelle (d’autant plus si vous n’avez pas déjà configuré votre Reverse proxy). On va donc ici configurer une redirection du domaine de second rang « mail.votredomaine.tld » vers l’application « MailPlus ». Ainsi depuis l’extérieur, il vous sera facile d’accéder à cette l’application pour consulter et gérer tous vos eMAILs et ce à partir d’un navigateur Web en saisissant simplement : « mail.votredomaine.tld ». Pour ce faire, suivez ces deux étapes : 7.1 Configurer la zone DNS chez OVH Cette opération est décrite au § 4.2.6 ci-dessus. 7.2 Configurer le Reverse Proxy sur le NAS Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Portail des applications » o Rendez-vous sur l’onglet « Application ». o Sélectionner la ligne « MailPlus » et 2xCliquez sur celle-ci OU Cliquez sur le bouton « Modifier ». o Une fenêtre « Règles d’accès aux applications » s’ouvre. o Dans l’onglet « Général » : ▪ Cochez la case « Activer un alias personnalisé ». ▪ Cochez la case « Activer un port personnalisé (HTTP) ». ▪ Saisissez les informations suivantes : * « Alias: » : mail * « Port: » : 21680 ▪ Dans les deux cas une URL de connexion à utiliser vous est indiquée. Respectivement : * https://votreNAS.votredomaine.tld/mail/ * http://votreNAS.votredomaine.tld:21680 o Cliquez sur « OK » pour valider. Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Portail des applications / Application ». o Rendez-vous sur l’onglet « Proxy inversé ». o Cliquez sur le bouton « Créer » o Une fenêtre « Règles de proxy inversé » s’ouvre. o Dans l’onglet « Général » : ▪ Saisissez les informations suivantes : ⚠Saisissez bien les informations, les champs paraissent déjà renseignés mais en fait ce n’est que de l’affichage ! Si vous validez sans faire de saisie effective, ces champs ne seront pas renseignés. * « Description: » : MAIL Partie « Source » : * « Protocole: » : sélectionnez dans le popup l’item « HTTPS » * « Nom d’hôte: » : mail.votredomaine.tld * « Port: » : 443 * Cochez la case « Activer HTTP/2 ». Partie « Destination » : * « Protocole: » : sélectionnez dans le popup l’item « HTTP » * « Nom d’hôte: » : localhost * « Port: » : 21680 o Cliquez sur « OK » pour valider. 8 Contrôle des eMAILs de votre serveur de messagerie Votre serveur de messagerie basé sur « MPS » est maintenant configuré et opérationnel. On va donc contrôler que les eMAILs que vous allez envoyer sont corrects et qu’ils ne risquent pas d’être considérés comme du SPAM par les serveurs de messagerie institutionnels. On contrôlera également la bonne réception des eMAILs qui vous seront destinés. 8.1 Contrôle de l’envoi Pour réaliser ce contrôle d’indésirabilité de vos eMAILs, on va utiliser les services du site « mail-tester.com ». Mais avant d’utiliser les services de ce site, il vous faut savoir ceci : « Mail-tester.com » ne vous offre en tout et pour tout, le droit d’exécuter que trois (3) tests par jour. Au-delà, si vous voulez en faire plus, il vous faudra passer à la caisse ! Donc soyez parcimonieux dans son usage sinon il vous faudra prendre votre mal en patience pour rester dans le domaine du gratuit … Donc, pour tester vos eMAILs, c’est on ne peut plus simple : Copiez l‘URL qui vous est proposée en page d’accueil de « mail-tester.com ». Rendez-vous sur l’application « MailPlus » et ouvrez celle-ci depuis le bureau de DSM sur le NAS ou si vous avez mis en place le reverse proxy : tapez l’URL « mail.votredomaine.tld » dans un navigateur Web sur votre PC/Mac. Cliquez sur le bouton « Rédiger » pour créer un nouvel eMAIL. Collez l’URL de test dans la zone « A : » Saisissez un texte quelconque pour l’objet de l’eMAIL. Veillez à ne pas être trop succinct car cela pourrait affecter votre note finale. Saisissez un texte consistant dans le corps de texte de l’eMAIL. Idem veillez à ne pas être trop succinct car cela pourrait aussi affecter votre note finale. Cliquez sur le bouton « Envoyer ». Revenez sur la page de « mail-tester.com » dans votre navigateur Web. Attendez 2 à 3 secondes (le temps que l'eMAIL arrive) et cliquez sur le bouton « Ensuite, vérifier votre Score ». Et là c’est tout bon ou tout mauvais … Le résultat des différents tests réalisés par « mail-tester.com » sur votre eMAIL s’affichent avec votre note obtenue. Si vous avez suivi correctement le paramétrage que je vous ai indiqué au cours du présent tutoriel, vous devriez normalement obtenir une note de 10/10. Si ce n’est pas le cas, c’est que vous avez raté quelque chose quelque part ! A vous d’analyser le problème … Heureusement pour vous, le compte-rendu produit par « mail-tester.com » est très explicite et très bien fait. L’analyse attentive de ce compte-rendu (développez chaque item pour en consulter le détail) devrait vous donner toutes les pistes à suivre pour corriger les problèmes relevés. Cela dit, même avec une note de 10/10, tout ne sera pas passé au « vert ». Il restera certains contrôles marqués en « orange » mais qui ne sont pas bloquants pour la suite. Typiquement, le compte-rendu vous annoncera que : « Vous n’êtes pas parfaitement authentifié » « Votre message pourrait être amélioré » Donc si vous développez chacun de ces deux items pour de plus amples détails, vous constaterez : Pour le premier Item : « Votre reverse DNS ne correspond pas avec votre domaine d’envoi » : Comme je vous l’ai expliqué au point 3 ci-dessus du préambule, il faudrait pouvoir paramétrer le « rDNS » d’Orange et c’est impossible. Donc, vis à vis de ce message d’« erreur » qui finalement n’impacte pas la note finale du test, on s’en tiendra là mais sans l’ignorer toutefois. Pour le second item : « Votre message ne contient pas d'en-tête List-Unsubscribe » : Je n’ai pas trouvé (peut-être mal cherché aussi) dans la documentation ni dans l’interface de « MPS » un quelconque moyen d’introduire cet « entête List-Unsubscribe » (à moins qu’un « Initié » ne sache). Donc, vis à vis de ce message d’« erreur » qui finalement n’impacte pas non plus la note finale du test, on s’en tiendra aussi là. 8.2 Contrôle de la réception Pour contrôler la réception de vos eMAILs, il suffit de demander à des personnes ayant un compte chez les principaux FAI institutionnels, de vous adresser un eMAIL (à « utilisateurprincipal@votredomaine.tld ») et de constater ou non la bonne réception de cet eMAIL. Dans le cas d’une non réception (ce qui serait tout de même étonnant si vous avez suivi correctement le présent tutoriel), vous pouvez toujours commencer par vérifier que votre serveur de messagerie n’est pas tout simplement quelque part sur liste noire. Pour cela, consultez notamment le site « spamhaus.org » en testant tour à tour votre « @IP externe » et votre « domaine.tld ». Vous saurez immédiatement si vous êtes ou non sur une liste noire quelque part. A vous alors, de vous rendre sur le site en question, pour trouver la procédure spécifique qui vous fera faire sortir de leur liste noire. ⚠Pour être totalement honnête, il vous faut savoir qu’il se produit parfois d’une façon encore inexpliquée à la date de la présente rédaction, une activation des serveurs de secours d’OVH que je qualifierai d’intempestive. Cette « anomalie », ayant été récemment relevée par quelques « initiés », a pour conséquence que les eMAILS, ayant pour origine certains FAI, ne sont pas récupérés sur la boite MAIL de votre utilisateur « principal » par votre serveur de messagerie. Rassurez-vous, ces eMAILs qui vous étaient destinés, ne sont pas perdus ! Les serveurs d’OVH que l’on utilise normalement en secours, ont simplement pris la main et ont redirigé ces eMAILS vers la boîte MAIL dite de secours que l’on a configurée à cet effet chez OVH (comme quoi cette fonction de secours que l’on a mise en place, fonctionne bien !). Sachez que vous pourrez donc toujours consulter et gérer ces eMAILs, mais pour cela, il vous faudra vous connecter à votre compte OVH. Il est vrai que cela pourrait vite devenir une contrainte si l’on ne trouve pas une solution à ce problème (on y travaille …). Par ailleurs et bien heureusement, le problème ne concerne que quelques FAI (ce qui est étonnant, c’est que ce n’est pas forcément les mêmes FAI d'un utilisateur à l'autre), ce qui en soi, est un moindre mal et donc heureusement pas totalement bloquant, si je peux m’exprimer ainsi. J’espère toutefois que la connaissance de cette anomalie, ne « refroidira » pas certains dans leur volonté d’appliquer le présent tutoriel pour mettre en place leur propre serveur de messagerie. Forcément, une solution sera trouvée à terme … Voilà c’est fini ! Vous pouvez souffler. Cela a été un peu long mais avec un minimum d’attention cela ne devrait pas vous avoir posé de problèmes. Beaucoup d’explications vous ont été fournies à propos des différents concepts abordés. J’espère en cela ne pas avoir été trop confus mais surtout que vous aurez bien pris le temps de toutes les lire et de les assimiler ! J’estime personnellement que c’est un passage obligé pour que vous compreniez parfaitement ce que vous faites et à terme que vous maîtrisiez votre serveur de messagerie. Remplir les cases « bestialement » ne vous aurait rien apporté au bout du compte si ce n’est des messages d’erreurs et une sérieuse prise de tête pour les résoudre. C’est quelque part le prix à payer pour être vraiment autonome de ce point de vue. Maintenant vous êtes seul propriétaire de vos choix et décisions … Ce tutoriel n’est jamais qu’un guide pour vous aider à configurer « MPS », mais comme vous avez pu le constater, il vous laisse souvent et largement toute la latitude nécessaire pour répondre à vos propres besoins spécifiques. Sachez enfin que depuis que j’ai mis en place cette configuration (cela fait bientôt 3 mois), je n’ai eu à faire à AUCUN problème d’eMAIL spammé et/ou d’@IP blacklistée pour le serveur de MAILs. Je dispose donc, comme vous maintenant, de mon propre système de messagerie et cela en totale autonomie. Donc pour moi le but initial, de ce point de vue ainsi que sur l’aspect technique avec cette contrainte initiale d’@IP externe « dynamique », est atteint et c’est le plus important 😊😊😊 Le fichier « .pdf » de ce tutoriel : [TUTO] Configuration MailPlusServer avec une @IP dynamique_20200616.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Cordialement Oracle7😉

@Thierry94 Absolument, je suis tout à fait d'accord avec toi, ce serait bien de pouvoir tracer mais là je crains de ne pas être d'un grand secours sur ce point précis 😟. Il n' y a plus qu'à espérer qu'un membre de ce forum nous fournisse ce type d'explication. Peut-être qu'il faudrait poster sur le forum OVH pour expliquer le problème ? Ton avis ? Cordialement oracle7😉

@Thierry94 Merci de ta réponse. Effectivement passer par un autre client POP3 est une voie de contournement mais je trouve que cela complique les choses. Comme en plus, je suis en train d'écrire un futur tuto de configuration de "MailPlus Server" avec une @IP dynamique d'Orange, cela me gêne quelque part de conseiller ce type de solution aussi efficace soit-elle j'en conviens et ce malgré son inconvénient que tu évoques. Dans tous les cas, on ne me sortira pas de l'idée qu'il y a quand même un truc qui nous échappe. Il y a sûrement un paramétrage supplémentaire (par ex un filtre à faire sauter, je ne sais...) à faire chez OVH mais le quel ? pour avoir une réception totale. C'est ma conviction. Cordialement oracle7😉

@Thierry94 Bonjour, Comme toi avec les emails issus de GMAIL, eh bien moi maintenant ce sont les emails issus d'Orange qui restent bloqués sur les serveurs de secours d'OVH alors qu'il y a encore 8 jours je les recevais sans problème sur ma boite mail "MailPlus Server" (le MX de mon domaine a pour priorité 1 pourtant et 5, 10, 100 pour les serveurs de secours OVH - mx1, mx2 et mx3). Accessoirement, je n'ai aucun soucis en revanche pour l'émission d'emails. J'ai essayé de modifier la compatibilité "moderne" en "intermédiaire" sur le NAS, mais sans effet. Je vais peut-être dire une c... mais le TTL des MX peut-il avoir un impact ? (j'ai laissé la valeur par défaut soit : 0) As-tu de ton coté depuis, trouvé la cause de ce "blocage" en réception ? Cordialement oracle7😉

@TuringFan Bonjour, Ce n'est pas normal dans le sens où tu n'as pas réaffecté/configuré le certificat aux services qui doivent l'utiliser. Voir "Panneau de configuration / Sécurité / Certificat / Configurer". Donc peut-être pas de réinstallation complète à faire ... Enfin pas pour ce motif précis ! C'est justement le problème que l'on essaie de régler avec @Bruno78 pour automatiser de bout en bout la procédure. Après la génération du nouveau certificat celui-ci devient bien le certificat par défaut mais il faut encore intervenir MANUELLEMENT pour affecter ce certificat aux services qui l'utilisent (piège si je puis dire dans lequel tu est manifestement tombé 😪pourtant on en parle dans les commentaires ci-avant). Si c'est du NAS, de mémoire a priori non (sauf omission de ma part) mais est-ce vraiment utile ? Sauf si tu as fait tout un tas d'essais de configuration dans tous les sens alors peut-être que cela serait utile histoire effectivement de repartir sur une base saine maintenant que tu maîtrises aussi certains concepts. C'est juste du temps et pas mal de manipulations ... mais pas insurmontable avec un tant soit peu d'attention et de méthode. Cordialement oracle7😉

@Juan luis C'est sûr que mettre en place un routeur pour faire ce travail est une très bonne chose en soi (indépendamment du coût d'investissement), il peut même suppléer la box en faisant encore mieux le travail dévolu habituellement à celle-ci et ce avec bien plus de fonctions de paramétrage qu'elle, offrant ainsi une plus grande souplesse d'utilisation. Cela dit, n'oublies pas qu'un NAS est conçu pour fonctionner h24. Si tu l'arrêtes, tu n'auras plus accès à tes données et autres fonctionnalités bien utiles comme par exemple la surveillance vidéo de ta maison justement lorsque tu es absent, ce qui apporterait des preuves aux autorités les cas échéants. Mais c'est toi qui vois ... et puis on s'écarte du sujet initial et du problème de @Comess. Cordialement oracle7😉

@comess Bonjour, Pour activer un VPN sur ton NAS (pour sécuriser les connexions de l'extérieur vers le NAS et ton réseau local), il est impératif que tu commences déjà par sécuriser les accès "normaux" à ton NAS (voir le tuto idoine). Ensuite seulement, tu prolongeras cela avec un l'utilisation d'un nom de domaine associée à un serveur DNS et un reverse proxy ainsi ton utilisation du NAS sera grandement facilité. Le seul changement à tes habitudes résidera uniquement dans une plus grande simplicité de ta façon de te connecter. De plus, toutes tes connexions seront vraiment sécurisées. Par ailleurs, ces conditions étant remplies, la mise en place d'un VPN de type NordVPN pour sécuriser les connexions depuis ton NAS et/ou ton réseau local vers l'extérieur ne sera qu'un jeu d'enfant. Je ne peux que te conseiller de lire tranquillement déjà tous les tutos correspondants à ces fonctions pour bien en appréhender et maitriser le jargon des notions mises en oeuvre et tout cela complété par une recherche personnelle sur la toile pour de plus amples détails. Et là tu seras bien armé pour installer de façon sereine ces fonctions sur ton NAS. Cela te demandera certes un petit effort et investissement personnel, mais crois moi le jeu en vaut la chandelle car tu va ainsi découvrir d'autres facettes et possibilités offertes par ton NAS que tu n'imagines peut être même pas aujourd'hui ... Bonne lecture et n'hésites pas à revenir poser tes questions ici, il y aura toujours un membre pour te répondre 😀 Cordialement oracle7😀

@TuringFan Bonjour, Ok, alors je crois alors qu'il y a un bémol avec ton fichier "ca.cer", il a dû être endommagé pour x raisons. Pour le vérifier: avec WINSCP recherche dans "/usr/syno/etc/certificate/_archive" le dossier "XyzWTu" de ton dernier certificat (en principe le plus récent mais en tout cas celui qui est cohérent avec la date de génération du certificat) ouvre ce dossier et récupère sur ton PC une copie du fichier "chain.pem" qui s'y trouve. compare en visualisant en cote à cote ce fichier avec une copie du "ca.cer" pris dans "volume1/Certs/ndd.tld" pour t'assurer qu'ils sont en principe identiques dans leur contenu (mis à part d'éventuels caractères parasites invisibles qui pourraient s'y trouver) ensuite sur le PC tu renommes le fichier "chain.pem" en "ca.cer" puis refait un import dans le RT du certificat "ndd.tld.key", "ndd.tld.cer" et en fichier intermédiaire le "nouveau "ca.cer" Si cela passe alors BINGO ! Sinon là je sèche et je vais tout de même pas te dire de relancer une génération complète... Cordialement oracle7😉

@Juan luis Bonjour, Effectivement, je me suis mal exprimé, désolé. Ce que j'ai voulu dire en fait, c'est qu'il me paraît plus pertinent d'utiliser un nom de domaine pour se connecter que d'utiliser une URL de type QuickConnect. L'usage d'un nom de domaine, sous entend aussi l'usage derrière de mécanismes et/ou d'outils qui sont eux même sécurisés et/ou sécurisant pour la connexion. En quelque sorte c'est pour cela que je pense qu'il concoure indirectement à un premier niveau de sécurisation et d'autant plus que l'on vient encore par dessus rajouter l'usage d'un certificat pour ce domaine afin d'en garantir l'authenticité. Un autre exemple, est l'usage d'un reverse proxy sur le NAS, qui impose de passer par une liaison sécurisée HTTPS qui est elle-même écoutée sur le port 443 lui-même sécurisé avant que ne soit traduit le nom de domaine et que la connexion soit redirigée au bon endroit sur le NAS ou le réseau local. C'est donc aussi cet "empilement" de sécurité autour qui me fait dire (peut-être par erreur et/ou abus de langage) qu'un nom de domaine est sécurisant même si, et j'en conviens volontiers, le terme est un peu fort, mal adapté ou pas le bon tout simplement. Maintenant tu as raison pour verrouiller complétement les choses la meilleure solution c'est d'utiliser un VPN pour sécuriser la connexion. Cordialement oracle7😉

@PPJP Bonjour, Effectivement ce serait vraiment sympa de ta part car il ne nous manque pas grand chose manifestement pour avoir une procédure complète, de bout en bout, pour générer, renouveler et gérer sur nos NAS ce fameux certificat wilcard LE. Cordialement oracle7😉

@comess Bonjour, Désolé pour mon délai de réponse, j'ai pas mal d'affaires sur le feu en ce moment... En tout cas Merci, avec ta dernière réponse, c'est bien plus exploitable. Bon maintenant je crains que ton problème vienne en fait de ta connexion via QuickConnecct. Je te dis cela sous toutes réserves car je n'en suis pas sûr (ne pas hésiter à me corriger au besoin). Je peux me tromper mais j'ai l'impression que la connexion via Quickconnect semble faire abstraction du paramétrage du pare-feu dans le sens où ton @IP de départ ne serait pas en fait celle à ton arrivée sur le NAS puisque cette connexion directe au NAS repose sur un VPN. Ce qui expliquerait que tu arrives à te connecter malgré les réglages que tu as mis en place sur celui-ci pour bloquer cette @IP de départ. A confirmer par un expert de QuickConnect. Par ailleurs, tu verras/liras partout sur ce forum que l'utilisation de QuickConnect n'est pas du tout recommandée du point de vue sécurité parce que tout ton trafic (donc tes données) passe par les serveurs de Synology. A moins que tu ne leur fasses une totale confiance à ton niveau, saches que ce n'est pas le cas pour un nombre d'utilisateurs ici. Pour mémoire voici un extrait du tuto sur la sécurisation des accès écrit par un expert reconnu à propos de QuickConnect : A toi de voir et d'y réfléchir mais une solution bien plus sécuritaire pour toi serait de prendre un nom de domaine personnalisé (environ 10€ par an chez OVH par ex) et de configurer ton NAS (une fois les accès sécurisés) avec un serveur DNS et un reverse proxy . Les Tutos pour faire cela sont disponibles sur le forum et c'est relativement facile à faire. Ainsi tu pourrais de connecter en tapant simplement une URL du type "xxxxxx.mondomaine.tld" avec un "xxxxxx" correspondant à chacun de tes périphériques et/ou applications/services de ton NAS. Cordialement oracle7😀

@bruno78 Bonjour, Je viens de re balayer le Tuto de UnPixel, aux pages 6-7 il évoque bien le même problème de non prise en compte du certificat que tu cites. Mais il n'indique pas vraiment de solution palliative. En plus ce n'est pas clair car ensuite il dit que le problème est réglé mais rien de plus. Par ailleurs, quand on observe le contenu du répertoire "/usr/syno/etc/certificate" on y trouve aussi un répertoire "system/default" qui contient les fichiers du certificat mais au format ".pem". Finalement je me demande s'il n'y aurait pas un lien entre ces fichiers et le problème que tu évoques. De plus je ne saurais dire à quoi correspondent ces fichiers ".pem" vu qu'ils sont cryptés : l'ancien ou le nouveau certificat par défaut ? Une autre piste à regarder : il semblerait que les fichiers du certificat soient aussi dupliqués dans tous les répertoires inclus dans le répertoire ""/usr/syno/etc/certificate/ReverseProxy". Du coup en plus de modifier les fichiers INFO et DEFAULT, ne faudrait-il pas faire une conversion des fichiers du certificat (".key', ".cert", etc ...) en ".pem" et les recopiier par remplacement dans chacun des dossiers du répertoire "ReverseProxy" suscité ? Ton avis STP ? Cordialement oracle7😀

@TuringFan Bonjour, C'est une belle colle que tu me poses là. J'avoue ne pas trop savoir. Pour ma part j'avais procédé comme je te l'ai indiqué précédemment en important les 3 fichiers issus de la génération. Force est de constaté que je n'ai pas rencontré les problèmes que tu évoques. Du coup je suis un peu sec pour te répondre. A tout hasard, as-tu essayé d'arrêter proprement le RT, de le débrancher électriquement, attendre au moins une minute et de le redémarrer tout aussi proprement, histoire que tous les caches mémoire soient bien vidés. Ensuite, tu réimportes les trois fichiers du certificat . Cela ce coûte rien d'essayer et peut être que ... Cordialement oracle7😉

@comess Ne le prends pas mal mais ce serait bien que tu sois STP plus explicite dans tes réponses car il faut deviner ce qui se cache derrière et cela ne facilite pas les choses pour t'aider. Par ex tu dis "ai fixé l'adresse ip de mon PC à ...88" : je crois comprendre que tu as défini un bail statique sur cette @IP dans ta box. Mais cela pourrait être une chose façon d'attribuer une @IP, l'impact de l'une ou l'autre peut être bien différent selon ... Comprends-tu ? En tout cas, pour bien comprendre ce qui se passe et pourquoi le blocage pare-feu mis en place n'est pas effectif, il faut que tu me dises aussi STP : Comment tu te connectes ? via un navigateur Web, une application client spécifique , etc ... Si c'est un navigateur Web, qu'est-ce que tu tapes précisément comme URL de connexion sur ton PC et/ou Tél ? Si tu es gênè du point de vue sécurité, dans ta réponse remplace l'@IP réelle par 1.2.3.4 si c'est ton @IP externe, pour les @IP locales que tu citerais, tu peux les laisser en clair car de toutes façon elles ne sont pas joignables hors de ton réseau local et si c'est ton domaine alors remplace le par "ndd.tld". Cordialement oracle7😉

@comess Je ne te dérange pas plus alors, on en reparle plus tard si tu as des questions ... Cordialement oracle7😉

@comess Ok donc tu es en DHCP sur la Livebox. Donc, c'est elle qui défini automatiquement l'@IP de ton PC, de ton NAS et de tous tes autres périphériques (bien évidemment s'ils sont configurés aussi en DHCP automatique comme ton PC). Alors en allant dans l'interface d'administration de la LB, dans "Mes équipements connectés" peux-tu regarder quelle @IP est affectée actuellement à ton PC ? Est-ce 192.168.1.28 ou pas ? Par ailleurs, dans ce cas il serait quand bien de figer au moins l'@IP de ton NAS par un bail statique dans la LB (dans Réseau / DHCP). Au moins tu seras ainsi sûr que ton NAS sera lui toujours à la même adresse et t'évitera ainsi des désagréments si par ex un reboot de la LB intervenait pour X raisons. En effet à cause du DHCP il pourrait y avoir une réaffectation totale ou partielle des @IP de tes périphériques. Cordialement oracle7😉

@comess Bonjour, Pourrais-tu STP préciser quelques points pour bien comprendre le contexte : As-tu un serveur DHCP d'activé et sur quoi ? ton NAS ou ta box ? L'@IP de ton PC est-elle fixe via un bail DHCP sur ta box ou l'as-tu fixée directement sur l'adaptateur réseau de ton PC (paramètres carte réseau) ? Est-tu sûr que l'@IP de ton téléphone n'a pas changé entre temps ? Par ailleurs, j'espère que ton pare-feu ne reste pas dans cet configuration (copie d'écran) en fonctionnement normal. Je ne peux que trop t'inviter à lire et à suivre le Tutoriel "[TUTO] Sécuriser les accès à son nas" sur le présent forum. Cordialement oracle7😉