Un domaine sur deux yunohosts?

Bonjour,
Je gère plusieurs instances yunohost. Une chez moi, sur laquelle j’ai plusieurs mails, qui fonctionne très bien, et du fait que je sois le seul à l’utiliser, a un très bon score pour éviter les spams de tout genre. :slight_smile:

Et d’autres sur des VPS, plus puissants que mon ordi maison, et surtout qui peuvent ainsi tourner tout le temps sans risque de coupure, ce qui n’est pas le cas de mon instal maison.

Seulement je rencontre un problème : les VPS, de chez OVH en l’occurence, ont de très mauvais scores pour les mails. Il est fréquent de se faire blacklister, ou catégoriser spam, ce qui n’est pas du tout acceptable dans de nombreux cas.

Ma question est donc : est-il possible de gérer les adresses mails (en lesquelles j’ai confiance) depuis mon serveur maison, même si je laisse les sites de ces domaines sur le VPS ?

J’ai bien pensé créer un sous-domaine pour résoudre mon problème, mais quand on a un site pro, c’est bien que l’adresse mail corresponde.
L’idée serait donc de faire un enregistrement DNS des MX, DKIM, SPF, qui pointe vers un serveur, et l’enregistrement A et AAAA, … vers l’autre.

Je n’ai pas fait de test encore, je voulais savoir si d’autres s’étaient penchés dessus, etc.

Merci de vos retours ! :slight_smile:

1 Like

Bonjour
Bizarre j’ai un VPS chez OVH et un tres bon score / mail.
Je viens de vérifier : https://www.mail-tester.com/ et il me donne un 10/10
(sur mon domaine principal et les autres domaines rattachés)
Tu as bien configuré le reverseDNS ? Aussi important : les alias

  • abuse@domaine.ext
  • postmaster@domaine.ext
  • webmaster@domaine.ext

?

Bonjour Crusty,
Oui, moi aussi j’ai 10/10 à mail-tester, et tout est bien configuré, mais ça n’empêche pas Google de me mettre en spams. Je pense qu’avec le temps, le domaine sera mieux accepté, mais je connais un peu la chose pour me méfier de ce genre de raisonnement : parfois, juste pour un changement de filtre de leur part, on repasse en spam alors qu’on en était sorti, sans raison. Et il faut alors tout recommencer…

Le problème ne vient pas du paramétrage de mon serveur, mais de la mauvaise réputation que pourrait avoir l’IP ou la baie de serveur de ovh, je pense.

1 Like

En théorie ça ne devrait poser aucun problème d’avoir les mails sur un autre serveur que le reste. Je n’ai pas testé pour ma part, par contre. Sans doute que le diagnostique automatique de chaque yunohost te fera une remarque sur la “mauvaise configuration dns”.

Salut o/
Si ton YunoHost sur le VPS a des applications qui doivent envoyer des mails (newsletter, confirmation d’inscription…), il faudra que son IP soit présente dans l’enregistrement SPF également.
Quelque chose comme v=spf1 a mx ip:16.37.161.42 -all, en mettant l’IP public de ton VPS

Le diagnostique de Ynh va râler mais tu pourras ignorer l’erreur. :stuck_out_tongue:

Merci @Velocipede et @Tagada pour vos retours !
Oui, le diagnostique râlera, je lui fais confiance pour ça :smile:

Ok, je vais faire des tests, je reviendrai vous dire ce qu’il en est !

Dans le même cas de figure que toi (chez ovh avec 10/10 au test) je ne peux pas envoyer de mails à outlook.com alors que je gère ce serveur depuis déjà très longtemps. Je pense que j’ai des voisins indésirables dans la baie. Je serai intéressé par tes retours d’expérience.

Bon ben c’est fait, aucune difficulté, aucun problème :grinning:

Les diagnostiques râlent un peu, on les ignore. J’ai toujours 10/10 avec mail-tester, les quelques essais que j’ai fait envoient et reçoivent les mails sans soucis, même chez google, tout comme il faut.

Côté site, pas de problème non plus, je n’ai pas encore testé d’installer un vrai site, qui envoie des notifications, mais j’ai déjà mis en place la proposition de @Tagada :

Maintenant que je l’ai fait en mode test, je vais passer sur le vrai domaine, mais il n’y a aucune raison que ce soit plus compliqué :wink:

J’en profite pour faire un retour d’expérience sur les mails envoyés depuis les mxplans d’OVH :
J’utilise une boite mail du genre. Récemment, plusieurs fois dans la semaine, mes mails partaient mais n’arrivaient jamais. J’ai ouvert un ticket, et après déblocage 1, 2, 3, ils ont finis par créer un script de faux-positif. En fait, OVH écoute l’IP avec laquelle on envoie nos mails. En l’occurrence, tant que je les envoyais depuis mon IP fixe, aucun problème. Dès que je passais par un VPN, ce que je fais tout le temps, en fonction de l’IP du VPN, ils bloquaient. J’ai fini par faire en sorte que thunderbird contourne le VPN pour envoyer les mails sans soucis, mais c’est bon à savoir.

Je vais détailler un peu, sait-on jamais :
J’ai créé mon domaine chez ovh.
Dans le VPS où je ferai mon site, je l’ajoute, et construit la zone DNS en fonction des conseils de ce serveur. Je génère le certificat SSL.
Puis dans le serveur chez moi, j’ajoute le domaine. Je vais voir les recommandations DNS, et je change juste celles concernant les mails (mx qui pointe vers le nom du serveur maison, dkim, spf modifié)
je crée ensuite un utilisateur sur le serveur maison, qui a un mail avec le domaine fraichement installé. Je lui donne accès à roundcube, ajoute à son profile les alias abuse, postmaster, webmaster, admin liés au domaine.
je me connecte avec ce nouvel utilisateur, vais sur roundcube, valide l’adresse mail d’utilisation, et tout est ok.
Côté diagnostiques, je vais vérifier sur les deux serveurs qu’il n’y a pas d’autre problèmes que ceux escomptés, ignore ceux qui sont donnés pour le domaine en question, et tout est bon.

Arg je n’y pense que maintenant, mais il faut aussi un certificat correct sur ton YunoHost à la maison (celui qui sert pour les mails), sinon j’ai peur que ton serveur ne puisse pas recevoir de mail, et que tu ne puisses pas t’y connecter avec un client mail (style Thunderbird).
Actuellement, les certificats sont générés et renouvelés avec un HTTP-01 challenge, qui requiert donc que le champ DNS A (ou AAAA?) pointe vers le serveur qui veut un nouveau certificat :frowning:

Si si, tout se passe bien :slight_smile:

En fait, lorsque tu fais l’attribution MX, tu es obligé de choisir un domaine qui va gérer la réception et l’envoi de tes mails. en l’occurrence, j’ai attribué le domaine qui gère mon installation maison. (mais tu peux attribuer n’importe quel autre (sous-domaine) correctement installé sur cette instance, si tu préfères laisser secrète l’adresse du serveur).
j’ai donc domaine.fr. 3600 MX mon.serveur.fr, et en SPF domaine.fr. 3600 SPF "v=spf1 a mx ip4:l'ip de mon autre serveur -all".

En faisant comme ça, sur thunderbird, tu rentres comme serveur d’envoi et de réception mon.serveur.fr, tout marche. Si jamais thunderbird est un peu capricieux, genre il refuse d’enregistrer un serveur sortant différent du nom de domaine, il faut le laisser faire lors de l’installation, puis retourner une fois l’installation terminée dans les paramètres du compte, et modifier le serveur smtp sortant en remettant l’adresse mon.serveur.fr. Tout fonctionne, j’ai testé :wink:

Je parlais spécifiquement du certificat Let’s Encrypt qui est utilisé pour le chiffrement des connexions (TLS).
Je pense que tout se passe bien actuellement car ton certificat Let’s Encrypt était déjà installé avant ta manip’ et est toujours valide (ils sont valide 90 jours et renouvelé régulièrement).
Lors que celui-ci va expirer, tu risques de ne plus pouvoir consulter tes mails, ni envoyer de mail, ni en recevoir? À tester d’avantage je pense.

Pourquoi l’expiration du certificat courant (qui sera remplacé par un autre automatiquement) entrainerait-il l’arrêt des mails ? Le mien expirera dans 48 jours, je viendrai vous donner des nouvelles à ce moment-là :slight_smile:

A savoir que sur un de mes serveurs je fais déjà une manip du genre :
Le serveur est installé sur un sous-domaine, roundcube sur ce sous-domaine.fr/roundcube.
Les mails qui arrivent sur le domaine sont reçus par un utilisateur, créé sur ynh, c’est-à-dire sur le sous-domaine. Pour câbler thunderbird, je devais donc renseigner le sous-domaine comme serveur, et pas le domaine. Il se trouve que dans ce cas précis, le domaine est entièrement installé sur le serveur (donc a son propre certificat ssl), donc c’est peut-être différent. Mais je verrai aussi pour celui-là, dans 30 jours, comment ça se passe :slight_smile:

Merci pour les questionnements, je serai attentif !

Oh flûte, j’étais en train d’écrire un long message en remettant à plat ce que je pensais qui aller se passer et… j’ai arrêté parce que je crois que j’ai enfin compris ça :

En fait, lorsque tu fais l’attribution MX, tu es obligé de choisir un domaine qui va gérer la réception et l’envoi de tes mails. en l’occurrence, j’ai attribué le domaine qui gère mon installation maison. (mais tu peux attribuer n’importe quel autre (sous-domaine) correctement installé sur cette instance, si tu préfères laisser secrète l’adresse du serveur).
j’ai donc domaine.fr. 3600 MX mon.serveur.fr, et en SPF domaine.fr. 3600 SPF "v=spf1 a mx ip4:l'ip de mon autre serveur -all".

Donc en effet, si ça marche bien comme je le comprends, devrait pas y avoir de soucis o/

1 Like