pa zar nikog nema da kaze nesto o ovome ??
Bojane posto si rekao da vec imas neku viziju ovoga jel bih mogao da je napises :) mene interesuje
kako bi sve to izgledalo

Ima ima, samo ih mrze da pisu ... ajde ajde, ne budite lenji, nije to tesko osmisliti. Sacekajmo jos malo, mozda ima neko ...

Okej,

ja ću da opišem qmail-based varijantu. Znači, to mu dođe pod 1). Čak možda ukoliko se želi extremna centralizacija može se uzeti i qmail-ldap patch. Operativni sistemi mogu biti različiti. Evo uzmimo na primer BSD ( OpenBSD3.x+softdeps ) po leaf-ovima i Linux2.4 ( Rock1.6.x-stable+RFS ) na mail hub-u.

Hardware može/mogu u najgoroj varijanti da bude/budu P1 ( >200MHz ) za leaf-ove ( kasnije objašnjeno ) i jedan pomalo jači P3 ( 1 GHz ili dual sa po 2x550MHz ) sa veoma brzim diskom za centralni server, hub. Disk storage u ovom slučaju je veoma važan faktor. On mora biti veoma brz zbog načina skladištenja poruka kod qmail-a. Bilo koja varijanta SCSI dolazi u obzir, a 10000 rpm je podrazumevano. Ukoliko postoji velika briga za nedodirljivost korisnika čak se može /var/qmail/queue umnožavati preko RAID kontrolera na X mesta ( paranoia is your best friend ).
Leaf nodes i mail hub moraju biti povezani najmanje sa 100BaseT, dummy hub je uključiv ako i samo ako je dedicated za tu grupu hostova, bez uplinkova. To znači podrazumeva po 2 mrežne kartice u svakom računaru. Ispravne route su podrazumevane.
Količina memorije, u slučaju da se koriste stari pentiumi, bi trebala da bude maximalna, koliko god ploča to može da primi. Mail hub bi trebao da ima >=256 MB memorije.

Moram priznati da mi je malo nejasan taj koncept mail hub-a sa leaf-ovima i evo zasto.

Sta se time dobija ? smanjis opterecenje ulaza mailova tako sto ga rasporedis na vise hostova ali opet sve to se srucava mail hub-u e sad mozda to ide brze koristeci onaj qmail-ov alat zaboravih mu ime za smtproute ali opet da li je to vredno muke posto realno gledano ako host ima kapaciteta da od sebe posalje sve te poruke koje su leafovi primili onda ima valjda i da primi posto je to isto smtp protokol i opet naglasavam da mislim da maildir2maildir nije tolko brzi od doticnog.

Poruke svakako moraju biti lokalno cuvane, format naravno -- ./Maildir/. Osim ako se zele izdaci za jos jedan host sa dedicated linkom prema hub-u. Ova druga varijanta ima jos par mana, pored cene, a to je upek potencijalna pretnja od prekida linka ( ljudski faktor ), ili eventualnog zaboda bilo koje od ta dva hosta ( marfijevi zakoni katastrofe ).

Jedan lokalni SCSI disk( mount point za /var/ ) na mail-hub hostu bi resio sve te problemcice.



DNS rekordi.
MX rekordi bi trebali da pointuju na mail-leaf satelite, kako vec da ih nazovemo. I to od najjaceg leaf-a pa do najslabijeg;
a.mx.profi-email.net - fastest.profi-email.net
b.mx.profi-email.net - faster.profi.email.net
c.mx.profi-email.net - fast.profi-email.net
d.mx.profi-email.net - slow-can.profi-email.net
... respektivno.

Ili mozda u bind-style tablici.
mx 5 fastest.profi-email.net
mx 5 faster.profi.email.net
mx 10 fast.profi-email.net
mx 15 slow-can.profi-email.net

I naravno, postaviti jedan smtp.profi-net ( RR ) rekord na sve gore-par-redova-nabrojane hostove, radi tasnparentnosti za end korisnike.
Broj hostova koji participiraju kao leaf-ovi je potpuno proizvoljan i sve zavisi od procesorske snage leaf-ova uzetih u obzir.

Jos nesto bitno reci, a sto ima veze sa dns-ovanjem ;) je da tcpserver koji se koristi kao wrapper za qmail-stmpd treba da se koristi sa -H parametrom sa kojim se izbegava dodatno opterecivanje sa dns look-up request-om. U nekom vrlo aktivnom radu to znaci, veoma, veoma mnogo.