Correo Electrnico

Protocolos SMTP, POP3 e IMAP

Email

Historia
Los primeros sistemas de correo electrnico simplemente consistan en protocolos de transferencia de archivos
la primera lnea del archivo contena la direccin del destinatario

Limitaciones de este sistema

envo a grupos sin notificacin

En 1982 se publicaron las propuestas de correo electrnico del ARPANET

RFC 821. Protocolo de transmisin SMTP RFC 822. Formato de mensaje

Dos aos despus, el CCITT elabor su recomendacin X.400, pero su excesiva complejidad, hace que no se utilice, como la mayora de aplicaciones OSI.
Email 2

Arquitectura del sistema de correo (1/2)

RFC821 Envoltura (cabecera antigua)
destino prioridad seguridad, etc,

RFC822 Contenido del mensaje

cabecera cuerpo
(separados por una lnea en blanco)

Email

Arquitectura del sistema de correo (2/2)

Funciones (o servicios) del sistema de correo:
edicin de mensajes transferencia generacin de informes

Subsistemas
de transferencia
(demonios)

de distribucin
(SMTP, ESMTP)

Agentes de usuario
Email

de entrega final
(POP3, IMAP)

Formato MIME
4

Agentes de transferencia
Estos agentes se clasifican en: de distribucin:
SMTP (Simple Mail Transfer Protocol) RFC 821 SMTP extendido (ESMTP) RFC 1425

de entrega final: que permita al usuario gestionar su correo a travs de una mquina remota
POP3 (Post Office Protocol) RFC 1225 IMAP (Interactive Mail Access Protocol) RFC 1064
Email 5

Agentes de transferencia de distribucin (SMTP) (1/2) El SMTP protocolo sencillo cliente/servidor formato ASCII Establecer comunicacin TCP al puerto 25
MTA Mail Transfer Agent Ejemplo de paquetes MTA son: Sendmail (www.sendmail.org) Smail Qmail (www.qmail.org) Exim ..
Email 6

Agentes de transferencia de distribucin (SMTP) (2/2): protocolo

El servidor comienza por enviar una lnea 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 conexin y lo intenta despus. b.- Si est dispuesto a aceptar correo electrnico, el cliente anuncia de quin viene el mensaje, y a quin est dirigido. Si existe tal destinatario en el destino, el servidor da al cliente permiso para enviar el mensaje. Entonces el cliente enva el mensaje y el servidor acusa su recibo. Si existe ms correo electrnico tambin se enva ahora. Una vez que todo el correo ha sido intercambiado en ambas direcciones, se libera la conexin.

Email

Comandos SMTP: cliente

Comando
HELO MAIL FROM: RCPT TO: DATA

Descripcin
Identifica el remitente al destinatario. Identifica una transaccin de correo e identifica al emisor. identificar un destinatario individual . Si se necesita Se utiliza para identificar mltiples destinatarios es necesario repetir el comando. Permite enviar una serie de lneas de texto. El tamao mximo de una lnea es de 1.000 caracteres. Cada lnea va seguida de un retorno de carro y avance de cter lnea <CR><LF>. La ltima lnea debe llevar nicamente el car punto "." seguido de <CR><LF>. Aborta la transaccin de correo actual. No operacin. Indica al extremo que enve una respuesta positiva . Keepalives Pide al otro extremo que enve una respuesta positiva y cierre la conexin. Pide al recep tor que confirme que un nombre identifica a un destinatario valido. Pide al receptor la confirmacin de una lista de correo y que devuelva los nombres de los usuarios de dicha lista. Pide al otro extremo informacin sobre los comandos disponibl es. El emisor pide que se inviertan los papeles , para poder actuar como receptor. El receptor puede negarse a dicha peticin. Si el destinatario est conectado, entrega el mensaje directamente al terminal, en caso contrario lo entrega como corr eo convencional. Entrega del mensaje en el buzn del destinatario. En caso de estar conectado tambin lo hace al terminal. Si el destinatario est conectado, entrega el mensaje directamente al terminal. Email

RSET NOOP
QUIT VRFY EXPN HELP TURN

SOML
SAML SEND

Cdigos de respuesta SMTP: servidor

Cdigo
211 214 220 221 250 251 354 421 450 451 452 500 501 502 503 504 550 551 552 553 554

Descripcin
Estado del sistema. Mensaje de ayuda. Servicio preparado. Servicio cerrando el canal de transmisin. Solicitud completada con xito. Usuario no local, se enviar a <direccin de reenvo> Introduzca el texto, finalice con <CR><LF>.<CR><LF>. Servicio no disponible. Solicitud de correo no ejecutada, servicio no disponible (buzn ocupado). Accin no ejecutada, error local de procesamiento. Accin no ejecutada, insuficiente espacio de almacenamiento en el sistema. Error de sintaxis, comando no reconocido. Error de sintaxis. P.ej contestacin de SMTP a ESMTP Comando no implementado. Secuencia de comandos errnea. Parmetro no implementado. Solicitud no ejecutada, buzn no disponible. Usuario no local, pruebe <direccin de reenvo>. Si no se tiene cuenta Accin de correo solicitada abortada. Solicitud no realizada (error de sintaxis). Fallo en la transaccin.

Email

Email

10

Email

11

Comentarios sobre SMTP (1/3)

La sintaxis de los comandos del cliente se especifica con rigidez. La sintaxis de las respuestas del servidor es menos rgida, slo cuenta el cdigo numrico, pudiendo cada implementacin del protocolo SMTP poner la cadena de texto que desee despus del cdigo numrico

Email

12

Comentarios sobre SMTP (2/3): inconvenientes

Algunas implementaciones ms 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 contina trabajando, terminando inesperadamente la conexin.
Email 13

Comentarios sobre SMTP (3/3): inconvenientes

En ocasiones pueden dispararse tormentas de correo infinitas cuando ambos servidores mutuamente tienen una lista que incluye a la otra lista del otro servidor. Servidor X List A={...,Lista B,...} Servidor Y Lista B={...,Lista A,...}
Bucle infinito

Email

14

 Solucin, un nuevo protocolo extendido: SMTP extendido (ESMTP) en el RFC 1425. Los clientes que deseen usarlo deben enviar un mensaje EHLO, en lugar de HELO. Si el saludo se rechaza, cdigo 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.

Email

15

Protocolos de entrega final de usuario (1/4)

Internet PC emisor
conexin permanente

Agente de transferencia (SMTP)

Agente de usuario

PC receptor

Problema: acceso no permanente a Internet a travs de un ISP PC servidor

Email 16

Protocolos de entrega final de usuario (2/4)

Solucin: un buzn en el servidor
conexin permanente Agente de transferencia (SMTP) conexin NO permanente

Internet
PC emisor

POP3

Agente de usuario

Servidor
(con buzn)

PC receptor

Problema: obtener correo del buzn Solucin: POP3

Email 17

Protocolos de entrega final de usuario (3/4)

El correo entrante en un cliente se puede realizar bsicamente a travs de los siguientes protocolos: POP3 (Post Office Protocol) RFC 1225 RFC 1939 tiene comandos para que un usuario establezca una sesin (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 electrnico del buzn remoto y almacenarlo en la mquina local del usuario para su lectura posterior. Puerto 110. Existen versiones actualmente, que ya permiten no descargar el correo del buzn como IMAP. IMAP (Interactive Mail Access Protocol) RFC 1064 RFC 2060. La idea en que se basa IMAP es que el servidor de correo electrnico mantenga un depsito central al que puede accederse desde cualquier mquina. Por tanto, a diferencia del POP3, no copia el correo electrnico en la mquina personal del usuario dado que el usuario puede tener varias computadoras para consultar el correo, y observa si sus correos han sido ledos con anterioridad. Puerto 143.
Email 18

Protocolos de entrega final de usuario (4/4) Ejemplo POP3

Email

19

Otras caractersticas de los agentes de transferencia

Pueden incorporar filtros o reglas cuando llega un correo electrnico Pueden reenviar (relay) a una direccin diferente, por ejemplo un telfono mvil con SMS, o a otro servidor de correo. Permiten generar una contestacin automtica, por ejemplo cuando estamos de vacaciones: Estoy de vacaciones. Regresar el 15 de Agosto. Que tenga feliz da Cuando activemos este mecanismo es mejor desuscribirse de las listas de correo, ya que inundaramos la lista con esta contestacin.
Email 20

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.

Email

21

Formato de los mensajes RFC 822 (1/3)

Los mensajes con formato RFC 822 estn formados por una envoltura primitiva (descrita en el RFC 821), algunos campos de cabecera, una lnea en blanco, y el cuerpo del mensaje. Cada campo de cabecera consiste en una sola lnea de texto ASCII que contiene el nombre del campo, dos puntos (:) y, para la mayora de los campos un valor.
Email 22

Formato de los mensajes RFC 822 (2/3)

Campos principales del RFC822:
Cabecera To: Cc: Descripcin Direcciones de email de los destinatarios primarios. Direcciones de email de los destinatarios secundarios. En trminos de entrega no existe diferencia con los destinatarios primarios. Bcc: Direcciones de email de las copias al carbn ciegas. Es como el campo anterior excepto que esta lnea se borra de todas las copias enviadas a los destinatarios primarios y secundarios. From: Persona o personas que crearon el mensaje. Sender: Direccin de correo del remitente. Puede omitirse si es igual al campo anterior. Received: Lnea agregada por cada agente de transferencia en la ruta. La lnea contiene la identidad del agente, la fecha y hora de recepcin del mensaje y otra informacin que puede servir para detectar fallos en el sistema de enrutamiento. Se aaden apiladas en la cabecera, a medida que se intercambia el email. Return-Path: Puede usarse para identificar una trayectoria de regreso al remitente.
Email 23

Formato de los mensajes RFC 822 (3/3)

Adems, los mensajes RFC 822 pueden contener una variedad de campos auxiliares de cabecera usados por los agentes de usuario o los destinatarios.
Cabecera Date: Reply-To: Descripcin Fecha y hora de envo del mensaje. Se usa cuando la persona que escribi el mensaje y la que lo envi no desean ver la respuesta. Message-Id: Nmero nico para referencia posterior a este mensaje. Suele estar compuesto por un nmero y la direccin de email completa del usuario que lo manda. In-Reply-To: Identificador del mensaje al que ste corresponde. References: Otros identificadores de mensaje. Keywords: Claves seleccionadas por el usuario. Subject: Resumen corto del mensaje para exhibir en una lnea.

El RFC 822 explcitamente indica que los usuarios pueden inventar cabeceras nuevas para uso privado siempre y cuando comiencen con la cadena X-.
Email 24

Lo que yo he enviado
From: To: CC: BCC: Date:

Subject:

X-cabeceras de uso privado:

Email

25

Lo que yo he recibido
No est el campo BCC (o CCO)

Email

26

Noticia del 23 de febrero de 2007 Multa de 600 euros por dejar a la vista 42 direcciones de correo electrnico Cuidado al mandar mensajes masivos: utiliza el campo CCO Da igual que sea un despiste, pero todo aquel que en una actividad que no sea domstica o personal deje a la vista las direcciones de correo electrnico de sus destinatarios est cometiendo una infraccin multada hasta con 60.101,21 euros por la Ley Orgnica de Proteccin de Datos (LOPD)

Email

27

MIME (Multipurpuse Internet Mail Extensions)

MIME o Extensiones multipropsito de correo Internet
El RFC 822 estaba pensado inicialmente para texto en ASCII 7 bits pero aparecen:

Mensajes en idiomas con acentos (espaol, ). Mensajes en alfabetos no latinos (hebreo y cirlico). Mensajes en idiomas sin alfabetos (chino y japons). Mensajes que no contienen texto (audio y vdeo).

Problems!
Email 28

MIME (1/2)
MIME RFC 1341,1521 & 2045 mantienen la idea bsica de continuar usando el RFC 822, pero permite agregar una estructura al cuerpo del mensaje y definir reglas de codificacin para los mensajes no ASCII. MIME slo afecta a los agentes de usuario, ya que para SMTP es totalmente transparente. Nada cambia respecto a la arquitectura de correo anterior.
Email 29

MIME (2/2): cabeceras de mensaje

Cabecera MIME-Version: Descripcin Identifica la version de MIME. Si no existe se considera que el mensaje es texto normal en ingls. Content-Description: Cadena de texto que describe el contenido. Esta cadena es necesaria para que el destinatario sepa s i desea descodificar y leer el mensaje o no. Content-Id: Identificador nico, usa el mismo formato que la cabecera estndar Message -Id. Content-Transfer -Encoding: Indica la manera en que est envuelto el cuerpo del mensaje. Content-Type: Especifica la n aturaleza del cuerpo del mensaje.

Email

30

MIME: Content-Transfer-Encoding
Indica la manera en que est envuelto el cuerpo para su transmisin, ya que podra haber problemas con la mayora de los caracteres distintos de letras, nmeros y signos de puntuacin. Existen 5 tipos bsicos de codificacin de mensajes conocidos con el nombre de esquemas (esquemas de codificacin):
ASCII 7 ASCII 8 Codificacin binaria Base64 Entrecomillada-imprimible
Email 31

MIME: Content-Transfer-Encoding (1/3) Esquemas de codificacin

ASCII de 7 bits y ninguna lnea exceda de 1000 caracteres ASCII de 8 bits. Este esquema viola el protocolo original del correo electrnico. Ninguna lnea exceda de 1000 caracteres. Binaria. Utilizan los 8 bits y no respetan el lmite de 1000 caracteres por lnea. Los programas ejecutables caen en esta categora. No se da ninguna garanta de que los mensajes en binario llegarn correctamente.

Email

32

MIME: Content-Transfer-Encoding (2/3) Esquemas de codificacin

Base64 o armadura ASCII. En este esquema, se dividen grupos de 24 bits en unidades de 6 bits (26 maysculas, 26 minsculas, 10 dgitos y + y / de forma A es 0, B es 1, ...,a es 26,... ), envindose cada unidad como carcter ASCII legal. Las secuencias == y = se usan para indicar que el ltimo grupo contena solo 8 o 16 bits, respectivamente.
Los retornos de carro y avances de lnea se ignoran, por lo que pueden introducirse a voluntad para mantener la lnea lo suficientemente corta.
Email 33

MIME: Content-Transfer-Encoding (3/3) Esquemas de codificacin

Entrecomillada-imprimible (QUOTED-PRINTABLE). sta codificacin es ASCII de 7 bits, con todos los caracteres por encima de 127 codificados como un signo de igual seguido del valor del carcter en dos dgitos hexadecimales. Se utiliza en el caso de mensajes que son casi completamente ASCII, pero con algunos caracteres no ASCII. En este caso la codificacin base64 es algo ineficiente.

Content-Type: text/plain; charset=iso8859-1 Content-Disposition: inline Content-Transfer-Encoding: quotedprintable el s=E1bado 13 de diciembre a las 17:18 me escribiste: > Alguien me facilitaria un programita de ejemplo de un servidor usando=20 > UDP? Email 34

MIME: Content-Type

Content-Type especifica la forma del cuerpo del mensaje. Existen 7 tipos iniciales definidos en el RFC 1521 (ahora 2045), cada uno de los cuales tiene uno o ms subtipos. El tipo y el subtipo se separan mediante un carcter diagonal (/), ej: Content-Type: video/mpeg
Email 35

MIME: Content-Type : tipos y subtipos

La lista inicial de tipos y subtipos que fue especificada por el RFC 1521 es:
Tipo Text Image Audio Video Application Message Subtipo Plain Richtext Gif Jpeg Basic Mpeg Octet-stream Postscript Rfc822 Partial External-body Mixed Alternative Parallel Digest Descripcin Texto sin formato. Texto con comandos de formato sencillos. Imagen fija en formato GIF. Imagen fija en formato JPEG. Sonido. Pelcula en formato MPEG. Secuencia de bytes no interpretada. Documento imprimible PostScript. Mensaje MIME RFC 822. Mensaje dividido para su transmisin. El mensaje mismo debe obtenerse de la red. Partes independientes en el orden especificado. Mismo mensaje en diferentes formatos. Las partes deben verse simultneamente. Cada parte es un mensaje RFC 822 completo.

Multipart

Se han agregado muchos otros desde entonces y se agregan nuevas entradas a medida que surge la necesidad
Email 36

MIME: Content-Type: tipo text

text/plain es para mensajes ordinarios que pueden visualizarse como se reciben, sin codificacin ni ningn procesamiento posterior text/richtext permite la inclusin de un lenguaje de marcacin sencillo en el texto (para indicar negritas, cursivas, tamaos ... Independiente del sistema). Utiliza el lenguaje
SGML (Standard Generalized Markup Language), tambin usado como base del HTML

Uso de negrita
Email 37

MIME: Content-Type: tipo application

El tipo application es un tipo general para los formatos que requieren procesamiento externo no cubierto por ninguno de los otros tipos. application /octet-stream simplemente es una secuencia de bytes no interpretados, tal que a su recepcin, un agente de usuario debera presentarla en la pantalla sugiriendo al usuario que se copie en un archivo y solicitando un nombre de archivo. application / postscript, se refiere al lenguaje PostScript de Adobe Systems. Aunque un agente de usuario puede llamar a un intrprete PostScript externo para visualizarlo, hacerlo no est exento de riesgos al ser PostScript un lenguaje de programacin completo.

Email

38

MIME: Content-Type: tipo message El tipo message permite que un mensaje est encapsulado por completo dentro de otro. Este esquema es til para reenviar, correo electrnico. message/rfc822 se utiliza cuando se encapsula un mensaje RFC 822 completo en un mensaje exterior. message/partial hace posible dividir un mensaje encapsulado en pedazos y enviarlos por separado. Los
parmetros hacen posible ensamblar correctamente todas las partes en el destino. Ej: 1/3, 2/3, 3/3.

message/external-body puede usarse para mensajes muy grandes, por ejemplo pelculas de vdeo. En lugar de incluir el archivo mpeg en el mensaje, se da una direccin de FTP y el agente de usuario del receptor puede obtenerlo a travs de la red cuando se requiera.
RECORDATORIO: no est bien mandar ficheros excesivamente grandes por e-mail. Usar FTP.
Email 39

MIME: Content-Type: tipo multipart

El tipo es multipart, que permite que un mensaje contenga ms de una parte, con el comienzo y el fin de cada parte claramente delimitados.
multipart/mixed permite que cada parte sea diferente. multipart/alternative indica que cada parte contiene el mismo mensaje, pero expresado en un medio o codificacin diferente. multipart/parallel se usa cuando todas las partes deben verse simultneamente, por ejemplo, en los canales de audio y vdeo de las pelculas multipart/digest se usa cuando se juntan muchos mensajes en un mensaje compuesto. Email 40

220 post.uv.es ESMTP UV Sendmail 8.13.4/8.13.4; Tue, 2 Jan 2007 13:22:13 +0100 EHLO [147.156.222.23] 250-post.uv.es Hello paquito.irobot.uv.es [147.156.222.23], pleased to meet you MAIL FROM:<francisco.r.soriano@uv.es> SIZE=3531377 250 2.1.0 <francisco.r.soriano@uv.es>... Sender ok RCPT TO:<soriano@glup.uv.es> 250 2.1.5 <soriano@glup.uv.es>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Message-ID: <459A4E74.7010407@uv.es> Date: Tue, 02 Jan 2007 13:22:12 +0100 From: "Francisco R. Soriano" <francisco.r.soriano@uv.es> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: soriano@glup.uv.es Subject: prueba2 Content-Type: multipart/mixed; Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Correo de prueba Content-Type: video/mpg; name="Berlitz.mpg" Content-Transfer-Encoding: base64

Email

41

Seguridad
Inicialmente, la seguridad no estaba incluida, pues el objetivo era extenderse en un mbito de investigadores y universidades. Actualmente los temas de seguridad son importantes. Se hace uso incorrecto de los servicios de Internet, tanto para sabotear nuestras cuentas (para lo cual se recomienda utilizar conexiones cifradas) como para enviar virus en el correo (por lo cual se recomienda no aceptar correo de remitente desconocido, as como deshabilitar la opcin de pre-visualizacin). Tambin es aconsejable instalar antivirus que inspeccionen los buzones de correo, para evitar la propagacin de virus entre usuarios. Se recomienda instalarse los parches de seguridad de los agentes.
Email 42