mynetworks = /etc/postfix/reseaux
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 ArnY (site web personnel) . En réponse au journal Pour ou Contre les RBL?. É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.