Journal Hashcash, vers une solution contre le spam ?

Posté par (page perso) .
Tags : aucun
0
30
juin
2005
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.
  • # et les mailings lists ?

    Posté par . Évalué à 6.

    imaginons que je sois admin d'un site avec une grosse mailing list (genre 400-450 abonnés), et une grosse activité quotidienne, je fais comment avec ton système positif ?
    • [^] # Re: et les mailings lists ?

      Posté par . Évalué à 2.

      et bien soit tu passe des accords avec des FAI pour être sur leur whitelist ou tu multithreadise l'envoi de mails (ou les deux)
      • [^] # Re: et les mailings lists ?

        Posté par (page perso) . Évalué à 5.

        multithreader ne changera rien : le serveur t'imposera un temps "d'attente" entre 2 envois, que tu es un ou plusieurs thread, une ou plusieurs machines.

        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 . Évalué à 4.

        Je ne pense pas que ce qoit le boulot des FAI de bloquer les mails, mais uniquement le client final. Si tu t'abonnes à une ML, tu la mets en whitelist.
        É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 . Évalué à 4.

          Il faudrait revenir sur Terre et comprendre que les MLs ne sont pas réservées aux geeks. Un utilisateur qui s'inscrit à une ML doit recevoir les mails de cette ML sans faire de configuration supplémentaire de son client mail, point barre.
          • [^] # Re: et les mailings lists ?

            Posté par . Évalué à 5.

            Mais si l'utilisateur utilise un outil anti-spam, charge lui revient de whitelister d'office les services (ou listes) auxquels il s'abonne (point barre aussi) ; car ce n'est pas au dit service de s'assurer que l'utilisateur n'a pas posé quinze barricades, un champ de mines et un champs de force pour se protéger du "courrier non désiré", alors que c'est ce même utilisateur qui a explicitement souhaité s'abonner à ce service.

            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 (page perso) . Évalué à 2.

        tu multithreadise l'envoi de mails

        Qu'est-ce qu'il ne faut pas entendre ... Comment gaspiller des ressources inutilement.
    • [^] # Re: et les mailings lists ?

      Posté par (page perso) . Évalué à 10.

      faut lire la FAQ je l'ai pas traduite pour rien quand même ?
  • # gpg ?

    Posté par . Évalué à 3.

    La solution a l'air intéressante mais je suis pas super convaincu, tout dabord car le coût de quelques machines de plus pour calculer le hash doit être négligeable, même pour un spammer, et que les probs évoqués dans la FAQ m'ont l'air plutôt rédhibitoires (notament au sujet des ML)
    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 . Évalué à 1.

    une suite de commentaires trollifères sur le hascash et sur le fait qu'il n'est pas forcement utilisable pour une entreprise.
    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 (page perso) . Évalué à 8.

    Comme dit ailleurs, On ne peut séparer la contrainte utilisateur de la contrainte spammer. En effet, ralentir l'envoi de mail, implique un besoin de plus de machines pour TOUS les acteurs du web.
    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 (page perso) . Évalué à 1.

      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 ?
      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 (page perso) . Évalué à 2.

        Je veux bien avoir tord, mais quelqu'un m'explique alors en quoi il faudra multiplier les machines ?
        • [^] # Re: Oui et non

          Posté par (page perso) . Évalué à 2.

          C'est un problème de file d'attente. Si 3600 utilisateurs veulent envoyer un courriel dans une fenêtre d'une heure, la cadence moyenne sera à 1 courriel par seconde. Si le serveur SMTP est reglé pour ne pas répondre à plus d'un courriel par seconde alors une partie de 7000 utilisateurs sur une heure ne pourront pas envoyer de courriel.

          Il faudra donc plus de machines/interfaces pour envoyer les courriels.
          • [^] # Re: Oui et non

            Posté par (page perso) . Évalué à 3.

            Si le serveur SMTP est reglé pour ne pas répondre à plus d'un courriel par seconde
            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 (page perso) . Évalué à 1.

              Si la temporisation est faite pour chaque utilisateur, je pense que tu as raison. Maintenant, il faut identifier l'utilisateur.
              - 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 (page perso) . Évalué à 2.

                adresse IP ? les réseaux nattés seront pénalisés
                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 (page perso) . Évalué à 1.

                  Ah, là, tu preches un convaincu. Cela obligerait quand même, à moyen terme, les personnes à utiliser le serveur de messagerie du fournisseur d'accès, ce qui n'est pas admissible.

                  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 . Évalué à 4.

                  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".
                  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 (page perso) . Évalué à 1.

                    bah oué les solutions existent déjà, et pourtant certains proposent de changer carrement le protocole smtp alors qu'on a tout ce qui faut pour éviter les spams. Ce qu'il faut blacklister c'est les FAIs qui sont des vecteurs de spams : ils seront obligés de prendre des mesures contre leurs clients s'ils le veulent pas tous les pénaliser. Je suis sûr qu'il est facile de trouver un certain "seuil" de tolérance, au dessus duquel le FAI peut être considéré de "complice".
                    • [^] # Re: Oui et non

                      Posté par . Évalué à 3.

                      va voir les reponses des mecs de free quand on leur dis qur leur seveurs sont dans des blacklists d'open-relay indirect. Tu vas pas etre decu...
                      • [^] # Re: Oui et non

                        Posté par . Évalué à 5.

                        faudrait savoir, aussi.


                        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 (page perso) . Évalué à 2.

                          Il serait peut être plus judicieux de prévenir ducon@fai.fr non ?
                          • [^] # Re: Oui et non

                            Posté par . Évalué à 5.

                            l'un n'empeche pas l'autre, mais l'expérience montre assez vite que souvent ducon est vérolé et s'en fout complet (et répond plutot quelque chose du style "lol ! téki ?") voir dans certains cas ducon est un warlodz qui propage directement ses saletés ou recherche des machines ouvertes, donc une personne à éviter.

                            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 . Évalué à 2.

        Il n'est pas question de rajouter des for(inti=0;i<10000000;i++)nop(); entre chaque envoi,

        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 . Évalué à 3.

          Mais non, c'est le client SMTP, sur la machine de la personne qui rédige le mail que le calcul est fait. La chaîne des serveurs n'est pas modifiée. L'absence du résultat du calcul dans le mail pourra entrer dans les critères du client du destinataire du mail pour le classer en spam.
          • [^] # Re: Oui et non

            Posté par . Évalué à 2.

            La chaîne des serveurs n'est pas modifiée.

            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 . Évalué à 4.


      Comme dit ailleurs, On ne peut séparer la contrainte utilisateur de la contrainte spammer. En effet, ralentir l'envoi de mail, implique un besoin de plus de machines pour TOUS les acteurs du web.


      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 . Évalué à 2.

        Je crois plutôt qu'il n'avait pas bien compris que c'est la machine de la personne qui rédige le mail qui calcule le hash. Pour une entreprise, ça serait la même chose, chaque employé a son poste.
        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 . Évalué à 3.

          Je pensais surtout au cas où une entreprise centralise ses envois de mails en un seul serveur smtp, ce qui doit être fréquent. Vu de l'extérieur, le smtp de l'entreprise doit être considéré comme fiable sous peine de devoir faire les calculs... mais d'un autre côté il faut aussi s'assurer qu'on ne considère pas fiable le smtp d'un spammer.
        • [^] # Re: Oui et non

          Posté par . Évalué à 5.

          et comme personne veut repondre a ca visiblement :
          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 . Évalué à 0.

            Pour tous les types d'email où le destinataire s'inscrit quelque part, il est assez simple de trouver une solution: il suffit que l'inscription soit enregistrée aussi au niveau du serveur mail du destinataire, qui ne demandera alors pas de résoudre un "challenge" à l'expéditeur.

            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 . Évalué à 4.

              il suffit que l'inscription soit enregistrée aussi au niveau du serveur mail du destinataire, qui ne demandera alors pas de résoudre un "challenge" à l'expéditeur.

              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 . Évalué à 3.

                Tu mélanges deux choses différentes:
                - 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.


                Fait toi meme le calcul 10 000 clients; 2 secondes par clients.
                un peu lourd tu est TRES gentil.

                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 . Évalué à 4.

                  Et voila le parano de service ..
                  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 . Évalué à 1.

                    Donc hashcash ne repond pas a cette problèmatique

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

                    Dans ce cas autant concevoir un vrai nouveau protocole qui prend le problème du spam en compte

                    Ben ecoute si tu as une meilleure solution, n'hesite pas hein...

                    On ne parle pas de ml [...] Mais bel et bien de newsletters

                    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.

                    Tu es toujours autorise d'envoyer des mails.

                    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.

                    Ca ressemble fort a l'etablissement d'un reseau de confiance

                    Non. Ca ressemble a une whitelist.

                    rien n'empeche de faire du pishing sur les domains qu'on a whitelister non?

                    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"

                    Oui je parlais que du premier round

                    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.

                    Et ensuite il faut que les clients nous ait whitelister

                    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 ?

                    Non juste de changer tous ses logiciels

                    Effectivement, si on change le protocole il faut changer les logiciels :)

                    Donc je vois pas de qui d'autre pourrait faire le tri entre bon et mauvais mails a whitelister.


                    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.

                    L'etablissement d'une whitelist est l'etablissement d'un reseau de confiance.

                    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.

                    les spammeurs c'est drone army

                    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.

                    Donc d'un cote on penalise les entreprise et particulier en utilisant leurs temps cpu

                    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 . Évalué à 1.

                      . Savoir si les gens qui ont propose hashcash sont des gros nazes, ca ne m'interesse pas franchement...
                      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(...)
                      Allez hop une idée comme ca rapidement , pas parfaite vu que je la fais on live
                      Une whitelist globale ; qui comprend tous les serveurs smtp qui sont autorise; et qui respecte certaines conditions. Les seuls mails qui sont autorisé avec cette whitelist sont ceux avec authentification smtp(comme ca on est sur de l'user). L'inscription est gratuite mais soumise a delais (genre 1/2 jours avant publication) La resiliation est immediate ,en cas de spam reporte, temporaire ou definitive suivant les cas. Une resilation temporaire fait juste un greylisting sur ce serveur.


                      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 . Évalué à 2.

                        Qui est un reseau de confiance.

                        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.

                        Et une newsletter n'a bien sur rien a voir avec une mailing list...

                        Ben pas grand chose.

                        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.

                        Vous ne changez pas le protocole; vous mettez des rustines. Changez de protocole pour moi c'est repartir de 0.

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

                        Rien compris.

                        J'ai oublie une negation.

                        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

                        Tu veux bien, le temps d'une experience de pensee, accepter que le processus de liste blanche soit automatique ?

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

                        Deja qui dis que c'est un million la division?

                        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.

                        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 ?

                        Et certains particuliers envoient de temps en temps des centaines de mails

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

                        Aie et deja un faux positif.

                        Un faux positif, ca serait quelqu'un qui est marque comme spammer alors qu'il ne l'est pas.

                        Deuxio et si les personnes ont demande mais n'ont pas forcement whitelister ?

                        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.

                        Tant que tu demande a l'utilisateur final de faire une action

                        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 . Évalué à 2.

                          Tu veux bien, le temps d'une experience de pensee, accepter que le processus de liste blanche soit automatique ?
                          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 :(


                          You are making the assumption that spam means to sell something. Spam
                          includes mailbombing, in which the purpose is not commercial at all, but
                          rather purely for annoyance. (there may be secondary commercial purposes,
                          ie, to annoy users at a certain ISP to harm its business, but we can't
                          discover that purpose by looking a single message.

                          The terribly obfuscated spams never seem to be genuinely commercial. But
                          its hard to count*.


                          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 . Évalué à 1.

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

      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 . Évalué à 1.

        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.
        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 . Évalué à 2.

          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.

          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 (page perso) . Évalué à -2.

    http://blog4.lemondeinformatique.fr/le_blog_des_cybriens/2005/06/ho(...)

    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 . Évalué à 1.

    Pourquoi y'aurait pas un système "d'ouverture de session Mail" d'une personne A auprès d'un personne B comme on peut le faire avec ssh ? Avec un échange de clef par exemple.

    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 . Évalué à 8.

    Je m'éloigne peut être un peut du sujet, mais il me semble que la question du spam est assez récurant. J'ai souvenir d'une discutions ou l'on était arrivé plus ou moins a la conclusion que le problème était paradoxale et assez proche de celui de l'IPv6. C'est a dire, que le protocole actuel SMTP, est mal adapté quand a la lute contre le SPAM ( comme Ipv4 est mal foutue pour le tunneling, la crypto etc etc ...), mais que tous le monde tient a ne pas y toucher. On se retrouve donc a mettre en place des correctifs, des sur couches et autres qui sont au final bien plus bordellique et bien moins satisfaisante qu'une remise a plat du protocole. De nombreuses idées bien plus simple et satisfaisante on était proposé ( révocation de contact, contacte unique entre destinataires, etc etc ... En gros le propriétaire de la boite distribue ses droits de poster et les gère comme bon lui semble, un peut comme jabber ou MSN ), mais comme Ipv6 personne n'est assez gros pour soutenir ou provoquer un tel changement en masse.

    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 . Évalué à 0.

      tout a fait d'accord. Mais y a quand meme du boulot a faire ;)
  • # N'imp

    Posté par . Évalué à 9.

    C'est n'importe quoi cette idée !

    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 (page perso) . Évalué à 5.

      Autre chose... Il a été dit que certains spams étaient envoyés à partir de PC compromis. Dans ce cas ca ne coûte plus rien au spammer, mais fait ramer le PC. Il suffit d'avoir plus de PC compromis pour pouvoir envoyer plus de spam.
      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 (page perso) . Évalué à 2.

        Ouais, et punir le vol c'est une incitation à tuer sa victime pour ne pas se faire choper.

        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 . Évalué à 3.

          tu as vu où que le spammeur pourrait compromettre plus de machines,
          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 . Évalué à 4.

    Merci pour cette traduction. J'ai relevé une erreur qui revient plein de fois : on écrit 'relais' et pas 'relai'.

    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 . Évalué à 4.

      pas evident a traduire...

      La meilleur traduction que j'ai trouver est pb d'acces concurent...
      • [^] # Re: traduction de la FAQ

        Posté par . Évalué à 2.

        Je confirmissoie.

        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 (page perso) . Évalué à 2.

          En fait c'est un collègue qui m'a parlé de "problème de course", j'ai eu du mal à comprendre la première fois mais ensuite ça m'a semblé bien.

          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 . Évalué à 2.

            ouais enfin si le gars sait a quoi correspond le principe de race condition ; il comprendra l'expression "race condition" .
            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 à ceux qui les ont postés. Nous n'en sommes pas responsables.