Amavis

[Ing. Pavel PaJaSoft Janousek]

Peter Ronai wrote:
> Skusal na tom ktosi zatazove testy (skusil som tomu dat riadne zabrat,
> ved ani klez by to nesetril) a vie poradit ako to vytunovat aby to
> chodilo aj pri vysokom loade (mailovom loade podotykam).

	Takze, aktualne pouzivam tuto konfiguraci:

POP3 server -> fetchmail (RH 6.2 updates) -> sendmail (RH 6.2 updates) 
-> amavisd (31.5.2002) -> sophie (1.40) - SAVI (sophos) -> amavisd -> 
procmail.orig (RH 6.2. updates) -> /var/spool/mail/*

	K tomu nekolik poznamek:

1. procmail.orig je puvodni /usr/bin/procmail, ktery je pouze zamerne 
prejmenovan, protoze fetchmail v okamziku, kdy mu sendmail neposloucha 
na portu 25 (pri vysokem loadu to sendmail detekuje sam) se ho snazi sam 
volat!
2. Vzhledem k tomu, ze fetchmail nenalezne ani /usr/bin/procmail, 
vyuzije (trubka!) /usr/sbin/sendmail a snazi se dorucit - nastesti tato 
akce zpusobi pouze a jen to, ze mail se doruci do fronty /var/spool/mqueue
3. Zkousel jsem postupne vsechny kombinace chybovych stavu (jeden z 
retezce nereaguje, nebezi apod. (amavisd i sophie bezi v demonovem 
modu)) a vzdy mail skoncil ve fronte s EX_TEMPFAIL chybou. V __ZADNEM__ 
pripade ani v jednom pripade neprosel dale, aniz by prosel celym 
zminenym retezcem.
4. Zkousel jsem zatez cca 200 mailu s EICARem, LOAD pri tom vysplhal az 
na hodnotu 35 (sendmail se od portu 25 odpojil a dokonce jednu chvili 
prestal byt ochoten prochazet lokalni frontu k doruceni - kterou 
normalne prochazi kazdou 1 minutu)

	V teto 'simple' konfiguraci tedy chyba nebude.

	Pokud si dobre pamatuji, pak tazatel se pokousel o tzv. mail hub gateway 
scan konfiguraci - tedy, aby sendmail postval na scaner nejen postu, 
kterou dorucuje pomoci transportnich podpurnych prostredku definovanych 
v Mlocal, ale rovnez veskerou postu, kterou je ochoten relayovat.

	V tomto pripade je mozno pouzit vzorove reseni s 2 frontami. Toto mi 
fungovalo, ale vzhledem k tomu, ze ho neprovozuji (nepovazuji za rozumne 
suplovat a zatezovat mail hub dalsi praci), pak aktualne nemohu podat 
hlaseni o testu s vysokym loadem. Osobne bych se skutecne zamyslel nad 
tim, jak se MTA (sendmail) zachova pri vysokem loadu... - muj scenar:

a) nejprve se odpoji od portu 25 => od teto chvile klient rve, ze nemuze 
dorucit nebo dorucuje __jinak__! - od teto chvile neni MTA schopen 
realyingu...
b) pri jeste vyssim loadu odmitne prochazet lokalni frontu => maily, 
ktere si tam nasadlil sam nebo mu to tam podstrcil jiny proces zustanou 
u ledu (ve fronte)!
c) obcas muze vypsat neco o tomeoutu at uz na vstupu nebo pri 
zpracovavani jednotliveho mailu (draining...) - ve vsech techto 
pripadech povazuje zpravu za nedorucenou a necha ji v lokalni fronte na 
pozdejsi doruceni (se scanem).

	Tento postup povazuji za spravny a praxi prokazany, nevim, kudy by maily 
mely utikat - popiste, v kterem okamziku a jakym zpusobem (treba 
analyzou sitove komunikace) unikaji a muzeme hledat pricinu (spise v 
konfiguraci)...

PS: Debatu doporucuji presunout do sendmail na linux.cz (a namne CC, nejsem 
si jist, zda-li ji nectu jen pres archiv...)

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------