Mailinglist Archive: opensuse-es (681 mails)

< Previous Next >
Re: [opensuse-es] Re: ¿maildir en gnome?
  • From: Camaleón <noelamac@xxxxxxxxx>
  • Date: Sat, 29 May 2010 08:28:09 +0000 (UTC)
  • Message-id: <pan.2010.05.29.08.28.09@xxxxxxxxx>
El Sat, 29 May 2010 01:34:45 +0200, Carlos E. R. escribió:

El 2010-05-28 a las 21:22 -0000, Camaleón escribió:

No no, hablo del estándar de verdad, el RFC. No el propio.

El detalle es que en este caso, el RFC es el propio. El wu-imap se
considera la implementación de referencia, por algo será. En este caso
no es un problema de, imap, es el protocolo de envío de anexos, mime y
toda esa pesca.

Sí, pero de 1986 (desarrollo del IMAP por el Sr. Crispin) a 1996
(último RFC 2060) han pasado unos cuantos años, unas cuantas revisiones
y unos cuantos ingenieros del IETF >:-)

Después, cada servidor de correo con soporte IMAP añade sus "trucos"
para mejorar la eficiencia de su sistema (manteniendo el estándar, por
supuesto, sólo como añadido complementario).

Repito que no es el RFC del imap. Es el de como se codifica el texto de
los mensajes. Si un final de linea se pone con CR, o con LF, con una
combinación, que cuando se quita uno de ellos, que cuando se añade...
etc. El problema es precisamente ese, que algunos clientes cuando graban
un anexo clasificado como texto hacen una traducción de los retornos de
carro que no es la especificada en el estándar.

A eso se le llama "estándar" o si prefieres, método normalizado para los
saltos de línea en mensajes mediante IMAP :-)

(...)

Y por otro lado, esa gente ha seguido encima de los RFC cuando se
añadían modificaciones. No se quedaron en la antigüedad.

Ah, eso no lo sabemos... sólo sabemos lo que ellos mismos dicen.

Y por cierto, casi nadie recomienda UW-IMAP para proyectos serios, por
algo será >:-)

Si defiendes a capa y espada algo, asegúrate de conocer antes toda la
historia:

http://www.courier-mta.org/fud/

Pero es que las ventajas del IMAP se dan cuando lo usas online, no
cuando lo usas como sustituto de un cliente IMAP local >>:-)

Tiene unas ventajas online y tiene otras ventajas en local. Yo lo quiero
en la red local.

Ventajas muy localizadas, para casos muy concretos. No es una solución de
amplio espectro.

No, hay más información en la documentación de dovecot :-)

Y donde te digo yo, que es la parte que le atañe al Postfix (la
entrega).

Que la conozco, pero no es suficiente.

El la parte que le corresponde a la entrega, sí. Tienes que saber
primero qué admite y que no admite Postfix y qué opciones de
configuración permite.

Que no, que me importa un bledo, que no afecta. El postfix entrega el
correo al agente de reparto local (procmail o su substituto), y se
terminó, ya es problema del dovecot.

No estamos hablando de un sistema con miles de usuarios virtuales. Es un
sistema con usuarios locales reales.

Lo que te digo es que el Postfix puede entregar el correo directamente al
Dovecot, directamente, sin pasar por procmail.

Si no te interesa eliminar un paso más en la entrega del correo, pues tú
sabrás, yo te lo tenía que decir para que supieras :-)

Me refiero a que es una patata tener que actualizar los índices "a
mano"
:-)

Claro, pues por eso se utiliza un substituto del procmail que lleva el
dovecot, que se llama... me vas a hacer mirarlo ahora.

(...)

Eso es lo que te estaba diciendo que podías eliminar.

The Dovecot LDA, called deliver, is a local delivery agent which takes
mail from an MTA and delivers it to a user's mailbox, while keeping
Dovecot index files up to date.

...

Main features of Dovecot LDA

* Mailbox indexing during mail delivery, providing faster mailbox
access later
* Quota enforcing by a plugin
* Sieve language support by a plugin
o Mail filtering
o Mail forwarding
o Vacation auto-reply


O sea, con 'deliver' el reparto (filtrado) es con scripts "sieve", con
lo cual tendría que rehacer mi procmail entero, no me valdría. Eso no me
gusta, es más trabajo del que me esperaba.

Ese es el que te decía... pero sin procmail :-)

Me refiero a que es esperable que de manera predeterminada autentifique
contra la base de datos de usuarios local.

No tiene manera predeterminada, todas están desactivadas (comentadas) de
manera predeterminada, incluso pam.

Ah, vaya, pues podían haber dejado al menos una opción ya lista para
usar :-?

Por cierto, ¿ya admite "sasldb2"?

Pues no lo se. ¿Esto?

http://wiki.dovecot.org/Sasl

(...)

Dovecot SASL can already be used with:

* Postfix v2.3 and later. See HowTo/PostfixAndDovecotSASL for
details. * Exim v4.64 and later. See HowTo/EximAndDovecotSASL for
details.

Sí, pero no.

La idea es poder almacenar los usuarios y sus contraseñas (inicio de
sesión pop3/imap) del propio Dovecot en esa base de datos y parece que
sólo lo han implementado del lado de la autentificación contra el MTA.

Es decir, no veo por aquí que se pueda usar sasldb:

http://wiki.dovecot.org/VirtualUsers
http://wiki.dovecot.org/UserDatabase

Quizá mediante pam enlazándolo con sasldb... no sé, no me queda claro.

Saludos,

--
Camaleón

--
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >