1 (edited by viktor 2012-09-29 10:34:59)

Topic: Envoi des mails et Sender Policy Framework (SPF)

Bonjour,

notre site web est aimablement hébergé sur web.tuxfamily.org, son domaine http://legamus.eu est géré chez OVH. Il y a un forum phpBB3 qui envoie des mails (notifications) en tant que info@legamus.eu. Plusieurs personnes (mais pas moi) ont des problèmes, elles ne reçoivent pas les mails. J'ai cherché et trouvé que dans l'entrée DNS de legamus.eu, il y a une ligne SPF
"v=spf1 include:mx.ovh.com ~all" qui pourrait expliquer cela.

Quelle approche préférez-vous ?

(1) Adapter l'entrée SPF - dans les en-têtes d'un mail je trouve pineau.tf-data.net et edony.tuxfamily.net. Qui dois-je ajouter à l'entrée SPF ? Les deux? un autre nom plus générique ?

(2) Faire en sorte que le forum utilise directement le serveur SMTP de OVH.

Merci beaucoup,
Viktor.

Re: Envoi des mails et Sender Policy Framework (SPF)

J'ai essayé (2) qui semble la solution la plus facile, or je n'arrive pas à utiliser le serveur mail ns0.ovh.net. En fait, sur la console ssh, un simple

telnet ns0.ovh.net 587

n'aboutit pas, chez moi cela fonctionne bien. Pareil pour l'alternative

telnet ssl0.ovh.net 465

Problème de firewall ? Interdiction d'utiliser un port 587 ou 465 ?

Re: Envoi des mails et Sender Policy Framework (SPF)

Salut,

viktor wrote:

J'ai essayé (2) qui semble la solution la plus facile, or je n'arrive pas à utiliser le serveur mail ns0.ovh.net. En fait, sur la console ssh, un simple

telnet ns0.ovh.net 587

n'aboutit pas, chez moi cela fonctionne bien. Pareil pour l'alternative

telnet ssl0.ovh.net 465

Problème de firewall ? Interdiction d'utiliser un port 587 ou 465 ?

Ouaip, c'est filtré, il faut utiliser sendmail depuis les serveurs web.

Pour les ports 465 et 25 c'est niet, pour des raisons évidentes :-) Pour le port 587 ça pourrait se laisser réfléchir, même si de nombreux serveurs mails ne font pas la distinction dans leur configuration entre 25 et 587 (bouhh, pas bien), c'est a priori de leur faute à la base.

Sylvain

Re: Envoi des mails et Sender Policy Framework (SPF)

Salut,

viktor wrote:

Bonjour,

notre site web est aimablement hébergé sur web.tuxfamily.org, son domaine http://legamus.eu est géré chez OVH. Il y a un forum phpBB3 qui envoie des mails (notifications) en tant que info@legamus.eu. Plusieurs personnes (mais pas moi) ont des problèmes, elles ne reçoivent pas les mails. J'ai cherché et trouvé que dans l'entrée DNS de legamus.eu, il y a une ligne SPF
"v=spf1 include:mx.ovh.com ~all" qui pourrait expliquer cela.

Quelle approche préférez-vous ?

(1) Adapter l'entrée SPF - dans les en-têtes d'un mail je trouve pineau.tf-data.net et edony.tuxfamily.net. Qui dois-je ajouter à l'entrée SPF ? Les deux? un autre nom plus générique ?

Normalement ça ne pose pas problème, parce que les mails en sortie de tuxfamily sont tous de la forme utilisateur@tuxfamily.org dans leur enveloppe. SFP étant defective by design, car ne faisant pas de distinction explicite entre le From: des headers et le FROM de l'enveloppe, et s'intéressant uniquement à l'IP qui se connecte, alors que la killer feature de SMTP sont ses mécanismes de routages, on arrive à ces situations difficiles ou SPF fait plus de mal que de bien. Mais si tu autorises tous les reverses en .tuxfamily.net, ça devrait le faire.

Sylvain

5 (edited by viktor 2012-10-17 20:50:05)

Re: Envoi des mails et Sender Policy Framework (SPF)

gradator wrote:

SFP étant defective by design, car ne faisant pas de distinction explicite entre le From: des headers et le FROM de l'enveloppe, et s'intéressant uniquement à l'IP qui se connecte, alors que la killer feature de SMTP sont ses mécanismes de routages, on arrive à ces situations difficiles ou SPF fait plus de mal que de bien.

Merci Sylvain. Je sais que SPF est loin d'être parfait mais j'espère que dans mon cas, ça fait plus de bien que du mal (sinon je peux aussi supprimer les entrées SPF). Sur un autre domaine je n'ai pas SPF et je reçois depuis quelque temps entre 5 et 40 "backscatter" par jour... J'aime l'idée principale que je déclare les serveurs mails sortants, dommâge que cela complique les redirections.

Mais si tu autorises tous les reverses en .tuxfamily.net, ça devrait le faire.

Donc "ptr:tuxfamily.net", n'est-ce pas ?

Re: Envoi des mails et Sender Policy Framework (SPF)

viktor wrote:
gradator wrote:

Mais si tu autorises tous les reverses en .tuxfamily.net, ça devrait le faire.

Donc "ptr:tuxfamily.net", n'est-ce pas ?

Il me semble, ça fait longtemps que je n'ai pas joué avec SPF.

Re: Envoi des mails et Sender Policy Framework (SPF)

Hello Sylvain,

serait-il possible de mettre les adresses IPv6 des machines qui envoient du mail dans les entrées DNS AAAA ?
Exemple :

Received: from edony.tuxfamily.net ([2a02:2178:2:c::3])

mais edony.tuxfamily.net n'a pas d'AAAA, donc pas de reverse DNS.

Re: Envoi des mails et Sender Policy Framework (SPF)

Humm ouais, c'est pénible ça. J'ai désactivé l'IPv6 sur les serveurs mails, on verra plus tard (comprendre jamais :p).

Sylvain

Re: Envoi des mails et Sender Policy Framework (SPF)

Sur edony.tuxfamily.net, IPv6 semble toujours actif :

Received: from edony.tuxfamily.net ([2a02:2178:2:c::3]) by [xxx] with ESMTP id U03f56pBHBoJ6PW for [xxx]; Tue, 17 Dec 2013 12:50:19 +0100 (CET)

Tu es sûr que la désactivation d'IPv6 est préférable à une entrée AAAA ?

Re: Envoi des mails et Sender Policy Framework (SPF)

viktor wrote:

Sur edony.tuxfamily.net, IPv6 semble toujours actif :

En effet, cette fois-ci c'est la bonne :-)

viktor wrote:

Tu es sûr que la désactivation d'IPv6 est préférable à une entrée AAAA ?

L'entrée AAAA ne suffit pas, il faut aussi ajouter l'entrée PTR sur la zone ip6.arpa dont on a pas encore le controle, et dont j'ai la flemme de m'occuper de le demander :-)   Le gain n'en vaut pour l'instant pas la peine.

Re: Envoi des mails et Sender Policy Framework (SPF)

gradator wrote:

L'entrée AAAA ne suffit pas, il faut aussi ajouter l'entrée PTR sur la zone ip6.arpa dont on a pas encore le controle, et dont j'ai la flemme de m'occuper de le demander :-)   Le gain n'en vaut pour l'instant pas la peine.

On a maintenant le contrôle des reverses IPv6, du coup, c'est réactivé :-)