Base del transporte de correo electrónico. Ya no es más el sistema de mensajería más utilizado.

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. mail.mi-servidor.com.ar MTA MTA mail.otro-servidor-remoto.com.ar SMTP (TCP) mail.servidor-remoto.com.ar SMTP (TCP) POP3 IMAP4 (TCP) MTA Sendmail Postfix Qmail yo@mi-servidor.com.ar Eudora The Bat! Thunderbird Outlook Cliente Telnet UA UA vos@mi-servidor.com.ar POP3 IMAP4 (TCP) UA ella@servidor-remoto.com.ar

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 822yMIME 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, Replay-To: dirección Campos de Dirección Destino. To: Cc: Bcc: Campos de Identificación. Message-ID: In-Replay-To: message-id References: otros mensajes. Campos de Información. Subject: Comments: Keywords: 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 no- ASCII 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 <joe@someplace.org> To: Jane Receiver <jane@somewhereelse.com> 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 MensajeEncapsulado 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 message/external-body: Provee una referencia para la localización del cuerpo del mensaje.

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-Encoding 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 codificada: =?<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: =?UTF-8?Q?aprobaci=C3=B3n=20de=20edici=C3=B3n?=

SMTP Proceso decomunicación

SMTP- Transacción

SesiónSMTP 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: <yo@mi-servidor.com.ar> 250 Sender ok >>> RCPT To: <ella@servidor-remoto.com.ar> 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 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) SIZExxxxxxxx = 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 (extendedturn-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: <xx@yy.com> BY=600

POP3 - Post Office Protocol, versión 3 SMTPseencargadelenvíodee-mailhastaelbuzóndelreceptor. 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 esla3,deahísunombrepop3. 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 LIST RETR DELE NOOP RSET TOP Requerimiento de información de estado de buzón (Número de mensajes, y bytes de cada mensaje) Lista información sobre los mensajes en el buzón(número de mensaje y tamaño) Para bajar un mensaje del buzón. Marca un mensaje para borrar, luego LIST o RETR darían error. 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 Parameters User name and password Authentication mechanism name STARTTLS 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 Mailbox name DELETE Mailbox name RENAME Current and new mailbox names LIST Mailbox name or reference string STATUS APPEND Mailbox name Mailbox name, message, optional flags and date/time

IMAP Comandos Seleccionado Command Parameters Description CHECK None Estableceun checkpoint paraun buzón. CLOSE EXPUNGE SEARCH FETCH STORE COPY None None Search criteria and an optional character set specification Sequence of message numbers and a list of message data items (or a macro) Sequence of message numbers, message data item name and value Sequence of message numbers and a mailbox name Cierrael buzónactual y retornaal estadoautenticado. Remueve mensajes marcados paraborrar. Automáticoal cierre. En el buzónactual. Para leer un númeroespecíficode elementosde un mensajeo una secuencia de mensajes. Por ejemplo encabezados, cuerpos, flags, fechas, etc. Es el complemento de FETCH para realizarcambiosa un mensaje, sobretodolasbanderas. UID Command name and arguments