Sender Policy Framework
 
Le système Sender Policy Framework (SPF) permet au propriétaire d'un nom de domaine ("exemple.com") d'utiliser les champs de type « TXT » du système DNS afin de spécifier quels sont les serveurs de messagerie autorisés à envoyer des messages pour ce nom de domaine. Ce système s'appuie sur le principe que les informations présentes dans les enregistrements DNS sont correctes et de confiance. On va ainsi identifier de façon explicite les serveurs de mail autorisés à émettre des mails pour un nom de domaine.

Lors de la réception d'un message, le serveur de mail va vérifier, via une requête DNS, via les enregistrements de type « TXT » si le message est bien en provenance des serveurs de mails listés comme "de confiance". Si le mail provient bien d'un serveur listé alors le mail est considéré comme "non spam". Dans le cas contraire, le message est rejeté.
 
Ce système est simple, mais souffre de quelques problèmes :

• Bien que techniquement simple à mettre en place, il est encore très peu utilisé. Il est donc impossible de tagger en "spam" un mail si aucune information n'est présente dans les champs TXT du nom de domaine de l'émetteur des messages (c'est le cas pour la très grande majorité, sinon la totalité des noms de domaines actifs sur Internet) : Les spammeurs sont dans ce cas en mesure d'émettre des messages en masquant leurs messages comme provenant de la société "exemple.com".

• SPF considère aussi que le serveur de messagerie à l'origine des messages n'a pas été compromis et qu'il n'est pas non plus en mode "relais ouvert". Un serveur en relais ouvert implémentant du SPF est donc une prise de choix pour un spammer.

• Ce système pose aussi problème dans le cas ou les messages sont renvoyés (forward) d'un serveur à un autre : Avec SPF, il faudrait que les serveurs de relais ("forwarders") soient aussi présents dans la zone DNS du domaine concerné... difficile à mettre en place !
• 
  

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) est un système dans lequel l'émetteur d'un message insère dans l'entête de celui-ci une signature électronique cryptographique de sorte que le serveur recevant le message va être en mesure de vérifier la source mais ainsi l'intégrité du message et de certains de ses entêtes.

Lors de la réception d'un message, le serveur va vérifier la signature en utilisant pour ce faire la clef publique de l'émetteur qui aura été publiée préalablement par le serveur émetteur dans une zone DNS spécifique. Si la signature est vérifiée avec succès alors l'origine et le contenu du message sont authentiques. Dans le cas contraire, le système peut réagir en rejettant le mail, en le détruisant ou en le redirigeant.

Au même titre que pour SPF, le système DKIM souffre aussi de quelques problèmes :

• Il est encore une fois très peu utilisé coté émetteurs de mails, très peu de mails sont signés : donc pas grand chose à se mettre « sous la dent » coté serveurs en réception.

• Toute modification du message ayant pour effet de rentrer invalide la signature numérique, l'insertion de "legal disclaimers" ou d'indication de test de détection de code malicieux via un antivirus va provoquer un changement du message donc rentre la signature invalide. A noter que qu'il est possible de rajouter dans les entêtes le résultat d'un test antivirus sans rendre la signature invalide : La liste des entêtes pris en compte lors du calcul de la signature est elle-même fournie dans l'entête DKIM.

• Un serveur de mail devant vérifier la signature électronique de chaque message entrant, cela va mécaniquement générer une augmentation de la charge de traitement sur les serveurs de messagerie. Ceci dit, vu le très petit nombre de message signés, ce n'est pas un problème en soit !

SenderID

Le système SenderID est très similaire à SPF : Alors que SPF s'efforce de protéger l'enveloppe du message (ie le contenu des informations présentes dans les commandes SMTP de serveurs à serveurs) ; SenderID vise à protéger certains entêtes du message lui-même.

Afin d'identifier quels serveurs ont le droit d'émettre des messages pour le compte d'un nom de domaine, les deux systèmes utilisent les enregistrements présents dans les zones DNS des noms de domaine : La syntaxe des informations des enregistrements TXT est de plus la même entre SPF et SenderID.

SenderID et SPF sont donc similaires dans le sens ou ils ont comme objectif de vérifier la véracité de l'émetteur des messages associés à un nom de domaine précis, cependant ils fonctionnent à un niveau protocolaire différent : Dans ce sens, SenderID est plus proche de DKIM que de SPF.Il existe certaines polémiques quand à SenderID et son respect des normes, notamment avec SPF.

DKIM, SenderID et SPF : Un rapide benchmark

- SPF reste une solution simple à mettre en œuvre mais qui pose une contrainte importante : comme la vérification est en mode point à point (ie d'un serveur de mail à un autre ; ou MTA à MTA ) il ne fonctionne pas dans le cas de forwarders ou de relais.

- DKIM est quant à lui un peu plus complexe à mettre en place (quoi que) mais donne une vérification de bout en bout (ie, l'émetteur signe son mail, le destinataire vérifie) : Il peut y avoir des serveurs de relais entre deux, cela ne pose aucun problème.

- SenderID est en pleine perte de vitesse. Parier sur ce cheval c'est partir perdant !

Autrement dit : La solution d'avenir est DKIM mais SPF peut être un début de réponse.

Par quel bout commencer ?

Sur vos serveurs SMTP d'envoi de mails
- Configurez vos serveurs DNS afin que vous soyez « SPF ready » en y ajoutant les enregistrements TXT qui vont bien au niveau de vos zones DNS. L'investissement est assez minime.
- Encore mieux, signez vos mails en DKIM. C'est un investissement à long terme. De plus en plus de serveurs de mails supportent DKIM.

Sur les serveurs de réception de mails

- Intégrez SPF dans votre système de scoring : Un mail validé a plus de chances d'être véridique car émis d'une source « fiable ». Ne basez cependant vos décisions uniquement sur ce type de test.

- Si une signature DKIM est présente, vérifiez la. Encore une fois, c'est DKIM est la voie royale vers plus de confiance dans le domaine des communications emails

Pour ceux qui rétorqueront que SPF et DKIM ne sont pas encore déployés et que donc ça ne sert à pas grand chose de s'exciter sur le sujet, j'aurai une recommandation très "terre à terre", surtout si vous êtes la cible d'attaques récurrentes de phishing :

Établissez des relations bilatérales avec des opérateurs de plateformes de messagerie, rapprochez-vous d'eux pour qu'ils considèrent n'acceptent les mails s'identifiant comme provenant de vous et vérifiés via DKIM ou SPF. De la sorte, les clients de l'opérateur de la plate-forme de messagerie ne recevront donc plus d'emails de phishing usurpant l'identité de votre société. Il va de soit que vous devrez trouver un bénéfice commun afin de motiver l'ensemble des parties concernées.

En conclusion

Les systèmes SPF et DKIM sont des systèmes encore peu utilisés. Leur potentiel est  intéressant mais reste limité du fait de leur faible niveau de déploiement au niveau mondial.

Afin de casser ce problème assez classique de la poule et de l'œuf, commencez à activer SPF sur vos serveurs de messagerie et intégrez-le dans vos mécanismes de scoring sur vos serveurs de réception. Les plus consciencieux complèteront leur dispositif via DKIM afin d'en étendre d'adoption, ou commenceront directement par DKIM...(this is the way to go)

Si vous êtes un acteur Internet de taille respectable et suffisamment motivé, la mise en place de ces mécanismes au cas par cas vous permettra d'en retirer plus rapidement la valeur : Cela permettra de protéger vos clients contre les messages usurpant votre identité.

C'est un sujet que nous seront amenés à rediscuter tant le domaine est vaste et intéressant.

Remerciements : Un « kudo » à Sylvain Houdusse, expert dans le domaine pour avoir eu la gentillesse de relire ce bulletin.