Les spammeurs utilisent bien sûr les ressources qui sont à leur disposition, à savoir nos propres serveurs, ce qui leur coûte moins cher et rend plus difficile leur détection. Par exemple, ils peuvent attaquer un serveur de messagerie pour en prendre le contrôle mais ce n'est pas discret et c'est vite détectable. Ils peuvent aussi se constituer un réseau d'ordinateurs zombie qui vont, pendant une période donnée, envoyer des milliers de messages à des destinataires aléatoires appartenant à un seul nom de domaine. Par exemple, les courriers vont être envoyés sans cesse par les bots à hjsghjd@mondomaine.fr, jgjkhgr@mondomaine.fr, hsfgoihs@mondomaine.fr etc.
Le serveur de messagerie ne va pas pouvoir délivrer ces messages car les destinataires sont inconnus. Suivant sa configuration, il va soit :
1) Les renvoyer à leur destinataire
2) Les supprimer
3) Les rediriger vers une adresse de messagerie qui collecte tous les messages envoyés à une adresse erronée (adresse catch-all). C'est pratique pour récupérer les messages lorsque l'expéditeur se trompe dans l'orthographe du nom d'un destinataire, par exemple jan.bon@mondomaine.fr au lieu de jean.bon@mondomaine.fr.
La solution 1 est celle généralement paramétrée par défaut sur les serveurs de messagerie et c'est celle qu'attendent les spammeurs. En effet, les messages de spam vont contenir comme adresse d'expéditeur les adresses des personnes qu'ils veulent réellement spammer. les méls vont être rejetés vers ces personnes et votre serveur devient en quelque sorte un serveur de spam. L'adresse IP de votre serveur risque alors de se retrouver inscrite sur diverses listes noires (voir http://multirbl.valli.org/lookup/ pour vérifier si c'est le cas) et vos correspondants habituels rejetteront vos messages s'ils sont abonnés à ces listes (c'est gênant).
La solution 3 embête les spammeurs. Elle est pratique pour récupérer les messages erronés envoyés par vos correspondants habituels mais vous allez vous retrouver submergés de spam et vous allez devoir ajouter sans cesse des filtres antispam sur l'adresse catch-all. C'est pénible.
La solution 2 embête les spammeurs mais vous allez parfois supprimer des messages envoyés par vos correspondants habituels. c'est gênant. en fait, ce serait la solution idéale si votre serveur de messagerie était capable de comparer plus finement chaque message collecté avec la liste des destinataires existants. Il faudrait que les messages adressés à un nom ressemblant fortement à un des destinataires existant (par exemple 90% de caractères en commun) soit redirigés vers l'adresse catch-all et que les autres messages de spam soient supprimés.
Savez-vous si un tel système existe ?
# Forum
Posté par NeoX . Évalué à 3.
vu qu'il y a une question à la fin de ce post
ca ferait une bonne entrée dans le forum, qui est quand meme là pour poser les questions.
# plop
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Effectivement, avec les trois solutions décrites ici, tu risques d'avoir pas mal de problèmes.
Ce n'est pas une solution. Le back scatter provient toujours d'une erreur de configuration. Un serveur ne doit pas accepter de messages sur la foi d'une adresse d'expéditeur mais sur celle de l'adresse de destinataire ou d'une authentification.
Les catch all sont un nid à spam qu'il convient de ne jamais utiliser. Il faut déclarer une série d'adresses explicites.
Il ne faut jamais droper de messages. Soit on l'accepte, soit on le rejette avec un message d'erreur explicite. En cas de faux positif, ni l'expéditeur, ni le destinataire ne sont prévenus.
La solution consiste à délivrer les spam dans une boite dédié (Dossier spam) qu'on videra automatiquement des messages les plus anciens et de paramétrer un filtre bayésien permettant de prendre en compte dans le trie effectué par les utilisateurs (déplacement vers spam, deplacement depuis spam.
L'autre solution est de paramétrer une quarantaine pour obliger l'utilisateur à trier les messages douteux et ainsi encore une fois éduquer un filtre bayésien.
Le vrai problème du spam aujourd'hui, c'est les abonnements abusifs à des newsletters qui sont beaucoup plus difficiles à trier car il y a derrière des moyens et de méthodes légitimes d'envoi.
[^] # Re: plop
Posté par NumOpen . Évalué à 1. Dernière modification le 13 janvier 2014 à 10:11.
"La solution consiste à délivrer les spam dans une boite dédié (Dossier spam) qu'on videra automatiquement des messages les plus anciens et de paramétrer un filtre bayésien permettant de prendre en compte dans le tri effectué par les utilisateurs (déplacement vers spam, deplacement depuis spam. "
-> c'est ce que je fais actuellement. Tous les messages récupérés par le catch-all sont délivrés à une adresse spécifique et je fais des filtres avec des règles. Mais ça oblige à faire des nouveaux filtres sans cesse donc ce n'est pas une bonne solution.
C'est pourquoi je voudrais une solution différente :
- Je pars du principe que ce n'est pas aux utilisateurs à s'occuper de filtrer leurs messages (ils ont d'autres chats à fouetter) mais au serveur de messagerie de faire le travail.
- Pour tous les messages qui arrivent avec un nom de destinataire différent des noms existants, le serveur les supprime tous sauf si le nom du destinataire a au moins x % de caractères identiques à un des noms de destinataire existant ET si cela n'arrive pas un nombre de fois trop grand (à définir) pendant une durée à définir. Si un message n'est pas supprimé, il est redirigé vers l'adresse ressemblante.
[^] # Re: plop
Posté par ZeroHeure (site web personnel) . Évalué à 6.
N'importe quoi. Je m'en sers depuis près de 20 ans, sans avoir plus de spams que sur un compte gmail par exemple. Un catch-all c'est très pratique : je donne l'adresse que je veux à mes correspondants et je peux filtrer en fonction. Les correspondants victimes de bots ou de virus spammeurs sont repérés instantanément.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: plop
Posté par dinomasque . Évalué à 4.
itou de mon coté.
C'est pratique pour savoir d'ou viennent les fuites (comment l'adresse que je n'ai donné qu'à une célèbre compagnie aérienne franco-néerlandaise se retrouve-t-elle spammé ?) et ça permet de donner des adresses email rigolotes aux gens ;)
BeOS le faisait il y a 20 ans !
[^] # Re: plop
Posté par AgentSteel (site web personnel) . Évalué à 0.
On peut aussi utiliser des adresses mail de la forme moi+sitealacon@mondomaine.net
En pratique ça marche pas mal.
[^] # Re: plop
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Le fait que tu n'ai jamais rencontré le problème ne signifie pas qu'il n'existe pas. Le jour ou ton domaine est attaqué via un dictionnaire de préfixe, tu risques de souffrir.
Et pour les préfixes que tu n'as pas donné tu fais quoi ? Parce que si tu les refuses ce n'est pas exactement un catch all. C'est juste que tu déclares tes adresses dans ton procmailrc au lieu de ton virtusertable. Ce qui permet au passage aux spammers de générer du backscatter ou qui t'obliges à droper des mails .
Je gère une infrastructure d'environ 1 million de mails/jour. Les adresses inexistantes représentent entre 15 et 20 % des tentatives de mail entrant. La dedans, il y a peut être 1% d'erreurs pour 99% de spam. Avec un catch all tout est accepté, filtré, délivré, stocké et l'expéditeur (dans les cas légitimes) ne sais même pas qu'il a fait une erreur. Donc oui les catch all sont un vrai problème et une vrai plaie.
[^] # Re: plop
Posté par oao . Évalué à 2.
Quelle est la proportion de spam dans tes mails entrants ? Si c'est, comme on l'entend souvent, >= 50, 80 ou 90%, les spams sur adresses inexistantes seront une faible portion du nombre total de spam, et les avantages de l'adresse catch-all l'emportera sur 20% de spam en plus. D'autant plus qu'il doit être possible d'entrainer son filtre bayésien pour qu'il prenne en compte l'existence de l'adresse dans ses paramètres.
[^] # Re: plop
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
50% c'est la proportion de connexions sur les MX qui n'aboutissent pas à un mail :
C'est à 95% du spam.
Sur les 50% effectivement accepté, c'est dur à dire. A la louche :
En étant un peu strict en entrée, la plus grosse partie du spam traditionnel ne rentre jamais dans les spools, le reste est correctement filtré.
J'utilise moi même cette infra. J'ai rarement un spam dans ma inbox.
Par contre les pubs sont un vrai problème car les filtres ne marchent pas et surtout ce qui est du spam pour les uns ne l'est pas pour les autres. Il faut donc avoir une politique de filtres individuels, ce qui n'est pas évident à mettre en place sur une grosse infra.
[^] # Re: plop
Posté par ZeroHeure (site web personnel) . Évalué à 2.
On est d'accord, une grosse infra n'a pas les mêmes besoins qu'un individu, c'est une évidence. Je réagissais à ta généralisation abusive : "ne jamais utiliser" :-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# c'est pas neuf comme sujet :)
Posté par fearan . Évalué à 3.
Si la solution miracle existait, ça ferait longtemps qu'elle serait mise en oeuvre.
En attendant, il y a des fournisseur de liste de serveur de mail indésirable (ce qui comprends souvent la quasi totalité des abonnement particuliers), un blocage par défaut du port 25 en sortie…
Comme dit au dessus, ne jamais dropper un mail silencieusement; à la rigueur, c'est fonctionner via un système de liste grise, et dès que tu reçois un mail venant de cette liste ton serveur répond busy (retry later), Si le mail revient effectivement plus tard, tu peux ajouter le serveur dans la liste blanche.
Ensuite en fonction de tes besoins tu peux purger cette liste de temps en temps. L'avantage de cette solution c'est que
1) elle respecte la norme
2) elle ne demande aucune intervention de l'utilisateur
Si tu as des utilisateurs averti tu peux même te débrouiller pour déléguer l'ajout / retrait à la liste blanche à l'utilisateur, mais c'est déjà plus chiant.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: c'est pas neuf comme sujet :)
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Les idées nouvelles ça existe. Avec ce genre de propos défaitistes on ne les mettrai jamais à l'épreuve.
Ou alors tu ne crois pas au progrès, aux idées nouvelles, aux inventions, … ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: c'est pas neuf comme sujet :)
Posté par fearan . Évalué à 2.
Je n'ai pas dit qu'il n'y avait pas de solution, mais pas de solution miracle, des idées pour contrer le spam j'en ai vu plein, tu retrouves toujours le même genre de problématique que pour le filtrage (trop limitant et tu bloque le légitime, trop permissif et tu laisse passer le spam), avec une préférence sur laisser passer le spam plutôt que bloquer du légitime.
Tu as d'un coté ceux qui bossent pour passer outre les solutions de filtrage et d'autres qui proposent des solutions de filtrage, et il n'est pas impossible que des personnes travaille des deux cotés, ajoute à cela un parc de serveur mails immense une population ancrée dans ses habitudes…
Bref tu peux trouver des solutions qui vont compliquer le boulot des spammeur, mais il vont s'adapter (le grey listing divisait par 20 ou 40 le nombre de spam avant, aujourd'hui c'est plutôt autour de 10. Mais si tous les serveur se dotent du même système… le résultat va encore baisser. )
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Autre solution?
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
J'ai eu pendant longtemps ce genre de problème, mais c'était dans les débuts 2000 quand mon serveur était configuré en open relay (erreur de débutant de ma part à l'époque); C'est d'ailleurs un gentil admin réseau qui m'avait prévenu en m'envoyant un mail perso pour me dire qu'il était spammé par mon domaine. Mais ça ne semble plus m'arriver depuis un bail, depuis que j'ai reconfiguré mon serveur pour faire des checks stricts à la reception d'un mail. Je viens de me vérifier et mon serveur n'est pas blacklisté.
Je ne sais pas quelle magie noire opère (je viens de regarder dans mes spams classés par spamassassin) mais il ne me semble pas avoir dedans de mails qui correspondent à l'entourloupe décrite. Je ne connais pas assez le protocole mail, mais je sais que j'avais à peu près fait tout ce qui est là dedans: http://www.cyberciti.biz/tips/postfix-spam-filtering-with-blacklists-howto.html ainsi que deux ou trois autres feintes, faudrait que je retrouve la doc dessus.
Ça n'empechera bien sûr personne de faire croire qu'il envoie un mail de chez moi à partir d'un autre serveur, mais si tout le monde fait plus ou moins ça ça semblerait être efficace pour empêcher l'impersonation que tu décris.
Me trompe-je?
[^] # Re: Autre solution?
Posté par NumOpen . Évalué à 2.
Ce ne sont pas des serveurs configurés en Open Relay qui envoient les méls vers mon serveur mais un réseau d'ordinateurs infectés par un virus. Actuellement, j'ai des messages venant de plus de 40 000 ordinateurs différents, tous les messages sont envoyés à des adresses aléatoires *@mondomaine.fr.
[^] # Re: Autre solution?
Posté par wilk . Évalué à 1.
Tu es sûr qu'ils envoient les spams à ces adresses bidons ? J'ai le même problème, quantité de mails qui arrivent sur des adresses aléatoires *@mondomaine, genre xyzazesdf@mondomain. Mais ce mail n'est pas destinataire du spam, c'est le from utilisé par le spameur, ce que je reçoit c'est le retour si le destinataire n'existe pas, du coup d'un serveur qui n'a pas a être incriminé…
A mon avis c'est que l'ancien hébergeur de @mondomaine était en openrelay…
C'est pas super gênant à part que ça pourri les logs.
[^] # Re: Autre solution?
Posté par NumOpen . Évalué à 1. Dernière modification le 13 janvier 2014 à 13:53.
Non, je ne reçois pas des rebonds mais directement 20 000 spams / jour envoyés à *@mondomaine.fr. Le spammeur utilise mon serveur pour générer des rebonds vers les adresses qu'il veut spammer (elle change dans chaque spam). J'ai donc désactivé les rebonds, tout redirigé vers une adresse spéciale avec le catchall et je voudrais maintenant avoir un filtrage spécifique qui ne conserve que les méls adressés à des adresses ressemblant aux adresses existantes et envoyés à une cadence très faible (donc qui sont des erreurs de frappe et non pas des spams). Au pire, les destinataires recevront statistiquement 2-3 spams à chaque vague de spam, pas plus, mais je ne perdrais pas les messages résultants d'une erreur de frappe dans le nom du destinataire et la probabilité de perte d'un de ces messages sera quasiment nulle et acceptable.
Exemple de spam :
From - Tue Jan 7 08:48:56 2014
X-Account-Key: account3
X-UIDL: UID80428-1386228567
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: inlnm17fmf@spararreda.in
Envelope-to: inlnm17@mondomaine.fr
Delivery-date: Tue, 07 Jan 2014 08:25:17 +0100
Received: from gcg201.internetdsl.tpnet.pl ([83.12.58.201]:2088)
by lucy.fr.planethoster.net with esmtp (Exim 4.82)
(envelope-from inlnm17fmf@spararreda.in)
id 1W0R2L-002GzJ-43
for inlnm17@mondomaine.fr; Tue, 07 Jan 2014 08:25:17 +0100
From: "PfizerLaboratory" inlnm17fmf@spararreda.in
To: inlnm17@mondomaine.fr
Subject: Exclusive Savings For Our Customers
Reply-To: "PfizerLaboratory" inlnm17fmf@spararreda.in
Content-Type: multipart/alternative; boundary="99a7dea9_fef5da6b_e68"
MIME-Version: 1.0
Message-Id: 20140107082512.560329836844@gcg201.internetdsl.tpnet.pl
Date: Tue, 07 Jan 2014 08:25:12 +0200
--99a7dea9_fef5da6b_e68
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Dear, inlnm17,
BLA BLA BLA pub viagra BLA BLA BLA
[^] # Re: Autre solution?
Posté par jyes . Évalué à 3.
Je ne comprends pas pourquoi tu dois générer des rebonds :
Le seul cas où tu dois générer un rebond est le premier cas, ce qui signifie que tu fais confiance à l’émetteur. Si c’est le cas, cesse donc ta confiance temporairement, jusqu’à ce qu’il ait résolu son problème. Si c’est un botnet qui t’écris depuis n’importe où et à des gens dont tu n’es pas responsable (ses adresses générées aléatoirement), je ne vois pas pourquoi ton serveur accepterait la charge de transmettre le message (engagement qui implique d’émettre un avis s’il n'y parvient pas) et n’a donc rien d’autre à faire que d’envoyer bouler le serveur émetteur.
[^] # Re: Autre solution?
Posté par NumOpen . Évalué à 1. Dernière modification le 13 janvier 2014 à 22:47.
Je ne comprends pas. Comment puis-je faire la différence entre les messages qui viennent des bots et les messages qui viennent des clients/fournisseurs/etc. ? Pour le serveur, dans tous les cas, les serveurs émetteurs sont normaux. Je faisais un rebond uniquement si l'adresse de réception n'existait pas, le rebond se faisait vers les adresses d'émetteur à spammer.
J'ai désactivé cela, je redirige maintenant tout vers une adresse spécifique sur laquelle je suis obligé pour l'instant de filtrer.
[^] # Re: Autre solution?
Posté par jyes . Évalué à 1.
Erratum, dans ma liste, le second point commence bien évidemment par « soit l’émetteur n’est pas identifié ».
Pour répondre à ta question, tu es justement dans ce cas, et…
… tu ne peux pas. Par contre tu peux faire la différence entre un destinataire dont tu as la charge du courrier, et un inconnu. Si tu es responsable de l’adresse de destination, alors tu ne peux rien contre ce spam à ce niveau là, mais ce n’est pas ton cas puisque dans le cas que tu décris l’adresse de destination est juste un prétexte pour générer un rebond. Comme l’adresse n’existe pas, il vaut mieux couper la conversation avec le serveur émetteur avant la fin de l’échange plutôt que d’accepter le message. Une fois accepté, tu t’es effectivement « engagé » à fournir un avis de non livraison, le cas échéant. Il vaut donc mieux vérifier la validité de l’adresse de destination pendant l’échange avec l’émetteur que a posteriori, une fois la charge de livrer le message acceptée.
# Adresses supprimées
Posté par NumOpen . Évalué à 1.
Ah, j'oubliais. Il faudrait aussi que je puisse faire une liste des anciennes adresses supprimées, pour conserver les messages envoyés à ces adresses et aux adresses ressemblantes.
Je n'ai pas trouvé de système permettant de faire cela mais je pense que ce serait une bonne solution contre le spam.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.