Forum Linux.général Vaincre le SPAM. Ou essayer, au moins.

Posté par (page perso) . Licence CC by-sa
3
16
déc.
2016

Bonjour à tous,

J'essaye, tant bien que mal, d'optimiser avec le temps mon serveur mail, et surtout diminuer le spam.
J'ai une conf postfix/spamassassin, avec un peu de scripting perso qui récupère les IP des SMTP qui m'ont envoyé du spam, et les balance dans fail2ban. Un peu de bayes le soir pour apprendre des spams en plus.

Néanmoins, si c'était aussi simple…
Je reçois toujours le même genre de spam, même genre de subject/body, avec un ptit lien de pRon. En plus du spam/porn français ! Si c'est pas mignon.
Il arrive depuis plein de coin du monde selon les whois, donc galère galère…
Hormi rajouter des mots clés dans ma blacklist de spamassassin je sais pas trop comment faire.

D'où ma super question du gars qui croit au père noël (oh oh oh) : est-ce qu'il y a un moyen de remonter le chemin du spam, ou de trouver le site web à l'origine qui a donné (ou s'est fait pomper) mon adresse mail pour ce spam ?

Si vous avez d'autres idées de conf spamassassin je suis preneur.. actuellement j'ai ça (c'est sûrement grandement améliorable) :

required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
bayes_auto_expire 1
bayes_auto_learn_threshold_spam 8.0
bayes_path /var/lib/spamassassin/bayes/bayes

dns_available yes
skip_rbl_checks 0
use_razor2 1
use_pyzor 1

urirhssub       URIBL_BLACK  multi.uribl.com.        A   2
body            URIBL_BLACK  eval:check_uridnsbl('URIBL_BLACK')
describe        URIBL_BLACK  Contains an URL listed in the URIBL blacklist
tflags          URIBL_BLACK  net
score           URIBL_BLACK  3.0

urirhssub       URIBL_GREY  multi.uribl.com.        A   4
body            URIBL_GREY  eval:check_uridnsbl('URIBL_GREY')
describe        URIBL_GREY  Contains an URL listed in the URIBL greylist
tflags          URIBL_GREY  net
score           URIBL_GREY  0.25

urirhssub       URIBL_JP_SURBL  multi.surbl.org.        A   64
body            URIBL_JP_SURBL  eval:check_uridnsbl('URIBL_JP_SURBL')
describe        URIBL_JP_SURBL  Has URI in JP at http://www.surbl.org/lists.html
tflags          URIBL_JP_SURBL  net
score           URIBL_JP_SURBL  3.0

score DCC_CHECK 4.000
score RAZOR2_CHECK 2.500
score BAYES_99 4.300
score BAYES_95 3.500
score BAYES_80 3.000

header LOCAL_SUBJECT      Subject =~ /sex/i
score LOCAL_SUBJECT       5.0

body LOCAL_HEADER       /sex/i
score LOCAL_HEADER      5.0

ok_languages fr en de

Merci, et gros câlins.

  • # Début de piste

    Posté par (page perso) . Évalué à 4. Dernière modification le 16/12/16 à 14:04.

    Salut,

    je ne sais pas trop comment est configuré ton postfix, mais je crois savoir que le caractère "+" est un peu magique pour les emails, et permet de personnaliser une adresse.
    Je m'explique :
    mon adresse mail est supertoto@gmail.com
    Et bien google considère que tout ce qui est de la forme supertoto+string@gmail.com est la même chose que supertoto@gmail.com

    Est ce que seul google fait ca? je ne crois pas, étant donné qu'il me semble que c'est dans la norme du formatage des adresse email. (que je n'arrive pas à retrouver…)

    Tout ca pour en venir au fait que lorsque je fournis mon adresse mail à un tiers, j'en profite pour la personnaliser.
    Si je donne mon adresse pour créer un compte client chez "bigcompany.com", je leur donne comme email supertoto+bigcompany@gmail.com

    Du coup quand je reçois du spam, si je vois qu'il a été envoyé à l'adresse supertoto+bigcompany@gmail.com, je sais que c'est bigcompany qui a revendu mon adresse aux spammer.

    C'est donc un début de piste pour répondre à ta question " y a t'il un moyen de remonter le chemin du spam, ou de trouver le site web à l'origine qui a donné (ou s'est fait pomper) mon adresse mail"

    • [^] # Re: Début de piste

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

      Hello

      Il est configuré comme ça mon postfix.

      Je l'utilise aussi le +, qui permet à postfix d'ignorer la suite du +.
      Sauf qu'apparemment les spams que je reçois doivent provenir d'avant… et j'utilise pas forcement le + dans certains forum sinon c'est un peu la galère pour se loguer.

    • [^] # Re: Début de piste

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

      Est ce que seul google fait ca? je ne crois pas, étant donné qu'il me semble que c'est dans la norme du formatage des adresse email. (que je n'arrive pas à retrouver…)

      Ce n'est pas une norme si je ne m'abuse, seulement une pratique commune. Et donc oui la plupart des serveurs mails permettent cela (par défaut sûrement même). Mon serveur Postfix+Dovecot permet cela aussi (je me souviens plus si j'ai dû activer une option ou si c'est par défaut).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Début de piste

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

        De mémoire il faut juste activer "recipient_delimiter="+"" dans la conf de postfix :)
        ça permet de gérer des utilisateurs virtuels.

    • [^] # Re: Début de piste

      Posté par . Évalué à 3.

      C'est donc un début de piste pour répondre à ta question " y a t'il un moyen de remonter le chemin du spam, ou de trouver le site web à l'origine qui a donné (ou s'est fait pomper) mon adresse mail"

      sauf que mailer intelligent il va faire regex de sa base de données, pour prendre avant le + et apres le @
      histoire que tu ne saches justement pas d'ou viennent les fuites.

    • [^] # Re: Début de piste

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

      Pas seulement Google : RFC 5233

      Voir le Subadressing.

  • # Améliorer ta configuration?

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

    J'ai une conf postfix/spamassassin, avec un peu de scripting perso qui récupère les IP des SMTP qui m'ont envoyé du spam, et les balance dans fail2ban. Un peu de bayes le soir pour apprendre des spams en plus.

    En sus d'essayer de "remonter le chemin du spam" (tu feras quoi si tu trouves la source d'ailleurs?), tu peux essayer d'améliorer ta config.

    Déjà, peut-être que spamassassin n'est pas le meilleur choix? Perso j'utilise dspam qui marche plutôt bien, mais il paraît que son développement est au point mort et que certaines distribs commencent à le retirer. Récemment quelqu'un sur linuxfr faisait un peu de pub pour rspamd, plus récent et qui paraîtrait-il marche bien mieux. Notamment il donnait le lien vers un test de performance (fait par le dév de rspamd). D'après ces tests, rspamd fonctionne mieux que dspam et spamassassin (ce dernier utilise apparemment les mêmes filtres bayésiens que Bogofilter et par conséquent faut regarder "Bogofilter" pour comparer dans ton cas).

    J'ai pas encore eu le courage de tester rspamd (parce que mon dspam, bien que non parfait, marche quand même relativement bien et que configurer mon serveur email, ça prend du temps et ne me met pas en joie…), mais ça peut valoir le coup si tu as le temps et si tu es trop mécontent de ton installation.

    Deuxième amélioration possible: le réapprentissage. Tu dis que tu le fais le soir. Quelle est ta procédure exactement? Pourquoi ne fais-tu pas du réapprentissage constant et temps réel?
    Perso, j'ai mis en place une boîte au lettre "spam" et si un spam n'est pas correctement détecté (il arrive dans Inbox, cad "Ham False Positive"), le déplacer dans le répertoire spam lance un réapprentissage sur ce spam. Au contraire, si je repère un email valide dans ma boîte spam ("Spam False Positive"), le déplacer hors du répertoire lance aussi un réapprentissage inverse.
    Je trouve cette façon de faire bien plus simple car en gros, c'est naturel: au moment où je suis dans mon lecteur de courriers, le simple fait de déplacer les messages dans un autre répertoire (ce qui est assez naturel de base) va lancer des réapprentissages.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Améliorer ta configuration?

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

      Perso j'utilise spamassassin qui marche très bien.

      Par contre, pour éviter le spam j'ai décidé de monter fortement la confiance que j'ai au filtre baysien de spamassassin quand celui-ci atteind 99% :

      score BAYES_99 8.000

    • [^] # Re: Améliorer ta configuration?

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

      Merci pour ton commentaire.
      En fait je lance juste une mise à jour du filtre le soir, avec un truc genre :

      /usr/bin/sa-learn --spam /home/nicolas/Maildir/.Junk/{cur,new} --dbpath /var/lib/spamassassin/bayes/
      /usr/bin/sa-learn --ham /home/nicolas/Maildir/{cur,new} --dbpath /var/lib/spamassassin/bayes/

      Comment fais-tu pour que le déplacement génère le réapprentissage ? ça serait pas mal en effet.

      Forcement si je retrouve la source je ne ferai pas grand chose, hormis me désabonner du dit site même si le mal est déjà fait :p

      Je vais regarder côté rspamd, ça coûte rien de l'étudier à part, et s'il met plait de le mettre par défaut :) Merci pour le conseil

      • [^] # Re: Améliorer ta configuration?

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

        C'est un peu violent ta méthode. En fait tu ré-entraines tous les jours avec l'ensemble de tes emails au lieu de seulement les erreurs? Je me demande même si ça peut pas être mauvais pour la qualité du filtre.

        Comment fais-tu pour que le déplacement génère le réapprentissage ? ça serait pas mal en effet.

        Franchement j'ai tout réglé y a des années et j'essaie d'y toucher le moins possible (en général, seulement lors de mises à jour si besoin).
        Mais j'ai jeté un œil et je crois que c'est grâce au plugin antispam de Dovecot. Si tu fais tourner dspam en daemon, tu peux alors communiquer avec dspam --client et lui envoyer des signatures d'email à réapprendre (en spam ou ham selon le type d'erreur). Sur le web, tu trouves divers tutoriaux qui donne des exemples de configuration, par exemple:
        https://kuther.net/howtos/integrate-dspam-postfix-dovecot-any-mail-client (tout en bas de page)

        Je ne saurais te donner plus de détails car — comme je disais — c'est super vieux pour moi et j'ai vraiment pas envie de me plonger sur le sujet si je peux éviter (la mise en place d'un serveur email fonctionnel est un vrai calvaire). J'espère que ces infos te donneront les pistes nécessaires.

        Bien sûr, je te donne la version dspam mais je suis persuadé que spamassassin ou rspamd ont une méthode de réapprentissage équivalente.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Améliorer ta configuration?

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

          Toutes les semaines je lance le script suivant. Il apprend des mails classés (spam et ham) par contre je n'apprend pas des mails qui sont dans la boite de réception (non classé) pour éviter d'apprendre du SPAM en tant que HAM.

          #!/bin/sh
          
          MAILDIR=/data/vmail
          SADIR=/var/lib/amavis/.spamassassin
          DBPATH=/var/lib/amavis/.spamassassin/bayes
          
          for domain in `ls $MAILDIR` ; do 
              echo "Domain: $domain"
              for user in `ls $MAILDIR/$domain` ; do 
                  echo "  User: $user"
                  ls -a $MAILDIR/$domain/$user/ | grep -e "^\.[^\.]" | grep -v "Junk" | grep -v "Sent" | grep -v "Trash" | grep -v "Drafts" | grep -v "Corbeille" | grep -v "Brouillons" | while read box ; do
                      echo "    Box: $box"
                      nice sa-learn --ham --showdots --dbpath $DBPATH "$MAILDIR/$domain/$user/$box/cur"
                  done
                  ls -a $MAILDIR/$domain/$user/ | grep "Junk" | grep -e "^\.[^\.]" | while read box ; do
                      echo "    Spam Box: $box"
                      nice sa-learn --spam --showdots --dbpath $DBPATH "$MAILDIR/$domain/$user/$box/cur"
                  done
              done
          done
          
          chown -R amavis:amavis $SADIR
          chmod -R 0755 $SADIR
          
          exit 0
  • # Configuration de Postfix

    Posté par . Évalué à 1.

    As-tu mis en oeuvre tous les dispositifs anti-spam de Postfix ?

    • vérification du domaine de l'expéditeur
    • vérification du PTR du MTA
    • blocage des adresses dynamiques
    • greylisting
    • vérification des listes noires

    …et quelques autres qu'on peut trouver dans des tutoriels divers.

    Un durcissement de Postfix peut rendre les filtres internes comme Spamassassin tout à fait inutiles.

    • [^] # Re: Configuration de Postfix

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

      hello

      j'ai déjà en effet activé quelques un:
      smtpd_recipient_restrictions =
      permit_mynetworks,
      permit_sasl_authenticated,
      reject_unauth_destination,
      reject_invalid_hostname,
      reject_unauth_pipelining,
      reject_non_fqdn_sender,
      reject_unknown_sender_domain,
      reject_non_fqdn_recipient,
      reject_unknown_recipient_domain,
      reject_rbl_client zen.spamhaus.org,
      reject_rhsbl_client dbl.spamhaus.org,
      permit

      • [^] # Re: Configuration de Postfix

        Posté par . Évalué à 1.

        Oui, avec la constitution de tes propres listes noires de MTAs et d'expéditeurs. (check_client_access & check_sender_access)

        Ajoute l'analyse des entêtes (peut-être la solution pour ton porn français ?).

        Le rejet des IP dynamiques.

        Bien entendu, à chaque liste noire correspond une liste blanche constituée automatiquement sur la base des mails sortants et manuellement quand un faux positif est détecté.

    • [^] # Re: Configuration de Postfix

      Posté par (page perso) . Évalué à 3. Dernière modification le 17/12/16 à 19:23.

      Je veux bien que certaines options puissent améliorer la donne, mais rendre un filtre anti-spam inutile, sûrement pas! S'il suffisait juste de quelques options pour avoir une boîte email sans spam et surtout sans faux-positifs (c'est le plus important: on ne veut surtout pas rejeter un email valide, c'est bien pire que de laisser passer quelques spams), alors le spam sur internet ne serait pas un tel problème.

      vérification du domaine de l'expéditeur

      Ça veut dire quoi ça? Tu acceptes que certains domaines? Genre si t'es pas Gmail ou Yahoo, ça va pas, email refusé?

      Ou alors tu veux vérifier si l'email est transmis avec un HELO qualifié avec un nom de domaine? Si c'est le cas, c'est une mauvaise méthode et tu peux te retrouver à bloquer des serveurs tout à fait OK. Tiens une petite recherche vite faite sur le web, qui donne des conseils avec lesquels je suis d'accord.

      Ou bien tu parles du SPF? SPF part d'une bonne idée, mais là aussi je me suis rendu compte que dans la réalité, des mails peuvent se perdre. Voici une histoire vraie qui m'est arrivée:

      • Quelqu'un de @redhat.com m'a envoyé un email sur mon adresse @gimp.org. Comme j'en ai marre d'avoir 100 adresses, je préfère les alias. Mon adresse @gimp.org est donc un alias sur mon adresse principale.
      • Puisque c'est un alias, l'email est passé par les serveur de gnome.org (bien qu'il soit parti de redhat.com).
      • Mon serveur a donc reçu un email disant provenir de redhat.com mais en apparence venant de gnome.org. Puisque RedHat a un enregistrement SPF strict et que j'avais configuré mon serveur pour obéir strictement aux règles SPF, ce dernier a rejeté cet email pourtant tout à fait valide (et même possiblement important). Je ne l'aurais jamais su si cette personne de RedHat ne m'avait pas ensuite contacté par une autre adresse pour me prévenir du problème. Et pourtant dans cette exemple tout le monde a fait parfaitement comme on lui demande: RedHat a un enregistrement strict, l'employé envoyait bien depuis les serveurs RedHat, mon serveur avait une politique stricte… SPF ne prend tout simplement pas la possibilité d'alias email en compte.

      Depuis j'ai appris ma leçon et je ne configure plus mon serveur email pour appliquer une politique SPF stricte en attendant de trouver une alternative (mais j'ai pas l'impression que ça existe).
      SPF a aussi des problèmes dans l'autre sens (envoi d'emails qui sont refusés), similaire aux alias, alors qu'on suit toutes les règles de bonne conduite, mais bon je vais pas détailler chaque cas possible qui peut mal tourner.

      blocage des adresses dynamiques

      Certains font de l'auto-hébergement et arrivent à associer des IPs dynamiques à un nom de domaine de manière transparente. C'est prise de tête, et je le ferais pas, perso, mais c'est quand même internet et je vais pas les refuser. Les personnes avec IPs dynamiques ne sont pas des sous-citoyens. Internet n'est pas que les gros serveurs des GAFAM.

      vérification des listes noires

      Les listes noires, ça bloque tout et n'importe quoi. Et pour se faire retirer de certaines, c'est la croix et la bannière. Pour le coup, ça bloque bien plus que des IPs dynamiques, mais aussi souvent des IPs fixes de fournisseurs d'accès (donc on considère qu'un particulier a pas le droit d'héberger un serveur?), et aussi des IPs d'hébergeurs sous prétexte que quelqu'un dans le bloc a loué une fois un serveur pour spammer.
      En gros, là c'est Internet == GAFAM++.

      Ensuite c'est une discussion qui revient souvent sur linuxfr et je ne vais pas revenir dessus. Je donne cependant mon avis: les listes noires, c'est mauvais.

      greylisting

      Je pense que c'est la seule bonne idée de la liste.

      Forcément si tu configures Postfix pour refuser tout et n'importe quoi, t'as plus de problème de spam, mais en même temps tu limites ton réseau à une micro portion de l'internet. Mon internet à moi, il est quand même un peu plus grand et va au delà de Google et Co.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Configuration de Postfix

        Posté par . Évalué à 1.

        Mon internet à moi

        Il est fort possible effectivement que nos situations ne soient pas comparables.

        A Nicolas de voir comment est son internet.

Suivre le flux des commentaires

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