Forum Linux.général Améliorer la configuration SPF

Posté par (page perso) .
Tags : aucun
1
29
juin
2010
Bonjour,

SPF est configuré sur mon serveur email. Sur ce point, ça marche en rejetant des emails non envoyés depuis les serveurs admis par l'enregistrement DNS du domaine envoyeur.

Néanmoins il y a un type de message qui passe encore et que je trouve ridicule. Je me demande si cela ne devrait normalement pas rentrer dans les règles de filtres SPF. Ce sont des emails envoyés depuis une adresse quelconque qui a un SPF qui passe (ou pas d'enregistrement SPF) mais dont l'expéditeur a changé le FROM. Ainsi si je regarde le Return-path, on voit une adresse email et c'est elle qui est testée pour SPF et elle passe. Par contre si le filtre regardait le FROM et testait l'enregistrement SPF du domaine du FROM (qui est une autre adresse), il rejetterait l'email.

Je me demande donc si le filtre ne devrait pas aussi vérifier cela. Qu'en pensent les admins experts du coin?

Notez que le "classique" sont des emails envoyés "apparemment" (en fait non, mais le FROM indique cela, donc le client email aussi) depuis le login "support" de mon domaine (alors que le seul support, c'est moi-même pour 4 utilisateurs), et qui en général me demande des trucs genre de mettre à jour mon compte email avec un url bidon (qui leur permettrait donc déjà de savoir que mon compte est bien actif pour me spammer mais aussi avoir mes login/mot de passe). C'est pour cela que je trouve ridicule que des emails avec un tel FROM passent (ils vont dans le dossier spam certes, mais si le filtre SPF pouvait les refuser directement, ce serait mieux).
Merci.
  • # Pratique courante

    Posté par . Évalué à  4 .

    C'est une pratique courante.

    D'abord, pas mal d'hébergeurs n'ont pas leurs dns convenablement configurés (oui bon, on n'est pas sensé s'adapter à la bêtise des autres, mais au delà d'un certain seuil ladite bêtise est une norme).

    Dans mon entreprise, beaucoup d'utilisateurs ont plusieurs boîtes email, avec des noms de domaines différents.

    Envoyer des emails ne se fait pas toujours via le "bon" domaine. Par exemple il est préférable d'avoir un seul prestataire ou serveur pour envoyer (car il est fiable, car il enregistre, car il fonctionne de partout, etc). Et en plus c'est simple à configurer.

    Dans certains endroits il n'est pas possible d'envoyer des emails autrement qu'en passant par le relais local.

    Nous avons même une raison supplémentaire: plusieurs lignes ADSL par site. Une chez Orange et une chez Free par exemple. Même les personnes qui utilisent une adresse toto@orange.fr ne peuvent passer par le SMTP d'Orange car rien ne garanti qu'ils seront sur la bonne ligne au moment de l'expédition (et orange ne permet d'accéder à leurs SMTP qu'à partir de leurs lignes).

    Nous utilisons donc le SMTP d'un prestataire pour faire transiter tout nos emails.

    Il y a probablement bien d'autres raisons, bonnes ou mauvaises.
    • [^] # Re: Pratique courante

      Posté par (page perso) . Évalué à  2 .

      Salut,

      donc si je comprends bien ce que tu me dis, en gros il ne *faut pas* refuser un email si le FROM ne correspond pas à la vraie adresse d'envoi ou en vérifiant l'enregistrement SPF du FROM?

      Donc je suis condamné à recevoir des faux emails d'arnaque de mon propre domaine en gros (ou encore des faux emails de mes comptes Facebook/Twitter/le truc hype du moment, alors que je n'ai aucun compte chez les moindre de ces services), lesquels passent le filtre SPF car celui-ci ne se base pas sur l'adresse du FROM mais sur la vraie adresse d'envoi.

      Alors bien sûr, ces emails ne passent en général pas le filtre spam ensuite, mais j'aimerais tout de même pouvoir les refuser avant tellement ce sont des faux évidents selon moi (mon domaine, donc mon adresse email, datant de nombreuses années, je reçois plus d'une centaine de spams par jour, aux alentours de 150 même. Et je parle juste de mon compte, pas du serveur).

      C'est quand même vraiment un protocole ridicule le protocol email.

      Si quelqu'un a des suggestions, je suis tous yeux.
      Merci pour la réponse et pour d'éventuelles autres réponses.
      • [^] # Re: Pratique courante

        Posté par . Évalué à  3 .

        le FROM ne correspond pas à la vraie adresse d'envoi
        Le FROM _est_ l'adresse d'envoi. Ton filtre SPF est sensé se baser dessus.
        Que nommes-tu "vraie adresse d'envoi" ?

        Ce qu'on trouve souvent, c'est toto@domain.com qui passe par smtp.orange.fr pour envoyer ses messages.
        Ou toto@domain.com qui passe par checkout.banquedefrance.fr
        Dans tous les cas, ton filtre SPF doit vérifier l'enregistrement SPF de domain.com (qui va te répondre "ça doit venir uniquement de smtp.domain.com" donc poubelle).

        Si tu reçois des emails avec toi@ton-domaine.com alors que tu ne devrais pas, c'est que ton SPF sur ton DNS est mal renseigné (ou que tu t'es trompé dans le paramétrage de ton filtre SPF).
        Ou alors je n'ai rien compris à ta question :-) Auquel cas il va te falloir expliquer posément en raison de mon grand âge.
        • [^] # Re: Pratique courante

          Posté par . Évalué à  1 .

          Je pertinente et j'en rajoute.
          Si le probleme est avec ton propre domaine, tu n'as qu'a lister les @IP qui ont le droit d'émettre des mails pour ton domaine, ça devrait bloquer ces mails.
    • [^] # Re: Pratique courante

      Posté par (page perso) . Évalué à  1 .

      Nous utilisons donc le SMTP d'un prestataire pour faire transiter tout nos emails.

      Par curiosité, quel prestataire ? J'ai pas mal cherché avant de me rabattre sur une solution maison SPF+DKIM...
      • [^] # Re: Pratique courante

        Posté par . Évalué à  3 .

        Ca dépend pour quelle entreprise du groupe. La plupart du temps nous utilisons OVH. Ce n'est pas le meilleur, mais 10 minutes de panne par mois ça nous va. Beaucoup d'autres sont franchement bien plus mauvais (et bien plus chers).

        Sinon MBII pour des raisons historiques et Oléane par paresse (là le taux de panne est impressionnant).
  • # Mauvaise idée

    Posté par (page perso) . Évalué à  2 .

    Ce que tu souhaites mettre en place, c'est Sender ID, le SPF à la sauce Microsoft. Ce n'est pas une bonne idée, SPF est déjà très bien.

    Il faut bien prendre le MAIL FROM pour ce qu'il est : l'adresse technique d'expédition, celle où les erreurs doivent être envoyées, celle dont tu utilises <abuse@son_domaine> pour te plaindre d'un abus.

    Le From, c'est l'adresse officielle de l'expéditeur, pas forcément l'endroit d'où il l'a posté.

    La seule chose raisonnable à faire quand MAIL FROM != From, c'est de l'afficher dans le logiciel de messagerie. Le serveur de réception doit placer l'adresse de MAIL FROM dans un champ Return-Path, et le logiciel de messagerie doit afficher un truc du genre « Message de [From] envoyé par [MAIL FROM] ».
    • [^] # Re: Mauvaise idée

      Posté par (page perso) . Évalué à  2 .

      Précision : SPF n'est pas fait pour lutter contre le spam ou contre l'usurpation d'adresse. Il est fait pour lutter contre le backscatter, les notification de non-livraisons renvoyées aux gens dont l'adresse a été usurpée.

      C'est pour ça qu'il se vérifie sur l'adresse MAIL FROM : si celle-ci est usurpée, il ne faut surtout pas envoyer de notification de non-réception en cas de problème.

      Mais de toute façon, un serveur bien configuré n'envoie de notification de non-réception que dans de très rares cas, le reste du temps, il refuse le message à la transaction SMTP.
      • [^] # Re: Mauvaise idée

        Posté par . Évalué à  2 .

        Je pense pas que spf serve au départ à lutter contre le backscatter, il suffit de refuser de délivrer aux utilisateurs inconnus pour ça.

        Il est surtout fait pour permettre de deviner ou de s'assurer que dans une transaction smtp, le serveur qui envoie le mail a le droit de le faire, en se basant sur le from, le helo et l'enregistrement dns de l'adresse ip.
  • # Je comprends pas très bien

    Posté par . Évalué à  2 .

    pas d'enregistrement SPF
    Déjà, les domaines sans enregistrements spf, c'est simple, le spf n'a pas à être utilisé pour les filtrer, quelque soit le from.
    l'expéditeur a changé le FROM
    L'expéditeur (=le serveur mail d'envoi) annonce un seul from pendant la transaction smtp, et chez moi c'est à ce niveau que le rejet ou le deferral sur base du spf se passe. Par contre, tu peux avoir un return-path différent du from. Mais si ton filtre spf se base là-dessus, alors que c'est dans le corps du mail je pense, ça me paraît bizarre. Autant rejeter le mail directement au niveau de la transaction, avant le data, et les seules infos dont tu disposes alors sont le helo, le from, et le rcpt-to. Chez moi ça filtre à ce niveau-là en vérifiant avec spf que l'adresse ip de la transaction est bien autorisée à envoyer avec le nom de domaine du from annoncé. Je comprends pas ton histoire de return-path.

    Ensuite, si tu acceptes des mails avec indiqué dans le from ton propre domaine, soit tu durcis ta politique, ou en rejetant tous les softfails, ou en mettant -all et non pas ~all dans ton enregistrement dns, soit tu acceptes, sachant que de toute manière ils vont se retrouver dans le dossier spam. (Déjà rejette tout mail provenant d'utilisateur non-existant).
    • [^] # Re: Je comprends pas très bien

      Posté par . Évalué à  2 .

      J'ai compris que return-path désignait le from de la transaction smtp. Si tu veux filtrer donc sur le from du corps du message avec spf, je pense pas que ça soit une très bonne idée, parce que beaucoup de serveurs mail peuvent servir de relai, et tu arriverais à bloquer des tas de mails légitimes qui n'ont fait que transiter par un relai légitime.

      Si ton problème est de recevoir des emails depuis support@cheztoi.com, et que tu veux le régler avec spf, je pense pas que ce soit la solution, parce que le filtre spf de base est au niveau smtp, avant le data. En revanche, si tu as un filtre post smtp, style spamassassin, amavis, tu peux sûrement rajouter les règles que tu veux pour le supprimer direct avec le filtre en question. J'utilise pas (pour l'instant) de tel filtrage sur mon serveur mail, donc je sais pas comment faire pour le coup. Et vérifie aussi que dans le return-path ne sont acceptés que des utilisateurs valides.
      • [^] # Re: Je comprends pas très bien

        Posté par . Évalué à  2 .

        beaucoup de serveurs mail peuvent servir de relai, et tu arriverais à bloquer des tas de mails légitimes qui n'ont fait que transiter par un relai légitime.
        Justement non :-)
        Si _tu_ gères ton-domaine.com alors c'est toi qui décide de mettre un enregistrement SPF dans ton DNS.

        Si tu sais que tu utilises n'importe quel relais, alors pas de SPF.
        Si tu sais que tu utilises toujours smtp.ton-prestataire.com alors tu mets les adresses qui vont bien.
        • [^] # Re: Je comprends pas très bien

          Posté par . Évalué à  2 .

          Oui, exact. J'ai tort quand je parle de relai. Par contre pour les mailing-lists son filtrage ne va pas marcher non?

          Puisqu'on peut toujours envoyer avec un return-path différent du from du corps du message, et que je ne vois pas a priori de raisons pour que cela soit toujours invalide. Ainsi les mailing-listes renvoient le message, changent donc de return-path, mais gardent le from d'origine. Ainsi, s'il s'amuse à filtrer post-smtp sur base de l'enregistrement spf, il risque de virer des messages légitimes.

          Surtout spf est conçu pour fonctionner au niveau smtp je pense, pour valider les sources d'envoi à partir de leur ip, ça me surprenait donc un peu de vouloir faire un filtrage à partir des enregistrements spf sur le corps des mails.

Suivre le flux des commentaires

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