J'écris mon tout premier journal parce ce que j'aurais bien besoin d'avis exterieurs:
Je suis (entre autre) administrateur mail pour une université, et actuellement sur mon UFR, nous gérons un bon millier de comptes mails (environ 20 000 mails par jour).
Nous utilisons avec bcp de succès les RBL (Realtime Blackhole List). Pour info, hier, alors que nous sommes en période "creuse" de l'année, nos RBL ont arreté 4000 mails et aujourd'hui entre minuit et midi déjà 2000 mails.
Mon problème est le suivant: Je travaille au déploiement d'un service de mail unifié pour l'université. Au lieu d'avoir un serveur de mail par UFR nous allons avoir un seul système de mail (de la bonne taille bien sur).
Le problème lui même etant qu'un autre membre de l'équipe ne veut pas que l'on utilise les RBL pour le service unifié: "on est jamais a l'abris d'un blacklistage par erreur de certains de nos correspondant" et "En cas de coupure réseau, les RBL n'étant plus joignables, le traffic mail interne est bloqué" sont les arguments anti RBL qui reviennent le plus souvent.
Sachant que le service unifié va gérer dans les 200 ou 300 000 mails par jour et sachant que rien que mon UFR, pour 20000 mails acceptés les RBL en refusent environ 6 ou 7000 (taux de faux positif étant proche de 0), je n'ose même pas imaginer le taux de spam que l'on va se prendre...(bon, il y aura SA & CRM derrière, mais mieux vaut éliminer les mails avant de les accepter sur le serveur, non?)
Qu'en pensez vous? Utilisez vous les RBLs? Pensez vous que cela est trop risqué comme mon collègue le prétend alors que nous les utilisons déjà sur plusieurs sites sans aucun problème?
Journal Pour ou Contre les RBL?
12
août
2004
# Mon point de vue
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 5.
Mettre en place un postfix récent avec un système de greylist puis un amavis+spamassassin+razor2+DCC (chercher google). Ne pas utiliser de RBL (effectivement ça peut virer des mails légitimes sans pouvoir faire quoi que ce soit) sauf peut-être relays.ordb.org (les openrelay).
Faire en sorte que les mails internes fonctionnent tout le temps, même en cas de coupure réseau (ça me parait évident).
Et regarder de pres "dspam" qui a l'air mieux que amavis, mais que je n'ai jamais essayé (un retour quelqu'un ?)
[^] # Re: Mon point de vue
Posté par ArnY (site web personnel) . Évalué à 4.
De plus, les serveurs frontaux (les MX) n'ont aucun compte linux, si ce n'ai root, tout les comptes mail sont ldap et ne sont pas des comptes shell. Je crois que pour dspam, il faut utiliser procmail.. pas de comptes shell, pas de procmail (procmail etant assez gourmand, pour gerer 40 000 comptes, ca fait un peu peur)
Dspam n'est pas une alternative à amavis (qui utilise l'API perl de SpamAssassin et fait l'interface postfix/anvirus) mais plutot un remplacant de spamd dans une architecture spamc/spamd (et donc avec procmail, encore)
Pour ce qui est de DCC et Razor2, il y a eu un temps ou j'utilisais ca.. le probleme etant que cela ralenti enormement le traitement du mails.. d'apres les timings d'amavis: 200ms avec les RBL mais sans DCC ni Razor, 1s avec les rbls et Razor et 1600ms avec RBL, DCC et Razor...
J'avais des problèmes avec Razor, certains mail de mailing lists etaient répertoriés sur les serveurs de Razor.. y compris des ML de la nasa... les chercheurs n'ont pas trop aimé.
Pour DCC, le problème est un peu le même.. certains mail en provenance de ml très répandue sont scoré sur DCC..
[^] # Re: Mon point de vue
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Si spamassassin inclus dans amavis utilise razor2 et DCC, il y a une pondération, donc le fait d'être inclus dans DCC ne fait pas que le spam est directement refusé. Par exemple sur http://uucpssh.org/(...) on refuse tout ce qui est supérieur à 5.4, très peu de false positive (quelques uns depuis des mois, à la limite du spam réel), même si parfois reporté par DCC. Sinon tu peux toujours rajouter dans ta whitelist amavis les listes internes ou les plus populaires qui seraient susceptibles d'être bloquées.
Pour DCC tu dois pouvoir mettre un serveur local qui fera proxy, ça peut peut-être aider. Mais c'est sûr qu'à chaque fois que tu rajoutes des requêtes externes pour chaque mail, ça rame plus...
# arguments.
Posté par Pierre . Évalué à 2.
C'est le probleme du false positive. Normalement ca arrive très peu.
"En cas de coupure réseau, les RBL n'étant plus joignables, le traffic mail interne est bloqué"
Tu rajoute une règle avant RBL qui laisse passer les mails internes.
Sinon, si j'ai bien compris, RBL ne gère que le spam envoyé d'addresses IP bien connues. Personnelement, je recois plus de virus que de vrai spams.
Si vous avez un peu de budget pour permettre un peu d'analyse, bogofilter s'en sort plutot pas mal, et prends beaucoup moins de ressources que SpamAssassin.
Tu peux dans un premier temps l'entrainer avec les mails acceptés/rejetés par RBL.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 1.
Tu fais ca comment avec postfix? les rbls ne sont pas locales.. je ne gère pas leur contenu.
Personnelement, je recois plus de virus que de vrai spams.
Exactement, c'est la nouvelle tendance.. de plus en plus de virus servent à envoyer du spam et contre cela, les rbls antirelay sont inutiles.. C'est pour cela que j'utilise aussi un antispam classique derriere
Pour bogofilter, même raison que pour dspam, je ne veux/peux pas utiliser procmail vu que cela se passe sur un serveur relai.
De plus, avec plusieurs milliers d'utilisateurs, je ne peux pas me premettre d'utiliser un flitre bayesien (je veux pas qu'un utilisateur décide qu'un mail de pub quelconque est un spam et qu'un autre décide que cela n'en est pas un)
[^] # Re: arguments.
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Tu fais ca comment avec postfix? les rbls ne sont pas locales.. je ne gère pas leur contenu.
mynetworks = /etc/postfix/reseaux
smtpd_client_restrictions = permit_mynetworks, reject_rbl_client ...
De plus, avec plusieurs milliers d'utilisateurs, je ne peux pas me premettre d'utiliser un flitre bayesien
C'est quoi concrêtement la solution que tu as envisagée pour le moment alors ?
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 2.
smtpd_client_restrictions = permit_mynetworks, reject_rbl_client ...
ah.. ben c'est comme ca que l'on fait.. le probleme des rbl pas joignables en cas de coupure réseau n'est pas mon argument mais celui de mon collegue anti-RBL.. j'ai jamais eu ce problème la personnellement.. j'ai pas vérifié la config de leur serveur de mail.
Concretement, on aura postfix (peut etre avec spf via postfix-policyd) amavis avec SpamAssassin et peut-etre CRM114 qui sera alimenté par les admins (CRM114 qui est actuellement en test, est largement plus performant que les filtres bayesiens que nous avons testé) le score de CRM114 donnera un score à amavis, qui sera ajouté au score de Spamassassin pour le calcul du score final, cela permet de minorer/majorer SpamAssassin.
Nous avons aussi testé avec le filtre bayesien de SA, mais cela ne nous convenait pas...il faut lui apprendre les bons et les mauvais mails, or les mails que recoit un admin ne sont pas forcement représentatifs des mails recu par un chercheur ou un étudiant.
Avec CRM114, c'est bcp plus simple.. tu ne lui donnes que des corrections: t'as un faux-positif, alors tu lui dis "tu t'es trompé, c'est pas un spam", si t'as un faux-negatif, alors tu lui dis "en fait, ca c'est un spam", on peut alors l'éduquer au cas par cas via une interface que l'on est en train de développer (on envoie un mail a une adresse donnée, si le mail est un spam, alors CRM114 l'apprend comme faux-positif et vis-versa). Avec une 10aine de corrections, CRM114 donne déja de très bons résultats ce qui permettra aux admins de maintenir un bon niveau de reconnaissance.
[^] # Re: arguments.
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: arguments.
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 1.
Pour le grey listing, je ne pense pas que cela puisse s'appliquer chez nous:
- au final on aura environ 40 000 comptes mails, donc je suppose plusieurs centaines de milliers de mails par jours.. je ne crois pas que refuser le mail une premiere fois soit une bonne option.
- nous partons avec 3 MX de poids egal, un mail qui est d'abord refusé (par le grey listing) sur un MX ne sera pas forcement renvoyé sur le meme.. . à moins d'avoir un spool commun.
Je n'ai pas vraiment envisagé cette solution, en fait.. peut être l'ai-je éliminée trop tot... si qq'un l'a mise en oeuvre sur une structure équivalente, je suis preneur de feedback.
[^] # Re: arguments.
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Le problème n'est pas de refuser la première fois. Le trucs c'est que beaucoup de spammeurs ne peuvent se permettre de garder dans un spool les messages rejetés (et ça se comprend), donc refuser une fois suffit à baisser le nombre de spam. Les vrais mails eux ont des systèmes de mail à spool (postfix, etc) et donc retentent ultérieurement de mailer. Ca ne fait ça qu'à la première présence du triplet (from/ip/to) évidemment.
Je trouve que ça prend du sens, surtout que c'est beaucoup moins consommateur que le reste, vu qu'un select dans une table SQL suffit pour refuser (ça n'empeche pas d'utiliser amavis et tout, mais tu l'utilises en plus).
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 1.
mais ca semble interressant..
Tiens moi au courant.
[^] # Re: arguments.
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
En gros après avoir regardé quelques heures, j'en pense plutôt du bien. Et en plus comme postfix passe pleins d'infos des mails, ton serveur greylist peut stocker tout ça pour voir par exemple combien de méga de mails un mec a reçu.
[^] # Re: arguments.
Posté par iznogoud . Évalué à 2.
Parce qu'un mail venant du ministère de l'éducation n'était pas passé, était passé en "relecture" auprès des serveurs du ministère.
Problème : celui-ci n'était pas configuré correctement, et il n'a jamais renvoyé le mail en question.
Ça n'a pas plu vraiment au directeur et il s'en est mêlé, même s'il n'y connaissait rien.
Le serveur mail que nous avons administre les quelques milliers de comptes de l'ensemble des campus de Zaragoza avec succès d'ailleurs. Il tourne sous sendmail, et utilise quasi exclusivement spamassassin et clamAV. Des programmes intermédiaires permettent de réaliser des statistiques et de faire partager certaines données entre diverses universités.
Il ne fonctionne plus qu'avec des RBL, blacklists et whitelists, et actuellement ils sont en train de rechercher un moyen de remettre les greylists.
Personnellement, je dirai que oui, il faudrait dans l'absolu utiliser les RBLs, avec si possible une règle permettant de ne pas bloquer pour le courrier interne.
Pour ceux qui accusent les "faux positifs", je dirai que les faux positifs sont excessivement rares. Avec les greylists en amont, un seul report de faux positif "important" a été fait à l'Université.
Alors après, comment ils gèrent ca, techniquement, c'est une autre paire de manche, et je ne suis pas allé trop loin là dedans, c'est un fouilli imprononçable.
[^] # Re: arguments.
Posté par sk . Évalué à 1.
Je dois vraiment pas avoir de chance alors, la société scientifique pour laquelle je travaillais comme administrateur a été blacklistée sur un RBL par un sombre individu en .ru... Je doute que ce phénomène soit vraiment exceptionnel, surtout au vu de la taille de l'association (quelques milliers d'adhérents en france).
Pour ce genre de sociétés, se faire blacklister sur un RBL est une vraie catastrophe, vu que toutes les communications se font par mail (et là je ne parle même pas de ce que l'administrateur doit subir pour faire comprendre aux utilisateurs que "non, on ne peut pas envoyer de mails à telle ou telle adresse").
Le principe du blacklistage n'est pas forcément quelque chose qui me choque en soi et j'en vois tout à fait l'utilité. Seulement en pratique, les RBL ne vérifient pas nécessairement la justesse de ce qui leur est rapporté et c'est uniquement celà que je reproche au système.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 1.
Certaines RBL se contentent de quelques mails de spam envoyé d'un domaine pour justifier le blacklistage de tout le domaine (dans ce cas, byebye hotmail, caramail, wanadoo, etc)
Certaines, au contraire, se basent sur l'open-relay. Dans ce cas, les machines sont testés avant d'etre blacklistées.
Il y a aussi le pire, comme osirusoft a oser le faire: Mettre la clé sous la porte apres faillite ou après en avoir eu marre des procès de spammeurs mécontant d'être blacklisté et pour que les utilisateurs pensent a virer leur RBL de leur config, ben osirusoft a eu la bonne idée de toujours envoyer une réponse positive aux requètes.
Résultat: tous les serveurs de mails du monde étaient blacklistés!
Perso, je suis pour l'utilisation minimale des RBL, n'en prendre que qq unes spécialisées et dignes de confiance.. atuellement je n'utilise que
relays.ordb.org (open relay), dnsbl.njabl.org (open relay, listes d'ip dynamiques), et korea.services.net (specialisé dans le spam asiatique)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: arguments.
Posté par ArnY (site web personnel) . Évalué à 2.
Si t'es chez un FAI, tu utilises le smtp du FAI
mail provenant d'une adresse ip dynamque = virus, spam
pour cette rbl, si c'est une ip dynamique postfix genère un warning et non un reject.
[^] # Re: arguments.
Posté par Bernez . Évalué à 2.
Et si un particulier veut héberger son propre serveur SMTP?
Si t'es chez un FAI, tu utilises le smtp du FAI
Si t'as un PC, tu utilises microsoft windows.
[^] # Re: arguments.
Posté par Alexandre . Évalué à 0.
suffit que, loi de murphy aidant, le SMTP de ton FAI soit en rade pour que t'ai besoin d'envoyer un mail très important ...
alors vive les SMTP sur les IP dynamiques !
# Contre !
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Je bosse sur quelques projets sur sourceforge, et ils utilisent des RBL. Eh bien il y a quelque chose comme deux mois, ils ont blacklisté les serveurs smtp de wanadoo.fr (oui oui). La raison invoquée par les gens de SF était que ces serveurs avaient relayé des spams. Le résultat est que pendant un mois je n'ai pu poster sur aucune mailing list hébergée par sourceforge (comme tous les autres wanadiens d'ailleurs).
Et comme ils sont très têtus chez sourceforge, ils voulaient pas enlever leur blacklist et m'ont répondu un truc comme "contactez wanadoo, dites leur de nous contacter (sourceforge) quand ils auront mis en place des filtres anti spam". Et comme chez wanadoo ils répondent pas aux clients (en même temps tout seul c'est pas évident de demander à wanadoo d'installer des filtres anti spam sur ses serveurs de mail), ben j'étais bloqué (les gens de SF m'ont entre autres suggéré que je pouvais changer de fournisseur d'accès et que ça résoudrait mon problème. super on sent les gens très compétents).
Finalement au bout d'un mois ça s'est remis à marcher j'ai pas cherché à comprendre comment. Mais si tu vas sur la partie "demande d'aide" de sourceforge, tu trouveras toujours des gens se plaignant des RBL et venant de divers fournisseurs d'accès (ce sont les gens qui reçoivent une erreur 550).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Contre !
Posté par iznogoud . Évalué à 4.
Pourquoi ? Parce que le spam vient _très_ souvent de là. Les virus aussi d'ailleurs. Alors on va me dire qu'il ne faut pas généraliser. Certes, et vous aurez bien raison, généraliser, c'est mal.
Mais entre recevoir 50% de mails en moins sur les centaines de milliers par jour simplement en supposant rapidement que c'est du spam, c'est :
* économique : on n'a pas besoin d'aller se payer XX machines en plus pour pouvoir supporter un surcroit de travail. Hé oui ! Le spam ça représente des sous. Pour le spammeur (qui en gagnerait ?) comme le spammé (qui devrait investir dans des solutions coûteuses). Et on dira ce qu'on voudra, mais le département "mail" n'a presque aucun budget pour ça. Alors on fait avec les moyens du bord parfois. Les vieilles machines sont recyclées en serveurs. Mais on n'a pas toujours assez de vieilles machines sous la main, surtout quand on nous propose d'augmenter la charge de travail de près du double de ce que l'on a actuellement. Non.
* simple : on part du principe que peu de personnes ont un serveur mail sur ip dynamique chez soi. Et s'en serve. Sans spammer. Et l'ont bien configuré. Mine de rien, avec ça, on en arrive vite à se dire que si le mail ne passe pas, la personne en question s'en apercevra vite, et donc pourra adapter son serveur aux besoins. De plus, c'est _ton_ serveur mail qui ne passe pas. A toi de t'adapter. Un serveur mail de plus de 10000 comptes ne devrait pas à avoir à s'adapter aux exigences de quelques dizaines d'utilisateurs je trouve. C'est pas démocratique mais c'est comme ça.
[^] # d'ailleurs ...
Posté par iznogoud . Évalué à 2.
# RBLs dans Spamassassin
Posté par Antoine . Évalué à 3.
Dans spamassassin, les RBLs produisent un score comme n'importe quelle règle. Un message dont l'émetteur est listé dans une RBL produira un score plus élevé, mais s'il ne déclenche pas d'autre règle, il ne produira pas de faux positif.
[^] # Re: RBLs dans Spamassassin
Posté par ArnY (site web personnel) . Évalué à 1.
Si t'as un tuyau, sans devoir changer les fichiers internes de SA, bien sur (maintenance plus aisée)
[^] # Re: RBLs dans Spamassassin
Posté par Lucas . Évalué à 2.
[^] # Re: RBLs dans Spamassassin
Posté par ArnY (site web personnel) . Évalué à 3.
Pour info, voici comment ajouter une RBL dans SpamAssassin:
header IN_NJABL_ORG rbleval:check_rbl('njabl','dnsbl.njabl.org.')
describe IN_NJABL_ORG Received via a relay in dnsbl.njabl.org tflags IN_NJABL_ORG net
header NJABL_OPEN_RELAY rbleval:check_rbl_results_for('njabl', '127.0.0.2') describe NJABL_OPEN_RELAY DNSBL: sender is Confirmed Open Relay tflags NJABL_OPEN_RELAY net
header NJABL_DUL rbleval:check_rbl_results_for('njabl', '127.0.0.3') describe NJABL_DUL DNSBL: sender ip address in in a dialup block tflags NJABL_DUL net
header NJABL_SPAM_SRC rbleval:check_rbl_results_for('njabl', '127.0.0.4') describe NJABL_SPAM_SRC DNSBL: sender is Confirmed Spam Source tflags NJABL_SPAM_SRC net
header NJABL_MULTI_STAGE rbleval:check_rbl_results_for('njabl', '127.0.0.5') describe NJABL_MULTI_STAGE DNSBL: sent through multi-stage open relay tflags NJABL_MULTI_STAGE net
header NJABL_CGI rbleval:check_rbl_results_for('njabl', '127.0.0.8')
describe NJABL_CGI DNSBL: sender is an open formmail tflags NJABL_CGI net
header NJABL_PROXY rbleval:check_rbl_results_for('njabl', '127.0.0.9') describe NJABL_PROXY DNSBL: sender is an open proxy tflags NJABL_PROXY net
score IN_NJABL_ORG 0.38
score NJABL_DUL 0.62
score NJABL_MULTI_STAGE 0.75
score NJABL_PROXY 3.00
score NJABL_OPEN_RELAY 3.00
score NJABL_CGI 1.50
score NJABL_SPAM_SRC 3.00
source: http://dbmscan.com:3455/poss/58(...)
[^] # Re: RBLs dans Spamassassin
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Clairement c'est comme ca qu'il faut les utiliser. Sauf pour une ou deux qui sont bien maintenues, vérifiées, et que tu peux trasher direct (genre relays.ordb.org).
[^] # Re: RBLs dans Spamassassin
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 1.
quand je rajoute ces RBL dans mon
j'ai un synthax errore for NJA... et il refuse de se lancer
ca me fait ca avec toutes les règles
il me dit qu'il y a une erreure à la ligne 1551.
Est ce normal ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.