You are on page 1of 20

Carrera: Ingeniera En Sistemas Computacionales

Materia: Administracin de Redes

Catedrtico: Ing. Landy Blanquet Escobar

Grado: Octavo Grupo: A

Integrantes: Cornejo Lara Alejandro David Domnguez Badia Grissel del Carmen Lpez Samayoa Mara del Rosario Noble Ponce Valeria Arahi

2.9 E-mail: SMTP, POP, IMAP y SASL

Coatzacoalcos, Veracruz a 20 de Marzo de 2014

2.9 E-mail: SMTP, POP, IMAP, SASL Protocolo simple de transferencia de correo (SMTP) est diseado para transferir correo confiable y eficiente. Se utiliza ampliamente en instalaciones gubernamentales y de educacin y tambin es el estndar utilizado en Internet para transferir correo. Fue definido en el RFC 2821 y es un estndar oficial de Internet. En 1982 se dise el primer sistema para intercambiar correos electrnicos en ARPANET, definido en los Request for comments RFC 821 y RFC 822. La primera de ellas define este protocolo y la + SMTP se basa en el modelo clienteservidor, donde un cliente enva un mensaje a uno o varios receptores. La comunicacin entre el cliente y el servidor consiste enteramente en lneas de texto compuestas por caracteres ASCII. El tamao mximo permitido para estas lneas es de 1000 caracteres. El funcionamiento de este protocolo se da en lnea, de manera que opera en los servicios de correo electrnico. Sin embargo, este protocolo posee algunas limitaciones en cuanto a la recepcin de mensajes en el servidor de destino (cola de mensajes recibidos). Como alternativa a esta limitacin se asocia normalmente a este protocolo con otros, como el POP o IMAP, otorgando a SMTP la tarea especfica de enviar correo, y recibirlos empleando los otros protocolos En la mayora de los casos, SMTP se utiliza junto con el servicio de protocolo de Control de transmisin (TCP), que proporciona la capa de transporte confiable (servicio). Otros mecanismos de transporte que se mencionan como compatible con la especificacin son el servicio de programa de Control de red (NCP), el servicio de transporte independiente (NITS) de red y el servicio X.25. Las respuestas del servidor constan de un cdigo numrico de tres dgitos, seguido de un texto explicativo. El nmero va dirigido a un procesado automtico de la respuesta por autmata, mientras que el texto permite que un humano interprete la respuesta. En el protocolo SMTP todas las rdenes, rplicas o datos son lneas de texto, delimitadas por el carcter <CRLF>. Todas las rplicas tienen un cdigo numrico al comienzo de la lnea. Modelo de procesamiento de correo El correo electrnico es presentado por un cliente de correo (MUA, agente de usuario de correo) a un servidor de correo (MSA, agente de sumisin de correo) usando SMTP. Una gran parte de los abastecedores de caja permiten la sumisin. Desde all, el MSA entrega el correo a su agente de transferencia postal mejor conocido como el MTA (Mail Transfer Agent, Agente de Transferencia de Correo). En algunas ocasiones, estos dos agentes son casos diferentes aunque hay que destacar que provienen del mismo software de donde fueron lanzados slo que presentan opciones diferentes dentro de la misma mquina.

El procesamiento local que se presenta puede ser realizado en una sola mquina, o en otro caso puede ser partido entre varias aplicaciones; en este segundo caso, los procesos implicados pueden compartir archivos; aqu SMTP es usado para la transferencia de mensajes internamente, con cada uno de los anfitriones configurados para usar la siguiente aplicacin como un anfitrin elegante. Para lograr la localizacin del anfitrin objetivo el MTA divisorio tiene que usar el sistema de nombre de Esfera (DNS) para lograr la bsqueda del registro interno de cambiado de correo conocido como registro MX para la esfera del recipiente (la parte de la direccin a la derecha). Es en ese instante cuando el registro de MX devuelto contiene el nombre del anfitrin objetivo. Luego el MTA se une al servidor de cambio como un cliente SMTP. Una vez que MX acepta el mensaje entrante, este a su vez se lo da a un agente de entrega de correo (MDA) para luego ser llevado a la entrega de correo local. El MDA, adems de entregar mensajes es tambin capaz de salvar mensajes en un buzn de formato, y la recepcin de correo puede ser realizada usando muchas computadoras. Hay dos formas en que un MDA puede entregar mensajes: ya sea envindolos directamente al almacenamiento, o expedirlos sobre una red usando SMTP. Una vez entregado al servidor de correo local, dicho correo es almacenado para la recuperacin de la hornada. Su recuperacin se logra por medio de las aplicaciones de usuario final, conocidas como clientes de correo electrnico, usando el Protocolo de Acceso de Mensaje de Internet (IMAP), este protocolo que facilita tanto el acceso para enviar, como el manejo de correo almacenado.

Puertos Los administradores de servidor pueden elegir si los clientes utilizan TCP puerto 25 (SMTP) o el puerto 587 (Presentacin) para retransmitir el correo saliente a una inicial del servidor de correo. Las especificaciones y muchos servidores soportan ambos. Aunque algunos servidores soportan el puerto 465 para el legado SMTP seguro en violacin de las especificaciones, es preferible utilizar los puertos estndar y comandos ESMTP estndar de acuerdo con RFC 3207, si se debe utilizar una sesin segura entre el cliente y el servidor. Los puertos 25 y 587 se utilizan para proporcionar la conectividad del cliente con el servicio de transporte en la parte delantera de la funcin de servidor de acceso de cliente (CAS). Los puertos 25, 465 y 475 son utilizados por el servicio de transporte de buzn de correo. Sin embargo, cuando la funcin de buzn se combina con la funcin de CAS en un nico servidor, el puerto 2525 se utiliza por la funcin de buzn de SMTP desde el servicio de transporte de extremo delantero del CAS, mientras que contina para utilizar el puerto 25. El puerto 465 es utilizado por el servicio de transporte de buzn de correo para recibir las conexiones de cliente proxy de la funcin CAS. Puerto 475 es utilizado por la funcin de buzn para comunicarse directamente con otras funciones de buzn, la transferencia de correo entre el servicio de envo de transporte de buzn de correo y el servicio de entrega de transporte buzn. Descripcin del protocolo SMTP es un protocolo orientado a la conexin basado en texto, en el que un remitente de correo se comunica con un receptor de correo electrnico mediante la emisin de secuencias de comandos y el suministro de los datos necesarios en un canal de flujo de datos ordenado fiable, normalmente un protocolo de control de transmisin de conexin (TCP). Una sesin SMTP consiste en comandos originados por un cliente SMTP (el agente de inicio, emisor o transmisor) y las respuestas correspondientes del SMTP del servidor (el agente de escucha, o receptor) para que la sesin se abra y se intercambian los parmetros de la sesin. Una sesin puede incluir cero o ms transacciones SMTP. Una transaccin de SMTP se compone de tres secuencias de comando / respuesta, ellos son:

MAIL: comando para establecer la direccin de retorno, tambin conocido como Return-Path, remitente o sobre. Esta es la direccin para mensajes de despedida. RCPT: comando, para establecer un destinatario de este mensaje. Este mandato puede emitirse varias veces, una para cada destinatario. Estas direcciones son tambin parte de la envolvente. DATOS: para enviar el mensaje de texto. Este es el contenido del mensaje, en lugar de su envoltura. Se compone de una cabecera de mensaje y el cuerpo del mensaje separado por una lnea en blanco. DATA es en realidad un grupo de comandos, y el servidor responde dos veces: una vez para el comando de datos adecuada, para reconocer que est listo para recibir el

texto, y la segunda vez despus de la secuencia final de los datos, para aceptar o rechazar todo el mensaje. rdenes bsicas de SMTP:

HELO, para abrir una sesin con el servidor MAIL FROM, para indicar quien enva el mensaje RCPT TO, para indicar el destinatario del mensaje DATA, para indicar el comienzo del mensaje, ste finalizar cuando haya una lnea nicamente con un punto. QUIT, para cerrar la sesin RSET Aborta la transaccin en curso y borra todos los registros. SEND Inicia una transaccin en la cual el mensaje se entrega a una terminal. SOML El mensaje se entrega a un terminal o a un buzn. SAML El mensaje se entrega a un terminal y a un buzn. VRFY Solicita al servidor la verificacin de todo un argumento. EXPN Solicita al servidor la confirmacin del argumento. HELP Permite solicitar informacin sobre un comando. NOOP Se emplea para reiniciar los temporizadores. TURN Solicita al servidor que intercambien los papeles.

De los tres dgitos del cdigo numrico, el primero indica la categora de la respuesta, estando definidas las siguientes categoras:

2XX, la operacin solicitada mediante el comando anterior ha sido concluida con xito 3XX, la orden ha sido aceptada, pero el servidor esta pendiente de que el cliente le enve nuevos datos para terminar la operacin 4XX, para una respuesta de error, pero se espera a que se repita la instruccin 5XX, para indicar una condicin de error permanente, por lo que no debe repetirse la orden

En el siguiente ejemplo se muestra una conexin tpica. Se nombra con la letra C al cliente y con S al servidor.
S: 220 Servidor ESMTP C: HELO miequipo.midominio.com S: 250 Hello, please to meet you C: MAIL FROM: <yo@midominio.com> S: 250 Ok C: RCPT TO: <destinatario@sudominio.com> S: 250 Ok

C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Subject: Campo de asunto C: From: yo@midominio.com C: To: destinatario@sudominio.com C: C: Hola, C: Esto es una prueba. C: Hasta luego. C: C: . S: 250 Ok: queued as 12345 C: quit S: 221 Bye

Formato del mensaje Como se muestra en el ejemplo anterior, el mensaje es enviado por el cliente despus de que ste manda la orden DATA al servidor. El mensaje est compuesto por dos partes: Cabecera: en el ejemplo las tres primeras lneas del mensaje son la cabecera. En ellas se usan unas palabras clave para definir los campos del mensaje. Estos campos ayudan a los clientes de correo a organizarlos y mostrarlos. Los ms tpicos son subject (asunto), from (emisor) y to (receptor). stos dos ltimos campos no hay que confundirlos con las rdenes MAIL FROM y RCPT TO, que pertenecen al protocolo, pero no al formato del mensaje. Cuerpo del mensaje: es el mensaje propiamente dicho. En el SMTP bsico est compuesto nicamente por texto, y finalizado con una lnea en la que el nico carcter es un punto. Internacionalizacin Muchos usuarios cuyo lenguaje base no es el latn han tenido dificultades con el requisito de correo electrnico en Amrica. RFC 6531 fue creado para resolver ese problema, proporcionando caractersticas de internacionalizacin de SMTP, la extensin SMTPUTF8. RFC 6531 proporciona soporte para caracteres de varios bytes y no para ASCII en las direcciones de correo electrnico. El soporte del internacionalizacin actualmente es limitada pero hay un gran inters en la ampliacin de el RFC 6531. RFC en pases como en china, que tiene una gran base de usuarios en Amrica.

Seguridad y SPAM Una de las limitaciones del SMTP original es que no facilita mtodos de autenticacin a los emisores, as que se defini la extensin SMTP-AUTH en RFC 2554. A pesar de esto, el spam es an el mayor problema. No se cree que las extensiones sean una forma prctica para prevenirlo. Internet Mail 2000 es una de las propuestas para reemplazarlo. Diferentes metodologas han aparecido para combatir el spam. Entre ellas destacan DKIM, Sender Policy Framework (SPF) y desde el 2012 Domain-based Message Authentication, Reporting and Conformance (DMARC). POP Post Office Protocol (POP3, Protocolo de Oficina de Correo o "Protocolo de Oficina Postal") se utiliza en clientes locales de correo para obtener los mensajes de correo electrnico almacenados en un servidor remoto. Es un protocolo de nivel de aplicacin en el Modelo OSI. Las versiones del protocolo POP, informalmente conocido como POP1 y POP2, se han quedado obsoletas debido a las ltimas versiones de POP3. En general cuando se hace referencia al trmino POP, se refiere a POP3 dentro del contexto de protocolos de correo electrnico.

Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto radicalmente diferentes.

Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente (validados por la cadena CR/LF) est compuesto por una palabra clave, posiblemente acompaada por uno o varios argumentos, y est seguido por una respuesta del servidor POP compuesta por un nmero y un mensaje descriptivo.

Caractersticas POP3 est diseado para recibir correo, no para enviarlo; le permite a los usuarios con conexiones intermitentes o muy lentas (tales como las conexiones por mdem), descargar su correo electrnico mientras tienen conexin y revisarlo posteriormente incluso estando desconectados. Cabe mencionar que la mayora

de los clientes de correo incluyen la opcin de dejar los mensajes en el servidor, de manera tal que, un cliente que utilice POP3 se conecta, obtiene todos los mensajes, los almacena en la computadora del usuario como mensajes nuevos, los elimina del servidor y finalmente se desconecta. En contraste, el protocolo IMAP permite los modos de operacin conectado y desconectado. Los clientes de correo electrnico que utilizan IMAP dejan por lo general los mensajes en el servidor hasta que el usuario los elimina directamente. Esto y otros factores hacen que la operacin de IMAP permita a mltiples clientes acceder al mismo buzn de correo. La mayora de los clientes de correo electrnico soportan POP3 IMAP; sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor agregado de sus servicios. Los clientes que utilizan la opcin dejar mensajes en el servidor por lo general utilizan la orden UIDL ('Unique IDentification Listing). La mayora de las rdenes de POP3 identifican los mensajes dependiendo de su nmero ordinal del servidor de correo. Esto genera problemas al momento que un cliente pretende dejar los mensajes en el servidor, ya que los mensajes con nmero cambian de una conexin al servidor a otra. Por ejemplo un buzn de correo contena 5 mensajes en la ltima conexin, despus otro cliente elimina el mensaje nmero 3, si se vuelve a iniciar otra conexin, ya el nmero que tiene el mensaje 4 pasar a ser 3, y el mensaje 5 pasar a ser nmero 4 y la direccin de estos dos mensajes cambiara. El UIDL proporciona un mecanismo que evita los problemas de numeracin. El servidor le asigna una cadena de caracteres nica y permanente al mensaje. Cuando un cliente de correo compatible con POP3 se conecta al servidor utiliza la orden UIDL para obtener el mapeo del identificador de mensaje. De esta manera el cliente puede utilizar ese mapeo para determinar qu mensajes hay que descargar y cules hay que guardar al momento de la descarga. Al igual que otros viejos protocolos de internet, POP3 utilizaba un mecanismo de firmado sin cifrado. La transmisin de contraseas de POP3 en texto plano an se da. En la actualidad POP3 cuenta con diversos mtodos de autenticacin que ofrecen una diversa gama de niveles de proteccin contra los accesos ilegales al buzn de correo de los usuarios. Uno de estos es APOP, el cual utiliza funciones MD5 para evitar los ataques de contraseas. Mozilla, Eudora, Novell Evolution as como Mozilla Thunderbird implementan funciones APOP. Ordenes. Para establecer una conexin a un servidor POP, el cliente de correo abre una conexin TCP en el puerto 110 del servidor. Cuando la conexin se ha establecido, el servidor POP enva al cliente POP y despus las dos mquinas se envan entre s otras rdenes y respuestas que se especifican en el protocolo. Como parte de esta comunicacin, al cliente POP se le pide que se autentifique (Estado de autenticacin), donde el nombre de usuario y la contrasea del usuario se envan al servidor POP. Si la autenticacin es correcta, el cliente POP pasa al Estado de transaccin, en este estado se pueden utilizar rdenes LIST, RETR y

DELE para mostrar, descargar y eliminar mensajes del servidor, respectivamente. Los mensajes definidos para su eliminacin no se quitan realmente del servidor hasta que el cliente POP enva la orden QUIT para terminar la sesin. En ese momento, el servidor POP pasa al Estado de actualizacin, fase en la que se eliminan los mensajes marcados y se limpian todos los recursos restantes de la sesin. Es posible conectarse manualmente al servidor POP3 haciendo Telnet al puerto 110. Es muy til cuando envan un mensaje con un fichero muy largo que no se quiere recibir. A continuacin se brinda un resumen de los principales comandos POP2: Comandos POP2 Comando HELLO FOLDER READ Descripcin Identificacin que utiliza la direccin IP del equipo remitente Nombre de la bandeja de entrada que se va a consultar Nmero del mensaje que se va a leer

RETRIEVE Nmero del mensaje que se va a recoger SAVE DELETE QUIT Nmero del mensaje que se va a guardar Nmero del mensaje que se va a eliminar Salida del servidor POP2

A continuacin se brinda un resumen de los principales comandos POP3: Comandos POP3 Comando USER identification Descripcin Este comando permite la autenticacin. Debe estar seguido del nombre de usuario, es decir, una cadena de caracteres que identifique al usuario en el servidor. El comando USER debe preceder al comando PASS. El comando PASS permite especificar la contrasea del usuario cuyo nombre ha sido especificado por un comando USER previo. Informacin acerca de los mensajes del servidor Nmero del mensaje que se va a recoger

PASS password STAT RETR

DELE LIST [msg] NOOP

Nmero del mensaje que se va a eliminar Nmero del mensaje que se va a mostrar Permite mantener la conexin abierta en caso de inactividad Comando que muestra n lneas del mensaje, cuyo nmero se da en el argumento. En el caso de una respuesta positiva del servidor, ste enviar de vuelta los encabezados del mensaje, despus una lnea en blanco y finalmente las primeras n lneas del mensaje. Solicitud al servidor para que enve una lnea que contenga informacin sobre el mensaje que eventualmente se dar en el argumento. Esta lnea contiene una cadena de caracteres denominada unique identifier listing (lista de identificadores nicos) que permite identificar de manera nica el mensaje en el servidor, independientemente de la sesin. El argumento opcional es un nmero relacionado con un mensaje existente en el servidor POP, es decir, un mensaje que no se ha borrado. El comando QUIT solicita la salida del servidor POP3. Lleva a la eliminacin de todos los mensajes marcados como eliminados y enva el estado de esta accin.

TOP <messageID> <n>

UIDL [msg]

QUIT

Por lo tanto, el protocolo POP3 administra la autenticacin utilizando el nombre de usuario y la contrasea. Sin embargo, esto no es seguro, ya que las contraseas, al igual que los correos electrnicos, circulan por la red como texto sin codificar (de manera no cifrada). En realidad, segn RFC 1939, es posible cifrar la contrasea utilizando un algoritmo MD5 y beneficiarse de una autenticacin segura. Sin embargo, debido a que este comando es opcional, pocos servidores lo implementan. Adems, el protocolo POP3 bloquea las bandejas de entrada durante el acceso, lo que significa que es imposible que dos usuarios accedan de manera simultnea a la misma bandeja de entrada. De la misma manera que es posible enviar un correo electrnico utilizando telnet, tambin es posible acceder al correo entrante utilizando un simple telnet por el puerto del servidor POP (110 de manera predeterminada):
telnet mail.commentcamarche.net 110

(El servidor indicado anteriormente no existe. Intente reemplazar commentcamarche.net por el nombre de dominio de su proveedor de servicios de Internet.)

S: +OK mail.commentcamarche.net POP3 service S: (Netscape Messaging Server 4.15 Patch 6 (built Mar 31 2001)) C: USER jeff S: +OK Name is a valid mailbox C: PASS password S: +OK Maildrop ready C: STAT S: +OK 2 0 C: TOP 1 5 S: Subject: Hola S: Hola Meandus: S: Cmo andan tus cosas? S: S: Nos vemos pronto! C: QUIT S: +OK

Ventajas La ventaja con otros protocolos es que entre servidor-cliente no se tienen que enviar tantas rdenes para la comunicacin entre ellos. El protocolo POP tambin funciona adecuadamente si no se utiliza una conexin constante a Internet o a la red que contiene el servidor de correo. IMAP El protocolo IMAP (Internet Message Access Protocol, Protocolo de acceso a mensajes de Internet) es un protocolo alternativo al de POP3, pero que ofrece ms posibilidades:

IMAP permite administrar diversos accesos de manera simultnea IMAP permite administrar diversas bandejas de entrada IMAP brinda ms criterios que pueden utilizarse para ordenar los correos electrnicos.

La ltima versin est definida en RFC3501 este protocolo se utiliza para lo mismo que el protocolo POP pero es mucho ms potente y por consecuente requiere de ms recursos. La caracterstica fundamental de este protocolo es que permite una organizacin por carpetas del correo electrnico y que al contrario que el protocolo POP, est diseado para que el correo electrnico este almacenado en el servidor. La principal ventaja de este protocolo es que siempre tenemos acceso a nuestro correo, incluso si lo leemos desde diferentes clientes y adems recuerda que correos hemos ledo y cules no. IMAP y POP3 (Post Office Protocol versin 3) son los dos protocolos que prevalecen en la obtencin de correo electrnico. Todos los servidores y clientes de correo electrnico estn virtualmente soportados por ambos, aunque en algunos casos hay algunas interfaces especficas del fabricante tpicamente propietarias. Por ejemplo, los protocolos propietarios utilizados entre el cliente Microsoft Outlook y su servidor Microsoft Exchange Server o el cliente Lotus Notes de IBM y el servidor Domino. Sin embargo, estos productos tambin soportan interoperabilidad con IMAP y POP3 con otros clientes y servidores. La versin

actual de IMAP, IMAP versin 4 revisin 1 (IMAP4rev1), est definida por el RFC 3501. IMAP fue diseado como una moderna alternativa a POP por Mark Crispin en el ao 1986. Fundamentalmente, los dos protocolos les permiten a los clientes de correo acceder a los mensajes almacenados en un servidor de correo. Ya sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar mensajes. Los clientes de correo electrnico son comnmente denominados clientes POP o IMAP, pero en ambos casos se utiliza SMTP. Proceso o funcionamiento Mail User Agent (MUA): con estas siglas nos referimos al cliente de correo electrnico (Outlook, Thunderbird, etc.) desde el cual se enva un correo electrnico o en el que se recibe un correo electrnico. En general los MUA usaran lo que se suele denominar servidor de correo saliente para enviar los correos y el servidor de correo entrante para leerlos. En el primer caso, el cliente de correo electrnico contactara con el servidor del correo saliente designado y usando el protocolo SMTP, entregar a este servidor el correo que se desea enviar. En el segundo caso, el cliente de correo usar el servidor de correo entrante designado para descargar los correos electrnicos almacenados en el servidor; en este caso, el protocolo que se usa es otro distinto: o bien se usa POP o bien se usa IMAP. Mail Transfer Agent (MTA): con estas siglas nos referimos al servidor de correo electrnico. El envi de un correo electrnico se hace en dos fases, en la primera fase, el MUA entrega el correo electrnico al servidor de correo electrnico que el proveedor de acceso a internet haya asignado. Una vez que el MUA ha entregado el correo electrnico al servidor de correo saliente, el MUA puede desconectarse de internet ya que el resto del trabajo lo hara el servidor de correo (con esto se evita tener que mantener arrancado el cliente de correo electrnico todo el tiempo). Este primer MTA, analizar la direccin de correo del destinatario y buscar (mediante DNS) el servidor o servidores de correo electrnico designados para ese dominio. Una vez localizados, se producir una conexin MTA.MTA. mediante esta segunda conexin, se estar entregando el correo al servidor que, alberga el buzn de correo del destinatario. Mail Delivery Agent (MDA): este agente no siempre aparece o bien est incluido en el propio servidor de correo del destinatario. Tcnicamente hablando el MDA es el agente que se encarta de, una vez recibido el correo en el MTA final, copiar ese correo electrnico en el buzn de usuario.

Ventajas y desventajas Actualmente, la mayora de los clientes de correo utilizan LDAP para sus servicios de directorio. IMAP es utilizado frecuentemente en redes grandes; por ejemplo, los sistemas de correo de un campus. Con IMAP, los usuarios pueden acceder a sus nuevos mensajes de correo de forma instantnea, ya que el correo se almacena en la red. Para leer los mensajes entrantes con POP3, los usuarios tendran que descargar primero el correo electrnico en sus equipos o acceder a l va web. Ambos mtodos requieren ms tiempo del que invierte IMAP en hacer lo mismo. En la siguiente tabla se recogen las principales ventajas de IMAP con respecto a POP3:

Protocolo Ventajas

Desventajas

IMAP4

Trabaja online. Gran nmero de transacciones. No es necesario descargar los correos. Gestiona carpetas locales y archivos desde el servidor. Permite la bsqueda de mensajes por medio de palabras claves.

Las carpetas que se hayan creado con IMAP no podrn ser ledas usando POP (la nica excepcin es la carpeta de la Bandeja de entrada). Con IMAP tienes que estar conectado a Internet todo el tiempo para poder leer tu correo y contestar los mensajes. Si pierdes la conexin a Internet no podrs acceder a tu correo recibido. Algunos clientes de correo tienen problemas de sincronizacin a la hora de acceder al servidor por IMAP (por ejemplo, Outlook 2002 presenta algunos mensajes de errores de conexin, aunque sin consecuencias).

POP3

Trabaja lnea.

fuera

de

Puede presentar problemas de configuracin. Tienes que darte de alta en reenvo dentro del portal. No todos los portales te ofrecen el servicio POP. Tiende a eliminar los mensajes del portal haciendo imposible la recuperacin de los mismos. Si el usuario se descuida cualquiera puede acceder al cliente. Enviar un mensaje desde el cliente puede tardar el doble del tiempo. Dependiendo del mensaje, puede consumir recursos del sistema.

Otras caractersticas importantes que diferencian a IMAP y POP3 son: Soporte para operacin en lnea y fuera de lnea Al utilizar POP3, los clientes se conectan brevemente al servidor de correo, solamente el tiempo que les tome descargar los nuevos mensajes. Al utilizar IMAP, los clientes permanecen conectados el tiempo que su interfaz permanezca activa y descargan los mensajes bajo demanda. Esta manera de trabajar de IMAP puede dar tiempos de respuesta ms rpidos para usuarios que tienen una gran cantidad de mensajes o mensajes grandes. Soporte para la conexin de mltiples clientes simultneos a un mismo destinatario El protocolo POP3 supone que el cliente conectado es el nico dueo de una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos simultneos a mltiples clientes y proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a un buzn de correo por otro cliente concurrentemente conectado. Soporte para acceso a partes MIME de los mensajes y obtencin parcial Casi todo el correo electrnico de Internet es transmitido en formato MIME. El protocolo IMAP4 les permite a los clientes obtener separadamente cualquier parte MIME individual, as como obtener porciones de las partes individuales o los mensajes completos. Es ms seguro. Soporte para que la informacin de estado del mensaje se mantenga en el servidor A travs de la utilizacin de seales definidas en el protocolo IMAP4 de los clientes, se puede vigilar el estado del mensaje, por ejemplo, si el mensaje ha sido o no ledo, respondido o eliminado. Estas seales se almacenan en el servidor, de manera que varios clientes conectados al mismo correo en diferente tiempo pueden detectar los cambios hechos por otros clientes. Cabe recordar que la navegacin de POP3 es un poco ms lenta. Soporte para accesos mltiples a los buzones de correo en el servidor Los clientes de IMAP4 pueden crear, renombrar o eliminar correo (por lo general presentado como carpetas al usuario) del servidor, y mover mensajes entre cuentas de correo. El soporte para mltiples buzones de correo tambin le permite al servidor proporcionar acceso a los directorios pblicos y compartidos. Soporte para bsquedas de parte del servidor IMAP4 proporciona un mecanismo para que los clientes pidan al servidor que busque mensajes de acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes descarguen todos los mensajes de su buzn de correo, agilizando de esta manera las bsquedas.

Soporte para un mecanismo de extensin definido Como reflejo de la experiencia en versiones anteriores de los protocolos de Internet, IMAP define un mecanismo explcito mediante el cual puede ser extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso comn. Un ejemplo de extensin es el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha llegado un nuevo mensaje de correo y stos se sincronicen. Sin esta extensin, para realizar la misma tarea, el cliente debera contactar peridicamente al servidor para ver si hay mensajes nuevos. Versiones de IMAP IMAP da acceso al correo electrnico de manera que los clientes pueden guardarse copias locales de los mensajes (consideradas como una cach temporal). Adems, presenta mltiples versiones, entre las cuales se encuentran: IMAP2, IMAP3, IMAP2bis e IMAP4. IMAP2 La versin IMAP2 fue la primera versin de IMAP distribuida pblicamente y fue definida en el RFC 1064 en 1988. Ms tarde, fue actualizado por el RFC 1176, la misma busc hacerle frente a la administracin de correo electrnico centralizado que careca de POP2. En ella se introdujeron comandos y respuestas de etiquetado. IMAP3 IMAP3 es una versin rara del IMAP, fue especficamente una contrapuesta del RFC 1176, la cual fue definida por el RFC 1203 en los aos 1991 pero la misma no fue aceptada por el mercado. IMAP2bis El protocolo de oficina de correo deja gran parte de la gestin a un usuario que permanece sujeto a una sola mquina o computadora, si el equipo llega a fallar, se pierden todos sus datos y no se pueden recuperar los correo electrnicos, debido a esto y con la llegada del MIME se toma la decisin de ampliar IMAP2 para apoyar el MIME y agregar funciones para las administracin de buzones. Entonces IMAP2bis considerado una revisin experimental aade estas funcionalidades de crear, eliminar y guardar como borradores los mensajes en los respectivos buzones. IMAP4 El IMAP decidi realizar un cambio en el nombre de IMAP2bis para evitar confusiones con la propuesta dada en los aos 1991 (IMAP3), la cual fue hecha por un grupo de la competencia que no obtuvo logros con dicha propuesta, el nuevo nombre dado de IMAP2bis sera entonces IMAP4. IMAP4 permite a los clientes de correo electrnico manipular los mensajes de correo electrnico almacenados en el servidor, como tambin la manipulacin de las carpetas locales. Sin embargo fue revisada puesto que encontraron o descubrieron fallas en

la seguridad. Para el ao del 2003 surge IMAP4rev1 que incluy las funciones de escuchar los mensajes antes de descargar el cuerpo entero del correo electrnico.

SASL La Capa de autenticacin y seguridad (SASL) Es un entorno de trabajo para la autentificacin y seguridad de datos en protocolos de internet. Para utilizar esta especificacin, un protocolo incluye un comando para identificar y autenticar a un usuario a un servidor y para opcionalmente negociar una capa de seguridad para el protocolo posterior interacciones. El comando tiene un argumento necesario identificar un SASL mecanismo. SASL proporciona medios para un uso negociado del mecanismo elegido. Las especificaciones originales de SASL fueron editadas por John Meyers en el RFC 2222. Este fue hecho obsoleto por el RFC 4422, editado por Alexey Melnikov y Kurt Zeilenga. SASL separa los mecanismos de autentificacin de los protocolos de aplicacin, en teora permitiendo cualquier mecanismo de autentificacin soportado por SASL para ser usado en cualquier protocolo de aplicacin que utilice SASL. Los mecanismos de autentificacin pueden tambin soportar proxy de autorizacin, una facilidad que permite a un usuario asumir la identidad de otro. Los mecanismos de autentificacin tambin pueden proveer una capa de seguridad de datos ofreciendo integridad de datos y servicios de confidencialidad de datos. DIGEST-MD5 es un ejemplo de mecanismos que pueden proveer una capa de seguridad de datos. Los protocolos de aplicacin que soportan SASL, generalmente tambin pueden soportar TLS (Transport Layer Security) para complementar los servicios ofrecidos por SASL. Algunos protocolos que soportan SASL son: BEEP, IMAP, LDAP, POP, SMTP, IMSP, ACAP y XMPP. SASL es utilizado por los servidores de la red (por ejemplo, IMAP, SMTP) para solicitar la autenticacin de los clientes, y en los clientes de autenticacin en los servidores. Mecanismos: Mecanismo Uso KERBEROS_V4 OBSOLETO GSSAPI COMN SKEY OBSOLETO EXTERNO COMN CRAM-MD5 LIMITED ANNIMO COMN

Mecanismo OTP GSS-SPNEGO LLANO SECURID NTLM NMAS_LOGIN NMAS_AUTHEN DIGEST-MD5 9798-U-RSA-SHA1-ENC 9798-M-RSA-SHA1-ENC 9798-U-DSA-SHA1 9798-M-DSA-SHA1 9798-U-ECDSA-SHA1 9798-M-ECDSA-SHA1 KERBEROS_V5 NMAS-SAMBA-AUTH SCRAM-* SCRAM-SHA-1 SCRAM-SHA-1-PLUS GS2-* GS2-KRB5 GS2-KRB5-PLUS SPNEGO SPNEGO-PLUS SAML20 OPENID20 EAP-AES128 EAP-AES128-PLUS

Uso COMN LIMITED COMN COMN LIMITED LIMITED LIMITED OBSOLETO COMN COMN COMN COMN COMN COMN COMN LIMITED COMN COMN COMN COMN COMN COMN NO DEBE utilizarse NO DEBE utilizarse COMN COMN COMN COMN

Conexin con SASL SASL es un mtodo que permite la identificacin a los servicios (NickServ) como el primer paso en la conexin a la red, antes de que ocurra cualquier otra cosa. Para usar SASL, hay que registrarse en los servicios. Para conectarse a freenode usando Tor , se requiere SASL. Algunos usuarios pueden ver este mensaje al intentar conectar:*** Aviso - Es necesario identificar a travs de SASL para utilizar este servidor cuando hay problemas repetidos con abuso o comportamiento antisocial de un rango de IP y los usuarios en esa IP rango parecen tener la capacidad de cambiar rpidamente

entre muchas IPs diferentes, freenode se queda con las decisiones incmodas de bloquear completamente el acceso a toda la gama, sin hacer nada, o de vuelta a SASL. Si no se hace nada, muchos canales grandes pueden terminar bloqueando los ISP y pases enteros, tal vez por un tiempo prolongado. SASL permite freenode para evitar un bloque completo al mismo tiempo mitigar los posibles abusos. Un nmero de clientes ya han incorporado soporte para SASL: Adium (versiones 1,6) AndChat (versiones 1.3.4) Android IRC AndroIRC (versiones 2,0) BitchX (versiones 1,2) EPIC5 (versiones 1.1.7) HexChat IceChat (versiones 9) Konversation (versiones 1,5) KVIrc (versiones 4) Pidgin ( versiones 2.10.7) Quassel (versiones 0.6.1) Textual (versiones 2,1) Weechat ZNC (versiones 1,0)

Ejemplo: Supongamos que tenemos un SMTP (Postfix) que soporta SASL a travs de la librera Cyrus-SASL. A su vez esta librera tiene los plugins para soportar los mecanismos de autenticacin PLAIN y DIGEST-MD5. Veamos el comienzo de la comunicacin SMTP:
S: C: S: S: S: S: S: S: S: S: S: S: 220 mail.ejemplo.com.ar ESMTP Postfix ehlo woitasen.com.ar 250-mail.ejemplo.com.ar 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN DIGEST-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN

La C indica los mensajes enviados por el cliente y la S los enviados por el servidor. Este es el clsico comando HELO del protocolo SMTP. Se usa para que el cliente se anuncie al servidor, el cual contesta con una serie de parmetros informativos. El ms importante ahora es el 250-AUTH, el cual indica que el servidor soporta

autenticacin a travs de los mecanismos PLAIN y DIGEST-MD5. En realidad, el servidor soporta SASL y es esta quien soporta esos mecanismos de autenticacin. Ahora bien, para que todo funcione el cliente tambin debe soportar SASL. Supongamos que el cliente usa Cyrus-SASL. Si la librera tiene solo el plugin para autenticar con DIGEST-MD5, entonces se produce la siguiente secuencia de mensajes:
C: AUTH DIGEST-MD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful.

El cliente le est indicando al servidor que quiere autenticar con DIGEST-MD5, el servidor le contesta 334 enviando un challenge al cual el cliente respond e. El intercambio finaliza con la confirmacin de que la autenticacin finalizo correctamente. Ahora veamos cmo encaja SASL. EL challenge, es esa secuencia de caracteres enviados por el servidor luego del 334. Esta secuencia es generada por la librera SASL. Al servidor SMTP no le importa el contenido de este mensaje. El cliente recibe el challenge y lo procesa con su librera SASL, la cual devuelve otra secuencia de caracteres que el cliente enva al servidor. La funcin de SASL es generar estos mensajes y de avisarle al servidor si la autenticacin finalizo correctamente o no. Entonces, para ir cerrando, SASL se encarga del manejo de los mensajes de autenticacin, siendo algo abstracto para los protocolos orientados a servicios. Si aparece un nuevo mecanismo de autenticacin y la librera de SASL lo soporta, automticamente el servicio tambin tendr soporte sin tocar una lnea cdigo

You might also like