la perte de fiabilité de l'email -- les techniques anti-spam que les FAI et les utilisateurs mettent en oeuvre pour lutter contre le spam ont comme effet secondaire de réduire la fiabilité de l'email, et ont pour résultat final la perte d'emails légitimes (les emails qui ne sont pas du 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 :

les filtres par mots-clé -- une approche courante pour réduire le spam est d'utiliser un logiciel qui examine l'email pour déterminer s'il a l'air d'être un spam. Parfois cette opération est effectuée par le FAI, par exemple hotmail ou d'autres FAIs et fournisseurs de webmails, parfois encore ce sont les utilisateurs eux-même qui installent ce type de logiciel. Les versions récentes de netscape mail et de microsoft outlook fournissent de tels fonctions de filtrage.
Si votre email, ou l'email d'une personne qui tente de vous envoyer un message, déclenche accidentellement un filtrage par mots-clé, vous avez des chances de ne jamais voir cet email. Ou bien, il sera placé dans un dossier que vous ne lirez pas pendant un long moment.
Cela arrive aux utilisateurs légitimes parce que les logiciels de filtrage ne sont pas très évolués. En effet, il n'est pas rare de tomber sur des « faux positifs » (un email considéré par le programme comme du spam, alors qu'il n'en est pas), parce qu'on se trouve dans une problématique qui nécessiterait une intelligence artificielle, et dépend d'un contexte difficile à reconnaître pour un ordinateur. Par exemple, si vous avez acheté un produit en ligne, vous souhaitez recevoir le reçu, même s'il a un aspect fortement publicitaire. Un autre problème est lié au fait que les mots peuvent avoir des significations très différentes en fonction du contexte, et il y a en réalité une importante frange commune au sein des mots que les spammeurs utilisent, et les mots que les utilisateurs légitimes utilisent.

les blacklists trop zélées -- si votre FAI ou le FAI de vos amis se retrouve catégorisé comme spammeur par le responsable d'une blacklist, votre email sera rejeté. C'est très courant parce que les responsables des blacklists sont prompts à blacklister mais lents à corriger les problèmes. Par exemple, pendant plusieurs mois je ne pouvais pas recevoir d'email de mon frère qui utilisait btinternet.com (un des plus gros FAI au Royaume-Uni), parce que mon FAI utilisait une blacklist qui comprenait la totalité de btinternet. Le problème est qu'en réalité les FAI sont utilisés à la fois par des utilisateurs légitimes et par des spammeurs. La plupart de leur utilisateurs sont légitimes. Mais lorsque du spam est rencontré, le FAI est blacklisté, que ce soit dû à un problème temporaire ou non, et malgré le fait que cela peut induire des problèmes chez des millions d'utilisateurs légitimes du FAI. Un simple constat suffit pour se convaincre que les services des FAI de taille moyenne sont constamment utilisés par des spammeurs. Le FAI n'a tout simplement aucun moyen de savoir si un nouvel utilisateur qui s'abonne à ses services sera finalement un spammeur. Le FAI supprimera le compte du spammeur dès qu'il connaîtra le problème, cependant, dans l'intervalle, il est courant que le nom du FAI se retrouve dans plusieurs blacklists.
Plusieurs responsables de blacklists ont même introduit une politique de suppression punitive de leur liste, en conservant par exemple le FAI sur leur blacklist pour une durée double de celle qu'il a fallu au FAI pour se rendre compte du problème du spammeur. Il est difficile de convaincre les responsables de blacklists à ce sujet -- ce sont des "croisés" de la lutte contre le spam. Ils sont mécontents du spam, et détiennent le pouvoir pour agir. Le problème, c'est qu'ensuite il n'y a pas de recours, parce que ce sont des indépendants et que leur service est en général gratuit. Cependant, leurs décisions sont cruciales, vu que de nombreux FAI et entreprises utilisent leur service. De temps en temps, un FAI deviendra suffisamment gêné par leur politique punitive et leurs décisions arbitraires, et tentera de les poursuivre en justice pour perte de fiabilité dans les emails. Il y a eu un cas d'une telle action, il y a quelques années. Le FAI a gagné, et le responsable de blacklist a dû stopper ses activités. Cependant, il y a beaucoup d'autres responsables de blacklists, et le mécontentement généralisé à propos du spam suscite toujours plus de vocations.

les configurations interdites -- si vous souhaitez configurer un relai ouvert (open relay) pour des raisons précises, les responsables de blacklists et les FAI rendront impossible le fonctionnement de votre serveur.
J'ai tenté de faire ça pour une connaissance, afin qu'il puisse envoyer des mails par mon serveur, sans se soucier du FAI qu'il utilise (il voyage beaucoup). En quelques heures, un spammeur avait découvert mon relai ouvert, et en quelques heures supplémentaires, mon serveur avait été blacklisté. J'avais alors configuré l'extention ESMTP afin de me défaire du spammeur, et effacé tous les spams en attente d'envoi sur mon serveur, mais je pense que mon serveur est toujours sur les blacklists. J'ai pourtant fait des démarches pour être retiré des blacklists, mais n'ai jamais reçu aucune réponse en retour.
À la fois les spammeurs et les responsables de blacklists sont à la recherche permanente de relais ouverts. Parfois, il arrive que des gens soient blacklistés même si aucun spammeur ne peut abuser de leurs services -- uniquement parce que le responsable d'une blacklist a découvert le relai ouvert.
John Gilmore a même essayé d'administrer un relai ouvert pour ses amis, et son FAI a supprimé son compte !
La conséquence, c'est que vous compromettez la fiabilité de vos emails, et votre compte auprès de votre FAI, si vous mettez en place un relai ouvert, et ceci même si vous le faites de manière sûre.

les configurations trop complexes -- il est très courant pour les spammeurs de falsifier leur adresse email, c'est une précaution de base pour ne pas être identifié. Certains logiciels de transmission des emails (MTA) utilisés par les FAI et les utilisateurs font des vérifications pour rendre cette falsification plus difficile. Malheureusement ces vérifications vont aussi rejeter les emails en provenance de domaines ayant des entrées DNS et DNS-inverse incohérentes. Les utilisateurs finaux n'ont en général pas les moyens de fournir des informations cohérentes à ce sujet, et les FAI n'ont pas intérêt à fournir ce genre de prestation pour tous leurs utilisateurs bénéficiant d'adresses IP dynamiques et statiques. Les services liés au DNS sont considérés comme haut de gamme par les FAI, et en général ils les fournissent à un prix élevé.
Un autre effet secondaire de ces vérifications, c'est qu'il peut y avoir beaucoup d'autres problèmes dûs à la configuration du FAI. Si par mégarde ils n'arrivent pas à conserver une cohérence parfaite entre leurs entrées DNS et DNS-inverse, lorsqu'ils changent certaines entrées DNS, ou font des erreurs de cohérence au moment du changement, cela pourra affecter la fiabilité des emails parce que certains logiciels de transmission des emails refuseront d'accepter les emails à cause de ces problèmes.

les types d'utilisateurs discriminés -- certains responsables de blacklists ont pour habitude de blacklister des intervalles entiers d'adresses IP de FAI à haut-débit (modem-câble, ADSL). Ça affecte la fiabilité pour les personnes utilisant ces types de connexion à Internet qui envoient directement leurs emails, ou administrent leur propre centre de transmission d'emails. J'ai connu des personnes obligées de m'envoyer des emails par des chemins détournés, parce que mon FAI utilise une blacklist ayant ce comportement. Pour la fiabilité, les utilisateurs de connexion à haut-débit sont alors obligés d'utiliser le centre de transmission des emails de leur FAI. Cela réduit la flexibilité (le centre de transmission peut très bien ne pas faire tout ce que l'utilisateur souhaiterait), et pose un problème relatif à la vie privée parce qu'ils doivent envoyer à travers leur FAI (s'ils pouvaient envoyer directement, il serait possible d'assurer la sécurité de bout en bout en utilisant SMTP sur SSL par exemple, alors qu'à travers le FAI, on doit utiliser PGP ou S/MIME qui sont moins pratiques et supportés par un moins grand nombre de destinataires).

la perte dans le volume -- une autre raison simple conduisant à rater un email, c'est que si vous recevez trop de spam, vous pouvez rater un email légitime si vous parcourez trop rapidement votre boîte aux lettres à la recherche du message sur 100 qui est un vrai email. Un autre problème lié au volume, c'est que certains FAI imposent des limites sur le nombre d'emails qui peuvent être conservés. Si vous ne nettoyez pas assez fréquemment le spam, votre boîte aux lettres peut se remplir totalement, et les nouveaux emails seront renvoyés à leur expéditeur.

la surcharge au niveau des FAI -- les FAI sont fréquemment surchargés par le spam. Lorsque c'est le cas et que leurs serveurs de mail tombent en panne, ou que leurs disques se remplissent trop, des emails légitimes peuvent être perdus ou renvoyés à leur expéditeur.

Comment hashcash s'intègre là-dedans ?

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.

Que fait hashcash ?

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> To: Adam Back <adam@cypherspace.org> Subject: test hashcash Date: Jeu, 26 Juin 2003 11:59:59 +0000 X-Hashcash: 0:030626:adam@cypherspace.org:6470e06d773e05a8 blah blah -Quelqu'un

Qu'est-ce qui empêche un spammeur d'utiliser hashcash ?

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é.

Mais les spammeurs ne voleront-ils pas du temps de processeur ?

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).

Mais est-ce que les spammeurs ne pourront pas toujours envoyer à beaucoup de destinataires en une fois ?

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.

Est-ce que ça ne rend pas l'email plus lent à l'utilisation ?

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.

En quoi cela rend-il mes emails plus fiables ?

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.

Quels logiciels antispam laissent spécialement passer les emails contenant un timbre hashcash ?

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.

Cette liste n'est pas très longue, pourquoi devrais-je m'y intéresser ?

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.

Mais donc, est-ce que je pourrai ignorer les emails sans timbre hashcash ?

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.

Comment fonctionne l'affranchissement par hashcash ?

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).

Est-ce que hashcash utilise des racines carrées ?

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)

Mais qu'est-ce qu'une collision dans un hachage ?

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).

Et qu'est-ce que c'est qu'une collision partielle dans un hachage ?

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)

Sur quoi hashcash calcule-t-il les collisions ?

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).

Comment puis-je tester une collision ?

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 | sha1 00000000c70db7389f241b8f441fcf068aead3f0

Hum, je n'ai pas trop compris avec tous ces maths, expliquez encore ?

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.

Mais est-ce qu'un spammeur ne peut pas tricher avec hashcash ?

Est-ce qu'un timbre ne peut pas être ré-utilisé pour envoyer des emails à beaucoup de destinataires différents ?

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é.

Est-ce qu'un spammeur ne pourrait pas changer l'adresse email à laquelle un timbre est 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.

Mais est-ce qu'un timbre ne peut pas être ré-utilisé pour m'envoyer plein d'emails ?

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é.

Mais est-ce que cette liste ne croît pas indéfiniment ?

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.

Mais est-ce que ça ne permet pas aux spammeurs de ré-utiliser des vieux timbres ?

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.

Mais est-ce que le spammeur ne peut pas changer la date de création dans des vieux timbres pour les rendre valides à nouveau ?

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.

Est-ce que quelqu'un ne peut pas faire déborder la liste des timbres reçus ?

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.

Est-ce que quelqu'un ne peut pas faire déborder la liste avec des timbres contenant des dates de création dans le futur ?

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.

Que se passe-t-il si deux personnes créent accidentellement le même timbre pour le même destinataire ?

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.

Est-ce que quelqu'un ne pourrait pas surcharger le serveur d'un FAI qui vérifierait le timbre hashcash pour tous les utilisateurs ?

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.

D'autres questions techniques ?

Et si on envoie un email à plusieurs destinataires en même temps ?

Il doit y avoir un entête X-Hashcash: par destinataire. Chaque destinataire cherche celui qui lui est destiné, et le vérifie.

Et avec les copies cachées (BCC) ?

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).

Est-ce que je peux utiliser plusieurs adresses email, et la transmission des emails (forwarding) ?

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.

Et en ce qui concerne les mailings-lists (listes de diffusion/discussion), est-ce que le processeur de la machine qui gère la mailing-list ne va pas être surchargé ?

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.

N'y a-t-il pas un problème de course (une race condition) avec les mailing-lists ?

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.

Est-ce que les spammeurs ne vont pas commencer à spammer les mailing-lists à la place ?

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).

Une approche est de n'autoriser que les abonnés à envoyer un message à la liste. (Ce n'est pas pratique pour les personnes utilisant plusieurs adresses, ou qui utilisent des MTA différents en fonction de l'endroit où ils se trouvent -- votre email est rejeté. Cela m'arrive très souvent, et c'est très gênant.)

Une autre approche est de filtrer la liste, ou d'utiliser la modération, ce qui peut malheureusement conduire à la partialité et une réduction de la libre parole, si le modérateur modère aussi les discussions (en plus du spam).

Une autre approche encore est d'imposer un antispam à la liste. Par exemple avec filtrage par mots-clé. Certains ont cette pratique, qui a le problème de supprimer des messages légitimes à cause des faux positifs.

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.

Mais est-ce que le problème de course lié aux mailing-lists ne s'applique pas aussi aux messages avec destinataires multiples ?

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.

Est-ce que les whitelists automatiques ne peuvent pas être abusées ?

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é.

Et lorsqu'on souhaite envoyer un message sur les news ?
Dans le contexte des news, utiliser un timbre hashcash serait utilisé pour exempter un message des autres vérifications antispam. La principale technique antispam sur les news est d'annuler les messages forgés. De même qu'avec les blacklists pour l'email, annuler les messages forgés demande de la vigilance -- un certain nombre d'utilisateurs privilégiés prennent l'initiative d'annuler les messages qu'ils considèrent être du spam. Malheureusement, cela dégénère fréquemment et les utilisateurs se font la course pour annuler et annuler les annulations pour les même messages. Et de plus, il y a eu des circonstances dans lesquelles certains messages annulés n'étaient pas du spam, l'annulation tenant plus de la censure et des motivations personnelles.
NoCeMs a été conçu pour lutter contre ce problème. Avec NoCeMs les messages ne peuvent pas être annulés. À la place de cela, plusieurs messages (signés par clé PGP) sont envoyés signalant le spam. Les utilisateurs choisissent les messages d'annulation qu'ils souhaitent prendre en compte, en fonction de leurs auteurs.
NoCeMs semble être une meilleure solution au spam sur les news que hashcash. Utiliser hashcash pour exempter des messages d'annulation peut sembler une bonne idée à première vue, mais puisque les news utilisent un système de diffusion large, le coût d'un timbre hashcash pourrait au contraire devenir intéressant pour le spammeur afin d'être sûr de ne pas subir d'annulation.
Si vous souhaitez l'utiliser quand même, je recommanderais d'utiliser le groupe de discussion lui-même comme destinataire pour le timbre hashcash, comme alt.privacy.anon-server par exemple.
Dans beaucoup de logiciels de messagerie, on peut mélanger des emails et des news. Par exemple, on peut faire une copie (email) d'un message envoyé sur les news. Cela conserverait donc une certaine logique d'envoyer un timbre vers le groupe de discussion aussi. (En fait, cela fonctionne peut-être sans aucune configuration particulière avec certains plugins hashcash)
Notez que les news souffrent du problème de course discuté à propos des mailing-lists de manière beaucoup plus aigüe. N'importe quel timbre envoyé sur les news sera reçu parfois plusieurs jours après les premiers sur certains serveurs et donc par certains utilisateurs. Cela signifie qu'un utilisateur recevant le message en premier pourra se servir du timbre.
Même si je considère hashcash de valeur marginale pour les news comme discuté plus haut, si on voulait résoudre ce problème, on pourrait utiliser la même approche qu'avec les mailing-lists. C'est-à-dire, utiliser le contenu du message dans le hachage. (même si, comme noté pour les mailing-lists, le problème avec cette solution est le fait que le contenu du message peut être altéré au cours du transport. On peut utiliser des signatures PGP ou S/MIME pour faire face à ce problème.)
Et en ce qui concerne les passerelles email vers les news ?

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.

Et en ce qui concerne les remailers 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).