Eric,
>> E> On sait tr�s bien que la charge vient des spammeurs. >> >> Et ? E> Et ce sont LEUR relais qui va en arracher... En admettant que les montes de flux viennent a 100% des spammeurs (ce qui n'est pas toujours le cas), que va t'il se passer pour le mails pass� au meme moment par des relais legitimes ? Et bien la meme chose -> deferral. >> E> Mieux vaut ralentir l'entr�e (qui sera de toute fa�on suffisante) >> >> Suffisante pour quoi ? On peut donc mettre 1 dans le concurrencyincoming >> sur une plateforme gerant des millions de mails par jours ? E> Dans le sens que ils sont rares les m�ga entreprises ici... Tout depend de ce que tu entends par mega ;-) E> et que bien souvent, 4 ou 10 mails simultan� est plus que suffisant. Pour une utilisation "personnel" certainement. E> Et aussi c'est par rapport au temps! Si 100 emails essayent d'entrer en E> m�me temps, le fait de les recevoir en paquet de 10, 10 fois est E> amplement acceptable plut�t que 100 d'un coup. E> Le temps de traiter 10 fois 10 est moindre que la charge de 100 d'un E> coup � cause de la gestion dans la machine... de la m�moire qui va E> swapper un max... etc. On en revient au probleme initial : Avoir une machine correctement dimensionn�e par rapport a ces besoins. >> E> que de laisser mourir ton serveur mail. >> >> Tout a fait, mais ce n'est qu'une solution temporaire, si un serveur >> n'encaisse pas le flux entrant et ce regulierement c'est qu'il est sous >> dimensionn�e. (C'etait �a ma reponse) E> Il est souvent sousdimensionn� seulement � des temps pr�cis... lors E> d'une pointe. Mettre une limite c'est allonger le temps de pointe pour E> r�partir la charge dans le temps! Je suis entierement d'accord, ce que je signale depuis le debut, c'est que la solution de reduire la porte d'entr� n'est justement valable que temporairement. Le concurencyincomming doit etre au plus pres des besoins que necessite ton trafic mail moyen. >> La solution n'est pas de reporter le probleme sur les relais precedent en >> les utilisant comme tampon, mais d'adapter la plateforme aux flux mails a >> traiter. E> Bof, c'est n�gligeable... Je te garantie que non ne serait qu'en espace disk, et encore une fois c'est une question de principe, on ne doit pas reporter des problemes de sous dimensionnement sur les autres. E> et d'ailleurs, sur 2000 spams, on re�oit 20 mails l�gitimes alors tant E> mieux si 1980 courriels viennent ralentir les relais des spammeurs. Ce seront *tous* les mails qui seront ralenti et tous les relais qui seront gen�s, pas seulement les spams et relais a spams. >> E> Et pour ce qui est du retard, c'est n�gligeable dans la plupart du >> E> temps. >> >> C'est a l'apreciation de tes utilisateurs et du service que tu souhaite leur >> fournir, mais en aucun cas une generalit�. E> On parle de quelques secondes hein? Non E> Les mails vont retarder de quoi... 30 secondes? une minute? 2 minutes? Voir plusieurs heures, �a depend de comment est configur� le relais precedent, je connais un gros FAI qui retente une connexion plusieures heures apres que la premiere tentative a echou�e par un deferral. E> C'est rarement plus � cause du incoming concurrency... C'est que ton smtp est bien proportionn� et qu'il encaisse ce qui lui arrive dans 99% des cas ;-) E> C'est donc N�GLIGEABLE! � moins que les gens qui t'envoies des mails E> soient au t�l�phone � attendre que tu le re�oives ? Apparement tu as une utilisation personnelle de ton smtp, dit toi que si tu avais plusieur milliers de comptes a gerer pour des *clients* ta conclusion ne serait pas : C'est negligeable ;-) Sur ce bonne soir�e, -- Toorop Solutions antispam & antivirus : http://www.protecmail.com -- Liste de diffusion qmailfr - http://qmail.free.fr/
