pass pp
list
retr 1
y luego quedarse mirando la pantalla mientras pasaba ese morzongo de datos en base64 que ni blas entendía pero que te dejaba la mar de hacker delante de los pringaillos.
Bueno, pues eso se acabó, al menos en esta entrada.
Recientemente he tenido la oportunidad de visitar el protocolo IMAP4, que como muchos sabréis es una especie de sustituto – mejora de POP3. Sin ánimo de avasallar con features diré que la mayor diferencia con el vetusto pero muy usado sistema de mensajería es que este protocolo mueve prácticamente toda la lógica de acceso al servidor; de esta forma se soportan carpetas, búsquedas y almacenamiento en el propio servidor de correo sin tener que manejar todo este follón en el lado del cliente.
Aquellos que usan IMAP4 suelen ser por un lado los usuarios de webmail (IMAP se viene a utilizar como pegamento entre el servidor web y el servidor de correo) y por otro lado los directivos que gustan de conservar toneladas de correos en su Outlook. De esta forma al conectarse al buzón sólo nos descargamos los encabezados y únicamente cuando hacemos doble click, el cliente pide al servidor los datos del cuerpo del mensaje. El colmo del despliegue viene de la posibilidad de pedir partes del mensaje (un adjunto, una cabecera MIME, el body etc…), de lo que se puede deducir que el servidor hace un parseo del contenido del mensaje, separándolo en partes y sirviéndolo bajo demanda. Si la implementación del protocolo por parte del cliente IMAP es acertada podemos abrir un mensaje con un adjunto de 50 megas que la descarga no se ralentizará: sólo se descargará el adjunto cuando pulsemos en ‘guardar como’. Por otro lado el cliente hace las funciones de una suerte de cache de datos, de forma que mantiene los mensajes mas consultados en local, descartando los menos visitados cuando el tamaño del buzón en local aumenta.
Por desgracia solo he podido dedicar un par de días a este tema, pero en ellos he podido probar 4 implementaciones de IMAP4, según he leído las más populares, en formato servidor:
- Microsoft Exchange 2003.
- Courier Imap 4.1.3-2ubuntu2.
- UWASH imapd 7:2002edebian-1-13-2.
- Cyrus 2.2.13.
Hubiera querido probar Lotus Domino que, según tengo entendido pega un par de patadas al RFC pero no ha podido ser por falta de tiempo.
Para cliente he elegido las opciones típicas:
- Outlook 2003.
- Outlook Express 6.0.
- Thunderbird 2.0.0.12.
- Evolution 2.12.1.
- Opera 9.26.
Sobre los 4 servidores destacar la sencillez de configuración básica para la mayoría.Dejando aparte Exchange el resto se instala solo con un apt-get install en la Ubuntu Server 7.10 que usé para las pruebas. Los únicos problemas vinieron de la mano de UWASH, un servidor casi centenario que se instala como demonio bajo inetd, que como sabeis hace ya tiempo que fue sustitutido por xinetd. El fichero de config que hay que añadir en /etc/xinet.d un fichero (llámalo ‘imap’ por ejemplo) tiene que contener lo siguiente para que funcione:
service imap2
{
instances = 60
log_type = SYSLOG authpriv
log_on_sucess = HOST PID
log_on_failure = HOST
cps = 25 30
disable = no
port = 143
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/sbin/imapd
}
Lo importante es el campo server, port y poco más. El resto de cosas son copia pega del man de xinet.d
Por otro lado Cyrus parece ser el más featuroso: instalando la herramienta de configuración cyradm podemos conectarnos al servidor y dar de alta buzones, modificar ACLs, poner quotas y distribuir los
buzones entre varios particiones. También admite configuraciones en cluster. Una de las dificultades iniciales que me encontré es lograr conectar la herramienta de administración con el demonio. Para ello hay que editar el fichero de configuracion /etc/imapd.conf e indicar el tipo de autenticación alwaystrue.
sasl_pwcheck_method: alwaystrue
por si acaso también es recomendable poner
admins: cyrus root
para dar acceso de administración al usuario cyrus y root. Nétese que todo esto va en contra de una instalación para un entorno en prod.
En cuanto a clientes son todos muy similares, destacando por lo alto Thunderbird con la capacidad de recuperar fragmentos de mensaje y por lo bajo Evolution por lo inestable que me ha resultado.
A nivel de protocolo IMAP4 es bastate farragoso. A continuación os detallo una mini-guía básica para poder comprobar de forma elemental lainstalación y conectividad.
Primeramente nos enganchamos la puerto de IMAP (el 143)
telnet localhost 143
Todos los comandos tienen que ir precedidos de un número de secuencia llamado tag. Si no se indica da error. El servidor nos contestará con ese mismo número de secuencia. Desconozco la razón de esto, quizá se puedan enchufar varias peticiones sin esperar respuesta (pipelinig) y de ahí que el servidor incluya en la contestación el número de secuencia de la petición. Los números de secuencia pueden ser numeros o letra o una mezcla; solo hay que tener cuidado de no repetirlos en dos comandos distintos.
Para saber las capacidades del servidor ponermos:
1 capability
y el servidor nos devolverá algo así como
* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE
Para hacer login ponemos
2 login usuario contraseña
Una vez autenticados podemos movernos por los buzones del usuario:
Para listar los buzones
3 list “” “*”
o
3 lsub “” “*”
List lista todas las carpetas indicando si tienen subcarpetas y sus flags mientras que Lsub realiza una criba y no indica flags. Devolverá algo como esto:
* LIST (\NoInferiors \UnMarked) “/” Borrador
* LIST (\NoSelect) “/” “Bandeja de entrada”
* LIST (\NoInferiors \Marked) “/” .bashrc
* LIST (\NoInferiors \UnMarked) “/” .sudo_as_admin_successful
* LIST (\NoInferiors \UnMarked) “/” UW
* LIST (\NoInferiors \UnMarked) “/” .mailboxlist
* LIST (\NoInferiors \UnMarked) “/” “Elementos enviados”
* LIST (\NoInferiors \UnMarked) “/” .bash_logout
* LIST (\NoInferiors \UnMarked) “/” Trash
* LIST (\NoInferiors \Marked) “/” .profile
* LIST (\NoInferiors \UnMarked) “/” “Correo electr&APM-nico no deseado”
* LIST (\NoInferiors) NIL INBOX
Si queremos crear un buzón lo hacemos con create
4 CREATE “prueba”
y para borrarlo usamos delete
5 DELETE “prueba”
Para seleccionar un buzón y poder operar con los mensajes hacemos select
6 select “prueba”
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 1 EXISTS
* 1 RECENT
* OK [UNSEEN 1]
* OK [UIDVALIDITY 1206417332]
* OK [UIDNEXT 13]
6 OK [READ-WRITE] Completed
Como se ve nos da cumplida cuenta del estado del buzón, los mensajes nuevos, los ya existentes etc.
Una vez seleccionado el buzón podemos listarlo, ver el contenido de un mensaje, cambiar sus flags, copiarlo a otra carpeta etc. La mayor parte de las operaciones de lectura y escritura de mensajes se hacen con los comandos fetch y append, aunque hay otros como copy, search, partial (este último permite recuperar un número arbitrario de bytes del mensaje).
Fetch tiene una sintaxis muy compleja, aquí sólo indicaré las típicas operaciones.
Por ejemplo, para recuperar los flags de todos los mensajes del buzón:
7 fetch 1:* (UID FLAGS)
devolverá algo como
* 1 FETCH (UID 1 FLAGS (\Recent \Draft))
Con este comando estamos recuperando un listado de todos los mensajes (en este caso solo 1) en los cuales se nos indican los flags y el identificador (UID) para podernos referirnos a cada mensaje con un número que lo identifica de forma unívoca. El primer parametro de Fetch es un rango (1:* es del primero hasta el ultimo, podemos poner 2:3 para recuperar el mensaje 2 y 3 o simplemente 4 si queremos recuperar el mensaje 4)
Podemos recuperar la estructura de un mensaje concreto con
8 fetch 4 (BODYSTRUCTURE)
en esta maraña podemos ver que tenemos un adjunto en el mensaje de nombre ‘prueba.tmp’