REPUBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA DEFENSA UNIVERSIDAD NACIONAL EXPERIMENTAL DE LA FUERZA ARMANDA UNEFA NUCLEO ZULIA SEDE EL MILAGRO MARACAIBO, ESTADO ZULIA REALIZADO POR: SOTO GARCÍA, LUIS MANUEL C.I.: 19550568 SECCIÓN: 08 ISI M01 PROFESOR: ING. JOSE PARRA MARCAIBO, FEBRERO DEL 2012 ARQUITECTURA TCP/IP TCP/IP (Protocolo de Control de Transmisión/Protocolo de Internet) es un conjunto de protocolos que definen cómo se intercambian todas las transmisiones a través de cualquier grupo de redes interconectadas El primer modelo de protocolo en capas para comunicaciones de internetwork se creó a principios de la década de los setenta y se conoce con el nombre de modelo de Internet. Define cuatro categorías de funciones que deben tener lugar para que las comunicaciones sean exitosas. La arquitectura de la suite de protocolos TCP/IP sigue la estructura de este modelo. Por esto, es común que al modelo de Internet se lo conozca como modelo TCP/IP. La mayoría de los modelos de protocolos describen un stack de protocolos específicos del proveedor. Sin embargo, puesto que el modelo TCP/IP es un estándar abierto, una compañía no controla la definición del modelo. Las definiciones del estándar y los protocolos TCP/IP se explican en un foro público y se definen en un conjunto de documentos disponibles al público. Estos documentos se denominan Solicitudes de comentarios (RFCS). Contienen las especificaciones formales de los protocolos de comunicación de datos y los recursos que describen el uso de los protocolos. Las RFC (Solicitudes de comentarios) también contienen documentos técnicos y organizacionales sobre Internet, incluyendo las especificaciones técnicas y los documentos de las políticas producidos por el Grupo de trabajo de ingeniería de Internet (IETF). COMPARACION ENTRE EL MODELO OSI Y EL MODELO TCP/IP Los protocolos que forman la suite de protocolos TCP/IP pueden describirse en términos del modelo de referencia OSI. En el modelo OSI, la capa Acceso a la red y la capa Aplicación del modelo TCP/IP están subdivididas para describir funciones discretas que deben producirse en estas capas. En la capa Acceso a la red, la suite de protocolos TCP/IP no especifica cuáles protocolos utilizar cuando se transmite por un medio físico; sólo describe la transferencia desde la capa de Internet a los protocolos de red física. Las Capas OSI 1 y 2 analizan los procedimientos necesarios para tener acceso a los medios y los medios físicos para enviar datos por una red. Los paralelos clave entre dos modelos de red se producen en las Capas 3 y 4 del modelo OSI. La Capa 3 del modelo OSI, la capa Red, se utiliza casi universalmente para analizar y documentar el rango de los procesos que se producen en todas las redes de datos para direccionar y enrutar mensajes a través de una internetwork. El Protocolo de Internet (IP) es el protocolo de la suite TCP/IP que incluye la funcionalidad descrita en la Capa 3. La Capa 4, la capa Transporte del modelo OSI, con frecuencia se utiliza para describir servicios o funciones generales que administran conversaciones individuales entre los hosts de origen y de destino. Estas funciones incluyen acuse de recibo, recuperación de errores y secuenciamiento. En esta capa, los protocolos TCP/IP, Protocolo de control de transmisión (TCP) y Protocolo de datagramas de usuario (UDP) proporcionan la funcionalidad necesaria. La capa de aplicación TCP/IP incluye una cantidad de protocolos que proporcionan funcionalidad específica para una variedad de aplicaciones de usuario final. Las Capas 5, 6 y 7 del modelo OSI se utilizan como referencias para proveedores y programadores de software de aplicación para fabricar productos que necesitan acceder a las redes para establecer comunicaciones. DIRECIONAMIENTO IP Además de la dirección física (en la interfaz de red) que identifica al dispositivo individual, Internet requiere una convención en el direccionamiento: una dirección que identifique la conexión de una estación a la red, Cada dirección Internet consta de 4 bytes (32 bits) que definen tres campos: la clase, el identificador de la red y el identificador de la estación. Estas partes son de longitud variable dependiendo de las clases de direcciones. DATAGRAMAS IP Hay dos formas de encaminar los paquetes en una red conmutación de paquetes. Estas son: datagrama y circuito virtual. En la técnica de datagrama cada paquete se trata de forma independiente, conteniendo cada uno la dirección de destino. La red puede encaminar (mediante un router) cada fragmento hacia el Equipo Terminal de Datos (ETD) receptor por rutas distintas. Esto no garantiza que los paquetes lleguen en el orden adecuado ni que todos lleguen al destino. Protocolos basados en datagramas: IPX, UDP, IPoAC, CL. Los datagramas tienen cabida en los servicios de red no orientados a la conexión (como por ejemplo UDP o Protocolo de Datagrama de Usuario). Los datagramas IP son las unidades principales de información de Internet. Los términos trama, mensaje, paquete de red y segmento también se usan para describir las agrupaciones de información lógica en las diversas capas del modelo de referencia OSI y en los diversos círculos tecnológicos. La estructura de un datagrama es: cabecera y datos. Un datagrama tiene una cabecera que contiene una información de direcciones de la capa de red. Los encaminadores examinan la dirección de destino de la cabecera, para dirigir los datagramas al destino. Internet es una red de datagramas. La conmutación de los paquetes puede ser orientada a conexión y no orientada a conexión. En el caso orientado a conexión, el protocolo utilizado para transporte es TCP. TCP garantiza que todos los datos lleguen correctamente y en orden. En el caso no orientado a conexión, el protocolo utilizado para transporte es UDP. UDP no tiene ninguna garantía.Sin embargo esta propiedad de los UDP; es básicamente, la que hacen tan preferido los protocolos SNMP (Simple Network Management Protocol), aportandole la baja carga a la red que posee y su absoluta independencia al hardware entre los que facilita el intercambio de información. Opción que debe aumentar en el tiempo, si tenemos en cuenta que las primeras versiones de los SNMP datan de la era de los microprocesadores de 8 bits. CORREO ELECTRONICO Correo electrónico (correo-e, conocido también como e-mail ), es un servicio de red que permite a los usuarios enviar y recibir mensajes y archivos rápidamente (también denominados mensajes electrónicos o cartas electrónicas) mediante sistemas de comunicación electrónicos. Principalmente se usa este nombre para denominar al sistema que provee este servicio en Internet, mediante el protocolo SMTP, aunque por extensión también puede verse aplicado a sistemas análogos que usen otras tecnologías. Por medio de mensajes de correo electrónico se puede enviar, no solamente texto, sino todo tipo de documentos digitales. Su eficiencia, conveniencia y bajo coste están logrando que el correo electrónico desplace al correo ordinario para muchos usos habituales. El correo electrónico antecede a la Internet, y de hecho, para que ésta pudiera ser creada, fue una herramienta crucial. En una demostración del MIT (Massachusetts Institute of Technology) de 1961, se exhibió un sistema que permitía a varios usuarios ingresar a una IBM 7094 desde terminales remotas, y así guardar archivos en el disco. Esto hizo posibles nuevas formas de compartir información. El correo electrónico comenzó a utilizarse en 1965 en una supercomputadora de tiempo compartido y, para 1966, se había extendido rápidamente para utilizarse en las redes de computadoras. En 1971, Ray Tomlinson incorporó el uso de la arroba (@). Eligió la arroba como divisor entre el usuario y la computadora en la que se aloja la casilla de correo porque no existía la arroba en ningún nombre ni apellido. En inglés la arroba se lee «at» (en). Así, fulano@máquina.com se lee fulano en máquina punto com. El nombre correo electrónico proviene de la analogía con el correo postal: ambos sirven para enviar y recibir mensajes, y se utilizan "buzones" intermedios (servidores), en donde los mensajes se guardan temporalmente antes de dirigirse a su destino, y antes de que el destinatario los revise. Principales protocolos usados en el correo electrónico: MIME SMTP POP3 IMAP ARQUITECTURA X.400 Es un estándar conforme al Modelo de interconexión de sistemas abiertos OSI, para el intercambio de correo electrónico (por entonces se llamaban Mensajes Interpersonales o IPMs) desarrollado por el ITU-T (por entonces llamado CCITT) con el beneplácito del ISO desde el año 1984 . Como le pasó a la mayor parte de los estándares OSI del Nivel de aplicación no soportó la competencia con el protocolo similar Internet, en este caso el SMTP. El correo X.400 llegó a tener una base de usuarios relativamente amplia, especialmente en Europa, sobre todo en entornos corporativos y de investigación. El modelo de correo era más robusto y completo que el equivalente de Internet. Su sistema de direcciones de correo, basado en X.500, era demasiado complicado para la época, aunque muchísimo más potente. Como todos los estándares OSI, este era el recomendado/soportado por las compañías telefónicas (por la época y en Europa casi todas eran monopolios estatales) que ofertaban unas tarifas de conexión excesivas. Un poco por todo ello el estándar OSI no tuvo gran aceptación. No obstante aún se usa el correo X.400 en algunas aplicaciones sectoriales que requieran mayor seguridad e integridad (como aplicaciones militares), y es el modelo que hay por debajo de aplicaciones relativamente populares como Lotus Notes. La primera versión de X.400 es de 1984 (el Libro Rojo), se revisó en profundidad en 1988 (Libro Azul). Se le añadieron nuevas funciones en 1992 (Libro Blanco), y en sucesivas actualizaciones. Los principales protocolos de X.400 eran: P1 para comunicación entre MTA's (las "estafetas electrónicas"), P3 entre agentes de usuario (UA, osea el programa de correo electrónico del usuario final) y MTA, y P7 entre UA y almacenes de mensajes. Se definieron protocolos conceptuales para la comunicación entre UAs, a pesar de que esto no podía darse directamente, usando P1 y P3 como canal fiable. Este protocolo se llamó P2 en Libro Rojo y P22 en el Libro Azul. Algunas características sobresalientes de X.400 eran la separación entre contenido y "sobre", las direcciones estructuradas, la posibilidad de contenido multimedia (en MIME) y el tratamiento integral del cifrado y autentificación. Dado que las operadoras de X.400 eran las Telefónicas se describieron pasarelas hacia otros servicios como el télex, el fax o el correo ordinario. El hecho de que requiriera control centralizado, puede que tenga que ver con el hecho de que no tuviera mucho éxito. ARQUITECTURA SMTP (SIMPLE MAIL TRANSFER PROTOCOL) Simple Mail Transfer Protocol (SMTP) Protocolo Simple de Transferencia de Correo, es un protocolo de la capa de aplicación.Protocolo de red basado en textos utilizados para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos (PDA's, teléfonos móviles, etc.). Está definido en el RFC 2821 y es un estándar oficial de Internet. SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje a uno o varios receptores. La comunicación entre el cliente y el servidor consiste enteramente en líneas de texto compuestas por caracteres ASCII. El tamaño máximo permitido para estas líneas es de 1000 caracteres. Las respuestas del servidor constan de un código numérico de tres dígitos, seguido de un texto explicativo. El número va dirigido a un procesado automático de la respuesta por autómata, mientras que el texto permite que un humano interprete la respuesta. En el protocolo SMTP todas las órdenes, réplicas o datos son líneas de texto, delimitadas por el carácter <CRLF>. Todas las réplicas tienen un código numérico al comienzo de la línea. En el conjunto de protocolos TCP/IP, el SMTP va por encima del TCP, usando normalmente el puerto 25 en el servidor para establecer la conexión. RESUMEN SIMPLE DEL FUNCIONAMIENTO DEL PROTOCOLO SMTP Cuando un cliente establece una conexión con el servidor SMTP, espera a que éste envíe un mensaje “220 Service ready” o “421 Service non available” Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conectó con el servidor SMTP correcto. El cliente comienza la transacción del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es valido, el servidor responde “250 OK”. Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestará “250 OK” o bien “550 No such user here”, si no encuentra al destinatario. Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que a continuación se envían los contenidos del mensaje. El servidor responde “354 Start mail input, end with <CRLF>.<CRLF>” Esto indica al cliente como ha de notificar el fin del mensaje. Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se termina con un <CRLF>.<CRLF> (la última línea será un punto), a lo que el servidor contestará “250 OK”, o un mensaje de error apropiado. Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la conexión. También puede usar la orden TURN, con lo que el cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene más mensajes que enviar, repite el proceso hasta completarlos. Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestará con una lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestará con un mensaje "500 Syntax error, command unrecognized". EN EL EJEMPLO PUEDEN VERSE LAS ÓRDENES BÁSICAS DE SMTP: HELO, para abrir una sesión con el servidor MAIL FROM, para indicar quien envía el mensaje RCPT TO, para indicar el destinatario del mensaje DATA, para indicar el comienzo del mensaje, éste finalizará cuando haya una línea únicamente con un punto. QUIT, para cerrar la sesión RSET Aborta la transacción en curso y borra todos los registros. SEND Inicia una transacción en la cual el mensaje se entrega a una terminal. SOML El mensaje se entrega a un terminal o a un buzón. SAML El mensaje se entrega a un terminal y a un buzón. VRFY Solicita al servidor la verificación del argumento. EXPN Solicita al servidor la confirmación del argumento. HELP Permite solicitar información sobre un comando. NOOP Se emplea para reiniciar los temporizadores. TURN Solicita al servidor que intercambien los papeles. De los tres dígitos del código numérico, el primero indica la categoría de la respuesta, estando definidas las siguientes categorías: 2XX, la operación 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 envíe nuevos datos para terminar la operación 4XX, para una respuesta de error, pero se espera a que se repita la instrucción 5XX, para indicar una condición de error permanente, por lo que no debe repetirse la orden Una vez que el servidor recibe el mensaje finalizado con un punto puede almacenarlo si es para un destinatario que pertenece a su dominio, o bien retransmitirlo a otro servidor para que finalmente llegue a un servidor del dominio del receptor. MODELO CLIENTE – SERVIDOR Cuando la gente intenta acceder a información en sus dispositivos, ya sean éstos una computadora personal o portátil, un PDA, teléfono celular o cualquier otro dispositivo conectado a la red, los datos pueden no estar físicamente almacenados en sus dispositivos. Si así fuere, se debe solicitar al dispositivo que contiene los datos, permiso para acceder a esa información. En el modelo cliente-servidor, el dispositivo que solicita información se denomina cliente y el dispositivo que responde a la solicitud se denomina servidor. Los procesos de cliente y servidor se consideran una parte de la capa de Aplicación. El cliente comienza el intercambio solicitando los datos al servidor, que responde enviando uno o más streams de datos al cliente. Los protocolos de capa de Aplicación describen el formato de las solicitudes y respuestas entre clientes y servidores. Además de la transferencia real de datos, este intercambio puede requerir de información adicional, como la autenticación del usuario y la identificación de un archivo de datos a transferir. Un ejemplo de una red cliente/servidor es un entorno corporativo donde los empleados utilizan un servidor de e-mail de la empresa para enviar, recibir y almacenar emails. El cliente de correo electrónico en la computadora de un empleado emite una solicitud al servidor de e-mail para un mensaje no leído. El servidor responde enviando el e-mail solicitado al cliente. Aunque los datos generalmente se describen como un flujo del servidor al cliente, algunos datos siempre fluyen del cliente al servidor. El flujo de datos puede ser el mismo en ambas direcciones o inclusive ser mayor en la dirección que va del cliente al servidor. Por ejemplo, un cliente puede transferir un archivo al servidor con fines de almacenamiento. La transferencia de datos de un cliente a un servidor se conoce como subida y la de los datos de un servidor a un cliente, descarga. En un contexto general de redes, cualquier dispositivo que responde a una solicitud de aplicaciones de cliente funciona como un servidor. Un servidor generalmente es una computadora que contiene información para ser compartida con muchos sistemas de cliente. Por ejemplo, páginas Web, documentos, bases de datos, imágenes, archivos de audio y vídeo pueden almacenarse en un servidor y enviarse a los clientes que lo solicitan. En otros casos, como una impresora de red, el servidor de impresión envía las solicitudes de impresión del cliente a la impresora específica. Diferentes tipos de aplicaciones del servidor tienen diferentes requerimientos para el acceso de clientes. Algunos servidores pueden requerir de autenticación de la información de cuenta del usuario para verificar si el usuario tiene permiso para acceder a los datos solicitados o para utilizar una operación en particular. Dichos servidores deben contar con una lista central de cuentas de usuarios y autorizaciones, o permisos (para operaciones y acceso a datos) otorgados a cada usuario. Cuando se utiliza un cliente FTP, por ejemplo, si usted solicita subir datos al servidor FTP, se le puede dar permiso para escribir su carpeta personal pero no para leer otros archivos del sitio. En una red cliente-servidor, el servidor ejecuta un servicio o proceso, a veces denominado daemon de servidor. Al igual que la mayoría de los servicios, los daemons generalmente se ejecutan en segundo plano y no se encuentran bajo control directo del usuario. Los daemons se describen como servidores que "escuchan" una solicitud del cliente, porque están programados para responder cada vez que el servidor recibe una solicitud para el servicio proporcionado por el daemon. Cuando un daemon "escucha" una solicitud de un cliente, intercambia los mensajes adecuados con el cliente, según lo requerido por su protocolo, y procede a enviar los datos solicitados al cliente en el formato correspondiente. MASCARAS DE SUB REDES La máscara de red es una combinación de bits que sirve para delimitar el ámbito de una red de computadoras. Su función es indicar a los dispositivos qué parte de la dirección IP es el número de la red, incluyendo la subred, y qué parte es la correspondiente al host. FUNCIONAMIENTO Básicamente, mediante la máscara de red una computadora (principalmente la puerta de enlace, router...) podrá saber si debe enviar los datos dentro o fuera de las redes. Por ejemplo, si el router tiene la dirección IP 192.168.1.1 y máscara de red 255.255.255.0, entiende que todo lo que se envía a una dirección IP que empiece por 192.168.1 va para la red local y todo lo que va a otras direcciones IP, para afuera (internet, otra red local mayor...). Supongamos que tenemos un rango de direcciones IP desde 10.0.0.0 hasta 10.255.255.255. Si todas ellas formaran parte de la misma red, su máscara de red sería: 255.0.0.0. También se puede escribir como 10.0.0.0/8 Como una máscara consiste en una seguidilla de unos consecutivos, y luego ceros (si los hay), los números permitidos para representar la secuencia son los siguientes: 0, 128, 192, 224, 240, 248, 252, 254 y 255. La representación utilizada se define colocando en 1 todos los bits de red (máscara natural) y en el caso de subredes, se coloca en 1 los bits de red y los bits de host usados por las subredes. Así, en esta forma de representación (10.0.0.0/8) el 8 sería la cantidad de bits puestos a 1 que contiene la máscara en binario, comenzando desde la izquierda. Para el ejemplo dado (/8), sería 11111111.00000000.00000000.00000000 y en su representación en decimal sería 255.0.0.0. Una máscara de red representada en binario son 4 octetos de bits (11111111.11111111.11111111.11111111). EJEMPLO 8bit x 4 octetos = 32 bit. (11111111.11111111.11111111.11111111 = 255.255.255.255) 8bit x 3 octetos = 24 bit. (11111111.11111111.11111111.00000000 = 255.255.255.0) 8bit x 2 octetos = 16 bit. (11111111.11111111.00000000.00000000 = 255.255.0.0) 8bit x 1 octetos = 8 bit. (11111111.00000000.00000000.00000000 = 255.0.0.0) En el ejemplo 10.0.0.0/8, según lo explicado anteriormente, indicaría que la máscara de red es 255.0.0.0 Las máscaras de redes , se utilizan como validación de direcciones realizando una operación AND lógica entre la dirección IP y la máscara para validar al equipo, lo cual permite realizar una verificación de la dirección de la Red y con un OR y la máscara negada se obtiene la dirección del broadcasting. TABLA DE MÁSCARAS DE RED MÁSCARAS DE RED Binario Decimal CIDR Nº HOSTs Clase 11111111.11111111.11111111.11111111 255.255.255.255 /32 1 11111111.11111111.11111111.11111110 255.255.255.254 /31 2 11111111.11111111.11111111.11111100 255.255.255.252 /30 4 11111111.11111111.11111111.11111000 255.255.255.248 /29 8 11111111.11111111.11111111.11110000 255.255.255.240 /28 16 11111111.11111111.11111111.11100000 255.255.255.224 /27 32 11111111.11111111.11111111.11000000 255.255.255.192 /26 64 11111111.11111111.11111111.10000000 255.255.255.128 /25 128 11111111.11111111.11111111.00000000 255.255.255.0 /24 256 11111111.11111111.11111110.00000000 255.255.254.0 /23 512 11111111.11111111.11111100.00000000 255.255.252.0 /22 1024 11111111.11111111.11111000.00000000 255.255.248.0 /21 2048 11111111.11111111.11110000.00000000 255.255.240.0 /20 4096 11111111.11111111.11100000.00000000 255.255.224.0 /19 8192 11111111.11111111.11000000.00000000 255.255.192.0 /18 16384 11111111.11111111.10000000.00000000 255.255.128.0 /17 32768 11111111.11111111.00000000.00000000 255.255.0.0 /16 65536 11111111.11111110.00000000.00000000 255.254.0.0 /15 131072 11111111.11111100.00000000.00000000 255.252.0.0 /14 262144 11111111.11111000.00000000.00000000 255.248.0.0 /13 524288 11111111.11110000.00000000.00000000 255.240.0.0 /12 1048576 11111111.11100000.00000000.00000000 255.224.0.0 /11 2097152 11111111.11000000.00000000.00000000 255.192.0.0 /10 4194304 11111111.10000000.00000000.00000000 255.128.0.0 /9 8388608 11111111.00000000.00000000.00000000 255.0.0.0 /8 16777216 11111110.00000000.00000000.00000000 254.0.0.0 /7 33554432 11111100.00000000.00000000.00000000 252.0.0.0 /6 67108864 11111000.00000000.00000000.00000000 248.0.0.0 /5 134217728 C B A 11110000.00000000.00000000.00000000 240.0.0.0 /4 268435456 11100000.00000000.00000000.00000000 224.0.0.0 /3 536870912 11000000.00000000.00000000.00000000 192.0.0.0 /2 1073741824 10000000.00000000.00000000.00000000 128.0.0.0 /1 2147483648 00000000.00000000.00000000.00000000 0. /0 4294967296 Las máscaras 255.0.0.0 (clase A), 255.255.0.0 (clase B) y 255.255.255.0 (clase C) suelen ser suficientes para la mayoría de las redes privadas. Sin embargo, las redes más pequeñas que podemos formar con estas máscaras son de 254 hosts y para el caso de direcciones públicas, su contratación tiene un coste alto. Por esta razón suele ser habitual dividir las redes públicas de clase C en subredes más pequeñas. A continuación se muestran las posibles divisiones de una red de clase C. La división de una red en subredes se conoce como Subnetting. CLASES DE MÁSCARAS EN SUBREDES Clase Bits IP Subred IP Broadcast Máscara en decimal CIDR A 0 0.0.0.0 127.255.255.255 255.0.0.0 /8 B 10 128.0.0.0 191.255.255.255 255.255.0.0 C 110 192.0.0.0 223.255.255.255 255.255.255.0 /24 D 1110 224.0.0.0 239.255.255.255 sin definir sin definir E 1111 240.0.0.0 255.255.255.254 sin definir sin definir /16 PROTOCOLOS POP (POST OFFICE PROTOCOL) En informática se utiliza el Post Office Protocol (POP3, Protocolo de la oficina de correo) en clientes locales de correo para obtener los mensajes de correo electrónico almacenados en un servidor remoto. Es un protocolo de nivel de aplicación en el Modelo OSI. Las versiones del protocolo POP (informalmente conocido como POP1) y POP2 se han hecho obsoletas debido a las últimas versiones de POP3. En general cuando uno se refiere al término POP, nos referimos a POP3 dentro del contexto de protocolos de correo electrónico. POP3 está diseñado para recibir correo, no para enviarlo; le permite a los usuarios con conexiones intermitentes o muy lentas (tales como las conexiones por módem), descargar su correo electrónico mientras tienen conexión y revisarlo posteriormente incluso estando desconectados. Cabe mencionar que la mayoría de los clientes de correo incluyen la opción dedejar 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 operación conectado y desconectado. Los clientes de correo electrónico 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 operación de IMAP permita a múltiples clientes acceder al mismo buzón de correo. La mayoría de los clientes de correo electrónico soportan POP3 ó IMAP; sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor agregado de sus servicios. PROTOCOLOS IMAP (INTERNET MESSAGE ACCESS PROTOCOL) Internet Message Access Protocol, o su acrónimo IMAP, es un protocolo de red de acceso a mensajes electrónicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado, es más complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP. IMAP y POP3 (Post Office Protocol versión 3) son los dos protocolos que prevalecen en la obtención de correo electrónico. Todos los servidores y clientes de email están virtualmente soportados por ambos, aunque en algunos casos hay algunas interfaces específicas del fabricante típicamente 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 también soportan interoperabilidad con IMAP y POP3 con otros clientes y servidores. La versión actual de IMAP, IMAP versión 4 revisión 1 (IMAP4rev1), está definida por el RFC 3501. IMAP fue diseñado como una moderna alternativa a POP por Mark Crispin en el año 1986. ver web. 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 electrónico son comúnmente denominados clientes POP o IMAP, pero en ambos casos se utiliza SMTP. La mayoría 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. IMAP les permite a los usuarios acceder a los nuevos mensajes instantáneamente en sus computadoras, ya que el correo está almacenado en la red. Con POP3 los usuarios tendrían que descargar el email a sus computadoras o accederlo vía web. Ambos métodos toman más tiempo de lo que le tomaría a IMAP, y se tiene que descargar el email nuevo o refrescar la página para ver los nuevos mensajes. VENTAJAS SOBRE POP3 Algunas de las características importantes que diferencian a IMAP y POP3 son: Respaldo para los modos de operación en línea y fuera de línea: 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 más rápidos para usuarios que tienen una gran cantidad de mensajes o mensajes grandes. Respaldo para la conexión de múltiples clientes simultáneos a un mismo destinatario: El protocolo POP3 supone que el cliente conectado es el único dueño de una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos simultáneos a múltiples clientes y proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a un buzón de correo por otro cliente concurrentemente conectado. Respaldo para acceso a partes MIME de los mensajes y obtención parcial: Casi todo el correo electrónico 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 más seguro. Respaldo para que la información de estado del mensaje se mantenga en el servidor: A través de la utilización de señales definidas en el protocolo IMAP4 de los clientes, se puede vigilar el estado del mensaje, por ejemplo, si el mensaje ha sido o no leído, respondido o eliminado. Estas señales 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. Respaldo para accesos múltiples 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 múltiples buzones de correo también le permite al servidor proporcionar acceso a los directorios públicos y compartidos. Respaldo para búsquedas 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 buzón de correo, agilizando, de esta manera, las búsquedas. Respaldo para un mecanismo de extensión definido: Como reflejo de la experiencia en versiones anteriores de los protocolos de Internet, IMAP define un mecanismo explícito mediante el cual puede ser extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso común. Un ejemplo de extensión 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 extensión, para realizar la misma tarea, el cliente debería contactar periódicamente al servidor para ver si hay mensajes nuevos. ESTRUCTURA Y CODIFICACION DE MENSAJES MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS) Multipurpose Internet Mail Extensions o MIME (en español "extensiones multipropósito de correo de internet") son una serie de convenciones o especificaciones dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. En sentido general las extensiones de MIME van encaminadas a soportar: Texto en conjuntos de caracteres distintos de US-ASCII; adjuntos que no son de tipo texto; cuerpos de mensajes con múltiples partes (multi-part); información de encabezados con conjuntos de caracteres distintos de ASCII. Prácticamente todos los mensajes de correo electrónico escritos por personas en Internet y una proporción considerable de estos mensajes generados automáticamente son transmitidos en formato MIME a través de SMTP. Los mensajes de correo electrónico en Internet están tan cercanamente asociados con el SMTP y MIME que usualmente se les llama mensaje SMTP/MIME. En 1991 la IETF (Grupo de Trabajo en Ingeniería de Internet, Internet Engineering Task Force en inglés) comenzó a desarrollar esta norma y desde 1994 todas las extensiones MIME están especificadas de forma detallada en diversos documentos oficiales disponibles en Internet. MIME está especificado en seis Request for Comments o RFC (en español "solicitud de comentarios): RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077. Los tipos de contenido definidos por el estándar MIME tienen gran importancia también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son algunos protocolos de redtales como HTTP de la Web. HTTP requiere que los datos sean transmitidos en un contexto de mensajes tipo e-mail aunque los datos pueden no ser un e-mail propiamente dicho. En la actualidad ningún programa de correo electrónico o navegador de Internet puede considerarse completo si no acepta MIME en sus diferentes facetas (texto y formatos de archivo). El protocolo básico de transmisión de mensajes electrónicos de Internet soporta solo caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de correo electrónico, ya que incluyen solo caracteres suficientes para escribir en un número reducido de lenguajes, principalmente Inglés. Otros lenguajes basados en el Alfabeto latino es adicionalmente un componente fundamental en protocolos de comunicación como HTTP, el que requiere que los datos sean transmitidos como un e-mail aunque los datos pueden no ser un e-mail propiamente dicho. Los clientes de correo y los servidores de correo convierten automáticamente desde ya formato MIME cuando envían o reciben (SMTP/MIME) e-mails. CONTENT-TRANSFER-ENCODING En Junio de 1992, MIME (RFC 1341 queda obsoleta por la nueva RFC 2045) define un conjunto de métodos para representar datos binarios usando texto ASCII. El encabezado MIME content-transfer-encoding: indica el método que ha sido usado. La RFC y la lista de IANA definen los siguientes valores los cuales no son sensibles a mayúsculas y minúsculas: Adecuados para usar con SMTP: 7BIT — soporta hasta 998 octetos por línea de código; los caracteres están en el rango entre 1 - 127 con CR y LF (códigos 13 y 10 respectivamente) que sólo pueden aparecer como parte de un fin de línea CRLF. Este es el valor implícito para este encabezado. QUOTED PRINTABLE — usado para codificar secuencias arbitrarias de octetos de forma que satisfaga las reglas de 7bit. Fue diseñado para ser eficiente y en la mayoría de los casos legible para un humano cuando es usado con datos de texto que consisten primariamente en caracteres del conjunto US-ASCII y que también contengan porciones de bytes con valores que están fuera de ese rango. BASE64 — usado para codificar secuencias arbitrarias de octetos de forma que satisfaga las reglas de 7bit. Tiene una sobrecarga fija al ejecutar el algoritmo y tiene el propósito de ser usado con datos que no sean de texto o textos que contengan pocos valores dentro del rango de ASCII. Adecuado para usar con servidores SMTP que soporten 8BITMIME extensiones SMTP: 8BIT — soporta hasta 998 octetos por línea de código, los caracteres están en el rango entre 1..256 con CR y LF (códigos 13 y 10 respectivamente) que sólo pueden aparecer como parte de un fin de línea CRLF. Adecuados sólo para usar con servidores SMTP que soporten la extensión SMTP BINARYMIME (RFC 3030): BINARY — cualquier secuencia de octetos. No existe una codificación definida explícitamente para enviar datos binarios arbitrarios a través de un transporte SMTP con las extensiones 8BITMIME. Por tanto base64 o quoted-printable (con sus ineficiencias asociadas) tienen que ser usadas aún. Estas restricciones no se aplican a otros usos de MIME como son Servicios Web con adjuntos MIME o MTOM.