You are on page 1of 24

Introducción a los protocolos.

César Llamas Bello
Octubre, 2011. Sistemas Distribuidos, Grado en Informática
1
Indice
Índice
1. Nociones básicas sobre protocolos 1
1.1. Descripción de protocolos . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Características del diseño de un protocolo . . . . . . . . . . . . . . . 3
1.3. Servicio y suposiciones sobre el entorno . . . . . . . . . . . . . . . . 3
1.4. Vocabulario y formato de mensajes de un protocolo . . . . . . . . . . 5
1.5. Reglas de procedimiento de un protocolo . . . . . . . . . . . . . . . 6
1.6. Ejemplo de diagramas de tipo de proceso (flujo) . . . . . . . . . . . . 9
1.7. Propiedades deseables en un protocolo . . . . . . . . . . . . . . . . . 10
2. Los protocolos de Internet 11
2.1. Sociedades de Internet . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Ejemplo de RFC: El RFC 2821 (SMTP) . . . . . . . . . . . . . . . . 12
3. Resumen de la unidad 22
1. Nociones básicas sobre protocolos
¿Qué es un protocolo?
Acuerdo de comunicación que afecta al intercambio de información en el sis-
tema.
Se considera una norma a seguir para integrar entidades activas en la aplicación:
• usuarios,
• objetos activos,
• sistemas, ?
Los protocolos son una especie de algoritmos distribuidos.
Un protocolo implementa una función de comunicación donde se define un ser-
vicio.
1.1. Descripción de protocolos
El protocolo como un lenguaje
La definición de un protocolo se asemeja mucho a la definición de un lenguaje:
Se define un formato preciso para los mensajes válidos (SINTAXIS);
Se definen reglas de procedimiento para el intercambio de datos
(pasos a seguir en el intercambio de mensajes) (ALGORITMO/COORDINACION)
Grado en Informática - SD (2011) - Protocolos 2
Definen un vocabulario de mensajes válidos junto a su significado (SEMANTI-
CA)
Elementos de un protocolo
La especificación completa de un protocolo contiene:
El servicio proporcionado por el protocolo.
Los supuestos sobre el entorno en el que se ejecuta el protocolo.
El vocabulario de los mensajes empleados en la implementación del protocolo.
El formato (codificación) de cada mensaje del vocabulario.
Las reglas de procedimiento que mantienen la consistencia de los intercambios
de mensajes.
Ciclo de vida
Versión inicial de la norma
(formal o semiestructurada)
Versión detallada de la norma
(formal o semiestructurada)
conjunto
de
pruebas
banco
de
pruebas
Verificación y validación
+ análisis de prestaciones
+ prototipado.
Diseño de pruebas
Reelaboración
Reelaboración
Diseñando un protocolo
Principio de diseño:
“Todo protocolo debería ser considerado incorrecto a menos que se pruebe lo
contrario”.
En primer lugar hay que enumerar el vocabulario de primitivas.
Ej.: conecta, envia, error, ack, desconecta
Grado en Informática - SD (2011) - Protocolos 3
En segundo lugar, el formato de cada primitiva.
Ejemplos:
• conecta(identidad).
• envía(destinatario, mensaje).
• error(mensaje).
1.2. Características del diseño de un protocolo
Diseñando un protocolo
En tercer lugar, las reglas por las que se rigen las secuencias de mensajes. Hay
diversas posibilidades de realizar la descripción:
• Hacerlo informalmente en texto, o
• Hacerlo formalmente mediante:
◦ Diagramas de secuencia de tiempo.
◦ Diagramas de tipo de proceso en SDL (System Design Language).
◦ Diagramas de estado y/o actividad en UML 2.0.
◦ Lenguajes especiales (Promela, etc.).
Reglas de procedimiento
Las reglas del procedimiento dicen qué secuencias de mensajes son admisibles
en el protocolo.
• Suelen expresarse como autómatas: guiados por eventos (que disparan tran-
siciones).
• Los eventos se almacenan en colas de entrada a las acciones.
En SDL se utiliza algo parecido a diagramas de flujo con estados.
1.3. Servicio y suposiciones sobre el entorno
Ejemplo - Protocolo de Lynch
Especificación del servicio
Transferir archivos como secuencia de caracteres por la línea telefónica evitando
errores de transmisión, suponiendo que pueden detectarse todos los errores.
Es una transferencia de archivos full-duplex.
Se envían reconocimientos positivos y negativos para el tráfico de Aa Bmediante
la línea de B a A (y viceversa).
Cada mensaje tiene dos partes, una de mensaje, y otra de control que se aplica al
tráfico en el canal contrario.
Grado en Informática - SD (2011) - Protocolos 4
Ejemplo - Protocolo de Lynch (ii)
Suposiciones sobre el entorno
El entorno consta de dos usuarios del servicio y un canal de transmisión.
Cada usuario pide un archivo y espera la vuelta.
Se supone que el canal distorsiona arbitrariamente el mensaje, pero no pierde,
inserta, duplica, ni reordena los mensajes.
Se parte de la existencia de un módulo de nivel inferior que atrapa las distorsiones
y reparte mensajes no distorsionados de tipo “err”.
Servicio y suposiciones sobre el entorno
Cada protocolo se compone de operaciones básicas proporcionadas por el entorno.
Así, la realización concreta de un servicio depende de las suposiciones sobre el
entorno en que se ejecuta el protocolo.
El sentido común dice que si un problema es demasiado grande ha de partirse en
subproblemas, y así se hace en las capas de protocolos.
P
1
P
2
Nivel base
'
P
2
P
1
''
P
2
''
'
P
1
Nivel '
Nivel ''
Servicio y suposiciones sobre el entorno
Las ventajas de un sistema estratificado son:
• Ayuda a determinar los protocolos separando tareas de nivel superior de los
detalles del nivel inferior.
• Resulta más fácil remplazar un módulo que reescribir el protocolo en caso
de extensión o cambio.
Capas/Niveles el esquema ISO:
• Físico: transmisión de bits sobre circuito.
• Enlace de datos: Detección de errores y recuperación.
• Red: Transferencia y rutado transparente de los datos.
• Transporte: Transferencia de alto nivel entre procesos.
• Sesión: Coordinación de interacciones en sesiones.
• Presentación: Interpretación de sintaxis de datos a nivel de proceso (ej:
encriptación, compresión?)
• Aplicación: Punto de entrada para procesos de usuario final.
Grado en Informática - SD (2011) - Protocolos 5
1.4. Vocabulario y formato de mensajes de un protocolo
Ejemplo - Protocolo de Lynch (iii)
Vocabulario del protocolo
V = {ack, err, nak}
ack: un mensaje combinado con un reconocimiento positivo
nak: un mensaje combinado con un reconocimiento negativo.
err: un mensaje con un error de transmisión.
Ejemplo - Protocolo de Lynch (iv)
Formato de los mensajes
Cada mensaje consta de un código de control que identifica el tipo de mensaje
y un campo de datos con el código del carácter. (suponemos que ambos son de
tamaño fijo.
<etiqueta de control (ack, err, nak) + datos>
Ejemplo en C
enum control { ack, nak, err };
struct message {
enum control etiqueta;
unsigned char datos;
};
Vocabulario y formato
Los mensajes respetan ciertas estructuras que codifican el vocabulario del proto-
colo.
Los tres métodos de formato usuales son:
• Orientado a bit.
• Orientado a caracteres.
• Orientado a flujos de bytes.
Además (sobre todo en flujos de bytes) estructuralmente pueden organizarse los
mensajes en bloques del tipo:
formato={header, data, trailer}
• header = {type, destination, sequence number, count}
• trailer = {checksum, return address}
Grado en Informática - SD (2011) - Protocolos 6
Volcabulario y formato (ii)
Bit oriented.
01111110 011100011101110 01111110
bit stuffing
delimiter user data delimiter
Character oriented.
STX byte,byte,DLE,STX,byte... ETX
delimiter user data delimiter
escape char
Byte count oriented.
STX ETX
delimiter user data delimiter header trailer
... ... ...
type;dest;seqn;count
checksum;return-address
1.5. Reglas de procedimiento de un protocolo
Ejemplo - Protocolo de Lynch (v)
Reglas de procedimiento
1. Si la recepción anterior no tenía errores, el próximo mensaje en el canal contrario
llevará un reconocimiento positivo;
si la recepción tuvo errores, llevará un reconocimiento negativo.
2. Si la recepción previa llevaba un reconocimiento negativo, o la recepción anterior
fue errónea, se retransmite el mensaje anterior;
de otro modo, se consigue otro mensaje para una nueva transmisión.
Grado en Informática - SD (2011) - Protocolos 7
Lenguaje de descripción de flujo
Este es un subconjunto del SDL (CCITT-1988)
Cada diagrama de flujo define un proceso que se ejecuta, en principio, concur-
rentemente con el resto de procesos.
Cada diagrama tiene un punto de entrada etiquetado con un nombre de proceso
o “start”.
Los elementos gráficos se conectan mediante arcos dirigidos que van de un ele-
mento a otro, o un conector:
Elementos del lenguaje de descripción de flujo (i)
Sentencia
con asignaciones u operaciones varias.
Test
con expresiones booleanas para bifurcar el flujo del proceso.
Espera
donde se detiene el proceso hasta que se produce cierta entrada o condición de
continuación.
Interno
con eventos internos que permiten la continuación del proceso, como timeouts y
temporizadores.
Entrada
indica que se ha producido cierta entrada.
Salida
emite un mensaje de salida desde el proceso.
Elementos del lenguaje de descripción de flujo (i)
Las expresiones booleanas se evalúan sin demora alguna, al contrario que las
condiciones de espera, sirven para modelar la sincronización de los procesos.
Los arcos de estos diagramas expresan la dirección del flujo de ejecución, y sólo
pueden converger en los conectores ;
Aunque pueden diverger en las esperas
Espera
y en los test
Test
.
Las salidas
Salida
, las sentencias
Sentencia
, los internos
Interno
, y los test
Test
,
pueden aparecer en cualquier lugar.
Las entradas
Entrada
sólo pueden aparecer a continuación de un símbolo de espera
recibe
recibe
.
Grado en Informática - SD (2011) - Protocolos 8
Condición de espera de recepción
Una condición de espera recibe demora la ejecución hasta que la cola de men-
sajes implícita contiene en su primer parte un mensaje del tipo indicado en una de las
entradas que siguen al símbolo.
Si el mensaje es de otro tipo, es un error.
Si a la espera le sigue un timeout, se aborta dicha espera cuando expira dicho
timeout.
Las esperas internas también admiten expresiones booleanas. En este caso el
proceso se demora hasta que se cumple la expresión.
recibe
timeout ack
Condición de espera de recepción
Hay dos acciones internas para modelar el acceso a archivos: next (recupera) y
accept (almacena).
Example 1.
next: a, b
msg: a, b accept: a, b
msg: a, b
timeout
Ejemplo - Protocolo de Lynch (vi)
Diagrama de tipo de proceso
Grado en Informática - SD (2011) - Protocolos 9
start
next: out
recibe
nak: inp ack: inp err: inp
next: out
ack: out ack: out nack: out
Estado básico del sistema,
donde se espera la entrada.
Mensaje
reconocido
Mensaje
enviado
Acción
interna
1.6. Ejemplo de diagramas de tipo de proceso (flujo)
Ejemplo - Protocolo de Lynch (vii)
Diagrama de secuencia de tiempo
A B
err
nak 'z'
ack: 'a' ... � err
nak: 'z' ... � err
nak 'a'
ack 'z'
Envía letras
de la 'a' a la 'z'
Envía letras
de la 'z' a la 'a'
next: out
next: out
acepta 'z'
acepta 'a'
acepta 'z'
next: out
ack 'b'
sin distorsión
con distorsión
Ejemplo - Protocolo de Lynch (viii)
Carencias del diseño
Grado en Informática - SD (2011) - Protocolos 10
El envío/recepción debe ocurrir simultáneamente.
El protocolo debe comenzar en puntos diferentes en cada uno de los dos proce-
sos, para que estén “en fase”.
Puede comenzarse con un mesaje “err”.
Se ha omitido: el receptor debe ser capaz de decidir si un dato recibido correcta-
mente (almacenado temporalmente en “inp"), ha de ser almacenado.
El protocolo, en resumen, contiene escenarios erróneos.
Ejemplo - Protocolo de bit alternante con timeouts
Diagramas de tipo de proceso (protocolo asimétrico)
start
next: o
msg: o,s
recibe
ack: r
r == s a == e
s �1�s
timeout
start
accept: i
ack: a
recibe
msg:i,a
e �1�e
true true
false false
1.7. Propiedades deseables en un protocolo
Propiedades de un buen protocolo
Simplicidad: El caso de los protocolos de peso ligero.
Modularidad: Una jerarquía de funciones.
Protocolo bien formado (aunque no sobre-especificado) (completo y sólido).
Robustez frente a situaciones no consideradas.
Consistencia. Posibles fallos son:
Grado en Informática - SD (2011) - Protocolos 11
• Interbloqueos (no hay ejecuciones posibles).
• Bloqueos vivos (sin progreso efectivo de los procesos).
• Terminaciones inadecuadas (sin satisfacer los requisitos).
2. Los protocolos de Internet
Estandarización de protocolos de Internet
Central domain
database
root server
accredited
registrars
ISOC
Society
IAB
Architecture
Board
IETF
Engineering
Task Force
IRTF
Research
Task Force
ICANN
corporation
for assigned
names & numbers
CCNSO
Country code
names support
organization
IANA
assigned numbers
authority
GNSO
Generic
names Support
organization
2.1. Sociedades de Internet
Sociedades de Internet
Internet Society (ISOC-www.isoc.org): guía el futuro de Internet supervisando
los estándares, política pública, educación y entrenamiento. Lo forman corpora-
ciones, organizaciones gubernamentales internacionales e individuos.
Internet Corporation for Assigned Names and Numbers (ICANN-www.icann.org)
Internet Activities Board (IAB-www.iab.org): define la arquitectura de Inter-
net, y supervisa los protocolos de Internet.
Internet Engineering Task Force (IETF-www.ietf.org): Con más de 70 sub-
comités informales corre con el día a día de Internet.
Grado en Informática - SD (2011) - Protocolos 12
Otras sociedades de estandarización
Institute of Electrical and Electronics Engineers (IEEE-eye-triple-e): dispone de
estándares hardware como los de LAN (802, con cable, wireless, . . . ).
World Wide Web Consortium (W3C-w-c-3): establece los estándares relaciona-
dos con la Web (html, SOAP, XML, . . . )
International Organization for Standarization (ISO-eye-so).
International Telecommunication Union (antiguamente CCITT), dependiente de
la ONU.
Free Software Foundation (FSF): proporciona herramientas gratuitas que muchas
veces derivan en estandarizaciones (GNU-guh-new).
2.2. RFC
Estándares de Internet
Los estándares de Internet están bajo la forma de RFCs (request for comments-
www.ietf.org/rfc.html).
Las categorías de RFCs son muy diversas, las más conocidas son:
Standard Track (STD): Estándar técnico aprobado.
Draft standard: Camino de aprobación.
Proposed standard: Camino de aprobación como draft standard.
Best current practices (BCP): Guías y recomendaciones (ej: 4107 sobre gestión
de claves).
Experimental (EXP): Investigación o desarrollo (ej.: 5335 sobre internacional-
ización de cabeceras de correo).
Historic: RFCs obsoletos que se conservan como recuerdo.
Informational (FYI-for-your-information): Útiles y tutoriales (ej.: 4677 “el Tao
de IETF”- una guía bla bla bla)
También los hay de broma (ej.: 1149) (ver en la Wikipedia “April Fools Day
RFC”).
2.3. Ejemplo de RFC: El RFC 2821 (SMTP)
Ejemplo de RFC: SMTP
Cabecera
Grado en Informática - SD (2011) - Protocolos 13
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
Status of this Memo
This document specifies an Internet standards track protocol
for the Internet community, and requests discussion and
suggestions for improvements. Please refer to the current
edition of the "Internet Official Protocol Standards" (STD
1) for the standardization state and status of this
protocol. Distribution of this memo is unlimited.
...
Ejemplo de RFC: SMTP (ii)
Cabecera (ii)
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is a self-contained specification of the basic
protocol for the Internet electronic mail transport. It
consolidates, updates and clarifies, but doesn’t add new or
change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol)
specification of RFC 821 [30],
- domain name system requirements and implications for mail
transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123
[2], and
- ... ‘‘bla bla bla hasta hasta el fin del abstract’’
Ejemplo de RFC: SMTP (iii)
Tabla de contenidos
Table of Contents
1. Introduction .................................................. 4
Grado en Informática - SD (2011) - Protocolos 14
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model ..(supera al RFC821)..................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology ..(definición del vocabulario).................... 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
Ejemplo de RFC: SMTP (iv)
Estructura básica
2.1 Basic Structure
The SMTP design can be pictured as:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
The means by which a mail message is presented to an SMTP client, and
Ejemplo de RFC: SMTP (v)
Modelo de Extensión
Grado en Informática - SD (2011) - Protocolos 15
2.2 The Extension Model
2.2.1 Background
In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform
the client as to the service extensions that it supports.
Contemporary SMTP implementations MUST support the basic extension
mechanisms. For instance, servers MUST support the EHLO command even
if they do not implement any specific extensions and clients SHOULD
preferentially utilize EHLO rather than HELO. (However, for
compatibility with older conforming implementations, SMTP clients and
servers MUST support the original HELO mechanisms as a fallback.)
Unless the different characteristics of HELO must be identified for
interoperability purposes, this document discusses only EHLO... ...
Ejemplo de RFC: SMTP (vi)
Tabla de contenidos (ii)
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .(desc. precisa pero informal) 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
Grado en Informática - SD (2011) - Protocolos 16
Ejemplo de RFC: SMTP (vii)
Terminología
2.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
(Esto aparece en casi todos los RFCs)
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
...
Ejemplo de RFC: SMTP (viii)
Terminología (ii)
2.3.2 Senders and Receivers
In RFC 821, the two hosts participating in an SMTP transaction were
described as the "SMTP-sender" and "SMTP-receiver". This document
has been changed to reflect current industry terminology and hence
refers to them as the "SMTP client" (or sometimes just "the client")
and "SMTP server" (or just "the server"), respectively. Since a
given host may act both as server and client in a relay situation,
"receiver" and "sender" terminology is still used where needed for
clarity.
2.3.3 Mail Agents and Message Stores
Cambio terminológico de ’’cliente-servidor’’ a MTA
(mail transfer agent) y MUA (mail user agent).
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Grado en Informática - SD (2011) - Protocolos 17
...
Ejemplo de RFC: SMTP (xix)
Tabla de contenidos (iii)
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ..(primitivas del protocolo sint/sem).. 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) .................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
Ejemplo de RFC: SMTP (xx)
Formato de los mensajes
4. The SMTP Specifications
4.1 SMTP Commands
4.1.1 Command Semantics and Syntax
The SMTP commands define the mail transfer or the mail system
function requested by the user. SMTP commands are character strings
terminated by <CRLF>. The commands themselves are alphabetic
characters terminated by <SP> if parameters follow and <CRLF>
otherwise. (In the interest of improved interoperability, SMTP
receivers are encouraged to tolerate trailing white space before the
terminating <CRLF>.) The syntax of the local part of a mailbox must
conform to receiver site conventions and the syntax specified in
section 4.1.2. The SMTP commands are discussed below. The SMTP
replies are discussed in section 4.2.
Grado en Informática - SD (2011) - Protocolos 18
A mail transaction involves several data objects which are
communicated as arguments to different commands...
Ejemplo de RFC: SMTP (xxi)
Formato de los mensajes (ii)
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keyworks follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
[8], is:
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*
( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
Ejemplo de RFC: SMTP (xxii)
Primitivas devueltas por el servidor
4.2.2 Reply Codes by Function Groups
500 Syntax error, command unrecognized
(This may include errors such as command line too long)
501 Syntax error in parameters or arguments
502 Command not implemented (see section 4.2.4)
503 Bad sequence of commands
504 Command parameter not implemented
211 System status, or system help reply
214 Help message
(Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user)
220 <domain> Service ready
221 <domain> Service closing transmission channel
Grado en Informática - SD (2011) - Protocolos 19
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)
Ejemplo de RFC: SMTP (xxiii)
Tabla de contenidos (iv)
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ..(secuenciación de las primitivas)..... 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
Ejemplo de RFC: SMTP (xxiv)
Ejemplo de secuenciación
Specific sequences are:
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
Grado en Informática - SD (2011) - Protocolos 20
E: 451, 554, 503
...
Ejemplo de RFC: SMTP (xxv)
Semántica de errores
Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:
Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.
MAIL Command: 5 minutes
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
DATA Initiation: 2 minutes
This is while awaiting the "354 Start Input" reply to a DATA
command.
Ejemplo de RFC: SMTP (xxvi)
Tabla de contenidos (v)
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ..(casi obligatorio)............ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ..(casi obligatorio)................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ..(casi obligatorio)....................... 67
9. References ..(casi obligatorio)................................ 68
10. Editor’s Address ..(casi obligatorio)......................... 70
11. Acknowledgments ..(casi obligatorio).......................... 70
Grado en Informática - SD (2011) - Protocolos 21
Ejemplo de RFC: SMTP (xxvii)
Tabla de contenidos (vi)
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ..(ejemplos y material complementario)............ 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ..(casi obligatorio)............ 76
Full Copyright Statement ..(casi obligatorio)..................... 79
Ejemplo de RFC: SMTP (xxviii)
Detalles de los apéndices
APPENDICES
A. TCP Transport Service
The TCP connection supports the transmission of 8-bit bytes. The
SMTP data is 7-bit ASCII characters. Each character is transmitted
as an 8-bit byte with the high-order bit cleared to zero. Service
extensions may modify this rule to permit transmission of full 8-bit
data bytes as part of the message body, but not in SMTP commands or
responses.
B. Generating SMTP Commands from RFC 822 Headers
Some systems use RFC 822 headers (only) in a mail submission
protocol, or otherwise generate SMTP commands from RFC 822 headers
when such a message is handed to an MTA from a UA. While the MTA-UA
protocol is a private matter, not covered by any Internet Standard,
Ejemplo de RFC: SMTP (xxix)
Detalles de los apéndices
D.1 A Typical SMTP Transaction Scenario
This SMTP example shows mail sent by Smith at host bar.com, to Jones,
Green, and Brown at host foo.com. Here we assume that host bar.com
contacts host foo.com directly. The mail is accepted for Jones and
Brown. Green does not have a mailbox at host foo.com.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
Grado en Informática - SD (2011) - Protocolos 22
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
3. Resumen de la unidad
Resumen (i)
Los protocolos son necesarios para comuniciar procesos.
• Son normativos.
• Son de la misma naturaleza que los algoritmos distribuidos.
• En ellos interviene la definición de un lenguaje definido tanto en su sintaxis
como en su semántica.
Definimos un protocolo mediante:
• Servicio.
• Supuestos.
• Vocabulario.
• Formatos de los mensajes.
• Reglas de procedimiento.
Resumen (ii)
El diseño de un protocolo real es complejo:
• Tiene su ciclo de vida, como el software, pasa por la definición de:
◦ Vocabulario
◦ Formato
◦ Reglas de procedimiento
• Para ello es recomendable utilizar notación estructurada y formal, cuando
es posible.
• La verificación del protocolo juega un papel importante.
Grado en Informática - SD (2011) - Protocolos 23
Resumen (iii)
Al especificar el servicio proporcionamos un modelo de funcionamiento.
Al concretar los supuestos del entorno, indicamos cuales son las restricciones
sobre las que constrúimos el sistema.
El vocabulario del protocolo consta de primitivas y mensajes devueltos.
El formato de los mensajes debe expresarse mediante notación formal (BNF?).
Resumen (iv)
Para describir las reglas de procedimiento es común emplear:
• diagramas de secuencia;
• diagramas de estado, y sus derivados como los
• diagramas de control de flujo.
Las propiedades deseables de un protocolo son:
• Simplicidad.
• Modularidad.
• Buena formación.
• Robustez.
• Consistencia.
Resumen (v)
En Internet existen diversas organizaciones que llevan la cuenta de su funcionamien-
to, extensión y estandarización.
• ISOC-Internet Society { IAB- Internet Architecture Board { IETF- Internet
Engineering Task Force, IRTF - Internet Research Task Force}}
• ICANN- Internet Corporation for Assigned Names & Numbers { IANA
- Internet Assigned Numbers Authority, CCNSO - Country Code Names
Support Organization, GNSO- Generic Names Support Organization { Cen-
tral Domain Database Root Server, Accredited Registrars}}
Resumen (vi)
Para estandarizar Internet se recurre a la emisión de documentos llamados RFC
(Request-for-comments)
• Siguen una pista de estandarización. (Proposed → Draft → standard).
• Los rfc están normalizados,
• Tienen una estructura estándar, y ciertas secciones normativas.
• Existen RFC de muy diversa índole.