We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

DKIM/exim4, dig, gmail, mail-tester,


foulweather
22/10/2016, 13h55
C'est fou, ces trucs !

cassiopee
22/10/2016, 13h40
Pour ce qui est signer par DKIM les messages sortants, regarde peut-être par là :

https://debian-administration.org/ar...ail_with_exim4

cassiopee
22/10/2016, 13h38
Oui, le NEUTRAL est normal car tu as mis un tilde dans ton SPF :

Code:
# dig -t txt tbr.ovh

tbr.ovh.		600	IN	TXT	"v=spf1 mx ~all"
alors que le mieux serait de mettre un signe "moins" : "v=spf1 mx -all"

Le tilde, c'est une sorte de "réponse de normand", c'est un "peut-être que oui, peut-être que non"
(pour ce qui est de l'autorisation à émettre des messages au nom du nom de domaine).

Alors que le "moins" est très explicite : seuls ceux qui sont explicitement autorisés le sont,
tous les autres ne le sont pas.

foulweather
22/10/2016, 09h57
Mes messages ne sont pas encore assez bons pour Gmail
SPF : NEUTRAL avec l'adresse IP 0.0.0.0 En savoir plus
qui me suggère d'ajouter un champ TXT dmarc du type :
_dmarc TXT "v=DMARC1; p=none; sp=none; rua=mailto:spam-reports@domain.com"
(domain.com étant bien sûr à remplacer par mon propre domaine.)
C'est comme cela que ça marche ? Ce n'est pas trop simple ?
D'autre part, les clés DKIM n'apparaissent pas dans les en-têtes.

cassiopee
21/10/2016, 21h04
J'ai vu plus de gens être emmerdés par un firewall faisant du zèle que de gens piratés parce qu'ils n'avaient pas de firewall
(dans un serveur dédié, pour un PC de particulier, c'est totalement différent)

Aucun des serveurs dont je m'occupe n'a de firewall (sauf un usage basique d'iptables pour bannir telle ou telle IP + fail2ban)
et il n'y a jamais eu de piratage pour autant (depuis 20 ans).

foulweather
21/10/2016, 19h49
Si je me souviens bien cette discussion sur l'utilité des pare-feu a déjà eu lieu à propos d'un post ancien. D'autres modérateurs n'étaient pas d'accord avec toi.
L'opinion courante pense malgré tout qu'il vaut mieux en avoir un et, dans ce cas, ce que je me suis laissé dire c'est qu'il fallait d'abord tout bloquer et n'ouvrir les ports nécessaires qu'au cas par cas.
Mon Kimsufi ne sert qu'à faire tourner Transmission-daemon. Pour le reste les bilans de santé envoyés par Logwatch et Rkhunter me suffisent. Il n'y a pas de données précieuses. Mes petits sites internet sont hébergés gratuitement par Free.
Ce que j'apprécie c'est d'apprendre des trucs Linux pour mieux utiliser mon desktop Debian au quotidien. Avec mon Kimsufi et le forum je crois que c'est le cas.

nowwhat
21/10/2016, 18h26
Citation Envoyé par foulweather
...... Mais une redirection à partir d'.ovh ne peut avoir lieu qu'avec les ports 110, 143, 993, 995, 1221, qui sont bloqués par mon pare-feu.
Ces portes "110, 143, 993, 995" sont des portes qu'un CLIENT mail utilise.
Ces portes, correct, doivent être ouvert ** sur ton serveur et un service POP (110 ou 995=SSL) ou IMAP (porte 143 ou 993=SSL) doit exister sur ton serveur.
C'est GMAIL, ou free.fr ou ton client mail comme Outlook sur ton PC, ou le client mail de ton smartphone qui av pouvoir relever tes mails.

Il est d’ailleurs totalement inutile de 'bloquer' des portes si t'as pas de service derrière ces portes qui écoutent.

Je présent de ce fait les règles parafeu de mon serveur =
=> Nada - zéro - aucun <=

Je risque quelque chose chose ? Noop. Car le type que va réussir à exécuter quelque chose sur mon serveur, explosera de toute toute façon le parafeu si ça lui gène ...

Citation Envoyé par foulweather
..
"Auth-result verifier port 25" les met en "neutral" et non en "pass" : je m'en contenterai.
Faut lui donner un peu de temps.
"Auth-result verifier port 25" a du demander le champs TXT qui parle de SPF dans ta zone.
Il va garder cette réponse (une requete DNS) en mémoire. Donc même si t'a changé ton champ TXT SPF, il va pas le savoir.

foulweather
21/10/2016, 17h28
Ce que je veux dire c'est que je prends bien en considération les appels à la prudence de Nowwhat et de Cassiopee. Je suis allé sur Gmail pour essayer de faire ce qu'il ma été conseillé de faire, et que je fais déjà avec free pour sauvegarder mes mails. Mais une redirection à partir d'.ovh ne peut avoir lieu qu'avec les ports 110, 143, 993, 995, 1221, qui sont bloqués par mon pare-feu.
J'ajouterai que je ne prévois pas d'autre usage d'exim que la redirection des mails système.
En tout cas cette fois, c'est bon. Mes messages sont correctement réceptionnés par Free et Gmail. Plus de "bounce" ni de "prevalence = bulk".
"Auth-result verifier port 25" les met en "neutral" et non en "pass" : je m'en contenterai.
Petit à petit j'apprends ici des choses, mieux qu'avec un manuel.
Merci aux modérateurs du forum Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 16h49
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57, puis la réponse de Cassiopee). Modestement j'ajouterai que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Je viens tout juste d'aller dans les paramètres pour tenter une redirection de utilisateur@tbr.ovh vers gmail. Ceci ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.
(@Cassipee je ne prévois pas d'autre usage pour l'envoi de mails que de faire suivre les messages système)

-----
En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 16h42
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57, puis la réponse de Cassiopee). Modestement j'ajouterai que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Je viens tout juste d'aller dans les paramètres pour tenter une redirection de email]utilisateur@tbr.ovh vers gmail. Ceci ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.
( A Cassipee je ne prévois pas d'autre usage pour l'envoi de mails que de faire suivre les messages système)

-----
En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 15h58
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57, puis la réponse de Cassiopee). Modestement j'ajouterai toutefois que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Je viens tout juste d'aller dans les paramètres pour tenter une redirection de utilisateur@tbr.ovh vers gmail. Cela ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.

-----

En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 15h38
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57). Modestement j'ajouterai toutefois que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Je viens tout juste d'aller dans les paramètres pour tenter une redirection de utilisateur@tbr.ovh vers gmail. Ceci ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.

-----

En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

cassiopee
21/10/2016, 15h15
D'accord mais, dans la pratique, on ne peut guère ne faire qu'envoyer des messages (*).

Déjà il faut bien être capable de faire quelque chose si le serveur SMTP de destination répond autre chose
"d'accord, j'accepte le message" (boîte aux lettres du destinataire qui est pleine, adresse email du destinataire
incorrecte, le serveur SMTP de destination qui a un problème, etc.), il y aura un flux d'information
en retour, généralement sous la forme d'un email de type bounce.

Ensuite, de plus en plus de serveurs SMTP de destination vont exiger que le nom de domaine d'émission
ait un enregistrement MX (et donc un serveur SMTP capable de recevoir) afin d'accepter un message.
Ou encore qu'à défaut de SPF, les messages ne soient émis qu'à travers le serveur indiqué en tant que MX.

Par ailleurs, il me semble que foulweather parlait de faire suivre les messages reçus sur "toto@tbr.ovh"
vers "toto@gmail.com" et donc pour ça, il faudra bien la capacité de recevoir des emails.

On pourrait imaginer recevoir les emails via un "MX Plan" d'OVH mais bon, c'est un tout autre scénario.
Quand on a un serveur dédié qui ne gère qu'un seul nom de domaine, autant l'utiliser comme serveur SMTP.

Perso, je n'ai rien contre Exim4, simplement j'utilise Postfix, c'est tout.

Code:
include:mx.ovh.com
dans le SPF n'est utile que et uniquement si on utilise un serveur d'OVH (= MX Plan, je ne parle pas d'un dédié ici)
pour émettre des messages, autrement, c'est inutile.

De la même façon, il est inutile de mettre "include:_spf.google.com" si on ne compte pas utiliser
les serveurs de Google afin d'émettre des messages pour le compte de son nom de domaine.

Même chose pour les serveurs de Free.


(*) ça peut s'envisager mais pour des cas particuliers. Par exemple, un système qui ne fait qu'émettre des messages système,
type monitoring ou équivalent. Et encore, dans ce cas là, on n'a même pas vraiment besoin d'un serveur SMTP.

foulweather
21/10/2016, 15h08
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57). Modestement j'ajouterai toutefois que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Je viens tout juste d'aller dans les paramètres pour tenter une redirection de utilisateur@tbr.ovh vers gmail. Ceci ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.

-----

En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 14h26
J'allais envoyer le message ci-dessous quand celui de Cassiopee est arrivé (et maintenant celui de Janus57) . Je vais bien sûr en tenir compte, Modestement j'ajouterai toutefois que pendant deux ans avant le remplacement du disque dur de mon kimsufi, j'ai utilisé la procédure "mails système -> free.fr -> gmail.com" sans ennui. Mais en suivant vos conseils je vais examiner l'opération inverse ("free.fr gmail.com -> mails sytème utilisateur@tbr.ovh").
Je viens tout juste d'aller dans les paramètres pour tenter une redirection de utilisateur@tbr.ovh vers gmail. Ceci ne peut se faire apparemment qu'avec les ports 110, 143, 993, 995, 1110, 1221 qui sont bloqués par mon pare-feu. C'est donc impossible.

-----

En tout cas cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

janus57
21/10/2016, 13h36
Bonjour,

pour info (et si je dit pas de conneries) il souhaite juste que son serveur soit capable d'envoyer (et non d'envoyer et recevoir), et c'est pour ça que dans un autre post je lui avais conseillé exim4, car en serveur d’envois il fait très bien son boulot et google accepte les mails à partir du moment ou le SPF est valide (déjà testé et cela passé sans aucun problème, même pas besoin de DKIM).

Du moment que le reverse + hostname du serveur sont correcte, que l'on a fait la configuration de exim4 après avoir mis le bon reverse/hostname exim4 est déjà configuré comme il faut, il faut alors juste rajouter l'enregistrement SPF.

Au niveau SPF j'utilise toujours :
Code:
v=spf1 mx a include:mx.ovh.com -all
Avec cette technique je peu avoir un VPS/Dédié avec exim4 qui envoie les mails systèmes + un MX Plan chez OVH (moins chiant à gérer que la réputation de son serveur, à condition de ne pas envoyer 5000 mails/jours).

Cordialement, janus57

foulweather
21/10/2016, 13h33
J'allais envoyer le message suivant quand le message de Cassiopee est arrivé. Je vais bien sûr en tenir compte, Modestement j'ajouterai toutefois que pendant deux avent le remplacement du disque dur de mon serveur chez OVH, j'ai utilisé la procédure "mails système -> free.fr, gmail.com" sans ennui. Mais en suivant vos conseils je vais examiner l'opération inverse ("free.fr gmail.com -> mails sytème @tbr.ovh").
------
Cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/exim4"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 13h23
J'allais poster le message suivant quand celui de Cassiopee est arrivé. Je vais bien sûr en tenir compte. Ce qui fait que ce post n'est peut-être pas terminé.
----
Cette fois, c'est bon.
Mes messages sont correctement réceptionnés par free et gmail. Plus de "bounce" ni "prevalence = bulk".
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass" : tant pis je m'en contenterai.
Il ne semble pas que tbr.ovh reçoive de mails de l'extérieur. J'ai vérifié dans les mails de root et de l'utilisateur. Je jetterai encore un coup d'oeil en n'oubliant pas "/var/log/exim4"
Petit à petit j'apprends ici des choses, mieux me semble-t-il qu'en utilisant un manuel.

Merci aux modérateurs du forum de Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.
----

cassiopee
21/10/2016, 13h17
Oui, si Google signale un souci (tout relatif, "neutral", ce n'est pas un drame) sur le SPF, c'est parce que
pour le moment le SPF actif pour ton nom de domaine ne contient pas ce que je t'avais indiqué

Comme le dit Nowwhat, il ne faut pas "faire suivre" les messages reçus dans "toto@tbr.ovh" vers "toto@free.fr"
ou encore "toto@gmail.com".

Tôt ou tard, tu recevras du spam sur "toto@tbr.ovh", spam que ton serveur essayera de faire suivre à Free ou à Gmail
et là eux ils vont bloquer le message. Au début, ce sera gentil mais si tu ne fais rien, ils finiront par blacklister
l'adresse IP de ton dédié et là tu ne recevras plus aucun message.

Si tu tiens à tout prix à lire tes messages dans l'interface de Gmail, y compris les messages reçus sur "toto@tbr.ovh",
c'est tout à fait possible : il suffit d'inverser le flux de lecture en quelque sorte.

Plutôt que de "faire suivre" les messages depuis ton serveur vers ta boite Gmail ou Free, il suffit de configurer
ta boîte Gmail pour que ce soit elle qui relève la boîté "toto@tbr.ovh".

Autrement dit dans ce contexte, c'est Gmail qui vient chercher dans ton serveur dédié tes messages
et non dans le sens inverse, ton serveur dédié qui viendrait déposer (faire suivre) les messages chez Gmail.

Concrètement, ça revient au même, tes messages reçus sur "toto@tbr.ovh" seront lisibles dans ton
interface Gmail, sauf que là, plus de problèmes de spams, blacklistage, etc.

Pour la configuration de la boîte sur Gmail dans ce sens, cf là :

https://support.google.com/mail/answer/21289?hl=fr

Concernant Exim4, je ne pourrais t'en dire beaucoup plus car je n'utilise pas ce logiciel (j'utilise Postfix).

Ceci dit, il ne faudrait pas utiliser "arthur.tbr.ovh" mais plutôt "mail.tbr.ovh" comme nom
afin d'être cohérent avec l'enregistrement DNS de type MX où l'on a indiqué "mail.tbr.ovh".

Pour le moment, tu ne peux pas encoyer de messages à destination d'une adresse email "toto@tbr.ovh"
car le serveur SMTP (Exim4) n'est pas à l'écoute dans ton serveur dédié :

Code:
# telnet 176.31.246.182 25

Trying 176.31.246.182...
telnet: Unable to connect to remote host: Connection refused
Vraisemblablement parce que sa configuration n'est pas encore tout à fait correcte
ou encore parce qu'il n'a pas été lancé.

foulweather
21/10/2016, 13h09
Cette fois, c'est bon.
Les messages envoyés par tbr.ovh sont correctement réceptionnés par free et gmail. Plus de "bouce" ni de "prevalence=bulk".
auth-results@verifier.port25.com les met en "neutral" et non en "pass" : je m'en contenterai.
J'ai vérifié si des mails parvenaient @tbr.ovh. Apparemment, non. Je jetterai encore un coup d'oeil dans les mails de l'utilisateur et dans les logs de /var/log/exim4.
Petit à petit j'apprends ici à faire des choses, mieux, me semble-t-il qu'avec un manuel.

Merci aux modérateurs du forum Kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

foulweather
21/10/2016, 13h00
Cette fois, c'est bon.
Plus de "bounce" de gmail ni de "prevalence=bulk". Les messages envoyés à partir de tbr.ovh sont correctement réceptionnés.
auth-results@verifier.port25.com les met en "neutral" et non pas en "pass", mais je ne pense pas qu'il faille s'y attarder..
J'ai vérifié encore une fois, je n'ai pas trouvé trace de messages vers @tbr.ovh. Je jetterai encore un coup d'oeil dans les mails de l'utilisateur, de root et dans les logs d'exim.
Petit à petit j'apprends ici des choses en les faisant, mieux, me semble-t-il qu'avec un manuel.

Merci aux modérateurs du forum kimsufi auprès de qui j'ai toujours trouvé une aide patiente et efficace.

nowwhat
21/10/2016, 11h55
[QUOTE=foulweather;198824]....
2 - gmail signale un problème de spf . Ce qui revient à dire, il me semble, que le spf est mal configuré. j'ai pourtant suivi les indications de Cassiopee. Pour moi, c'est là qu'il y a des choses à revoir. Gmail conseille la création d'un enregistrement TXT contenant le texte suivant : v=spf1 include:_spf.google.com ~all
Oui, Google a raison.
Et pas besoin que Google te le dise, t'as qu'à faire ceci :
Code:
dig tbr.ovh TXT +short
T'auras ça comme réponse :
Code:
...
"v=spf1 ~all"
Et ça, ça craint.
T'as a peu près désactivé toutes les avantages qu'offre SPF.

Google te propsoe
v=spf1 include:_spf.google.com ~all
mais c'est uniquement valable si tu utilise Google (gmail) pour envoyer des mails de la part de ton zone (domaine).

Un
Code:
"v=spf1 mx -all"
sera bien mieux, comme Cassiopée a proposé déjà plus haut.
Il suffit d'éditer le champs DNS concernant dns ta zone (utilise le Manager de ton domaine pour ça).

Citation Envoyé par foulweather
....
3 - Si à partir de ma messagerie free, j'essaie d'envoyer des messages vers @tbr.ovh, ça ne marche pas. Je trouve cela plutôt rassurant et il me semble que ce blocage invalide sans doute une bonne partie du #27 de Nowwhat ?
Je pense que ton serveur devrait recevoir ce mail. Pour le transmettre vers ton mail free.fr juste après.

foulweather
21/10/2016, 11h38
Je réfléchis sur les remarques de Nowwhat et sur la meilleure manière de les prendre en considération. Mais dans l'état actuel des choses, je constate que :
1 - Les message envoyés à partir de tbr.ovh n'ont plus de "prevalence = bulk" ni à free.fr ni à gmail.com. (Tous les messages que je reçois à free.fr sont automatiquement sauvegardés sur gmail.)
2 - gmail signale un problème de spf
SPF : NEUTRAL avec l'adresse IP 0.0.0.0
. Ce qui revient à dire, il me semble, que le spf est mal configuré. j'ai pourtant suivi les indications de Cassiopee. Pour moi, c'est là qu'il y a des choses à revoir. Gmail conseille la création d'un enregistrement TXT contenant le texte suivant : v=spf1 include:_spf.google.com ~all
3 - Si à partir de ma messagerie free, j'essaie d'envoyer des messages vers @tbr.ovh, ça ne marche pas. Je trouve cela plutôt rassurant et il me semble que ce blocage invalide sans doute une bonne partie du #27 de Nowwhat ?

nowwhat
21/10/2016, 00h53
Ceci :
Citation Envoyé par foulweather
.....
j'ajouterai que je n'entends pas recevoir du courrier à tbr.ovh mais seulement faire parvenir les messages système à mon adresse @free.fr.
ne fait pas ça !!
Ça implique que tout les mails que tu va recevoir seront relayer vers ton mail chez free.fr.
Très utile et pratique - mais cette fonctionnalité fait partie du passé : c'est trop dangereux maintenant.
SI tu désire regrouper tes mails chez free.fr, va voir dans leur/ton interface (chez Free) si t'as la possibilité que ton compte mail free récupère les mails sur ton serveur (un peu comme un client mail). gmail possède cette fonctionnalité depuis longtemps. Mon FAI, Orange, le propose.
Sinon, informe ton client mail (si t'en a une) qu'il ramasse les mails, présent dans tes boites mails sur ton serveur. C'est beaucoup plus sur.

Pourquoi : le jour qu'un rigolo t'adresse quelques centaines des mails pur-spam, et ton filtre spam sur ton serveur les laisse passer, il va tous l'envoyer vers ton mail chez free.fr.
Le résultat va frapper double :
1) OVH(KS) va bloquer la possibilité d’émettre des mails.
2) free.fr va blacklister l'IP de ton serveur. T'as pas d'autres IP's (car t'as un KS) : t'es mal.

Donc : uniquement si t'es un as de filtrage des spam (avec ton serveur) : n'utilise PAS ce système 'smartrelay'. Utilise le type serveur mail "internet" qui implique que tes boites mails seront gardés localement, sur le serveur . En suite, à ta de le consulter avec un webmail (comme Squirrelmail ou Roundcube) que tu installe sur ton serveur (il s'agit d'un simple CMS écrit très souvent avec PHP).
Ou : installe l'accès IMAP et/ou POP pour que ton client mail (Outlook, Thunderbird, ton smartphone) les récupère.

foulweather
20/10/2016, 17h55
Je vous remercie pour votre patience. Je ne suis qu'un littéraire de formation qui s'aventure dans un domaine qui n'est pas le sien et pour lequel il n'a jamais été formé.

(Les "<-" correspondent à mes remarques ou mes questions)

1 - "v=spf1 mx -all"
<- fait

2 - La question pour moi est de savoir ce que je doit mettre dans :
/etc/exim4/passwd.client.
Le fichier indique ceci :
# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:loginassword
<- ?


3 - /etc/aliases
Ce fichier contient à la fin
root: user, prénom.nom@free.fr
user: user, prénom.nom@free.fr
<- Est-ce corect ?

4 - /etc/email-addresses
root: prénom.nom@free.fr
user: prénom.nom@free.fr
<- Est-ce corect ?


5 - Mêmes questions pour la configuration de exim4 dans : dpkg-reconfigure exim4-config
Je me suis largement inspiré de : https://www.debian-fr.org/t/configur...s-sa-bal/29512 et de : https://www.medlibre.fr/index.php/po...tre-boite-mail

"dpkg-reconfigure exim4-config" :

1/ Type de configuration : choisissez la deuxième ligne
" Envoi via relais ("smarthost") -réception SMTP ou fetchmail "
<- ma configuration précédente marchait très bien avec "internet" au lieu de "smarthost"
Mais je ne sais pas du tout ce qu'il convient de mettre. Qu'est-ce qu'un "smarthost" ?

2/
Nom de courriel du système : entrez le nom de la machine, suivi du nom de domaine, en fait, le résultat de la commande ' $ hostname -f ' (souvent préinscrit)
" machine.domaine.extension "
<- arthur.tbr.ovh devrait être correct.

3/
Liste d'adresses IP où exim ... : pour désactiver les connexions entrantes sur les interfaces réseau publiques, entrez 127.0.0.1 (ou laissez vide)
4/
Autres destinations à accepter :
videz ou laissez vide
5/
Machines à relayer :
laissez vide
6/
Nom réseau ou adresse IP du système "smarthost" : le smtp de votre FAI
smtp.Free.fr (par exemple)
<- Que faut-il mettre ??

7/
Faut-il cacher ...
NON
8/
Faut-il minimiser ... :
NON
9/
Méthode de distribution du courrier local : choisissez la première ligne
Format "mbox" dans /var/mail
10/
Faut-il séparer ...
NON
j'ajouterai que je n'entends pas recevoir du courrier à tbr.ovh mais seulement faire parvenir les messages système à mon adresse @free.fr.

cassiopee
20/10/2016, 11h55
Citation Envoyé par foulweather
Questions :
1 - Dans le spf est-ce que je ne devrais pas inclure free.fr au lieu d'avoir : "include:mx.ovh.com"
Oula, quel pataquès

Là tu as essayé d'utiliser ton serveur dédié (IP 176.31.246.182 ) afin d'émettre des messages
avec comme adresse email d'émission "mon_prénom.mon_nom@free.fr".

Cela ne pourra jamais fonctionner ainsi (parce que ton serveur dédié ne fera jamais partie
des adresses IP que Free autorise à émettre des messages au nom de Free)

Si tu utilises ton serveur dédié comme serveur SMTP d'émission de messages, c'est pour une
(ou des) adresse email appartenant à ton nom de domaine "prenom.nom@tbr.ovh" par exemple.

(adresse email qu'il faudra créer au préalable dans ton dédié)

De la même façon, si tu veux utiliser "mon_prénom.mon_nom@free.fr" comme adresse email
d'émission, il faudra impérativement utiliser le serveur SMTP de Free pour cela (smtp.free.fr).


Il n'y a aucune raison d'y avoir les serveurs d'OVH (include:mx.ovh.com) dans ton SPF
sauf si tu veux utiliser les serveurs SMTP d'OVH afin d'émettre des messages au nom
de ton nom de domaine (à la place d'utiliser ton dédié).

Même chose pour Free :

- soit tu veux utiliser le serveur SMTP de Free pour émettre des messages au nom de ton nom de domaine,
dans ce cas là, oui, tu dois ajouter l'IP du serveur SMTP de Free dans ton SPF.

- soit tu veux utiliser le serveur SMTP de ton dédié pour émettre des messages au nom de ton nom de domaine,
dans ce cas, tu n'as besoin que d'ajouter l'IP de ton dédié dans le SPF.

Dans ce dernier cas de figure, soit tu indiques explicitement l'IP de ton dédié, quelque chose comme :

Code:
"v=spf1 +ip4:176.31.246.182 -all"
par exemple.

soit tu l'indiques indirectement via :

Code:
"v=spf1 mx -all"
qui indique que l'enregistrement DNS de type "MX" est le seul autorisé. Et comme par ailleurs
tu as indiqué que le "MX = mail.tbr.ovh" et que par ailleurs "mail.tbr.ovh = 176.31.246.182"
cela revient à autoriser l'IP de ton dédié.

2 - Je reviens également sur la question initiale de mon post concernant le nom du hostname.
Si je lance la commande hostname --fqdn j'obtiens : arthur.tbr.ovh or "arthur" est le nom de ma machine et "tbr.ovh" est le domaine. Il me semble normal que sur Internet le premier ne soit pas présent et seulement le second "tbr.ovh". Non ?
Ce que tu mets dans "/etc/hostname" n'a de portée que localement, dans ton serveur dédié.

A la limite, ça peut interagir un peu avec la config de ton serveur SMTP mais bon, ça dépend
de la configuration de ce dernier.

Mais ça, ce sera à voir après avoir réglé les problèmes de DNS/SPf en amont.

foulweather
20/10/2016, 09h42
Toujours seulement 4/10 dans mail-tester.
Les commentaires :
[SPF] free.fr does not allow your server 176.31.246.182 to use "mon_prénom.mon_nom@free.fr"
You do not have a SPF record, please add the following one to your domain free.fr:
v=spf1 a mx ip4:176.31.246.182 ~all
Your message is not signed with DKIM
We check if there is a server (A Record) behind your hostname arthur.tbr.ovh.
Questions :
1 - Dans le spf est-ce que je ne devrais pas inclure free.fr au lieu d'avoir : "include:mx.ovh.com"
2 - Je reviens également sur la question initiale de mon post concernant le nom du hostname.
Si je lance la commande hostname --fqdn j'obtiens : arthur.tbr.ovh or "arthur" est le nom de ma machine et "tbr.ovh" est le domaine. Il me semble normal que sur Internet le premier ne soit pas présent et seulement le second "tbr.ovh". Non ?

foulweather
20/10/2016, 08h46
J'ai modifié le spf dans le manager en adoptant la configuration par défaut :
$TTL 604800
@ IN SOA dns200.anycast.me. tech.ovh.net. (2016102001 86400 3600 3600000 300)
IN NS ns200.anycast.me.
IN NS dns200.anycast.me.
IN MX 10 mail.tbr.ovh.
IN A 176.31.246.182
600 IN TXT "v=spf1 include:mx.ovh.com ~all"
IN TXT ( "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn1XX 4arVtEcOQc4rSEQicQHaITOYA8AqyUb7so7E9e0668I3kpQa+V b7o5Tl1JZYVriZ9cogVGG3Fyan2tlmGUoe3Mct4sWj8TQWr4JT I1JZ1WibMjxKtSXApXhkPPF/Qzsd6t+R4HrfGznAQ8nMaZmdxkXFcQLXbH/qk4RLaEGQ0lxTl0fOEoh" "hySKdix9vYNf1elFwoDgPPDAX4fNcykxBEJ8UGiZB8MlZ/6ov6drXNpd5RCCevzPixOQh5aWcsHdgDfaYH2ECdq8/gUNFVhmh+7O83c/j3Xne5iN9W/yVc7CTt3el4+4NVmKbCe6j7UxzPT9TjyVGEibSTFJCoQIDAQAB " )
IN IN A 213.186.33.5
IN 600 IN TXT "1|www.tbr.ovh"
mail IN A 176.31.246.182
ownercheck IN TXT "039b0d97"
postmaster IN A 176.31.246.182
www IN TXT "l|fr"
www IN TXT "3|welcome"

cassiopee
19/10/2016, 22h01
Bon, pour le "mail", IN MX, c'est tout bon

En revanche, je ne vois plus de SPF (de l'extérieur), peut-être es-tu en train de faire évoluer ça
en ce moment (?)

Le plus important, c'est le SPF.
Une clé DKIM n'est pas du tout indispensable afin de pouvoir écrire à "gmail.com"
alors qu'un enregistrement SPF, oui.

foulweather
19/10/2016, 20h12
Nouveau résultat :
$TTL 604800
@ IN SOA dns200.anycast.me. tech.ovh.net. (2016101908 86400 3600 3600000 300)
IN NS ns200.anycast.me.
IN NS dns200.anycast.me.
IN MX 10 mail.tbr.ovh.
IN A 176.31.246.182
IN IN A 213.186.33.5
IN 600 IN TXT "1|www.tbr.ovh"
IN 600 IN TXT "v=spf1 a mx ~all"
IN 600 IN TXT "v=DKIM1; k=rsa; t=s; s=*; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzzqq WF6/8pc+eSG/ebXZ GxuusPZmfTOywpmd1/+1xcJh4nL/Q8QMAjMzW/TRXreAoi9pVz3tdSEWzla1MEGE edKsyUVoirTuw2rk5tQ3wxvQXmwXBtgvDiphA9d3KeOOweOcPZ G7WRcSim25IGsh nzZzqbpmyeXBgYANN9eYGAXQFsTVqV"
mail IN A 176.31.246.182
ownercheck IN TXT "039b0d97"
postmaster IN A 176.31.246.182
www IN TXT "l|fr"
www IN TXT "3|welcome"
Mais il faut aussi maintenant que je regénère une clé DKIM, car l'actuelle ne fonctionne plus.

cassiopee
19/10/2016, 19h53
Attention, je crois que tu n'as pas mis le point final :
Code:
tbr.ovh IN MX 10 mail.tbr.ovh.
tbr.ovh IN A 176.31.246.182
ça devrait être :

Code:
tbr.ovh. IN MX 10 mail.tbr.ovh.
tbr.ovh. IN A 176.31.246.182

foulweather
19/10/2016, 19h28
J'ai fait ce que tu m'as demandé :
tbr.ovh. IN MX 10 mail.tbr.ovh.
tbr.ovh. IN A 176.31.246.182
.
Le résultat en mode texte :
$TTL 604800
@ IN SOA dns200.anycast.me. tech.ovh.net. (2016101905 86400 3600 3600000 300)
IN NS ns200.anycast.me.
IN NS dns200.anycast.me.
IN IN A 213.186.33.5
IN 600 IN TXT "v=spf1 a mx ~all"
IN 600 IN TXT "1|www.tbr.ovh"
IN 600 IN TXT "v=DKIM1; k=rsa; t=s; s=*; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzzqq WF6/8pc+eSG/ebXZGxuusPZmfTOywpmd1/+1xcJh4nL/Q8QMAjMzW/TRXreAoi9pVz3tdSEWzla1MEGEedKsyUVoirTuw2rk5tQ3wxvQ XmwXBtgvDiphA9d3KeOOweOcPZG7WRcSim25IGshnzZzqbpmye XBgYANN9eYGAXQFsTVqV R"
mail IN A 176.31.246.182
ownercheck IN TXT "039b0d97"
postmaster IN A 176.31.246.182
tbr.ovh IN MX 10 mail.tbr.ovh.
tbr.ovh IN A 176.31.246.182
www IN TXT "3|welcome"
www IN TXT "l|fr"

foulweather
19/10/2016, 19h13
A l'aide !
Si j'essaie de me connecter en ssh, (sous Debian) j'obtiens :
ssh: Could not resolve hostname tbr.ovh: No address associated with hostname
Ouf ! la connexion ssh est revenue ! Mon latin n'était déjà pas très bon, mais là je le perds complètement.

cassiopee
19/10/2016, 19h05
Citation Envoyé par foulweather
En essayant d'éliminer les caractères parasites, je crois que ça a marché.
Très bien, ça devait être ça, parce que syntaxiquement, les lignes étaient déjà correctes.

Voici le résultat. Est-ce que l'on peut considérer qu'il est conforme ?
Presque :

Code:
IN IN MX 10 mail.tbr.ovh.
IN IN A 176.31.246.182
Là je vois deux fois "IN"

Essaye à la place :

Code:
tbr.ovh. IN MX 10 mail.tbr.ovh.
tbr.ovh. IN A 176.31.246.182

foulweather
19/10/2016, 18h04
Avec un
dig txt tbr.ovh
la clé DKIM n'apparaît plus !

foulweather
19/10/2016, 18h01
Retour vers le forum.
Les arobases n'étaient pas acceptées. Elles se sont effacées toutes seules.
En essayant d'éliminer les caractères parasites, je crois que ça a marché.
ZoneImport 19 oct. 2016 - Terminée
Voici le résultat. Est-ce que l'on peut considérer qu'il est conforme ?
$TTL 604800
@ IN SOA dns200.anycast.me. tech.ovh.net. (2016101904 86400 3600 3600000 300)
IN NS dns200.anycast.me.
IN NS ns200.anycast.me.
IN IN MX 10 mail.tbr.ovh.
IN IN A 176.31.246.182
IN 600 IN TXT "1|www.tbr.ovh"
IN 600 IN TXT "v=DKIM1; k=rsa; t=s; s=*; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzzqq WF6/8pc+eSG/ebXZGxuusPZmfTOywpmd1/+1xcJh4nL/Q8QMAjMzW/TRXreAoi9pVz3tdSEWzla1MEGEedKsyUVoirTuw2rk5tQ3wxvQ XmwXBtgvDiphA9d3KeOOweOcPZG7WRcSim25IGshnzZzqbpmye XBgYANN9eYGAXQFsTVqV R"
IN 600 IN TXT "v=spf1 a mx ~all"
mail IN A 176.31.246.182
ownercheck IN TXT "039b0d97"
postmaster IN A 176.31.246.182
www IN TXT "l|fr"
www IN TXT "3|welcome"

cassiopee
19/10/2016, 17h44
Peut-être qu'à la place de :

Code:
IN MX 10 mail.tbr.ovh.
IN A 176.31.246.182
le backoffice d'OVH préfèrerait peut-être une écriture plus explicite :

Code:
@ IN MX 10 mail.tbr.ovh.
@ IN A 176.31.246.182
?

L'arobase désigne le nom de domaine, c'est comme si on avait écrit :

Code:
tbr.ovh. IN MX 10 mail.tbr.ovh.
tbr.ovh. IN A 176.31.246.182
Autre piste : Il n'y aurait pas un caractère parasite invisible ? (type une tabulation)

cassiopee
19/10/2016, 17h38
Citation Envoyé par BBR
les noms de domaines sont gérés sur le manager ovh, sur les autres manager c'est uniquement le serveur lui-même
Ok, comme ça on est bien sur les mêmes écrans

je t'avais mis la bonne ligne au-dessus :
mail.tbr.ovh. IN A 176.31.246.182
ou comme ceci, ça marche aussi :
mail IN A 176.31.246.182
tu la mets comme ceci en modifiant ta zone en mode texte
Mais il a déjà cette ligne dans sa zone DNS ?

foulweather
19/10/2016, 17h36
Je viens d'essayer :
Vous allez ajouter l'entrée suivante dans votre zone DNS :
Type de champ
A
Domaine
tbr.ovh.
Cible
176.31.246.182

Attention, un ou plusieurs conflits peuvent survenir :
Soit cette entrée existe déjà dans votre zone DNS, soit un champ de type CNAME est présent sur ce sous-domaine.
Effectivement il y a bien déjà une entrée existante de ce type.

BBR
19/10/2016, 17h26
Je viens de regarder dans l'interface OVH (je ne sais pas si c'est 100% identique
dans le site web Kimsufi.com), après une zone "TTL", il y a une zone "Type"
et là, dans la liste déroulante, il suffit de choisir "A". Dans la zone suivante,
"Cible" on saisi simplement l'adresse IP.
les noms de domaines sont gérés sur le manager ovh, sur les autres manager c'est uniquement le serveur lui-même
mail IN A 176.31.246.182
je t'avais mis la bonne ligne au-dessus :
mail.tbr.ovh. IN A 176.31.246.182
ou comme ceci, ça marche aussi :
mail IN A 176.31.246.182
tu la mets comme ceci en modifiant ta zone en mode texte

foulweather
19/10/2016, 16h40
Aucune des deux solutions ne marche :
Avec un point après "mail.tbr.ovh." ->
Zone is not valid : line 6: unknown RR type 'mail.tbr.ovh.'
Avec "mail" tout court ->
Zone is not valid : line 6: unknown RR type 'mail'
Voici le contenu complet de la zone DNS en mode textuel :
$TTL 604800
@ IN SOA dns200.anycast.me. tech.ovh.net. (2016101903 86400 3600 3600000 300)
IN NS ns200.anycast.me.
IN NS dns200.anycast.me.
IN MX 10 mail.tbr.ovh.
IN A 176.31.246.182
600 IN TXT "1|www.tbr.ovh"
600 IN TXT "v=spf1 a mx ~all"
IN TXT ( "v=DKIM1; k=rsa; t=s; s=*; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzzqq WF6/8pc+eSG/ebXZGxuusPZmfTOywpmd1/+1xcJh4nL/Q8QMAjMzW/TRXreAoi9pVz3tdSEWzla1MEGEedKsyUVoirTuw2rk5tQ3wxvQ XmwXBtgvDiphA9d3KeOOweOcPZG7WRcSim25IGshnzZzqbpmye XBgYANN9eYGAXQFsTVqV" "RdqD6I1vmqmNWxyYjgy5euYbZeeDoxJaCOWzdEcx4D+w7bjrL rkFeZQoGKKqOAFs0hrQj19e0Ltf+XcYEt65yvk6cSdtW7f5alp x9iPfAj1QKnIz8JUeV0x9SXtB2aS/ZOeRotAXEHyngsSnPpkNnSuOOCf3P8MXjItQIDAQAB" )
mail IN A 176.31.246.182
ownercheck IN TXT "039b0d97"
postmaster IN A 176.31.246.182
www IN TXT "3|welcome"
www IN TXT "l|fr"

cassiopee
19/10/2016, 15h35
Il faudrait voir le contenu exact (= texte) de la zone DNS afin de pouvoir t'en dire davantage.

Tu dois pouvoir obtenir en demandant à "modifier manuellement la zone DNS" ou
une option équivalente.

Edit :
Je viens de regarder dans l'interface OVH (je ne sais pas si c'est 100% identique
dans le site web Kimsufi.com), après une zone "TTL", il y a une zone "Type"
et là, dans la liste déroulante, il suffit de choisir "A". Dans la zone suivante,
"Cible" on saisi simplement l'adresse IP.

foulweather
19/10/2016, 14h25
Dernières nouvelles du manager OVH à 12:21 dans "Opérations en cours" :
Zone is not valid : line 6: unknown RR type 'mail.tbr.ovh.'

foulweather
19/10/2016, 13h33
Merci à tous les trois.
Pour
mail.tbr.ovh. IN A 176.31.246.182
cela ne passait pas. Mais j'y suis parvenu en rajoutant un champ A.
Je vais retester pour voir les résultats.
Comment je désactive le DNSSEC ?

cassiopee
19/10/2016, 13h15
Citation Envoyé par foulweather
Modifications faites dans le manager OVH pour le spf.
Pour :
J'obtiens l'avertissement suivant :

Je dois rajouter ce point ?
Quel type de champ dans le manager pour
Merci, en tout cas, pour la réponse.
C'est comme tu préfères, cf les explications déjà données.

Si tu écris "mail" tout court (sans point final), le système va ajouter tout seul ton nom de domaine, ce qui donnera "mail.domaine.com", ce qui sera correct.

Si tu écris "mail.domaine.com." (avec un point final), le système ne va rien ajouter, ce qui donnera "mail.domaine.com",
ce qui sera correct.

C'est seulement si tu écris "mail.domaine.com" (sans point final) que ça n'ira pas, car alors le système va ajouter tout seul
ton nom de domaine ce qui donnera "mail.domaine.com.domaine.com" ce qui ne sera pas correct.

Certains préfèrent l'écriture relative (sans point), d'autres l'écriture absolue (avec point final). C'est un peu une question
de goût.

Mon seul conseil à ce niveau : ne pas mélanger les écritures : soit on décrit tout en relatif, soit tout en absolu.
Mélanger les deux types d'écrirtures au sein d'une même zone est le meilleur moyen de se planter

Quel type de champ dans le manager pour
N'utilisant pas cette interface, je ne pourrais te le dire précisément mais
c'est l' "enregistrement DNS" de base, le plus basique qui soit,
où l'on défini que "tel nom correspond à telle adresse IP".

BBR
19/10/2016, 12h58
mail.tbr.ovh. IN A 176.31.246.182

nowwhat
19/10/2016, 12h56
Concernant le MX :
SOIT : tu ajout le sous domaine "MX" dans la zone - tu tape donc MX sans rien d'autre.
SOIT : le champs MX + le domaine et tu termine avec un point.
Sans ce point à la fin, tu va créer un MX point point point qui est faux.

named-checkconf -z
Sachant que le service 'bind9' (le client serveur DNS sur ton serveur) travaille uniquement comme 'client' sur ton serveur, il est inutile de t'occuper de ce 'bind9'.
Ta zone n'est pas géré sur ton serveur (pas géré par bind9 sur ton serveur).
Il est géré par OVH (accessible par le Manager qui gère ton nom de domaine).

Tes serveurs DNS sont :
root@ns311465:~# dig tbr.ovh NS +short
dns200.anycast.me.
ns200.anycast.me.
Ces deux serveurs sont paramétré dans le Manager qui gère ton nom de domaine.

édit : j'ai vu que t'as activé le DNSSEC. Je te conseille de le déactiver - sauf si t'as vraiment une raison spéciale d'utiliser le DNSSEC.
Normalement, on active le DNSSEC si on a vraiment rien d'autre à faire .... et que gérer un serveur t'amuse plus.

foulweather
19/10/2016, 12h36
Modifications faites dans le manager OVH pour le spf.
Pour :
IN MX 10 mail.
J'obtiens l'avertissement suivant :
Attention : La cible utilise la notation relative, et pointe donc vers "mail.tbr.ovh.". Pensez à ajouter un point final à votre champ cible si vous souhaitez utiliser la notation absolue.
Je dois rajouter ce point ?
Quel type de champ dans le manager pour
mail. IN A 176.31.246.182
Merci, en tout cas, pour la réponse.

cassiopee
19/10/2016, 11h52
Parmi les choses à faire :

1) déclarer quel est le serveur de messagerie en charge de la réception des emails pour ce nom de domaine.

Actuellement, un :

Code:
dig -t mx 
ne ramène rien. Il manque donc un enregistrement DNS du genre :

Code:
 IN MX 10 mail.
suivi d'un autre :

Code:
mail. IN A 176.31.246.182
afin qu'au nom indiqué dans le "IN MX" corresponde bien la bonne adresse IP.

Ensuite, au niveau du SPF :

Code:
"v=spf1 +mx ~all"
afin d'autoriser ce MX a émettre des messages.

Tout ceci est à faire dans le backoffice du site web d'OVH, inutile de modifier localement
dans le dédié un fichier de zone puisque les serveurs DNS en charge de ton nom
de domaine sont ceux d'OVH (et non ton dédié).

Ensuite, patienter que la progation DNS se fasse, inutile d'aller se précipiter à faire
des tests immédiatement après.

Une fois ces différentes corrections apportées, il faudra voir ce que dit Gmail

foulweather
19/10/2016, 10h28
Je m'efforce de configurer mon serveur pour que l'envoi des messages système soit correct. A l'heure actuelle Free me les fait bien parvenir.
La meilleure aide que j'ai trouvée pour configurer DKIM dans exim est ici : https://wiki.meurisse.org/wiki/Exim/DKIM
J'en ai essayé beaucoup d'autres.
Le manager OVH contient bien - apparemment - ma clé publique DKIM et un spf.
Code:
600 IN TXT "v=spf1 a ~all"
Si je fais un dig, la clé semble bien présente :
Code:
dig +short TXT tbr.ovh
"1|www.tbr.ovh"
"v=spf1 a ~all"
"v=DKIM1\; k=rsa\; t=s\; s=*\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzzqqWF6/8pc+eSG/ebXZGxuusPZmfTOywpmd1.... f+XcYEt65yvk6cSdtW7f5alpx9iPfAj1QKnIz8JUeV0x9SXtB2aS/ZOeRotAXEHyngsSnPpkNnSuOOCf3P8MXjItQIDAQAB"
Code:
named-checkconf -z
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
Mais Gmail retourne mes messages avec une erreur 550.
"Mail-tester.com" me donne un 4/10. Pour rentrer dans les détails :
1 - You do not have a SPF record, please add the following one to your domain free.fr:
v=spf1 a mx ip4:176.31.246.182 ~all (répété 2 fois)
2 - Your message is not signed with DKIM
3 - We check if there is a server (A Record) behind your hostname arthur.tbr.ovh.
You may want to publish a DNS record (A type) for the hostname arthur.tbr.ovh or use a different hostname in your mail software.
En désespoir de cause, je me demande si mon fichier "hosts" et le "hostname" est bien nommé.
127.0.0.1 localhost
127.0.0.1 le_nom_de_ma_machine.mon_dns le_nom_de_ma_machine
Est-ce que ce ne devrait pas être plutôt ?
127.0.0.1 localhost
127.0.0.1 mon_dns le_nom_de_ma_machine
Et le " hostname " le nom du domaine sans le tld ?
J'ai déjà abordé ces questions en 2014. Mais depuis le disque dur a été changé et j'ai dû tout réinstaller.
Merci pour votre aide.