Sauf que ce passage ne répond pas à ma problématique. La réponse parle de spammer des listes existantes.
Je n'ai pas distingué la première partie de ta phrase (réponse sur la ML) de la deuxième partie et je m'en excuse :
Toi tu me dis qu'il n'y a besoin que d'un seul hash si on envoie à une liste (donc grosso modo qu'on ne fait un hash que au destinataire marqué dans l'entete, pas à ceux qui recoivent via le smtp). Et alors rien ne les empêche soit de simuler une pseudo-liste inexistante, soit de créer eux même leurs liste.
Aucune des solutions explicités ne répond à ce problème : le filtrage de la liste, sa modération ou la contrainte d'être inscript ne servent à rien si c'est le spammeur qui contrôle (ou simule la liste). Et le seul moyen de faire la différence entre une liste réelle et un truc de spammeur c'est faire un filtre par white list .. on retourne en rond avec le problème des utilisateurs qui n'iront jamais tenir à jour une white list (enfin pas ceux que je connais)
Le spammeur ne peut pas controler/simuler la liste puisque le principe repose sur le fait que chaque utilisateur "s'inscrit" à la liste (whitelist).
Je pense que s'inscrire est simple, et peut très bien devenir une contraite imposée aux neuneux. Il ne faut pas oublier qu'actuellement, si tu ne le fais pas (si tu ne configures pas tes filtres) ca veut dire que tu vas recevoir du courrier qui ne t'es pas destiné explicitement. Du point de vue MUA, c'est la même chose qu'un BCC. La plupart des gens passent ça direct dans leur boite spam actuellement. Rien n'empêche le neuneu du futur de continuer à lire son spam s'il ne veut pas s'inscrire. Le système permet de fournir de meilleures informations aux antispam, ensuite il est clair qu'il est plus prudent pour les FAI d'informer leurs utilisateurs de ce qu'ils peuvent faire de ces infos (faire confiance par défaut à l'antispam au prix de s'inscrire aux listes voulues, ou alors recevoir le spam aussi).
Elle est bien la FAQ mais encore une fois ta citation répond à coté. Je parle bien de bêtement monter des serveurs chez le spammeurs, parce que le cpu ce n'est pas vraiment ce qui leur coute cher. Je ne parle pas de voler le cpu à des zombies.
Ce n'est pas économiquement réaliste pour les spammeurs. Le spammeur n'a aucun intérêt à dépenser 100+ euros pour lui permettre d'envoyer un spam supplémentaire par seconde. Calcule qu'actuellement ils en envoient 150 par seconde.
Je crois que le problème bien de là : on ne vit pas dans le même monde. Dans mon monde imposer aux machines de ramer pour envoyer un mail ce n'est acceptable que pour quelques utilisateurs finaux avec bonne machine : ni pour les sites perso, ni pour les sites pro, ni pour les entreprises, ni pour madame michu avec son vieux tromblon qui veut envoyer ses voeux.
Je ne suis pas d'accord mais je crois que tu étais déjà au courant :) Certains "acquis" d'Internet seront amenés à évoluer puisque la population d'utilisateurs n'a plus rien à voir. On va aller vers plus de contrainte. Cette contrainte me semble très acceptable par rapport au problème actuel et futur du spam et la vacuité des autres solutions. Madame Michu a toujours accepté de passer 2 heures à se faire chier à écrire 50 fois la même chose et coller 50 timbres sur ses cartes postales de voeux. Bien sûr il ne faut pas abandonner gratuitement les capacités supplémentaires que permet l'ordinateur, mais dans le cas d'espèce cette solution me semble un bon compromis.
Ce n'est pas parce que MS cherche à imposer une mauvaise solution qu'on est obligés de faire pareil en catastrophe.
Hashcash date de 1997, et est déjà intégré par plusieurs grands noms (gnus, spamassassin).
Je suis d'accord avec ta phrase, mais par contre c'est parce que microsoft cherche à imposer une mauvaise solution qu'il faut encore plus se bouger le cul pour tenter d'apporter une bonne réponse au problème avant qu'une mauvaise réponse ne nous soit imposée de l'extérieur. J'ai découvert hashcash il y a 4 jours et je trouve que c'est pas mal.
Notes qu'à choisir entre les deux celle de MS me parait meilleure que le coup du hash à calculer (et pourtant je n'aime pas celle de MS).
Laquelle ?
Je pars du principe que ce n'est pas parce que des gens proposent des trucs que c'est forcément une bonne idée. Des trucs idiots ou simplement pas bons on en a vu pas mal, même en ne parlant que des anti-spam ça doit se compter par centaines.
Bien sûr. Alors concentrons-nous sur les vraies questions en fonction de ce qu'il y a dans hashcash et les réponses données aux questions de base dans la FAQ.
Tu pars toi même sur le principe que la solution de MS est mauvaise et qu'il vaut mieux les hash. Laisses donc aux autres la possibilité d'être critique sur ce que tu soutiens si tu l'es sur ce que d'autres soutiennent.
J'avais plutôt l'impression de défendre presque l'idée de "paiement pour les mails" proposée par microsoft depuis un certain temps. Quant à sender ID, oui j'ai une mauvaise opinion du truc à partir du moment où microsoft veut le faire passer en force et qu'il semble inefficace face au spam !
Euh, j'espère que non parce que sinon tous les SPAM vont avoir un "To" sur une adresse semblant de ML (beaucoup le font déjà) et n'auront qu'un seul hash à calculer.
Il n'y a pas d'échapatoire : soit tu fais un hash par destinaire (long) soit tu demande au destinataire de mettre l'adresse en liste blanche (illusoire)
C'est marrant, masi tu penses pas que ces questions ont déjà des réponses ? Pourquoi partir du principe que ce truc est débile ? Bon puisque j'en ai marre de paraphraser la FAQ à chaque fois :
They might. Well in fact they already are. You can see the attraction: they get a for-free open-relay -- the mail server -- you send it mail and it sends mail to the thousands of users who subscribe to the list in question. Even with hashcash the spammer gets more bang for his buck: he computes one stamp and gets to deliver to many recipients.
There are different things that can and have been done to combat this. (Again these anti-spam approaches cause mailing-list related email loss for users).
* One approach is to allow only subscribers to post. (This is incovenient for people with multiple addresses, or who use different MTAs depending on where they are -- your mail gets rejected. This happens to me all the time and is very annoying.)
* Another approach is filtered versions of the list, or moderated lists, though this tends to lead to bias and less free discourse if the moderator also moderates discussion (beyond just squelching spam.)
* Another approach is to impose some anti-spam technology to the list feed. Such as keyword filtering. Some people do this and the problem there is occasionally mail gets dropped due to false positives.
There is also a collaborative filtering system called NoCeMs, though this requires client software, or at minimum delivery delays while the NoCeMs are accumulated.
Ou alors ils augmenteront leur puissance de calcul (qui ne doit pas être actuellement ni le facteur limitant ni le facteur le pluscher).
FAQ :
# But won't spammers steal CPU time?
Spammers already compromise security on many users machines to make so-called "Zombie" armies to send spam from. However currently the rate at which spammers can send mail on a zombie machine is limited purely by the speed of those machine's internet links. A typical DSL user might be able to send 25 unique messages per second each of size 1KB (assumes 256kbit uplink). Or many more messages per second if the messages are delivered to multiple users at once (using multiple Cc or Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on the highest end pc hardware at time of writing. This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once).
10~20 pour les autres ? à 20s, si ma copine envoie ses voeux ou une nouvelle importante (on se marie bientot) à son carnet d'adresse ça veut dire une heure de calcul. Je ne parle même pas de *mon* carnet d'adresse. C'est loin d'être négligeable, même en arrière plan. Même sur un site perso un mail d'information à 1000 personnes c'est loin d'être rare. [...]
Je ne peux pas répondre grand chose si tu pars de ce type de scénario. Dans le monde réel le maximum de personnes à qui j'ai envoyé un mail ça n'a jamais du dépasser 15 (au delà il y a les mailing-lists, c'est fait pour ça, et même sur yahoo tu peux t'en faire gratos sans besoin de serveur).
Au lieu d'attendre que Microsoft impose son système, tout en conduisant des discussions à n'en plus finir visant à trouver la solution parfaite (hint : il n'y aura pas de solution parfaite), je pense qu'on devrait essayer de voir en face ce système qui n'est pas idéal mais qui est la moins mauvaise solution qu'il m'ait été personnellement donné de voir.
Euh, j'espère que non parce que sinon tous les SPAM vont avoir un "To" sur une adresse semblant de ML (beaucoup le font déjà) et n'auront qu'un seul hash à calculer.
Il n'y a pas d'échapatoire : soit tu fais un hash par destinaire (long) soit tu demande au destinataire de mettre l'adresse en liste blanche (illusoire)
C'est marrant, masi tu penses pas que ces questions ont déjà des réponses ? Pourquoi partir du principe que ce truc est débile ? Bon puisque j'en ai marre de paraphraser la FAQ à chaque fois :
They might. Well in fact they already are. You can see the attraction: they get a for-free open-relay -- the mail server -- you send it mail and it sends mail to the thousands of users who subscribe to the list in question. Even with hashcash the spammer gets more bang for his buck: he computes one stamp and gets to deliver to many recipients.
There are different things that can and have been done to combat this. (Again these anti-spam approaches cause mailing-list related email loss for users).
* One approach is to allow only subscribers to post. (This is incovenient for people with multiple addresses, or who use different MTAs depending on where they are -- your mail gets rejected. This happens to me all the time and is very annoying.)
* Another approach is filtered versions of the list, or moderated lists, though this tends to lead to bias and less free discourse if the moderator also moderates discussion (beyond just squelching spam.)
* Another approach is to impose some anti-spam technology to the list feed. Such as keyword filtering. Some people do this and the problem there is occasionally mail gets dropped due to false positives.
There is also a collaborative filtering system called NoCeMs, though this requires client software, or at minimum delivery delays while the NoCeMs are accumulated.
Ou alors ils augmenteront leur puissance de calcul (qui ne doit pas être actuellement ni le facteur limitant ni le facteur le pluscher).
FAQ :
# But won't spammers steal CPU time?
Spammers already compromise security on many users machines to make so-called "Zombie" armies to send spam from. However currently the rate at which spammers can send mail on a zombie machine is limited purely by the speed of those machine's internet links. A typical DSL user might be able to send 25 unique messages per second each of size 1KB (assumes 256kbit uplink). Or many more messages per second if the messages are delivered to multiple users at once (using multiple Cc or Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on the highest end pc hardware at time of writing. This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once).
10~20 pour les autres ? à 20s, si ma copine envoie ses voeux ou une nouvelle importante (on se marie bientot) à son carnet d'adresse ça veut dire une heure de calcul. Je ne parle même pas de *mon* carnet d'adresse. C'est loin d'être négligeable, même en arrière plan. Même sur un site perso un mail d'information à 1000 personnes c'est loin d'être rare. [...]
Je ne peux pas répondre grand chose si tu pars de ce type de scénario. Dans le monde réel le maximum de personnes à qui j'ai envoyé un mail ça n'a jamais du dépasser 15 (au delà il y a les mailing-lists, c'est fait pour ça, et même sur yahoo tu peux t'en faire gratos sans besoin de serveur).
Au lieu d'attendre que Microsoft impose son système, tout en conduisant des discussions à n'en plus finir visant à trouver la solution parfaite (hint : il n'y aura pas de solution parfaite), je pense qu'on devrait essayer de voir en face ce système qui n'est pas idéal mais qui est la moins mauvaise solution qu'il m'ait été personnellement donné de voir.
Il y a les lettres d'information, les listes de diffusion très publiques (genre la ML Linux mais c'est très loin d'être un cas à part) ou simplement de serveurs qui ont des listes à faible/moyen traffic maisen nombre importat. Bref, beaucoup de cas qui doivent représenter un volume assez important pour être gênés.
Et non, croire que les utilisateurs vont établir des whitelist à chaque fois qu'ils s'inscrivent quelque part c'est totalement illusoire. De même qu'il est autant illusoire de croire que les utilisateurs vont accepter de perdre ces mails en se disant "c'est normal j'ai oublié de remplir la whitelist" (et là je prend le pai qu'ils s'en rendront compte, ce qui est déjà probablement une erreur).
En fait je disais une connerie à ce sujet. Il n'y a aucune surcharge pour les mailing-list. On génère un timbre hashcash avec comme destinataire la mailing-list, et un seul. Rien à faire du côté de la ML. Il suffit de configurer son hashcash en réception pour recevoir des mails de cette mailing-list (mais on le fait déjà en configurant le filtre).
Quant à gêner les spammeurs, je ne suis pas sûr que ce qui leur coute le plus cher ce soit la puissance de calcul, franchement. Et même alors, je ne suis pas sûr que multiplier le nombre de serveurs en interne les empêche vraiment d'opérer.
Le but d'un spammeur est d'envoyer le plus de mails possibles avant de se faire choper. Ils en envoient 10'000 par minute en ce moment. S'ils ne peuvent plus qu'en envoyer 60 à la minute je suis preneur, ça veut dire que je passerai de 150 spams par jour à une quantité négligeable.
Pire, avec la montée en fréquence des machines ce qui prend 5 secondes aujourd'hui ne prendra déjà plus que 4 secondes le temps que ça se mette en place, dans les deux secondes une vingtaine de mois après. C'est vraiment à court terme.
Non, le seul risque c'est de casser la fonction cryptographique SHA-1. Pour la montée en puissance aucun problème, on sélectionne en ce moment une collision partielle à 20 bits, il suffit de monter ce nombre de 1 pour multiplier par 2 le temps nécessaire à la génération. Il suffira de monter au fur et à mesure le nombre de bits minimum pour qu'un timbre soit accepté.
Que fait on ? on change d'algo tous les ans pour prendre en compte la montée en puissance ? sympa pour ceux qui sont encore en PII-500. Si celui qui a un P4-3Ghz met 5 secondes, celui qui a un PII-500 commence à en mettre quasiment 30. Rien que pour envoyer ses voeux à son carnet d'adresse son ordinateur risque de ramer une heure alors qu'il devrait faire ça en moins d'une minute. Bonjour aussi les gens qui devront tenir tout ça à jour pour supporter à chaque fois le nouvel algo.
On parle de 1 seconde pour les machines de haut niveau, donc peut-etre environ 10~20 pour les autres. Si le plugin est intelligent, c'est fait en arrière-plan, fin du problème.
1er octobre : passage du senderid chez msn et hotmail
attitude des boites : peut-on se permettre de ne plus pouvoir communiquer avec nos clients qui utilisent des emails msn et hotmail ? non, alors on met à jour.
résultat, une certaine masse critique est atteinte, et plus grand monde ne pourra ignorer le truc.
1. Ca n'évitera pas le spam, ils trouveront un moyen de contourner ce système à la con (tm) en moins de temps qu'il ne faut pour contourner un système anticopie de CD audio
Va te documenter sur hashcash et on en reparle. Là tu parles dans le vent complet. Moi je l'ai lue, et je peux te dire que ce que tu dis est faux.
2. Ca va faire chier tout le monde (moi déjà, je ne vois pas pourquoi je ralentirai artificiellement mon système), surtout les applications web qui doivent envoyer pas mal de mails (profiles utilisateurs, confirmations de commandes, ...)
Ben non. Documente-toi sur hashcash. Au pire des cas ton mail met 1~5 secondes de plus à partir, et dans le meilleur des cas le plugin est assez intelligent pour le faire en background. Ca ne représente aucun inconvénient pour l'utilisateur.
C'est le "beaucoup" de mails qu'il faut bien saisir. Le spam, c'est environ 10'000 mails à la minute. Ralentis cette possibilité d'un facteur 10 à 1000 et tu ne fais chier que les spammeurs. Il n'y a aucune utilisation légitime de cela (à part les spam "lettres d'informations" à optin, mais d'une part ce serait pas une grande perte, et d'autre part tu peux utiliser des whitelists pour ça).
je ne vois pas trace de la mention de posixité dans le man de sort, et vu que les specs posix ne semblent pas disponibles gratuitement.. tu as un pointeur ?
Normalement la stabilité de l'algorithme ne devrait pas influer sur sa performance. Un algorithme de tri stable semble être (d'après perldoc -f sort) la caractéristique de garder l'ordre initial d'éléments qui comparent comme étant égaux. Vu le reste de la doc perl et des chiffres ci-dessous, je dirais que la demande d'un algo stable fait passer de l'utilisation de quicksort à mergesort, qui est plus efficace dans ce cas particulier.
Perl 5.6 and earlier used a quicksort algorithm to implement sort. That algorithm was not stable, and could go quadratic. (A stable sort preserves the input order of elements that compare equal. Although quicksort’s run time is O(NlogN) when averaged over all arrays of length N, the time can be O(N**2), quadratic behavior, for some inputs.)
In 5.7, the quicksort implementation was replaced with a stable mergesort algorithm whose worst case behavior is O(NlogN). But benchmarks indicated that for some inputs, on some platforms, the original quicksort was faster. 5.8 has a sort pragma for limited control of the sort. Its rather blunt control of the underlying algorithm may not persist into future perls, but the ability to characterize the input or output in implementation independent ways quite probably will.
portable ? sort utilisé sous Linux est l'implémentation GNU d'un outil classique Unix, ce n'est pas un problème de portabilité, sort n'est pas standardisé.
en plus, ça m'étonnerait que les coreutils GNU d'où provient sort ne soient pas portables sur tes vieux Unix propriétaires.
Pour ma part, c'est l'utilisation du javascript qui fout en l'air le bouton Back du navigateur. Pourtant il y a la technique du # comme exposé récemment dans un commentaire linuxfr à un autre propos (ruby on rails / ajax).
est-ce que tu me suggere d'essayer le noyau de la 9.2?
ce n'est pas vraiment conseillé avec les changements systèmes, par exemple devfs->udev, je ne sais pas si un "vieux" kernel est supporté.
essaie des options au boot; tu tappes Echap, puis "linux" suivi d'une option.
je suggère les options :
- acpi=off
- noapic
- nolapic
et des combinaisons de ces options. il y a peut-etre d'autres options nouvelles plus recentes que je ne connais pas, ceci dit.
tu dois pouvoir t'en sortir en choissant "failsafe" aussi, et une fois booté tu peux éditer le /etc/fstab pour enlever le swap (rajoute juste un # devant la ligne du swap), puis rebooter à nouveau.
Toute la subtilité est de savoir si la société te vend un logiciel ou non. Je pense qu'ils affirment que c'est un tout non séparable, donc pas un logiciel, donc ils n'ont pas l'obligation de révéler les sources.
Le coeur du problème, c'est que le projet SNF a été très mal vendu, et lorsque Mandrake s'était aperçu que même des boîtes de service (Cap Gemini si ma mémoire est bonne, par exemple) s'en servaient dans leurs offres sans que Mandrake ne soit officiellement au courant du truc, une certaine amertume a été ressentie. Pour sauver le produit MNF, il avait été décidé de mettre une licence plus restrictive sur le produit fini. Le coeur restant libre, les contributeurs les bienvenus (et pour être honnête, utiles au produit), mais un mécanisme permettant d'éviter le "pillage" du produit fini. Il est apparemment très difficile pour ce produit de trouver une place commercialement viable aux yeux de Mandriva.
[^] # Re: editeur à la place de l'IDE
Posté par gc (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 5.
les mamans ourses. c'est féminin boudiou.
[^] # Re: Sun oui ! mais...
Posté par gc (site web personnel) . En réponse au journal Shocking : du matos Sun pas cher !. Évalué à 4.
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 2.
Je n'ai pas distingué la première partie de ta phrase (réponse sur la ML) de la deuxième partie et je m'en excuse :
Toi tu me dis qu'il n'y a besoin que d'un seul hash si on envoie à une liste (donc grosso modo qu'on ne fait un hash que au destinataire marqué dans l'entete, pas à ceux qui recoivent via le smtp). Et alors rien ne les empêche soit de simuler une pseudo-liste inexistante, soit de créer eux même leurs liste.
Aucune des solutions explicités ne répond à ce problème : le filtrage de la liste, sa modération ou la contrainte d'être inscript ne servent à rien si c'est le spammeur qui contrôle (ou simule la liste). Et le seul moyen de faire la différence entre une liste réelle et un truc de spammeur c'est faire un filtre par white list .. on retourne en rond avec le problème des utilisateurs qui n'iront jamais tenir à jour une white list (enfin pas ceux que je connais)
Le spammeur ne peut pas controler/simuler la liste puisque le principe repose sur le fait que chaque utilisateur "s'inscrit" à la liste (whitelist).
Je pense que s'inscrire est simple, et peut très bien devenir une contraite imposée aux neuneux. Il ne faut pas oublier qu'actuellement, si tu ne le fais pas (si tu ne configures pas tes filtres) ca veut dire que tu vas recevoir du courrier qui ne t'es pas destiné explicitement. Du point de vue MUA, c'est la même chose qu'un BCC. La plupart des gens passent ça direct dans leur boite spam actuellement. Rien n'empêche le neuneu du futur de continuer à lire son spam s'il ne veut pas s'inscrire. Le système permet de fournir de meilleures informations aux antispam, ensuite il est clair qu'il est plus prudent pour les FAI d'informer leurs utilisateurs de ce qu'ils peuvent faire de ces infos (faire confiance par défaut à l'antispam au prix de s'inscrire aux listes voulues, ou alors recevoir le spam aussi).
Elle est bien la FAQ mais encore une fois ta citation répond à coté. Je parle bien de bêtement monter des serveurs chez le spammeurs, parce que le cpu ce n'est pas vraiment ce qui leur coute cher. Je ne parle pas de voler le cpu à des zombies.
Ce n'est pas économiquement réaliste pour les spammeurs. Le spammeur n'a aucun intérêt à dépenser 100+ euros pour lui permettre d'envoyer un spam supplémentaire par seconde. Calcule qu'actuellement ils en envoient 150 par seconde.
Je crois que le problème bien de là : on ne vit pas dans le même monde. Dans mon monde imposer aux machines de ramer pour envoyer un mail ce n'est acceptable que pour quelques utilisateurs finaux avec bonne machine : ni pour les sites perso, ni pour les sites pro, ni pour les entreprises, ni pour madame michu avec son vieux tromblon qui veut envoyer ses voeux.
Je ne suis pas d'accord mais je crois que tu étais déjà au courant :) Certains "acquis" d'Internet seront amenés à évoluer puisque la population d'utilisateurs n'a plus rien à voir. On va aller vers plus de contrainte. Cette contrainte me semble très acceptable par rapport au problème actuel et futur du spam et la vacuité des autres solutions. Madame Michu a toujours accepté de passer 2 heures à se faire chier à écrire 50 fois la même chose et coller 50 timbres sur ses cartes postales de voeux. Bien sûr il ne faut pas abandonner gratuitement les capacités supplémentaires que permet l'ordinateur, mais dans le cas d'espèce cette solution me semble un bon compromis.
Ce n'est pas parce que MS cherche à imposer une mauvaise solution qu'on est obligés de faire pareil en catastrophe.
Hashcash date de 1997, et est déjà intégré par plusieurs grands noms (gnus, spamassassin).
Je suis d'accord avec ta phrase, mais par contre c'est parce que microsoft cherche à imposer une mauvaise solution qu'il faut encore plus se bouger le cul pour tenter d'apporter une bonne réponse au problème avant qu'une mauvaise réponse ne nous soit imposée de l'extérieur. J'ai découvert hashcash il y a 4 jours et je trouve que c'est pas mal.
Notes qu'à choisir entre les deux celle de MS me parait meilleure que le coup du hash à calculer (et pourtant je n'aime pas celle de MS).
Laquelle ?
Je pars du principe que ce n'est pas parce que des gens proposent des trucs que c'est forcément une bonne idée. Des trucs idiots ou simplement pas bons on en a vu pas mal, même en ne parlant que des anti-spam ça doit se compter par centaines.
Bien sûr. Alors concentrons-nous sur les vraies questions en fonction de ce qu'il y a dans hashcash et les réponses données aux questions de base dans la FAQ.
Tu pars toi même sur le principe que la solution de MS est mauvaise et qu'il vaut mieux les hash. Laisses donc aux autres la possibilité d'être critique sur ce que tu soutiens si tu l'es sur ce que d'autres soutiennent.
J'avais plutôt l'impression de défendre presque l'idée de "paiement pour les mails" proposée par microsoft depuis un certain temps. Quant à sender ID, oui j'ai une mauvaise opinion du truc à partir du moment où microsoft veut le faire passer en force et qu'il semble inefficace face au spam !
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 0.
Il n'y a pas d'échapatoire : soit tu fais un hash par destinaire (long) soit tu demande au destinataire de mettre l'adresse en liste blanche (illusoire)
C'est marrant, masi tu penses pas que ces questions ont déjà des réponses ? Pourquoi partir du principe que ce truc est débile ? Bon puisque j'en ai marre de paraphraser la FAQ à chaque fois :
# Won't spammers start spamming mailing lists instead?
They might. Well in fact they already are. You can see the attraction: they get a for-free open-relay -- the mail server -- you send it mail and it sends mail to the thousands of users who subscribe to the list in question. Even with hashcash the spammer gets more bang for his buck: he computes one stamp and gets to deliver to many recipients.
There are different things that can and have been done to combat this. (Again these anti-spam approaches cause mailing-list related email loss for users).
* One approach is to allow only subscribers to post. (This is incovenient for people with multiple addresses, or who use different MTAs depending on where they are -- your mail gets rejected. This happens to me all the time and is very annoying.)
* Another approach is filtered versions of the list, or moderated lists, though this tends to lead to bias and less free discourse if the moderator also moderates discussion (beyond just squelching spam.)
* Another approach is to impose some anti-spam technology to the list feed. Such as keyword filtering. Some people do this and the problem there is occasionally mail gets dropped due to false positives.
There is also a collaborative filtering system called NoCeMs, though this requires client software, or at minimum delivery delays while the NoCeMs are accumulated.
Ou alors ils augmenteront leur puissance de calcul (qui ne doit pas être actuellement ni le facteur limitant ni le facteur le pluscher).
FAQ :
# But won't spammers steal CPU time?
Spammers already compromise security on many users machines to make so-called "Zombie" armies to send spam from. However currently the rate at which spammers can send mail on a zombie machine is limited purely by the speed of those machine's internet links. A typical DSL user might be able to send 25 unique messages per second each of size 1KB (assumes 256kbit uplink). Or many more messages per second if the messages are delivered to multiple users at once (using multiple Cc or Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on the highest end pc hardware at time of writing. This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once).
10~20 pour les autres ? à 20s, si ma copine envoie ses voeux ou une nouvelle importante (on se marie bientot) à son carnet d'adresse ça veut dire une heure de calcul. Je ne parle même pas de *mon* carnet d'adresse. C'est loin d'être négligeable, même en arrière plan. Même sur un site perso un mail d'information à 1000 personnes c'est loin d'être rare. [...]
Je ne peux pas répondre grand chose si tu pars de ce type de scénario. Dans le monde réel le maximum de personnes à qui j'ai envoyé un mail ça n'a jamais du dépasser 15 (au delà il y a les mailing-lists, c'est fait pour ça, et même sur yahoo tu peux t'en faire gratos sans besoin de serveur).
Au lieu d'attendre que Microsoft impose son système, tout en conduisant des discussions à n'en plus finir visant à trouver la solution parfaite (hint : il n'y aura pas de solution parfaite), je pense qu'on devrait essayer de voir en face ce système qui n'est pas idéal mais qui est la moins mauvaise solution qu'il m'ait été personnellement donné de voir.
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 3.
Il n'y a pas d'échapatoire : soit tu fais un hash par destinaire (long) soit tu demande au destinataire de mettre l'adresse en liste blanche (illusoire)
C'est marrant, masi tu penses pas que ces questions ont déjà des réponses ? Pourquoi partir du principe que ce truc est débile ? Bon puisque j'en ai marre de paraphraser la FAQ à chaque fois :
# Won't spammers start spamming mailing lists instead?
They might. Well in fact they already are. You can see the attraction: they get a for-free open-relay -- the mail server -- you send it mail and it sends mail to the thousands of users who subscribe to the list in question. Even with hashcash the spammer gets more bang for his buck: he computes one stamp and gets to deliver to many recipients.
There are different things that can and have been done to combat this. (Again these anti-spam approaches cause mailing-list related email loss for users).
* One approach is to allow only subscribers to post. (This is incovenient for people with multiple addresses, or who use different MTAs depending on where they are -- your mail gets rejected. This happens to me all the time and is very annoying.)
* Another approach is filtered versions of the list, or moderated lists, though this tends to lead to bias and less free discourse if the moderator also moderates discussion (beyond just squelching spam.)
* Another approach is to impose some anti-spam technology to the list feed. Such as keyword filtering. Some people do this and the problem there is occasionally mail gets dropped due to false positives.
There is also a collaborative filtering system called NoCeMs, though this requires client software, or at minimum delivery delays while the NoCeMs are accumulated.
Ou alors ils augmenteront leur puissance de calcul (qui ne doit pas être actuellement ni le facteur limitant ni le facteur le pluscher).
FAQ :
# But won't spammers steal CPU time?
Spammers already compromise security on many users machines to make so-called "Zombie" armies to send spam from. However currently the rate at which spammers can send mail on a zombie machine is limited purely by the speed of those machine's internet links. A typical DSL user might be able to send 25 unique messages per second each of size 1KB (assumes 256kbit uplink). Or many more messages per second if the messages are delivered to multiple users at once (using multiple Cc or Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on the highest end pc hardware at time of writing. This would slow spammers down by a factor of 10-100 or more per compromised machine (depending on whether the messages sent are sent individually or to many users at once).
10~20 pour les autres ? à 20s, si ma copine envoie ses voeux ou une nouvelle importante (on se marie bientot) à son carnet d'adresse ça veut dire une heure de calcul. Je ne parle même pas de *mon* carnet d'adresse. C'est loin d'être négligeable, même en arrière plan. Même sur un site perso un mail d'information à 1000 personnes c'est loin d'être rare. [...]
Je ne peux pas répondre grand chose si tu pars de ce type de scénario. Dans le monde réel le maximum de personnes à qui j'ai envoyé un mail ça n'a jamais du dépasser 15 (au delà il y a les mailing-lists, c'est fait pour ça, et même sur yahoo tu peux t'en faire gratos sans besoin de serveur).
Au lieu d'attendre que Microsoft impose son système, tout en conduisant des discussions à n'en plus finir visant à trouver la solution parfaite (hint : il n'y aura pas de solution parfaite), je pense qu'on devrait essayer de voir en face ce système qui n'est pas idéal mais qui est la moins mauvaise solution qu'il m'ait été personnellement donné de voir.
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 1.
Et non, croire que les utilisateurs vont établir des whitelist à chaque fois qu'ils s'inscrivent quelque part c'est totalement illusoire. De même qu'il est autant illusoire de croire que les utilisateurs vont accepter de perdre ces mails en se disant "c'est normal j'ai oublié de remplir la whitelist" (et là je prend le pai qu'ils s'en rendront compte, ce qui est déjà probablement une erreur).
En fait je disais une connerie à ce sujet. Il n'y a aucune surcharge pour les mailing-list. On génère un timbre hashcash avec comme destinataire la mailing-list, et un seul. Rien à faire du côté de la ML. Il suffit de configurer son hashcash en réception pour recevoir des mails de cette mailing-list (mais on le fait déjà en configurant le filtre).
Quant à gêner les spammeurs, je ne suis pas sûr que ce qui leur coute le plus cher ce soit la puissance de calcul, franchement. Et même alors, je ne suis pas sûr que multiplier le nombre de serveurs en interne les empêche vraiment d'opérer.
Le but d'un spammeur est d'envoyer le plus de mails possibles avant de se faire choper. Ils en envoient 10'000 par minute en ce moment. S'ils ne peuvent plus qu'en envoyer 60 à la minute je suis preneur, ça veut dire que je passerai de 150 spams par jour à une quantité négligeable.
Pire, avec la montée en fréquence des machines ce qui prend 5 secondes aujourd'hui ne prendra déjà plus que 4 secondes le temps que ça se mette en place, dans les deux secondes une vingtaine de mois après. C'est vraiment à court terme.
Non, le seul risque c'est de casser la fonction cryptographique SHA-1. Pour la montée en puissance aucun problème, on sélectionne en ce moment une collision partielle à 20 bits, il suffit de monter ce nombre de 1 pour multiplier par 2 le temps nécessaire à la génération. Il suffira de monter au fur et à mesure le nombre de bits minimum pour qu'un timbre soit accepté.
Que fait on ? on change d'algo tous les ans pour prendre en compte la montée en puissance ? sympa pour ceux qui sont encore en PII-500. Si celui qui a un P4-3Ghz met 5 secondes, celui qui a un PII-500 commence à en mettre quasiment 30. Rien que pour envoyer ses voeux à son carnet d'adresse son ordinateur risque de ramer une heure alors qu'il devrait faire ça en moins d'une minute. Bonjour aussi les gens qui devront tenir tout ça à jour pour supporter à chaque fois le nouvel algo.
On parle de 1 seconde pour les machines de haut niveau, donc peut-etre environ 10~20 pour les autres. Si le plugin est intelligent, c'est fait en arrière-plan, fin du problème.
[^] # Re: meuh
Posté par gc (site web personnel) . En réponse au journal Le punk n'est pas mort. Évalué à 2.
Y'a clairement un problème dans le son. Après, si c'est voulu, c'est comment dire, euh, grave d'être punk à ce point-là :)
[^] # Re: rooooh
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 3.
qu'est-ce qui va se passer ?
1er octobre : passage du senderid chez msn et hotmail
attitude des boites : peut-on se permettre de ne plus pouvoir communiquer avec nos clients qui utilisent des emails msn et hotmail ? non, alors on met à jour.
résultat, une certaine masse critique est atteinte, et plus grand monde ne pourra ignorer le truc.
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 2.
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 1.
Va te documenter sur hashcash et on en reparle. Là tu parles dans le vent complet. Moi je l'ai lue, et je peux te dire que ce que tu dis est faux.
2. Ca va faire chier tout le monde (moi déjà, je ne vois pas pourquoi je ralentirai artificiellement mon système), surtout les applications web qui doivent envoyer pas mal de mails (profiles utilisateurs, confirmations de commandes, ...)
Ben non. Documente-toi sur hashcash. Au pire des cas ton mail met 1~5 secondes de plus à partir, et dans le meilleur des cas le plugin est assez intelligent pour le faire en background. Ca ne représente aucun inconvénient pour l'utilisateur.
C'est le "beaucoup" de mails qu'il faut bien saisir. Le spam, c'est environ 10'000 mails à la minute. Ralentis cette possibilité d'un facteur 10 à 1000 et tu ne fais chier que les spammeurs. Il n'y a aucune utilisation légitime de cela (à part les spam "lettres d'informations" à optin, mais d'une part ce serait pas une grande perte, et d'autre part tu peux utiliser des whitelists pour ça).
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 2.
[^] # Re: base debian
Posté par gc (site web personnel) . En réponse au sondage Que conseiller à Mandriva de racheter ?. Évalué à 4.
# meuh
Posté par gc (site web personnel) . En réponse au journal Le punk n'est pas mort. Évalué à 2.
[^] # Re: Pour sort, ca depend des options
Posté par gc (site web personnel) . En réponse au journal M'enfin ?? .... Évalué à 2.
[^] # Re: Dell semble jouer le jeu
Posté par gc (site web personnel) . En réponse à la dépêche Ces entreprises qui jouent le jeu de l'Open Source. Évalué à 4.
[^] # Re: Pour sort, ca depend des options
Posté par gc (site web personnel) . En réponse au journal M'enfin ?? .... Évalué à 6.
[gc@meuh /tmp] head meuh
39541
21152
70685
8033
13506
82620
34950
34526
99135
29911
[gc@meuh /tmp] /usr/bin/time sort -n meuh > n
0:29.01elapsed
[gc@meuh /tmp] /usr/bin/time sort -ns meuh > ns
0:21.11elapsed
[gc@meuh /tmp] cat meuh | time perl -e 'print sort {$a <=> $b} ' > perldef
0:12.18elapsed
[gc@meuh /tmp] cat meuh | time perl -e 'use sort _quicksort; print sort {$a <=> $b} ' > perlqui
0:18.85elapsed
[gc@meuh /tmp] cat meuh | time perl -e 'use sort _mergesort; print sort {$a <=> $b} ' > perlme
0:12.17elapsed
[^] # Re: glou
Posté par gc (site web personnel) . En réponse au journal M'enfin ?? .... Évalué à 3.
perldoc -f sort :
Perl 5.6 and earlier used a quicksort algorithm to implement sort. That algorithm was not stable, and could go quadratic. (A stable sort preserves the input order of elements that compare equal. Although quicksort’s run time is O(NlogN) when averaged over all arrays of length N, the time can be O(N**2), quadratic behavior, for some inputs.)
In 5.7, the quicksort implementation was replaced with a stable mergesort algorithm whose worst case behavior is O(NlogN). But benchmarks indicated that for some inputs, on some platforms, the original quicksort was faster. 5.8 has a sort pragma for limited control of the sort. Its rather blunt control of the underlying algorithm may not persist into future perls, but the ability to characterize the input or output in implementation independent ways quite probably will.
[^] # Re: Pour sort, ca depend des options
Posté par gc (site web personnel) . En réponse au journal M'enfin ?? .... Évalué à 3.
en plus, ça m'étonnerait que les coreutils GNU d'où provient sort ne soient pas portables sur tes vieux Unix propriétaires.
[^] # Re: juste pour faire chier
Posté par gc (site web personnel) . En réponse au journal Le metier de trolleur.... Évalué à 2.
[^] # Re: normalement non
Posté par gc (site web personnel) . En réponse au message Adresse Mac. Évalué à 2.
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?Media+Access+Control(...)
[^] # Re: Brevets?
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 2.
[^] # Re: j'ai essayé...
Posté par gc (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 4.
[^] # Re: quelque renseignement
Posté par gc (site web personnel) . En réponse au message reboot automatique. Évalué à 2.
ce n'est pas vraiment conseillé avec les changements systèmes, par exemple devfs->udev, je ne sais pas si un "vieux" kernel est supporté.
essaie des options au boot; tu tappes Echap, puis "linux" suivi d'une option.
je suggère les options :
- acpi=off
- noapic
- nolapic
et des combinaisons de ces options. il y a peut-etre d'autres options nouvelles plus recentes que je ne connais pas, ceci dit.
tu dois pouvoir t'en sortir en choissant "failsafe" aussi, et une fois booté tu peux éditer le /etc/fstab pour enlever le swap (rajoute juste un # devant la ligne du swap), puis rebooter à nouveau.
quel est le modèle de ta carte mère ?
[^] # Re: En parlant de sources
Posté par gc (site web personnel) . En réponse au journal Une Freebox Media Player ?. Évalué à 1.
# meuh
Posté par gc (site web personnel) . En réponse au journal Sortie de la MNF 2 et colére des testeurs.... Évalué à 7.