Journal Authentifier n'est pas autoriser

Posté par .
Tags : aucun
8
18
août
2010
Coucou tout le monde,

Vous vous souvenez peut-être de ce sondage sur spf : Sender_Policy_Framework, dkim:DomainKeys_Identified_Mail, etc...

J'avais mis en place spf et dkim chez moi suite à ce sondage. Finalement, ça a surtout augmenté ma "délivrabilité", mais comme outil contre le spam, j'ai l'impression que c'est très moyen. J'imagine que ça a déjà été maintes fois discuté, mais bon, voilà mon compte-rendu.

Au départ je me suis dit que spf pourrait permettre de lutter contre le forgeage de mon domaine. Mais si ça marche pour mon domaine, ça n'est pas forcément le cas pour les autres domaines. Finalement, j'ai trouvé plus simple. Je refuse tout serveur qui prétend s'appeler comme moi. J'oblige les utilisateurs (cercle familial, ça va) à s'authentifier via submission en utilisant reject_auth_login_mismatch dans postfix. Si des utilisateurs veulent utiliser d'autres adresses d'envoi que celle de chez moi, je peux rajouter une liste d'adresses permises avec leur identifiant. Pour mon serveur personnel, c'est suffisant, et ça n'a pas posé problème pour le moment. Je raisonne dans la perspective où tout le monde ferait ainsi: seuls les utilisateurs authentifiés pourraient envoyer des mails, et encore uniquement avec des adresses définies. Ça réduirait sérieusement les sources de spam.

Pour dkim, ça permet aux autres serveurs d'authentifier les mails envoyés par mon serveur, mais ça ne permet pas de rejeter les mails qui ne valident pas le test. Gmail par exemple est souvent relayé d'une manière ou d'une autre, ce qui casse parfois la signature. Je ne vais pour autant tout rejeter. Cependant comme certains noms de domaine ont des signatures qui valident toujours, je pourrais peut-être rejeter les mails qui ne valident pas quand ils viennent de ces domaines.

En fait, je pense que spf et dkim peuvent surtout être utilisés pour scorer des mails dans spamassassin par exemple. Mais les deux normes me paraissent globalement inutiles du point de vue du spam, car aucune des deux ne permet de s'assurer que le message envoyé n'est pas un spam. Rien ne dit que toutes les adresses d'un nom de domaine utiliseront les smtp prévus par les admin de ce nom de domaine pour envoyer leurs mails. Comme le dit Bortzmeyer (cf fin), ce sont des normes qui permettent d'authentifier des serveurs émetteurs. À mon avis elles ne renseignent pas plus a priori que des listes blanches/noires sur le contenu des messages de ces serveurs, non plus qu'elles ne renseignent a priori sur le contenu envoyé par des serveurs non authentifiés. Et pour les deux, le taux de faux-positifs monte vite si on applique bêtement les règles.

Est-ce que vous voyez dans ces normes une utilité que j'ai loupée?

http://www.bortzmeyer.org/authentifier-et-autoriser.html
http://www.postfix.com/postconf.5.html#reject_sender_login_m(...)
  • # ouah!

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

    J'oblige les utilisateurs (cercle familial, ça va) à s'authentifier via submission en utilisant reject_auth_login_mismatch dans postfix.

    Il est balaise ton cercle familial!

    http://devnewton.bci.im

    • [^] # Re: ouah!

      Posté par . Évalué à 2.

      Surtout quand on prend les gens par la main :)
      Mail d'Apple trouve tout seul le bon port, ce qui est plus gênant est les certificats déclarés invalides.
    • [^] # Re: ouah!

      Posté par . Évalué à 2.

      une famille de geeks peut être ?
      • [^] # Re: ouah!

        Posté par . Évalué à 4.

        Non, c'est juste une mesure de sécurité avant-gardiste en vue de la loi Hadopi2, qui va éliminer définitivement le spam, tout comme la première élimine bien le piratage:

        Ton réseau ne doit pas souffrir de défaut de sécurité permettant l'envoi de spam depuis ton routeur.

        Il faut donc des logiciels de protection contre l'envoi de spam, tels que OpenOffice ou les outils cités dans le journal.

        Si des spams provenant tout de même de ton routeur sont détectés, tu pourras toujours envoyer ton routeur au ministère pour analyse en guise de bonne foi.
  • # Utiité de tout celà

    Posté par . Évalué à 4.

    Comme tu le dis, configurer SPF et DKIM pour son domaine/serveur c'est bien pour augmenter la "dalivrabilité" des mails, mais concernant les spams arrivants, amha il faut s'en contenter pour rajouter du score de spam... mais si tu n'utilises que ça, ça ne servira à pas grand chose... ce n'est pas parce qu'un mail a été relayé par gmail ou orange que c'est forcément du spam, inversement, ça n'est pas forcément parce que le relais est dans champ SPF ou est authentifié par DKIM que le mail n'est pas du spam.

    SPF et DKIM sont des méthodes qui permettent de dégager les tentatives d'hameçonnage flagrantes (non, paypal n'utilise pas le serveur SMTP d'Orange) mais sont quasi inutiles dans la lutte contre le spam : elles ne peuvent que donner des éléments en plus, c'est tout.

    Pour le spam, une technique d'apprentissage efficace (voire double : spamassassin+filtre thunderbird par exemple, éventuellement adjointe à des RBL) est bien plus intéressent qu'utiliser SPF et/ou DKIM amha
    • [^] # Re: Utiité de tout celà

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

      Tiens, justement aujourd'hui j'ai envoyé un email à un service informatique d'une université pour savoir pourquoi mes mails envoyés depuis mon adresse perso partaient très souvent en spam quand j'écrivais à des gens de l'université.
      La réponse c'est que mon serveur n'utilise pas SPF et que j'envoie mes mails depuis gmail. Là où je suis embêté c'est que ce domaine il est géré par un membre de ma famille (pas la même famille que l'auteur du journal :P) et que je ne suis pas administrateur dessus.
      La solution la plus simple serait visiblement de configurer gmail pour utiliser le serveur smtp de mon compte mail perso. Le problème c'est que ce n'est qu'une redirection de mail et que je sais pas m'authentifier au smtp...
      • [^] # Re: Utiité de tout celà

        Posté par . Évalué à 3.

        tu peux aussi simplement demander à ce membre de ta famille d'inclure gmail dans le spf du domaine et voila
        • [^] # Re: Utiité de tout celà

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

          Ouep, mais j'ai parlé de la solution la plus simple et qui me permet aussi d'éviter de communiquer mon adresse gmail quand j'utilise mon autre adresse email. (ouais l'email gmail est fournie dans l'email et certains clients email répondent à cette adresse...)
          • [^] # Re: Utiité de tout celà

            Posté par . Évalué à 2.

            euh bah tu peux pas, en plus d'ajouter gmail au SPF, configurer correctement ton client mail (gmail ou client lourd) pour que le return-path et le reply-to soient configurés comme étant ton adresse habituelle ?
          • [^] # Re: Utiité de tout celà

            Posté par . Évalué à 2.

            ah au temps pou moi, trompé de personne, j'ai cru que tu étais l'auteur du journal... je reformule donc :

            → tu configures un SPF pour déclarer le serveur gmail comme envoyant légitimement des mails depuis ton domaine et tu configures le reply-to/return-path de ton client mail : ainsi, dans ton mail, est clairement spécifié qu'il faut que les réponses te soient envoyées à ton adresse email et pas celle de gmail.
            • [^] # Re: Utiité de tout celà

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

              Dans gmail, si tu utilises un compte sur un autre serveur et que tu n'utilises pas le smtp de ce serveur, alors il rajoute dans l'header des emails ton adresse gmail.
        • [^] # Re: Utiité de tout celà

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

          Moi, si j'était l'adminstrateur du nom de domaine en question : pas question, je n'ai pas mon nom de domaine et mon serveur pour déléguer l'envoi à tout Google. D'ailleurs c'est contraire à l'idée de SPF, d'autoriser des gens qu'on ne contrôle pas du tout à poster.

          Donc, toujours si j'était l'adminstrateur : si tu veux utiliser ton adresse chez moi, tu poste par chez moi. Si tu ne veux pas, tant pis, utilise ton adresse chez Google et fais pas chier.
          • [^] # Re: Utiité de tout celà

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

            Est-ce qu'on peut envoyer un email depuis le smtp de gmail sans être authentifié ? Et est-ce qu'on peut envoyer depuis le smtp de gmail un email depuis une autre adresse sans être passé par leur mécanisme de vérification d'appartenance de l'adresse email ?

            En fonction de la réponse à ces questions, tu peux peut-être envisager de considérer le serveur de gmail assez sécurisé pour autoriser l'émission d'emails depuis lui.
            Cela dit, puisque gmail permet d'utiliser le smtp du compte en question... À voir ce que tu préfères : des gens qui fillent à gmail les identifiants de leur compte smtp sur ton serveur, ou autoriser l'envoi d'emails depuis leurs serveurs ?
            • [^] # Re: Utiité de tout celà

              Posté par . Évalué à 2.

              Si je ne me trompe pas, le return-path est réécrit par google avec l'adresse du compte gmail par lequel tu t'authentifies. Mais ils ne changent pas les adresses du corps du message.
              C'est pour dire que oui les serveurs de gmail sont sécurisés, mais pas toujours très pratiques pour relayer son courrier, à cause de la réécriture d'adresse.
              Et ensuite, puisque gmai réécrit les adresses, on ne peut pas détecter lors de la transaction smtp qu'en fait le mail devait à la base être simplement relayé par google. Autoriser l'envoi de mail relayé depuis google ne servira à rien, puisque ça n'existe pas au niveau smtp.
  • # Rappel : buts de SPF et DKIM

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

    Alors, je crois qu'un rappel s'impose.

    SPF n'est pas une mesure contre le spam, ni contre l'usurpation d'adresse. En effet :
    — il n'empêche pas le spam, qui n'a qu'à être envoyé avec une adresse dans une nom de domaine dédié, ou autorisant n'importe quoi, ou sans politique SPF ;
    — il n'empêche pas l'usurpation d'adresse, puisqu'il s'applique à l'adresse d'expéditeur d'enveloppe — MAIL FROM — et que ce que les gens voient, c'est l'adresse d'expéditeur des en-têtes — From.

    SPF est une surtout une mesure contre le backscatter, c'est à dire les notifications d'erreurs abusives qui font suite aux spams envoyés avec des adresses d'expéditeur d'enveloppe usurpés.

    DKIM n'est pas une mesure contre le spam, ni contre l'usurpation d'adresse. En effet :
    — il n'empêche pas le spam, qui n'a qu'à être envoyé avec une adresse depuis un nom de domaine dédié, en signant les messages correctements, ou sans signature DKIM ;
    — il n'empêche pas l'usurpation d'adresse, puisqu'à cause de serveurs de ML qui modifient les messages, il ne peut pas être utilisé en blocage.

    DKIM est surtout une mesure contre les abus involontaires d'un serveur d'un nom de domaine. En effet, il permet, pour un message donné, d'être sûr qu'il est bien passé par un serveur autorisé pour le nom de domaine qui l'a signé — ou que, si ce n'est pas le cas, c'est la faute de l'admin qui s'est fait voler sa clef privée — et donc d'envoyer un message à <abuse@>.
    • [^] # Re: Rappel : buts de SPF et DKIM

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

      DKIM est surtout une mesure contre les abus involontaires d'un serveur d'un nom de domaine.

      Involontaires au sens de : non autorisés par l'adminstrateur et effectués à son insu. C'est à dire les abus d'utilisateurs et les piratages.

      Dans le cas d'un administrateur complaisant avec les spammeurs, après en avoir acquis la certitude : blocage complet.
    • [^] # Re: Rappel : buts de SPF et DKIM

      Posté par . Évalué à 2.

      À vrai dire, je pense que DKIM peut encore avoir une utilité, au sens où signer les messages peut être utile, dans le cas où le destinataire doit être sûr du serveur d'émission, Là c'est une sorte de signature gpg automatisée. Et ça peut servir dans le cas que tu donnes par exemple, même si couramment c'est plutôt les adresses ip des serveurs d'envoi qui servent à repérer lesquels sont sources de spam.
      Mais jusque là j'ai l'impression que spf est assez inutile au fond, même pour le backscattering. Il n'est pas possible de distinguer les mails forgés et illégitimes des mails non forgés et légitimes quand ceux-ci sont relayés par des serveurs non autorisés, à part par la quantité de spam, ce qui renvoie au blocage par adresse ip ou nom de domaine. Les politiques spf les plus courantes sont de plus ? ou ~ ce qui n'arrange rien. Mais c'est logique, parce que c'est rare que tous les mails d'un domaine sortent d'une liste précise et fixe de serveurs.
      Et merci pour les précisions :)

Suivre le flux des commentaires

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