A l'occasion de la publication de la traduction en français de la FAQ de hashcash, longue et détaillée, à l'adresse suivante : http://hashcash.org/faq/index.fr.php(...) je voulais revenir sur ce système que je trouve séduisant.
Hashcash vise grosso modo à rendre l'email plus coûteux. Le moyen de paiement retenu consiste en traitement processeur, et le "prix" est choisi pour être marginal pour les utilisateurs normaux d'email, et cher pour les spammeurs. Typiquement, il faut environ 1 seconde pour chaque envoi d'email, ce qui réduit d'un facteur énorme l'envoi de spam (qui est typiquement de 10'000 emails par minute) mais est négligeable pour vous et moi.
Il est clair que ce système n'est pas parfait car il augmente les contraintes des transmissions d'email ; par exemple il devient plus difficile de faire du mass mailing. Une discussion a porté sur ce sujet dans la news consacrée au "passage en force" de Microsoft sur Sender-ID, dont vous pourrez lire la substantifique en pianotant sur votre mulot : http://linuxfr.org/comments/594200.html#594200(...)
Pour ma part, c'est la première fois que je voie un système de lutte contre le spam qui me semble vraiment positif, et je considère les contraintes rajoutées comme largement supportables au vu des avantages potentiels.
Journal Hashcash, vers une solution contre le spam ?
30
juin
2005
# et les mailings lists ?
Posté par maston28 . Évalué à 6.
[^] # Re: et les mailings lists ?
Posté par alexissoft . Évalué à 2.
[^] # Re: et les mailings lists ?
Posté par TImaniac (site web personnel) . Évalué à 5.
En tout cas il est clair qu'il faut établir une relation de confiance entre l'expéditeur et le FAI, les FAIs étant actuellement le principal vecteur technique permettant ces envois simultanés, une gestion plus "indivivudelle" et basé sur une whiteliste permettrait d'assurer une certaine "sécurité.
Le risque est de voir apparaître ce genre de service "+" (l'envoi de mails en masse) comme un service payant.
Enfin dans tous les cas il est clair que les solutions techniques sont dans les mains des FAIs, qui sont les seuls intermédiaires de "confiance" (ou tout du moins facilement blacklistable) qui peuvent intervenir facilement.
[^] # Re: et les mailings lists ?
Posté par pshunter . Évalué à 4.
Évidemment, c'est moins efficace contre les spammeurs car les FAI doivent encore les acheminer, mais le spam deviendrait beaucoup moins intéressant, en fait hashcash serait un nouveau gros critère pour les antispams.
L'idée étant de tuer les spammeurs par attrition ;)
[^] # Re: et les mailings lists ?
Posté par Antoine . Évalué à 4.
[^] # Re: et les mailings lists ?
Posté par romain . Évalué à 5.
Les gars qui s'abonnent à des listes ou à des services par mail, et dont les boites mails renvoient systématiquement un "bonjour, je me protège du spam, veuillez cliquer sur le lien ci-dessous pour valider que vous n'etes pas un spammeur et etre inséré dans ma white list", ça me fait doucement rigoler.
[^] # Re: et les mailings lists ?
Posté par Nelis (site web personnel) . Évalué à 2.
Qu'est-ce qu'il ne faut pas entendre ... Comment gaspiller des ressources inutilement.
[^] # Re: et les mailings lists ?
Posté par gc (site web personnel) . Évalué à 10.
# gpg ?
Posté par Alex . Évalué à 3.
Mais bon c'est toujours une solution de plus, qu'il faudrait utiliser conjointement avec de l'asmtp, la signature de mail, les grey-list....
Et une fois de plus ça sera intéressant le jour où cette solution s'imposera... jarrive déjà pas à convaincre mes proches de signer leur mail ;)
# suite du troll ?
Posté par briaeros007 . Évalué à 1.
J'attend d'ailleurs toujours la reponse a mes questions sur les newsletters et sur mon protocole :-D (aïe pas taper)
https://linuxfr.org/comments/593126.html#593126(...)
Enfin bref pour eviter les redites...
# Oui et non
Posté par hervé Couvelard . Évalué à 8.
Effectivement, que vas-tu dire si les FAI doivent doubler, trippler, décupler ou centupler leurs serveurs smtp pour envoyer le même nombre de mails de leurs clients NORMAUX ?
Accepterais-tu que ton FAI ne puisse pas envoyer ton mail dans la journée, car il a eu une surcharge des demandes ?
Accepterais-tu de devoir payer plus cher ton abonnement pour compenser l'augmentation du nombre de machine smtp ?
Non et moi non plus, le problème ne peut se résoudre de cette manière, c'est une mauvaise solution à un vrai problème.
La seule solution est de ne pas répondre aux mails poubelles, désactiver javascript, désactiver chargement des images web dans les mails, désactiver réponse automatique d'ouverture etc...)
Ensuite, si on veut se la jouer warrior, il faut faire des trucs vachement pervers:
-Lorsqu'il y a des liens particuliers (qui confirment une adresse mail, il faut leur pourrir la base avec des mails qui n'existent pas avec un/des scripts automatiques d'inscription/désincription pour des milliers de faux mails)
- Lorsqu'il y a des mails de phishing, faire exactement la même chose, en donnant des faux identifiants et faux mot de passes.
Curl est vachement bien pour cela, on pourrais même envisager un mini-browser en c qui ne ferait que cela : gérer des cookkies, des requettes get et post, pas besoin d'affichage !.
Tiens ca c'est un projet vachement interessant à monter : un mini-browser C qui permettrais avec un fichier de conf minimum :
adresse web
champs de formulaire avec valeurs
variables get et cokkies,
algos de fabrication des identifiants et pass (pour coller aux méthode des vrais site)
algos de fabrication d'adresses mails inexistante.
[il permettrait] d'envoyer des requettes automatiques pour pourrir les bases des spammers. Je suis sur que pas mal de gentils hackers au travers du web finirait par pourrir la vie de ses spammers.
Ensuite, porter plainte contre les sociétés.
La solution d'augmenter le coût du mail est un chemin qui prépare le jour bénis par les FAIs ou ils pourront faire payer les mails.
hervé
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 1.
Mais arrêtez de fumer la moquette ! Pourquoi faudrait-il plus de machines ? Il n'est pas question de rajouter des for(inti=0;i<10000000;i++)nop(); entre chaque envoi, il est question de refuser toute tentative d'envoi de mail trop "fréquente". Cela n'influerai en rien sur la capacité du serveur smtp à traiter des envoi d'émetteur différent. Au contraire : le serveur concerné ne serait pas "submergé" par les demandes des spammeurs.
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Oui et non
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
Il faudra donc plus de machines/interfaces pour envoyer les courriels.
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 3.
par utilisateur non ?
auquel cas le serveur peut répondre à autant d'utilisateur qu'il peut, envoyer des millions de mails par heure, ce qui importe c'est qu'il impose une pause d'une seconde PAR utilisateur... auquel cas je ne vois absolument pas où est le problème, je me trompes ?
[^] # Re: Oui et non
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
- mail from ? falsifiable
- adresse IP ? les réseaux nattés seront pénalisés
- authenfication SMTP ? Pas tout le monde le fait.
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 2.
Une entreprise aurait évidemment plus de possibilités. Chez le particulier je doute qu'on atteigne 10000 PC nattés ;)
authenfication SMTP ? Pas tout le monde le fait.
Ben certain le font :)
A chaque FAI de trouver sa méthode, mais chaque FAI est et doit être capable d'identifier son client qui veut utiliser son serveur. C'est pas la mer à boire, ca responsabiliserait un peu les FAIs, et les spammeurs seraient vite "cernés".
[^] # Re: Oui et non
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
Le spammeurs sont des particuliers sous mswin dont le système est utilisé à leur insu, le problème est surtout là. Une fois les microsofteries désactivées et des punitions pénales, avec coopération internationale, infligées aux spammeurs la situation sera forcément meilleure.
Evidemment, les usagers y gagneraient. Pas les marchands de transit réseau, les éditeurs anti-virus/espiogiciels/truc/machin, les complices politiques des spammeurs. Ca doit être ça qui bloque.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 4.
Enfin si les fai utilisent des auth smtp ; pas besoin de hashcash ; vu qu'en cas de report de spams on sait directement qui est le spammeur et par consequent prendre des mesures.
Ca a l'air vachement utile hashcash , pour chaque problème vous donnez des solutions qui existent deja ....
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Oui et non
Posté par M . Évalué à 3.
[^] # Re: Oui et non
Posté par Gniarf . Évalué à 5.
des FAIs dont le dialogue se résume à ceci quand tu leur signales un problème :
* "ducon@fai.fr chez vous telle ip à telle heure est vérolé, surement avec Tagazou.D"
* "on s'en branle"
à la troisième fois, tu ne leur signales plus le problème, et le jour où les petits tracas quotidiens qu'ils te causent deviennent un enfer sur terre, ben tu prends la hache et tu coupes le fil.
si un FAI est incompétent, qu'il assume. si ses clients sont trop cons pour se rendre compte qu'il est incompétent, qu'ils assument aussi.
[^] # Re: Oui et non
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Oui et non
Posté par Gniarf . Évalué à 5.
et quand bien meme, le fai reste l'interlocuteur technique : ai-je à contacter directement ses clients que je ne connais pas pour ce genre de problèmes techniques ? je ne pense pas.
[^] # Re: Oui et non
Posté par Antoine . Évalué à 2.
Hé ben si, c'est exactement ça. Sauf que le "for (...)" est remplacé par le calcul compliqué d'un machin dont la présence est rapide à vérifier, à l'autre bout, par le filtre antispam.
[^] # Re: Oui et non
Posté par pshunter . Évalué à 3.
[^] # Re: Oui et non
Posté par Antoine . Évalué à 2.
Oui, tu as raison. Enfin, sauf si dans la chaîne des serveurs il y a un service de redirection, ou de mailing-list, ou tout autre machin modifiant le To...
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 4.
Admettons qu'envoyer un e-mail coûte (en temps d'attente) une demie seconde. Un utilisateur moyen envoie combien de mails dans la journée ? Prenons une estimation assez large et admettons qu'il en envoie une centaine. Ça fait un total de 50 secondes d'attente à cause de calculs effectués par sa machine... 50 secondes, c'est moins que le temps que passe mon filtre antispam à filtrer tous mes mails.
Maintenant, prenons un spammer et admettons qu'il envoie 10 000 000 spams par jour, ça fait environ 1400 heures d'attente par jour, si je ne me trompe pas. Pour lui, il y a un besoin de plus de puissance de calcul.
(Tout ça suppose bien sûr qu'une entreprise a la possibilité de se mettre sur une whitelist pour ne pas avoir à payer le coût d'envoi des emails de tous ses employés, mais qu'un spammer n'a pas cette possibilité.)
[^] # Re: Oui et non
Posté par pshunter . Évalué à 2.
Si l'entreprise édite des mailing lists, leurs clients devront les mettre en white-list, je trouve que c'est une bonne chose, car dans le cas où ces mailings ne t'intéressent pas ils passent quand même en spam.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 5.
Et pour les newsletters personnalise (avec "cher monsieur X" ); quand tu as 10 000 mails a envoye dans la journee (offre promotionelle ou autre); c'est sur que tu as que ca a faire de prendre un quadri opteron ; surtout quand le p3 avant tenait la charge ....
Et comme le faisait remarquer (toujours dans le gros troll) pour les gens qui ont des serveurs qui sont plutot bien charges ; tu leurs fais quoi si ils implementent ca ; tu leurs offrent une nouvelle machine ?
bref :
Pour toutes le entreprises qui envoient des confirmations (factures etc...) ou des documents par mail ; je suis sur qu'ils apprecient. J'imagine bien dell qui utilisent deja une ferme pour les serveurs web devoir en acheter une nouvelle pour ses mails; ou alors gmail (google) devoir acheter son ile....
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 0.
Autrement dit, si j'autorise quelqu'un à m'envoyer des emails, ça ne lui coûte pas de temps de calcul, mais si je ne l'ai pas encore autorisé, ça lui coûte quelques instants. C'est un peu lourd à mettre en place puisqu'il faut authentifier l'expéditeur pour ça, mais si c'est faisable, alors ça semble une solution correcte.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 4.
Ah oui mais que je suis con ; il suffit de whitelister tous les serveurs auxquels on s'abonne. y compris ceux avec lequel on a fait ca par papier. Et d'autant plus quand on est juste un utilisateur. Mais oui la solution saute aux yeux.
Euh juste comme ca si j'ai besoin de faire ca ; dans ce cas je me cree un veritable reseau de confiance; c'est beaucoup plus simple (vu que c'est ce que vous me proposez de faire) , et ca consomme moins de ressources.
De plus sur 10 000 personne je suis sur qu'il y en a pas un ou deux qui oubliera et donc qui ne pourra pas etre atteint par la newsletter.
Vous avez d'autres solutions comme ca que "il suffit de whitelister"?
mais si je ne l'ai pas encore autorisé, ça lui coûte quelques instants. C'est un peu lourd à mettre en place puisqu'il faut authentifier l'expéditeur pour ça, mais si c'est faisable, alors ça semble une solution correcte.
Fait toi meme le calcul 10 000 clients; 2 secondes par clients.
un peu lourd tu est TRES gentil.
Et les spammeurs ont un metro d'avance car ils utilisent des drones army .
Ca me semble plutot une solution incorrecte.
-A demande un system actif de la part du destinataire.
J'imagine bien le gars qui est abonne a 30 newsletter pour son boulot et/ou son chez lui (ca vas vite) devoir whitelister 30 entreprises.
Ensuite il souhaite envoyer des mails a d'autres personnes eux aussi vont devoir le mettre dans sa whitelist.
Et la qu'est ce qu'on cree ? Oh un beau reseau de confiance. Quelle solution Hashcash elle nous a force a mettre un reseau de confiance d'une facon heu comment dire ...
ce qui amene le B :
-B ca a un effet boule de neige pour le reseau de confiance; ce qui est forcement tres prejudiciable si une seule machine du reseau de confiance est corrompu.
Sans compter que
-C les drones army sont la donc les spammeurs s'en foutent.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 3.
- un système entièrement à base de whitelists, ou un réseau de confiance
- un système entièrement à base de challenges à effectuer par l'expéditeur
Or, ce que je proposais comme réponse à ta question (et j'aurais aimé que tu le prennes de manière un peu moins hautaine, ce n'était qu'une suggestion), c'était un système à base de challenges ET équipé de whitelists permettant d'éviter aux gens "connus" d'effectuer les challenges.
Gérer des whitelists n'a jamais impliqué que les utilisateurs fassent tout à la main comme tu le supposes. Puisque mettre en place un système à base de challenges implique une extension du protocole ou un nouveau protocole, il est tout à fait envisageable de concevoir un protocole dans lequel une inscription à une mailing-list est conçue comme une autorisation explicite pour cette ML d'envoyer des emails, et que ce soit géré de manière transparente par les serveurs de mails. De la même manière, ajouter un utilisateur à son carnet d'adresses peut être considéré comme une autorisation à envoyer des emails.
Tu n'as pas compris visiblement que ce que je proposais était une réponse à cette objection que tu as déjà faite. Dans cette solution:
- envoyer 10 000 mails à des "clients" qui ne se sont pas inscrit à la mailing list prend 20 000 secondes
- envoyer 10 000 mails à des clients qui se sont inscrits ne prend pas plus de temps qu'actuellement.
Au final, ça ne demande pas plus de participation à l'utilisateur qu'actuellement, ça n'implique pas de réseau de confiance. Reste ton objection sur les "drone army", mais comme tu n'as pas expliqué pourquoi ça invalidait le procédé, je ne sais pas quoi répondre.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 4.
Non je ne l'ai pas prise de facon hautaine. Desole si tu l'as cru, ce n'etait pas mon intention.
ce n'était qu'une suggestion),
Donc hashcash ne repond pas a cette problèmatique . Merci.
Puisque mettre en place un système à base de challenges implique une extension du protocole ou un nouveau protocole,
Dans ce cas autant concevoir un vrai nouveau protocole qui prend le problème du spam en compte plutot que des rustines dans tous les sens...
envisageable de concevoir un protocole dans lequel une inscription à une mailing-list est conçue comme une autorisation explicite pour cette ML d'envoyer des emails,
On ne parle pas de ml; vu que les ml sont deja prise en compte par hashcash. Mais bel et bien de newsletters , la ou il y a des mails qui contiennent par exemple "cher client toto, aujourd'hui , les actualités de Y sont ..."
De la même manière, ajouter un utilisateur à son carnet d'adresses peut être considéré comme une autorisation à envoyer des emails.
Je suis pas sur d'avoir bien compris . Tu es toujours autorise d'envoyer des mails. Le problème c'est avec hashcash ou pas.
Entend tu ajouter un utilisateur a son carnet d'adresse grace a un mail qu'on vient de recevoir de sa part <=> a le whitelister. Ca ressemble fort a l'etablissement d'un reseau de confiance , , et donc hashcash servira juste a envoyer les mails aux personnes qui nousont pas whitelister.
Ce qui implique de verifier si on est whitelister ou pas. Si c'est accesible directement ; rien n'empeche de faire du pishing sur les domains qu'on a whitelister non? dans ce cas sert pas a grand chose ...
Et dans tous les cas demande une activite de la part de l'utilisateur car il doit ajouter les personnes dont il desire recevoir les mails sans hashcash a son carnet d'adresse.
Tu n'as pas compris visiblement que ce que je proposais était une réponse à cette objection que tu as déjà faite. Dans cette solution:
- envoyer 10 000 mails à des "clients" qui ne se sont pas inscrit à la mailing list prend 20 000 secondes
Oui je parlais que du premier round :
20 000 secondes pour "initialiser" une newsletter je suis pas sur que beaucoup d'entreprise accepte. Et ceci quand c'est pas pour les factures etc...
Et ensuite il faut que les clients nous ait whitelister, si les clients sont des entreprises ce n'est pas dit qu'ils puissent le faire , les services informatiques ne voulant pas forcement que les utilisateurs puisse whitelister n'importe qui n'importe comment.
Et encore c'est 20 000 secondes en ayant un ordi a disposition pour faire que ca ; ce qui est pas forcement le cas.
Au final, ça ne demande pas plus de participation à l'utilisateur qu'actuellement, ça n'implique pas de réseau de confiance.
Non juste de changer tous ses logiciels ; de faire en sorte qu'ils whitelist automatiquement les bons mails et pas ceux qu'on ne veuille pas whitelister etc... Parceque si les personnes whiteliste automatiquement les mails avec hashcash , les spammeurs ovnt d'abord utiliser hashcash , puis ensuite ils ne l'utilsieront plus et pourront faire mumsue comem des petits fou.
Donc je vois pas de qui d'autre pourrait faire le tri entre bon et mauvais mails a whitelister.
Quand aux reseau de confiance :
L'etablissement d'une whitelist est l'etablissement d'un reseau de confiance. Ensuite le reseau peut couvrir tout ou partuie de ton reseau reel.
Reste ton objection sur les "drone army", mais comme tu n'as pas expliqué pourquoi ça invalidait le procédé, je ne sais pas quoi répondre.
Parce qu'ils ont du temps cpu gratuitement.Et les listes de plus de 3000 ordinateurs sont monnaies courantes a ce qu'il parait.
Donc d'un cote on penalise les entreprise et particulier en utilisant leurs temps cpu ; de l'autre cote , le temps cpu etant vole par les spammeurs , de meme que la bp (les spammeurs c'est drone army , bp paye par cb vole etc...) Ben eux ils s'en foutent un peu qu'on les fassent payer, de toute facon ils paieront pas.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 1.
Je n'en sais rien, je n'ai fait que suggerer une maniere triviale de resoudre le probleme que tu evoquais. Savoir si les gens qui ont propose hashcash sont des gros nazes, ca ne m'interesse pas franchement...
Ben ecoute si tu as une meilleure solution, n'hesite pas hein...
Et une newsletter n'a bien sur rien a voir avec une mailing list...
Je le rappelle, ma distinction etait entre d'une part les services auxquels on souscrit, qui n'ont pas a effectuer de challenge et d'autre part les services auxquels on ne souscrit pas, ce qui caracterise assez bien les spams, et qui eux doivent effectuer un challenge.
Effectivement, si ce qui te gene c'est que ce procede empeche une entreprise d'envoyer des newsletter a des gens qui n'ont rien demande, je me permet de te rappeler que c'est le but recherche.
Je ne parle pas d'autorisation legale ou d'autorisation technique, je parle de monsieur Dupont qui dit "ah oui, j'aimerais bien recevoir des emails promotionnels de La Redoute", par opposition a monsieur Durand qui lui n'a rien demande.
Non. Ca ressemble a une whitelist.
C'est pour ca que je disais que pour que ce soit efficace, il fallait que les expediteurs s'authentifient, et que je disais que c'etait "un peu lourd"
Il n'y a pas de premier round: soit l'utilisateur s'est inscrit et tu n'as pas de calcul a faire, soit l'utilisateur s'est inscrit et la tu dois faire un calcul.
Le "whitelistage" faisant partie du processus d'inscription a ta mailing-list (une newsletter est une mailing list), tu peux etre sur que tous tes "clients" se sont inscrits et t'ont whiteliste.
Ensuite, qu'une entreprise puisse empecher ses employes de s'inscrire a des mailing lists, c'est une eventualite plutot raisonnable, non ?
Effectivement, si on change le protocole il faut changer les logiciels :)
Il ne s'agit pas de faire un tri entre spam et non-spam, il s'agit de faire un tri entre mail sollicite par le destinataire et mail non sollicite. Seuls les mails non sollicites coutent du temps de calcul a l'expediteur. La separation entre mails sollicites et non sollicites est triviale a faire: tout mail qui provient d'un type qui n'a pas ete whiteliste n'est pas sollicite.
Un reseau en forme d'etoile, meme si c'est techniquement un reseau, ce n'est pas tres interessant. Pour parler de reseau de confiance, il faudrait au moins que tu herites en partie de la confiance des gens en qui tu fais confiance.
Quelle que soit la puissance de calcul a la disposition d'un spammeur, si on divise par un million son debit, on diminue l'interet pour lui de spammer.
Le particulier, a moins d'envoyer des centaines de mails par jour, n'est pas du tout penalise. Les entreprises, elles, ne sont penalisees que si elles envoient des emails de masse a des gens qui n'ont rien demande... mais... mais... c'est du spam ca, non ?
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 1.
Mais ou est ce que j'ai suppose ca ???
Ben ecoute si tu as une meilleure solution, n'hesite pas hein...
J'avais bien propose en truc fais vite fait :
ici : https://linuxfr.org/comments/594440,1.html(...)
Non. Ca ressemble a une whitelist.
Qui est un reseau de confiance.
Tu fais confiance a certains serveurs/expediteur. Donc tu cree un reseau de confiance.
Et une newsletter n'a bien sur rien a voir avec une mailing list...
Ben pas grand chose.
Une ml est caracterise par une seule adresse , chacun peut ecrire a cette adresse , et cette adresse renvoie tous les message recu a toutes les autres adresses.
Une newsletter est plus un système d'information ou il n'a jamais ete concus comme plusieurs personnes pouvant se parler en meme temps.
Tu peux comparer une ml a un wiki et une newsletter a un site web par exemple.
Effectivement, si on change le protocole il faut changer les logiciels :)
Vous ne changez pas le protocole; vous mettez des rustines. Changez de protocole pour moi c'est repartir de 0.
Il n'y a pas de premier round: soit l'utilisateur s'est inscrit et tu n'as pas de calcul a faire, soit l'utilisateur s'est inscrit et la tu dois faire un calcul.
Rien compris .
soit a alors b soit a alors c . gnéé ???
Je ne parle pas d'autorisation legale ou d'autorisation technique, je parle de monsieur Dupont qui dit "ah oui, j'aimerais bien recevoir des emails promotionnels de La Redoute", par opposition a monsieur Durand qui lui n'a rien demande.
Donc monsieur dupont c'est inscrit sur le site de la redoute et a cocher la case "oui je veux bien recevoir une newsletter de la redoute". Et il doit allez a son client mail pour whitelister la redoute pour sa newsletter , pour ses contacts et pour ses factures?
La separation entre mails sollicites et non sollicites est triviale a faire: tout mail qui provient d'un type qui n'a pas ete whiteliste n'est pas sollicite.
c'est d'ailleurs si trivial qu'il faut un protocole de feedback pour specifier que l'on veut le hashcash ; deja rien que pour ca ...
Deuxiemement on peut tres bien avoir sollicite des mails sur une page web , sur un courier ; et oublie ensuite qu'on l'a fait. Dans tous les cas ca demande une confirmation de la part de l'utilisateur.
Quelle que soit la puissance de calcul a la disposition d'un spammeur, si on divise par un million son debit, on diminue l'interet pour lui de spammer.
Deja qui dis que c'est un million la division?
Deuxio qui dis qu'il a un interet a spammer ? Une etude avait montrer que plus de 50 % du spam n'avait AUCUN interet commercial, juste faire chier les gens (il y avait un lien sur nanog).
Pour parler de reseau de confiance, il faudrait au moins que tu herites en partie de la confiance des gens en qui tu fais confiance.
question de definition.
Le particulier, a moins d'envoyer des centaines de mails par jour, n'est pas du tout penalise. Les entreprises, elles, ne sont penalisees que si elles envoient des emails de masse a des gens qui n'ont rien demande... mais... mais... c'est du spam ca, non
Et certains particuliers envoient de temps en temps des centaines de mails (voir le liens sur l'article de sender id) : voeux etc ...
Donc oui eux ils sont penalise. Aie et deja un faux positif.
Deuxio et si les personnes ont demande mais n'ont pas forcement whitelister ? mais... mais... c'est pas du spam ca , non?
Tant que tu demande a l'utilisateur final de faire une action tu auras forcement ce cas.
Sans compter que le protocole de feedback dont tu as besoin pour savoir si tu dois ou pas hashcasher ton message , peut permettre aux spammeur de spammer avec le pishing.
Et si tu n'utilise pas de protocole de feedback ; les entreprises envoyant des infos importantes (factures par exemple) hascasheront leurs messages pour etre sur que tu les recoient !
Donc , de mon point de vue , l'interet est nul.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . Évalué à 2.
C'est du capillotractage, un reseau de confiance à un seul niveau, sans heritage de confiance, c'est aussi interessant que considerer qu'un ordinateur tout seul est un reseau d'ordinateurs. Techniquement c'est vrai, mais je ne vois pas du tout ce que ca apporte a la discution.
Histoire de bien chipotter sur le vocabulaire et de dire des evidences, une whitelist c'est une liste de confiance, et assimiler une liste a un reseau... ben... pourquoi pas, mais ca n'apporte rien.
Note que je n'ai rien contre les reseaux de confiance, et ca pourrait tres bien etre utilise dans ce contexte... simplement je ne suis pas d'accord qu'une whitelist soit equivalente a un reseau de confiance "general": c'est a la fois moins puissant et plus sur.
Tatata, une mailing list c'est une liste de diffusion, c'est a dire une adresse qui sert a dispatcher des emails. Il y a des mailing lists auxquelles tout le monde peut ecrire, et d'autres ou seul une liste reduite de gens peut ecrire. Une newsletter, c'est une mailing list ou seules quelques personnes peuvent ecrire.
Changer pour moi c'est changer, c'est a dire apporter des modifications ou remplacer par quelque chose de different. Mais nous n'avons l'air d'accord sur aucune des definitions des mots que nous employons :)
J'ai oublie une negation.
Tu veux bien, le temps d'une experience de pensee, accepter que le processus de liste blanche soit automatique ?
C'est deja le cas pour les mailing-lists, sauf de tres rares exceptions. Au risque de me repeter encore une fois, ce que je propose est une extension du protocole pour que cette confirmation (qui existe deja) soit interpretee automatiquement par les serveurs mails comme une autorisation a envoyer des mails sans payer le cout.
C'etait une valeur lancee au hasard, si tu veux on peut remplacer par un "x". Si un mail coute x secondes a envoyer, alors le facteur de penalite, si je ne me trompe pas, est x multiplie par le nombre de mails qu'un spammer peut envoyer en une seconde.
Mais bien sur... Tu ne confonds pas avec les virus par hasard ?
Oui, de temps en temps. Selon la duree du calcul, ca peut etre acceptable ou non. Mais en general, les gens qui envoient des cartes de voeux le font a des gens qui les connaissent bien. Si, comme je le proposais, l'ajout de quelqu'un dans ton carnet d'adresse le whiteliste, ca elimine au moins la moitie du temps de calcul, en admettant que la moitie des gens a qui tu envoies des cartes de voeu t'ont dans leur carnet d'adresse.
Ce n'est evidemment pas parfait, puisqu'on ne peut pas penalise tous les emails non sollicites sans en penaliser quelques uns de legitimes. Tout est une question de compromis entre penaliser un peu les particuliers une fois l'an et penaliser beaucoup les spammers tous les jours...
Un faux positif, ca serait quelqu'un qui est marque comme spammer alors qu'il ne l'est pas.
Puisque le "whitelistage" est automatique (cf. plus haut), le cas de gens qui ont demande mais n'ont pas whiteliste est forcement tres rare, et donc la penalite est forcement tres reduite.
Je trouve que j'ai depense beaucoup d'energie inutile pour expliquer que je ne demandais pas de nouvelle action a l'utilisateur final. Je voudrais essayer de conclure ma position sur la question clairement, pour qu'on puisse voir si on c'est compris.
- Si tu penses toujours que j'ajoute une etape de confirmation, ou une quelconque nouvelle action de la part de l'utilisateur final, je t'encourage a me relire, parce que ce n'est pas mon intention. Je propose de modifier le protocole de mail actuel pour que les actions habituelles des utilisateurs qui peuvent etre interpretees comme une autorisation a envoyer des mails le soient.
- Si on est d'accord sur la nature de ma proposition, mais que tu penses que cette extension du protocole n'est pas raisonnable, je suis tout a fait pret a en discuter, parce que je suis tres loin d'etre un expert en protocoles reseau.
- Si on est d'accord sur la nature de ma proposition et que tu es d'accord que c'est une extension de protocole qui est faisable en pratique, mais que tu penses que ca penalise trop les utilisateurs et pas assez les spammers, pourquoi pas, c'est un point de vue. Je n'ai pas grand chose d'autre a y repondre qu'un exemple bricole:
Si une machine peut envoyer 10 mails par seconde. Si un individu possede une machine et envoie 100 mails par jour, alors qu'un spammer possede 1000 machines et envoie 100 millions de mails par jour, alors en rajoutant un challenge qui dure une seconde par mail:
* l'utilisateur doit depenser 100 secondes de temps de calcul dans sa journee, ce qui est tres raisonnable, surtout si c'est en plusieurs fois.
* le spammer doit depenser 100 000 secondes, soit 27h, par jour, alors qu'avant cela ne lui coutait que 10 000 secondes, soit 2.7 heures. (Ca reste faisable avec ces chiffres, la penalite n'est que de 10)
Il s'agit de chiffres pris un peu au hasard, pour donner un ordre de grandeur de la penalite pour un utilisateur et un spammer. J'estime au juge qu'une penalite de 5 minutes par jour est raisonnable pour moi car c'est moins que le temps que je depense a filtrer mes spams. Vu mon debit de mails, je sais tres bien que meme si on fixait un challenge a 5 secondes, ca me penaliserait de moins de 5 minutes, et ca penaliserait beaucoup les spammers (d'un facteur 5*le nombre de mails qu'ils peuvent envoyer en une seconde).
Selon mon point de vue, la question principale pour savoir si cette solution est interessante, c'est de calculer s'il existe des valeurs qui penalisent tres peu les utilisateurs qui consomment plus que moi, et qui penalisent beaucoup les spammers. Pour ca il faudrait des chiffres plus fiables.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 2.
Ok mais je peux aussi accepter que on trouve un graphe hamiltonient dans tous graphes; si il existe , en telmps polynomial. Ca ne le rendra pas vrai pour autant , non?
Dans tous les cas ca demande une confirmation de la part de l'utilisateur.
C'est deja le cas pour les mailing-lists, sauf de tres rares exceptions.
C'est vrai pour ce qui est des mailing lists. Ca ne l'est beaucoup moins en ce qui concerne les newsletters.
Un faux positif, ca serait quelqu'un qui est marque comme spammer alors qu'il ne l'est pas.
Ben oui une entreprise que ne spamme pas ; ne peux pas envoyer ce qu'elle veut parcequ'elle a un comportement que certains spammeurs peux avoir. C'est bel et bien un faux positif non?
Une etude avait montrer que plus de 50 % du spam n'avait AUCUN interet commercial, juste faire chier les gens
Mais bien sur... Tu ne confonds pas avec les virus par hasard ?
je copie colle une partie d'un email de nanog entre autre. Il y avait un article beaucoup mieux mais je le retrouve plus :(
et honnetement quand tu as des trucs comme ca , pour les meilleurs ,
Haven'tSeen YouAround TheSiteInAWhile So I thought I would shoot YouALetter
AndSeeWhat's Been Up?= StopBySoon and IPromiseI'llPlayWithMyself ;)
Qui peux croire que ca a un but commercial. Qui peux etre assez con pour cliquer sur les liens donnees?
pour que les actions habituelles des utilisateurs qui peuvent etre interpretees comme une autorisation a envoyer des mails le soient.
Supposons. Mais comme je le disais ; on peut s'abonner a des newsletters sans que l'utilisateurs utilise son client mail pour une quelconque confirmation. Par consequent il faudrait que les actions soient aussi observe sur les autres support : http et/ou courrier.
mais que tu penses que cette extension du protocole n'est pas raisonnable, je suis tout a fait pret a en discuter, parce que je suis tres loin d'etre un expert en protocoles reseau.
Tout depend quelle extension tu veux rajouter ;) (moi non plus je ne suis pas un expert)
Si il n'y as pas de feedback sur la whitelist : cad que ta whitelist elle est chez toi et l'expediteur ne sait pas si il est whitelister donc ne sait pas si il doit t'envoyer hashcash ou pas, ca peux poser des problèmes a certaines entreprises : cas du hashcash obligatoire pour envoyer les factures, ce qui peux etre penalisant.
Si Il y a un feedback; n'y a t'il pas une possibilité que les spammeurs fasse du pishing en se faisant passer pour les entreprises les plus utilise (par exemple amazon , alapage etc...)?
Pour eux c'est simple de faire du pishing sachant qu'ils utilisent deja des adresses mails qu'ils ont payes(les listes d'adresses mails j'entend), donc ils font des tests de feedbacks sur les mails qu'ils connaissent sur ; on va dire qu'ils testent un millier de domaine , et comme ca il ne se concentrent plus que sur ces adresses.
Quand a l'exemple , le spammeur ne possede pas ses machines, paient ses factures de bp avec des cartes bleu vole etc...
Ca lui prend 100 * plus de temps a faire?
Ben il utilisera 100* plus de machines .
Certains disent que si on bloque les ports 25 chez les clients des fai on bloquera 90% du spam. (et la remarque judicieuse : oui mais on bloquera 90% du courrier normal aussi :-D ). Tout ceci pour dire que faire consommer plus les spammeurs pour arreter le spams ne marche pas amha car ils ne paient pas ce qu'ils consomment.
Quand au fait de changer de protocole : pour moi il s'agit par exemple d'utiliser qmtp plutot que smtp etc...
Et donc quitte a modifier en profondeur le protocole et se prendre la tete avec la detection automatique des machins bidule chouette.
Autant changer radicalement de protocole, d'en concevoir un tout nouveau avec comme point du cahier des charges : ne pas permettre ni le psihing ni le spam , non?
[^] # Re: Oui et non
Posté par Antoine . Évalué à 1.
Et pourquoi ces méthodes simples connues depuis des années n'empêchent pas le spam de proliférer ? Tu n'as pas l'impression d'oublier deux choses :
- aspiration des adresses e-mail sur le Web (archives de MLs, forums, etc.) ;
- attaques dictionnaire sur les SMTP (sur un domaine existant toto.com, essayer tous les prénoms courants john@toto.com etc.) ?
Accepterais-tu de devoir payer plus cher ton abonnement pour compenser l'augmentation du nombre de machine smtp ?
Je ne crois pas que le nombre de machines SMTP constitue une part significante des dépenses du FAI moyen... La connectivité et la masse salariale doivent être largement supérieures.
La solution d'augmenter le coût du mail est un chemin qui prépare le jour bénis par les FAIs ou ils pourront faire payer les mails.
Au cas où tu n'aurais pas remarqué, je te signale que le mail fourni par ton FAI fait partie d'un paquet global que tu paies déjà.
[^] # Re: Oui et non
Posté par briaeros007 . Évalué à 1.
Raison de plus pour qu'elle ne le devienne pas.
Au cas où tu n'aurais pas remarqué, je te signale que le mail fourni par ton FAI fait partie d'un paquet global que tu paies déjà.
Ah non : le cout de la transmission d'un paquet est paye. En aucun ca le surcout generer par un quelconque systeme de gestion des mails.
[^] # Re: Oui et non
Posté par Antoine . Évalué à 2.
Et tes boîtes POP et IMAP, c'est pas un système de gestion des mails ? Et les redirections ? Le mail, ce n'est pas juste des paquets qui entrent par une interface et sortent par l'autre sans traitement...
Raison de plus pour qu'elle ne le devienne pas.
Ca n'empêche pas certains FAI de commencer à proposer de l'antivirus et de l'antispam gratuit (Nerim fait ça)...
# En parlant du spam et de hotmail
Posté par ~ lilliput (site web personnel) . Évalué à -2.
Le Blog des cybériens heberger par Le Monde Informatique a conseillé très vivement ;)
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
# Ouvrir une session Mail
Posté par mmMMOoooOMMmm . Évalué à 1.
Bon, ça nécessiterait pas mal d'échanges de mails au préalable et il faudrait une whitelist, mais ça permettrait d'éviter l'usurpation de compte sans bouffer du temps CPU.
Et puis les courriers ne répondant pas à ce critère sont triés ensuite normalement.
# réflexion
Posté par Beretta_Vexee . Évalué à 8.
hascash, Sender ID, Certified Domaine, etc etc ... c'est très beau, mais cela ne peut fonctionner que dans le cadre d'un adoption globale, dans ce cas pourquoi se contenter d'une rustine si tous le monde doit changer son soft ou son infrastructure ? pourquoi ne pas voir plus large ? Qui cracherait sur un protocole plus sur, qui intégrerait d'office les systèmes de restrictions plus large que la simple black et white list, prendrait en compte les mailling list, etc etc ?
[^] # Re: réflexion
Posté par briaeros007 . Évalué à 0.
# N'imp
Posté par Guillaume Knispel . Évalué à 9.
Imaginons que je veux envoyer un mail depuis un 386... J'attend 3 heures ?
Deja que nombre de soft moderne rament leur race pour cause de developpeur ayant des machines trop moderne et codant n'importe comment, si en plus on se met a ralentir volontairement les programmes...
Et si je suis un spammeur riche ? Ben je me monte un cluster d'une 100aines de machines modernes et je continue comme si de rien était.
[^] # Re: N'imp
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 5.
Donc dans ce cas là non seulement ca ne marche pas, mais c'est aussi une insitation à faire des spy-wares plus puissants...
[^] # Re: N'imp
Posté par gc (site web personnel) . Évalué à 2.
Soyons sérieux, tu as vu où que le spammeur pourrait compromettre plus de machines, mais qu'il ne le fait pas parce qu'il envoie déjà suffisamment de spam à son goût ?
En plus, le fait de consommer tout le CPU des machines vérolées peut être une façon pour le vérolé de se rendre compte plus vite qu'il se passe quelque chose de pas normal sur sa machine.
[^] # Re: N'imp
Posté par briaeros007 . Évalué à 3.
C'est le problème cout /effort.
Si il estime qu'utiliser plus de drones lui demande trop d'effort par rapport au cout que ca va lui apporter ; il ne le feras pas.
Par contre si le ssyteme commence a l'embeter ; alors l'effort est suffisant pour compenser le cout.
Tu as exactement la meme chose au niveau du petrole : on arrete l'extraction quand elle n'est plus assez rentable par rapport au cout du baril. si le baril vient a exploser , on pourras reprendre des anciennes exploitations parce qu'elle redeviendront rentable.
En plus, le fait de consommer tout le CPU des machines vérolées peut être une façon pour le vérolé de se rendre compte plus vite qu'il se passe quelque chose de pas normal sur sa machine.
La plupart des gens , quand ca rame trop , formate et reinstalle. les 3/4 des windowsienque je connais ont ce reflexe de formater et de reinstaller lors des problèmes. Donc je vois pas trop en quoi ca va eviter qu'ils se fasse veroler aussi vite.
# traduction de la FAQ
Posté par JoeBar . Évalué à 4.
Par ailleurs, tu traduis 'race condition' par 'problème de course'. J'avoue avoir un peu de mal à comprendre parfaitement cette expression mais je pense que c'est une mauvaise traduction.
Je suppose que cela signifie problème de type, de genre. Si quelqu'un a une meilleure idée, qu'il se fasse connaître !
Autrement, rien à dire, très bien.
[^] # Re: traduction de la FAQ
Posté par M . Évalué à 4.
La meilleur traduction que j'ai trouver est pb d'acces concurent...
[^] # Re: traduction de la FAQ
Posté par Obsidian . Évalué à 2.
La traduction quasi-officielle des « race conditions » est « accès concurrents », même si c'est une règle non écrite.
[^] # Re: traduction de la FAQ
Posté par gc (site web personnel) . Évalué à 2.
Le problème de "accès concurrents" c'est que ça se traduirait en anglais par "concurrent access".
Une "race condition" c'est un peu différent, c'est un problème qui est variable en fonction de variables plus ou moins aléatoires, par exemple la latence réseau ou encore le scheduling des threads.
Utiliser "problème de course" permet de conserver le fait qu'il y a une "course" entre différentes entités et c'est ce qui cause le problème.
Est-ce que tu as un pointeur pour aller dans le sens de "accès cncurrents" ?
[^] # Re: traduction de la FAQ
Posté par briaeros007 . Évalué à 2.
Sinon ben qu'on lui dise "acces concurrent" , "problème de courses" ou "race condition" ca sera la meme chose pour lui, vous pensez pas?
De meme que l'on traduit rarement "socket" non ?
c'est un problème qui est variable en fonction de variables plus ou moins aléatoires, par exemple la latence réseau ou encore le scheduling des threads.
Ben les acces concurrent sont aussi variables en fonction de variables aleatoires . C'est exactement le meme problème pour moi .
1°)A accede a x et le stocke dans xa
2°)B accede a x et le stocke dans xb
3°)A fait son calcul
4°)B fait son calcul
5°)A met xa dans x
6°)B met xb dans x.
Tout le problème d'un acces concurrent est quand les etapes 1,2,3,4,5,6 sont faites . Donc oui ca depend de variables plus ou moins aleatoires.
Amha "race condition" correspond a "poblèmes d'acces concurrent" et pas juste a "acces concurrent" .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.