| We need Your Support. Make a Donation now! or |  |
|
La FAQ de hashcashTraduction de l'anglais par Guillaume Cottenceau. Click here for the English version of this FAQ.
Il y a deux probl�mes avec le spam :
La perte d'emails � cause du spam et des techniques anti-spam est un effet secondaire d'un grand nombre de techniques anti-spam, comme par exemple :
Hashcash est une approche technique de r�duction de l'impact du spam. Le but de hashcash est de rendre l'email plus fiable. C'est une technique qui doit accompagner l'utilisation d'un anti-spam. Peu importe quel anti-spam vous utilisez, vous devez le configurer pour qu'hashcash puisse passer outre les filtres et blocages mis en place, afin que les autres utilisateurs de hashcash puissent vous envoyer des emails de mani�re fiable. De m�me, en tant qu'exp�diteur, vous utilisez hashcash afin que les filtres chez le destinataire ne soient pas d�clench�s, et que votre email soit le plus fiable possible.
Hashcash se pr�sente sous la forme d'un plugin pour les clients mail, qui ajoute des timbres hashcash aux emails � envoyer. Le plugin hashcash ins�re un ent�te X-Hashcash: dans les emails que vous envoyez. Vous pouvez voir ci-dessous un exemple d'email qui m'a �t� envoy� avec un timbre hashcash dans les ent�tes :
From: Quelqu'un <test@test.invalid>
Les spammeurs peuvent eux aussi utiliser hashcash, cependant hashcash leur pose un gros probl�me parce que la g�n�ration du timbre hashcash consomme du temps de processeur. Pour vous en tant qu'utilisateur l�gitime, avec une machine de bureau tout � fait normale ou bien encore un portable, le temps de processeur n�cessaire est n�gligeable parce que vous n'envoyez pas tant d'emails que �a ; au pire, votre email sera ralentit de quelques secondes avant d'�tre envoy� si vous utilisez une vieille machine particuli�rement lente. Cependant, pour les spammeurs c'est une autre histoire : ils envoient plus de 10'000 emails par minute par une ligne ADSL achet�e avec une carte de cr�dit vol�e, le plus vite possible avant que le compte ne soit supprim�.
Les spammeurs s'introduisent d�j� de mani�re non l�gitime sur beaucoup d'ordinateurs de simples utilisateurs, afin de cr�er ce qu'on appelle des arm�es de "zombies" � partir desquelles ils envoient du spam. Cependant, � l'heure actuelle, la quantit� d'emails que les spammeurs peuvent envoyer � partir de ces zombies est limit�e par la vitesse de la connexion Internet utilis�e. Une ligne ADSL moyenne pourra envoyer 25 messages diff�rents par seconde d'une taille de 1 Ko (avec une ligne � 256 kbit en upload). Ou bien beaucoup plus de messages par seconde si les messages sont envoy�s � plusieurs destinataires en m�me temps (en utilisant les copies ou copies cach�es - CC ou BCC). Un simple timbre hashcash de 20 bits n�cessite une demie seconde par destinataire de temps de processeur sur l'ordinateur personnel le plus puissant au moment o� ces lignes sont �crites. Cela ralentirait donc les spammeurs d'un facteur de 10 � 100 ou plus (en fonction du fait que les messages sont envoy�s � un seul ou � plusieurs destinataires).
Les spammeurs optimisent souvent la quantit� de spam qu'ils peuvent envoyer en destinant leurs messages � des centaines voire des milliers d'adresses � l'aide de copies cach�es (BCC). De cette mani�re, ils peuvent ne consommer que 3,5 Ko de bande passante pour envoyer � 100 destinataires, au lieu de 100 Ko qui serait n�cessaire s'ils envoyaient chaque messages s�paremment. Cela permettrait � un spammeur d'envoyer 700 messages par seconde (avec une ligne ADSL � 256 kbit en upload). Envoyer de cette mani�re r�duit la personnalisation que le spammeur peut effectuer parce que tous les contenus de message d'un paquet donn� sont n�cessairement les m�mes, mais malgr� cela les spammeurs sont friants de cette technique qui leur permet d'accro�tre sensiblement la quantit� d'emails qu'ils peuvent envoyer par seconde. Cependant, avec hashcash un timbre diff�rent est n�cessaire pour chaque destinataire, ce qui r�duit � n�ant cette technique. Si le spammeur doit mettre un timbre hashcash pour chaque destinataire, m�me un Pentium-4 � 3 GHz ne pourra g�n�rer que 2 timbres par seconde, en comparaison de 700 par seconde sans timbre hashcash, donc l'utilisation de hashcash dans ce cas de figure ralentirait la quantit� de spam envoy� d'un facteur 350.
Pas vraiment. Au pire votre email sera retard� de quelques secondes avant d'�tre envoy�. Mais des plugins de meilleure qualit� seront capable de cr�er le timbre hashcash en arri�re plan lorsque vous �crivez votre email, ou aura suppos� que vous souhaitez r�pondre aux emails que vous recevez et aura d�j� cr�� les timbres n�cessaires lorsque vous le ferez. De plus, certains plugins hashcash peuvent automatiquement reconna�tre la pr�sence d'un timbre et whitelister (le contraire de blacklister), ou exempter les personnes avec lesquelles vous communiquez fr�quemment : par exemple les personnes de votre carnet d'adresse, ou les personnes auxquelles vous r�pondez. Un exemple est le syst�me CAMRAM qui est bas� sur hashcash, et qui pratique ces distinctions (CAMRAM veut dire "CAMpaign for ReAl Mail", "Campagne pour de Vrais Emails", c'est un jeu de mot sur une pub pour de la bi�re anglaise). Les whitelists automatiques r�duisent encore plus le temps de processeur pour les utilisateurs l�gitimes, parce que votre plugin hashcash cr�era des timbres uniquement pour le premier email que vous enverrez � une nouvelle personne. Mais c'est un b�n�fice interdit aux spammeurs parce qu'ils ne pratiquent pas une communication bidirectionnelle -- ils envoient du spam, qui par essence n'est qu'une communication unidirectionnelle, et tr�s peu d'utilisateurs auront normalement l'id�e de rajouter le spammeur sur leur whitelist.
Les FAI et les destinataires qui utilisent des antispams bas�s sur le filtrage par mots-cl�, les blacklists, les incoh�rences dans les entr�es DNS, etc, commencent � utiliser hashcash comme exception dans le tri du spam. Votre email qui est "affranchi" -- avec le timbre hashcash -- navigue � travers les filtres antispam sans jamais �tre refus�. Cela accro�t la fiabilit� parce que les antispam sont surcharg�s et commettent des erreurs comme le fait de bloquer des emails qui ne sont pas en r�alit� du spam.
Hashcash est support� par SpamAssassin � partir de la version 2.70. SpamAssassin est un antispam tr�s utilis� par les utilisateurs et les FAI. Il utilise le filtrage par mots-cl� (et d'autres techniques) pour supprimer le spam. Si vous jetez un coup d'oeil � vos ent�tes d'emails et que vous trouvez X-Spam-Checker-Version: SpamAssassin, cela veut dire qu'ils ont �t� examin�s par SpamAssassin. Hashcash est aussi support� par TMDA et CAMRAM. Cela veut dire qu'en envoyant des timbres hashcash dans vos emails, vous pouvez virtuellement �liminer les chances de subir un faux positif, et donc par la m�me occasion vos emails seront bien d�livr�s au destinataire, sans �tre plac�s dans le dossier poubelle si le FAI du destinataire ou lui-m�me utilise SpamAssassin, TMDA ou CAMRAM. Le nombre de syst�mes supportant hashcash est en augmentation. Si vous souhaitez ajouter le support de hashcash dans un syst�me antispam, contactez-moi, Adam Back <adam@cypherspace.org>, et je ferai mon possible pour vous y aider.
SpamAssassin est assez r�pandu chez les FAI. Si vous regardez dans les ent�tes des emails que vous recevez, et que vous y trouvez X-Spam-Checker-Version: SpamAssassin, alors cela veut dire qu'ils sont examin�s par SpamAssassin. Et m�me si votre FAI n'utilise pas SpamAssassin, r�fl�chissez : le spam augmente � un rythme tr�s �lev�. Les estimations sont variables, mais en g�n�ral autour de 10% par mois ! � ce rythme-l�, la fiabilit� des emails et leur utilit� vont se r�duire rapidement. Les techniques antispam seront probablement utilis�es pour tenter de contrer la mar�e montante du spam -- et cela rendra le taux de faux positifs encore plus important, rendant vos emails toujours moins fiables. D�j�, de nombreux FAI d�clarent que plus de 50% des emails qu'ils transmettent sont en fait du spam. Hashcash met en oeuvre quelque chose de concret pour �viter le d�sastre. Mais comme tout autre syst�me, on doit l'amorcer : plus il y aura d'utilisateurs qui s'en serviront, plus la demande sera forte pour que les logiciels antispam en tiennent compte ; de la m�me mani�re, plus la proportion de logiciels antispam � en tenir compte sera �lev�e, plus il y aura d'avantages � l'utiliser au plan personnel pour accro�tre la fiabilit� de ses emails. Utilisez hashcash d�s maintenant, prenez votre part dans la solution au probl�me du spam. C'est une question � laquelle chaque utilisateur doit r�pondre lui-m�me. Le revers de la m�daille, c'est que si vous vous mettez � ignorer les emails sans hashcash, vous pourrez tr�s bien manquer des emails que vous auriez voulu voir. Pour une utilisation standard, il faut �tre patient, et je pense qu'on ne pourra pas faire �a avant au moins 10 ans, si jamais c'est possible un jour. Il y a d'autres points de vue plus engag�s, ceci dit ; les gens qui sont vraiment trop agac�s par le spam, et qui re�oivent peu de mails l�gitimes spontan�s, peuvent adopter cette attitude radicale. On peut mettre quelque chose dans la r�ponse automatique � un mail refus� qui permet � l'exp�diteur de g�n�rer un timbre hashcash. Par exemple, il y a une applet java qui permet � tout un chacun de g�n�rer un timbre hashcash directement depuis le navigateur web. Il faut aussi pr�ciser que l'approche temporaire adopt�e par CAMRAM est d'avoir des moyens alternatifs pour entrer dans la whitelist, avec une simple r�ponse � un email.
Il y a beaucoup de probl�mes math�matiques pour lesquels il est bien plus facile de v�rifier la solution, que de calculer la solution. Par exemple, calculer une racine carr�e. Il est bien plus complexe et cela demande beaucoup plus de calcul � l'ordinateur de calculer une racine carr�e que d'en v�rifier une. Rappelez-vous que la v�rification d'une racine carr�e consiste juste en une multiplication : y = sqrt(y) x sqrt(y). Non, mais ce n'est pas si loin de la v�rit�. En fait, Dwork et Naor avaient propos� d'utiliser des racines carr�es pour illustrer la faisabilit� de la solution dans leur article de 1992 sur le sujet. Pour utiliser cette approche, il fallait utiliser des grands nombres -- d'une longueur se comptant en milliers de chiffres -- parce que les ordinateurs sont bien trop rapides pour calculer des racin�es carr�es sur des nombres de taille normale. La technique utilis�e par hashcash consiste en fait � utiliser des collisions partielles dans les hachages ("partial hash-collisions" en anglais). Ces collisions partielles sont bien plus rapides � v�rifier et faciles � programmer que des racines carr�es sur des grands nombres. Ils sont aussi plus courts (ce qui est plus pratique pour les ins�rer dans les ent�tes des emails). Hashcash est en outre non interactif ce qui est une propri�t� tr�s utile pour s'en servir dans les emails, parce que vous ne voulez pas attendre que le logiciel de votre correspondant vous envoie une r�ponse de refus automatique contenant le nombre � partir duquel vous devriez calculer la racine carr�e. Avec hashcash, vous, en tant qu'exp�diteur, vous choisissez la cha�ne de caract�res � partir de laquelle la collision partielle sera calcul�e, donc aucune interaction n'est n�cessaire. (Note technique : l'utilisation des racines carr�es poss�de une variante non interactive propos�e par l'auteur, qui consiste en une fonction de hachage et calculer des racines cubiques)
Une fonction de hachage est une fonction cryptographique dont le but est qu'il soit tr�s difficile de trouver deux donn�es d'entr�e diff�rentes qui produisent la m�me donn�e de sortie. Parmi les fonctions de hachage c�l�bres, on peut citer MD5 et SHA1 (hashcash se sert de la fonction de hachage SHA1). Les fonctions de hachage cryptographiques comme SHA1 sont con�ues pour �tre r�sistantes aux collisions. Cela signifie qu'il est normalement tr�s difficile de trouver SHA1(x) == SHA1(y) lorsque x != y. Pour SHA1, on consid�re qu'il faudrait 2^160 essais de diff�rentes valeurs de y pour trouver la m�me donn�e de sortie que ce que donne une valeur fix�e de x. (Note technique : ce dernier probl�me s'appelle r�sistance � la deuxi�me pr�-image, parce que vous commencez avec une pr�-image x fix�e, et vous essayez de trouver une autre pr�-image y. Une collision standard dans un hachage aurait �t� de trouver deux valeurs arbitraires x et y qui donnent la m�me donn�e de sortie. Les collisions arbitraires sont bien plus faciles � trouver : environ 2^80 op�rations, ce qui est d� � un principe connu sous le nom de paradoxe de l'anniversaire).
Puisque calculer une collision compl�te dans un hachage est impossible actuellement -- il n'y a pas assez de puissance de calcul dans le monde entier pour en cr�er une dans les 100 prochaines ann�es -- nous souhaitons simplifier le probl�me. Une fa�on simple de le simplifier est d'accepter une collision partielle. L� o� une collision compl�te veut dire que tous les bits de SHA1(x) sont identiques � ceux de SHA1(y), une collision partielle � k bits indique que seuls les k bits les plus significatifs doivent �tre identiques. Si par exemple nous prenons les 16 bits les plus significatifs, une collision partielle � 16 bits devient largement trouvable. En fait, mon ordinateur de bureau (un vieux pentium 2 � 400 MHz) peut en calculer une en un tiers de seconde. (Note technique : il s'agit de la deuxi�me pr�-image parce que nous commen�ons avec une valeur de x fix�e, et nous essayons de trouver une deuxi�me pr�-image telle que les r�sultats correspondent pour les 16 bits les plus significatifs)
Pour faire simple, sur l'adresses email du destinataire. En pratique, il y a quelques d�tails suppl�mentaires. Ce que hashcash fait en r�alit�, c'est chercher des collisions sur des cha�nes de caract�res telles que : 0:030626:adam@cypherspace.org:6470e06d773e05a8 dans laquelle vous pouvez distinguer une date (030626 = 2003, Juin, 26), et une adresse email (la mienne, adam@cypherspace.org). Le premier champs (le 0:) est la version du timbre, qui est fix�e � 0 actuellement. Le dernier champs -- la cha�ne de lettres tir�es aux hasard -- est juste du bruit qui permet de trouver une collision (nous devons essayer de nombreuses cha�nes diff�rentes, approximativement 2^16 pour une collision � 16 bits).
C'est une des choses pratiques avec hashcash. Il utilise SHA1, donc si vous avez une impl�mentation de SHA1 � votre disposition, vous pouvez l'essayer. Le timbre ci-dessus hach� (sans retour � la ligne) donne : echo -n 0:030626:adam@cypherspace.org:6470e06d773e05a8 | sha1Comme vous pouvez le constater, les 8 premiers chiffres sont 0. Je ne l'ai pas expliqu� auparavant, mais hashcash essaie de trouver une collision avec une s�rie de chiffres � 0. Donc le timbre ci-dessus est une collision sur 32 bits. C'est une collision exceptionnellement longue qui a demand� environ 7 heures de calcul � mon pentium 2 � 400 MHz. Mais pour des emails normaux, vous utiliseriez des timbres avec une collision de 16 � 20 bits (ce qui demande entre une fraction de seconde et quelques secondes sur la plupart des ordinateurs).
En fait, vous n'avez pas besoin de comprendre la totalit� des maths utilis�s dans les fonctions de hachage cryptographique pour comprendre de quoi il s'agit. L'exemple de la racine carr�e est une analogie satisfaisante. L'exp�diteur peut calculer quelque chose en relation avec l'adresse du destinataire (la racine carr�e de celle-ci, pour continuer avec l'analogie), et le destinataire peut v�rifier cela (en l'�levant au carr�). Le destinataire saura donc que l'exp�diteur a cr�� ce timbre uniquement pour lui (et non pour quelqu'un d'autre) parce que la r�ponse (la racine carr�e) est intimement li�e � l'adresse email du destinataire. Et le destinataire pourra faire cette v�rification tr�s rapidement. Vous pourriez m�me faire exactement ceci. La seule raison pour laquelle hashcash ne le fait pas, c'est qu'il est plus efficace d'utiliser les collisions partielles dans les hachages, bien que l'effet soit exactement le m�me.
Non, parce que les timbres ne sont valides que pour un seul destinataire. Les timbres sont un peu comme un ch�que : il y a un destinataire bien identifi�. Si un timbre est fait pour joe@foo.com, alors tous les destinataires autres que joe@foo.com rejetteront le timbre, parce qu'il ne leur est pas destin�.
Non, parce que le timbre est calcul� sur l'adresse email du destinaire. Si l'adresse email est chang�e, la v�rification du timbre �chouera. Il n'y a aucune fa�on de changer l'adresse email du destinataire d'un timbre existant sans calculer un tout nouveau timbre sur cette nouvelle adresse email.
Non, parce que les timbres ne sont valides que pour une seule utilisation. Chaque destinataire conserve la liste des timbres re�us afin d'�viter ce probl�me, et si un message contenant un timbre d�j� utilis� est re�u, il est rejet�.
Non, parce que le destinataire n'a besoin que de garder la liste des timbres valides actuellement, les timbres qui ont expir� peuvent �tre supprim�s de la liste. Chaque timbre contient une date de cr�ation, et l'expiration est mesur�e � partir de cette date.
Non, parce que le destinataire rejettera les timbres expir�s s'ils sont r�-utilis�s apr�s expiration bas�e sur leur vieille date de cr�ation.
Non, parce que le timbre est calcul� � partir de la date de cr�ation aussi. Si la date de cr�ation change, la v�rification du timbre �chouera. Il n'y a aucune mani�re de changer la date de cr�ation d'un timbre existant sans devoir recalculer un tout date de cr�ation.
Non, parce que le co�t serait prohibitif. Hashcash ne conserve les timbres dans la liste des timbres re�us que le temps pendant lequel ils sont valides et ont une valeur suffisante. Donc cela co�te � l'exp�diteur significativement plus pour cr�er un timbre valide que cela ne vous co�te � vous pour le conserver. Apr�s que les timbres aient expir�, ils seront supprim�s de votre liste, et l'espace qui �tait occup� est ainsi lib�r�. De plus, le co�t de stockage de l'email sera bien plus important que le co�t de stockage d'une liste de petits timbres.
Non, parce que les timbres avec des dates de cr�ation dans le futur sont rejet�s comme invalides et donc ne sont pas stock�s dans la liste. On suppose ici qu'avec une fausse date de cr�ation tr�s loin dans le futur, la liste du destinataire contiendra le timbre pendant un temps tr�s grand, mais c'est impossible puisque les timbres sont rejet�s.
Si cela arrivait, ce serait un probl�me parce que la deuxi�me utilisation d'un m�me timbre est rejet�e. Cependant, hashcash est con�u de telle sorte qu'il est tr�s improbable qu'un tel cas de figure se produise. La probabilit� est de l'ordre de celle de gagner au loto � chaque tirage pendant plusieurs tirages de suite. La v�rification d'un timbre hashcash est tr�s rapide. Il faut environ 2 microsecondes pour v�rifier un timbre sur une machine � 1 GHz. Cette m�me machine peut v�rifier des timbres plus rapidement que vous ne pourrez jamais lui envoyer des emails sur une ligne OC12 (une ligne tr�s ch�re � environ 1 Gbit par seconde de d�bit). Si quelqu'un envoie des emails � cette vitesse, le goulot d'�tranglement sera la pile TCP, le serveur mail et le syst�me d'exploitation. V�rifier des timbres hashcash pour les utilisateurs ne ralentira pas de mani�re visible le serveur mail, parce que cela consiste en des op�rations bien moins co�teuses que toutes les autres n�cessaires au traitement d'un email.
Il doit y avoir un ent�te X-Hashcash: par destinataire. Chaque destinataire cherche celui qui lui est destin�, et le v�rifie. Afin de conserver le caract�re priv� des destinataires cach�s, chaque email contenant un destinataire cach� doit �tre transmis s�paremment. Cependant, on peut noter que Bcc: n'est plus tr�s utilis� de nos jours, justement � cause du spam. Les spammeurs aiment beaucoup utiliser Bcc parce que c'est moins criard qu'un email contenant 100 ou 1000 destinataires en Cc:. Au final, nombre de gens ont commenc� � tout simplement supprimer les email qui ne contiennent pas comme destinataire explicite leur propre adresse. (En fait, l'auteur est aussi coupable de cela parce que c'�tait facile et efficace pendant un moment). Bien s�r. Vous devez juste configurer votre plugin hashcash avec les adresses pour lesquelles vous attendez du courrier. Par exemple si vous avez deux adresses foo@pobox.com et foo@isp.com, et votre adresse pobox.com est transmise (forward�e) � votre adresse isp.com � partir de laquelle vous lisez vos emails, il vous suffit de dire � votre plugin hashcash que vous recevez les emails destin�s � foo@isp.com, ainsi qu'� l'adresse suppl�mentaire foo@pobox.com. Le serveur qui s'occupe de la mailing-list ne doit pas cr�er de timbres hashcash pour chaque destinataire, cela le surchargerait beaucoup trop. Lorsqu'on envoie un email � une mailing-list, le plugin hashcash va consid�rer que l'adresse de la mailing-list est le destinataire. En fait, cela se passera de mani�re transparente parce que les adresses des mailing-lists ont exactement la m�me allure que toutes les autres adresses email. Ensuite, les utilisateurs qui se sont abonn�s � la mailing-list devront accepter les emails en provenance de l'adresse de la mailing-list. Lorsque vous vous abonnez � une mailing-list, et que vous reconfigurez les filtres de votre logiciel, de la m�me fa�on vous signalez � votre logiciel (et son plugin hashcash) que vous allez recevoir des emails en provenance de cette adresse. Finalement, pour hashcash, une mailing-list c'est exactement comme une adresse suppl�mentaire pour laquelle vous souhaitez recevoir du courrier. Oui. Voici comment �a marche : un spammeur s'inscrit � une mailing-list pour laquelle des utilisateurs envoient des messages avec un timbre hashcash. Si le spammeur est assez rapide, il peut recevoir le timbre hashcash avant certains autres abonn�s, et le r�utiliser pour envoyer du spam � ces personnes-l�, sans avoir � subir le co�t de g�n�ration du timbre. Avec certaines mailing-lists, il est m�me possible pour le spammeur d'obtenir la liste des abonn�s uniquement en la demandant au serveur de la liste (mais de toutes fa�ons, ceux qui envoient des messages ne peuvent cacher leur adresse). Cependant, ceci est un probl�me d� aux mailing-lists, ce n'est pas un probl�me � cause de hashcash. Le but de hashcash c'est que le destinataire (unique) v�rifie le timbre. Le destinataire ici, c'est le serveur de la mailing-list. De toutes fa�ons, n'importe quel timbre hashcash conserv� par le serveur peut subir ce probl�me de course. Le manque d'authentification au niveau des mailing-lists est un probl�me ind�pendant de hashcash. Si une mailing-list poss�de un mod�rateur, ou bien encore si elle est configur�e pour n'accepter que les emails des abonn�s, un spammeur peut encore forger un message de telle sorte qu'il semble venir de la mailing-list, et tous les destinataires le placeront automatiquement dans le dossier correspondant � la mailing-list. Je n'ai pas rencontr� ce probl�me pour de vrai, mais je suppose que cela doit d�j� arriver ; sinon, c'est s�rement parce qu'il y a d'autres proc�d�s encore plus simples pour spammer les mailing-lists (pas de mod�rateur contre le spam, pas de restriction pour que seuls les abonn�s puissent poster, etc). D'autres approches ont �t� utilis�es pour authentifier le trafic sur les mailing-lists. Par exemple, il est possible de demander au serveur de signer avec PGP les messages qu'il envoie. Une approche sp�cifique � hashcash (�vitant les signatures) serait que le timbre hashcash inclue un hachage du contenu du message lui-m�me. Cela interdirait le probl�me de course pour r�-utiliser le timbre, et aussi les probl�mes de course utilis�s comme d�ni de service. (lorsque le probl�me de course est exploit�, les utilisateurs qui re�oivent le spam ne verront jamais le vrai message parce que le plugin hashcash aura identifi� le timbre comme d�j� re�u gr�ce � la liste discut�e plus haut). Cependant, inclure le contenu du message dans le hachage pose un probl�me � cause des transformations effectu�e par le MTA. Il est effectivement tr�s difficile de transmettre de mani�re fiable le contenu d'un email sans que des modifications (souvent mineures) soient appliqu�es. (lignes vides, codage des caract�res, etc) Les syst�mes de signature num�rique comme PGP et S/MIME rencontrent des probl�mes similaires. Vous pouvez consulter aussi la section sur les news. Peut-�tre. Bon, en fait, c'est d�j� ce qu'ils font. Vous pouvez voir l'int�r�t : ils obtiennent gratuitement un relai -- le serveur de la mailing-list -- avec lequel il suffit d'envoyer un message pour qu'il soit retransmis � des milliers d'abonn�s. M�me avec hashcash, le spammeur a un int�r�t � utiliser cette technique : il calcule un timbre et il envoie � un grand nombre de destinataires. Il y a plusieurs choses qui peuvent et qui ont �t� faites pour pallier ce probl�me (encore une fois, ces approches antispam ont pour cons�quence des pertes d'email pour les utilisateurs).
Il existe aussi une syst�me de filtrage collaboratif du nom de NoCeMs, mais il a besoin d'un logiciel particulier chez les utilisateurs, ou au minimum d'un d�lai de transmission lors duquel les NoCeMs s'accumulent. Oui, en th�orie c'est le cas. En pratique le probl�me est marginal parce que le spammeur aurait bien moins de contr�le sur les messages qu'il recevrait, et en g�n�ral les messages sont envoy�s � bien moins de destinataires et donc contiennent bien moins d'adresses pour lesquelles le probl�me de course pourrait survenir. Une autre approche pour r�soudre ce probl�me (lorsqu'il y a une tr�s grande liste de destinataires, et parmi eux potentiellement des spammeurs) est d'utiliser les copies cach�es (BCC). En utilisant les copies cach�es, chaque email est transmis s�paremment donc chaque destinataire ne voit que le timbre qui lui est adress�. Cependant, les copies cach�es sont parfois moins fiables parce que les gens ont l'habitude de ne pas lire les copies cach�es � cause du spam. Une autre approche serait d'utiliser une distribution comme pour les copies cach�es (s�paremment pour chaque destinataire) mais en conservant le destinataire explicitement. De cette mani�re, chaque destinataire ne recevra que l'affranchissement hashcash lui �tant adress�. De m�me, la m�me approche qu'avec les mailing-lists (le fait d'utiliser le contenu du message dans le hachage) serait une solution � ce probl�me. Cependant, en g�n�ral les listes tr�s longues de destinataires avec un timbre hashcash pour chacun seraient peu utilis�es, parce que le temps d'envoi serait particuli�rement long � mesure que la liste compterait des centaines voire des milliers de destinataires. Dans ce cas-l�, l'exp�diteur subirait le m�me probl�me que le spammeur, � savoir un temps d'envoi excessif. L'exp�diteur devrait en fait faire en sorte que les destinataires le traitent comme une mailing-list de telle mani�re qu'un timbre hashcash ne soit pas n�cessaire � l'envoi. Si aucune authentification n'est utilis�e, les whitelists automatiques pourraient �tre abus�es. Voici comment cela fonctionnerait : les utilisateurs qui entrent dans la whitelist sont des utilisateurs qui n'ont plus besoin de timbre hashcash entre eux. Si un spammeur capturait votre carnet d'adresses, ou votre whitelist, il pourrait forger un email � destination de vos amis en se faisant passer pour vous, et n'aurait donc pas � utiliser de timbre hashcash. La solution � ce probl�me est d'utiliser l'authentification bien que les utilisateurs soient dans la whitelist. J'ai mentionn� auparavant dans la FAQ que CAMRAM est un syst�me bas� sur hashcash qui utilise une whitelist automatique. La fa�on dont CAMRAM pratique l'authentification avec la whitelist, est que hashcash est utilis� pour vous pr�senter aux autres utilisateurs, puis une fois cela fait, une signature est utilis�e. Ainsi, il n'est pas possible d'abuser la whitelist. En r�alit�, pour le d�ploiement � court terme, CAMRAM fournit aussi d'autres moyens de se pr�senter, et dans ce cas il n'y a pas de signature, donc la whitelist est th�oriquement vuln�rable � l'abus. Cependant, � l'heure actuelle, c'est un effet de second plan qui a peu de chance d'�tre attaqu�. Ces passerelles sont des adresses email qui permettent d'envoyer des messages vers les news. Leur principale fonction est d'�tre associ�es aux remailers anonymes, car certains d'entre eux ne peuvent envoyer qu'� des adresses emails, mais pourtant les utilisateurs de remailers souhaitent pouvoir envoyer des messages vers les news. C'est un cas diff�rent de celui des envois normaux vers les news. Il peut y avoir des �tapes suppl�mentaires � effectuer pour utiliser hashcash avec une telle passerelle, pour limiter l'abus de ses services. Michael Shinn et Alex de Joode font des essais avec l'affranchissement hashcash pour les passerelles email vers news. Michael Shinn fait aussi des essais avec le principe d'autoriser des envois de messages avec comptes pseudo-anonymes. Tout comme dans le cas des passerelles email vers news, les remailers individuels peuvent se servir de hashcash pour limiter fortement l'abus de leurs services. Je pense qu'il doit exister des logiciels pour faire cela, et si je me rappelle bien, il a exist� un remailer exp�rimental qui utilisait hashcash dans l'envoi des messages. Cependant, cette pratique semble peu utilis�e. Il peut �tre cependant utile d'utiliser hashcash lorsque plusieurs remailers se transmettent un email, pour accro�tre la fiabilit� entre eux. La fiabilit� des emails est consid�r�e comme un probl�me majeur pour les remailers de type I et II ; le probl�me est exacerb� par le fait que l'exp�diteur ne recevra jamais en retour son email refus� lorsque quelque chose fait �chouer la transmission. Mais la meilleure id�e est quand m�me de ne pas effectuer une transmission directe par email entre les remailers (parce que l'absence de message refus� en retour est syst�mique). Mixminion (qui est aussi appel� un remailer de type III) utilise par d�faut SSL pour effectuer cette transmission. Cela accro�t la fiabilit� et fournit une meilleure s�curit� parce que la cl� n'est utilis�e qu'une fois au cours du transfert (forward-secrecy). |
