Ceci est à l'origine d'une partie des problèmes de spam rencontrés actuellement : les spammeurs peuvent se forger une identité (une adresse mail) pour émettre des messages semblant provenir de bill gates ou d'un utilisateur de hotmail, yahoo ou caramail. Par la suite, la victime (le destinataire) aura l'impression que l'émetteur du message de spam est légitime, puisqu'il connaît sinon l'émetteur, du moins le domaine de l'adresse mail utilisée.

L'une des techniques les plus courantes des spammeurs consiste à utiliser un relais de messagerie mal configuré pour envoyer un grand nombre de "pourriels" (terme consacré pour la françisation de spam). Les technologies présentées ici n'empêcheront certainement pas l'utilisation de tels relais. Néanmoins, ils permettraient (dans un monde idéal) de compliquer la vie des spammeurs en les empêchant d'utiliser des domaines arbitraires comme source de leurs messages.

Actuellement, la standardisation de ces technologie est en cours et aucune d'entre elle ne s'est affirmée comme la seule et l'unique devant être utilisée sur Internet. Aucune n'a notamment atteint le stade de standard reconnu, et elles seront par ailleurs probablement complémentaires.

Sender Policy Framework

SPF est destiné à limiter l'utilisation abusive d'adresses e-mail émettrices. Définie actuellement dans un draft (http://spf.pobox.com/draft-ietf-marid-protocol-00.txt) elle a pour vocation de permettre à un relais de messagerie recevant un courriel de vérifier auprès du domaine concerné si l'émetteur (au sens IP du terme) est bien un émetteur légitime.

Pour comprendre plus précisément le fonctionnement de ce solution, imaginons qu'une entreprise possédant le domaine business.com souhaite déployer cette technologie. Il est important de préciser :

  • Qu'elle agira au niveau de ses serveurs DNS.
  • Que l'adoption de cette norme lui permettra de fournir des informations aux destinataires des courriels émis par ses employés. Ces informations concerneront les serveurs de messagerie autorisés à envoyer des messages utilisant comme émetteur des adresses en business.com.

Elle ne se protégera donc pas elle-même contre les spams, mais contribuera à protéger les autres utilisateurs. C'est d'ailleurs le cas pour l'ensemble des technologies décrites dans cet article : mis en place par les grands acteurs d'Internet (et notamment les ISPs et les fournisseurs d'adresses de messagerie gratuites), elles permettent de renforcer la lutte globale contre le spam et le spoofing d'adresses mail, mais ne protègent pas spécifiquement les utilisateurs de ceux qui les déploient.

L'utilisation de SPF consiste alors à modifier le serveur DNS de la zone business.com en lui ajoutant un champ de type TXT. Les champs de type TXT sont destinés à fournir des informations textes sur les informations de la zone ou la zone elle-même.

Dans le cas de SPF, on va ajouter un champ TXT concernant l'ensemble de la zone, de la forme suivante :

business.com. IN TXT "v=spf1 mx -all"

Cette entrée précise que la zone business.com fournit des informations conforme au standard SPF1 (v=spf1). Elle précise de plus que seuls les mx de la zone business.com sont autorisés à envoyer des e-mails provenant de cette zone (mx). La chaîne -all permet de préciser que le comportement par défaut est de refuser un message provenant d'un serveur de messagerie non listé précédemment.

Ainsi, dans cet exemple, lorsque le serveur de messagerie du domaine client.com recevra un message provenant de l'utilisateur emetteur@business.com, envoyé par le serveur disposant de l'adresse IP 1.2.3.4 et à destination de dest@client.com, il procèdera aux vérifications suivantes :

  1. Récupération de l'adresse IP de l'émetteur : 1.2.3.4
  2. Récupération du domaine de l'émetteur : business.com
  3. Interrogation du champ TXT au format SPF1 du domaine business.com auprès de son serveur DNS :
    business.com. IN TXT "v=spf1 mx -all"
  4. Interrogation de ce même serveur DNS pour vérifier la liste des serveurs MX de la zone
    business.com IN MX 5 1.2.3.4
    business.com IN MX 10 5.8.6.1

Dans le cas où l'adresse IP de l'émetteur fait partie des émetteurs autorisés (ce qui est le cas ici), le message est accepté. Dans le cas contraire, la politique de sécurité est appliqué. Le message peut par exemple être marqué comme du spam (pour permettre à l'utilisateur de le trier) ou être supprimé purement et simplement.

Le champ SPF peut aussi être construit de manière plus complexe, en précisant par exemple la liste explicite des adresses IP autorisées (à l'aide de l'option a:), ou encore en renvoyant vers le champ SPF associé à une autre zone. Ainsi, si la société possédant le domaine business.com possède aussi le domaine business.fr, elle pourra préciser le champ suivant pour cette dernière zone :

business.fr. IN TXT "v=spf1 include:business.com -all"

De cette manière, elle n'aura à maintenir qu'une seule liste des émetteurs autorisés, celle associés à son domaine principal

Une des limites de cette technologie est qu'elle se contente d'analyser l'instruction MAIL FROM du protocole SMTP (l'enveloppe du message) et non son entête From:. Or les spammeurs contournent déjà cette limitation en utilisant au niveau SMTP une adresse email différent de celle précisée dans l'entête, qui est celle affichée par le logiciel de messagerie des utilisateurs.

Pour une description plus précise de cette technologie, on pourra se référer à la proposition de HOWTO rédigé par la société Zytrax.

Domainkeys

Yahoo a, de son côté, développé une solution pour lutter contre le spam en empêchant les spammeurs d'envoyer des messages en utilisant des adresses émettrices arbitraires. Elle est expliquée dans un draft . Yahoo possède sur cette technologie un certain nombre de brevets, mais n'en a restreint l'usage d'aucune façon (à ma connaissance, car je ne suis pas juriste), contrairement à la solution de Microsoft exposée plus bas.

L'idée de cette solution est de permettre la signature par le relais émetteur des messages et la vérification de cette signature par les destinataires.

Ainsi, si on reprend l'exemple cité ci-dessus, les administrateurs de business.com commmencent par créer une paire de clé publique/clé privée destinées à signer les messages émis par le relais sortant. A chaque fois qu'un email sera envoyé, le relais ajoutera un entête appelé DomainKey-Signature qui contiendra la signature du message avec sa clé privée. Cet entête est rajouté avant le reste du message (y compris son entête) et n'est pas utilisé pour calculer la signature :

  • DomainKey-Signature: a=rsa-sha1 s=blah; d=business.com;

  • c=simple; q=dns;
  • b=dzdVyO...iYzR;

On précise alors l'algorithme utilisé (rsa-sha1), des informations nécessaires pour retrouver la clé publique associée (blah, voir plus bas), le nom de domaine associé à la signature (business.com), l'algorithme utilisé pour "canoniser" le message (simple) et la méthode pour récupérer la clé publique (dns).

Dans la plupart des cas, la signature est calculée à partir de la ligne suivant l'entête DomainKey-Signature. Néanmoins, il est possible de préciser dans ce champ quels sont les entêtes à intégrer dans la signature (à l'aide de l'option h=)

Par la suite, les relais de messagerie intermédiaires ajoutent des informations dans l'entête du message, mais ils le font au début, avant le champ DomainKey-Signature. La signature n'est donc pas modifiée.

Lors de la réception du message par le relais de messagerie du domaine du destinataire, celui-ci récupère le champ DomainKey-Signature et s'apprête à effectuer un ensemble d'action de vérification de signature :

  1. Analyse de l'entête DomainKey-Signature pour récupérer le nom de domaine concerné et construire la requête DNS permettant de récupérer la clé publique associée.
  2. Requête auprès du serveur DNS du domaine émetteur. Dans l'exemple pris ici, l'enregistrement TXT de l'entrée blah._domainkey.business.com sera utilisé. _domainkey est réservé dans ce but, et blah est précisé dans l'entête (voir la description du champ DomainKey-Signature ci-dessus). Ceci permet à l'administrateur du domaine de l'organiser comme il l'entend.
  3. Récupération et analyse de ce champ. On précise notamment l'algorithme à l'aide du champ k= et la clé publique, encodé en Base64, à l'aide du champ p=
    4. blah._domainkey IN TXT "k=rsa; p=MHww ... IDAQAB"
  4. Muni de cette information, le serveur de messagerie destinataire peut appliquer sa politique de sécurité, par exemple en marquant ce message comme du spam ou en le supprimant purement et simplement.

Contrairement à SPF, Domain Keys analyse le champ From: de l'entête et ne se content donc pas de travailler au niveau SMTP.

Le défaut de cette technique est qu'elle introduit un traitement supplémentaire au niveau du relais de messagerie émetteur, qui risque d'être consommateur en ressource CPU.

Sender ID : extension Microsoft de SPF

Sender ID est la solution issue de la fusion de la proposition de Microsoft et de SPF v1. Elle est définie sur la page Sender ID FrameWork. En septembre 2004, l'IETF a refusé de normaliser officiellement cette proposition, et AOL a annoncé que pour sa part elle ne la soutiendrait pas. On peut donc penser que, par rapport aux deux solutions présentée ci-dessus, Sender ID est en perte de vitesse et risque de ne pas parvenir à s'imposer.

Sender ID est un complément à SPF. De la même manière, il repose sur des enregistrements DNS précisant les relais de messagerie autorisés à envoyer des messages provenant d'un domaine particulier.

Ces entrées commencent par la chaîne spf2, indiquant par là la filiation avec la norme SPF :

spf2.0/pra mx a:81.91.65.187 -all

Sender ID complète SPF en précisant que le champ From: de l'entête devrait être vérifié en plus de l'adresse de l'enveloppe SMTP.

Elle introduit aussi la notion de PRA (Purported Responsible Address) permettant de déterminer l'adresse mail responsable de l'envoi du message. Dans le cas de mailing-lists par exemple, ce n'est pas forcément l'adresse précisée dans le champ From:. Sender ID définit alors un algorithme capable de retrouver l'adresse responsable.

Elle propose de plus l'ajout de la commande SUBMITTER au protocole SMTP afin de résoudre les problèmes posés par cette technologie concernant la forwarding des messages.

En effet, supposons que l'utilisateur emetteur@test.com envoie un message à forward@tempo.com, et que ce compte de messagerie soit configuré pour transmettre (forwarder) tous les messages à destination de dest@final.com. Si l'émetteur du message utilise Sender ID (ou SPF d'ailleurs), il pourra l'envoyer à tempo.com, qui sera chargé de simplement le transmettre à final.com. Le problème est que l'adresse mail source du message sera emetteur@test.com, mais que le message proviendra de l'adresse IP du relais de messagerie de tempo.com. Ce dernier ne sera pas indiqué dans la liste des relais de messagerie autorisés pour le domaine test.com, ce qui est normal puisqu'il n'est pas lié à ce domaine. Le relais de messagerie de final.com considérera alors ce message comme du spam ! Pour résoudre le problème, Microsoft a proposé avec Sender ID d'ajouter un commande SUBMITTER au protocole SMTP, passé avec la commande MAIL FROM:. Ainsi, dans notre exemple, on aurait :

MAIL FROM: emetteur@test.com SUBMITTER=forward@tempo.com

Ainsi le relais recevant le message est informé que le message a transité par le domaine tempo.com et peut aller faire ses vérifications auprès de lui.

A noter que la solution SPF version 1 ne dispose pas d'une telle solution de contournement, et que son promotteur, pobox propose tout simplement que le relais de messagerie de tempo.com ré-écrive l'adresse email de l'émetteur (au niveau SMTP, puisque SPF v1 ne travaille qu'à ce niveau). Cette solution est appelé SRS (pour Sender Rewriting Scheme) et consiste alors à réécrire l'adresse email de l'émetteur en emetteur=test.com@tempo.com. Ainsi le serveur destinataire ira chercher les informations de SPF auprès du serveur DNS de la zone tempo.com, tout en étant capable de retrouver l'émetteur initial du domaine (en supprimant le @tempo.com et en remplaçant le = par un @). Néanmoins, ceci requiert de modifier l'ensemble des relais de messagerie, y compris ceux ne supportant pas SPF et SRS, afin qu'ils puissent au moins retrouver l'émetteur original du message.

Alternatives

Les trois solutions présentées ci-dessus ne sont pas les seules. Plusieurs autres, non soutenues par des groupes tels que Yahoo ou Microsoft, coexistent :

  • Client SMTP Validation précise que le client SMTP doit préciser dans le champ HELO son nom DNS, et que le relais de messagerie cible doit vérifier que l'adresse IP du client correspond à l'adresse IP associée à son nom DNS. Cette solution a l'avantage de la simplicité, et empêche les spammeurs de prétendre émettre des messages depuis smtp.yahoo.com par exemple
  • RMX est une alternative aux solutions SPF et Sender ID, fonctionnant lui-aussi au niveau des adresses mail SMTP. RMX précise lui aussi la liste des adresses IP autorisées à émettre des messages pour un domaine donné, mais propose de diffuser cette information via les protocoles HTTP, HTTPS ou encore LDAP.

Limites et conclusion

En conclusion, il est important de retenir qu'aucune de ces solutions ne constitué la panacée :

  • Dans tous les cas, elles demandent une adoption large pour commencer à être utiles et efficaces dans la lutte contre le spam. Il est évident que ce point est difficilement évitable
  • En attendant cette phase de diffusion plus importante, à nouveau quelle que soit la technologie, la "protection" n'est efficace que si à la fois l'émetteur et le destinataire l'implémente. business.com peut très bien diffuser des entrées SPF, si personne ne les vérifie, cela sera inutile. De même, configurer un relais de messagerie pour qu'il vérifie les informations Domain Keys alors qu'aucun n'émetteur n'en fournit s'avance pas à grand chose.
  • Certaines solutions posent des problèmes importants d'implémentation, tel le problème concernant le forwarding pour SPF et Sender ID.
  • Ces solutions n'empêchent pas un spammeur de créer le domaine businesss.com (avec trois s à la fin) et de l'utiliser pour émettre des mails en provenant de ce domaine.

Il est donc important de garder à l'esprit que ces solutions permettent de compléter la lutte contre le spam, qu'elles sont souvent complémentaires et à implémenter ensemble (par exemple SPF + DomainKeys), et qu'elles ne signifient pas qu'il faille abandonner les solutions utilisées jusqu'alors, telles que les listes RBL ou les logiciels de détection de spam tels que SpamAssassin, SpamBayes ou les produits proposés par les principaux éditeurs du marché.