
SendMail (I): Fundamentos del Correo Electrnico
Autor: Juan Antonio Martnez Castao
E-Mail: jantonio@dit.upm.es

Indice:
1- Introduccin
2- Filosofa 
3- El RFC 822
4- Las Cabeceras de un mensaje
5- Extensiones MIME
6- Resumen. Conclusiones
7- Referencias

Entradilla

Iniciamos aqu una serie de artculos sobre uno de los componentes ms
conocidos, antiguos y potentes subsistemas de nuestro servidor: El gestor
de correo electrnico: SendMail. En este primer artculo desarrollaremos
los conceptos bsicos del correo electrnico, dejando para posteriores
entregas la configuracin y detalles de SendMail

Introduccin

	Podramos decir que el correo electrnico ha sido el padre de InterNet:
antes incluso de existir el concepto de Red Local, existan en el mundo UNIX
una serie de utilidades para transferencia de datos entre mquinas a travs de
modem. Es el venerable -y todava ampliamente usado- UUCP. Bsicamente no era
sino una serie de utilidades que permitan transferir ficheros entre dos
mquinas ( UUCP es acrnimo de Unix-to-Unix-CoPy ) y ordenar la ejecucin
remota de diversas aplicaciones. En paralelo con estos programas, todos los
sistemas incluan una utilidad para intercambiar mensajes entre los diversos
usuarios de un sistema. Esta utilidad se denominaba -cmo no- "mail"

	No tardo mucho en surgir la idea de que los intercambios de mensajes
pudieran producirse entre diversas maquinas, aprovechando los programas
existentes "mail" y "uucp". En este momento surgi la necesidad de establecer
un mecanismo para saber de dnde venan los mensajes, a dnde iban, y cmo
y por dnde deban encaminarse ( recordad que no tenemos an red local, sino
un monton de sistemas ocasionalmente conectados va mdem ). La solucin a
este problema fue un nuevo programa "delivermail" que todava aparece en
algunas distribuciones de UNIX'es basados en 4.1 BSD  ( ao 1979 )

	Con la aparicin de ARPANet y las primeras redes locales, la complejidad
del sistema de correo, del encaminamiento y los problemas aadidos de gestin
de listas, modos de conexin entre mquinas, diferentes sistemas "UNIX", etc
hacen que "delivermail" crezca y crezca en complejidad. Finalmente en 1980
se publican los primeros Drafts sobre lo que ser la futura InterNet ( lo que
ahora tenemos ) y aparece el primer RFC sobre un protocolo especfico para
transferencia de correo electrnico: el Simple Mail Transfer Protocol ( SMTP )

	Por entonces un estudiante de la Universidad de Berkeley, Eric Allman
modifica "delivermail" y lo transforma en "sendmail". La primera versin
pblica de sendmail apareci en la distribucin 4.1c de BSD UNIX, que fue
tambin la primera versin de UNIX que soport de base TCP-IP 

	Desde entonces SendMail ha evolucionado rpidamente, creciendo en
potencia y en complejidad. En el momento de escribirse este artculo, la
ltima versin oficial es la 8.9.1. La potencia de este programa ha hecho
que siendo el "corazn" de la conectividad UNIX, sendmail sea tambien el
programa ms difcil de configurar -que no de mantener- Por ello han aparecido
diversas variantes de sendmail, que hacen hincapi en los mtodos de 
configuracin, asi como diversos agentes de correo mucho ms simples -y
mucho menos potentes- como puedan ser smail o qmail


Filosofa de funcionamiento del correo electrnico

Ya est bien de historia. Vamos con un ejemplo:

[jantonio@cochito jantonio]$ telnet cochito.micasa.es smtp
Trying 192.1.1.1...
Connected to cochito.micasa.es.
Escape character is '^]'.
220 cochito.micasa.es ESMTP Sendmail 8.8.7/8.8.7; Thu, 6 Aug 1998 23:14:05 +0200
HELO cochito
250 cochito.micasa.es Hello jantonio@cochito.micasa.es [192.1.1.1], pleased to meet you
MAIL FROM: jantonio
250 jantonio... Sender ok
RCPT TO: jamc@eurielec.etsit.upm.es
250 jamc@eurielec.etsit.upm.es... Recipient ok (will queue)
DATA
354 Enter mail, end with "." on a line by itself
Hola mundillo
.
250 XAA00868 Message accepted for delivery
QUIT
221 cochito.micasa.es closing connection
Connection closed by foreign host.

	Podramos llamar a este listado como el "hello world" del correo 
electrnico. La primera lnea es una invocacin mediante "telnet" al puerto
smtp ( definido en el /etc/services como "25/tcp" ) lo siguiente es un dilogo
con el servidor en "lenguaje SMTP"

	Antes de explicar en detalle el protocolo SMTP, vamos a ver qu es lo
que sendmail debe ser capaz de hacer, y las razones de su complejidad. Para 
ello establecemos una primera distincin: Agentes de "entrega" de correo y
Agentes de "distribucin" de correo ( en ingls MUA -Mail User Agent y MTA
-Mail Transfer Agent-, respectivamente )

	Un MUA se encarga de la distribucin local de correo. Bsicamente es
un interfaz de usuario, que permite editar, componer y enviar mail local. 
Ejemplos tipicos son "mail" "pine" "mailx" Algunos MUA's ms elaborados
permiten "tunelizar" correo a travs de pasarelas ppp, o gestionar listas
( p. ej "fetchmail" o "procmail" ). Todos los MUA's saben hablar SMTP para
enviar correo no local

	Un MTA se encarga del encaminamiento del correo entre los diversos
sistemas. Entre sus funciones se cuentan:
- Detectar si el mail es local, y en caso afirmativo, ceder el control a un
  MUA local
- En el caso de mail remoto, debe ser capaz de reescribir las direcciones
  de correo del destinatario y remitentes del correo de manera que sean 
  compatibles con el sistema remoto y el agente de transporte
- Debe ser capaz de reconocer aliases, manejar ficheros de forwarding
- Se deben poder discriminar diversos agentes de distribucin de correo:
  faxes, uucp, bitnet, arpanet, etc.
- Puesto que cada sistema tiene sus propios usuarios, configuraciones,
  requerimientos, condicionantes, etc, el MTA debe ser altamente configurable
  de manera que ningun potencial usuario se vea limitado
- Especial hincapi debe hacerse en cuanto a la seguridad: no debemos olvidar
  que estamos conectando con una maquina remota, cuya configuracin 
  desconocemos, y que debemos hacer lo posible por autentificar tanto el
  origen como el destinatario del mensaje
- El encaminamiento del correo debe ser rapdo, fiable y que consuma pocos
  recursos. El sistema debe garantizar que el correo llegue a su destino
  o sea rechazado como "no valido". pero NUNCA debe perderse por el camino
  Vamos, que igualito que en la vida real....

Por todo ello, SendMail, y en general todos los MTA's hacen hincapi
en la rapidez, la posibilidad de configuracin y el bajo consumo de recursos.
 Cmo conjuntar estos dos puntos, aparentemente irreconciliables? pinsese, 
por ejemplo, que slo el "parser" para leer la configuracin del sistema de
correo consume ms de la mitad del tiempo de CPU que necesita sendmail para
saber qu hacer con nuestro inocente "hola mundillo". Una alternativa es
tener permanentemente en memoria una database con la configuracin, pero 
entonces nos encontramos con el problema de gasto de recursos...

El truco consiste en hacer un fichero de configuracin cuyo anlisis sea
inmediato para sendmail, aun a costa de hacerlo incomprensible para los 
humanos. Un ejemplo tipico, extraido de un /etc/sendmail.cf:

....
R$* < @ > $*            $@ $>Parse0 $>3 $1              user@ => user
R< @ $=w . > : $*       $@ $>Parse0 $>3 $2              @here:... -> ...
R$- < @ $=w . >         $: $(dequote $1 $) < @ $2 . >   dequote "foo"@here
R< @ $+ >               $#error $@ 5.1.1 $: "user address required"
R$* $=O $* < @ $=w . >  $@ $>Parse0 $>3 $1 $2 $3        ...@here -> ...
....

Incomprensible, verdad?. Bueno, con un poco de entrenamiento... No debemos
olvidar que se trata de un codigo escrito para que lo entienda el programa, 
no el usuario

	Hasta hace unos aos, configurar sendmail era una tarea para autnticos
gurs. La frase "No puede llamarse guru de UNIX quien nunca ha editado a mano
un sendmail.cf" afortunadamente ha pasado a la historia. ahora, mediante el
uso de macros y de directivas "prefabricadas" de configuracin, la configuracin
de sendmail est convirtiendose en una tarea rutinaria, y slo es necesario
editar el fichero en casos desesperados.

	Como conclusin podemos decir que todas las reglas que van a definir el
comportamiento de nuestro sendmail estn definidas en /etc/sendmail.cf. 
SendMail no es sino el operario de la oficina de correos que coge cada carta e
intenta buscarse la vida para hacer que llegue a su destino, en funcin de lo
que el administrador del sistema le ha dicho que puede y debe hacer

El protocolo SMTP

Antes de introducirnos en la instalacin y configuracin de sendmail - que
ser desarrollada en mayor amplitud en prximos nmeros de LINUX ACTUAL - 
echaremos un vistazo al protocolo SMTP. para ello miremos los siguientes RFC's

- Standard for the format of ARPA Internet text messages: RFC-822
- Simple Mail Transfer Protocol: RFC-821
- Extensions for SMTP and Internet text message format: RFC-1123
- Domain Name Convention for Internet User Aplications (DNS): RFC-819
- UUCP Mail Interchange Format Standards: RFC-976
- Multi-purpose Internet Mail Extensions (MIME) RFC-1341

o mejor, una vez superado el susto volvemos a nuestro telnet y tecleamos:
[jantonio@cochito jantonio]$ telnet cochito.micasa.es smtp
Trying 192.1.1.1...
Connected to cochito.micasa.es.
Escape character is '^]'.
220 cochito.micasa.es ESMTP Sendmail 8.8.7/8.8.7; Fri, 7 Aug 1998 00:22:12 +0200
help
214-This is Sendmail version 8.8.7
214-Topics:
214-    HELO    EHLO    MAIL    RCPT    DATA
214-    RSET    NOOP    QUIT    HELP    VRFY
214-    EXPN    VERB    ETRN    DSN
214-For more info use "HELP <topic>".
214-To report bugs in the implementation send email to
214-    sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info


Todos los comandos ( realmente dsn no es un comando, sino una serie de flags
que indican que hacer con el destinatario y el remitente ) constan de cuatro
letras ( idealmente maysculas; los nuevos MTA's reconocen indistintamente
maysculas y minsculas )

	- HELO ( de "hello" ) inicia el dialogo e identifica la maquina desde 
	  la que se establece la conexin. Los nuevos sendmails autentifican el 
	  saludo, de manera que no le podemos "mentir" a sendmail
	- EHLO ( de "Extended hello" ) es equivalente, solo que le indica al
	  sistema remoto que "sabemos" hablar extended SMTP
	- MAIL FROM: <remitente> indica que vamos a enviar un mensaje, y que
	  el origen ( sender ) es el indicado
	- RCPT TO: <destinatario> indica la direccion de destino del correo.
	  Pueden ser especificados diversos destinos, pero solo un remitente
	- DATA indica el comienzo del mensaje. Para finalizar la introduccin
	  de datos, se introduce una lnea que comience por punto "."
	  En el caso de querer introducir una lnea que comienze por "." dentro
	  del texto, lo haremos duplicando dicho punto ".."
	- NOOP ( "No Operation" ) pues eso...
	- QUIT para finalizar la sesion
	- EXPN ( "Expand" ) sirve para indicar como se va a resolver la 
	  direccin de correo del RCPT que le indiquemos.
	- VRFY ( "Verify" ) sirve para saber si el sendmail remoto va a aceptar
	  o no una direccin de correo. Puesto que un antiguo truco de hacker
	  consista en buscar usuarios "standard" en un sistema preguntando
	  con VRFY y EXPN al sendmail de dicho sistema, estos son inhabilitados
	  en los sendmails modernos
	- VERB ( "Verbose" ) presenta mensajes en modo verboso. SMTP especifica
	  que las respuestas a las peticiones del protocolo son salidas 
	  numericas. Poniendo verbose a ON se le aaden diversos textos que
	  sirven de ayuda a interpretes humanos.
	- RSET ( "Reset" ) resetea la introduccion de datos, partiendo de cero
	- TURN indica al sendmail remoto, que el cliente pasa a modo "escucha"
	  pudiendo actuar el antiguo servidor como cliente. Utilizado
	  antiguamente en conexiones telefnicas, casi ningun MTA lo utiliza
	  hoy en da
	- ETRN fuerza el envio de correo dirigido a un determinado host o
	  dominio en el servidor. su implementacin y uso es opcional

Con estos pocos comandos se construye toda la historia....

Las cabeceras del mensaje

	Ahora que sabemos como se enva el mensaje, vamos a ver cmo se
identifica cada mensaje, y como extraer e introducir informacin sobre
la fecha, el origen y destino, la ruta, las extensiones, el status, etc...
para ello cogemos el RFC-822 y empezamos a estudiar las cabeceras de un
mensaje de correo electrnico. Veamos un ejemplo:


From mdw21@hermes.cam.ac.uk  Thu May  7 00:34:41 1998
Return-Path: <mdw21@hermes.cam.ac.uk>
Received: from sanson.dit.upm.es (sanson-cdc.dit.upm.es [138.4.1.130])
        by drake.dit.upm.es (8.8.7/8.8.7) with ESMTP id AAA01509
        for <jantonio@drake.dit.upm.es>; Thu, 7 May 1998 00:34:41 +0200
Received: from violet.csi.cam.ac.uk (violet.csi.cam.ac.uk [131.111.8.58]) by san
son.dit.upm.es (8.8.4/3.14) with ESMTP id BAA14729 for <jantonio@dit.upm.es>; Th
u, 7 May 1998 01:34:16 +0200 (MET DST)
Received: from mdw21.clare.cam.ac.uk ([131.111.214.145] helo=mdw21)
        by violet.csi.cam.ac.uk with smtp (Exim 1.92 #1)
        for jantonio@dit.upm.es
        id 0yXDhZ-00075a-00; Thu, 7 May 1998 00:34:17 +0100
Message-ID: <001501bd7947$a68f73e0$91d66f83@mdw21.clare.cam.ac.uk>
From: "Mark Wever" <mdw21@cam.ac.uk>
To: "Juan Antonio Martinez" <jantonio@sanson.dit.upm.es>
Subject: Re: Puzzle bobble source code for Linux 
Date: Thu, 7 May 1998 00:35:27 +0100
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Status: RO
X-Status: 

Hello, you may remember you wrote to me ages ago about PB.
....

Todo mensaje de correo trae una cabecera y un cuerpo. las cabeceras empiezan
siempre con un "From " al comienzo de la lnea y acaban con una linea en 
blanco. El cuerpo empieza y acaba siempre con una linea en blanco. Aunque
Microsoft se empee en decir lo contrario, el RFC-822 prohibe expresamente
utilizar en las cabeceras caracteres no-ASCII ( cdigos mayores que 0x7f ). 
Esto implica que ninguna direccion de correo puede tener tildes, ees, etc
 
Echemos un vistazo a los datos que son relevantes a Sendmail.

- Tenemos en primer lugar el campo From. Indica quin envia el mensaje. Puesto
que el SMTP no impone ninguna restriccin al mensaje MAIL FROM: es mision de
sendmail autentificar dicho sender. Por ello intenta hacer una peticin de
identd con la mquina remota, y en el caso de que la conexin no la
establezca un "trusted user" ( otro sendmail, por ejemplo ) genera en la
cabecera un mensaje de X-Autentication-Warnig indicando que es posible que el
sender no corresponda a quien dice ser

- Return-path: indica a sendmail, por donde debe ser rutado el mensaje en caso
de devolucin. No todos los mailers hacen caso de dicho mensaje, salvo que
sendmail sea expresamente instrudo para hacerlo. Otro truco antiguo de hacker
consista en engaar al correo para que el que reciba el mensaje, al responder
respondiera a la mquina "ladrona" en lugar de a la persona suplantada. Existen
diversas variantes al uso "truculento" de esta cabecera, cuyo estudio se deja
a los fanticos del "hackering"

- Received: indica todas y cada una de las mquinas por donde ha ido pasando el
mensaje. Cada MTA inserta un "Received", de manera que estudiando detenidamente
la cabecera es posible hacer el seguimiento de un mensaje ( a menos que la
cabecera este "trampeada", lo que exige un cierto nivel de conocimiento... )
Asimismo, Contando el nmero de "Received" que contiene una cabecera podemos
especificar un "time-to-live" de un mensaje, definiendolo como el numero de
saltos que puede dar un mensaje entre mquina y mquina antes de considerar
que dicho mensaje no puede ser entregado. De nuevo, un parmetro del fichero
de configuracin de sendmail, define el TTL de un mensaje

- Message-ID: es una etiqueta que identifica el mensaje y garantiza que sea
unico en toda la Internet. El mtodo habitual consiste en formar dicho ID con
el nombre de la maquina origen, la fecha del mensaje y el nombre asignado en
la cola de envio

- X-Priority: Indica al MTA la prioridad con que debe ser tratado un mensaje
El fichero de configuracin de sendmail define diversos niveles de prioridad, 
asignando diversos valores a diversas etiquetas ( "normal", "urgent", etc )
Cuando sendmail procesa la cola de mensajes en espera de ser enviados, intenta
enviar primero los de mayor prioridad

No podemos inclur aqu todas las posibles cabeceras por motivos ms que
evidentes de espacio. Remitimos al lector a la lectura del RFC-822 y a sus
diversas revisiones.

 Cmo se incluye la informacin de cabecera en el protocolo SMTP ?. Muy
sencillo: Despues de la instruccin DATA, y hasta encontrar la primera lnea
vacia, sendmail reconoce e inserta los diversos "tags" correspondientes 
a las cabeceras del mensaje. una vez encontrada una linea vacia o una que no
corresponda a una cabecera vlida, sendmail interpreta como "body" o cuerpo
del mensaje todo lo que siga a continuacin

Multi-Purpose Internet Mail Extensions.

	Hasta ahora hemos asumido que todos los mensajes estaban basados en
caracteres ASCII de 7 bits. Pero Que hacer cuando lo que se desea es enviar
un mensaje que incluye caracteres internacionales, o cdigo binario?.

	Una primera aproximacin es utilizar un MTA que hable ESMTP ( extended
SMTP ). Este protocolo permite la transmision de caracteres de 8 bits. El
problema fundamental consiste en que nosotros ( el usuario que enva el 
mensaje ) no tenemos control sobre el camino que dicho mensaje va a recorrer, 
especficamente: no sabemos si todos los MTA's que nuestro mensaje se va a
encontrar saben hablar ESMTP

	Una segunda aproximacin consiste en convertir nuestro mensaje a un
cdigo 7bits puro. Las utilidades "uudecode" y "uuencode" se encargan de dicha
tarea. El problema aadido es que estos paquetes slo son estndard en el
mundo UNIX, y aunque parezca mentira, no todo el mundo tiene la suerte de tener
un UNIX encima de la mesa...

	La solucin ms viable consiste en dejarle al MUA la tarea de codificar
y descodificar el mensaje de forma transparente al usuario: mediante los
famosos "Attachments" le indicamos a nuestro mailer que vamos a insertar un
fichero con  un formato X y que dicho fichero debe ser icludo en el cuerpo
del mensaje a enviar.

	Para ello el MUA "clasifica" el fichero en una "categora", y lo 
codifica en la forma que considere ms conveniente, incluyendo en las cabeceras
y en el cuerpo del mensaje que envia informacin sobre los datos que incluye
y su forma de decodificacin. Estas categoras estn definidas - cmo no - 
en un RFC y constituyen las denominadas MIME's ( Multipurpose Internet Mail
Extensions ). El objetivo de MIME es el de permitir que cualquier tipo de 
mensaje ( texto, imagenes, voz, datos, binarios, etc ) pueda ser enviado
a travs de SMTP, de una forma sencilla y reversible

Volviendo a nuestra cabecera ejemplo, nos encontramos con las entradas

MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

- La primera indica la version de MIME que utiliza el mensaje
- Content-Type indica la clasificacion del "attachment" que se incluye en el 
  mensaje
- Content-Transfer-Encoding: indica el tipo de codificacin utilizada a la hora
  de incluir el attachment en el cuerpo del mensaje

Se pueden inclur mltiples attachments en un mensaje, cada uno con su propio
content-type y Content-transfer-encoding. Sendmail es transparente a dichos 
datos, pues estn insertados en el cuerpo del mensaje, y lo unico que requiere
es que sean datos de 7bits ( 8, si soporta ESMTP ). Los Mimetypes sern usados
a la recepcin del mensaje por el MUA para reconstrur el fichero original

Resumen. Conclusin

A modo de resumen se puede indicar:

- En la gestin de correo electrnico intervienen dos tipos de agentes: 
  MUA's ( interfaz de usuario ) y MTA's ( encaminamiento y distribucin )
  SendMail es un MTA, aunque tiene un mnimo MUA para su uso directo desde
  lnea de comandos
- El MTA ideal es rpido, eficiente, altamente configurable, y garantiza que
  ningn mensaje es perdido. El mayor problema de cara al usuario es casi
  siempre la configuracin
- Sendmail posee un fichero de configuracin /etc/sendmail.cf, de sintaxis
  casi criptica, pensado para un rpido procesamiento por el programa, no
  por el usuario. Diversas utilidades de configuracin mediante macros
  facilitan al administrador del sistema la tarea de configurar sendmail
- La transferencia de mensajes a travs de InterNet est regulada mendiante
  una serie de RFC's, que regulan:
	El protocolo de transferencia
	El formato de los mensajes
	Las extensiones al protocolo

En este artculo hemos introducido al lector en los fundamentos del correo 
electrnico. En futuros nmeros de LINUX ACTUAL nos centraremos especificamente
en el caso de SendMail, introduciendo al lector en la instalacin y 
configuracin de dicho software, presentando ejemplos de configuraciones
e introduciendo las diversas opciones y posibilidades. Posteriormente se
describir sendmail y los ficheros de configuracin en profundidad, explicando
en profundidad la "magia" de la configuracin de sendmail

En el CD-Rom que acompaa a esta revista encontrar el lector los RFC's que
se refieren de una u otra forma al correo electrnico, asi como la ltima
distribucin disponible de sendmail en formatos rpm y tgz

Referencias

Puesto que el correo electrnico es incluso ms antiguo que InterNet, est
profundamente documentado, existiendo una ampila bibliografa y referencias
sobre el tema. Indicamos aqu alguna de las ms relevantes:

Referencias sobre TCP-IP y SMTP
	Douglas E. Comer
	"Internetworking con TCP-IP" Tercera Edicin( tres volmenes )
	Prentice Hall international
	ISBN 0-13-474321-0
	http://www.phall.com
( una coleccin que todo administrador de sistemas debe tener en su biblioteca
informtica )

Referencias sobre Sendmail
	Eric Allman,Bryan Costales, Neil Rickert
	"Sendmail" Segunda edicin
	O'Reilly Associates, Inc
	ISBN 1-56592-056-2
	http://www.ora.com

( considerado como "la biblia de sendmail" es el nico manual reconocido como 
oficial por el creador de sendmail )

RFC's
	Consultar el fichero indice includo en el CD-Rom

Sendmail Home Page
	http://www.sendmail.org
