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 <[email protected]> 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 <[email protected]> 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/
>
>
