Ça va dépendre de la configuration de smtp.orange.fr, mais en principe il devrait y avoir quelque chose comme client@orange.fr, où client est le nom associé au compte dudit client chez Orange.
Je ne vais pas relever utilisateur@orange.fr, que je n'utilise pas, juste pour voir si j'ai des erreurs sur mes envois.
Ben si tu passes par les serveurs d’Orange pour envoyer, ça ne me paraît pas déconnant...
Si je choisis l'option MX -all, est-ce que j'oblige mes utilisateurs à passer par mon SMTP ?
Non. Si on reprend ton exemple : je suis chez Orange, et je passe par leur serveur pour envoyer un mail avec l’adresse de mon compte chez toi.
smtp.orange.fr contacte le MX du destinataire et lui annonce :
HELO smtp.orange.fr
MAIL FROM: gouttegd@orange.fr
(« Coucou, je suis smtp.orange.fr, j’ai un mail pour quelqu’un de chez toi de la part de gouttegd@orange.fr »)
À ce moment-là, le serveur du destinataire vérifie que smtp.orange.fr figure bien parmi les machines listées dans l’enregistrement SPF de orange.fr. Comme c’est le cas (enfin, ce serait le cas s’il y avait un SPF chez orange.fr), le serveur accepte le mail (et le flagge éventuellement avec un en-tête indiquant qu’il a passé la validation SPF, comme Received-SPF: pass ou Authentication-Result: spf=pass).
À aucun moment le fait que l’en-tête From: du message indique gouttegd@domaine.tld n’est entré en ligne de compte. En fait, ton enregistrement SPF n’a jamais été consulté.
Il ne faut pas se méprendre sur le rôle de SPF : il ne sert pas à empêcher un utilisateur d’usurper une adresse qui n’est pas la sienne (SPF ne m’empêchera pas d’envoyer un message avec From: françois.hollande@élysée.fr).
Ce que SPF sert à éviter, c’est ça (exemple réel tout juste tiré de mon dossier SPAM) :
Return-Path: <educational.permissions@example.com>
Received-SPF: Softfail ('domain owner discourages use of this host') identity=mailfrom; client-ip=182.98.254.225; helo=mx32.usaindiamunish.net; envelope-from=educational.permissions@example.com; receiver=webmaster@incenp.org;
Received: from mx32.usaindiamunish.net (unknown [182.98.254.225])
by mail.incenp.org (Postfix) with SMTP id 4824F9C30E
for <webmaster@incenp.org>; Mon, 8 Dec 2014 03:02:21 +0100 (CET)
Ici, la machine mx32.usaindiamunish.net a contacté mon serveur en prétendant avoir un message venant de educational.permissions@example.com, alors qu’il n’y est pas autorisé par le SPF de example.com (j’ai changé le nom de domaine original, puisqu’il n’est pour rien dans ce spam — c’est lui la victime de l’usurpation en fait).
En gros, mx32.usaindiamunish.net envoie du spam en tentant de faire porter le chapeau à example.com. L’enregistrement SPF de example.com permet à tout le monde de déjouer la supercherie (et d’éviter à example.com d’être accusé d’envoyer du spam).
[^] # Re: Je comprends toujours pas
Posté par gouttegd . En réponse au message SPF : autoriser l'envoi par un autre SMTP. Évalué à 3. Dernière modification le 08 décembre 2014 à 11:46.
Ça va dépendre de la configuration de smtp.orange.fr, mais en principe il devrait y avoir quelque chose comme client@orange.fr , où client est le nom associé au compte dudit client chez Orange.
Ben si tu passes par les serveurs d’Orange pour envoyer, ça ne me paraît pas déconnant...
Non. Si on reprend ton exemple : je suis chez Orange, et je passe par leur serveur pour envoyer un mail avec l’adresse de mon compte chez toi.
smtp.orange.fr contacte le MX du destinataire et lui annonce :
(« Coucou, je suis smtp.orange.fr, j’ai un mail pour quelqu’un de chez toi de la part de
gouttegd@orange.fr»)À ce moment-là, le serveur du destinataire vérifie que smtp.orange.fr figure bien parmi les machines listées dans l’enregistrement SPF de orange.fr. Comme c’est le cas (enfin, ce serait le cas s’il y avait un SPF chez orange.fr), le serveur accepte le mail (et le flagge éventuellement avec un en-tête indiquant qu’il a passé la validation SPF, comme
Received-SPF: passouAuthentication-Result: spf=pass).À aucun moment le fait que l’en-tête
From:du message indiquegouttegd@domaine.tldn’est entré en ligne de compte. En fait, ton enregistrement SPF n’a jamais été consulté.Il ne faut pas se méprendre sur le rôle de SPF : il ne sert pas à empêcher un utilisateur d’usurper une adresse qui n’est pas la sienne (SPF ne m’empêchera pas d’envoyer un message avec
From: françois.hollande@élysée.fr).Ce que SPF sert à éviter, c’est ça (exemple réel tout juste tiré de mon dossier SPAM) :
Ici, la machine
mx32.usaindiamunish.neta contacté mon serveur en prétendant avoir un message venant deeducational.permissions@example.com, alors qu’il n’y est pas autorisé par le SPF deexample.com(j’ai changé le nom de domaine original, puisqu’il n’est pour rien dans ce spam — c’est lui la victime de l’usurpation en fait).En gros,
mx32.usaindiamunish.netenvoie du spam en tentant de faire porter le chapeau àexample.com. L’enregistrement SPF deexample.compermet à tout le monde de déjouer la supercherie (et d’éviter àexample.comd’être accusé d’envoyer du spam).