El servicio de correo electrónico en la Universitat de València

Héctor Miguel Rulot Segovia. Analista de Sistemas, Servicio de Informática de la Universitat de València. Mayo 1998.

Índice.

1.-Introduccción.
2.-Historia del correo electrónico en la Universitat de València.
3.-¿Qué es el correo electrónico?
4.-¿Cómo funciona el correo electrónico?
5.-Comentarios sobre el SMTP, el POP3 y el IMAP.
6.-El servicio de correo electrónico
6.01.-Especificaciones.
6.02.-Especificaciones secundarias.
7.-Diseño del servicio
7.01.-La plataforma material (primera fase).
7.02.-La cantidad de disco por usuario.
7.03.-La plataforma material (segunda fase).
7.04.-La categorización de usuarios.
7.05.-Gestión versus funcionamiento del servicio.
7.06.-La base de datos.
7.07.-Los servidores POP3 e IMAP.
7.08.-El programa que deposita las cartas.
7.09.-Usuarios NO de sistema.
7.10.-Los formularios de gestión y el servidor HTML.
7.11.-El servidor HTML seguro.
7.12.-Las cuentas de correo no personales. Alias.
8.-Procedimientos: los servicios atendidos por personal.
9.-El servicio de correo electrónico.
9.01.-Mantenimiento del servicio.
9.02.-Personal.
9.03.-Estado actual y previsiones.

Introducción.

A lo largo de los últimos años, el progreso en las comunicaciones ha permitido que poco a poco se fuera conformando una red de interconexión que enlaza, no sólo la práctica totalidad de los centros relacionados con la educación, sino también la mayoría de las grandes empresas proveedoras de servicios y bienes del comercio mundial.

Originada a principio de los años 70, esta red fué impulsada, en sus comienzos, por un proyecto de investigación financiado por la agencia ARPA del ejército de los Estados Unidos, cuyo fin era el de conseguir una red militar de comunicaciones electrónicas, fiable y tolerante a fallos en alguno de sus componentes. La red tuvo su lugar de nacimiento en algunas de las principales universidades estadounidenses, bajo el auspicio de los contratos de colaboración que estas universidades firmaron con el proyecto de ARPA. Al principio, enlazó únicamente las universidades involucradas, que establecieron líneas de comunicación entre ellas con el objetivo de probar un nuevo protocolo de enrutamiento, cuyo desarrollo era parte fundamental del proyecto. Este protocolo se bautizó por entonces como "Internet Protocol" y , sobre él se desarrollaron otras capas de protocolos de superior nivel que permitían el fácil desarrollo de aplicaciones de comunicación y de servicio vía la red. Estos protocolos superiores fueron luego conocidos como el TCP ("Transport Control Protocol") y el UDP; siendo el primero de ellos el que sirvió de base para la mayoría de las aplicaciones que requerían un protocolo de transporte fiable.

En el transcurso de los años, las aplicaciones de comunicaciones electrónicas (nótese que, en todo momento, nos estamos refiriendo a transportar información entre sistemas electrónicos de tratamiento de la misma: es decir, entre ordenadores) demostraron ser incomparablemente útiles para el trabajo diario de colaboración entre investigadores; hasta el punto en que la interconexión comenzó a extenderse fuera del ámbito de las universidades y organismos militares integrados en el proyecto original, para abarcar, poco a poco, a todos los que tenían algún proyecto, cualquiera que fuese, con el ejército de los Estados Unidos. No era nuestra red, desde luego, la única red informática que existía en el mundo ni, mucho menos, entre universidades; ni tampoco esta red tenía el monopolio de ninguna de las útiles aplicaciones que soportaba, pero, dado que la gran mayoría de los ordenadores del mundo estaba en Estados Unidos y, de éstos, la gran mayoría estaba en las universidades y centros militares de aquel país, la red ARPA terminó por convertirse en un estándar "de facto"; máxime, cuando el ejército de EE.UU. estableció la conectividad con su red como condición imprescindible para cualquier ordenador que fuera a adquirirse con destino a sus dependencias. Como el ejército de EE.UU. era el mayor comprador de ordenadores del mundo, todos los fabricantes se apresuraron a compatibilizar sus equipos con los protocolos TCP (UDP) e IP.

El resto de la historia es bien conocido. A lo largo de las últimas décadas, el protocolo TCP/IP se fué generalizando en el mundo académico y militar, no sólo en los Estados Unidos, sino en el resto del mundo: lógicamente, todas las universidades han deseado (o más bien, necesitado) estar a la altura de sus colegas estado-unidenses y, sobre todo, poder comunicarse en pié de igualdad con ellas. Basándose en su prevalencia y difusión, el TCP/IP se fué imponiendo sobre otros protocolos muy utilizados, asociados a redes muy extendidas, algunas de las cuales incluso estaban asociadas a determinados fabricantes muy influyentes en el mundo informático (la red BITNET de IBM, la red DECNET de DIGITAL). Incluso perdieron la lucha otros estándares absolutamente independientes y promovidos por organizaciones internacionales de estándarización (ISO); todos se rindieron ante un estándar "de facto", sencillo (en comparación con otros) y conocido por todos. En el proceso también influyó, en gran medida, el hecho de que todos los detalles técnicos e incluso los programas fuente fueran de amplio y gratuito conocimiento: el TCP/IP no era propiedad de nadie ni estaba controlado por nadie.

El punto de inflexión de esta historia ocurrió a finales de los años ochenta, cuando ya el número de empresas comerciales, que formaban parte de la red, empezó a ser importante. Esto, en principio, contradecía una premisa básica: desde el comienzo de la red, la única condición para poder conectarse (aparte de la obvia de ser capaz de autofinanciarse el enlace con el punto más próximo de la red) era la de ser una entidad militar o educativa. Estaba pues prohibido formalmente el utilizar la red para fines comerciales. Sin embargo, muchas empresas fueron consiguiendo conexión, en virtud de su relación más o menos estrecha con determinados componentes "legales", ya sea porque participaban directamente en proyectos de investigación, ya sea para facilitarles el soporte a los equipos científicos que suministraban a dichos proyectos. En este contexto de una red constituída por miles de universidades y entidades gubernamentales y militares, junto con algunos centenares de empresas, surgió, en el CERN (el Centro Europeo de Investigación Nuclear, en Ginebra), una aplicación de red cuyo fin era publicar información de manera visual y atractiva, en oposición a los habituales y prosaicos textos no proporcionales, en pantallas de 24x80 caracteres, que cumplían su función, pero sin provocar ningún entusiasmo. Esta aplicación, inicialmente diseñada "para ir por casa", aunque basada en sólidos antecedentes y estudios, tuvo un éxito tan absoluto y total que la conmoción que produjo (y sigue produciendo), está llevando a un profundo cambio social en la manera que tienen las personas de comunicarse entre sí. A raíz del nacimiento de esta aplicación, las redes de ordenadores han dejado de ser algo conocido tan sólo por expertos y estudiosos; y su utilización se está introduciendo poco a poco en todos los ámbitos de nuestra cultura. La red originada por la ARPA está llegando a los domicilios particulares de todas las personas con medios económicos del mundo; su nombre, derivado del del protocolo que la soporta, INTERNET, está en la boca de todos y aparece diariamente en todos los medios de comunicación de masas; la aplicación rompedora, el Worl Wide Web (la "telaraña mundial", o WEB, o WWW o W3) y sus "páginas" son de conocimiento obligado para cualquiera que se precie de estar "al día".

Sin embargo, una aplicación mucho más antigua que el WWW había conseguido su carta de nobleza mucho antes que éste, y se había convertido en indispensable para todo aquel que la utilizaba en su trabajo. En efecto, desde el mismo principio de las redes, el primer objetivo a cumplir por éstas, mucho antes incluso que el de conseguir la transmisión rápida y eficiente de ficheros de datos, fué el facilitar la intercomunicación personal entre los usuarios. Intercambiar ideas, opiniones, informes y notas, a la velocidad que permitían las comunicaciones electrónicas, con personas situadas, no sólo en el despacho de al lado o en el mismo edificio, sino en las mismas antípodas del mundo, se convirtió pronto en algo absolutamente imprescindible para la comunidad científica, del mismo modo que, hoy en día, está demostrando ser vital para todas las empresas que pretendan una proyección exterior algo más que meramente local (e incluso en este caso). El correo electrónico fué y sigue siendo la aplicación fundamental de las redes electrónicas y, por ende, de Internet; y ello aún a pesar de que el WWW haya afectado algo a su primacía.

Se desprende con facilidad de todo lo dicho hasta ahora el que, para una universidad y en los tiempos en que vivimos, resulta absolutamente vital disponer de correo electrónico; y no sólo entre los componentes de su personal, sino también, a través de Internet, con el resto del mundo. Efectivamente, hace ya algunos años que las demás redes mundiales se han fundido en La Red con mayúsculas, es decir, en Internet. La presencia de una entidad en el mundo de la enseñanza, de la investigación, por no hablar del comercio, no es posible que se entienda hoy sin que se halle presente en la red. La ausencia de ésta implica una pérdida de competitividad fatal para cualquier investigador y, pronto, incluso será catastrófico para la calidad de enseñanza de un centro. Más aún, las tareas administrativas serán en breve imposibles sin disponer encima de la mesa de las dos aplicaciones fundamentales de red: el WWW y el correo electrónico. Este descubrimiento, que hicieron, hace ya 20 años, todos los investigadores del mundo que intentaban destacar mínimamente en su campo, ha alcanzado por fin a todas las esferas de decisión de las universidades españolas, las cuales se han lanzado en frenética carrera para recuperar el tiempo perdido, en un intento de no quedarse atrás también en este desafío tecnológico.

El resto del presente trabajo se focaliza en la descripcción de la aplicación más antigua de la red: el correo eléctrónico, concentrándose en la descripción del mismo, enfocado como un servicio necesario para todas las personas que trabajan dentro del ámbito de la Universitat de València.

Historia del correo electrónico en la Universitat de València.

En nuestra Universitat de València, el correo electrónico hizo su tímida aparición hace ya muchos años (años 80), principalmente a través de los investigadores en física corpuscular que instalaron una conexión propia a través de la red DECNET con el CERN y, a través de él, con el resto del mundo. Ya entonces esta conexión fué inevitable, si se deseaba la participación en algunos de los proyectos del mencionado centro europeo. Durante varios años, esta fué la única vía de comunicación electrónica con el exterior existente en nuestra universidad, si nos olvidamos de la comunicación (vía tarjetas perforadas e impresora de líneas) con el MEC, en Madrid, para fines de cálculo y administración, pero no de comunicación interpersonal.

La instalación de un nuevo ordenador, destinado al cálculo intensivo, en el Servicio de Informática a principios de los 90, fué el punto de partida de un servicio de correo que finalmente alcanzaría a todas las personas que tuvieran necesidad de él en la universidad. Este ordenador, un 3090 de IBM con sistema operativo multiusuario VM, fué, desde el primer momento, conectado con el resto de las redes mundiales mediante enlaces con Madrid y Barcelona, soportando aplicaciones de envío de ficheros y, cómo no, de correo electrónico con el exterior. La conexión se efectuó utilizando protocolos de la empresa IBM, enlazando con la red que utilizaba dichos protocolos: la red BITNET. Por entonces, BITNET se extendía por gran parte del mundo aunque, hoy en día, se ha extinguido prácticamente ante la evolución imparable de Internet. En un principio, sólo el personal con necesidades imperiosas de cálculo se vió otorgar un usuario en una máquina cuyo fin primordial era precisamente ése: el cálculo. Pero, al poco tiempo, se hizo evidente que la creación de un usuario con otros fines era posible, dado los pocos recursos que acaparaba un usuario sin grandes requisitos, en comparación con los devoradores de medios que utilizaban el procesador vectorial y los demás útiles de cálculo. Ello, y la toma de conciencia de la importancia del correo electrónico, impulsó la creación, en el sistema operativo VM (en la máquina "de cálculo"), de usuarios "sólo para el correo"; simultánemente, se fomentó dicho servicio entre el personal de la universidad, dando toda clase de facilidades para acceder a él. Fué entonces cuando el correo electrónico empezó de verdad en nuestra universidad.

Transcurrido un tiempo, comenzaron a tomar importancia otras consideraciones que ponían en cuestión la conveniencia de mantener un servicio, exclusivamente basado en software y recursos asociados a una determinada marca (IBM en este caso). En particular, el acceso al correo electrónico estaba condicionado a disponer de un tipo determinado de programa emulador de terminal (3270 de IBM) cuya funcionalidad estaba orientada exclusivamente hacia ordenadores de dicha marca y que, en ningún modo, era un software que se pudiera considerar "estándar". Además, por la misma época, el VM se dotó por fin de una conexión que utilizaba protocolo IP para unirse con el resto de las redes IP del mundo; es decir, la Universitat de València quedó conectada a Internet (quede como recuerdo que fué de las primeras en España); e Internet es una red que utiliza fundamentalmente protocolos abiertos, es decir públicos y de libre uso. Todo ello, junto con la popularización de multitud de programas de usuario que utilizaban los protocolos propios de Internet para transmitir y recibir correo hasta el propio ordenador del usuario, hicieron aconsejable un cambio de estrategia. Se estaba entrando en un mundo en que la red llegaba a las mesas de los usuarios, directamente a sus ordenadores personales y no, como antes, sólo al ordenador central de la empresa. Todos los ordenadores tenían conexión "full Internet", con capacidad de actuar de forma totalmente independiente y no ya simplemente como un terminal del ordenador central.

La nueva orientación ya se había estado probando en nuestra universidad en un servicio dirigido únicamente a los ordenadores de tipo MacIntosh de la marca Apple. Para ellos (y exclusivamente para ellos, pues el servicio utilizaba protocolos Apple, no fácilmente instables en otros sistemas como los clónicos de PC-IBM) se dispuso un servidor MacPost, el cual comunicaba, él sí, via el protocolo Internet SMTP con el servidor principal de la universidad, el VM, para transmitir y recibir mensajes. El éxito de tal aproximación fué considerable: el programa agente del usuario (MUA: "Mail User Agent"), es decir, el que utilizaba y con el cual interactuba el usuario, era un programa familiar, del mismo tipo que todos los demás programas a los que estaba habituado en el entorno del sistema operativo con el que trabajaba (en este caso, el Mac-OS), lo que reducía drásticamente el coste de aprendizaje y asimilación de la nueva herramienta.

La misma idea era perfectamente trasladable a todos los ordenadores empleados en nuestra universidad, e incluso generalizable para que, en todos los casos, sea cual fuera el sistema operativo que utilizara el ordenador del usuario, el servidor y el protocolo a utilizar fueran el mismo. En efecto, en Internet ya estaban construídos estos servidores y definidos estos protocolos (POP3 e IMAP), existiendo, como hemos mencionado más arriba, los programas cliente necesarios. Éstos, al igual que el MacPost, además cumplían un requisito que se ha procurado mantener en todo los servicios informáticos que se han ido instalando en la red de nuestra universidad y que ya cumplía el MacPost: la gratuidad (por lo menos para instituciones académicas). A todas estas ventajas se unía una más, poco apreciada por los administradores de sistemas, pero muy agradecida por los usuarios: la versatilidad; dada la gran cantidad de programas cliente existentes, incluso para un mismo sistema operativo del ordenador el usuario, éste podía escoger el que más coincidía con sus gustos y apetencias.

La estandarización de servidor-protocolo se efectuó en el año 1994, año en el que se dió de baja el servicio de correo en el VM y se trasladó a una máquina UNIX (un HP-9000/715-33 de Hewlett Packard). Todos los usuarios de correo del VM fueron trasladados al nuevo servidor y se inició un proceso de adaptación de los usuarios y sus ordenadores a las nuevas aplicaciones (y a los nuevos tiempos). Simultáneamente, se hizo lo mismo con el servicio MacPost, que tan buenos resultados había dado (aunque estaba a punto de entrar en colapso por insuficiencia de recursos) y, en aras de la estandarización y simplificación, se trasladaron también sus usuarios al nuevo servidor y se cambió el programa cliente en los ordenadores (MacIntosh) de los usuarios. El nuevo servidor soportó, practicamente desde el primer momento los dos protocolos de lectura de correo definidos en Internet: el POP3 y el IMAP, a pesar de las tendencias existentes en aquel momento (y que, todo hay que decirlo, simplificaban mucho la tarea de administración del servidor) de sólo utilizar el protocolo POP3. Nuestra universidad fué pues puntera en España en la utilización del IMAP, protocolo que se está imponiendo cada vez con más fuerza en la red.

Sin embargo, aún por entonces, la importancia del correo electrónico no había calado lo suficientemente hondo en los órganos directivos de nuestra preciada institución (las malas lenguas dudan que haya calado ya hoy :-) y los recursos asignados (la configuración material del servidor) resultaron pronto insuficientes; ello a pesar de que, en un principio, se limitó el servicio al personal que trabajaba para la universidad, excluyendo así explícitamente a los estudiantes. Ello se hizo, no por ninguna opción discriminativa, ni siquiera de seguridad, sino simplemente por escasez de medios: el servidor, a la postre, incluso resultó insuficiente para atender a los 4.000 usuarios que llegó a tener. Desde un principio era obvio que no soportaría, de ningún modo, el tener que atender además a nuestros 65.000 estudiantes.

La siguiente transición tuvo lugar en Noviembre de 1996. El tremendo agobio del servidor que teníamos impulsó la adquisición de un equipo mucho más moderno y adecuado para la tarea, una auténtica máquina servidora preparada para tal fin y no simplemente una estación de trabajo adaptada, como era el servidor de entonces (se optó por un HP 9000/820 serie D200). Tras el estudio correspondiente, la adquisición del servidor, el análisis de la aplicación, la elaboración de los programas necesarios y la configuración adecuada del servidor y los programas, el trasvase de los usuarios tuvo lugar con perfecta suavidad: por una vez, prácticamente no hubo quien se diera cuenta del cambio. El desarrollo necesario para la puesta en marcha de este nuevo servidor costó casi 6 meses y fué un preludio al desarrollo, aún más complejo, que ya se veía venir y cuya ineludible necesidad se vaticinaba próxima (o, más bien, ya estaba allí, presente, pero insatisfecha): la ampliación del servicio de correo a nuestra base total de posibles usuarios, incluyendo por fin a nuestros millares de estudiantes.

Por fin, en julio de 1997, se dispuso de los créditos y del tiempo necesarios para abordar esta nueva fase. La adquisición de otro servidor, dimensionado mucho más generosamente en previsión de soportar una base de 10 a 20 veces más usuarios que el anterior, disparó el proceso que culminó, tras una reelaboración de todo el sistema software de correo con el objetivo de hacerlo mucho más eficaz, en febrero de 1998, fecha en la que la Universitat de València, con considerable retraso con respecto a algunas otras universidades pero, desde luego, sin ser la última, proporcionó a la totalidad de sus alumnos el acceso a esta herramienta de nuestros tiempos.

El correo electrónico, a fecha de hoy (mayo de 1998) aún está difundiéndose entre nuestros estudiantes, de los cuales sólo 4500 han solicitado y obtenido ya su cuenta. La integración de este servicio en la vida académica es aún pobre, pero es un objetivo, no sólo deseable, sino de inevitable consecución dada la evolución de nuestra sociedad. Aún ahora, el correo electrónico ya está fomentando esa capacidad, que se vaticinaba en declive y de olvido inevitable, de escribir para comunicarse. Y, si bien es cierto que la mayoría de los mensajes son cortos párrafos sin mucho estilo, también abundan las largas cartas que recuerdan las de antaño, cuando aún no existía el teléfono.

A continuación, se pasa a describir toda la problemática asociada a la instalación y mantenimiento de un servicio de correo electrónico, tal como se ha enfocado en nuestra universidad y, en concreto, en el Servicio de Informática. Se desarrollará toda la problemática asociada, explicitando las decisiones tomadas e intentando hacer patente el esfuerzo que ha supuesto y que aún supone instalar y mantener todo el sistema que se halla instalado.

¿Qué es el correo electrónico?

Antes de entrar en materias más técnicas, conviene recordar algunos conceptos, que si bien son elementales, pueden no ser conocidos por personas no directamente involucradas en los desarrollos de las redes informáticas y sus aplicaciones.

Como se ha mencionado en apartados anteriores, la aplicación de correo electrónico es una aplicación básica de las redes informáticas. Su objetivo (la tarea que debe cumplir) es simple de entender: se trata, ni más ni menos, que de simular electrónicamente el correo ordinario, es decir, el proceso de escribir una carta, meterla en un sobre y enviarla (dándosela al cartero). Por el otro lado, se trata del proceso de recibir una carta, es decir, ir a un buzón, extraer las cartas que hemos recibido, seleccionar la que nos interesa en este momento, abrirla y leerla; posteriormente, tirarla, guardarla o contestar a ella (lo que nos llevaría de nuevo al proceso incial de escribir). Dada la similutud de filosofía entre los dos tipos de correo, cabe esperar ventajas e inconvenientes similares, aunque el posible aprovechamiento de las capacidades informáticas nos deje suponer que son posibles incontables mejoras sobre la version "papel" del correo ordinario. Ello es cierto, aunque aún no se ha llegado al desarrollo completo de todas las posibilidades que se hallan implícitas en los mecanismos utilizados, principalmente porque los protocolos empleados para realizar estas funciones, si bien han sufrido variadas adaptaciones desde entonces, son básicamente aún los mismos que se definieron a principios de los años 70 (estamos hablando del SMTP).

Ventajas.

Dicho esto, podemos mencionar las siguientes ventajas del correo electrónico sobre el correo ordinario:

La principal: rapidez. En un entorno ideal (servidores y redes con capacidad ampliamente sobredimensionada) el correo electrónico es prácticamente instantáneo: el mensaje es depositado en el buzón del receptor en el tiempo que se tarda en transmitirlo hasta él y escribirlo; ello, en las condiciones indicadas supone algunos segundos en el peor de los casos. En la práctica, las condiciones no son tan ideales y pueden darse condiciones de saturación muy serias, tanto en los servidores como en las redes. Una buena instalación deberá pues intentar un compromiso entre los costes en equipo informático y la eficiencia que se prevee obtener. Ello supone que, en la mayoría de los casos, los mensajes locales e incluso los mensajes cortos destinados a lugares "bien conectados" con nuestro servidor a través de la red, llegan normalmente de forma "instantánea" (en cuestión de segundos). El resto de los mensajes pueden tardar algo más, e incluso ser encolados para su transmisión en horas de menor carga. De todas maneras, en el peor de los casos, se espera siempre que un mensaje de correo electrónico tarde menos de un día en alcanzar su destino, aunque éste se halle en el lugar más alejado ("peor conectado") de la red.

Ha de observarse que con "bien conectados" nos referimos a lugares tales que los cables por los que va a transcurrir el mensaje que enviamos hasta ellos, sean cables que normalmente no estén saturados. En la red el concepto de distancia no existe como tal: lo importante es la rapidez/eficacia de la transmisión de un lugar a otro. Ello que normalmente suele resumirse diciendo que "está más lejos quién peor conexión tiene". Un mensaje a las antípodas puede tardar segundos en llegar: está "ahí al lado". Un mensaje a una pequeña empresa española cuya sede está a 100 metros de nosotros puede tardar un día en llegar: está "muy lejos".

La secundaria: comodidad. Esta ventaja, si bien no parece determinante "a priori", en la práctica actúa como gran impulsora del uso del correo electrónico. La comodidad del correo electrónico está apoyada en la ayuda que son capaces de dar las herramientas que utilizamos para enviar y recibir nuestros mensajes electrónicos, es decir en los ordenadores. Son muchas las etapas del proceso de enviar y recibir mensajes en que un ordenador se muestra particularmente útil:

En la composición de la carta: La primera y más evidente de las comodidades está claramente expuesta cuando se recuerda que un ordenador, que dispone de un programa de edición de textos, suple con mucha ventaja a cualquier máquina de escribir en facilidad y versatilidad. La posibilidad de borrar y reorganizar cualquier parte del texto en cualquier momento es sólo una faceta de un todo que puede incluir hasta corrección ortográfica (¡o gramatical!) e incluso una traducción elemental.

En la preparación del sobre: Una dirección de correo electrónico suele ser corta e incluso muchas veces fácil de recordar. Es más, cuando se trata de contestar a una carta previamente recibida, la dirección del destinatario suele escribirse automáticamente. El resto del sobre es construído a partir de los datos de que ya dispone el ordenador (a excepción de una línea de "asunto" opcional) y no requiere usualmente más intervención por parte del remitente que la de pulsar un botón etiquetado como "enviar".

En la entrega de la carta al cartero (su introducción en el buzón de la oficina de correos): parte que suele ser la más fastidiosa y desagradable y que se ve totalmente anulada por el programa usado para escribir y enviar una carta de correo electrónico (obsérvese que suele ser el mismo programa): él se encarga automáticamente y en pocos segundos de todo, al pulsar el mismo botón de "enviar" mencionado en el apartado anterior.

En ir al buzón donde las recibimos y abrir una carta: tarea también muy facilitada, que se limita a la labor de arrancar el programa de lectura de correo y esperar (algunos segundos) a que abra nuestro buzón electrónico y nos muestre las cartas que en él se hallan. Seleccionar una (con el inevitable ratón, o con el teclado) suele ser suficiente para que se nos muestre su contenido.

En el proceso de archivo, destrucción y/o respuesta: que pueden llegar a ser automáticos (la carta se guarda en un determinado archivo en función, p.e., del nombre del remitente) o es simplemente cuestión de unos pocos movimientos de ratón (informático) o pulsaciones de teclado.

Evidentemente, en todo esto se ha supuesto la tesitura de que el acceso a nuestro equipo informático es muy poco costoso (mucho menos. p.e., que acceder al buzón de nuestro domicilio o al de correos), condición que se cumple cada vez con más frecuencia: los equipos suelen estar en nuestra misma mesa de trabajo o en una habitación de nuestras casas y, normalmente, el mayor tiempo se invertirá en encender dicho equipo.

Las ventajas expuestas hasta ahora, ya de por sí, son suficientes para justificar el desbancamiento del correo ordinario frente al correo electrónico. Sin embargo, existen otras ventajas, aún no presentes en la mayoría de las aplicaciones informáticas dedicadas al correo electrónico pero cuya disponibilidad es sólo cuestión de tiempo:

En cuanto a la certificación del remitente: El correo electrónico, al igual que el ordinario, no nos provee, en su estado actual, de medios para asegurarnos que un determinado texto procede de quien dice proceder. Como mucho, en el correo ordinario podremos fiarnos de reconocer la letra y/o la firma manuscrita del remitente, cosas totalmente ausentes en una carta electrónica. En general, hay que destacar que la mayoría de los procedimientos, programas y protocolos de correo electrónico son completamente abiertos y no cuentan con mecanismos de autentificación (esto es una herencia de los tiempos en que la Internet era una red "inocente" en la que un principio base era la confianza mutua y la responsabilidad compartida): hoy por hoy, está al alcance de cualquiera con conocimientos elementales el enviar cartas electrónicas falsas o anónimas. Pero que ello no lleve a alarma: obsérvese que esta situación es absolutamente equivalente a la del correo ordinario y ello, en general, no supone catástrofe alguna.

Están desarrollándose procedimientos (y, de hecho es posible usarlos ya en la actualidad aunque no se hayan generalizado aún) para generar "firmas electrónicas" prácticamente inviolables. Sin embargo, su uso requiere la instalación de toda una infraestructura aneja que tardará todavía unos años en difundirse.

En cuanto a la confidencialidad del mensaje: Los mensajes de correo electrónico discurren por la red "en claro", es decir, sin criptografiar y sin ninguna "llave" que los proteja. En los servidores, los buzones están protegidos de miradas extrañas, salvo de aquellos que tengan acceso al servidor en modo administrador: estas personas, habitualmente responsables, por deber profesional tienen la obligación de respetar la confidencialidad de la información personal depositada en la máquina que administran. Sin embargo, no cabe duda que tienen la posibilidad, aunque sea accidental, de trabar conocimiento con el contenido de un mensaje ajeno e, incluso, modificarlo, ambas cosas sin que quede ninguna constancia de ello. Tampoco cabe duda que cualquiera que sea capaz de violar los mecanismos de seguridad de los servidores (los famosos "hackers") o de "pinchar" la red puede hacer igual. El correo electrónico es pues aún ligeramente menos fiable en este aspecto que el correo ordinario: normalmente, si alguien abre un sobre de papel queda algún rastro (a menos que sea muy hábil).

También se está trabajando duro en resolver este problema, que conlleva técnicas muy similares a las de las firmas electrónicas, en particular la utilización de algoritmos de criptografía extremadamente sofisticadas. Hasta tal punto ello es cierto, que países como Estados Unidos han prohibido su exportación y quieren prohibir su uso, alegando razones de seguridad nacional: una mensajería inviolable sería una herramienta inapreciable para espías, mafiosos y, en general, delincuentes de todo tipo. También en existen soluciones ya utilizables para resolver el problema de la confidencialidad y, al igual que para las firmas electrónicas, sólo cabe esperar a que se prueben a fondo y se generalizen, cosa que sucederá en breve. En efecto, todo ello es crucial para el desarrollo futuro de la red, cuyo mayor impulso futuro provendrá del comercio electrónico. Y para éste último es imprescindible asegurarse de la confidencialidad, como mínimo, de sus medios de pago (números de tarjetas de crédito, cuentas bancarias, etc...).

No podemos dejar de mencionar una ventaja más del correo electrónico, ventaja cuyo abuso está provocando en la actualidad graves problemas a la red y a la mayoría de sus usuarios, no limitándose la consecuencias a afectar a los gestores de los servidores de correo. Nos referimos a la facilidad inaudita, existente en el correo electrónico, para mandar copias de una carta a un número ilimitado de personas: basta con que el usuario indique a su programa de correo una por una las direcciones destinatarias o, incluso, únicamente el nombre de una lista que contiene las mencionadas direcciones. Esta facilidad, que constituye una ayuda muy grande para el trabajo en equipo de un grupo de personas, ha permitido el desarollo de lo que se conoce como "listas de distribución", en las cuales la lista de destinatarios es mantenida por un gestor en el propio servidor de correo. Las listas de destribución pueden considerarse como una aplicación de red derivada del correo electrónico, pero con entidad propia, y autorizan la difusión e intercambio de noticias y opiniones sobre un determinado tema de forma rápida y sencilla. Sin embargo, la creación de listas de distribución tiene consecuencias extremadamente graves a nivel del funcionamiento de los servidores; en efecto, en el estado actual de la técnica, el mandar copias de un mensaje implica copiarlo físicamente (y no sólo lógicamente) en los buzones de cada uno de los destinatarios de una copia. Obviamente, cuando el número de destinatarios es grande, ello trae como consecuencia el manejo y almacenamiento de ingentes cantidades de información por parte de los servidores de correo, que en muchos casos pueden llegar a colapsarse por agotamiento de recursos. En evitación de ello y para poder soportar listas de discusión a nivel mundial con millones de subscriptores, surgió una nueva aplicación de red, también independiente del correo electrónico, dedicada a recolectar y difundir de manera eficiente estos mensajes: es lo que se conoce como los grupos de noticias de USENET ("USENET News").

Por otro lado, dado que la red se financia colectivamente y, en ningún caso, los servidores de correo cobran por transmitir mensajes, no repercute el coste de un envío en el remitente, por lo que enviar millones de copias no produce coste alguno (!). Obviamente, es absolutamente tentador para las mentes con mentalidad panfletaria o de agente publicitario el abusar de ello. Existe una norma extremadamente explícita en la red que prohíbe formalmente el mandar un mensaje a miles (millones) de destinatario. Por desgracia, esto no detiene a los irresponsables o egoístas (o ignorantes), que se aprovechan además de la facilidad de falsificar la dirección del remitente para permanecer impunes. Este problema, conocido en el argot informático como "spamming", es el que causa los dolores de cabeza arriba mencionados y llena de variopinta propaganda los buzones de los usuarios que han tenido la desgracia de que su dirección de correo haya caído en las listas de los spammers.

¿Cómo funciona el correo electrónico?

Para hacer posible la compreensión de las explicaciones técnicas que se propondrán en los apartados siguientes, es necesario describir, aunque sea de manera rápida y somera el funcionamiento del correo electrónico y definir la teminología que será inevitable usar.

En primer lugar, simplificaremos abusivamente el concepto de "red informática" para quedarnos sólo con la idea de "interconexión por cualquier medio físico de dos o más ordenadores que permita el intercambio ordenado de información entre ellos". Con "ordenado" queremos decir que la información siempre tiene un originatario y un destinatario claros. Obviaremos así hablardel TCP, del IP y de los demás protocolos y mecanismos que aseguran esta interconexión en la realidad y que podrían llevarnos a discurrir sobre detalles como "el número de voltios que debe haber en un cable RJ-45" (obsérvese que nos estamos centrando exclusivamente en la red Internet).

Independientemente del nivel de intercomunicación con el que estemos tratando, una vez que tenemos nuestros ordenadores interconectados y que, por lo tanto, capaces de transmitirse información, debemos hacer que dicha información se ajuste a unas reglas claras, es decir, exista un lenguaje (incluso una gramática en el sentido de Chomsky) y que las reglas para intercambiarla también estén establecidas y conocidas por todos, es decir, exista un protocolo de intercambio. La definición del protocolo debe hacerse en todos los niveles del intercambio (p.e. el tipo de cable determina un protocolo a nivel físico, el IP es un protocolo de encaminamiento, el TCP es un protocolo superior que asegura la fiabilidad de la conexión), pero en nuestro caso, el correo electrónico, nos centraremos en los protocolos necesarios para:

Transmitir mensajes: En Internet, el protocolo estándar para transmitir mensajes, es decir, el que usan los ordenadores estafetas de correo (los carteros o servidores) para intercambiar cartas de correo electrónico es el SMTP ("Simple Mail Transfer Protocol).

Leer buzones: Para acceder a un buzón, abrirlo y consultar y modificar su contenido, se han definido en Internet dos protocolos estándar: el POP3 ("Post Office Protocol, versión 3") y el IMAP ("Interactive Mail Access Protocol").

El funcionamiento y uso de estos protocolos se basa en el concepto, fundamental en los entornos de ordenadores conectados en red, de cliente-servidor. En plan muy generalista, un servidor se define como un programa que rueda en un ordenador conectado a una red, que está permanentemente a la espera de que programas clientes, que ruedan en el mismo servidor o, más usualmente, en otros ordenadores, se conecten a él para pedirle y recibir determinados "servicios". Normalmente, con abuso del lenguaje, se usa también la palabra "servidor" para referirse al ordenador en el que rueda el programa servidor y "cliente" para el ordenador en el que rueda el programa "cliente". Los "servicios" suelen consistir en proporcionar determinada información que desea el cliente (en realidad, la persona que lo usa) y que el servidor tiene almacenada (p.e., las cartas de esa persona), en otros casos, el servicio consistirá en recoger determinada información y procesarla de forma convenida siguiendo las instrucciones del cliente (p.e.: recoger una carta y enviarla a su destino). La lengua (las palabras que hay que decir) y el diálogo a seguir para llegar a un acuerdo (un ejemplo burdo sería: "si yo digo GRACIAS", tu dices "DE NADA") es lo que se halla definido en el conjunto de reglas que forman el protocolo.

El proceso que sigue una carta de correo electrónico por la red es pues el siguiente: una persona compone la carta y la manda mediante un programa, el programa "cliente de correo" que rueda en su ordenador. Dicho programa, cuando recibe la orden de hacerlo, manda la carta por el procedimiento de conectarse vía la red a un determinado servidor ("su servidor") de correo. Los dos programas, en su diálogo utilizan el protocolo SMTP. Luego, el servidor estudia el sobre de la carta (las direcciones de destino) y la envía al servidor más adecuado para entregar con prontitud el mensaje, según las reglas que previamente se le han especificado. Este nuevo servidor puede ser ya directamente el que almacena el buzón al que la carta va destinada; en ese caso, se limita a depositarla en él. En caso contrario, el proceso se repite y el mensaje es reenviado sucesivamente de servidor en servidor hasta que llega al que almacena el buzón destinatario. Obviamente, uno de los problemas en la configuración de servidores es asegurarse de que la carta, en cada paso, se acerque a su destino y nunca se aleje de él; en caso contrario sería extremadamente probable que el mensaje se pusiera a dar vueltas indefinidamente "rebotando" entre servidores. Nótese que los diálogos entre servidores se hacen siempre utilizando el protocolo SMTP y que la principal función de un servidor es la de "encaminar" los mensajes, es decir, la de escoger la siguiente y más óptima etapa en su camino hasta el buzón destinatario.

Una vez la carta se halla en su buzón de destino, permanece en él hasta que alguien autorizado (normalemente el propietario) abra el buzón y la lea. Para ello, el destinatario ordena a un programa cliente apropiado (usualmente el mismo que utiliza él para mandar mensajes) que abra su buzón y le enseñe las cartas que hay en él. El programa entonces se conecta a un determinado servidor de correo ("su servidor"), en el que se halla el buzón, y le solicita las cartas. Evidentemente, el servidor, antes de enseñarselas, exigirá al cliente (que, a su vez, se la pedirá al usuario) una identificación (usualmente constituída por un par usuario-contraseña) para asegurarse de que tiene autorización para leer esas cartas. Todo este diálogo entre programas se hace utilizando el protocolo POP3 o el protocolo IMAP, según lo desee el cliente y tenga a bien el servidor.

Obsérvese que no se solicita ninguna identificación a la hora de mandar el mensaje: es por eso que es tan fácil el falsificar mensajes (textos y remites) con el protocolo SMTP.

En cuanto a las direcciones de correo electrónico, en su versión Internet, tienen el formato "entidad@dominio" donde, tanto la entidad como el dominio suelen estar formados por palabras separadas por puntos y guiones. En su versión más sencilla, cuando no se realiza ningún esfuerzo particular de configuración, los servidores las generan automáticamente a partir del "usuario" de correo y del nombre Internet de la máquina en la que estan ubicados. Obviamente, esto no es deseable en un sistema de correo institucional, en el que no tiene ningún sentido el que una dirección de correo tenga nada que ver con una máquina concreta, por mucho que pertenezca ésta a la institución: la máquina puede cambiar o incluso puede haber más de una. Es por ello que se habla de "direcciones electrónicas de dominio" cuando se preparan los servidores para que la parte de "dominio" haga referencia a la institución y no a la máquina (p.e., en el caso de la Universitat de València, en España, se ha decidido que el dominio sea "uv.es"). Obsérvese que, a ser posible, también es deseable que la "entidad" sea (o pueda ser) un texto independiente del nombre del usuario (cuyo sentido se halla limitado a tareas internas de identificación dentro de los servidores).

Comentarios sobre el SMTP el POP3 y el IMAP.

Todos estos protocolos son sencillos y su definición puede encontrase libremente en la red. En particular el POP3 y el SMTP, más antiguos y menos ambiciosos, son extremadamente fáciles de usar e implementar, lo que ha facilitado la enorme proliferación de programas clientes de correo electrónico. Debe observarse que, en Internet, la definición de protocolos se hace mediante la publicación, completamente sin restricciones por parte de cualquiera, de un documento calificado como una "petición de comentarios" (un "Request For Comments", RFC). Usualmente estos documentos están tan bien madurados que no suelen hacerse dichos comentarios o esos comentarios se incorporan en siguientes RFC, que mejoran o perfeccionan el anterior. La aceptación de un RFC por un número creciente de desarrolladores y usuarios es lo que impulsa en mayor o menor medida su devenir como estándar: una suficiente aceptación equivale en la práctica a su entronización como norma.

En concreto, el SMTP se halla definido en uno de los RFC's más antiguos: el RFC-821. El POP2 en se definió en el RFC-937 y su sucesor, más utilizado hoy en día, el POP3, en el RFC-1081. Por su parte, el IMAP es mucho más complejo y se definió por primera vez en el RFC-1064 (primera versión, obsoleta), luego se corrigió en el RFC-1176 (IMAP versión 2bis) y su última versión se halla en el RFC-2060 (IMAP versión 4, revisión 1). Entre medias y posteriores existen muchos RFC's más que completan y/o concretan el protocolo (RFC-1731, RFC-1732, RFC-1733, RFC-2061, RFC-2062, RFC-2086, RFC-2087, RFC-2088, RFC-2095); esta superabundancia es principalmente debida al tremendo impulso de desarrollo e implementación que ha sufrido el IMAP en estos 2 últimos años, al ser adoptado prácticamente por todas las empresas desarrolladoras como el protocolo de lectura de buzones por excelencia y sustituto total del POP3 en un próximo futuro.

La diferencia fundamental entre los dos protocolos para leer buzones, POP3 e IMAP, es la causa de muchas de las preguntas que recibe diariamente el postmaster. Es un problema de filosofía de fondo, de dos conceptos de contemplar el funcionamiento del correo electrónico fundamentalmente distintos. El POP, es un protocolo definido a partir de la idea de que todo el trabajo debe realizarlo el ordenador cliente (el del usuario) y que debe minimizarze en todo lo posible el trabajo del servidor y el tiempo que la información permanece en él. La consecuencia es que el funcionamiento de un cliente POP se basa en copiar el buzón remoto que está en el servidor al ordenador del usuario y, acto seguido, borrarlo totalmente del servidor. En estas condiciones, la conexión con el servidor dura lo estrictamente necesario para transmitir todos los mensajes presentes en el buzón. A partir de ese momento el servidor deja de tener los mensajes y puede desentendersede ellos. A pesar de que esta aproximación tiene claras ventajas (conexiones cortas con el servidor, las cartas ocupan espacio en el servidor durante un tiempo mínimo), también tiene una desventaja crítica: el usuario no puede dejar cartas de una vez para otra en el servidor para, por ejemplo, leerlas más tarde desde otro lugar. Ello es extremadamente molesto si el usuario necesita poder acceder a su buzón desde más de un sitio. Otra desventaja crucial de un cliente POP, tal como se suele implementar, es que se trae todos los mensajes antes de mostrar los que hay, por lo que, si la conexión es lenta (por ejemplo, vía módem) y hay mensajes grandes, puede tardarse horas en poder acceder a un mensaje pequeño e importante (incluso puede llegar a ser imposible cuando la conexión es mala y se corta sistemáticamente antes de poder traérselo todo).

Todo lo anterior justifica el que, en la Universitat de València, se decidiera soportar también el protocolo IMAP, a pesar de la tendencia que existía en aquellos momentos a considerar tan sólo el POP3. El protocolo IMAP es un protocolo completo de acceso a buzones remotos (no sólo a UN buzón remoto como el POP3), que permite a un usuario mantener varios buzones, incluso en varios servidores distintos (esto último no se soporta en nuestra universidad). El protocolo IMAP, entre muchas otras cosas, incluye todo lo necesario para accede a todo o parte del buzón, al índice del mismo (ordenado según solicite el cliente), a las partes de un mensaje (el protocolo entiende y soporta mensajes multiparte), a poner y quitar diversas marcas al mismo (leído, borrado, contestado, urgente), y todo lo necesario para el manejo de buzones (copia, creacion, borrado) y subbuzones y para el control de acceso y de las cuotas de disco, ...

El servicio de correo electrónico. Especificaciones.

Cuando hubo que abordar seriamente la puesta en marcha de un servicio de correo electrónico como tal, es decir, cuando se plateó seriamente el dotar a todas las personas que trabajan en nuestra universidad de la posibilidad de mandar y recibir cartas de correo electrónico de manera fiable, segura y sencilla, se enfrentaron problemas totalmente nuevos, apenas abordados antes, de configuraciones cliente-servidor en nuestra red universitaria. En primer lugar, como corresponde, se intentó delimitar el problema y los objetivos a cubrir, es decir, determinar las especificaciones que debían cumplir, tanto las máquinas como los programas servidores y clientes. Estas especificaciones fueron evolucionando con el tiempo y las que se presentan a continuación representan el estado actual o próximamente futurible, de las mismas.

Alcance:

• El correo electrónico debe estar disponible para todas las personas que trabajan en esta universidad, incluidos los alumnos.
• Debe comprobarse de que una persona a la que se le asigna una cuenta de correo electrónico está vinculada a la universidad.
• Debe ser posible, previa autorización por personas competentes, conceder cuentas a personas no vinculadas a la universidad.
• El correo electrónico de la universidad deberá estar integrado en el correo electrónico mundial (Internet).

Registro y listín:

• Debe llevarse un registro de a quién pertenece cada una de las cuentas de correo.
• Es necesario que exista un listín, públicamente accesible, con las direcciones de correo existentes en la universidad. Debe ser posible que un usuario solicite su no aparición en el listín.

Gestión:

• La gestión (creación, modificación y borrado) de las cuentas de correo deberá ser lo más automática posible, al alcance de un operador.
• El sistema de gestión de cuentas de correo permitirá categorizar a los usuarios, de forma que sea posible asignarles distintos privilegios a la hora de utilizar los recursos de correo.
• Tanto la contraseña como el nombre de usuario deberán crearse automáticamente, siempre procurando que sean de fácil memorización, aunque cumpliendo el requisito de seguridad.
• Las cuentas de correo deberán caducar automáticamente, en la fecha registrada (o previstas según las normas), previo aviso (también automático) al usuario.
• Sería deseable que los usuarios pudieran activar su cuenta de correo con el mínimo de formalidades, incluso, si ello fuera viable, desde su mismo ordenador.
• Deberá haber límite para el espacio máximo ocupable por un buzón y los usuarios deberán ser avisados automáticamente de que han agotado el espacio de sus buzones, si se da el caso.

Disponibilidad:

• Los servidores deberán estar disponibles (accesibles) las 24 horas del día, los 7 días de la semana.
• Los tiempos de respuesta de un servidor deben ser del orden de segundos. En caso de mucha carga, y como máximo, 30 segundos.

Seguridad:

• La seguridad de los servidores ante ataques externos debe estar garantizada en la máxima medida posible.
• La conservación y recuperabilidad de los datos de los servidores también deberá estar asegurada.

Adaptabilidad:

• Los servidores utilizarán protocolos abiertos independientes del fabricante.
• Se procurará disponer en la máxima medida de los posible de los fuentes de los programas servidores e incluso de los clientes, con el fin de asegurar siempre su adaptabilidad a las necesidades del servicio.
• Deberán existir programas cliente para la mayor cantidad posible de plataformas. Sería deseable que dichos programas estuvieran traducidos y manejen debidamente los acentos castellanos y catalanes.

Comodidad y funcionalidad:

• Los usuarios deberán poder consultar sus mensajes sin necesidad de descargarlos en su ordenador cliente.
• Se proveerá a los usuarios, hasta donde alcancen los recursos, de buzones remotos.
• Los usuarios deberán poder consultar su correo y mandar mensajes utilizando la interface usuario a la que están acostumbrados.
• Los usuarios deberán poder redireccionar su correo a otras direcciones, internas y externas, sin necesidad de solicitud previa.
• Los usuarios deberán poder actualizar sus contraseñas de acceso al servidor, sin necesidad de solicitarlo, pero las contraseñas deberán ser lo suficientemente seguras, aunque facilmente memorizables.
• Los usuarios deberán poder enviar y recibir mensajes con grandes adjuntos sin poner en peligro la estabilidad del servidor.
• Las direcciones electrónicas deben ser fáciles de memorizar y transmitir. No deben verse afectadas ante un cambio de la estructura de funcionamiento del servicio de correo.
• A ser posible, el usuario deberá tener la posibilidad de escoger, de entre varios, el programa cliente que más se adapte a sus gustos o necesidades.
• Deberá existir la posibilidad de crear "direcciones de correo no personales" o direcciones de "ente" o grupo de trabajo. Dichas direcciones no podrán tener contraseña propia, sino que irán asociadas a usuarios de correo ya existentes.

Atención:

• Debe haber un servicio de atención y asesoramiento al usuario de correo.
• Tanto el servicio de atención como los demás servicios de tramitación de solicitudes varias deberán tener capacidad de respuesta en menos de 24 horas.
• Todas las utilidades de correo y la documentación deberían estar en las dos lenguas oficiales de la Comunidad. Si fuera posible y, en atención a los estudiantes extranjeros invitados, también en inglés.

El lector puede sorprenderse de que la enumeración de condiciones anterior haya entrado en ciertos detalles que parecen excesivos a este nivel (posibilidad de cambio de contraseña, de redireccionar correo,...) pues parece que se esté entrando a detallar funciones muy concretas del programa servidor de correo. Sin embargo, tal idea está equivocada y, de hecho, tales posibilidades NO SON esperables normalmente de un sistema de correo cliente-servidor, de los usualmene utilizados en Internet.

El servicio de correo electrónico. Diseño.

Estas condiciones, implícitamente y como consecuencia lógica, llevaban a estas otras:

• El servicio de correo adoptará una estructura cliente-servidor (pues es la única manera de conseguir adaptar la interface de usuario a lo acostumbrado en cada ordenador cliente).
• El servicio de correo deberá soportar hasta 70.000 usuarios (total del número de personas en nómina más alumnos en nuestra universidad).
• Los servidores deberá inexcusablemente soportar los protocolos POP3 e IMAP de acceso a los buzones (ambos son los protocolos estándares en Internet e IMAP es imprescindible para poder soportar buzones remotos y acceso a los mismos a al buzón de entrada sin descarga local).
• Los servidores se comunicarán entre sí y con otros servidores exteriores vía SMTP (para asegurar la interconectividad óptima con Internet).
• Se procurará que los programas, tanto los de los servidores como los de los clientes, sean gratuitos y de libre disposición siempre que sea posible (en el caso de los servidores, porque es la manera más segura de asegurarse de que siempre habrán revisiones y de que se dispone de los fuentes a un precio razonable; en el caso de los programas cliente, para asegurar la independencia de los fabricantes, la economía y la flexibilidad en la elección).
• El servidor deberá ser una máquina UNIX (Lo que garantiza también la independencia del fabricante de todo el sistema de correo y además, dada la fiabilidad y flexibilidad de los sistemas UNIX, su adaptabilidad, estabilidad y disponibilidad).
• El programa servidor SMTP y encaminador de mensajes será el "Sendmail" (dado que la maquina va a ser una máquina UNIX y que el sendmail es el servidor de correo más estándar de Internet, de fiabilidad más que probada y estando disponibles sus fuentes con actualizaciones muy frecuentes, que están precisamente orientados a máquinas UNIX).
• El servidor deberá admitir direcciones en forma de "dominio", independientes del nombre del servidor (para que las direcciones sean independientes de la estructura del sistema de correo).
• El servidor deberá dedicarse en su totalidad al correo electrónico. Sólo se admitirá que soporte otros servicios si representan una carga despreciable frente a la del correo.
• El servidor deberá ser una máquina de marca reconocida (por oposición a una máquina clónica o de marca cuya fiabilidad no ha sido suficientemente contrastada. Esto, en aras de la disponibilidad - se prevee obligatoriamente dotarse de un contrato de mantenimiento - y calidad uniforme del sistema - muy difícilmente conseguible de otro modo- en su vertiente material).
• Habrá un SAI (Sistema de alimentación eléctrica Ininterrumpida) (pues es la única manera de asegurar la disponibilidad del sistema frente a los periódicos cortes de suministro en la alimentación eléctrica del Servicio de Informática, que es donde se planea ubicar físicamente el servidor.
• Se procederá regularmente a realizar copias de seguridad de los buzones de los usuarios y, en general, de todo el sistema de correo (para garantizar la conservación y recuperabilidad de los datos y del servicio). Las copias abarcarán un espacio de tiempo de varios meses y serán diarias por lo menos durante la última semana.
• Será necesario de dotar al servidor de una aplicación de Base de Datos (única manera de cumplir eficientemente las condiciones de alcance, registro, listín y gestión explicitadas en el apartado anterior). Ver más abajo.
• La dirección de dominio de la Universitat de València, España, se decide será "uv.es" (la misma que la utilizada en los nombres Internet de las máquinas de nuestra universidad) (para cumplir la condición de independencia de las direcciones de correo de la máquina servidora concreta, es decir, de la estructura física del servicio). El formato de las direcciones electrónicas correspondientes a nuestra universidad será pues terminar siempre con dicho sufijo.
• Los nombres de usuario y las contraseñas serán palabras pronunciables fácilmente por un hispano-parlante, es decir, estar formadas por sílabas del español (esto para cumplir la condición de fácil memorización). Podrán llevar algunos números y/o símbolos especiales intercalados (para garantizar mejor la seguridad).

Se procederá a la construcción del sistema de correo en varias fases, para ir abordando gradualmente la complejidad que representa el mismo. En particular, se construirá un primer servidor prototipo totalmente funcional, pero restringido a una parte muy limitada del conjunto de usuarios final; concretamente, al 10% del mismo. Obsérvese que esto coincide con la relación existente entre el número de alumnos de nuestra universidad (65.000) y el número de personal en nómina en ella (5.000). Esto nos permitirá, además, disponer mucho antes del servicio para la parte más interesada de nuestro conjunto objetivo.

Diseño: la plataforma material (primera fase).

Teniendo en cuenta la condición impuesta por la fiabilidad, disponibilidad y calidad de la máquina servidora de la que se pretendía disponer, se procedió a seleccionarla de entre un conjunto de ofertas presentadas por varias casas fabricantes de ordenadores de reconocido prestigio (Hewlett-Packard, IBM, Sun, Digital, Apple) y, tras el correspondiente análisis de ofertas se escogió, para la primera fase, una máquina de la marca Hewlett-Packard.

Las necesidades que se estimaron para la primera fase (5.000 usuarios) fueron las siguientes:

- Un lector de CD-ROM para actualizaciones de programas e instalación de los mismos.

- Velocidad de CPU máxima dentro de las limitaciones económicas.

- Tipos de disco: los más rápidos igualmente. SCSI (Fast-Wide).

- Cantidad de memoria central (RAM): 128 Mbytes. Esto se calculó estimando una necesidad de 200 a 500Kbytes por usuario simultáneo conectado. Se preveyeron unos 30 Mbytes para el funcionamiento del sistema operativo, unos 100 usuarios y otros tantos procesos asociados al correo de similar tamaño. Estas cifras han resultado bastante acertadas: el número de usuarios simultáneos llega fácilmente a 50 todos los días y el número de procesos en la máquina se eleva a más de 200. Obviamente, se trata de que la máquina en ningún caso se quede corta en memoria física: ello provoca, en todos los casos, una casi parálisis del servidor durante el tiempo que dura la carencia.

- Cantidad de disco: 4 Gbytes en primera aproximación. 1 para el Sistema Operativo y logs del sistema, 1 para buzones de entrada, 1 para buzones remotos y el resto para recepción paquetes grandes e instalacion y mantenimiento de programas. Al cabo de un año, hubo que revisar esta estimación al doble: 8 Gbytes (2.5 Gbyte para el Sistema Operativo y logs, 3 GBytes para buzones de usuarios, 1 Gbyte para buzones remotos, 0.5 Gbytes para paquetes). Ver el apartado siguiente para una discusión detallada sobre la estimación de la cantidad de espacio de disco necesaria.

- Un sistema de almacenamiento masivo para las copias de seguridad (cinta) capaz de almacenar la mayor parte posible del espacio en disco solicitado. La unidad finalmente adquirida es un DAT-DDS2 con capacidad de hasta 2 Gbytes (con compresión) en una cinta.

Diseño: la cantidad de disco por usuario.

Antes de proseguir, cabe explicar más prolijamente cúales son las ideas directrices que han guíado la estimación del espacio en disco necesario para el funcionamiento del sistema de correo y qué limitaciones imponen las decisiones tomadas a la funcionalidad del servicio desde el punto de vista de un usuario.

Decíamos, en el apartado anterior, que al año de funcionamiento del servidor hubo que ampliar el espacio destinado, entre otros, a los buzones de entrada y a los buzones remotos de los usuarios, llevándolos a 3 Gbytes y 1 Gbyte respectivamente. Es fácil caer en la cuenta de que, incluso tras esta ampliación, la asignación de espacio no es muy generosa, pues concede a los usuarios menos de 1 Mbyte para su buzón de entrada y 0.5 Mbytes para sus buzones remotos y, que incluso con cifras tan reducidas, se está confiando en que, estadísticamente, no se use todo el espacio a la vez (¡lo cual, obviamente, en un momento dado puede llegar a no ser cierto!). Esta restricción ha sido imprescindible, porque, en caso contrario las estimaciones dispararían la cantidad de recursos necesarios en el servidor: si todos los usuarios utilizaran todo el espacio que se les tiene permitido hoy en día, 2.5 Mbytes para buzón de entrada y 1.4 Mbytes para buzones remotos, la cantidad de espacio en disco total necesaria subiría a 19.5 (12.5+7) Gbytes. Un asignación generosa de espacio para buzones remotos (10 Mbytes), que sería la realmente adecuada para contentar a la mayoría, elevaría esta cifra a 70 Mbytes de disco, lo que, aparte del coste en los propios discos, implicaría procedimientos y dispositivos para hacer la copias de seguridad también mucho más costosos (o DUPLICAR la cantidad de disco para asegurar el sistema mediante "mirroring" - escribir todo por duplicado).

A la hora de la práctica, las limitaciones impuestas no parecen haber afectado a la calidad (percibida por los usuarios) del servicio, excepto en lo que se refiere a los buzones remotos, que constituyen precisamente la partida más delicada de aumentar. En efecto, el espacio asignado a buzones de entrada es un espacio "dinámico", que crece con el número y tamaño de los mensajes recibidos en un determinado intervalo de tiempo, pero que también decrece a medida que se leen y procesan dichos mensajes. Por el contrario, los buzones remotos constituyen espacio de "archivo" para el usuario: son información que el usuario espera encontrar a su disposición siempre y que muy difícilmente decrece (los usuarios son poco proclives a gastar su tiempo en clasificar y descartar información antigua: a "limpiar" su espacio en disco). Por lo tanto, toda decisión de aumento en la capacidad para almacenar buzones remotos debe hacerse teniendo en mente que todo espacio asignado es espacio "utilizado" definitivamente, a menos de estar dispuesto a provocar una reaccion de indignación por parte de la mayoría de los usuarios, al disminuirles el espacio previamente concedido. Por otra parte, hasta ahora el uso de los buzones remotos no ha alcanzado excesiva popularidad, pues los programas que los usan no son la mayoría (sólo estan disponibles vía el protocolo IMAP y muchos de los programas clientes actuales son sólo POP3) y los usuarios desconocen usualmente que disponen de dicha facilidad. A la vista de ello, se está considerando seriamente el duplicar el espacio hoy asignado hasta los 3 Mbytes, para no penalizar a los usuarios que usan buzones remotos manteniendo libre un espacio que no llega a ocuparse. De todas formas, si en un futuro llegaran a popularizarse sería ineludible incrementar físicamente el espacio de disco disponible en el servidor. Por otra parte, el diferir la adquisición de este material hasta que sea realmente necesario sólo trae ventajas: los precios del alamacenamiento en discos bajan continuamente e, incluso, es posible que para cuando sea necesario ampliar la configuración el servidor haya cumplido con su esperanza de vida y esté amortizado, lo que permitiría considerar la adquisición de un equipo mucho más potente, no sólo en almacenamiento, sino en los restantes factores.

Téngase en cuenta que, a la hora de estimar el espacio concedido a los buzones de entrada que el máximo asignado es un máximo PERMANENTE, a no superar durante un plazo determinado. Puntualmente (en el actual sistema, hasta 7 días), se permite superar este espacio para recibir cantidades de mensajes elevadas o algunos mensajes relativamente grandes (hasta 5 Mbytes). El espacio total máximo absoluto permitido para un buzón de entrada se halla hoy en 50 Mbytes y esa es la cantidad que se autoriza a gastar temporalmente, hasta 7 días, por un usuario. Esta política, heredada del sistema de "cuotas" de los sistemas operativos UNIX ha demostrado ser muy adecuada para mantener dentro de los límites el espacio total ocupado por el conjunto de buzones de entrada, sin penalizar excesivamente al usuario que necesita recibir muchos mensajes o alguno más grande de vez en cuando. Por otro lado, el espacio permanente admitido (2.6 Mbytes) es más que razonable: permite holgadamente el almacenamiento de más de 500 cartas, eso sí, sin adjuntos.

Recuérdese, sin embargo, queuna de las condiciones de diseño especificaba que era necesario que los usuarios pudieran enviar y recibir grandes adjuntos. Ello quiere decir que, adjuntado al mensaje y formando parte de él se pudieran transmitir por correo electrónico grandes "paquetes" de información (documentos, programas, en general cualquier tipo de archivo o fichero). Un estudio de las necesidades reales llevó en su momento a que los usuarios podían llegar a requerir razonablemente hasta paquetes de unos 50 Mbytes como máximo. Llegados a este punto, es imprescindible notar que todos los sistemas de correo electrónico de la Internet fueron diseñados en su momento para soportar sólo la transmisión de "textos ASCII", es decir un tipo muy específico de datos, orientado a textos en inglés sin ningún tipo de "formateo" (negritas, subrayados, etc...) que incluso con textos enormes, no requiere mucho espacio (0.5 Mbyte equivalen, sin compresión alguna, a unas 250 páginas de texto). Dicho de otra manera, el enviar mensajes de correo electrónico del orden del Mbyte o más, solía provocar serios problemas (de espacio y CPU) en los servidores. Con el paso del tiempo, dichos problemas se han ido solventando, principalmente gracias a las enormes mejoras en el rendimiento de los servidores, propiciadas por los constantes progresos de la técnica microeléctronica; sin embargo, sigue siendo absolutamente suicida el autorizar la recepción sin control de mensajes de esta magnitud: un único envío, accidental o malintencionado, podría acabar en un momento con la totalidad de la capacidad del servidor, provocando su bloqueo y la paralización del servicio.

Para resolver este dilema, en la Universitat de València se ha optado por autorizar la recepción en el buzón de entrada de mensajes de hasta 5 Mbytes. Todo mensaje mayor es redirigido a una zona especial (la zona de "paquetes") que tiene sus propios sistemas de control y sus propios límites, de forma que el agotamiento del mismo no afecte a la recepción y envío de los mensajes corrientes. Obviamente, siendo puristas y, a la vista de la estimación (250 páginas) hecha anteriormente, la consideración de "paquete" debería extenderse a todo mensaje que tuviera más de unos 20.000 bytes: es muy poco usual que una "carta" tenga más de 10 hojas de texto y puede considerarse que, con toda probabilidad, se trata de un documento texto adjunto a la carta propiamente dicha. Sin embargo, los límites actuales (5 Mbytes) están establecidos mediante un compromiso comodidad del usuario/seguridad del servidor, de forma que se permite sin dificultad el envío de adjuntos "medianos", que normalmente no pondrán en grave peligro al servidor, sin penalizarlos tratándolos como "paquetes". En efecto, el recuperar un "paquete", en la situación actual del sistema de correo, es un proceso que requiere el uso de, por lo menos, dos programas distintos del propio cliente de correo (no se ha encontrado una forma viable que se puedan recuperar vía el propio cliente de correo): un cliente FTP (es decir, un programa que entiende y utiliza el protocolo FTP - "File Transfer Protocol") para trasladar el "paquete" desde el servidor al ordenador del usuario y un decodificador (p.e. MIME) (un programa que decodifica documentos adjuntos a un mensaje de correo, que suelen ir codificados - p.e., en formato MIME).

Obsérvese que existe otra buena razón que justificaría reducir drásticamente el tamaño límite de los mensajes de correo, eso sí, sólo en el caso específico de aquellos buzones que son accedidos a través de líneas lentas de transmisión (p.e. módem), utilizando protocolo POP3 para leerlos: un mensaje de 1Mby cuesta fácilmente 10 minutos en ser transmitido. Un usuario que quisiera abrir su buzón en estas condiciones y que hubiera recibido un mensaje de similar tamaño, aunque sólo sea para saber qué cartas tiene, tardaría todo ese tiempo en conseguirlo, suponiendo que no hubiera problemas y la transmisión no se le cortara.

Diseño: La plataforma material (segunda fase).

Para la segunda fase, se estimaron las mismas necesidades, pero teniendo en cuenta que el número de usuarios aumentaba en un orden de magnitud (70.000). En principio, cabría pensar que, puesto que en la primera fase se contaba con que el 10% o 20% del total de los usuarios se conectaran simultánemente; en la segunda fase se debía aplicar tal relación, es decir... 1400 conexiones simultáneas (!). Ello nos hubiera llevado, de entrada a multiplicar por un factor de 5 a 10 la cantidad de memoria RAM, requiriendo entonces... hasta 1.2 Gbytes (!), puesto que el número de procesos podría llegar a 3000. Esta cantidad, sin ser imposible, es claramente inabordable, no sólo por el coste económico que supondría, sino porque el dimensionamiento de un servidor de tal capacidad se dispara en todas las partidas: número de CPU's, número de buses de entrada-salida, etc... En la práctica, si se quisiera llegar a tal extremo, sería probablemente aconsejable recurrir a un "cluster" (grupo) de servidores que se repartieran adecuadamente la tarea. Sin embargo, es fácilmente observable que el problema se debe a una mala apreciación de la tarea a resolver. En efecto, el número de conexiones simultáneas no viene determinado por el número de usuarios definidos en el servidor, sino por el número de ordenadores accesibles simultáneamente a dichos usuarios y por la capacidad de entrada-salida del servidor. Una rápida estimación de la cantidad de ordenadores a disposición de los alumnos (65.000 usuarios, el 93% del total) en las aulas informáticas conduce a que éstos difícilmente alcanzaban los 1000 y que era harto improbable, dada la ocupación de las aulas, que se alcanzara un pequeño porcentaje de esa cantidad. En esta tesitura, se estimó que duplicar la estimación hecha para la primera fase y dimensionar el nuevo servidor para unos 200 accesos simultáneos debería ser más que suficiente. En todo caso, el duplicar la capacidad del servidor hasta unos 400 accesos simultáneos debía entrar aún dentro de lo factible, por lo que se debía adquirir una máquina que admitiera este crecimiento.

En cuanto a la cantidad de disco disponible, sí que debía incrementarse en el factor 5 a 10 con respecto a la primera fase. Ello conduce a la cantidad, nada despreciable, de, por lo menos, 30 Gbytes. Contando que tal cantidad no sería necesaria durante el primer año de funcionamiento, se aceptaron ofertas con algo menos, pero con la condición, aquí también, de que fuera fácilmente ampliable.

Es decir, la máquina ofertada debía reunir las mismas condiciones que la anterior, con las salvedades:

- Cantidad de Memoria Central (RAM): 256 Mbytes.

- Cantidad de Disco: 18 Gbytes.

- Cantidad de usuarios soportados: mayor de 65.000.

Tras el mismo proceso que en la primera fase, incluso sin tener en cuenta el condicionante de la compatibilidad con la máquina anterior (para facilitar la portabilidad de los programas instalados y desarrollados), al final, pareció adecuado aceptar, aquí también, la oferta de Hewlett-Packard, que contaba con 21 Gbytes en disco y un DAT-DDS3 con capacidad de almacenamiento de hasta 24 Gbytes (con compresión de datos). Obsérvese que la cantidad de usuarios a soportar es un factor importante en la decisión: muy pocos sistemas operativos son capaces de manejarse con tal cantidad de ellos.

Diseño: la categorización de usuarios.

Hay que observar en este punto que, a la hora de abordar la segunda fase, se decidió mantener en funcionamiento del sistema conseguido en la primera, aún después que estuviera en marcha el nuevo sistema. Las razones aducidas son principalmente de seguridad y fiabilidad. Una máquina con 70.000 usuarios corre muchos más riesgos de seguridad y fiabilidad que una máquina con 5000; y la seguridad de estos 5000, al estar constituídos por el personal docente y de administración y servicios de la universidad es prioritaria: asegurar el funcionamiento para estos 5000 asegura el funcionamiento para toda la parte administrativa y de investigación de la universidad. La parte docente del correo electrónico relacionada directamente con los alumnos, de momento por lo menos, no resulta tan vital. Y aún cuando lo sea, la independencia de ambos sistemas sólo puede redundar en una mayor seguridad de funcionamiento.

El objetivo de esta segunda fase, aún siendo el mismo que en la primera, se concretará configurando dos máquinas servidoras distintas; una reservada para el personal en nómina de esta universidad (y aquellas otras personas debidamente autorizadas) y otra para los alumnos (y aquellos autorizados). Esta separación, además, se concretará, a la hora de construir la gestión de los usuarios, en una categorización de los mismos: tal como se especifica en las condiciones de diseño, el sistema permitirá separar a los usuarios en categorías, lo que permitirá asignarles distintos privilegios a la hora de utilizar recursos de correo electrónico.

En el fondo, el objetivo de la categorización va enfocado a conseguir, a muy largo plazo, alcanzar otra etapa en la gestión de red de esta universidad. Se trata de que la misma base de datos utilizada para la gestión de los usuarios de correo pueda ser utilizada para la gestión, en sentido más general, de todos las personas que utilizan recursos informáticos (no sólo de correo) dependientes del Servicio de Informática. Se pretende simplificar y facilitar el control de acceso a cosas tan variadas como las aulas de informática, los servicios de páginas WWW, los servicios de acceso vía módem, los servicio de calculo, etc...

Diseño: Gestión versus Funcionamiento del servicio.

Llegados a este punto, cabe resaltar que el funcionamiento del servicio de correo electrónico se desglosa en dos partes bien diferenciadas, tal como se ha podido intuir en lo que antecede:

1) El servicio de correo electrónico en sí.

2) La gestión de los usuarios de correo.

En efecto, estas dos funciones se pueden (y se deben) asegurar de forma totalmente independiente. Si se recuerda todo lo dicho hasta ahora, principalmente en el apartado en el que se explica el funcionamiento del correo electrónico, se puede suponer, acertadamente, que el funcionamiento de la recepción y transmisión de mensajes sólo depende de que estén en buen estado de marcha los servidores SMTP, POP3 e IMAP. Las funciones explicitadas en las condiciones de diseño relativas a la gestión de usuarios, al alcance del servicio, al registro de usuarios y al listín de los mismos son de utilidad exclusivamente administrativa o auxiliar: si los usuarios no cambiaran y pudieran fijarse de una vez por todas, la mayoría no serían necesarias; y, de hecho, no son necesarias para que el sistema de correo funcione. Viceversa, aunque no funcionara el sistema de correo, la gestión de los usuarios no tiene porqué verse afectada y puede ser llevada a cabo a la espera que todo vuelva a ponerse en marcha.

Ello nos traza un camino para el diseño del servicio, que nos llevará a mantener separadas en todo momento estas dos funciones, de forma que puedan funcionar independientemente.

Diseño: la base de datos.

Para la gestión de los usuarios de correo, es obvio que se requieren unas tablas en las que se apuntarán los datos asociados a cada cuenta de correo y los datos asociados a las personas a quien pertenece cada cuenta que puedan ser de utilidad para la gestión de la misma. Ello además está requerido explicitamente por las condiciones de diseño en las que se nos obliga a mantener un registro de usuario y un listín de cuentas de correo electrónico.

Por otro lado, las condiciones de diseño del servicio de correo electrónico, relativas a las obligatoriedad de comprobar la vinculación del solicitante con la universidad antes de conceder una cuenta o a la validez de su autorización en caso contrario, recomiendan disponer de tablas en las que se hallen registradas todas las personas con derecho a correo electrónico en nuestra institución y señaladas, de entre ellas, las personas suficientemente competentes para avalar a una persona a priori sin derecho a cuenta.

Dada la dimensión del problema, evidenciada inmediatamente por el número de usuarios potenciales (cuyo registro total requiere tablas de más de 70.000 entradas) se hace pronto obvio que una gestión de tal entidad no puede llevarse a cabo sin herramientas adecuadas para ello. En este caso, la herramienta imprescindible consiste en algún tipo de programa gestor de tablas de grandes dimensiones que nos facilite el manejo de las mismas. No queda más remedio que añadir este programa al conjunto de programas necesarios para que funcione el sistema de correo electrónico, tal como se ha hecho cuando se han especificado las condiciones derivadas de diseño. Estas condiciones no nos obligan a ningún tipo de programa gestor de tablas en particular, pero sí nos recomiendan que sea de libre disposición y que sus fuentes estén disponibles.

Por razones de estandarización y compatibilidad y para minimizar el tiempo de instalación evitando el aprendizaje y familiarización con otro tipo de gestor, se llega a la conclusión de que el tipo de gestor que nos interesa es un gestor de tablas relacionales que entienda el lenguaje estándar de interrogación SQL ("Standard Query Language", que sigue normas ANSI). Un largo estudio, consistente en la búsqueda de programas de base de datos SQL gratuitos y que funcionaran en UNIX (sistema en el que se iba a instalar el gestor de bases de datos), a su instalación y prueba minuciosa, condujo a considerar dos candidatos: el programa conocido como "MSQL" (Mini-SQL) y el PostGres95.

El MSQL es un gestor de bases de datos SQL limitado, pero potente, con muchas herramientas disponibles y extremadamente utilizado en el entorno de servidores UNIX, principalmente en aplicaciones de acceso a bases de datos a través de formularios HTML (páginas de WWW).

El PostGres95 es un derivado de una base de datos construída a raíz de un proyecto de insvestigación sobre el tema en la Universidad de Berkeley (California, EE.UU.) conocido como "postgres". Este proyecto, que derivaba indirectamente de las mismas fuentes que llevaron a la muy conocida base de datos empresarial Ingres, terminó hace algunos años, pero fué continuado, principalmente vía la adición del intérprete SQL por un grupo de personas en Internet, que aún hoy en día prosiguen activamente su desarrollo sacando una revisión nueva cada tres meses aproximadamente. Al igual que el MSQL, aunque en menor medida, dispone de las herramientas necesarias para su acceso desde cualquier lenguaje de programación y de utilidades y herramientas para su utilización desde páginas WWW. La potencialidad del PostGres (se prevee que el soporte total del ANSI-SQL se consiga en breve), a pesar de que inicialmente demostró ser más inestable que el MSQL, nos ha llevado a escoger dicho gestor.

Muchas de las tablas necesarias son copias o extracciones de tablas presentes en el servidor principal de gestión de esta universidad (un sistema operativo MVS de IBM), en concreto son 10 tablas las que forman este grupo: tabla de PANs, tabla de lugares, tabla de cargos, tabla de cuerpos y escalas, tabla de destinos, tabla de titulaciones, entre otras. El resto de las tablas son las definidas para el funcionamiento del servicio de correo: la tabla de usuarios, la tabla de avalados y la tabla de aliases principalmente.

Diseño: los servidores POP3 e IMAP.

A la hora de diseñar la configuración definitiva del servidor de correo lo primero que se determinó fué cuál iba a ser el programa servidor de protocolo SMTP y encaminador de los mensajes de correo. Como ya se explicitó en las condiciones derivadas de diseño, el programa elegido fué el programa estándar UNIX Sendmail. Quedaban pues por definir que programas nos iban a realizar las funciones de servidor de protocolo POP3 y de servidor de protocolo IMAP.

Experiencias anteriores en este campo, unidas a la condición de gratuidad (libre disponibilidad) y acceso a los fuentes nos limitaron prácticamente de entrada a dos posibilidades: el servidor de la Washington University (WU-IMAP) y el servidor de la Carnegie-Mellon University (CMU-IMAP), ambas estadounidenses. Las dos implementaciones son notablemente distintas.

La implementación de la Universidad de Washington es llevada a cabo por Mark Crispin, la persona que definió (y sigue definiendo) el protocolo IMAP mediante la autoría de los RFC's que se han enumerado en el apartado correspondiente. Este servidor es el que, en todo momento, más se aproxima al estándar y utiliza los buzones de entrada estándar del sistema operativo UNIX (es decir, un buzón es una lista de cartas separadas por una línea que empieza por "From " y que se halla en un directorio públicamente conocido). No necesita pues ninguna configuración especial del programa que deposita las cartas (generalmente, el Sendmail). Es un servidor pequeño y eficiente, que accesoriamente incluye un servidor POP3 que utiliza las mismas librerías y se desarrolla al mismo tiempo que el IMAP. Los buzones remotos tienen el mismo formato que el de entrada y están en un subdirectorio del directorio raiz (HOME) UNIX del usuario. Su principal inconveniente radicaba (se corrigió en la última versión) en que, durante la conexión, mantenía en memoria una copia completa (y muy generosa: ocupaba 4 veces el tamaño original) del buzón que estaba sirviendo, lo que, en el caso de tratarse de buzones de grandes dimensiones provocaba rápidamente el agotamiento de la memoria de trabajo del servidor. El sistema de "cuotas" de disco para controlar la ocupación de los buzones también es, simplemente, el proporcionado por el sistema operativo.

La implementación de la Universidad de Carnegie-Mellon es una implementación mucho más ambiciosa, orientada de entrada a servir a gran número de usuarios con muchos buzones. Utiliza su propio programa de entrega de cartas (que debe pues configurarse especialmente en el Sendmail) y su propio sistema de buzones, bastante particular: un buzón es un directorio del sistema que contiene in fichero índice, un fichero caché y un fichero por cada una de las cartas que hay en el buzón. El sistema de "cuotas" es propio e independiente del sistema operativo y requiere también de un fichero (otro diferente) por buzón, lo que permite aplicar cuotas por "grupos de buzones". El principal inconveniente de este servidor radica en la enorme proliferación de ficheros que supone en el servidor, lo que no sólo le lleva a depender enormemente de la eficacia del sistema de ficheros del mismo, sino que propicia el agotamiento del disco, pues cada fichero supone siempre una pérdida de parte de un bloque de disco (la asignación de espacio en disco se hace por bloques o partes de bloque, aunque éstos no se llenen). Las pruebas realizadas no indicaron sin embargo, ningún problema descarado de eficiencia (aunque no fueron exahustivas), pero problemas de compilación (memoria compartida no estándar) bajo el sistema operativo del servidor parecían indicar que este servidor IMAP no sería tan eficiente en esta configuración como podría serlo en otras. Por otra parte, el formato no estándar de los buzones dificulta mucho la fabricación de herramientas para manejarlos durante los procesos de gestión cuyo desarrollo ya se planeaba como propio. Los procedimientos de gestión de usuarios y buzones pasan necesariamente por programas específicos al servidor, de uso poco flexible.

Una vez considerada, instaladas y probadas las dos opciones, se optó por el servidor de la Washington University.

Diseño: el programa que deposita las cartas.

Uno de los programas, prácticamente, no mencionado hasta ahora, pero imprescindible para el funcionamiento del correo en un sistema que utiliza como encaminador de mensajes y servidor de protocolo SMTP al programa Sendmail; se trata del programa encargado de depositar las cartas, pues el Sendmail, delega siempre esta función. Usualmente, se utiliza un programa más o menos estándar que viene con el sistema operativo UNIX (ejemplos de ellos son: rmail, mail, deliver). Sin embargo, en el caso que se desee algún tipo de funcionalidad no estándar a la hora de entregar mensajes, será necesario sustituir el programa habitual por otro más adecuado o por uno diseñado específicamente para cumplir (acaso entre otras) con la función buscada. En nuestro caso, dado que se optó por un servidor de buzones (POP3 e IMAP) que utilizaba los mismos buzones estándar del sistema UNIX, no era, en principio, obligatorio modificar la configuración por defecto simplemente para depositar los mensajes en un formato especial requerido por el servidor (cosa que hubiera ocurrido, como ya se ha comentado, en el caso de optar por el servidor de la Carnegie-Mellon University); a pesar de ello, en previsión de que pudiera requerirse alguna otra función no estándar se procedió a la instalación y configuración de un programa de entrega de mensajes famoso por su versatilidad: el procmail. No fué éste el único programa considerado, pero, dado que su fama era merecida, pareció la opción más adecuada.

La decisión, al poco, demostró ser acertada, porque tuvo que utilizarse casi inmediatamente en la configuración del servicio de "paquetes", mencionado más arriba, e imprescindible para el control de los mensajes de gran tamaño. La función realizada por el procmail en este caso se limita a la de comprobar las dimensiones (número de bytes) de un mensaje entrante y, si supera cierto máximo (5 Mbytes) derivarlo a la zona de paquetes en vez de al buzón del usuario. En este caso, además, el procmail se halla configurado para llamar a algunas utilidades accesorias (scripts de shell) que envían notificación al usuario de lo sucedido y de la manera de recuperar su "paquete".

Accesoriamente, el procmail se ha configurado para que acepte direcciones que se refieren a buzones de entrada "secundarios", es decir, y para explicarlo sencillamente, si un mensaje llega la servidor dirigido a la dirección usuario+obuz@midominio, el mensaje es entregado, no en el buzón de entrada del usuario, sino en uno de sus buzones remotos: el buzón "obuz". Este buzón, obviamente, sólo será accesible al usuario a través del protocolo que sí soporta buzones remotos: el IMAP.

Diseño: Usuarios NO de sistema.

Uno de los principales problemas de diseño que planteó el sistema que se pretendía instalar en la Universitat de València estaba centrado en la cantidad de usuarios a servir. Ya se han descrito los problemas que esto planteaba, no sólo a la hora de diseñar un servidor con suficiente espacio en disco, sino también el cómo afectaba esto a todos los demás recursos del servidor (CPU, RAM, etc...) , incluídas las necesidades asociadas a las unidades destinadas a las copias de seguridad. Además de ello, a nivel de los programas que iban a manejar esta ingente cantidad de usuarios se planteaban otros problemas. El primero de ellos para el mismo sistema operativo de la máquina servidora: ya se constató que el número de usuarios a soportar era una de la condiciones necesarias a la hora de la adquisición de dicha máquina. Sin embargo, ello no es una condición suficiente; en efecto, el que las estructuras internas del sistema operativo estén diseñadas con el número de bits necesarios para soportar identificadores de usuario de gran magnitud (mayores de 65.000), no quiere decir que la máquina se comporte eficientemente cuando tiene que manejar grandes cantidades de usuarios. De hecho, las especificaciones de la máquina aclaraban tajantemente que ello no era así para algunas de las funciones del sistema operativo. El caso es que el problema es difícilmente soslayable para el sistema operativo UNIX si se desea conservar su principal cualidad: la estandarización. En efecto, la tabla de usuarios en UNIX, es, por definición, un fichero TEXTO que debe recorrerse secuencialmente cada vez que se realiza una búsqueda. Obviamente, en condiciones de gran número de usuarios y muchos accesos a la tabla de usuarios el coste se vuelve prohibitivo, máxime cuando una tabla de estas dimensiones empieza a tener dificultades para permanecer en memoria vía los buffers de fichero.

El problema es tanto más grave en cuanto cada entrega de mensaje implica por lo menos dos accesos a la tabla de usuarios del sistema opertivo (uno por el SendMail y uno por el procmail); en cuanto a los envíos o apertura de buzón, por lo menos requieren un acceso cada uno.

Fué por lo tanto un objetivo primordial y de los que más esfuerzo costó el conseguir, el construir un sistema de correo tal que NO utilizara la tabla de usuarios del sistema, sino que acudiera cada vez que le era necesario, a una tabla propia, obviamente en formato no texto, y adecuadamente indexada, es decir, cuyo acceso no fuera secuencial. Ello obligó a alterar los fuentes de todos los programas servidores (el Sendmail-SMTP, el POP3 y el IMAP) e incluso del programa procmail, con el fin de sustituir la llamada que efectuaban al sistema para consultar la tabla de usuarios, por una llamada a una función propia que consultaba una tabla indexada.

Afortunadamente, el sistema operativo UNIX no utiliza en ningún momento la tabla de usuarios para su funcionamiento interno, pues ella sólo le es realmente útil a la hora de comunicar con humanos. Ello es posible debido a que todo el sistema, internamente, utiliza los identificadores (números) de usuario y no los nombres de los mismos. Esto, a la hora de diseñar el sistema de correo, ha permitido definir los permisos y las cuotas de los ficheros de los usuarios (buzones en general) utilizando los permisos y sistema de cuotas del sistema UNIX, a pesar de utilizar como tabla de usuarios una tabla desconocida para el sistema.

Diseño: los formularios de gestión y el servidor HTML.

Ya hemos visto que, dentro de un servicio de correo electrónico, la gestión de los usuarios de correo es una función completamente distinta de la de enviar mensajes y que, de hecho, se podían separar completamente hasta el punto de que cada una fuera efectuada en una máquina y entorno distintas a la de la otra. Hemos visto también que la gestión del servicio requería imprescindiblemente de un gestor de tablas que fuera capaz de manejar tablas de grandes dimensiones de manera eficiente y que se había optado por un servidor-gestor de tablas de tipo SQL, fácilmente accesible desde otros programas. El siguiente problema que inmediatamente plantea esta aproximación es que, finalmente, el número de tablas necesarias es grande y que las relaciones entre ellas son complejas, por no hablar del número de campos necesarios para archivar y ordenar todos los datos asociados a los usuarios de correo. Obviamente, es gestor de tablas está construído para desenvolverse sin dificultades en este tipo de entorno, pero el manejo de tal complejidad por parte de la o las personas encargadas de la gestión de los usuarios de correo es imposible sin ayuda. Se hace pues necesario el construir (escribir) todo un conjunto de programas que simplifiquen las tareas habituales de la gestión (en particular, el alta, baja y modificación de usuarios), pidiendo los datos y actualizando correctamente todas las tablas en el gestor SQL. En la presente implementación del servicio de correo en la Universitat de València se ha optado por escribir dichos programas en lenguaje PERL, lenguaje que, a pesar de ser interpretado y no compilado, presenta enormes ventajas a la hora de programar, en cuanto a rapidez de programación y versatilidad de las instrucciones de las cuales está dotado.

El siguiente problema se presenta al abordar la interface de comunicación con el usuario (con los gestores de la base de datos de usuarios de correo) de que dispondrán los programas de ayuda a la gestión. Lo ideal en estos tiempos es dotar a los programas de una interfaz gráfica, atractiva y manejable cómoda e intiutivamente a golpe de ratón. Es posible conseguir dicho tipo de interfaz acudiendo a muchos y variados entornos (librerías) que nos proporcionan, cada uno, su versión de dichas posibilidades (en concreto, bajo UNIX: Xwindows y TK). Sin embargo, se deseaba una interfaz de gestión que fuera fácilmente accesible vía la red y requiriera el mínimo conjunto de programas adicionales en la máquina que se estuviera utilizando para acceder a las facilidades de gestión del servidor. Es por ello que se pensó (y finalmente optó) por un método que aprovechaba los programas de comunicación gráfica más extendidos en la actualidad: los navegadores de Internet (p.e.: NetScape y MS-Explorer). Estos programas comunican con sus servidores vía el protocolo de comunicación de páginas WWW: el HTML ("Hyper-Text Markup Language") el cual está dotado de facilidades para definir, muy sencillamente, formularios gráficos.

Por lo tanto, los programas de ayuda a la gestión de los usuarios de correo se diseñaron, en nuestra universidad para comunicarse vía formularios HTML. Sin embargo, para que un navegador Internet pueda conectarse con una determinada maquina servidora y hablar HTML, es necesario que dicha máquina disponga (obviamente) de un programa servidor que se comunique en HTML. En realidad, un programa servidor de este tipo establece la comunicación y dialoga con el navegador, aunque no genera ni interpreta datos en formato HTML él mismo: se limita a pasar la información que se atiene a este protocolo a programas especiales diseñados a tal efecto (CGI's, en el argot aplicable) y que, en nuestro caso, serán los programas de ayuda a la gestión de usuarios de correo. Estos mismos programas generan los formularios necesarios y las respuestas pertinentes escribiéndolos ambos en HTML y pasándolselos al servidor para su transmisión al navegador.

A la hora de escoger un buen servidor HTML, la condición de diseño que recomendaba disponer de los fuentes y de la gratuidad de los mismos inclinó pronto la balanza hacia el servidor más utilizado en Internet: el Apache (que no tiene, hoy en día, rival entre los servidores de libre disposición), a pesar de que se disponía legalmente de un servidor de pago muy considerado: el FastTrack de NetScape.

Obsérvese finalmente que los formularios de ayuda a la gestión de usuarios no sólo están destinados a los gestores del sistema de correo, sino que muchos de ellos se diseñan para facilitar a los propios usuarios del servicio el acceso a sus datos, a la posible modificación de éstos y, en general, a cualquier utilidad que pueda considerarse de interés. En concreto, el funcionamiento del sistema automático que le permite a un usuario, con sólo que disponga de su DNI y el PAN de su tarjeta, activarse su cuenta de correo, está basado en esta aproximación. Del mismo modo funcionan o funcionarán el cambio de contraseña, la redirección de correo, el acceso al listín telefónico y muchas utilidades más.

Diseño: el servidor HTML seguro.

Uno de los inconvenientes más desagradables de los formularios basados en HTML, cuando se requiere autentificación del que envía los datos, es que la identificación del mismo (la contraseña y el usuario) viajan, cada vez (a cada envío y recepción de formulario o datos) y en claro por la red. Efectivamente, el HTML es un protocolo que no establece conexión permanente, por lo que no se almacena ningún parámetro que permita asegurar que una página que se solicita o se envía, en un determinado momento, tiene alguna relación con otra anterior. Ello quiere decir, que cuando se pida usuario y contraseña antes de proporcionar una determinada página, las siguientes páginas, aunque sean derivadas de ésta, volverán a requerir del mismo envío del par de identificación. Es decir, que se enviará a cada vez dicho par, y ello, sin que el usuario normalmente sea consciente de ello, pues el navegador se encarga de almacenar y reenviar cada vez la contraseña y el usuario. Esto es de especial gravedad cuando se observa que, en este caso, se está pensando en el par usuario-contraseña perteneciente a una de las personas autorizadas a gestionar la base de datos de usuarios.

A raíz de esta primera consideración y existiendo en los diseñadores una real consciencia de la cada vez mayor peligrosidad de enviar datos en claro por la red, máxime cuando estos datos van a ser datos de importancia para la gestión de un determinado servicio (el correo electrónico en este caso) se consideró oportuno, para cumplir con la condición de diseño que exige garantizar al máximo la seguridad del servidor, el obligar a que todas las comunicaciones referidas a la gestión de los usuarios de correo fueran criptografiadas. Ello, al incluir todos los formularios HTML de ayuda a la gestión, solventaba además el problema de la transmisión repetitiva del usuario y contraseña del gestor: ambos se transmiten cada vez, sí, pero criptografiados.

La consecución de este nuevo objetivo obligó a instalar y a configurar no sólo el servidor HTML Apache, sino unos módulos auxiliares de establecimiento de conexiones criptografiadas según el estándar SSL ("Secure Sockets Layer") y los correspondientes programas de gestión de claves (el conjunto se agrupa en un paquete conocido como el "SSLeay"). Además, ello obligó a crear una autoridad de certificación (CA, "Certification Autority"), propia a la Universitat de València, para poder certificar las claves que utiliza el servidor, sin tener que recurrir a pagar a una entidad de certificación externa. La gran inversión en trabajo realizada se piensa aprovechar además para otros fines tales como la proporcionar un servicio de páginas WWW seguras para quien lo requiera y permitir el uso de correo electrónico criptografiado.

Diseño: las cuentas de correo no personales, alias.

Entre las condiciones de diseño del servicio de correo se impone la necesidad de que puedan existir en el servidor cuentas de correo direcciones electrónicas no personales, asociadas a un ente o a un grupo de usuarios de correo. Se especifica también que dichas direcciones no deberán tener asociadas una contraseña propia para acceder a las cartas a ellas dirigidas, sino que obligatoriamente irán asociadas a determinados usuarios de correo quienes, con sus contraseñas, accederán a las cartas enviadas a estas direcciones no personales. Esta condición, un poco absurda a primera vista y que levanta no poca incomprensión por parte de los usuarios, es una regla de oro para garantizar cosas tan importantes como la seguridad del servidor y la identificación del destinatario de un mensaje (y facilitar la identificación del remitente, dentro de las limitaciones de la actual definición de correo electrónico). En efecto, el procedimiento directo e intiutivo de asignar "usuarios de grupo o ente", con su buzón y contraseña asociados, para entidades como departamentos, etc. lleva, en una buena parte de los casos, a problemas tales como que las cartas destinadas a estos buzones no son leídas por falta de interés de los mismos que los han solicitado; que las contraseñas, al no ser "de nadie" acaben corriendo de boca en boca hasta ser de dominio público; que nadie sepa quién concretamente ha contestado a una carta dirigida a uno de estos buzones (el que contesta "se olvida" de identificarse); que el buzón se utilize para otros fines muy distintos al declarado (p.e.: para que un amigo que pasa po allí pueda enviar una carta...), etc...

Sentado el principio, pues, de la no creación de "cuentas no personales", se trata de resolver la cuestión de dónde entregar las cartas dirigidas a las direcciones de grupo o ente para que su acceso sea posible a la (o a las) persona(s) interesada(s). El procedimiento seguido en la presente implementación del correo electrónico de la Universitat de València es simplemente redirigir estas cartas al(a los) buzón(es) personales de las personas en cuestión. Se utiliza para ello simplemente el mecanismo de la tabla de "alias" del programa servidor SMTP, el Sendmail, que permite definir una nueva dirección de correo dentro del mismo dominio, tal que se redirigen luego los mensajes a una lista de buzones de usuarios que se define al crear la dirección.

Otra posible solución sería, en el caso de que realmente se generalize el uso de los clienes de correo que utilizen el protocolo IMAP, el que las cartas destinadas a las direcciones de ente o grupo se depositaran en un buzón del servidor (un buzón remoto desde el punto de vista de los usuarios) que tuviera los permisos de acceso adecuados para que pudieran acceder al mismo el (los) usuario(s) correspondientes. Ello obligaría a definir un sistema de definición y gestión de cuotas también para este tipo de buzones.

Procedimientos: los servicios atendidos por personal.

Los procedimientos de gestión asociados al sistema de correo de la universitat de València se derivan directamente de las especificaciones para el mismo. El objetivo primordial de todo el diseño del sistema ha estado enfocado en todo momento a la automatización del máximo número de tareas posibles. Esto se ha conseguido en gran medida, lo que quiere decir que, para muchas de las tareas requeridas por el servicio, el diseño total de la servucción realizó en el momento de escribir los programas informáticos que efectúan las tareas en cuestión y se halla descrita en los algoritmos que representan la función de estos programas. Dichos algoritmos no se describen aquí, sino que dedicaremos esta sección a describir la servucción de los procesos de gestión que aún no han sido automatizados (aunque algunos, en su día, podrían llegar a serlo) y que están siendo atendidos por personal asignado a dichas tareas.

Se recuerda que es condición de diseño el que todos estos trámites se prolonguen menos de 24 horas, es decir, que el tiempo de respuesta sea menor de un día.

Las principales funciones administrativas, vinculadas con la creación, modificación y baja de una cuenta de correo se enumeran pues a continuación:

Creación de un usuario de correo o activación de una cuenta de correo. Este es el primer paso administrativo que deberá realizarse. Se hará siempre a solicitud del interesado (no se crean de oficio cuentas no solicitadas). La solicitud implica siempre identificación suficiente del solicitante y comprobación de su derecho a la cuenta. Existen dos vías para tramitarla:

1) Formulario escrito de solicitud de cuenta de correo. El formulario a rellenar es el siguiente:

###########

Solicitud de cuenta de correo de la Universidad de Valencia

El abajo firmante solicita una cuenta en el servidor de correo de la Universidad de Valencia, y se compromete a acatar las normas de funcionamiento del SIUV.

Apellidos:
Nombre:
Cargo:
Departamento:
Centro:
Teléfono en la Universidad:
Dirección Postal en la Univ.:

Marcar con una cruz: 
[ ] El usuario NO desea ser incluido en la lista pública de cuentas de correo. 
[ ] El usuario NO desea recibir la contestación a esta solicitud por correo ordinario, dirigido a la dirección arriba indicada, sino que pasará personalmente por el SIUV para recogerla (con DNI u otra identificación). 

Fecha y Firma del interesado:

############

Esta solicitud se envía, debidamente firmada, por correo (usualmente interno) al Servicio de Informática para su tramitación. Un operador informático comprueba, consultando las correspondientes tablas en las bases de datos del servidor, que el solicitante es personal de la universidad (está en la tabla de personal con nómina). Si todo es correcto, se le da de alta utilizando los procedimientos automáticos al efecto (un formulario WWW a rellenar); dicho procedimiento genera una notificación de alta en la que se incluye el par usuario-contraseña y la dirección electrónica asignados al solicitante y que es enviada por correo interno al mismo (salvo indicación de lo contrario en la solicitud, en cuyo caso se almacena hasta que el solicitante pase a recoger su notificación de alta), a la dirección indicada en la solicitud. La solicitud se archiva para futura constancia. Si hay algún problema, el operador intenta comunicarse con el solicitante vía el número de teléfono indicado para notificarle la denegación de la solicitud y, en su caso, qué debe hacer para subsanarla. Si la vía telefónica no conduce a nada, se procede a la misma notificación vía correo interno a la dirección mencionada en la solicitud. Si la persona ya tuviera cuenta de correo, se rechaza la solicitud indicando la causa.

2) Formulario WWW de Activación de la cuenta de correo. Este procedimiento, en la actualidad, se halla sólo disponible para los alumnos de la universidad. Se espera en breve extenderlo al personal en nómina, pero no podrá alcanzar a todos hasta que todo el mundo disponga de la tarjeta universitaria. Efectivamente, en este caso la identificación se lleva a cabo mediante la comprobación de dos números propios al solicitante: el de su tarjeta universitaria (o PAN) y el de su Documento Nacional de Identidad (DNI).

El futuro usuario accede a una determinada página del servidor WWW asociado al servidor donde esta la Base de Datos de usuarios, en la que se halla el formulario a rellenar:

############

Activación de una Cuenta de Correo

Datos Necesarios----
PAN: 
NIF: 
Listín: 

############

Una vez rellenos los datos solicitados, el servidor efectúa automáticamente las comprobaciones pertinentes y asigna, tambien automáticamente, un usuario y contraseña a la vez que crea todos los registros y estructuras necesarios para el funcionamiento de la cuenta. Procede a notificar al solicitante los datos generados que le serán necesarios para acceder a su cuenta (usuario, contraseña, dirección electrónica, nombre del servidor en que tiene su cuenta) así como advertirle de algunas precauciones elementales que debe tomar (ver apéndice).

Comprobación de aval para la creación de una cuenta de correo. Una de las condiciones de diseño especifica que deberán poderse conceder cuentas a personas que, en principio, no tienen derecho a ellas (no son personal ni alumno de la universidad), siempre que estén debidamente avaladas por personas con la competencia adecuada para ello. La lista de personas con capacidad de avalar ha sido elaborada en función del cargo que ocupan en la universidad. Cuando una persona externa a la universidad desea una cuenta de correo, debe enviar la misma solicitud de cuenta de correo que una persona de la universidad, pero acompañada de un aval en el que figura la identicación y firma de uno de los avaladores autorizados. Dicho aval corresponde al formulario siguiente:

##########

AVAL DEL DIRECTOR/A DEL CENTRO (Departamento, Instituto, Servicio, Escuela,...)

Este aval se requiere en el caso de no tener relación contractual con la Universitat de València ni estar matriculado en la misma. (cumplimentar TODOS los datos): 

CERTIFICO que la persona arriba firmante, cuyo N.I.F./Pasaporte es: 
(Marcar UNA de las opciones con una cruz): 
[ ] colabora con este centro y debe ser considerada como PERTENECIENTE AL MISMO, 
[ ] está completando sus estudios en este centro y debe ser considerada como ALUMNO DE LA UNIVERSIDAD , a TODOS LOS EFECTOS relacionados con los servidores informáticos de la Universidad. 
En el segundo caso (ALUMNO), dar también estos dos datos (elegir subrayando): Vinculación: 'Alumno', 'Doctorando', 'Alumno Extranjero' Relación...: 'de Cursillo', 'Becario', 'Visitante', 'Contratado' 
Nombre del Centro, Dpto., etc.:
Nombre y Apellidos del Director/a:
Fecha de caducidad de la cuenta: (máximo 1 año)
Fecha y Firma del Director/a: 

##########

El aval contiene unos datos adicionales que el operador encargado de tramitar la solicitud añadirá a los datos que se registran habitualmente cuando se da de alta a un usuario de correo. El operador, además, procederá a registrar la identidad del avalador, comprobando al mismo tiempo su validez como tal (el mismo formulario WWW de registro efectúa automaticamente esta comprobación). El resto de la operativa es exactamente la misma que en el caso de una solicitud de creación de cuenta ordinaria. Obsérvese que, en la solicitud, el avalador debe seleccionar qué tipo de privilegios solicita para el avalado (hoy por hoy, significa simplemente que debe escoger entre que tenga los privilegios asociados al personal de la universidad o los asociados a los alumnos de la misma). Evidentemente, se rechazarán las solicitudes cuyo avalador no esté en la lista de avaladores autorizados.

Modificación y/o Consulta de los datos de una cuenta de correo. Este procedimiento se utiliza en las ocasiones en que el usuario desea o necesita modificar alguno de los datos de su registro personal (p.e.: cambio de número de teléfono, nombre con falta de ortografía,...) o de su cuenta de correo (contraseña, alias, redirección) cuando no existe posibilidad de que modifique sus datos él mismo (vía, p.e. un formulario WWW). En general, bastará con que se haga llegar la solicitud a la dirección electrónica de la administración del servicio de correo electrónico y atención al usuario del mismo (en la Universitat de València: postmaster@uv.es). Dada la inseguridad del correo electrónico, este procedimiento es aplicable tan sólo cuando se trate de datos no críticos y deberá denegarse si hay alguna duda razonable sobre la identidad del remitente. La persona al cargo de la atención al usuario procederá a realizar el cambio, si ello está en su mano, y a notificar de ello simplemente mediante una respuesta al usuario vía el mismo correo electrónico. Si el cambio fuera imposible se denegará la solicitud y se notificará igualmente. Si el cambio fuera posible y excediera de su competencia, el funcionario remitirá la solicitud, mediante redirección de correo electrónico a la persona competente.

Para el cambio de datos críticos, los usuarios deberán tramitarlos por vía correo interno ordinario, mediante solicitud escrita en papel debidamente firmada. Ejemplo de ello, es la solicitud de cambio de contraseña por olvido o extravío de la misma:

#######

Solicitud de cambio de contraseña de correo

El abajo firmante solicita se le asigne una nueva password para su cuenta de correo en el servidor de la Universidad de Valencia.

Apellidos:
Nombre:
Cuenta de correo:
Dirección de correo: .....@uv.es 
Dirección Postal en la Univ.:

Marcar con una cruz:

[ ] El usuario NO desea recibir la contestación a esta solicitud por correo ordinario, dirigido a la dirección arriba indicada, sino que pasará personalmente por el SIUV para recogerla (con DNI u otra identificación).

Fecha y Firma del interesado:

########

Este tipo de solicitudes se tramitarán del mismo modo que las de solicitud de creación de cuenta, incluída la notificación por teléfono, pues el número telefónico del usuario debe hallarse registrado en la Base de Datos.

También se ponen a disposición del usuario diversos formularios WWW automáticos para la modificación y/o consulta de datos registrados, similares al presentado para la activación de la cuenta y disponibles en URL's radicados en el mismo servidor. En este caso la identificación se llevará a cabo comprobando automáticamente el usuario y la contraseña del solicitante (y no ya su PAN y DNI: estos dos sólo se utilizarán para la creación de cuentas). Se procurará que estos formularios abarquen todos los datos que sea posible modificar por esta vía. Se hallan activos actualmente los formularios para modificación de contraseña (obviamente, conocida la antigua) y modificación de redirecciones (sólo en el servidor de fase 1).

Baja de una cuenta de correo. En principio, todos estos procedimientos serán automáticos y no deberán requerir intervención humana. Se procederá automáticamente a la cancelación de una cuenta de correo en el momento en que se alcance su fecha de caducidad o bien, si ésta no existe, cuando la persona haya dejado de tener derecho a el (p.e., ha causado baja en la universidad). Se procederá a la notificación previa vía mensaje de correo electrónico a la cuenta afectada un mes antes de la cancelación. Los datos de la cuenta permanecerán almacenados durante un año desde el momento de la cancelación, por si la cesación de derechos fuera temporal (p.e.: cambio de contrato). Si el avalador de una cuenta lo solicita formalmente, vía escrito con firma dirigido al Servicio de Informática, esa cuenta podrá ser cancelada inmediatamente vía los procedimientos automáticos que se pondrán a disposición de los operadores, al igual que en los otros casos, los datos sólo serán borrados transcurrido el año de la cancelación.

Solicitud de ayuda y/o información (parte centralizada). Estas solicitudes son las más difíciles de gestionar y requieren de toda una infraestructura de "atención al cliente", incluído el personal de contacto debidamente capacitado. Una solicitud de este tipo debe hacerse normalmente vía el propio correo electrónico, dirigido a una dirección (electrónica) preparada a tal efecto (en el caso de la Universitat de València, ésta es la dirección estándar del administrador de correo: postmaster@uv.es). La dirección de consulta se hallará asociada a una lista de distribución que redirige la solicitud al conjunto de personas asignadas al servicio de atención al usuario. Una de éstas personas lee, interpreta y contesta a la solicitud vía el mismo correo electrónico. Si la cuestión excede de su competencia, la solicitud es redirigida, o bien a los encargados de la gestión de usuarios o a las encargadas del mantenimiento del sistema de correo. Si la cuestión no compete al servicio de correo, se procura redirigirla al servicio correspondiente. La persona que conteste debe enviar copia de la respuesta al resto de personas asignadas al servicio, con el fin de que stas conozcan que la solicitud ha sido respondida, puedan cotejarla o aportar alguna corrección y/o puntualización y transmiti al gurpo todo conocimiento particular que pudiera estar hasta entonces sólo en poder de uno. En caso excepcionales (p.e.: imposibilidad de acceder al correo electrónico), se admitirán también solicitudes de ayuda y/o información vía medios no electrónicos (fax, carta de correo ordinario) que serán contestadas del mismo modo o vía correo electrónico, si ello es razonable. También, excepcionalmente y por razones de urgencia, se admitirán preguntas vía telefónica. A éste respecto debe observarse que un servicio de respuesta telefónica es mucho más oneroso (en tiempo consumido por cuestión resuelta) y, generalmente, de peor calidad que el mismo servicio atendido vía correo electrónico.

Solicitud de ayuda y/o información (parte descentralizada). Estas solicitudes son solicitudes de atención personal, a las cuales se dedicará personal operador radicado en el mismo centro en el que se genere la solicitud. La vía de para hacer llegar la solicitud será normalmente la vía directa (en persona), cuando se trate de problemas surgidos en un aula informática y del personal de operación asignado a ella, y la vía telefónica o el correo electrónico cuando se trate de personal de operación informática asignado a un centro. Las solicitudes se atenderán por estricto orden de llegada (a menos de priorización por parte del responsable del centro). La velocidad de respuesta deberá ser inmediata (atención concedida en menos de 10 minutos) en el caso de los operadores de aula (siempre dentro de las posibilidades y carga momentánea de trabajo del operador) y dentro de las 24 horas en el caso del operador de centro (puesto que éste, en general, deberá desplazarse). En todos los casos, para poder responder a una solicitud que involucre algún dato personal de un usuario, el operador deberá previamente identificar con seguridad a la persona que realiza la solicitud, para evitar imposturas.

El correo electrónico: mantenimiento del servicio

Una vez totalmente instalado y configurado el servicio, es decir, una vez adquiridos los medios materiales (ordenadores y periféricos) necesarios, instalados los programas procedentes de fuentes externas, escritos e instalados los programas desarrolados "in situ" y puesto en marcha el servicio mediante la suficiente difusión de la existencia y disponibilidad del mismo entre las personas objetivo, se plantea, inmediatamente a continuación, la necesidad de estimar las necesidades de personal imprescindibles para el mantenimiento del servicio y elaborar una organización de tareas e intercomunicaciones entre los componentes del servicio para cubrir eficientemente dicho mantenimiento.

En el caso del correo electrónico, como hemos comprobado en los apartados anteriores, tenemos que cubrir permanentemente las siguientes necesidades para asegurar su funcionamiento:

1) El mantenimiento del material; lo que requiere, en primer lugar, asegurar el funcionamiento físico de los sistemas utilizados. Para esto existen dos posibles aproximaciones: el acuerdo con la empresa suministradora de un contrato de mantenimiento en el que se establezca un compromiso de reparación en un plazo máximo de tiempo (habitualmente, 24 horas) de todas las averías que puedan surgir durante la vigencia del contrato; o bien escoger, en el momento de la adquisición del material, un sistema cuyos componentes sean muy comunes y siempre disponibles en el mercado, de forma que una sustitución pueda hacerse en el mínimo tiempo posible. Obviamente, esta última solución requiere que el sistema (sus componentes) no sean excesivamente costosos para que siempre sea posible su adquisición y/o reposición sin excesivo "desbarajsute" presupuestario; ello, en nuestro caso, implicaría que el material fuera del tipo utilizado en los PC-Compatibles (clónicos IBM).

Centrándonos en el actual sistema de correo electrónico de la Universitat de València, se ha optado por la primera de las soluciones, el contrato de mantenimiento, indudablemente más segura y también inevitable, puesto que en el momento de la adquisición se decidió comprar un equipo de alta fiabilidad perteneciente a una empresa determinada, lo cual suele restringir drásticamente la disponibilidad de piezas de recambio, así como obligar a una especialización del personal de mantenimiento del material sólo posible dentro de la propia empresa suministradora.

2) El mantenimiento del Sistema Operativo y del Sistema de Correo. Se engloba aquí todo el conjunto de tareas requeridas para asegurar el correcto e ininterrumpido funcionamiento del conjunto de programas que ruedan sobre el sistema material del que se trata en el punto anterior. Ello incluyo dos partes claramente diferenciadas:

a) El Sistema Operativo o conjunto de programas básicos de funcionamiento, no relacionados directamente con la aplicación (el correo electrónico, en nuestro caso) y que son comunes a todos los sistemas servidores del tipo que ha sido adquirido. Para el mantenimiento de esta parte del sistema no es necesario ningún conocimiento específico de la aplicación instalada, por lo que la persona al cargo puede ser alguien con conocimientos generalistas sobre este tipo de sistemas (UNIX en el caso de nuestra universidad). Las labores principales a atender este subapartado son:

- Vigilancia (que NO realización) de las copias de seguridad del sistema, para controlar que se realizan correctamente en los momentos programados.

- Vigilancia, rotado y archivado de los ficheros de logs (trazas de actividad y registros ) del sistema para comprobar la no existencia de anomalías en el funcionamiento del mismo y evitar el bloqueo de todo el conjunto por agotamiento de espacio de almacenamiento. En esta labor de vigilancia también se incluye estar atento a todo posible signo de que la seguridad del sistema pueda haberse visto comprometida. El "rotado" o archivado o vaciado periódico de los ficheros de logs puede automatizarse, pero ello siempre requerirá una supervisión, pues el llenado se hace a velocidad muy variable, dependiendo de las circunstancias, y es necesaria una supervisión periódica del contenido (no se debe archivar un registro sin haber comprobado que no hay anomalías en él).

- Solución a problemas de funcionamiento y de configuración. En principio, éstos deben ser mínimos si el sistema ha sido bien planificado y construído desde el primer momento, sin embargo su aparición es inevitable dada la enorme variabilidad del entorno constituído por el conjunto red+usuarios+programas cliente que se trata de soportar. En algún caso implican una enorme inversión de tiempo, en momentos no planificables "a priori", para evitar el hundimiento del servicio (p.e., en el caso de tener que ampliar en número total de procesos admisibles por el sistema).

- Reconfiguración y/o reestructuración compleja del sistema. Estas tareas surgen periódicamente como consecuencia del agotamiento o inadecuación de parámetros del sistema. Inicialmente inexistentes si el sistema ha sido bien planificado, pueden ser tremendamente costosos en tiempo y material cuando aparecen (p.e.: sustitución o ampliación de unidades de disco por agotamiento de espacio).

b) El Sistema de Correo, o conjunto de programas específicos de correo. Obviamente, si éstos son totalmente estándares, su mantenimiento podrá englobarse en el apartado anterior. Desgraciadamente, las necesidades y condicionantes específicos de una instititución (y de la Universitat de València en concreto) suelen llevar a la implementación de mecanismos que requieren conocimientos muy especializados y que obligan a disponer de expertos especialmente entrenados en el sistema concreto, por lo que la persona al cargo no puede ser un generalista. Es preciso pues disponer de un personal con profundos conocimientos sobre el funcionamiento interno de los programas instalados, sobre todo de los escritos y/o desarrollados en la propia institución. Las tareas a realizar son similares a las del apartado anterior:

- Solución de problemas de funcionamiento y/o configuración específicos al sistema de correo.

- Reconfiguración del sistema de correo (p.e.: instalación de filtros anti-spam).

Obsérvese que puesto que estamos tratando con sistemas con buena parte de desarrollo propio, estas tareas de reconfiguración y/o solución de problemas pueden conllevar un replanteamiento de partes del sistema y obligar a reescribir (rehacer) dichas partes. Ello implica que el personal al cargo del mantenimiento de los programas concretos de correo deba poder disponer, no ya de simplemente de conocimientos de mantenimiento y funcionamiento, sin tambén de medios de programación (escritura y modificación de programas informáticos) suficientes (dígase tener dichas capacidades o personal asociado que las tenga). Obsérvese también que éstas necesidades de programación no van a ser planificables "a priori".

Y otro grupo de tareas inevitable para la supervisión del sistema de correo sería:

- Supervisión de los mensajes de error del sistema. Esta tarea es igualmente de gran importancia y consiste en atender a todos los mensajes de correo electrónico generados por el sistema de correo para notificar a su gestor sobre todo tipo de problemas que pueden surgir al enviar y/o recibir mensajes. Estos mensajes de error o atención, muy abundantes (varios al día), a menudo constituyen el mejor y más precoz indicador de las posibles dificultades de funcionamiento que están afectando al sistema y deben inexcusablemente ser revisados.

3) La gestión de los usuarios. Como se ha hecho notar anteriormente, una parte primordial del sistema de correo la constituye la gestión de los usuarios. Se ha visto también que, cuando el número de éstos es de gran calibre, se han de proveer de los mecanismos suficientes para que el alta/baja/modificación de un usuario (de su registro) sea lo más rápido y cómodo posible y pueda ser atendido por un personal mínimamente especializado, aunque numeroso, dada la magnitud del trabajo que ello supone. Una vez construídos los mecanismos en cuestión, el personal correspondiente deberá ser entrenado en las peculiaridades y, sobre todo, en las normas de funcionamiento del servicio de correo electrónico. En efecto, este personal deberá tomar decisiones de alta/baja/modificación de cierta relevancia y es improcedente que deban tomarlas sin disponer de unas reglas normativas y conocimientos claros y precisos sobre las limitaciones y condiciones del servicio que los descargue de unas responsabilidades que no les compete asumir. Este personal deberá tamitar, entre otras:

- Las solicitudes de alta (en papel o formato electrónico), procediendo a su rechazo aceptación y registro.

- Las solicitudes de modificación de datos que puedan hallarse erróneso en el registro de usuarios.

- Las solicitudes de cambio de configuración (p.e. cambio de contraseñas) de la cuenta de usuarios concretos.

- Las solicitudes de baja provenientes de un avalador.

En todos los casos, todos estos trámites implicarán también el envío de la correspondiente notificación al solicitante.

4) Operación del sistema informático. Estas tareas se hallan reducidas al estricto mínimo, en el caso del sistema de correo instalado, dada la capacidad que tiene el mismo de funcionar en modo (casi) desatendido. Excepto en caso de operaciones de mantenimiento, no se requiere ni apagado ni encendido del servidor, pues éste, con la ayuda del SAI puede permanecer en marcha durante meses. La única labor de operación restante se refiere a la gestión de las cintas en las que se realizan las copias de seguridad del sistema, básicamente cambio y etiquetado de las mismas, lo cual, obviamente requiere de un operador informático, pero no exige de él ningún conocimiento específico mas allá de los usuales para poder ejercer su función. Resumiéndola brevemente, la labor del operador se concreta en colocar en la unidad adecuada la cinta que el sistema le solicita diariamente, vía correo electrónico; previamente, deberá retirar la cinta del día anterior la cual colocará en el archivador correspondiente, no sin antes haberla etiquetado a lápiz con la fecha del día en curso.

5) Atención a los usuarios: se agrupan aquí todas las tareas diarias de respuesta a las solicitudes de información y/o ayuda que los usuarios del sistema de correo electrónico efectúan. Estas solicitudes llegan por dos vías claramente diferenciadas: el correo electrónico y la línea telefónica (y muy excepcionalmente por fax o correo ordinario). En un primer momento, se hallan intermezcladas con las solicitudes de modificación de datos y/o configuración, siendo una de las primeras tareas del personal de atención el separar y redirigir convenientemente estas otras solicitudes. El tipo de cuestiones que pueden llegar a plantear los usuarios a través de este canal es de tal variedad (¿cómo se configura? ¿porqué no me funciona ...? ¿qué significa este mensaje ...? ¿ cómo evitar este error ... ? ¿qué he de hacer si quiero ... ? ¿cuál es el servidor de ... ? ¡No me va! ... ) que su respuesta requiere conocimientos extremadamente amplios de mucho calado sobre el funcionamiento, no sólo del sistema de correo electrónico, sino de cada uno de los posibles clientes de correo (o por lo menos de los más utilizados) que se hallan a disposición de los usuarios, por no hablar de conocimiento suficiente de los problemas a que puede dar lugar la propia red. Este personal, además, constituye obviamente el "personal de contacto", del servicio con sus usuarios y, por consiguiente, deberá estar dotado de las cualidades de empaía necesarias para entender, a partir de información, a menudo fragmentada, inconexa y mal expresada, la necesidad (pregunta) del usuario. Se requerirá adicionalmente a este personal el poseer unas dotes correspondientes de tacto, amabilidad, corrección y ... buena ortografía y expresión escrita (no hay que olvidar que el 90% de las solicitudes se reciben y contestan vía el propio correo electrónico) para no ofender a los usuarios accidentalmente.

El tiempo exigido para poder dar respuesta y/o tramitar una cuestión planteada por un usuario es, al igual que el tipo de preguntas en sí, extremadamente variable y, a menudo, es muy difícil de cuantificar "a priori", aún a la vista de la pregunta. Únicamente la experiencia permite evaluar los costes asociados a este servicio que, hoy en día, con unos 10.000 usuarios, se puede cuantificar en unas 3 a 4 horas al día de personal altamente cualificado (programadores y analistas). Una organización más eficiente de este servicio, tal como se propone en el apartado correspondiente, permitiría reasignar de 1.5 a 2 de éstas horas a un operador. Nótese que en estas cifras ya se supone la existencia de la "operación in situ" para filtrar, en primera aproximación, la gran mayoría de las preguntas.

6) Atención "in situ" a los usuarios. Idealmente, y excepto en casos de respuesta muy clara y concisa, la atención a los usuarios descrita en el apartado anterior se debería proporcionar de forma personalizada, con desplazamiento de la persona de contacto al lugar de trabajo del usuario; o, por lo menos, sería deseable acercar el personal de contacto al usuario de forma que éste pudiera, con un mínimo desplazamiento y si lo desea, realizar sus consultas de persona a persona. Este tipo de atención es, obviamente, muy onerosa y sólo viable cuando existe personal suficiente para ello. Sin embargo, una solución intermedia no es sólo viable sino deseable: distribuir el personal de contacto. En efecto, dado que la respuesta a gran parte de las cuestiones planteadas por los usuarios (más de las dos terceras partes) está al alcance de un operador informático debidamente formado en las peculiaridades de funcionamiento del sistema de correo en la universidad, es viable abordar esta atención a los usuarios de forma distribuída, aprovechando la existencia, en nuestra universidad de personal operador de aula informática y/o operador de soporte informático a un centro. Este tipo de operadores, aparte de la mencionada y necesaria formación específica sobre el correo electrónico de la universidad, estará, en mor de su puesto de trabajo, ya especialmente preparado en cuestiones relativas a la instalación y configuración de clientes de correo electrónico, así como de los sistemas opertivos que acompañan a los ordenadores personales habituamente utilizados por sus usuarios. Si a ésto se añade además el conocimiento profundo, del que suelen disponer, sobre el funcionamiento e instalación de los sistemas informáticos de su centro, incluída la propia red, hace que los operadores de centro y/o aula se conviertan en el personal ideal para constituirse en "personal de contacto a primer nivel" del servicio de correo electrónico. Obviamente, la asignación de este nuevo tipo de tareas de soporte a sus usuarios, implicará para los operadores un aumento de su carga de trabajo, por lo que puede ser necesario considerar, en ciertos casos, la ampliación de su número o el cambio de prioridades en sus funciones. Dada la enorme cantidad de usuarios, se estima que la distribución del soporte a los mismos, tal como se está llevando a cabo, es la única manera viable de conseguir cumplir con este objetivo.

El correo electrónico: personal.

En el apartado anterior se han descrito las grandes categorías a las que deberá pertenecer el personal necesario para asegurar el mantenimiento del servicio. Éstas son:

1) Analista de sistemas UNIX (30 min.).
2) Analista de sistema de correo (30 min.).
3) Programador de sistema de correo (1 h.).
4) Operador de la gestión de los usuarios (1 h.).
5) Operador de sistema informático (7 min.).
6) Personal de atención central al usuario (profesionalmente, operador como mínimo) (3 h.).
7) Operadores de atención distribuída (10 h.)

El coste o dedicación ESTIMADOS por día de cada uno de ellas se ha puesto entre paréntesis. Téngase en cuenta que estos valores son aproximados, pudiendo sufrir enormes variaciones según las circunstancias puntuales. Los valores pequeños (en minutos) son promedios de las horas semanales que deben usualmente dedicarse a la tarea en cuestión. La separación de funciones, aunque deseable no ha sido siempre posible por falta de medios (de personal), por lo que estas tareas a menudo se concentran en un grupo reducido de personas. Concretamente, las funciones 1, 2, 3 y un tercio de 6, están atendidas en la actualidad, a tiempo parcial, por una única persona (obviamente, un analista). Estas necesidades, en la fase de desarrollo y perfeccionamiento del sistema en la que nos hallamos actualmente se multiplican enormemente, sobre todo en lo que se refiere a las funciones 1,2 y 3 e incluso de 6 y 7 (formación de los usuarios). Obsérvese que la estimación sobre la función 7 esta hecha sin ningún tipo de contraste con la realidad, por lo que puede ser totalmente errónea.

El correo electrónico. Estado actual y previsiones.

En la actualidad (Mayo de 1998) la primera fase de la implementación del servicio de correo electrónico en la universidad de Valencia se dió por prácticamente completada hace más de un año, es decir la parte dedicada a dotar de un primer servicio de correo a todo el personal que trabaja en nuestra universidad. Se está en pleno desarrollo de la fase 2, es decir, la extensión del servicio a la totalidad de los alumnos, habiéndose iniciado ésta hace menos de 2 meses. El número de usuarios de correo es de casi 6500 en el servidor de personal, de los cuales 2500 son personal no en nómina, pero que colabora con algún departamento y, por lo tanto, ha sido avalado por él. En cuanto al servidor de alumnos, el número de usuarios se eleva a 4000, de los cuales hay 40 personas que no son oficialmente alumnos pero que se hallan avalados por algún cargo de la universidad. Para hacerse una idea de la cantidad de información manejada por el servidor de correo, baste decir que, entre el 4 de noviembre de 1996 y el 27 de mayo de 1998 (19 meses) el servidor de personal ha enviado 2.5 millones de mensajes (48.5 Gbytes de información) y ha recibido 5 millones de mensajes (85 Gbytes de información), es decir, ha procesado un promedio de 500 mensajes a la hora.

El número de líneas de programa escritas para implementar el servidor de fase 1 fueron más de 6000, el servidor de fase 2 ya ha requerido de más de 9000.

En este momento se está procediendo a adaptar el antiguo sistema de fase 1 para incorporarle todos los nuevos mecanismos que se fueron desarrollando al tiempo que se diseñaba e instalaba el nuevo servidor de fase 2. Este último está aún lejos de estar completado, faltándole funciones tan importantes como la recepción de paquetes y la posibilidad de redirigir el correo. Al mismo tiempo que se realizan los pasos previstos, van surgiendo nuevos problemas, a veces de urgente resolución (p.e.: los ataques producidos por los "spammers") cuyas soluciones se van incorporando progresivamente al sistema. Aparte de ello, se están diseñando nuevas posibilidades, entre las cuales cabe citar la previsión de que, en más o menos breve plazo, se procederá a la fusión de las tablas de los dos servidores actuales para centralizar en uno sólo de ellos toda la gestión de usuarios. Ello permitirá, no sólo utilizar los nuevos programas desarrollados para el nuevo servidor en la gestión del antiguo, sino que, al integrar la información en un único conjunto de tablas hará más fácil el mantenimiento del sistema en su conjunto, permitiendo, p.e., el que el personal de la universidad que disponga de tarjeta universitaria active su cuenta sin necesidad de enviar solicitud escrita como hasta ahora. Además, se está considerando seriamente la instalación de utilidades en el servidor WWW del servidor de correo que permitan la consulta y gestión de los mensajes de correo vía formularios WWW, sin necesidad de utilizar clientes específicos de correo, para minimizar el esfuerzo de aprendizaje de la herramienta por parte de los nuevos usuarios; asímismo, se prevee instalar todo el entramado de servidores y procedimientos de gestión requeridos para un servicio (desde luego, piloto, en una primera aproximación) de correo seguro, es decir criptografiado y firmado con firma autentificada. Mientras, se está vigilando continuamente el crecimiento del sistema de fase 2 para poder responder con prontitud si se presentaran problemas a medida que alcanza su número de usuarios "de crucero" (¡ estimado en unos 30.000 !).