Journal SPF désigné vainqueur dans le match contre Sender ID

42
21
juil.
2012

L'IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d'authentification faible du courrier électronique par le biais de la publication dans le DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, SPF et Sender ID. Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender ID. Six ans après est publié le RFC 6686 qui conclut enfin officiellement que Sender ID est un échec total et que seul SPF est déployé et utilisé.

  • # Erreur dans le numéro

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

    6686, pas 6696. Désolé mis j'ai l'impression qu'on ne peut pas modifier un journal, juste ajouter des commentaires.

  • # 6 ans ?

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

    Le groupe a été créé en 2004 non ?

    Pourtant, dans le journal il est indiqué que la RFC a été publiée 6 ans plus tard. Je pense qu’il y a un soucis : 2012 - 6 = 2006 :)

    • [^] # Re: 6 ans ?

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

      Les six ans, c'était à partir de la dissolution du groupe et de la publication des premiers RFC, en 2006. Deux ans étaient annoncés, cela en a pris six.

  • # Type DNS

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

    Concernant cette histoire de type DNS, j'imagine que le type SPF avait été créé pour permettre d'effectuer des requêtes ciblées — par exemple example.com. SPF — renvoyant directement les enregistrements SPF, plutôt que de demander du TXT — example.com. TXT — et de recevoir potentiellement d'autres informations — TXT n'étant pas réservé à SPF — à rejeter au tri.

    Il est à noter que pour les protocoles à la SPF, conçus un peu plus récemment, ce système d'enregistrement a été remplacé par des noms spécifiques. Si SPF devait être conçu aujourd'hui, ou revu, on utiliserait plutôt des enregistrement du style _spf.example.com. TXT.

    • [^] # Re: Type DNS

      Posté par . Évalué à 1.

      Sur le problème d'adoption du type SPF, en plus des arguments cités et repris dans l'analyse de Stephane, j'y vois aussi que très peu d'organismes maitrisent leur serveur DNS et que donc, même s'ils ont une volonté de changement, ils ne sont pas les acteurs de celui-ci. Ils ne peuvent que suggérer.

      Que ce soit les domaines que je connais tant au niveau professionnel que personnel, les DNS qui les gèrent ne proposent pas l'enregistrement SPF. Au niveau personnel, je pourrais tout à fait gérer mes propres DNS et résoudre cela, mais je n'ai jamais vraiment trouvé justification à le faire(contrairement à un MX secondaire ;), rapport à un autre excellent journal de Stephane).

      De plus quand j'avais regardé cette question d'enregistrement SPF je trouvais ça compliqué à mettre en œuvre (pour toutes les raisons cités) alors que la solution existante, sur l'enregistrement TXT, fonctionnait très bien, et que ce changement incluait un risque que je ne trouvait pas nécessaire de prendre.

    • [^] # Re: Type DNS

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

      C’est d’ailleurs ce que fait google en partie :

      ~# dig +short TXT gmail.com
      "v=spf1 redirect=_spf.google.com"
      ~# dig +short TXT _spf.google.com
      "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
      
      

Suivre le flux des commentaires

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