Servicios TCP/IP

2. DNS
3. FTP
4. DHCP
5. WWW
6. SMTP

INTRODUCCIÓN

La presente Monografía
fue realizada con fines académicos, para ser presentada
ante el INSTITUTO UNIVERSITARIO
AERONÁUTICO con sede en Córdoba, Argentina. La información es en su totalidad recopilada
de Internet y
constituye la primera entrega de una investigación sobre Servicios
TCP/IP, siendo la
segunda de ellas, dichos servicios y su
configuración para Windows NT
4.0.

1) DNS

En el grupo de
protocolos
TCP-IP se
encuentran los protocolos de
resolución de nombres por direcciones IP. Estos protocolos
permiten a las aplicaciones tener acceso a los servicios de un
computador a
través del uso de un nombre. Para ello debe existir un
mecanismo que permita la resolución y asociación de
una dirección IP por un nombre. El mecanismo de
asociación consiste en una base de datos
donde se encuentran las asociaciones de una dirección IP con su nombre respectivo. Y el
mecanismo de resolución consiste en identificar cual es la
dirección IP asociada a un nombre. De esta manera los
computadores de la red pueden ser accesados a
través de un nombre en vez de su dirección
IP.

En los comienzos de la red Internet la
resolución de nombres por números IP se realizaba a
través de un archivo de
texto llamado
hosts. Este archivo de
texto
contenía toda las direcciones IP asociadas al nombre
asignado a cada computador. A
medida que la red Internet fue creciendo este método de
resolución de nombre por números IP fue presentando
problemas
debido a que el archivo hosts era administrado por el administrador de
cada red, de esta manera no se podía garantizar que un
administrador
no asignara el mismo nombre a máquinas
distintas ubicadas en redes distintas. Esto trae
como consecuencia la colisión de nombres e inconsistencia
del archivo hosts a lo largo de una red en crecimiento. El
formato de este archivo de texto es el siguiente:

Lupolo@pc-1:~$ cat /etc/hosts

127.0.0.1 localhost pc-1

192.168.2.1 pc-2

En este archivo podemos observar que la dirección
IP 127.0.0.1 está asociada con los nombres localhost y
pc-1 y la dirección IP 192.168.2.1 está asociada
con el nombre pc-2.

Con el fin de resolver los problemas
explicados anteriormente se desarrolló el protocolo de
Sistema de
nombres de dominios "DNS Domain
Name System". Este protocolo es una
base de datos distribuida
que permite un control local
sobre los segmentos de la base de datos en
general, logrando que cada segmento esté disponible a lo
largo de toda la red Internet. El sistema de
nombres de dominios utiliza un esquema cliente servidor. El
protocolo DNS
está compuesto por dos programas uno
llamado servidor de
nombres de dominios y otro llamado resolvers. Los servidores de
nombres de dominios contienen la base de datos de un
segmento y dicha base de datos es accesada por los clientes a
través de un programa conocido
como resolvers. Los resolvers son rutinas utilizadas para tener
acceso a la base de datos ubicada en los servidores de
nombres de dominios con el fin de resolver la búsqueda de
una dirección IP asociada a un nombre.

1.1) Protocolo DNS

En la figura 1.1 podemos observar la estructura
gráfica de una base de datos DNS donde cada nodo es un
nombre de dominio, Todos
los nombres de dominios nacen a partir del dominio
raíz, el cual se denota con un punto. A su vez cada uno de
estos nombres de dominio puede sub-dividirse. Por ejemplo, el
dominio .org. incluye a dos nombres de dominio caida y kernel.
Cada uno de estos nombres de dominio tienen dos nombres de
dominio llamados www.caida.org. y ftp.caida.org
y www.kernel.org. y ftp.kernel.org.. Esto implica que el nombre de
dominio www asignado a dos computadores "www.caida.org. y
www.kernel.org." gozan de un nombre de dominio único. Cada
uno de estos nombres de dominio son nombres de dominio
completamente calificados "FQDN, Full Qualified Domain Name". De
esta manera dos computadoras
pueden tener el mismo nombre sí y sólo sí
pertenecen a zonas distintas.

Una zona representa las partes contiguas del
árbol del dominio para el cual un servidor de nombres
contiene la información completa y es autoridad del
dominio. En la figura 1.1 podemos apreciar dos zonas Caida.org. y
Kernel.org.. Los servidores de dominio de cada zona contienen en
sus bases de datos la
dirección IP asociada al nombre de dominio.

El servidor de nombres de una zona puede delegar la
responsabilidad del sistema de nombres de dominios
a otro servidor de nombres de dominio con el fin de
descentralizar la base de datos. Tal es el ejemplo de los
servidores de nombres "." raíz presentados en la figura
1.1. Estos servidores de nombres delegan sus zonas a los
servidores de nombres del dominio org..

 Para ver el gráfico
seleccione la opción "Descargar"

Figura 1.1 Estructura
gráfica de una base de datos DNS

Como cada computadora
está asociada a un nombre de dominio completamente
calificado "FQDN" y un FQDN tiene asociado una dirección
IP, esto implica que los servicios ofrecidos por una computadora
pueden ser accesados a través de un nombre completamente
calificado. El nombre de un dominio puede tener hasta 63
caracteres de longitud y puede pertenecer a cualquiera de los 127
niveles posibles. En el protocolo DNS no existe diferencia entre
mayúsculas o minúsculas. Un dominio puede ser una
computadora o puede ser un nodo del cual parten otros
dominios.

Un nombre de dominio es un índice dentro de la
base de datos DNS. Los nombres indexados en un dominio son las
rutas que conforman el espacio de nombres de dominio. El nombre
completo asociado a una dirección IP es una secuencia de
nombres de dominios asignados desde su nodo hasta el nodo
raíz.

El espacio de dominio de la red Internet está
dividido básicamente en tres niveles: Nivel Raíz,
Nivel Tope y Nivel secundario. En la figura 1.2 podemos observar
el nivel jerárquico de cada uno de estos
niveles.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Figura 1.2 Espacio de dominio de la red
Internet

Los servidores de nombres de dominio superiores, es
decir, los servidores de nombres de raíz primarios, son
los servidores que delegan la resolución de nombres de
dominios por números IP a los servidores de nombres de
dominio de nivel tope. Los nombres de dominios de nivel tope
más comunes en la red Internet son los dominios
genéricos:

-. Com. Son dominios asignados a organizaciones
comerciales. Ej. newdevices.com.

-. Edu. Son dominios asignados a instituciones educativas. Ej.
ucv.edu.

-. Gov. Son dominios asignados a agencias
gubernamentales.

-. Net. Son dominios asignados a organizaciones
relacionadas con la red Internet.

-. Org. Son dominios asignados a organizaciones sin
fines de lucro.

Además de estos nombres de dominio incluidos en
el nivel tope se encuentran los nombres de dominio
geográficos basados en la nomenclatura
ISO3166. Cada uno de estos nombres de dominio son administrados
por cada país. Este tipo de nombres de dominio son
organizados por localidad y son útiles para organizaciones
y negocios que
deseen operar en dicha localidad geográfica.

Los servidores de nombres de dominio de nivel tope
delegan la resolución de nombres por números IP a
los servidores de nombres de dominio de nivel secundario. En este
nivel se encuentran todos los nombres de dominio asignados a las
computadoras
que ofrecen servicios de
Internet. Ejemplo: www.caida.org..

Dentro del espacio de nombres de dominio de la red
Internet se encuentra el espacio de nombres de dominio
in-arpa.addr cuya función es
asociar una dirección IP con un nombre de dominio de esta
manera el usuario a partir de una dirección IP puede
conocer el nombre de dominio asociado a dicha dirección
IP. En este espacio de nombres de dominios la dirección IP
se lee desde lo más especifico a lo más general;
Por ejemplo www.caida.org. (192.172.226.123) se leeria
123.226.172.192.in-addr.arpa. lo cual retorna en una
búsqueda a www.caida.org..

1.1.1) Base de datos del protocolo DNS

Cada servidor de nombres de dominio mantiene una base de
datos que sirve para asociar los nombres de dominios con
direcciones IP. Está base de datos se conoce con el nombre
de archivos de la
zona. Cada servidor de nombres de dominio también mantiene
una base de datos de resolución inversa. Esta base de
datos se conoce con el nombre de archivos de
resolución inversa de la zona.

Ambas bases de datos
son manejadas por un servidor de nombres, el cual responde a las
solicitudes hechas por el resolver. El formato de dichas bases de
datos son archivos de texto donde se definen los registros de
recurso "Resource Records RR" que sirven para especificar la
relación entre un nombre de dominio y una dirección
IP además sirve para especificar en qué zona del
espacio de nombres de dominios el servidor de nombres de dominios
pertenece. La siguiente tabla presenta los registros de
recursos
más comunes para la clase IN, es decir;
Internet.

El formato de un registro de
recurso es el siguiente:

[nombre] [ttl] IN <tipo de registro>
<valor>

-. [nombre] es el nombre del objeto referenciado por
el registro del recurso. Puede ser un nombre de estación
o un nombre de dominio.

-. [ttl] es el tiempo de vida
del registro. Define la cantidad de segundos que la
información sobre este registro puede ser mantenida en
la memoria
de un servidor de dominios. Si el ttl es omitido usa el ttl
indicado por el recurso definido en la sección
SOA.

-. IN Identifica la clase del registro como clase
Internet.

-. <tipo de registro> Identifica el tipo de
recurso de acuerdo a la tabla anterior.

-. <valor> es
la información específica al tipo de
recurso.

1.1.2) Servidores de nombres
Autoritarios

Cada zona goza de un servidor de nombres de dominio
autoritario. Un servidor de nombres de dominio autoritario es la
autoridad de
la zona ya que contiene todos los registros de recursos de la
zona. Un servidor de nombres de dominio autoritario se define con
el registro de recurso NS y SOA.

Para que el protocolo DNS sea tolerante a fallas se
recomienda dos o más servidores de nombres de dominio
autoritarios por zona donde al menos uno de ellos sea master. Existen diferentes tipos de
servidores de nombres autoritario, a saber:

-. Servidores de nombres de dominio Primario o
Master

-. Servidores de nombres de dominio Secundarios o
Esclavos

-. Servidores de nombres de dominio Recursivos o
Cache

El servidor que contenga los datos de la zona en su
sistema de archivos se conoce con el nombre de servidores de
nombres de dominio primario o master. Los servidores de nombres
de dominio primarios cargan los datos de la zona a través
de los archivos de la zona ubicados en el sistema de archivo del
servidor.

Los servidores de nombres de dominio esclavos cargan el
contenido de la zona de otro servidor usando un proceso de
réplica conocido como transferencia de la zona. Los datos
se transfieren típicamente desde un servidor de nombres de
dominio primario.

Un servidor de nombres de dominio recursivos o cache
utiliza búsquedas recursivas en el sistema de nombres de
dominio con el fin de buscar la dirección IP asociada al
nombre de dominio solicitado por el resolver y por cada
búsqueda el servidor de nombres de dominio recursivo
almacena el resultado en memoria "Cache"
con el fin de acelerar futuras búsquedas. Un servidor de
nombres de dominio recursivo es conocido también con el
nombre de servidor de nombres de dominio cache.

1.1.3) Métodos de
búsqueda

Los servidores de nombres de dominio no sólo
pueden ofrecer al resolver los datos de la zona que tienen
autoridad sino que pueden buscar a lo largo del espacio de
dominios, datos sobre los que no tienen autoridad. A esto se le
como conoce como resolución. La resolución comienza
siempre desde los servidores de nombres de dominio superiores
"Servidores de nombres de dominio de raíz primarios" hasta
llegar al servidor de nombres de dominio de nivel secundario que
tiene la información acerca de la zona solicitada por el
resolver. El proceso de
resolución o búsqueda puede ser de dos tipos:
Recursiva o Iterativa.

Una búsqueda recursiva consiste en que un
servidor de nombres de dominios a medida que obtiene respuestas
durante el proceso de resolución de nombres de dominios
este va guardando los nombres y su dirección IP asociada
en una memoria cache
con el fin de acelerar el proceso de búsqueda si la misma
información es solicitada nuevamente.

Una búsqueda iterativa consiste en que el
servidor de nombres de dominios da la mejor respuesta posible
basado en la información contenida en los archivos de la
zona y en la memoria cache.
La preguntas "Queries" solicitadas a los servidores de nombres de
dominio raíz solo pueden ser iterativas.

En la figura 1.3 podemos observar como la computadora
PC1 a través de una aplicación cliente que hace
uso del protocolo HTTP, requiere
establecer una conexión TCP, puerto de destino 80 con el
servidor de servicios WWW cuyo nombre de dominio es
www.debian.org.. Para poder
establecer dicha conexión TCP, la aplicación del
computador PC1 hace uso de la función
gethostbyname(www.debian.org) ofrecida por la aplicación
resolver con el fin de iniciar el proceso de resolución.
Una vez ejecutada dicha función la aplicación
resolver pregunta al servidor de nombres de dominio de la zona
donde se encuentra el computador PC1 "¿Cuál es la
dirección IP del nombre de dominio www.debian.org?" a
partir de este momento los siguientes pasos ocurren:

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Figura 1.3 Método de
resolución de nombres por números IP

-. El servidor de nombres de dominio ejecuta una
búsqueda en los registros de recursos ubicados en la memoria
cache y en los archivos de la zona. Si la búsqueda no
arroja resultados, el servidor de nombres de dominios pregunta a
los servidores de nombres de dominio raíz.

-. Los servidores de nombres de dominio raíz
"f.root-servers.net" responden indicando que el servidor de
nombres de dominio de la zona debian.org. puede ser encontrado en
el servidor de nombres de dominio org. "B.GTLD-SERVERS.NET". En
este paso podemos apreciar como los servidores de nombres de
dominio raíz "f.root-servers.ne" delegan las
búsquedas a los servidores de nombres de dominio de nivel
tope "B.GTLD-SERVERS.NET", tal como lo es el dominio org..-. El
servidor de nombres de dominio local pregunta a los servidores de
nombres de dominio"B.GTLD-SERVERS.NET" org. ¿cuál
es la dirección IP del dominio www.debian.org?.. El
servidor de nombres de dominios "B.GTLD-SERVERS.NET" org.
encuentra que uno de los servidores de nombres de dominios de la
zona debian.org. es administrada por el servidor de dominios
"NS2.CISTRON.NL => IP 62.216.31.55". Esta información
es enviada al servidor de nombres de dominio local.

-. El servidor de nombres de dominio local pregunta al
servidor de nombres de dominio NS2.CISTRON.NL:
¿Cuál es la dirección IP del nombre de
dominio www.debian.org.? Este servidor responde con la
dirección IP asociada al dominio www.debian.org =>
192.25.206.10. Luego el servidor de nombres de dominio local
almacena en la memoria cache
www.debian.org => 192.25.206.10 y la función
gethostbyname(www.debian.org) finaliza retornando la
dirección asociada al nombre de dominio www.debian.org.. A
partir de este momento la aplicación que hace uso del
protocolo HTTP puede
iniciar la conexión TCP, puerto 80 con el servidor de
servicios WWW cuyo nombre de dominio es
www.debian.org..

Con este ejemplo pudimos demostrar que el sistema de
nombres de dominios del protocolo DNS es una base de datos
distribuida que permite un control local
sobre los segmentos de la base de datos en general, logrando que
cada segmento esté disponible a lo largo de toda la red
Internet. El sistema de dominios de nombres utiliza un esquema
cliente servidor.

1.1.4) Servidores de nombres de
dominio

La aplicación de servicios de nombres de dominios
más conocida he implementada en la red Internet es BIND
"Berkeley Internet Name Domain". Esta aplicación
actualmente es mantenida y desarrollada por la
organización sin fines de lucro: The Internet Software Consortium
"www.isc.org". Esta aplicación determina el lugar de los
archivos de configuración de la zona a través de un
archivo de configuración cuyo nombre por defecto es
named.conf. Un ejemplo de este archivo de configuración es
el siguiente:

noteimporta-2:/etc/bind# more named.conf

options {

// La siguiente linea indica que el directorio de
trabajo de la aplicación named "BIND es directory
"/var/cache/bind".
// En este directorio se guardan todos los archivos generados
transitorios generados por named.

directory "/var/cache/bind";

//La siguiente linea indica que el servidor no va a
responder de manera autoritativa si el dominio solicitado no
existe.

auth-nxdomain no;

};

//La siguienete tres lineas sirven para indicar el
archivo de la zona raiz donde de encuentran nombres de los
servidores raices y sus direcciones de IP asociadas.
//

zone "." {
type hint; //Tipo de servidor definido para esta zona
Cache.
file "/etc/bind/db.root";
};

//Las siguientes lineas sirven para indicar el archivo
de las zonas: localhost, 127.in-addr.arpa, 0.in-addr.arpa y
255.in-addr.arpa

zone "localhost" {
type master; //Tipo de servidor definido para esta zona
Master.
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master; //Tipo de servidor definido para esta zona
Master
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master; //Tipo de servidor definido para esta zona
Master
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master; //Tipo de servidor definido para esta zona
Master
file "/etc/bind/db.255";
};

Esta es la información contenida en el archivo
db.local

noteimporta-2:/etc/bind# more db.local

;
; BIND data file for local loopback interface

;
$TTL 604800

@ IN SOA localhost. root.localhost. (

1 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;
@ IN NS localhost.

@ IN A 127.0.0.1

Esta es la información contenida en el archivo
db.127

noteimporta-2:/etc/bind# more db.127

;

; BIND reverse data file for local loopback
interface

;

$TTL 604800

@ IN SOA localhost. root.localhost. (

1 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;
@ IN NS localhost.

1.0.0 IN PTR localhost.

Esta es la información contenida en el archivo
db.0

noteimporta-2:/etc/bind# more db.0

;
; BIND reverse data file for broadcast zone

;
$TTL 604800

@ IN SOA localhost. root.localhost. (

1 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;

@ IN NS localhost.

Esta es la información contenida en el archivo
db.255

noteimporta-2:/etc/bind# more db.255

;

; BIND reverse data file for broadcast zone

;

$TTL 604800

@ IN SOA localhost. root.localhost. (

1 ; Serial

604800 ; Refresh

86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;

@ IN NS localhost.

Los archivos de configuración presentados pueden
ser utilizados por un servidor de nombres de dominios
local.

1.2) Cabecera del protocolo DNS

1.2.1) Servidores de nombres de
dominio

El protocolo DNS trabaja en la capa de
aplicación. Si el segmento a enviar es menor que 512 Bytes
utiliza el protocolo UDP, de lo contrario utiliza el protocolo
TCP. El número de puerto que utiliza el protocolo DNS para
comunicarse con la capa de aplicación es el número
53.

Todos los mensajes generados por el protocolo DNS
utilizan un único formato de cabecera el cual se muestra en la
figura 1.4.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

| ID |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

|QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

| QDCOUNT |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

| ANCOUNT |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

| NSCOUNT |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

| ARCOUNT |

+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

Figura 1.4 Cabecera del protocolo
DNS

-. ID. Es un identificador de 16 bits
asignado por el programa. Este
identificador se copia en la respuesta correspondiente del
servidor de nombres y se puede usar para diferenciar respuestas
cuando concurren múltiples consultas.

-. QR. Flag que indica consulta(0) o
respuesta(1).

-. Op code. Campo de 4-bit que especifica el tipo de
consulta:

-. 0 consulta estándar(QUERY).

-. 1 consulta inversa(IQUERY).

-. 2 solicitud del estado del
servidor(STATUS).

-. Se reservan los otros valores para
su uso en el futuro.

-. AA. Flag de respuesta autoritativa. Si está
activo es una respuesta, especifica que el servidor de nombres
que responde tiene autoridad para el nombre de dominio enviado en
la consulta.

-. TC. Flag de truncado. Activo si el mensaje es
más largo de lo que permite la línea de
transmisión.

-. RD. Flag de recursividad. Este bit se copia en la
respuesta e indica al servidor de nombres una resolución
recursiva.

-. RA. Flag de recursividad disponible. Indica si el
servidor de nombres soporta resolución
recursiva.

-. Z. 3 bits reservados para uso futuro. Deben ser
cero.

-. Rcode. Código
de respuesta de 4 bits. Los posibles valores
son:

-. 0. Ningún error.

-. 1. Error de formato. El servidor fue incapaz de
interpretar el mensaje.

-. 2. Fallo en el servidor. El mensaje no fue procesado
debido a un problema con el servidor.

-. 3. Error en nombre. El nombre de dominio de la
consulta no existe. Sólo válido si el bit AA
está activo en la respuesta.

-. 4. No implementado. El tipo solicitado de consulta no
está implementado en el servidor de nombres.

-. 5. Rechazado. El servidor rechaza responder por
razones políticas.
Los demás valores se reservan para su usuario en el
futuro.

-. QDcount. Un entero sin signo de 16 bits que
especifica el número de entradas en la sección
"question".

-. ANcount. Un entero sin signo de 16 bits que
especifica el número de RRs en la sección
"answer".

-. NScount. Un entero sin signo de 16 bits que
especifica el número de RRs en la sección
"authority".

-. ARcount. Un entero sin signo de 16 bits que
especifica el número de RRs en la sección
"additional records".

1.3) Conclusiones

El sistema de nombres de dominio del protocolo DNS es
una base de datos distribuida que permite un control local sobre
los segmentos de la base de datos en general, logrando que cada
segmento esté disponible a lo largo de toda la red
Internet. El sistema de nombres de dominios utiliza un esquema
cliente servidor.

2) FTP

FTP significa File Transfer Protocol, protocolo de
transferencia de ficheros. Es un servicio de
Internet que permite transferencia de archivos. Se utiliza en
modo cliente-servidor: conectados a un ordenador remoto (que
actúa como servidor y que es un gran ordenador
permanentemente conectado a Internet) nuestro programa (cliente)
nos permite solicitar la transferencia de archivos en cualquiera
de las dos direcciones.

El servidor de archivos debe admitir las transferencias
de tipo FTP, por lo que deberá ser un ordenador
especialmente preparado para esta tarea. En nuestro ordenador
necesitaremos un programa específico; hay varios muy
populares, gratuitos, algunos incluso en castellano. A
nuestro programa le indicaremos en primer lugar cuál es el
servidor que vamos a utilizar.

Algunos servidores solamente admiten conexiones
identificadas: el usuario debe iniciar su conexión
mediante una identificación ("login") y una clave secreta
("password"). En ese caso, y dependiendo del usuario, se
podrá acceder a más o menos directorios del
servidor. Muchos servidores de FTP también admiten la
posibilidad de hacer una conexión no identificada,
anónima: en tal caso debemos utilizar como identificativo
la palabra "anonymous"; es de cortesía utilizar la
dirección de correo
electrónico como clave secreta, para que los
administradores del servidor puedan llevar una estadística de los diferentes accesos
anónimos.

Típicamente, los programas de FTP
muestran en dos "ventanas" los archivos correspondientes a los
directorios elegidos en el disco local y en el servidor. Existen
procedimientos
para cambiar el directorio de cualquiera de los dos ordenadores.
En el caso del servidor remoto, es posible que la
identificación de la conexión no nos permita
acceder a todos los directorios (esto puede ser así, tanto
para las conexiones identificadas como para las anónimas).
Algunos servidores nos permitirán obtener archivos
remotos, pero no nos consentirán el envío de
ficheros hacia el servidor. Típicamente la transferencia
se realiza seleccionando en la lista los archivos que se desean
transferir y pulsando en el botón correspondiente para que
se inicie la transferencia. Es posible transferir varios archivos
en bloque.

Las transferencias pueden realizarse en dos modos: texto
y binario; el primero es adecuado solo para los archivos de texto
(ASCII o ANSI),
mientras que el segundo es válido para todos los
ficheros.

Los programas más populares para realizar FTP son
conocidos por los siguientes nombres: CuteFTP y WS_FTP. Se pueden
conseguir fácilmente a través del Web y,
lamentablemente, están en inglés.

El sistema FTP está sufriendo una importante
devaluación porque la mayoría de las
transferencias pueden efectuarse desde páginas
Web y utilizando el programa navegador, lo cual facilita y
simplifica la tarea. Esto solo es válido para
transferencias descendentes (desde el servidor remoto al
ordenador local) y en formato "anónimo". El servicio
Web integra
perfectamente este modo de FTP, que es el utilizado por la
mayoría de los usuarios.

En cada directorio del servidor suele haber un archivo
de texto que explica el contenido de los otros ficheros y de los
subdirectorios. Con los programas más potentes es posible
acceder a este fichero (en una ventana) sin necesidad de guardar
una copia en el disco duro
local. Los directorios pueden estar organizados por temas, por
sistemas
operativos o por cualquier otro criterio.

El sistema FTP también es usado habitualmente
para colocar las páginas
Web en los ordenadores que se dedican a este servicio. Las
páginas son "creadas" en el disco duro y
luego son transferidas utilizando el sistema FTP.

2.1) Ejecución del FTP

Los pasos que hay que seguir para hacer FTP de una
máquina (local) a otra (remota), son los
siguientes:

Entrar en la máquina local (es decir, en la que
vamos a trabajar físicamente)

Una vez dentro, nos conectaremos a la máquina
remota, para lo cual haremos ftp, de una de las dos formas
siguientes:

% ftp nombre o dirección IP de la
máquina remota

o bién

% ftp

% FTP> open nombre o dirección IP de la
máquina remota

Una vez hecho esto nos preguntará el nombre de
usuario y la palabra clave, es decir:

Username nombre de usuario

password palabra clave

donde el nombre de usuario puede ser:

El user name (login) de una cuenta en la máquina
a la que voy a acceder; o bien

anonymous : para poder acceder
al servidor de ficheros de la máquina remota.
En este caso es aconsejable (y a veces obligatorio) introducir
como palabra clave, la dirección de correo
electrónico.

Una vez hecho esto, ya se ha establecido comunicación con la máquina remota a
través de FTP; por lo que el prompt del sistema desaparece
y aparece el prompt del FTP, que es:

FTP> o FTP-0>

A partir de este momento ya se pueden utilizar los
comandos
específicos del FTP.

2.2) Salir de una sesión de
FTP

Para salir de una sesión de FTP, se pueden
utilizar los siguientes comandos:

2.3) Ayuda

FTP posee varios comandos para obtener ayuda de
cómo utilizarlo:

2.4) Ficheros y
directorios

A continuación se da una relación de
comandos del FTP referentes al manejo de ficheros y
directorios.

2.5) Transferencia de
información

Con FTP se puede realizar la transferencia de
información en dos formatos diferentes: ascii y binario.
Por defecto, la transferencia se hace en modo ascii.

 Para saber el tipo de formato que está
activado para realizar las transferencias, se utiliza el
comando:

 Para hacer la transferencia en formato ascii
(lo hace por defecto), se utiliza el comando:

 Para hacer la transferencia en formato binario,
se utiliza el comando:

2.5.1) TRANSFERENCIA DE FICHEROS DE LA MAQUINA REMOTA
A LA LOCAL

Para transferir un fichero de la máquina remota a
la local, se utiliza el comando get o recv (ambos son
equivalentes). La sintaxis es:

o

Si se quiere cambiar el nombre del fichero que se va a
transferir, se pondrá:

Si se quieren transferir varios ficheros de la
máquina remota a la local, se utiliza el comando mget. La
sintaxis es:

o

Entonces:

* si está en Interactive mode on , va a pedir
confirmación antes de transferir cada uno de los ficheros
especificados.

* si está en Interactive mode off , no va a pedir
confirmación antes de transferir cada uno de los ficheros
especificados.

Para cambiar de mode on a mode off, o viceversa, se
utiliza el comando prompt, cuya sintaxis, es
simplemente:

Los nombres de los ficheros van separados por blancos y
pueden incluir los metacaracteres * e ?.

2.5.2) TRANSFERENCIA DE FICHEROS DE LA MAQUINA LOCAL
A LA REMOTA

Para transferir un fichero de la máquina local a
la remota, se utiliza el comando put o send (ambos son
equivalentes). La sintaxis es:

o

Si se quiere cambiar el nombre del fichero que se va a
transferir, se pondrá:

Si se quieren transferir varios ficheros de la
máquina local a la remota, se utiliza el comando mput. La
sintaxis es:

o

Análogamente, al caso de transferir ficheros con
el comando mget :

* si está en Interactive mode on , va a pedir
confirmación antes de transferir cada uno de los ficheros
especificados.

* si está en Interactive mode off , no va a pedir
confirmación antes de transferir cada uno de los ficheros
especificados. de los ficheros especificados.

Para cambiar de mode on a mode off, o viceversa, se
utiliza el comando prompt, cuya sintaxis, es
simplemente:

Los nombres de los ficheros van separados por blancos y
pueden incluir los metacaracteres * e ?.

3) DHCP

DHCP (Dynamic Host Configuration Protocol) son las
siglas que identifican a un protocolo empleado para que los hosts
(clientes) en
una red puedan
obtener su configuración de forma dinámica a través de un servidor del
protocolo. Los datos así obtenidos pueden ser: la
dirección IP, la máscara de red, la
dirección de broadcast, las características del DNS, entre otros. El
servicio DHCP permite acelerar y facilitar la
configuración de muchos hosts en una red evitando en gran
medida los posibles errores humanos.

Con una función similar a la del DHCP, pero con
algunas restricciones, existe el BOOTP o Internet Bootstrap
Protocol, el cual permite también la asignación de
la configuración de red en forma dinámica pero a partir de su
definición estática
para cada cliente en una base de datos en el servidor. Esta
información a diferencia de como se hace usualmente con
DHCP no puede ser renovada.

Básicamente el servicio DHCP/BOOTP funciona de la
siguiente forma. Existe un programa servidor en un host de la red
que escucha las solicitudes de los clientes y que en su
configuración almacena tablas de posibles direcciones IP a
otorgar además del resto de la información. Cuando
un cliente requiere del servicio envía una solicitud en
forma de broadcast a través de la red. Todos los
servidores alcanzados por la solicitud responden al cliente con
sus respectivas propuestas, este acepta una de ellas
haciéndoselo saber al servidor elegido, el cual le otorga
la información requerida. Esta información se
mantiene asociada al cliente mientras este no desactive su
interfaz de red (posiblemente porque se apague la máquina)
o no expire el plazo del “contrato''
(léase time). El plazo del “contrato'' o
renta es el tiempo en que un
cliente DHCP mantiene como propios los datos que le otorgó
un servidor. Este se negocia como parte del protocolo entre el
cliente y el servidor. Una vez vencido el plazo del contrato el
servidor puede renovar la información del cliente,
fundamentalmente su dirección IP, y asignarle otra nueva o
extender el plazo, manteniendo la misma información. El
cliente puede solicitar también la renovación o
liberación de sus Datos.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Figura: Representación
simplificada del protocolo DHCP

A continuación se listan los principales mensajes
que se intercambian como parte del protocolo DHCP y para que se
emplea cada uno:

DHCPDISCOVER – mensaje de broadcast de un cliente para
detectar los servidores.

DHCPOFFER – mensaje de un servidor hacia un cliente con
una oferta de
configuración.

DHCPREQUEST – mensaje de un cliente a un servidor
para:

a) aceptar la oferta de un
servidor determinado y por ende rechazar las otras

b) confirmar la exactitud de la información
asignada antes del reinicio del sistema

c) extender el contrato de una dirección IP
determinada

DHCPPACK – mensaje del servidor hacia un cliente para
enviarle la configuración asignada excluyendo la
dirección IP que ya fue aceptada.

DHCPNAK – mensaje del servidor al cliente para indicar
que la dirección que tiene asignada es incorrecta (por
ejemplo, cuando el cliente cambia de subred) o que el contrato ha
expirado.

DHCPDECLINE – mensaje del cliente para el servidor
indicando que aún está usando una dirección
determinada.

DHCPRELEASE – mensaje del cliente para el servidor para
indicar que renuncia a la dirección otorgada y cancela lo
que queda del contrato establecido anteriormente.

DHCPINFORM – mensaje del cliente para el servidor para
pedir sus parámetros de configuración excluyendo la
dirección IP que ya tiene asignada.

Un servidor de DHCP puede identificar a cada cliente a
través de dos formas fundamentales:

La dirección MAC (Media Access Control)
de la tarjeta de red
del cliente.

Un identificador que le indique el cliente.

Aunque la idea central del servicio DHCP es la
dinamicidad de las direcciones IP asignadas no se excluye la
posibilidad de utilizar direcciones fijas para algunos hosts que
por sus características lo requieran, ejemplo de
ello son las máquinas
proveedoras de disímiles servicios como el correo
electrónico o el DNS. Este tipo de host utilizaría
las ventajas del servicio para obtener el resto de los datos que
se pueden proveer mediante DHCP.

En Linux la
implementación del servidor de DHCP y de BOOTP la mantiene
la ISC (Internet Software Consortium). Esta
se empaqueta en la distribución Red Hat bajo el nombre dhcp.
Existen además otros dos paquetes asociados a este
servicio que implementan la parte cliente: pump y
dhcpcd.

3.1) Las ventajas del uso de DHCP son:

a) solo se configura un servidor para entregar
números IP para clientes de red

b) se entregan todos los parámetros
básicos de TCP/IP

c) facilidad de configuración

3.2) Las desventajas del uso de DHCP
son:

1. La seguridad
2. Al entregar números IP dentro de la red,
   habiendo un DNS, no hay un puente intermedio entre DNS y DHCP
   directo. Es decir, hay que agregar las máquinas "a mano"
   en el DNS
3. Mayor difusión de paquetes en la red, aunque
   hoy en día con la velocidad de
   las redes no parece
   demasiado problemático.

4) WWW

La tecnología World Wide
Web surge en la Organización Europea para la Investigación Nuclear "CERN" cuando Tim
Berners-Lee propone la necesidad de implementar un sistema de
gerencia de la
información a fin de solucionar la pérdida de
información producida por la dinámica de la
organización.

El consorcio W3C fue creado en octubre de 1994 con el
fin de estandardizar e implementar protocolos y especificaciones
que promuevan:

-. Nuevas formas de documentación de la información y
de comunicación.

-. La implementación de protocolos y
especificaciones no propietarias para asegurar la
interoperabilidad entre sistemas
operativos.

Desde entonces, la tecnología World Wide
Web se ha convertido en el paradigma
más influyente en los actuales sistemas de
información.

4.1) Bases de la tecnología World Wide
Web

La tecnología del World Wide Web es un sistema de
información el cual esta compuesto por agentes
interconectados. Un agente es un programa que actúa a
nombre de otra persona, entidad,
o proceso con el fin de intercambiar información y
presentar la información en un formato legible al usuario.
Por ejemplo un navegador de paginas webs es un agente (Konqueror,
Mozilla) utilizado por el usuario para accesar las paginas webs
que se encuentran en los agentes servidores (Apache, Tomcat,
etc). Para que los agentes puedan intercambiar información
y presentar la información en un formato legible al
usuario, los agentes deben satisfacer tres
propiedades:

-. Representación.

-. Identificación.

-. Interacción.

4.4.1) Propiedad de
representación

La propiedad de
representación es utilizada para estructurar la
información contenida en un documento Web. Esta propiedad
utiliza una combinación de grafos en
forma de árbol, grafos
directos y objetos para estructurar la información. En un
documento Web, los siguientes tipos de información pueden
ser estructurados: Texto, imágenes y
objetos. La información contenida en un documento Web es
estructurada en forma de árbol donde cada nodo es
considerado un objeto. Cada nodo puede estar compuesto por
atributos, nodos hijos y contenido. Cada nodo es considerado una
entidad. Una entidad un recurso que goza de identidad [3].
Por ejemplo un documento Web es un recurso, por lo tanto todos
los nodos contenidos en el documento Web son recursos. Un recurso
es nombrado e identificado por la propiedad de
identificación. Una vez identificado un recurso, los
agentes utilizan la propiedad de interacción para accesar,
actualizar, eliminar o intercambiar recursos entre
agentes.

El principal estándar internacional utilizado
para representar la información de documentos
electrónicos es el estándar ISO 8879. Este
estándar es conocido con el nombre de Standard Generalized
Mark Up Language (SGML) [5][6]. El SGML es un metalenguaje
utilizado para definir, describir y normalizar documentos
electrónicos basados en etiquetas. Una etiqueta es
utilizada para dar: significado, estructura, nombre a un nodo,
entidad y acción aplicada a la información
etiquetada. La mayoría de las especificaciones de la
tecnología World Wide Web son aplicaciones del SGML o
derivan del SGML. Por ejemplo: El lenguaje
extensible de etiquetas (Extensible Mark Up Language ) (XML) es el
principal estándar para estructurar la información
en la tecnología World Wide Web. Este estándar
deriva del SGML. Las especificaciones XML permiten a
los usuarios definir las etiquetas de un documento modelo el cual
es utilizado para dar estructura y significado a la
información de un documento. Un documento modelo se
define con las especificaciones XML Schema o Document Type
Definition [5][6][8][13]. Una vez definido un documento modelo se
pueden crear múltiples documentos. De esta manera la
información de un documento es estructurada y normalizada.
Las especificaciones XML delega la función de formato o
presentación de la información a las
especificaciones XSL y CSS [11][15].

4.1.2) Propiedad de
Identificación

La función de la propiedad de
identificación es identificar, localizar y nombrar los
recursos definidos por la propiedad de representación los
cuales son almacenado en los repositorios de información
de los agentes. Las especificaciones del RFC 2396 (URI) satisface
la propiedad de identificación [3]. Un URI esta compuesto
por tres definiciones:

-. Uniformidad.

-. Recurso.

-. Identificador.

La definición de Uniformidad establece el
conjunto de reglas que definen las secuencias correctas de los
elementos que conforman a un URI. Este conjunto de reglas
proporciona un mecanismo común para interpretar los
diferentes tipos de identificadores de recursos.

La definición de recurso es el mapeo conceptual a
un nodo. Este mapeo es visto como un grafo directo entre dos
nodos.

La definición de identificador es un objeto que
actúa como referencia a algo que tiene identidad.
Ejemplo un recurso.

La sintaxis genérica que representa a un URI es
la siguiente:

<esquema>:<parte especifica del esquema
>

Dicha sintaxis es utilizada para definir las
aplicaciones de un URI. Entre estas aplicaciones se encuentran
los localizadores de recursos (URL) y nombre de recursos
(URN).

Un URL define a un subconjunto de URI que identifican
los siguientes parámetros: nombre del recurso, Localidad
del recurso y protocolo de acceso del recurso. En general la
parte especifica del esquema de un URL es el
siguiente:

<Esquema>://<usuario>:<password>@<host>:<puerto>/<ruta
del recurso>

El parámetro <Esquema> identifica el
protocolo de acceso del recurso. Los parámetros
<usuario> y <password> son opcionales ya que la
presencia de estos parámetros en un URL depende del
protocolo de acceso del recurso. Por ejemplo el protocolo FTP
permite el uso de estos dos parámetros. El
parámetro <host> define el nombre de dominio
completamente calificado del agente. [18]. El parámetro
<puerto> identifica el número de puerto del agente.
Y el parámetro <ruta del recurso> identifica el
nombre del recurso.

En la figura 1.1 podemos apreciar el siguiente URL:
http://www.debian.org..

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Figura 1.1 Uniform Resource Locator
(URL)

Este URL identifica los siguientes
parámetros:

-. ¿Cómo se llama el recurso (En este caso
el documento Web)?

Por defecto index.html

-. ¿Dónde se puede localizar este
recurso?

En el directorio raíz incluido en el directorio
virtual del servidor de páginas Web cuyo nombre de dominio
es www.debian.org.

-. ¿Cómo puede ser accesado el
recurso?

La página puede ser accesada con el protocolo
HTTP.

Un URL puede ser absoluto o relativo. Un URL absoluto
identifica explícitamente el nombre del recurso, donde se
localiza el recurso, y cómo el recurso puede ser accesado.
Una vez que un recurso halla sido accesado, se puede utilizar un
URL relativo para identificar los recursos de un documento. Un
URL relativo no identifica el mecanismo de acceso primario. Por
ejemplo, el siguiente: URI index.html#2 se puede
clasificar como un URL relativo ya que el recurso index.html fue
identificado y accesado por un URL absoluto, y el recurso 2
incluido en el documento index.html es identificado por el
siguiente fragmento URI: # 2.

Los nombres uniformes del recurso (URN) no identifican
la ubicación física del recurso
mas bien son utilizados como identificadores persistentes e
independientes de recursos y están diseñados para
hacer factible el mapeo de nombres de recursos. La sintaxis
genérica de un URN se puede representar de la siguiente
manera:

<URN> ::= "urn:" <NID> ":"
<NSS>

Un URN utiliza la secuencia "urn:" para identificar el
esquema donde el parámetro NID especifica la
identificación del espacio de nombres, y <NSS>
especifica la secuencia del espacio de nombres de recursos de un
documento. Una de las ventajas al utilizar un URN es la capacidad
para el programador de nombrar sus propios recursos con el fin de
evitar colisiones que pueden ocurrir cuando muchos documentos XML
van a ser combinados en uno [14].

4.1.3) Propiedad de Interacción

Una vez que un recurso es identificado por la propiedad
de identificación, los agentes utilizan la propiedad de
interacción para accesar, actualizar, eliminar o
intercambiar recursos entre agentes vía protocolos. El
principal protocolo implementado en los agentes en la
tecnología del World Wide Web es el protocolo (HTTP) [4].
El protocolo http funciona a partir de solicitudes. Las
solicitudes más comunes del protocolo http son:

-. GET. Es una solicitud para leer un recurso.Ejemplo
una pagina Web.

-. PUT. Es una petición para almacenar un
recurso.

-. DELETE. Indica una solicitud para remover un
recurso.

-. POST. Es una petición que añade
información a un recurso nombrado.

-. HEAD. Es una petición para leer la cabecera
de un página
Web.

Cada solicitud hecha por el navegador a través
del protocolo http recibe una respuesta acompañada por un
código
de estado. El
código de estado más común es el
código 200 (OK), este código indica que el servidor
respondió a la solicitud satisfactoriamente. Para conocer
las solicitudes y respuestas del protocolo http ver las secciones
9 y 10 del RFC 2616.

4.2) Conclusiones

La tecnología del World Wide Web es un sistema de
información el cual esta compuesto por agentes
interconectados.

Un agente es un programa que actúa a nombre de
otra persona, entidad,
o proceso con el fin de intercambiar información y
presentar la información en un formato legible al
usuario.

Para que los agentes puedan intercambiar
información y presentar la información en un
formato legible al usuario, los agentes deben satisfacer tres
propiedades:

-. Representación.

-. Identificación.

-. Interacción.

El consorcio W3C fue creado en octubre de 1994 con el
fin de estandardizar e implementar protocolos y especificaciones
que promuevan:

-. Nuevas formas de documentación de la
información.

-. Nuevas formas de comunicación.

-. La implementación de protocolos y
especificaciones no propietarias para asegurar la
interoperabilidad entre sistemas
operativos.

5) SMTP

El significado de las siglas de SMTP, es Protocolo
Simple de Transmisión de Correo ("Simple Mail Transfer
Protocol"). Este protocolo es el estándar de Internet para
el intercambio de correo electrónico. SMTP necesita que el
sistema de transmisión ponga a su disposición un
canal de comunicación fiable y con entrega ordenada de
paquetes, con lo cual, el uso del protocolo TCP en la capa de
transporte, es
lo adecuado. Para que dos sistemas
intercambien correo mediante el protocolo SMTP, no es necesario
que exista una conexión interactiva, ya que este protocolo
usa métodos de
almacenamiento y
reenvío de mensajes.

Son tres los protocolos que se aplican a un correo de
esta clase. El termino SMTP es frecuentemente y
erróneamente usado para referirse a la combinación
del grupo de
protocolos involucrados en el envío de correo
electrónico. Esto porque los tres están
estrechamente relacionados, pero estrictamente hablando SMTP es
uno de los tres protocolos. Los tres protocolos son:

·Un estándar para el intercambio de
correo entre dos computadores (RFC 821), el cual especifica el
protocolo usado para enviar correo entre "host" TCP/IP. Este
estándar es SMTP.

·Un estándar del formato del mensaje de
correo, contenido en dos RFC:

-RFC 822 describe la sintaxis del campoo de
título o cabecera del correo electrónico y
describe la interpretación del grupo de campos de la
cabecera.

-RFC 1049 describe como un conjunto de otros tipos de
documentos, que tengan texto ASCII, y que pueden ser usados en
el cuerpo del correo electrónico. El nombre del
protocolo oficial para este estándar es MAIL.

·Un estándar para el "routing" de "mail"
usando el sistema de nombres de dominio, descrito en RFC 974.
El nombre oficial del protocolo para este estándar es
DNS-MX.

5.1) Modo de Comunicación
SMTP

Cuando un servidor de SMTP, requiere transmitir un
mensaje a otro servidor SMTP, el emisor (servidor que inicia la
sesión SMTP) establece una conexión con el receptor
(servidor que recibe petición de establecer sesión
SMTP). Esta conexión es unidireccional, es decir, el
emisor puede enviar correo al receptor, pero durante esa
conexión, el receptor no puede enviar correo al emisor. Si
el receptor tiene que enviar correo al emisor, tiene que esperar
a que finalice la conexión establecida y establecer otra
en sentido contrario, cambiando los papeles de emisor y receptor.
Una vez establecida la conexión, el emisor envía
comandos y mensajes. Los mensajes pueden tener como destino el
receptor o un intermediario para llegar

a un destino más lejano. El receptor puede enviar
al emisor respuestas y códigos de estado. Los comandos son
cadenas de caracteres que se pueden entender fácilmente y
las respuestas son códigos numéricos seguidos de
una explicación del código. Por lo señalado,
SMTP (RFC 821) está basado en entrega "end-to-end". Esto
es diferente del principio guardar y enviar común en
muchos sistemas de mensajería electrónica, donde el mensaje puede pasar a
través de un numero de maquinas intermediarias su camino
al destino final.

Existen aplicaciones que permiten intercambiar correo
entre el sistema de mensajería electrónica TCP/IP SMTP y el sistema de
correo localmente usado. Estas aplicaciones son llamadas
"Gateways" de correo ("Gateways") o "Bridges" de correo. Enviar
correo a través de un "Gateway" puede alterar la entrega
"end-to-end". El protocolo SMTP solo puede garantizar la entrega
al "Gateway" y no al destino final que está localizado
más allá de la red TCP/IP. Cuando el "Gateway" es
usado, la transmisión SMTP "end-to-end" se realiza en
varias partes, de "host" a "Gateway", "Gateway" a "host" o
"Gateway" a "Gateway". El comportamiento
más allá del "Gateway" no está especificado
por SMTP. En la Fig. 2-1 se observa la
comunicación a través de los
"Gateways".

SMTP se basa en el modelo de comunicación que se
muestra en la
Fig. 2-2.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

En este modelo de comunicación en primera
instancia un usuario establece la petición de enviar un
mensaje a través de correo electrónico, luego el
Emisor SMTP establece una conexión de dos hilos con el
Receptor SMTP. El Receptor SMTP puede ser la destinación
última o un intermediario, como es el caso del "Gateway".
El Emisor SMTP genera comandos que son contestados por el
Receptor SMTP.

5.2) Flujo de Transferencia de los Mensajes de
Correo Electrónico

Aunque los comandos y respuestas son estrictamente
definidos por el protocolo, el intercambio de ellos entre emisor
y receptor resultar fácil de comprender, como se muestra
en la Fig. 2-3a y la Fig. 2-3b.

Todo intercambio de comandos/respuesta/datos
(líneas de texto) son delimitados por un CRLF, los que no
se incluyen en las Fig. 2-3a y Fig. 2-3b para facilitar la
compresión del protocolo SMTP. Toda respuesta tiene un
código numérico al principio de la
línea.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

El ejemplo de trasferencia se detalla a
continuación:

·El Emisor SMTP establece una conexión TCP
con el destino SMTP y luego espera que el servidor envíe
un 220 Servicio de lectura de
mensaje o un 421 Servicio de mensaje no habilitado, esto ultimo,
cuando la destinación está temporalmente
inhabilitada para procesar el mensaje.

·HELO (Es una abreviación de "hello") es
enviado para que el receptor identifique si el Emisor SMTP
está enviando su nombre de dominio. El Emisor SMTP puede
usarlo para verificar si contactó la destinación
SMTP correcta. Si el Emisor SMTP soporta Extensión de
Servicios ("Service Extensions") SMTP, como está definido
en RFC 1651 (Extensión de Servicios es explicada en
detalle en la subsección 2.1.4), puede sustituir por un
comando EHELO el comando HELO. El Receptor SMTP que no soporta
Extensión de Servicios, responde con una sintaxis de error
500, que es un comando de mensaje no reconocido. El Emisor SMTP
debe entonces reintentar con HELO, o si el emisor no puede
transmitir el mensaje sin uno o más de los comandos que
son propios de Extensión de Servicios, éste debe
enviar un mensaje QUIT.

·Si el Receptor SMTP soporta Extensión de
Servicios, responde con un mensaje multilínea 250 OK, que
incluye una lista de extensión de servicios que
soporta.·El Emisor SMTP, luego de recibir este comando 250
OK, inicializa la transferencia del mensaje enviando el comando
MAIL al Receptor SMTP. Este comando contiene el "reverse-path"
(habitualmente se utiliza para el envío del nombre de
dominio del emisor) que puede ser usado para reportar errores.
Esta " reverse-path" puede contener más que solamente el
nombre de dominio de usuario (del emisor), en adición,
éste puede contener una lista de "host" de la ruta.
Ejemplo de esto es cuando se pasa por un "Bridge" o cuando se
provee explícitamente información de la uta en la
dirección de destino. Si el Receptor SMTP acepta responde
con un 250 OK.

·El segundo paso del intercambio de mensajes a
través de correo electrónico, consiste en proveer
al servidor SMTP la destinación para el mensaje. Se
realiza enviando uno o más comandos RCPT TO:forward-path.
Cada uno de estos envíos es contestado por parte del
Receptor SMTP con un 250 OK, si la destinación es conocida
por el servidor, o un 550 NO, si tal usuario no es
conocido.

·Cuando todos los comandos RCPT son enviados, el
Emisor SMTP emite un comando DATA para notificar al Receptor SMTP
que el contenido del mensaje será el siguiente
envío. El Receptor SMTP responde con 354 Start mail input,
end with CRLF CRLF. Esta secuencia final es la que el Emisor SMTP
utiliza cuando termina el envío de datos del mensaje a
transferir.

·El cliente ahora envía las líneas
de datos, una a una, finalizando con la secuencia CRLF.CRLF,
secuencia que el Receptor SMTP responde con un 250 OK o un
mensaje de error si es que algo ha fallado.

·Luego se tienen algunas opciones:

-El Emisor SMTP no tiene más mensajes qque
enviar, por lo que se finaliza la conexión con un comando
QUIT, a lo cual el Receptor SMTP responde con 221 Service closing
transmission channel.

-Si el Emisor SMTP no tiene más mensajes que
enviar, pero quiere recibir mensajes del otro extremo. Este
envía el comando TURN. Los dos extremos de la
comunicación SMTP ahora cambian roles de
Emisor/Receptor y el nuevo Emisor SMTP (Anterior Receptor SMTP)
puede enviar mensajes partiendo del paso 3 del esquema mostrado
en la Fig. 2-3a.

-Si el Emisor SMTP tiene otro mensaje ppara enviar
retorna al paso 3 y envía un comando MAIL.

Ciacci Miguel

Facultad de Educación a
Distancia

Ingeniería de Sistemas