Bueno, leyendo las opiniones me reafirmo en mis temores (pocos) y preguntas. Muchas gracias a todos los que habeis participado, todos aportáis (y carayo, con lo educados que somos en esta lista, no demos lugar a malos rollos por esta cosa tan tonta como es el sw). Asi que perfilaré un poco más la pregunta. Opcion 1: SLES (antes habia un OpenExchange, no?? no lo veo en novell... donde ha ido a parar :-?). Esta opción la sugeriría para: + postfix + cyrus + sasl + tls (no creo que haga falta) + spamassassin + ClamAV - me dejo algo? Las preguntas en esta opcion son: 1. Vienen todos los paquetes en la sles? 2. vienen integrados? (o tengo que andarme peleando con ficheros de configuración esotéricos) 3. la sles tiene soporte para configurar este invento? 4. Como de bueno y actualizado es el ClamAV? 5. cyrus soporta tanto mbox como maildir? 6. Cuanto cuesta el dichoso sles por año de mantenimiento? que otros costes tiene? Montseeeeeeeeeeeeeee! (seguro que me odia, desde que la que le monté la última vez). La opcion 2: SuSE Pro (ultima version suficientemente testeada) o Debian estable (para instalar qmail no hacen falta las alforjas de una sles, obviamente). + qmail + vpopmail + spamassassin + ClamAV Preguntas 1. No hay un imap para qmail? 2. qmail maneja sus propios usuarios virtuales sin necesidad de nada más (sasl y hierbas semejantes) 3. qmail soporta tanto mbox como maildir? Os cuento que la idea de este servidor de correo es la siguiente. - Mi cliente tendrá un Contact Centre, donde llegarán una serie de mails que llegan a unos buzones genericos (no hay personas fisicas detrás en una primera fase). Estos mails se distribuiran por SAP entre los operadores adecuados (según perfiles, según direcciones de envio), donde serán respondidos y enviados a través de este smtp. Por otro lado, SAP generará unos 40mil emilios más para enviar automaticamente a las cuentas de cliente. Esto significa, entre otras cosas, que no se si SAP usa el protocolo imap o pop para coger el correo, o accede a él - por ejemplo - como un sistema de archivos remoto (se me ve verde en sap, ehhhh?), tipo NFS. - En principio, esas cuentas corporativas no me imagino yo que vayan a estar en ningun LDAP o MS AD. Esto lo he contado para tener una idea del cuadro general. - No me atrae la idea, por seguridad, de cuentas reales de sistema para el correo. Desde luego sería mas simple. - a mi si se me ha roto un mbox (bueno, en realidad fue un fallo de disco :-( ). No lo pude recuperar. - el servidor imap no me lo imagino yo en la intranet, pq los usuarios de este servidor no son personas, es un sap, que distriubira el correo a los operadores (los operadores *creo* que veran el correo a traves de la gui de sap). No se si estará en la dmz, pero si habra de estar donde sap, o muy cerca. - no puedo ir a herramientas integradas con una unica interfaz de administracion (mas quisiera yo) y super caras, pq lo que propongo es justamente lo contrario, usar Open Source para cepillarnos un MS Exchange. Los presupuestos ya estan cerrados... Me resultara dificil explicar a mi jefe el sustituir una licencia por un mantenimiento si no nos ahorramos gran cosa (porque ´el exchange... funcionar funciona, ¿no?´) - la configuracion de dos maquinas en failover... me imagino que serán dos maquinas con configuracion identica, en la que una toma el relevo si falla la principal. Correcto? Qué pasa con los correos que se estaban procesando en el momento de la caida? Como se sincronizan los datos entre las dos maquinas (si es que hay que hacerlo)? - el propio qmail recomienda NO usar inetd, y usar tcpserver en su lugar (vaya, que no es una mania mia). En cualquier caso, como Jose Maria dice, estos servicios deberan estar configurados como demonios independientes. - El calculo de hw lo dejo para más adelante. Me quedo con la copla de que: * el mta usa muy pocos recursos para esta carga de trabajo * el spamassassin se come la ram -> ampliar * necesito acceso muy rapido al disco -> scsi con altas rpm * discos en raid (bueno, existe la idea de usar una array de discos (*) para este y otros servicios...) Gracias a todos por vuestros comentarios... (*) por qué demonios queda bien decir ´array´ de discos y no ´vector de discos´? -- Saludos, miguel