-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-05-28 a las 21:22 -0000, Camaleón escribió:
El Fri, 28 May 2010 22:53:20 +0200, Carlos E. R. escribió:
Y oye, Courier-Imap tiene "su" estándar para IMAP, Cyrus el suyo y el UW- IMAP tendrá el suyo, Exchange casi mejor ni imaginarlo... todos barren para su casa >:-)
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. Ten en cuenta que, para estos protocolos multiplataforma funcionen cuando envían "texto", tienen que hacer traducciones de los retornos de carro si piensan que el otro lado es windows y no unix, o cualquier combinación de las posibles. Hacen traducciones, y si interpretan mal la definición pues tenemos problemas. En cambio cuando se envía un binario no hay traducción. Es lo que en un cliente "FTP" se activa con el modo "ascii" o "binary". 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.
Pues por eso te digo que a la nube que le den morcillas. Bueno, que se las lleven las tormentas.
Pues por eso un servidor IMAP online puede ser un peligro >>:-)
Pues no lo pongas online. Yo no lo voy a hacer. Digo que hay quien lo hace.
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.
Más información detallada en el documento VIRTUAL_README.
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.
O sea, una patata.
No creo que sea una patata. Si hace lo que hace el procmail es perfecto. Si hace más, es una maravilla.
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. http://en.wikipedia.org/wiki/Dovecot_%28software%29 Dovecot also includes a Mail delivery agent (called Local delivery agent in Dovecot’s documentation), with optional Sieve filtering support. http://wiki.dovecot.org/MDA An MDA is a Mail Delivery Agent. An LDA is a Local Delivery Agent. These two terms are synonyms. An MDA is being passed messages from an MTA and delivers it to a real or virtual mailbox. Common choices include: * maildrop * procmail (appears to be unmaintained) * Dovecot's `deliver` LDA http://wiki.dovecot.org/LDA 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.
Lo hace de muchas maneras. Ldap, postgres, mysql, sqlite, passwd file, pam... De hecho, recomiendan no usar la contraseña del sistema, poner otra para no comprometerla. Les haré caso, pero de momento es más simple no hacerlo.
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.
Por cierto, ¿ya admite "sasldb2"?
Pues no lo se. ¿Esto? http://wiki.dovecot.org/Sasl SASL stands for "Simple Authentication and Security Layer". SASL itself is nothing more than a list of requirements for authentication mechanisms and protocols to be SASL-compatible as described in RFC 4422. IMAP, POP3 and SMTP protocols all have support for SASL. Many people confuse SASL with one specific SASL implementation: the Cyrus SASL library. Dovecot has its own SASL implementation which may at some point be separated from Dovecot itself to "compete" against Cyrus SASL library in server side. 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. Hopefully more software will follow. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkwAUxwACgkQtTMYHG2NR9WiGwCdFGjjHQ5sQFsbmKjicmSrfmPl HmoAoImHTUW0lAaz8Rrmvhhww1O1+Bqd =fhXj -----END PGP SIGNATURE-----