Forum général.général SPF : autoriser l'envoi par un autre SMTP

Posté par  . Licence CC By‑SA.
Étiquettes :
0
5
déc.
2014

Bonjour.

Mon nom de domaine domain.tld, que j'utilise pour envoyer mes courriels, ne possède pas actuellement d'enregistrement SPF. J'aimerais en configurer un dans l'espoir de limiter mes messages considérés comme spam (ça arrive peu, mais ça arrive) et parce que ça ferait plus joli d'avoir 0 warning sur les sites de test.

Le serveur est un dédié chez Gandi. J'envoie les courriels en passant par le SMTP du serveur lui-même, que ce soit via mon client logiciel à la maison ou mon webmail quand je me déplace. Pour autant, je ne souhaite pas interdire quelqu'un d'envoyer un courriel avec une adresse d'expéditeur @domain.tld depuis un autre SMTP (par exemple le SMTP d'Orange s'il est derrière une box qui ne lui laisse pas le choix).

Et c'est là que j'ai du mal à comprendre.

WP dit :

SPF ne garantit pas que la partie locale de l'adresse de courrier électronique (à gauche du signe @) est authentique.

mais aussi

SPF FAIL policies can be an effective but problematic tool. A typical example is a user that wishes to send an email from a private PC or a mobile phone: the user uses their corporate email address but may use a different outgoing SMTP server which is not listed in the SPF record. The corporate domain may therefore be secure by blocking all email that does not originate from themselves, but have thereby limited some of their own users. Many organizations consider this compromise acceptable and even desirable.

Si je mets un truc minimaliste comme

domain.tld. IN TXT "v=spf1 mx -all"
est-ce que je vais bloquer cet usage que je considère comme légitime ?

Et si je mets

domain.tld. IN TXT "v=spf1 +all"
ça n'a pas un grand intérêt.

Et je ne comprends pas trop l'utilisation de ~all et ?all.

Si je comprends bien, soit le SPF est super laxiste et donc ne sert à rien, soit il est rigoureux mais interdit des usages que je considère légitimes.

Je pense que je dois passer à côté de quelque chose. Par exemple, dans ce paragraphe, je ne comprends pas à quoi correspond la sender address, si ce n'est pas le champ From. Je pense que c'est le nœud du problème.

The sender address is transmitted at the beginning of the SMTP dialog. If the server rejects the sender, the unauthorized client should receive a rejection message, and if that client was a relaying message transfer agent (MTA), a bounce message to the original sending address may be generated. If the server accepts the sender, and subsequently also accepts the recipients and the body of the message, it should insert a Return-Path field in the message header in order to save the sender address. While the address in the Return-Path often matches other originator addresses in the mail header such as From or Sender, this is not necessarily the case, and SPF does not prevent forgery of these other addresses.

J'espère que quelqu'un qui a compris le mécanisme saura m'éclairer.

  • # Suite...

    Posté par  . Évalué à 2.

    En continuant de chercher, je trouve cette discussion :

    https://linuxfr.org/forums/linux-general/posts/am%C3%A9liorer-la-configuration-spf

    Notamment cette réponse de Tanguy :

    https://linuxfr.org/nodes/83411/comments/1139891

    J'en comprends que ce n'est pas le champ From qui est en question ici, donc si je mets quelque chose comme

    domain.tld. IN TXT "v=spf1 mx -all"
    je n'empêcherai pas quelqu'un d'envoyer un message @domain.tld via un SMTP tiers (hébergeur, par exemple).

    Mais alors je me demande ce que ça empêche.

    Et ça semble contredire le message de Kerro :

    https://linuxfr.org/nodes/83411/comments/1139838

    J'aurais pu préciser que j'héberge aussi des listes de discussion (Mailman). Est-ce que ça nécessite une config spécifique ?

  • # Distinguer 5321.MailFrom de 5322.From

    Posté par  . Évalué à 4.

    Je pense que je dois passer à côté de quelque chose. Par exemple, dans ce paragraphe, je ne comprends pas à quoi correspond la sender address, si ce n'est pas le champ From. Je pense que c'est le nœud du problème.

    Le problème, c’est que ce terme de « champ From » est ambigu et peut désigner deux choses complètement différentes.

    Pour l’expliquer, l’analogie avec le courrier postal est souvent employée et je la trouve assez pertinente.

    La sender address, ou adresse « d’expédition », « d’enveloppe », « de retour » (parfois aussi appelé, plus formellement, « 5321.MailFrom », du numéro du RFC qui décrit le protocole SMTP), c’est l’adresse qui figure au dos de l’enveloppe du courrier, celle à laquelle le facteur renvoie l’enveloppe s’il ne peut pas la distribuer.

    Elle est distincte de l’adresse qui apparaît dans l’en-tête From: du message (« 5322.From », du numéro du RFC qui décrit le format des e-mails), et qui est analogue à l’adresse située en-tête du courrier proprement dit (à l’intérieur de l’enveloppe).

    Concrètement, l’adresse « 5321.MailFrom » est celle qu’envoie le client SMTP pour annoncer au serveur qu’il a un mail à envoyer. Comme le dit le passage que tu cites, ça se passe au tout début du dialogue SMTP (juste après le EHLO) :

    MAIL FROM: return-address@example.net

    À ce moment-là, le serveur (s’il implémente SPF) peut vérifier si le domaine example.net a un enregistrement SPF et, le cas échéant, si l’adresse du client fait partie des adresses autorisées par ledit enregistrement.

    While the address in the Return-Path often matches other originator addresses in the mail header such as From or Sender, this is not necessarily the case, and SPF does not prevent forgery of these other addresses.

    Comme le dit ce passage, rien n’oblige le 5321.MailFrom et le 5322.From a être identique (tout comme l’adresse de retour au dos d’une enveloppe peut être différente de l’adresse mentionnée sur le papier à en-tête). SPF ne concerne que le 5321.MailFrom.

    • [^] # Re: Distinguer 5321.MailFrom de 5322.From

      Posté par  . Évalué à 2.

      Merci pour cette réponse.

      J'aime aussi expliquer le courriel avec des analogies, notamment l'histoire du champ From, ou bien le fait qu'on poste depuis une boîte publique et qu'on reçoit dans sa boîte privée.

      En vrai, dans un courrier postal, on met plutôt son adresse privée au versum de l'enveloppe, pas l'adresse de la boîte où on poste. Mais ok pour l'explication.

  • # c'est pas très compliqué en fait

    Posté par  . Évalué à 2. Dernière modification le 05 décembre 2014 à 20:15.

    Ce qu'il faut prendre en compte, c'est que généralement le destinataire a un antispam derrière la vérification SPF. Le SPF va influer sur le score qu'il lui donne. Souvent, si il y a un champ SPF et que l'adresse est explicitement autorisée, le mail a un meilleur score sur l'antispam.

    La doc openspf dit :

    "+" Pass
    "-" Fail
    "~" SoftFail
    "?" Neutral

    Si tu mets 'v=spf1 mx -all', ce qui sera envoyé par le MX sera autorisé, le reste sera directement rejeté.
    Si tu mets 'v=spf1 mx +all' ou 'v=spf1 +all', ça ne sert pas à grand chose effectivement
    Si tu mets 'v=spf1 mx ~all', ce qui n'est pas envoyé par le MX sera accepté, mais avec un moindre score sur l'antispam. Typiquement, il risque de se retrouver dans le dossier spams.
    Si tu mets 'v=spf1 mx ?all', ce qui n'est pas envoyé par le MX sera vu comme neutre, on ne lui augmente pas son score mais on ne le diminue pas non plus.

    EDIT : quand je parle de « meilleur score », je veux dire qu'il ne sera pas vu comme du spam (les antispams fonctionnent en général dans l'autre sens : plus le score est elevé, plus le mail est vu comme spam).

    • [^] # Re: c'est pas très compliqué en fait

      Posté par  . Évalué à 2.

      Merci pour ces détails. Je vois l'idée. Je l'avais compris à peu près comme ça, mais pas aussi précisément.

      Mais en tant que "rédacteur" de l'enregistrement spf, soit je considère que le hors MX est illégitime, et je mets -all, soit je considère que c'est légitime, et je mets +all (ou rien). Ça me gène d'autoriser des utilisateurs à utiliser un autre SMTP, tout en leur plombant leur score.

  • # SMTP avec authentification

    Posté par  . Évalué à 4.

    Le serveur est un dédié chez Gandi. J'envoie les courriels en passant par le SMTP du serveur lui-même, que ce soit via mon client logiciel à la maison ou mon webmail quand je me déplace.

    ca c'est classique.

    Pour autant, je ne souhaite pas interdire quelqu'un d'envoyer un courriel avec une adresse d'expéditeur @domain.tld depuis un autre SMTP (par exemple le SMTP d'Orange s'il est derrière une box qui ne lui laisse pas le choix ).

    utiliser le SMTP avec authentification, et configurer le client pour utiliser les ports prevus pour ca (465 ou 587)
    il n'y a guere que les SMTP sur le port 25 qui sont bloqués par les box des FAI.

    • [^] # Re: SMTP avec authentification

      Posté par  . Évalué à 2.

      utiliser le SMTP avec authentification, et configurer le client pour utiliser les ports prevus pour ca (465 ou 587)
      il n'y a guere que les SMTP sur le port 25 qui sont bloqués par les box des FAI.

      J'utilise effectivement le SMTP avec authentification et je suppose que c'est avec les bons ports (à vérifier et corriger le cas échéant).

      Si ça résout le problème actuel avec les box, c'est bien. Mais ça ne résout pas le problème théorique du gars qui veut passer par son FAI parce qu'il a une bonne raison : plusieurs comptes et un seul SMTP configurable sur son logiciel (c'était le cas la dernière fois que j'ai utilisé Thunderbird), limitation due à son téléphone mobile, ou n'importe quelle autre raison.

      • [^] # Re: SMTP avec authentification

        Posté par  . Évalué à 2.

        un seul SMTP configurable sur son logiciel (c'était le cas la dernière fois que j'ai utilisé Thunderbird)

        ca doit daté d'un moment,
        et si le logiciel email est mal foutu, faut changer de logiciel.

        en plus autoriser les SMTP non referencé, c'est la porte ouverte aux spammeurs, puisque tu vas autorisés n'importe qui a envoyer un email avec un @tondomaine.com

  • # Je comprends toujours pas

    Posté par  . Évalué à 2.

    Si je comprends bien la première réponse, les choses se passent comme ceci.

    Si j'indique

    domain.tld. IN TXT "v=spf1 mx -all"
    le filtre SPF éventuel sur le serveur qui reçoit le message va vérifier que l'adresse dans le champ

    MAIL FROM: return-address@example.net
    est bien de la forme

    MAIL FROM: return-address@domain.tld
    Je comprends bien que c'est sur ce champ que ça se base et pas sur le From.

    Mais dans le cas où un utilisateur passe par son SMTP, par exemple smtp.orange.fr, que se passe-t-il ?

    Le champ From sera utilisateur@domain.tld, mais qu'y a-t-il dans le champ MailFrom ? A vrai dire je trouverais ça logique qu'il y ait aussi utilisateur@domain.tld. Je ne vais pas relever utilisateur@orange.fr, que je n'utilise pas, juste pour voir si j'ai des erreurs sur mes envois.

    Si c'est comme ça, ça ne change rien au problème.

    J'ai compris quelques détails techniques grâce à vos explications, mais je n'ai pas répondu à ma question qui se résume en une phrase.

    Si je choisis l'option MX -all, est-ce que j'oblige mes utilisateurs à passer par mon SMTP ?

    Si oui, je me demande que faire.

    • Ne pas utiliser SPF (ou l'utiliser en +all) ? Ça revient à considérer que c'est trop mal foutu pour s'adapter à un cas que je suppose courant.

    • Utiliser SPF et forcer tous les utilisateurs à utiliser le SMTP maison ? C'est contraignant, non ?

    Dans le fond, la situation actuelle ne me gêne pas, mais j'aimerais faire les choses bien (et idéalement les comprendre, c'est aussi le but de l'auto-hébergement), et éviter de me choper des flags spam parce que ma config est pas top.

    • [^] # Re: Je comprends toujours pas

      Posté par  . Évalué à 3. Dernière modification le 08 décembre 2014 à 11:46.

      Mais dans le cas où un utilisateur passe par son SMTP, par exemple smtp.orange.fr, que se passe-t-il ?

      Le champ From sera utilisateur@domain.tld, mais qu'y a-t-il dans le champ MailFrom ?

      Ç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  . Évalué à 2.

        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…

        Oui, c'est vrai.

        Merci pour tes éclaircissements. C'est maintenant clair.

        Je comprends ton exemple. Je ne voyais pas au début pourquoi le spammeur faisait ça. Pourquoi ne pas envoyer son message avec Return-Path:  ? En fait c'est aussi un nom de domaine fictif (voir network-tools.com) donc facilement déjoué par l'anti-spam et la seule chose qui permet d'identifier l'envoyeur, c'est son IP (unknown [182.98.254.225]).

        Je vais donc mettre un -all, et supposer que les clients de mes utilisateurs sont bien foutus et renseignent le champ MailFrom correctement.

        Merci d'avoir pris le temps de détailler.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.