1 Protocolos SMTP, POP3 e IMAPCorreo Electrónico Protocolos SMTP, POP3 e IMAP
2 Historia Los primeros sistemas de correo electrónico simplemente consistían en protocolos de transferencia de archivos, con la convención de que la primera línea de cada mensaje (es decir del archivo) contenía la dirección del destinatario. Limitaciones de este sistema: envío a grupos, sin notificación En 1982 se publicaron las propuestas de correo electrónico del ARPANET como RFC 821 (protocolo de transmisión SMTP) y RFC 822 (formato de mensaje). Dos años después, el CCITT elaboró su recomendación X.400, pero su excesiva complejidad, hace que no se utilice, como la mayoría de aplicaciones OSI.
3 Arquitectura del sistema de correoConceptos de envoltura (destino, prioridad, seguridad, etc, un tipo de cabecera primitiva definida en RFC821) y contenido o mensaje (que a su vez se divide en cabecera del mensaje y cuerpo, separados por una línea en blanco y se define en RFC822). Funciones del sistema de correo:edición de mensajes, transferencia y generación de informes. Subsistemas que lo forman: agentes de transferencia (generalmente “demonios”) y los agentes de usuario. distribución transferencia entrega final Agentes usuario La distinción entre la envoltura y el contenido, que a su vez incluye una cabecera no queda muy clara. Hay campos de la envoltura que aparecen en la parte de la cabecera del contenido etc. Muchos MTA por tanto, cuando tienen que enviar un correo, tanto con la envoltura como con la cabecera, extraen y procesan la información que les interesa para enviar por SMTP el mensaje.
4 Agentes de transferenciaEstos agentes se clasifican en: -de distribución: utilizando para ello el protocolo SMTP (Simple Mail Transfer Protocol) RFC 821 o SMTP extendido (ESMTP) RFC 1425 -de entrega final: que permita al usuario gestionar su correo a través de una máquina remota, utilizando los protocolos POP3 (Post Office Protocol) RFC 1225 e IMAP (Interactive Mail Access Protocol) RFC 1064
5 Conceptos DNS y registros MX: son intercambiadores de correo, que reciben correo en nombre de otro servidor cuando el principal está fuera de servicio Relay o reenvio: indica si un servidor de correo, de transferencia de distribución, acepta correo de otro servidor para reenviar. Ejemplo: post.uv.es cuando manda un correo a un servidor de EEUU no lo hace directamente, si no lo va reenviando a través de servidores. SPAM: envío masivo a un conjunto de direcciones gestionadas por un servidor. El servidor puede configurarse para marcarlas como SPAM. La obtención de usuarios de un servidor se puede realizar utilizando los comandos SMTP “VRFY” y “EXPN”. El nombre de SPAM viene de una marca de chorizo americana q se hizo tan popular q todo el mundo la nombraba, que aparecía hasta en la sopa, y por tanto, luego pasó a utilizarse en la jerga popular, pero fue una coletilla tan popular que empezó a agobiar, terminando su término a identificar cuando algo empieza a ser pesado, cuando te llega mucho correo, otro correo!!! spam, spam,
6 Agentes de transferencia de distribución (SMTP) (1/2)El SMTP es un sencillo protocolo cliente/servidor en formato ASCII. Establecida una comunicación TCP entre la computadora transmisora del correo, que opera como cliente, y el puerto 25 de la computadora receptora del correo, que opera como servidor, el cliente permanece a la espera de recibir un mensaje del servidor. En inglés es conocido como MTA mail transfer agent. Ejemplo de paquetes MTA son: Sendmail (www.sendmail.org), Smail, Qmail (www.qmail.org) diseñado para alta seguridad con una recompensa de 500$ quien encuentre el primer agujero (desde Marzo 97 no ha habido reclamaciones), Exim, ...
7 Agentes de transferencia de distribución (SMTP) (2/2): protocoloEl servidor comienza por enviar una línea de texto que proporciona su identidad e indica si está preparado o no para recibir correo: a.-Si no lo está, el cliente libera la conexión y lo intenta después. Por defecto en Sendmail, cada 15 minutos durante 4 días. b.-Si está dispuesto a aceptar correo electrónico, el cliente anuncia de quién viene el mensaje, y a quién está dirigido. Si existe tal destinatario en el destino, el servidor da al cliente permiso para enviar el mensaje. Entonces el cliente envía el mensaje y el servidor acusa su recibo. Si existe más correo electrónico también se envía ahora. Una vez que todo el correo ha sido intercambiado en ambas direcciones, se libera la conexión.
8 Comandos SMTP: clienteLos 7 primeros (HELO a QUIT) son obligatorios y son aceptados por todos los agentes SMTP. Este protocolo se puede llevar a cabo utilizando una conexión telnet post.uv.es 25, y tecleando los comandos según el protocolo tal como se especifica a continuación.
9 Códigos de respuesta SMTP: servidor
10 C: MAIL FROM
11 Ejemplo de diálogo entre el cliente “glup. uvEjemplo de diálogo entre el cliente “glup.uv.es” C y el servidor “post.uv.es” S (2/2) C: Aquí va el mensaje de correo en texto. C: C: --abcdef C: Content-Type: message/external-body; C: access-type=”anon-ftp”, C: site=”glup.uv.es”, C: directory=”pub”, C: name=”mensaje.snd” C: content-type: audio/basic C: content-transfer-encoding: base64 C: . C: From: C: To: C: MIME-Version: 1.0 C: Message-Id: C: Content-Type: multipart/alternative; boundary=abcdef C: Subject: Mensaje de correo C: C: Éste es el preambulo, el agente de usuario lo ignora. C: --abcdef C: Content-Type: text/richtext S: 250 mensaje aceptado C: QUIT S: 221 post.uv.es cerrando conexión
12 Comentarios sobre SMTP (1/2)La sintaxis de los comandos del cliente se especifica con rigidez. La sintaxis de las respuestas del servidor es menos rígida, sólo cuenta el código numérico, pudiendo cada implementación del protocolo SMTP poner la cadena de texto que desee después del código numérico
13 Comentarios sobre SMTP (2/2): inconvenientesAlgunas implementaciones más viejas de SMTP no pueden manejar mensajes mayores de 64 Kbytes. Si el cliente y el servidor tienen temporizaciones distintas, uno de ellos puede terminar mientras que el otro continúa trabajando, terminando inesperadamente la conexión. En ocasiones pueden dispararse tormentas de correo infinitas cuando ambos servidores mutuamente tienen una lista que incluye a la otra lista del otro servidor. Solución, un nuevo protocolo extendido: SMTP extendido (ESMTP) en el RFC Los clientes que deseen usarlo deben enviar un mensaje EHLO, en lugar de HELO. Si el saludo se rechaza, código 500, esto indica que el servidor es un servidor SMTP normal (basado en el RFC 821) y el cliente debe proceder de la manera normal.
14 Tormenta de correos Servidor X Servidor YList A={...,B,...} Lista B={...,A,...}
15 Protocolos de entrega final de usuario (1/2)Hemos visto como envían y reciben las máquinas el correo electrónico. Sin embargo, en muchas compañías los usuarios trabajan en un PC de escritorio que no está en Internet (no tienen su dominio propio) y que es incapaz de enviar o recibir correo. Sin embargo, la compañía puede tener uno o más servidores SMTP que pueden enviar y recibir correo electrónico. Para poder recibir el correo electrónico, un PC debe comunicarse con un servidor de correo electrónico usando algún protocolo de entrega. Esta comunicación se realiza explícitamente bajo indicación del usuario. Para poder salir conectándose al servidor de correo local, se realiza habitualmente por SMTP o SendMail. Los protocolos utilizados son parecidos al SMTP. Son utilizados para configurar correo entrante. Como correo saliente, se puede especificar o SMTP o SendMail en el caso de una máquina Unix. Si es SMTP, el cliente conectará con su servidor local para pasar los correos por SMTP. Si es Sendmail el correo saliente, tratará de conectar directamente con el agente SMTP remoto. En ocasiones, por temas de seguridad esta conexión no se puede realizar, porque sólo se permite la salida y conexión de SMTP a través del servidor de correo de la corporación. Con SMTP como correo saliente en el usuario, es la configuración habitual en el caso de tener un cortafuegos con la restricción anterior de salida.
16 Protocolos de entrega final de usuario (2/2)El correo entrante en un cliente se puede realizar básicamente a través de los siguientes protocolos: POP3 (Post Office Protocol) RFC tiene comandos para que un usuario establezca una sesión (USER y PASS), la termine (QUIT), obtenga mensajes (RETR) y los borre (DELE). El protocolo mismo consiste en texto ASCII y se asemeja a SMTP. El objetivo del POP3 es obtener correo electrónico del buzón remoto y almacenarlo en la máquina local del usuario para su lectura posterior. Existen versiones actualmente, que ya permiten no descargar el correo del buzón como IMAP. IMAP (Interactive Mail Access Protocol) RFC La idea en que se basa IMAP es que el servidor de correo electrónico mantenga un depósito central al que puede accederse desde cualquier máquina. Por tanto, a diferencia del POP3, no copia el correo electrónico en la máquina personal del usuario dado que el usuario puede tener varias computadoras para consultar el correo, y observa si sus correos han sido leídos con anterioridad.
17 Otras características de los agentes de transferenciaPueden incorporar filtros o reglas cuando llega un correo electrónico Pueden reenviar (relay) a una dirección diferente, por ejemplo un teléfono movil con SMS, o a otro servidor de correo. Permiten generar una contestación automática, por ejemplo cuando estamos de vacaciones: “Estoy de vacaciones. Regresaré el 15 de Agosto. Que tenga feliz día” Cuando activemos este mecanismo es mejor desuscribirse de las listas de correo, ya que inundaríamos la lista con esta contestación.
18 Formato del buzón (V7 mailbox)Mientras el correo se guarda en el buzón del usuario a la espera de la entrega final, se utiliza un formato determinado. El más frecuente es separar los diferentes correos con una línea empezando por “From “ y si se repite en el interior del texto, entonces se introduce el prefijo “>”. Este formato es conocido por V7 Mailbox, por ser una convención en Unix Version 7. Existen otros formatos como BABYL, MMDF, MH y QMAIL MAILDIR
19 Agentes de usuario Un agente de usuario es normalmente un programa que acepta una variedad de comandos para componer, recibir y contestar los mensajes, así como para manipular los buzones de correo.
20 Formato de los mensajes RFC 822 (1/3)Los mensajes con formato RFC 822 están formados por una envoltura primitiva (descrita en el RFC 821), algunos campos de cabecera, una línea en blanco, y el cuerpo del mensaje. Cada campo de cabecera consiste en una sola línea de texto ASCII que contiene el nombre del campo, dos puntos (:) y, para la mayoría de los campos un valor.
21 Formato de los mensajes RFC 822 (2/3)Campos principales del RFC822:
22 Formato de los mensajes RFC 822 (3/3)Además, los mensajes RFC 822 pueden contener una variedad de campos auxiliares de cabecera usados por los agentes de usuario o los destinatarios. El RFC 822 explícitamente indica que los usuarios pueden inventar cabeceras nuevas para uso privado siempre y cuando comiencen con la cadena X-.
23 MIME (Multipurpuse Internet Mail Protocol)MIME o Extensiones multipropósito de correo Internet. El RFC 822 estaba pensado inicialmente para texto en ASCII 7 bits pero con: Mensajes en idiomas con acentos (español, francés y alemán). Mensajes en alfabetos no latinos (hebreo y ruso). Mensajes en idiomas sin alfabetos (chino y japonés). Mensajes que no contienen texto (audio y vídeo). .... Y aparecen problemas...
24 MIME-(1/2) MIME RFC 1341 y RFC 1521 mantiene la idea básica de continuar usando el RFC 822, pero permite agregar una estructura al cuerpo del mensaje y definir reglas de codificación para los mensajes no ASCII. MIME sólo afecta a los agentes de usuario, ya que para SMTP es totalmente transparente. Nada cambia respecto a la arquitectura de correo anterior.
25 MIME-(2/2): cabeceras de mensaje
26 MIME: Content-Transfer-EncodingIndica la manera en que está envuelto el cuerpo para su transmisión, ya que podría haber problemas con la mayoría de los caracteres distintos de letras, números y signos de puntuación. Existen 5 tipos de codificación de los mensajes según se especifica en RFC1521 conocidos con el nombre de esquemas: ASCII 7, ASCII 8, codificación binaria, base64 y entrecomillada-imprimible.
27 MIME: Content-Transfer-Encoding (1/3) Esquemas de codificación1.-ASCII de 7 bits y ninguna línea exceda de 1000 caracteres 2.-ASCII de 8 bits. Este esquema viola el protocolo original del correo electrónico. Ninguna línea exceda de 1000 caracteres. 3.- Binaria. Utilizan los 8 bits y no respetan el límite de 1000 caracteres por línea. Los programas ejecutables caen en esta categoría. No se da ninguna garantía de que los mensajes en binario llegarán correctamente.
28 MIME: Content-Transfer-Encoding (2/3) Esquemas de codificación4.- Base64 o armadura ASCII. En este esquema, se dividen grupos de 24 bits en unidades de 6 bits (26 mayúsculas, 26 minúsculas, 10 dígitos y + y / de forma ‘A’ es 0, ‘B’ es 1, ...,‘a’ es 26,... ), enviándose cada unidad como carácter ASCII legal. Las secuencias == y = se usan para indicar que el último grupo contenía solo 6 o 12 bits, respectivamente. Los retornos de carro y avances de línea se ignoran, por lo que pueden introducirse a voluntad para mantener la línea lo suficientemente corta. Este es el motivo por lo cual cuando mandamos un texto comprimido muy grande por correo, tarde mucho tiempo en procesar y codificar.
29 MIME: Content-Transfer-Encoding (3/3) Esquemas de codificación5.- Entrecomillada-imprimible (QUOTED-PRINTABLE). Ésta codificación es ASCII de 7 bits, con todos los caracteres por encima de 127 codificados como un signo de igual seguido del valor del carácter en dos dígitos hexadecimales. Se utiliza en el caso de mensajes que son casi completamente ASCII, pero con algunos caracteres no ASCII. En este caso la codificación base64 es algo ineficiente.
30 Ejemplo: Content-Transfer-Encoding base64Supongamos que deseamos enviar el siguiente fragmento de código binario de un programa Código binario (en bytes): 214, 04, 23, 97, 08, 200 Código Base 64: Dividimos cada grupo de 24 bits en grupos de 6 bits, con lo que resultan lo grupos de seis bits siguientes Calculando ahora su valor decimal y teniendo en cuenta la codificación en caracteres descrita con anterioridad: 0fPWXPiH
31 MIME: Content-Type Content-Type especifica la forma del cuerpo del mensaje. Existen 7 tipos definidos en el RFC 1521, cada uno de los cuales tiene uno o más subtipos. El tipo y el subtipo se separan mediante un carácter diagonal (/), ej: Content-Type: video/mpeg
32 MIME: Content-Type: tipos y subtiposLa lista inicial de tipos y subtipos especificada por el RFC 1521 es: Se han agregado muchos otros desde entonces y se agregan nuevas entradas a medida que surge la necesidad
33 MIME: Content-Type: tipo texttext/plain es para mensajes ordinarios que pueden visualizarse como se reciben, sin codificación ni ningún procesamiento posterior text/richtext permite la inclusión de un lenguaje de marcación sencillo en el texto (para indicar negritas, cursivas, tamaños ... Independiente del sistema). Utiliza el lenguaje SGML (Standard Generalized Markup Language), también usado como base del HTML
34 MIME: Content-Type: tipo applicationEl tipo application es un tipo general para los formatos que requieren procesamiento externo no cubierto por ninguno de los otros tipos. El subtipo octet-stream simplemente es una secuencia de bytes no interpretados, tal que a su recepción, un agente de usuario debería presentarla en la pantalla sugiriendo al usuario que se copie en un archivo y solicitando un nombre de archivo. El subtipo postscript, se refiere al lenguaje PostScript de Adobe Systems. Aunque un agente de usuario puede llamar a un intérprete PostScript externo para visualizarlo, hacerlo no está exento de riesgos al ser PostScript un lenguaje de programación completo.
35 MIME: Content-Type: tipo messageEl tipo message permite que un mensaje esté encapsulado por completo dentro de otro. Este esquema es útil para reenviar, correo electrónico. El subtipo rfc822 se utiliza cuando se encapsula un mensaje RFC 822 completo en un mensaje exterior. El subtipo partial hace posible dividir un mensaje encapsulado en pedazos y enviarlos por separado. Los parámetros hacen posible ensamblar correctamente todas las partes en el destino. Ej: 1/3, 2/3, 3/3. El subtipo external-body puede usarse para mensajes muy grandes, por ejemplo películas de vídeo. En lugar de incluir el archivo mpeg en el mensaje, se da una dirección de FTP y el agente de usuario del receptor puede obtenerlo a través de la red cuando se requiera. RECORDATORIO: no es ético manda ficheros excesivamente por , para ello está FTP.
36 MIME: Content-Type: tipo multipartEl tipo es multipart, que permite que un mensaje contenga más de una parte, con el comienzo y el fin de cada parte claramente delimitados. El subtipo mixed permite que cada parte sea diferente. El subtipo alternative indica que cada parte contiene el mismo mensaje, pero expresado en un medio o codificación diferente. El subtipo parallel se usa cuando todas las partes deben “verse” simultáneamente, por ejemplo, en los canales de audio y vídeo de las películas El subtipo digest se usa cuando se juntan muchos mensajes en un mensaje compuesto.
37 } Ejemplo 1º de correo Cabecera RFC822.Return-Path: TRAYECTORIA DE REGRESO X-Sieve: cmu-sieve NUEVA CABECERA Return-Path: Received: from biron.usc.edu (biron.usc.edu [ ]) 3º salto by sello.uv.es (8.11.3/8.11.3) with ESMTP id fACMwIg27676 for Mon, 12 Nov :58: Received: from biron.usc.edu (localhost [ ]) 2º salto by biron.usc.edu (8.12.1/8.12.1) with ESMTP id fACMw6sG029550 for Mon, 12 Nov :58: (PST) Received: from localhost 1º salto by biron.usc.edu (8.12.1/8.12.1/Submit) with ESMTP id fACMvxMm029547 for Mon, 12 Nov :58: (PST) Date: Mon, 12 Nov :57: (PST) From: Baltasar Beferull-Lozano To: santiago felici Subject: HOLA SANTI!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; Content-Transfer-Encoding: QUOTED-PRINTABLE > Balta } Cabecera RFC822. Los “Received” se van apilando. Versión de Sendmail
38 Ejemplo 2º de correo En este ejemplo no hemosFrom: To: MIME-Version: 1.0 Message-Id: Content-Type: multipart/mixer; boundary=abcdef Subject: Mensaje de correo Éste es el preambulo, el agente de usuario lo ignora. --abcdef Content-Type: text/richtext Aquí va el mensaje de correo en texto. Content-Type: message/external-body; access-type=”anon-ftp”, site=”glup.uv.es”, directory=”pub”, name=”mensaje.snd” content-type: audio/basic content-transfer-encoding: base64 En este ejemplo no hemos introducido los campos auxiliares del RFC822.
39 Ejemplo 3º de correo (1/4) Este es un ejemplo de correo, que incluye el envío de un (CCNP 2001/2002 New call for CCNP Local academies (56,7kb) de otra persona que a su vez incluye documentos (CCNP EMEA EQUIPMENT ORDERING TEMPLATE OCT 01.xls (53.1 kb). A su vez, el contiene una tarjeta de presentación personal (gfuster.vcf de 315 bytes) Return-Path: X-Sieve: cmu-sieve 2.0 Received: from tomir.uib.es (tomir.uib.es [ ]) by sello.uv.es (8.11.3/8.11.3) with ESMTP id f9U874g01189 for Tue, 30 Oct :07: Received: from uib.es ([ ]) by clust.uib.es (PMDF V #30169) with ESMTP id for Tue, 30 Oct :59:
40 Ejemplo 3º de correo (2/4) Email Date: Tue, 30 Oct 2001 08:59:08 +0100From: Gabriel Fuster Subject: [Fwd: CCNP 2001 / 2002 New call for CCNP Local academies] To: Santiago Felici Roberto Campos Message-id: Organization: UIB MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Win98; U) Content-type: multipart/mixed; boundary="Boundary_(ID_SLsnbrCR+H8votHJHMWN0Q)" X-Accept-Language: en This is a multi-part message in MIME format. --Boundary_(ID_SLsnbrCR+H8votHJHMWN0Q) Content-type: text/plain; charset=iso Content-transfer-encoding: 8BIT Os mando el mensaje de Michael. Saludos Gabriel Content-type: message/rfc822
41 Ejemplo 3º de correo (3/4) Email Return-path: [email protected]Received: from esclot.uib.es ([ ]) by clust.uib.es ... Date: From: Michael Furminger .... Subject: CCNP 2001 / 2002 New call for CCNP Local academies X-Sender: To: Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: multipart/mixed; boundary="Boundary_(ID_Z3rQcuHfhqevVCQtCHdMQw)" Original-recipient: --Boundary_(ID_Z3rQcuHfhqevVCQtCHdMQw) Content-type: text/plain; format=flowed; charset=iso Content-transfer-encoding: 8BIT Dear CATC main contact, I attach here something. Michael Content-type: application/octet-stream; x-mac-creator= C; x-mac-type=584C5334; name="CCNP EMEA EQUIPMENT ORDERING TEMPLATE OCT 01.xls" Content-disposition: attachment; filename="CCNP EMEA EQUIPMENT ORDERING TEMPLATE OCT 01.xls" Content-transfer-encoding: BASE64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAA
42 Ejemplo 3º de correo (4/4) EmailAAAAAAAAAAAAAAAAAAAAAAAAABcAAAAABAAAAAAAAA= --Boundary_(ID_Z3rQcuHfhqevVCQtCHdMQw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Michael Furminger Technology Manager, --Boundary_(ID_Z3rQcuHfhqevVCQtCHdMQw)-- --Boundary_(ID_SLsnbrCR+H8votHJHMWN0Q) Content-type: text/x-vcard; name=gfuster.vcf; charset=us-ascii Content-description: Card for Gabriel Fuster Content-disposition: attachment; filename=gfuster.vcf Content-transfer-encoding: 8BIT begin:vcard n:Fuster Martínez;Gabriel tel;cell: url:htp://www.uib.es end:vcard --Boundary_(ID_SLsnbrCR+H8votHJHMWN0Q)--
43 Seguridad Inicialmente, la seguridad no estaba incluida en Internet, pues el objetivo era extenderse en un ámbito de investigadores y universidades. Actualmente los temas de seguridad son importantes, ya que muchos impresentables hacen uso incorrecto de los servicios de Internet, tanto para sabotear nuestras cuentas (para lo cual se recomienda utilizar conexiones cifradas) como para infiltrar virus en el correo (para lo cual se recomienda no aceptar correo de remitente desconocido, así como en MS-Windows deshabilitar la opción de previsualización). También es aconsejable instalar antivirus que inspeccionen los buzones de correo, para evitar la propagación de virus entre usuarios. Se recomienda instalarse los parches de seguridad de los agentes.