Simple Mail Transfer Simple Mail Transfer Protocol

SMTP
Simple Mail Transfer Protocol
SMTP
• Simple Mail Transfer Protocol
• Base del transporte de correo electrónico. Ya no es más el sistema de
mensajería más utilizado.
• 1981. SMTP fue ideado para entrega de correo electrónico entre máquinas
con capacidad SMTP en Internet.
• La idea principal era permitir la transferencia sin que el receptor estuviera
presente. Se hablaba de una transmisión retardada: Tx en cualquier
momento, Rx por decisión => Desacople entre ambos procesos.
• Inicialmente la máquina transmisora debía indicar la ruta para la entrega. Hoy
se basa en DNS.
• Inicialmente sólo se transferían mensajes de texto. Hoy se pueden transferir
todo tipo de mensajes y archivos.
Topología básica
.
Message
Transfer
Agent
Message
Transfer
Agent
User
Agent
User
Agent
User
Agent
Topología
.
MTA
mail.mi-servidor.com.ar
MTA
mail.otro-servidor-remoto.com.ar
SMTP (TCP)
mail.servidor-remoto.com.ar
SMTP (TCP)
MTA
POP3
IMAP4
(TCP)
[email protected]
•Eudora
•The Bat!
•Thunderbird
•Outlook
•…
Cliente
Telnet
UA
POP3
IMAP4
(TCP)
•Sendmail
•Postfix
•Qmail
•…
UA
[email protected]
UA
[email protected]
SMTP – Proceso de comunicación – Entrega indirecta
1. Crear mensaje (Formato RFC 822 + MIME).
El mensaje: header (descriptivo del mensaje, controla procesamiento y
entrega)+ body (el mensaje propiamente dicho).
2. Enviar el mensaje al Servidor SMTP local (Protocolo SMTP, RFC 821).
3. Entregar mensaje . Sistema SMTP local del Tx realiza una consulta al servicio
DNS para hallar el registro MX del sitio de entrega de mail. Conexión SMTP
sobre TCP entre Servidor Local y Servidor remoto. Puerto 25.
4. Recepción y procesamiento del mensaje. El Servidor del sitio receptor coloca el
mail en un buzón del destinatario, a la espera de que éste lo lea.
5. Acceso y Recuperación. El destinatario muestrea su buzón a demanda,
mediante protocolo POP/IMAP que le permite mirar encabezados y remitentes
antes de abrir los mensajes.
• SMTP para transporte y entrega. POP para acceso al buzón.
SMTP – Direcciones de e-mail
•
Comunicación orientada al usuario. No es del tipo (Dir IP:Nº de puerto), sino
del tipo (Who: Where).
•
<username>@<domainname>. Es un esquema menos restrictivo, con
sintaxis DNS. Debe ser genérico y representativo, no un Servidor o una
máquina, ya que un sitio puede contar con más de un Servidor por asuntos de
balance de carga.
•
El registro MX de DNS permite especificar el Servidor de Correo de un dominio.
•
De este modo no se usan relays intermedios.
•
El sistema permite usar alias, armar agendas de direcciones y crear listas
especificando múltiples receptores.
Formato de Mensajes – RFC 822 y MIME
•
Los mensajes RFC 822 tienen un formato bien definido.
•
•
•
Se trata de líneas de texto ASCII que se usan inclusive para los encabezados.
Cada línea finaliza con CRLF.
Cada línea debería ser de 78 caracteres o menos y no debe superar los 998
caracteres. Los caracteres CR y LF no deben aparecer en el texto.
•
Los mensajes comienzan con un conjunto de líneas que conforman el
encabezado. Se compone de headers, expresados en el formato <header
name>: <header value>. Este formato hace que los mensajes sean
explicativos casi por sí mismos.
Luego de los encabezados aparece una línea en blanco (dos caracteres CRLF
consecutivos). Es un indicador del comienzo del cuerpo del mensaje.
El cuerpo del mensaje también consta de líneas de caracteres ASCII con los
límites previamente mencionados.
Todo es muy sencillo pero limitado a texto en inglés. Por eso surgió MIME
•
•
•
Formato de Mensajes – Grupos de encabezados
•
Campo de Fecha de Origen. Date:
•
Campos de Originador. From: dirección, Sender: nombre,
dirección
•
Campos de Dirección Destino. To: Cc: Bcc:
•
Campos de Identificación.
References: otros mensajes.
•
Campos de Información. Subject: Comments: Keywords:
Message-ID:
In-Replay-To:
Replay-To:
message-ID
• Campos de Re-envío. Resent-Date: Resent-From: Resent-Sender:Resent-To:
Resent-Cc: Resent-Bcc: Resent-Message-ID:
•
Campos de Traza. Received: Return-Path:
Formato de Mensajes
•
•
•
El estándar define un objeto de correo: mensaje + sobre.
El sobre contiene toda la información para transporte.
El mensaje es lo que hemos visto hasta ahora: encabezados y cuerpo.
•
SMTP sólo mira el sobre cuando debe decidir cómo enviar un mensaje.
•
No es lo mismo el sobre que los encabezados del mensaje. El sofware que
procesa e interpreta el mensaje, puede construir el sobre para transporte de
SMTP.
envelope
header
body
Formato de Mensajes - MIME
•
•
RFC 822 no provee flaxibilidad para soporte de información multimedia o
archivos arbitrarios o idiomas diferentes.
Multipurpose Internet Mail Extensions (MIME) fue creado por ese motivo.
•
MIME define hasta una estructura que permite codificar múltiples archivos
diferentes en un único mensaje de correo.
•
Usa reglas de codificación especiales que transforman un archivo noASCII a formato ASCII.
•
Se agregan headers al mensaje. Los headers indica la forma de codificación
utilizada.
El programa de presentación de mail debe tener soporte MIME.
RFC 2045 a RFC 2049.
Premisa 1: Cuerpo de mensaje RFC 822 puede cargar cualquier tipo de texto
ASCII respetando la limitación de 998 caracteres y fin “CRLF”.
Premisa 2: RFC 822 facilita la creación de headers del tipo “user-defined”.
•
•
•
•
Formato de Mensajes - MIME
•
Tipos de Estructuras Básicas
Estructura Simple (Discrete Media): por ejemplo texto o imágenes, sólo llevan
un tipo de codificación simple.
Estructura Compleja (Composite Media): varios tipos de mezclados, el
mensaje contiene varias partes MIME.
•
Entidades MIME
Tanto los mensajes MIME completos como sus partes individuales se
denominan entidades MIME. Cada conjunto de encabezados MIME provee
información sobre la entidad, ya sea el mensaje completo o cada una de sus
partes si es compuesto. En la recepción, primero se analizan los del todo, que
indican si la estructura es simple o compleja. En el último caso, se procede a
analizar las partes componentes.
Formato de Mensajes – Headers MIME Primarios
•
MIME-Version, por ahora 1.0. Quiere decir mensaje codificado en MIME
•
Content-Type, describe la naturaleza de los datos de la entidad, especificando
tipo y subtipo. En el cuerpo del mensaje, le dice al receptor qué clase de
medios contiene y si es estructura simple o compleja. Por ejemplo:
“multipart/mixed” or “multipart/alternative”. En una parte del cuerpo, la describe.
Por ejemplo: “text/html”, “image/jpeg”. Es opcional, si no estuviera presente se
asume US-ASCII RFC 822.
•
Content-Transfer-Encoding, puede referirse al todo o a cada una de sus
partes. Es opcional y su default es US- ASCII.
•
Content-ID, código de referencia, opcional.
•
Content-Description, opcional, texto descriptivo.
Formato de Mensajes – Headers MIME Adicionales
•
Content-Disposition, en MIME multiparte se puede especificar en cada parte
cómo presentar la información al usuario. Por ejemplo: “inline” (presentación
automática junto con el resto de las partes) o “attachment” (separado del
documento principal).
•
Content-Location, permite identificar localización con URI, por ejemplo cuando
se habilita codificación HTML.
•
Content-Length, en bytes. Importante en HTTP.
Content –Type y Medios Discretos
•
•
•
•
•
•
•
•
La sintaxis de Content-Type es <type>/<subtype> [; parameter1 ; parameter2
.. ; parameterN ]
La descripción va de lo general a lo específico. “<type>” y “<subtype>” son
obligatorios. Los parámetros son opcionales y ofrecen una descripción aún más
detallada del tipo attribute=value
Por ejemplo:
Content-type: text/plain; charset=“us-ascii”
Content-type: image/jpeg; name=“ryanpicture.jpg”
text/plain; text/enriched; text/html; text/css;
image/jpeg; image/gif; image/tiff; image/vnd.dwg; image/vnd.dxf; image/vnd.svf
audio/basic; audio/mpeg
video/mpeg; video/dv; video/quicktime
application/octet-stream;
application/postscript;
application/applefile;
application/msword;
application/pdf;
application/vnd.lotus-1-2-3;
application/vnd.ms-excel; application/vnd.ms-powerpoint; application/vnd.msproject; application/zip
Medios Compuestos tipo Multipart
•
•
•
•
Multipart Media Type (multipart): Uno o más conjuntos de datos dentro de un
mensaje MIME. Cada uno se representa por un tipo discreto.
Message Media Type (message): Permite que un mensaje encapsule a otro,
que puede ser otro e-mail.
Subtipos Multipart Message:
multipart/mixed (no relacionados pero en el mismo mensaje);
multipart/alternative (representaciones alternativas); multipart/parallel (mostrar
al
mismo
tiempo);
multipart/digest
(apéndices);
multipart/related;
multipart/encrypted.
Multipart Message Encoding
Cada parte individual se procesa como si fuese a ser transmitida como el
cuerpo de un tipo de mensaje MIME discreto. Esto incluye la especificación de
Content-Type, Content-ID y Content-Transfer-Encoding. Para separar las
partes, se utiliza un delimitador especial (string aleatorio que comienza con “--”.
Luego se ensambla el mensaje: preámbulo texto/ línea delimitadora/ primera
parte/ línea delimitadora/…./ última parte/ línea delimitadora/ texto final.
Medios Compuestos tipo Multipart
From: Joe Sender <[email protected]>
To: Jane Receiver <[email protected]>
Date: Sun, 1 Jun 2003 13:28:19 —0800
Subject: Photo and discussion
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="exampledelimtext123"
This is a multipart message in MIME format
—exampledelimtext123
Content-Type: text/plain
Jane, here is the photo you wanted me for the new client.
Here are some notes on how it was processed.
(Blah blah blah…)
Talk to you soon,
Joe.
—exampledelimtext123
Content-Type: image/jpeg; name="clientphoto.jpg"
Content-Transfer-Encoding: base64
SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs
•
…
zv/wAARCADIARoDASIAAhEBAxEB/8QAHAAAAQUBA
—exampledelimtext123
(Epilogue)
Medios Compuestos tipo Mensaje Encapsulado
•
También tiene subtipos:
message/rfc822: Encapsula un mail con formato RFC 822. Podría ser un
mensaje MIME.
message/partial: Permite fragmentar mensajes largos que luego pueden reensamblarse.
message/external-body: Provee una referencia para la localización del cuerpo
del mensaje.
Content--Transfer
Content
Transfer--Encoding
•
Restricciones RFC 822: Codificación US ASCII (representación en 7 bits),
Límite de línea 1000 caracteres incluyendo “CRLF”.
•
Genera problemas para datos binarios: video, archivo mp3, ejecutables, etc. =>
Métodos de Codificación MIME => Header Content-Transfer-Encoding.
•
7bit: Compatible ASCII RFC 822. Es el default que se asume cuando no está el
header.
•
8bit / binary: RFC 1652 con extensión SMTP para 8bit-MIMEtransport.
•
quoted-printable: Cuando la mayoría de los datos son texto ASCII, pero
existen violaciones a las reglas RFC 822 (por ejemplo acentos), para que sea
consistente con RFC 822.
•
base64: Para datos binarios, se codifican en fomato ASCII.
Content--Transfer
Content
Transfer--Encoding – base 64
6-bit
Value
Encoding
6-bit
Value
Encoding
6-bit
Value
Encoding
6-bit
Value
Encoding
0
A
16
Q
32
g
48
w
1
B
17
R
33
h
49
x
2
C
18
S
34
i
50
y
3
D
19
T
35
j
51
z
4
E
20
U
36
k
52
0
5
F
21
V
37
l
53
1
6
G
22
W
38
m
54
2
7
H
23
X
39
n
55
3
8
I
24
Y
40
o
56
4
9
J
25
Z
41
p
57
5
10
K
26
a
42
q
58
6
11
L
27
b
43
r
59
7
12
M
28
c
44
s
60
8
13
N
29
d
45
t
61
9
14
O
30
e
46
u
62
+
15
P
31
f
47
v
63
/
3 bytes -> 4 palabras de 6 bits ->tabla => 4 char ASCII
Extensiones MIME para Headers no ASCII
•
Por ejemplo para Subject en lenguaje distinto del inglés.
•
•
•
•
•
El header normal se reemplaza por una palabra
=?<charset>?<encoding>?<encoded-text>?=
“=?” y “?=” encierran el header non-ASCII e indican la codificación.
<charset>: por ejemplo “iso-8859-1”.
<encoding>: “B” es base64 y “Q” quoted-printable.
<encoded-text>: es el texto codificado.
•
Por
ejemplo:
Subject:
codificada:
=?UTF-8?Q?aprobaci=C3=B3n=20de=20edici=C3=B3n?=
SMTP – Proceso de comunicación
SMTP - Transacción
Sesión SMTP
Al estar montado sobre una conexión TCP al puerto 25, se inicia con three-way handshake
220 mail.mi-servidor.com.ar (E)SMTP (Sendmail/Postfix/etc. 4-oct)
>>> HELO mi-maquina (EHLO)
250 mail.mi-servidor.com.ar HELLO mi-maquina
>>> MAIL From: <[email protected]>
250 … Sender ok
>>> RCPT To: <[email protected]>
250 … Recipient ok
>>> DATA
354 Enter data; end with “.” (<CR><LF>. <CR><LF>)
>>> Message body
… (aca van la cabecera y los datos!)…
250 ok Mail accepted
>>> QUIT
221 Ok Bye
se cierra la conexión TCP en ambas direcciones
SMTP – Cliente y Servidor
•
Servidor códigos numéricos de 3 cifras
• se inician con cifras del 1 (obsoleto) al 5: abc
• a=2: ok!
• a=3: vamos bien, pero faltan cosas
• a=4: falla temporal recuperable
• a=5: error critico
•
Cliente comandos de 4 letras
• los más comunes son 5
• MAIL, RCPT, DATA, QUIT, HELO, EHLO
• Otros: TURN, RSET, VRFY, EXPN, AUTH, SIZE
TURN: intercambia roles C y S, sin caer la conexión TCP
RSET: aborta el mail en curso, y borra toda info almacenada
NOOP: solo fuerza al mail server a contestar con Ok (200)
VRFY: el cliente consulta al server la existencia del destinatario, SIN mandar
mensaje
AUTH, SIZE son extensiones
•
•
•
•
•
ESMTP
•
Cambios en envelope: Extensiones sobre SMTP (ESMTP, extended…)
• La sesión se inicia con EHLO (a diferencia del HELO), si el MTA me invitó con ESMTP
• El MTA responde 250 (Ok) y envía su conjunto de extensiones
• 250-PIPELINING
• 250-SIZE xxxxxxxx
• 250-VRFY
• 250-ETRN
• 250-AUTH
• 250-ENHANCEDSTATUSCODES
• 250-8BITMIME
• 250-DSN
• 250-XADR
• 250-STARTLS
• 250-DELIVERBY
• 250-EXPN
• 250 HELP
Extensiones SMTP => ESMTP
PIPELINING = reduce el tiempo de enviar varios mensajes, al no esperar confirmaciones a comandos
uno a uno (p.ej. si la red está lenta)
SIZE xxxxxxxx = tamaño del mensaje que soporta el server. O lo especifica el server, o lo manifiesta el
cliente previo al envío.
AUTH (authentication)
LOGIN => Username - Ok (250)/Password - Ok (250); (codif. base64)
CRAM-MD5 => encripta username y password (Eudora)
PLAIN => “0username0password” – Ok (250); (codif. base64)
DSN (delivery status notification)
failed / delayed / succesfull / relayed
CHECKPOINT (RESTART) = puntero por posible interrupción; retoma la transferencia desde el punto
marcado por el corte.
ETRN (extended TURN- QSND) permite que un mail server solicite a otro/s el envío de mails. Se suele
aplicar cuando un host no está conectado permanentemente.
ENHANCEDSTATUSCODES (codificación numérica del mailserver, con mas opciones. Se mantiene el
formato de 3 cifras; RFC 1893)
8BITMIME (usa 8 bits p/byte, lo cual permite interpretar MIME)
STARTTLS (transport layer security) conexión segura / (vers. 1.1)
DELIVERBY (enviar dentro de los nn seg.); “Mail From: <[email protected]> BY=600”
POP3 - Post Office Protocol, versión 3
•
SMTP se encarga del envío de e-mail hasta el buzón del receptor.
•
La recuperación del mensaje desde el buzón a la máquina del cliente se realiza
con otros protocolos.
•
Post Office Protocol (POP) e Internet Message Access Protocol (IMAP).
•
POP es el más popular. Se basa en un modelo de acceso offline para recuperar
correo del servidor SMTP. Es muy sencillo, de pocos comandos, su versión actual
es la 3, de ahí su nombre POP3.
•
POP3: Modelo C-S; C: Eudora, Microsoft Outlook, etc; S: puerto 110. Conexión
TCP. Comandos C->S texto ASCII finaliza con CRLF. Respuestas S->C: +OK/-ERR.
Máquina de Estados.
POP3 - Autorización
POP3 - Transacción
STAT
Requerimiento de información de estado
de buzón (Número de mensajes, y bytes
de cada mensaje)
LIST
Lista información sobre los mensajes en el
buzón (Número de mensaje y tamaño)
RETR
Para bajar un mensaje del buzón.
DELE
Marca un mensaje para borrar, luego LIST
o RETR darían error.
NOOP
RSET
TOP
Para obtener sólo encabezados y las
primeras N líneas especificadas.
POP3
Internet Message Access Protocol (IMAP4)
Con POP3 la lectura de
los mensajes se realiza
luego
de
su
recuperación, en la
máquina del C.
IMAP provee mayor
funcionalidad.
IMAP4 se basa en el
modelo C-S. El S debe
encontrarse en el
mismo S donde se
alojan los buzones.
IMAP4 usa TCP. El
servidor escucha en el
puerto 143.
IMAP – Códigos Resultado
OK: Resultado positivo, usualmente se acompaña de la etiqueta del
comando.
NO: Resultado negativo, si no se etiqueta se debe interpretar como
mensaje de advertencia sobre alguna situación en el servidor.
BAD: Indica mensaje de error.
PREAUTH: Mensaje no etiquetado que se envía al comienzo de una
sesión para indicar que no es necesario autenticarse.
BYE: Servidor a punto de cerrar la sesión, en respuesta al comando
para logout.
IMAP – Códigos Respuesta
ALERT: Información a C sobre algo importante.
BADCHARSET: Conjunto de caracteres no soportado.
CAPABILITY: Listado.
PARSE: Error durante la separación de headers o contenido MIME.
PERMANENTFLAGS: Lista de banderas de estado de mensajes, que el
C puede manipular.
READ-ONLY: Modo de acceso a buzón.
READ-WRITE: Modo de acceso a buzón.
TRYCREATE: Cuando comandos APPEND o COPY fallan por
inexistencia de buzón.
UIDNEXT: Enviado con un número que especifica el siguien¡ente ID a
usar en una operación.
UIDVALIDITY: Usado para confirmar el ID.
UNSEEN: Enviado con número que le dice al C el mensaje marcado
como no leído.
IMAP – Comandos No Autenticado
Command
LOGIN
AUTHENTICATE
STARTTLS
Parameters
User name and password
Authentication mechanism
name
None
IMAP – Comandos Autenticado
SELECT
Mailbox name
Si existoso, transición a SELECTED
EXAMINE
Mailbox name
Buzón se abre en modo read-only.
CREATE
DELETE
RENAME
LIST
Mailbox name
Mailbox name
Current and new mailbox names
Mailbox name or reference string
STATUS
Mailbox name
APPEND
Mailbox name, message, optional
flags and date/time
IMAP – Comandos Seleccionado
Command
Parameters
CHECK
None
CLOSE
None
Cierra el buzón actual y retorna al
estado AUTENTICADO.
EXPUNGE
None
Remueve mensajes marcados
para borrar. Automático al cierre.
SEARCH
FETCH
STORE
COPY
UID
Description
Establece un “checkpoint” para un
buzón.
Search criteria and an optional
En el buzón actual.
character set specification
Para leer un número específico de
Sequence of message numbers elementos de un mensaje o una
and a list of message data items secuencia de mensajes. Por
ejemplo encabezados, cuerpos,
(or a macro)
flags, fechas, etc.
Sequence of message numbers, Es el complemento de FETCH para
message data item name and realizar cambios a un mensaje,
value
sobre todo las banderas.
Sequence of message numbers
and a mailbox name
Command name and arguments