Amavis

[Peter Ronai]

On Wed, 2002-07-24 at 11:33, Ing. Pavel PaJaSoft Janousek wrote:
> 
> 	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)

ja som skusil 2000 a viac ;)
ked sa load vysplhal privisoko, sendmail prestal prijimat postu, ale
load dalej stupal az do 50, potom postupne odchadzala response na stroji
az som ho stratil (pokial som neskilloval amavis)
v oboch pripadoch zostalo kopec posty vo /var/amavis a tato nebola nikdy
dorucena. Ona tam caka, ale nic sa o nu nepostara.

> 	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.

MTA ma byt mailhub za ucelom kolektivnej ochrany pred virusmi. Dany SMTP
agent nema dorucovat lokalne nic.

> 
> 	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).

toto vsetko vieme s predosleho, problemom zostava, aok nastavit premenne
ako fork, max user connection, load pri ktorom MTA prestava prijimat
postu, atd. Predmetom otazky je ako to prinutit behat pri vyssom
zatazeni, resp riesenie vyssieho zatazenia systemovymi zmenami. Mne to
tiez chodi, pane, len to mnozstvo co tadial ma pretiect je privela na to
co ta konfiguracia dokaze (raid, P4 1,7GHz, 512MB RAM)

inak sendmail mi este masinu nezhodil, je dost inteligentny co sa loadu
tyka a uz som na nom bezal aj instalaciu s desiatkami tisic pripojeni.
Problem je v tom ze amavis takuto sebakontrolu nema. Amavis to zhadzuje.
Pripustam ze sa to da nejak zregulovat a vytunovat. Ako? - Bolo povedane
ze zmenit pocet konkurentnych pripojeni, zmenit poces procesov na
uzivatela, pouzit demonizovanu verziu pokial to ide vzhladom na
rezidentnost v pamati. Ako ale konkretne postupit dalej? Napisal som do
Amavis konfery, ale tam som len jeden z viacerych majuci ten isty
problem a odpoved ziadna. Je teda mozne ze amavis nie je vhodny na danu
ulohu. Je nieco ine k dispozicii? Co som pozeral, vsetko co je
opensource je pre tento ucel pisane v perle. Existuje riesenie v C ale
to je dost drahe. Any ideas, robil uz niekto antivir on the queue s
tisicami uzivatelov alebo prezil niekto s takymto cimsi DoS attack a
pod? V pripade nizsieho vykonu na masinu a distribuovania loadu, co
centralna administracia, zabezpecenie proti neprimeranemu loadu skrz
amavis atdatd. ? 

> 	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)...

ok
maily "ujdu" ked sa o ne stara amavis. Jednoducho ak amavis zdochne,
maily su "stratene" alebo skor zostanu v adresari /var/amavis. 

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

jednak nie som subscribnuty a jednak sa mi podla posledneho vyvoja vidi
ze sa to bude skor tykat qmailu ako hocicoho ineho :(


dz


______________________________________________________________________
This message has been checked by Dionach for all known viruses using
MessageLabs Virus Scanning Service. For further information visit
http://www.dionach.com