->
-> Finalmente, tengo que anotar aqu� que ninguno de estos dos esquemas es
-> realmente usable si lo que pretendes es atender a miles de usuarios,
-> incluso si restringes cuotas y todo eso. Tu disco duro se volver�
-> loco. Lo que yo hago en tales situaciones es suspirar profundamente,
-> rumiar maldad por las restricciones en la licencia, e instalar Cyrus.
En esto �ltimo yo *NO* estoy de acuerdo. Si tienes decenas de
miles de buzones a NADIE se le ocurre ponerlo en una misma
m�quina. Lo que se suele hacer es montar una infraestructura basada en
un servicio de directorio (ej: LDAP), y montas una granjita de
servidores que es donde est�n los buzones.
En un conocido ISP el esquema es parecido al siguiente
(simplific�ndolo much�simo, pero la esencia es esa)
FRONTEND de SMTP-POP-IMAP (via round-robin de DNS o IPVS)
SERVICIO DE DIRECTORIO EN HA
BACKEND DE CORREO
As�, cuando un usuario env�a un correo, entra por el frontend de
SMTP (que puede ser una docena de m�quinas con qmail), el qmail le
pregunta al servicio de directorio a que m�quina del backend de correo
tiene que enviarselo
A la hora de recoger el correo, el pop-imap del front-end le
pregunta al servicio de directorio de que m�quina del back-end ha de
coger los correos para el usuario tal. Y tu en el back-end puedes
tener pos n maquinitas con discos locales, o mejor a�n, n maquinitas
tirando de una SAN (Storage Area Network), para tener backup
network-less y una capacidad de crecimiento no atada a las m�quinas
Si necesitas m�s recursos, simplemente, a�ades m�s m�quinas al
front-end y al back-end, y tocas en el servicio de directorio para
asignarle tareas
Yo he visto instalaciones MUY gordas con qmail (del orden de
millones de buzones), pero tambi�n he o�do buenos resultados con
postfix. Hasta un sendmail bien configurado puede llevar esta
infraestructura (eso si, conozco pocas personas con esa
capacidad/paciencia para trabajar con el viejo dinosaurio)
En resumen: para dar servicio a MUCHOS usuarios lo que hace
falta NO es un maquin�n, sino muchas maquinas peque�itas, un buen ancho
de banda, un I/O respetable, y sobre todo, un buen administrador(es) :-)
->
-> -CR
->
-> [1] s/archivo/fichero/g si es necesario. Estoy demasiado acostumbrado a
-> llamarles as�...
->
->
->
-> --
-> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
-> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
->
