Ouep même config que toi Maxime en moins couillus certe sur le nombre de mail 
traite mais par contre plus d'une quarantaine de serveurs sur cette conf sans 
aucun soucis !
Juste Clamav qui se bloque de temps en temps un petit stop/start et ça repart, 
sur deux serveurs j'ai eu des soucis de maj de clamav !

        Patrice Trognon
http://www.boxadmin.com
         09.50.15.77.80
         06.21.09.36.94

Le 23 juil. 2010 à 15:59, Maxime Teissèdre <maxime.teisse...@gmail.com> a écrit 
:

> Bonjour,
> 
> Je gère plusieurs relais de messagerie sous Postfix/Amavis/ClamAV/SA.
> Les deux plus gros ont un trafic journalier de 5,2 millions de connexions SMTP
> 
> Le serveur ne peut pas traiter tous ces messages!!!
> 
> Il en rejette à la connexion 5,1 millions, pour à peine 20 000 messages 
> scannés par jours.
> 
> Pour certains domaines, la liste des BAL est nécessaire, sinon le serveur ne 
> tient pas.
> J'utilise les restrictions intégrés à Postfix, la liste des BAL de certains 
> domaines, les Greylists puis Amavis combiné à ClamAV et SA (en fonction des 
> domaines à filtrés ou non).
> 
> Ça fonctionne pas mal, mais si les Greylists sont trop utilisées, le serveur 
> peut être DOWN chaque nuit pendant le traitement de la BDD de postgrey.... 
> (je suis monté à 3millions d'entrées dans la BDD et avec la liste des BAL 
> d'un seul domaine, je suis retombé à 300 000).
> 
> Bon weekend,
> 
> Maxime Teissèdre.
> 
> Le 23 juillet 2010 14:35, Sébastien Namèche <sebastien.name...@netensia.fr> a 
> écrit :
> 
> Le 23 juil. 2010 à 13:16, Lilian RIGARD - Devclic a écrit :
> > Plus le filtrage est fait en amont moins on a besoin de filtrer derrière : 
> > à mon sens Dspam et Spamassassin ne doivent analyser que les mails des 
> > utilisateurs utilisant des comptes Yahoo, Gmail etc ... pour spammer.
> >
> > C'est encore une fois une question d'architecture et de réflexion sur le 
> > système en place.
> 
> 
> Oui, il n'est pas envisageable de pouvoir absorber une charge importante si 
> chaque message doit passer par des analyses de contenu (filtres bayésiens, 
> OCR sur les images, etc.).
> 
> Pour les grosses volumétries, deux aspects essentiels :
> 
>  1) Il faut détecter les courriers indésirables pendant la session SMTP pour 
> refuser de les prendre en charge à ce moment là. C'est ce que j'appelle le 
> problème de la patate chaude. Cf. 
> http://clx.anet.fr/spip/article.php3?id_article=238 (c'est un peu ancien mais 
> toujours d'actualité). J'aime bien embarrasser les files d'attente des 
> hébergeurs peu scrupuleux ou peu consciencieux. Un produit tel que MIMEDefang 
> (déjà cité dans ce fil) est l'idéal.
> 
>  2) Il faut épuiser tous les tests possibles (DNSBL, listes grises, SPF, 
> DKIM, conformance, etc.) avant de se résoudre à regarder le contenu d'un 
> message. En fait, la plus grosse partie des messages indésirables doivent 
> être repérés avant la phase DATA de la sessions SMTP. Ainsi, par exemple, les 
> anti-virus de nos relais de messagerie détectent très peu de virus car ils 
> sont interceptés avant d'arriver à l'anti-virus.
> 
> En se basant sur ces principes, nous avons des cas où nous arrivons à traiter 
> 1 million de sessions SMTP entrantes par jour sur un simple Dell d'entrée de 
> gamme d'il y a 3 ans.
> 
> Bon WE à tous,
> 
> --
> Sébastien Namèche
> Société Netensia
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 

Répondre à