Journal Tactiques de lutte anti-SPAM: greylist ?

Posté par  (site web personnel) .
Étiquettes :
0
22
mai
2006
Bonjour à tous.

J'ai découvert le concept "greylist" sur le dernier numéro de Gnu Linux Magazine France http://www.ed-diamond.com/produit.php?produit=429 permettant de filter le spam dès la négociation smtp, avant même d'en accepter la délégation.

Auparavant, j'utilisais un système à base de spamassassin, produisant une note (post délagation, le courriel est accepté, en cours de traitement), note utilisée ensuite de 2 façons:

1. un filtrage dans le MTA (jamais fonctionné décemment chez moi)
2. un filtrage dans le MUA (merci thunderbird, ses filtres humains et bayesiens) http://fr.wikipedia.org/wiki/Inf%C3%A9rence_bay%C3%A9sienne

J'ai rapidement trouvé un résumé sur le paquet Debian greylistd http://www.debian-administration.org/articles/167

Le filtre est installé depuis maintenant 4 jours, ce qui me permet de subjectivement le trouver efficace.

Avez vous des réactions/expériences/avis/statistiques ?

Rafael

  • # Avis positif

    Posté par  . Évalué à 3.

    Avez vous des réactions/expériences/avis/statistiques ?

    Expérience plus que positive !
    installation extrêment simple sous debian avec postfix : apt-get install postgrey.
    Depuis que nous avons mis en oeuvre ce principe de greylisting, nous supprimons entre 1000 et 1500 spams pour à peu près l'équivalent de mails corrects qui passent...

    donc, que du bonheur...

    • [^] # Re: Avis positif

      Posté par  (site web personnel) . Évalué à 4.

      Pareil : c'est efficace ici aussi:

      http://emu.freenetproject.org/cgi-bin/mailgraph.cgi

      bon, j'ai d'autre regles assez stricte sur les EHLO aussi, m'enfin la majeure partie c'est postgrey.

      le spam c'est tabou, on en viendra tous a bout!

      • [^] # Re: Avis positif

        Posté par  (site web personnel) . Évalué à 1.

        j'ai d'autre regles assez stricte sur les EHLO

        Tu peux les diffuser ou les expliquer ? C'est toujours bon à prendre un petit tuning supplémentaire contre le spam :o)

        Proverbe Alien : Sauvez la terre ? Mangez des humains !

    • [^] # Re: Avis positif

      Posté par  (site web personnel) . Évalué à 3.

      Expérience positive aussi sur un serveur au boulot.

      Dans tous les cas si c'est un serveur pour plusieurs utilisateurs il y a deux choses intéressantes à spécifier :

      - leur demander quels sont leurs correspondants réguliers et importants pour pouvoir autoriser (whitelister) les domaines concernés

      - définir une période de tests claire (si possible pendant une période non critique) pour éviter que des courriers soient ralentis alors qu'ils sont urgents.

  • # Bof

    Posté par  . Évalué à 2.

    C'est peut-être efficace mais c'est bien contraignant, ca rajoute un sacré délai dans la délivrance du mail et ça crée parfois des problèmes avec les serveurs SMTP maison, où le domaine ne correspond pas au nom d'hôte de la machine etc...
    Bref, je ne suis pas convaincu du tout.

    • [^] # Re: Bof

      Posté par  . Évalué à 1.

      Ca dépend des serveurs, oui.
      Par exemple, Gmail attend bien 3 ou 4h avant de retenter, alors que Hotmail attend 10 ou 20 minutes.

      C'est pour ça qu'il faut combiner avec une liste de serveurs autorisés par défaut pour assurer un temps de livraison du mail minimal pour les serveurs "connus".

    • [^] # Re: Bof

      Posté par  (site web personnel) . Évalué à 1.

      pareil. Parfois recevoir le mail avec 2 ou 3 heure de délai, c'est vraiment bof bof... J'ai eu l'expérience de mailling list hébergée derrière ça, et c'est vraiment pas chouette... Suivant les points de départ des mails, ça prend plus ou moins de temps, et les réponses arrivent dans n'importe quel ordre (et souvent, on se tape plusieurs fois la même réponse vu qu'il faut du temps avant qu'elles arrivent).
      Bref, la solution basée sur du spamassassin (http://mailcleaner.net/index_en.html ) à laquelle j'ai gouté pendant longtemps était vraiment plsu agréable de mon point de vu (mais sans doute plus couteuse niveau ressources)

    • [^] # Re: Bof

      Posté par  . Évalué à 1.

      Pas convaincu non plus, je l'avais mis en place 2 ou 3 jours pour tester. C'est sur que ça filtre super bien les spams, mais malheureusement trop de courriers légitimes sont aussi bloqués: les serveur SMTP qui ne respectent pas la RFC par exemple, les mails de Free qui sont envoyés dans un premier temps depuis une adresse IP puis pour le deuxième passage depuis une IP totalement différente, ...

      Tu utilises quel code d'erreur lors du premier passage d'un serveur SMTP ?

  • # uucpssh.org

    Posté par  . Évalué à 4.

    Moi j'utilise uucpssh.org, c'est encore plus simple, c'est eux qui font la config :) Greylist, antispam, café, etc.
    D'ailleurs, c'est pour quand la possibilité de faire des dons ?

    • [^] # Re: uucpssh.org

      Posté par  . Évalué à 1.

      Ca marche comment cette bete. J'ai jamais compris et du coup je ne me suis jamais lance.

      Si tu utilises, tu dois avoir des informations a me faire partager :)

      Ai-je par exemple besoin d'un serveur SMTP comme actuellement ? (j'heberge mon domaine et les services afferents (smtp, pop, imap, ...)).

      Merci

      J'ai egalement deux adresses que j'utilises frequemment mais dont je ne controle pas les serveurs SMTP, comment cela se passe-t-il alors ?

      Merci

      • [^] # Re: uucpssh.org

        Posté par  . Évalué à 2.

        Tu dois pouvoir modifier les entrées DNS des domaines, donc tu peux le faire que pour tes propres domaines, pas pour free.fr par exemple.

        Une fois inscrit, tu déclares main.uucpssh.org comme ton MX principal.

        Tu mets en place un script cron qui récupère les emails toutes les 10 minutes. Ces emails sont ensuites donnés à mon postfix en local. Je pense que tu dois garder un SMTP en local, mais y'en a des légers, genre Exim, ça doit pas mettre à genoux ta machine.

        Dans les logs, ça donne (l'id 10 correspond à l'utilisateur uucp) :

        May 22 12:50:01 rincevent /USR/SBIN/CRON[17934]: (uucp) CMD (/usr/sbin/uucico -f -suucpssh)
        May 22 12:50:11 rincevent postfix/pickup[16789]: C09C1C7000: uid=10 from=<EXPÉDITEUR@MAIL>
        May 22 12:50:11 rincevent postfix/cleanup[17941]: C09C1C7000: message-id=<87psi6fi9p.fsf@rincevent.net>
        May 22 12:50:11 rincevent postfix/qmgr[6574]: C09C1C7000: from=<EXPÉDITEUR@MAIL>, size=2965, nrcpt=1 (queue active)
        May 22 12:50:11 rincevent postfix/local[17942]: C09C1C7000: to=<adresse_locale@domaine hébergé>, relay=local, delay=0, status=sent (delivered to command: procmail -a "$EXTENSION")
        May 22 12:50:11 rincevent postfix/qmgr[6574]: C09C1C7000: removed


        Y'a toutes les infos sur le site d'uucpssh.org.

        J'en suis absolument satisfait :)

        • [^] # Re: uucpssh.org

          Posté par  . Évalué à 1.

          C'est etrange. Comment cela peut-il etre si interessant pour les posseseurs de portables ? (comme indique sur le site).

          • [^] # Re: uucpssh.org

            Posté par  . Évalué à 2.

            Les emails sont stockés sur uucpssh tant que tu les récupères pas. Suffit de lancer une récupèration quand tu es connecté, et voilà, tu as tes emails sur ton portable en local, transmis par un flux chiffré.

            • [^] # Re: uucpssh.org

              Posté par  . Évalué à 1.

              Certes mais dommage qu'il ne soit pas possible de le faire pour n'importe quelle adresse mail -i.e. qu'il faille un SMTP/DNS "controlable". Du coup ca perd de son charme.

    • [^] # Re: uucpssh.org

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Puis un jour je terminerai bien le nouveau serveur.

      Ensuite il sera possible de faire des dons, ou de payer une somme ridicule tous les mois pour avoir des options en plus. Un jour... :)

  • # combinaison de techniques

    Posté par  . Évalué à 3.

    il s'agit de combiner des mauvaises techniques pour en faire une seule bonne, qui permet d'éviter de retarder la majorité des mails légitimes :

    J'avais lu cela sur :
    http://blog.madism.org/index.php/2006/03/25/79-debianorg-and(...)

  • # Avis positif, mais...

    Posté par  . Évalué à 3.

    Nous utilisons cette technique depuis plus d'un an maintenant et nous en sommes pleinement satisfait.

    Il y a bien quelques gros sites d'ou l'adresse de réessai est différente, à gérer en liste blanche, et quelques sites très mal configuré (l'occasion de le signaler aux administrateurs en question).

    Il y a toutefois 2 limitations amha. La première concerne les messages redirigés : il suffit que le message transite par une liste ou un .forward sur un serveur n'utilisant pas cette technique pour qu'il passe sans encombre.
    La seconde, c'est que la réponse des spammeurs à la généralisation de cette technique ne c'est pas faite attendre : de plus en plus de zombis et autres serveurs relais implémentent désormait cette partie de la RFC... le greylisting perd donc petit à petit de son efficacité, même si pour le moment il reste une très bonne arme vu son rapport qualité/prix ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.