Yo he usado Cyrus y me ha funcionado bien, la verdad no me encanta
pero no he encontrado otra opcion mejor.
Ahora lo estoy usando con la base de datos de usuarios en LDAP (la
misma que uso en sendmail para ruteo, muy comodo) tambien lo he usado
con la base de datos en sasldb esta tambien funciona bien pero no es
una solucion escalable ya que no se puede distribuir en varias
maquinas.
>neccesito instalar un servidor de correo, pero sin dar acceso a un shell a
>los usuarios [1]. adem�s, necesito restricciones de tama�o de los buzones, de
>manera que cuando el usuario rebase su l�mite asignado el servidor rechace
>los correos siguientes[2]. por otra parte, necesito que el cambio de
>passwd sea
>lo m�s simple posible[3]. ahora no lo necesito, pero talvez luego los usuarios
>quieran definir de alguna manera buzones POP3 o IMAP en otros servidores y
>'traerlos' a su cuenta [4].
>
>r�pidamente, ayer resolv� algunos de estos problemas as�:
>[1] el shell de los usuarios es /bin/false
>[2] nunca hab�a usado quota, y no creo que lo sepa usar todav�a, pero puse
>restricciones en /var/spool/mail para cada usuario (no he probado los
>mensajes que dar�a el MTA local cuando no pueda escribir en el buz�n...)
>[3] una opci�n: cambiar el shell a /usr/bin/passwd, y as� para cambiar el
>passwd nada m�s se hace telnet a la m�quina (pero lo mencion� a algunos
>'usuarios no t�cnicos' (???) que andan por aqu� y no les son�... otra:
>instalar poppassd (no s� si se llama as� en no-debian), que permite cambiar
>el passwd de correo en eudora, mozilla...
>[4] hacer una p�gina web que permita definir configuraciones de fetchmail (o
>similar) a cada usuario, y que agregue a cron las entradas correspondientes.
>
>el asunto es este: aunque algunas soluciones funcionan, y funcionan bien, me
>gustar�a saber si a alguien se le ocurre algo mejor para resolver cualquiera
>de estos problemas, o si alguien ya ha hecho algo similar de manera
>diferente. pregunto esto porque acabo de encontrar una herramienta que hace
>casi todo esto: cyrus (http://asg.web.cmu.edu/cyrus/), pero no la he probado,
>y no s� si despu�s habr� alguna pega que haya que resolver cuando tenga m�s
>de los dos usuarios de prueba actuales... aunque no es imperativo, ser�a
>mejor que las soluciones no tuvieran costos asociados al n�mero de usuarios.
>
>cualquier idea/experiencia/sugerencia ser�a �til y agradecida.
>
>toa,
>
>beto
>
>--
>�Desea desuscribirse? Escriba a [EMAIL PROTECTED] con
>el tema "unsubscribe".
--
�Desea desuscribirse? Escriba a [EMAIL PROTECTED] con
el tema "unsubscribe".
