Correo Electrónico
Protocolos SMTP, POP3 e IMAP
Email
1
Historia
• Los primeros sistemas de correo electrónico simplemente
consistían en protocolos de transferencia de archivos
– la primera línea 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
– RFC 821. Protocolo de transmisión SMTP
– 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.
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 línea en blanco)
Email
3
Arquitectura del sistema de correo (2/2)
• Funciones (o servicios) del sistema de correo:
– edición de mensajes
– transferencia
– generación de informes
• Subsistemas
• de distribución
(SMTP, ESMTP)
de transferencia
(demonios)
Agentes
• de entrega final
(POP3, IMAP)
de usuario
Email
Formato MIME
4
Agentes de transferencia
Estos agentes se clasifican en:
• de distribución:
– SMTP (Simple Mail Transfer Protocol) RFC 821
– SMTP extendido (ESMTP) RFC 1425
• de entrega final: que permita al usuario gestionar
su correo a través de una máquina remota
– POP3 (Post Office Protocol) RFC 1225
– IMAP (Interactive Mail Access Protocol) RFC 1064
Email
5
Agentes de transferencia de distribución (SMTP) (1/2)
El SMTP
• protocolo sencillo cliente/servidor
• formato ASCII
• Establecer comunicación 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 distribución (SMTP) (2/2): protocolo
El 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.
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.
Email
7
Comandos SMTP: cliente
Comando
HELO
MAIL FROM:
RCPT TO:
DATA
RSET
NOOP
QUIT
VRFY
EXPN
HELP
TURN
SOML
SAML
SEND
Descripción
Identifica el remitente al destinatario.
Identifica una transacción de correo e identifica al emisor.
identificar un destinatario individual . Si se necesita
Se utiliza para
identificar múltiples destinatarios es necesario repetir el comando.
Permite enviar una serie de líneas de texto. El tamaño máximo de una línea es
de 1.000 caracteres. Cada línea va seguida de un retorno de carro y avance de
ácter
línea <CR><LF>. La última línea debe llevar únicamente el car
punto "." seguido de <CR><LF>.
Aborta la transacción de correo actual.
No operación. Indica al extremo que envíe una respuesta positiva
.
Keepalives
Pide al otro extremo que envíe una respuesta positiva y cierre la conexión.
Pide al recep tor que confirme que un nombre identifica a un destinatario
valido.
Pide al receptor la confirmación de una lista de correo y que devuelva los
nombres de los usuarios de dicha lista.
Pide al otro extremo información sobre los comandos disponibl es.
El emisor pide que se inviertan los papeles , para poder actuar como receptor.
El receptor puede negarse a dicha petición.
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 buzón del destinatario. En caso de estar conectado
también lo hace al terminal.
Si el destinatario está conectado, entrega el mensaje directamente al terminal.
Email
8
Códigos de respuesta SMTP: servidor
C ód igo
211
214
220
221
250
251
354
421
450
451
452
500
501
502
503
504
550
551
552
553
554
D escrip ción
E stado del sistem a.
M ensaje de ayuda.
S ervicio prep arad o.
S ervicio cerran d o el can al d e transm isión .
S olicitu d com p letad a con éxito.
U suario no local, se enviará a < dirección de reenvío>
In trod u zca el texto, fin alice con < C R > < L F > .< C R > < L F > .
S ervicio no disponible.
S olicitud de correo no ejecutada, servicio no disponible (buzón ocupado).
A cción no ejecutada, error local de procesam iento.
A cción no ejecutada, insuficiente espacio de alm acenam iento en el sistem a.
E rror de sintaxis, com ando no reconocido.
E rror de sintaxis. P .ej con testación d e SM T P a E S M T P
C om ando no im plem entado.
S ecuencia de com andos errónea.
P arám etro no im plem entado.
S olicitud no ejecutada, buzó n no disponible.
U suario no local, pruebe < dirección de reenvío> . Si n o se tien e cu enta
A cción de correo solicitada abortada.
S olicitud no realizada (error de sintaxis).
F allo en la transacción.
Email
9
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 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
Email
12
Comentarios sobre SMTP (2/3): inconvenientes
• Algunas 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.
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,...}
Email
Bucle infinito
14
• Solución, 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, 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.
Email
15
Protocolos de entrega final de usuario (1/4)
Internet
PC emisor
conexión permanente
Agente de
transferencia
(SMTP)
Agente de
usuario
PC receptor
Problema: acceso no permanente a Internet
• a través de un ISP
• PC servidor
Email
16
Protocolos de entrega final de usuario (2/4)
Solución: un buzón en el servidor
conexión NO
permanente
conexión permanente
Internet
PC emisor
Agente de
transferencia
(SMTP)
POP3
Servidor
Agente de
usuario
PC receptor
(con buzón)
Problema: obtener correo del buzón
Solución: POP3
Email
17
Protocolos de entrega final de usuario (3/4)
El correo entrante en un cliente se puede realizar básicamente a
través de los siguientes protocolos:
POP3 (Post Office Protocol) RFC 1225  RFC 1939 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.
Puerto 110. Existen versiones actualmente, que ya permiten no
descargar el correo del buzón como IMAP.
IMAP (Interactive Mail Access Protocol) RFC 1064  RFC 2060. 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. Puerto 143.
Email
18
Protocolos de entrega final de usuario (4/4)
Ejemplo POP3
Email
19
Otras características de los agentes de
transferencia
• Pueden incorporar filtros o reglas cuando llega un correo
electrónico
• Pueden reenviar (relay) a una dirección diferente, por
ejemplo un teléfono móvil 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.
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 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.
Email
22
Formato de los mensajes RFC 822 (2/3)
Campos principales del RFC822:
C ab ecera
T o:
C c:
B cc:
F rom :
S ender:
R eceived:
R eturn -P ath:
D escrip ción
D ireccion es de em ail de los destinatarios prim ario s.
D ireccion es de em ail de los destinatarios secun darios. E n térm inos de
entrega no ex iste diferen cia con los destinatarios prim arios.
D ireccion es de em ail de las copia s al carbón ciegas. E s com o el cam po
anterior ex cepto que esta línea se borra de todas las copias enviadas a los
destinatarios prim arios y secundarios.
P ersona o person as que crearon el m ensaje.
D irección d e correo del rem itente. P uede o m itirse si es igual al cam po
anterior.
L ínea agregada p or cad a agen te d e tran sferen cia en la ru ta . La línea
contiene la identidad d el agente, la fech a y hora de recepción del m ensaje
y otra info rm ación que p uede servir p ara detectar fallos en el si stem a d e
enrutam iento. S e añ aden apiladas en la cab ecera, a m edida que se
intercam bia el em ail.
P uede usarse p ara id entificar una tra yectoria de regreso al rem itente.
Email
23
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.
C ab ecera
D ate:
R eply-T o:
D escrip ción
F ech a y hora de envío del m ensaje.
S e usa cu ando la person a que escribió el m ensaje y la que lo envió n o
desean ver la respuesta.
M essage-Id: N úm ero único para referencia posterior a este m ensaje. S uele estar
com puesto por un núm ero y la dirección d e em ail com pleta del usuario
que lo m anda.
In -R eply-T o: Id entificador d el m ensaje al que éste co rrespond e.
R eferen ces:
O tros identificadores de m ensaje.
K e yw ords:
C laves seleccion adas por el usuario.
S ubject:
R esum en co rto del m ensaje para ex hibir en una línea.
El RFC 822 explícitamente 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:
Subject:
To:
CC:
BCC:
Date:
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 electrónico
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 doméstica o personal deje a la vista las
direcciones de correo electrónico de sus destinatarios está
cometiendo una infracción multada hasta con 60.101,21
euros por la Ley Orgánica de Protección de Datos (LOPD)”
Email
27
MIME (Multipurpuse Internet Mail Extensions)
MIME o Extensiones multipropósito de correo Internet
El RFC 822 estaba pensado inicialmente para texto en ASCII 7 bits pero
aparecen:
•
•
•
•
Mensajes en idiomas con acentos (español, …).
Mensajes en alfabetos no latinos (hebreo y cirílico).
Mensajes en idiomas sin alfabetos (chino y japonés).
Mensajes que no contienen texto (audio y vídeo).
Problems!
Email
28
MIME (1/2)
MIME RFC 1341,1521 & 2045 mantienen 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.
Email
29
MIME (2/2): cabeceras de mensaje
Cabecera
MIME-Version:
Descripción
Identifica la version de MIME. Si no existe se considera
que el mensaje es texto normal en inglés.
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
estándar Message-Id.
Content-Transfer-Encoding: Indica la manera en que está envuelto el cuerpo del
mensaje.
Content-Type:
Especifica la naturaleza del cuerpo del mensaje.
Email
30
MIME: Content-Transfer-Encoding
Indica 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 básicos de codificación de mensajes
conocidos con el nombre de esquemas (esquemas de
codificación):
–
–
–
–
–
ASCII 7
ASCII 8
Codificación binaria
Base64
Entrecomillada-imprimible
Email
31
MIME: Content-Transfer-Encoding (1/3)
Esquemas de codificación
ASCII de 7 bits y ninguna línea exceda de 1000 caracteres
ASCII de 8 bits. Este esquema viola el protocolo original del
correo electrónico. Ninguna línea exceda de 1000
caracteres.
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.
Email
32
MIME: Content-Transfer-Encoding (2/3)
Esquemas de codificación
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 8 o 16 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.
Email
33
MIME: Content-Transfer-Encoding (3/3)
Esquemas de codificación
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.
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 más
subtipos. El tipo y el subtipo se separan
mediante un carácter 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:
T ip o
T ext
Im age
A udio
V ideo
A pplication
M essage
M ultipart
S u b tip o
P lain
R ichtext
G if
Jpeg
B asic
M peg
O ctet-stream
P ostscript
R fc822
P artial
E xternal-body
M ixed
A lternative
P arallel
D igest
D escrip ción
T exto sin form ato.
T exto con com andos d e form ato sencillos.
Im agen fija en form ato G IF .
Im agen fija en form ato JP E G .
S onido.
P elícula en form ato M P E G .
S ecuencia d e bytes no interpretada.
D ocum ento im prim ible P ostS cript.
M ensaje M IM E R F C 822.
M ensaje dividido para su transm isión.
E l m ensaje m ism o debe obtenerse d e la red.
P artes independientes en el orden esp ecificado.
M ism o m ensaje en diferentes form atos.
L as partes d eben verse sim ultáneam ente.
C ada parte es un m ensaje R F C 822 com pleto.
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 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
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 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.
• application / 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.
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 electrónico.
• 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
parámetros 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 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 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 más 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
codificación diferente.
• multipart/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
• 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:<[email protected]> SIZE=3531377
250 2.1.0 <[email protected]>... Sender ok
RCPT TO:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Message-ID: <[email protected]>
Date: Tue, 02 Jan 2007 13:22:12 +0100
From: "Francisco R. Soriano" <[email protected]>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: [email protected]
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 opción de
pre-visualizació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.
Email
42
Descargar

Correo Electrónico