logo-IRIS
  
> Inicio
> Sitemap
> Contacto
> Buscador
  



< Servicios < Correo electr�nico

Servicio Correo Electr�nico RedIRIS
Dise�o de un Servicio de correo electr�nico

Plan de direccionamiento Topolog�a del servicio Medidas de prevenci�n Pol�tica de uso Politica de RedIRIS

Servicio Correo Electr�nico RedIRIS

Introducci�n

El dise�o de una Servicio de correo electr�nico est� �ntimamente relacionado con la topolog�a f�sica (red) de la organizaci�n y por lo tanto debe intentar acoplarse a ella. La estructuraci�n id�nea de este servicio es un encaminamiento de correo centralizado. Basicamente, consiste un serie de servidores locales de correo distribuidos a lo largo de la red y centralizados en una Estafeta central, la cual ser� responsable de encaminar todo el correo hacia y desde el exterior.

Antes de dise�ar una estructura corporativa del servicio de correo electr�nico hay que crear un "Plan de direccionamiento del sistema de correo electr�nico para la organizaci�n". El Plan de direccionamiento y encaminamiento de correo de estra imbricado con la estructura de un servicio de directorio, tal y como se ha comentado con anterioridad.

Plan de direccionamiento del sistema de correo electr�nico

Un plan de direcciones debe de tener en cuenta los siguientes principios elementales:

  • Una direcci�n de correo no debe de ser excesivamente larga pero tampoco excesivamente cr�ptica.

  • La parte identificadora del usuario debe intentar de contener dos campos que definan nombre y el primer apellido del responsable del buz�n.Habria que definir un limite m�ximo del n�mero de caracteres. Estilo: nombre.apellidos. Ejemplo: carles.subirats.

  • Ha de reflejar la estructura organizativa de la instituci�n con objeto que la direcci�n de un usuario pueda deducirse facilmente conociendo sus datos personales y los de la unidad administrativa a la que pertenece. No habr�a que abusar de la jerarqu�a mas all� del tercer nivel. Estilo: nombre.apellidos@OU1.O.es. ( OU=Unidad de organizaci�n, O=Organizaci�n). Ejemplo: jesus.heras@rediris.es

  • Deber�a de ser flexible y capaz de absorver potenciales cambios organizativos dentro de la propia instituci�n.

  • Es muy importante que el dise�o del direccionamiento sea jer�rquico y no plano pues puede tener repercusiones en una hipot�tica organizaci�n del Servicio de Directorio.

Topolog�a de un Servicio de Correo Electr�nico

Definici�n de t�rminos

Es importante definir una serie de sencillos conceptos a la hora de intentar definir un modelo de encaminamiento de correo electr�nico en un Organizaci�n.

  • Encaminamiento directo. Es el que permite que cualquiera de los servidores de correo locales establezcan contacto con las m�quinas remotas, responsables del buz�n destino.

  • Encaminamiento indirecto. Es el que utilizan m�quinas intermedias como almacenes para el reenvio, para lo cual debe de existir cierta consistencia de la topolog�a.

  • Estafeta (MTA o servidor de correo). Es una m�quina configurada de tal forma que sea capaz de ofrecer servicio de correo al espacio de direcciones de las que es responsable. Ejemplo: sendmail, PMDF etc.

  • Cliente de correo (UA o Agente de Usuario). Es el paquete de software que interactua con la Estafeta y ayuda al usuario a gestionar el correo electr�nico. Ejemplo: Eudora, Communicator etc.

Modelo propuesto

El modelo que se propone, Figura 3., es un modelo basado en encaminamiento indirecto que dar� lugar a una topolog�a centralizada en un Servicio de correo electr�nico. El elemento clave que articula todo el Servicio es la Estafeta Central de correo a trav�s de la cual deber� encaminarse todo el correo entrante y saliente. Esta Estafeta ser� el motor de una estructura jer�rquica de servidores (Nivel 2, Nivel 3 etc) que configurar�n completamente el mapa de encaminamiento de un Servicio de Correo Electr�nico.

En ciertas circustancias, este modelo puede ser flexibe e implementar cierto de grado de encaminamiento directo. Esta opci�n debe ser coordinada por el equipo de personas responsable del Servicio. Se deber� evitar la aparici�n de servidores de correo con encaminamiento directo en centros, departamentos, delegaciones etc pertenecientes a la propia organizaci�n que ofrece el Servicio. Esta situaci�n producir�a un incremento de �islas� que desvirtuar�an y degradar�an el Servicio.

El mapa topol�gico de Estafetas secundarias (Nivel 2) deber� ser un reflejo de la estructura f�sica de la Intranet de la organizaci�n. Es decir, cada red de �rea local deber� de tener un servidor de correo de Nivel 2 que ofreciera servicio a sus usuarios .Estas Estafetas secundarias estar�n configuradas de tal forma para que trabaje de forma cooperativa con la Estafeta central.

Evidentemente este modelo centralizado supone un grado superior de recursos y por lo tanto, estar� condicionado por par�metros como disponibilidad del personal, m�quinas etc. Si por cualquier motivo no es posible una estructura centralizada es muy aconsejable que los responsables del Servicio supervisen y aprueben las configuraciones de servidores de correo locales para una mejor gesti�n.

La Estafeta Central, como tal, no interviene en la distribuci�n de correo electr�nico intradominio.

Nota impotante: Es imprescindible para el correcto desarrollo de un Servicio de Correo Electr�nico disponer de una Estafeta Central de repuesto (backup) interna para el caso en que no est� operativa por muy diversos motivos (fallos del sistema, alimentac�n, red, ataques etc). Esta m�quina de repuesto debe de estar siempre preparada, configurada y actualizada para cuando necesite actuar.

Funciones de la Estafeta Central

Las dos principales funciones de una Estafeta Central deben ser:

  • Correo entrante desde Internet. Recoger todos los mensajes dirigidos al dominio de la Organizaci�n y encaminarlos hacia las Estafetas sencundarias y/o, si los hubiera, clientes de correo (UA).

  • Correo saliente hacia Internet. Habria dos posibilidades:

    1. Estafetas secundarias con encaminamiento indirecto (opci�n deseable). Estos servidores estar�n configurados para que todo el correo exterior sea encaminado a trav�s de la Estafeta Central.

    2. Estafetas secundarias con encaminamiento directo (opci�n no deseable).

    Estos servidores de nivel 2, estar�n configurados para poder encaminar el correo exterior usando directamente los registros de tipo MX del DNS y establecer una conexi�n directa con la Estafeta destino.

    Evidentemente y para optimizar recursos, una Estafeta central o secundaria no s�lo tiene que ser dedicada en exclusividad a una labor de encaminamiento. Una Estafeta deber� de usarse para ofrecer servicio a los usuarios locales mas cercanos.

    Si existen direcciones del tipo nombre.apellido@organizacion.es (sin subdominio) es la Estafeta principal la encargada de resolverlas localmente, bien por medio de cuentas locales o por otros mecanismos.

    Todo el correo intradominio es enviado por la Estafeta Central a las secundarias sin tener en cuenta el manejador asignado (MX) en Domain Name System (DNS).


Ventajas de una topolog�a centralizada

Partiendo de una Estafeta central perfectamente configurada, dise�ada, gestionada y dimensionada, podemos ennumerar las siguientes ventajas de una estructura centralizada para un Servico de correo electr�nico local.

  • Centrar recursos humanos y t�cnicos en una sola m�quina que permita configurarla y gestionarla de forma �ptima para tenerla siempre operativa.

    Este apartado es especialmente importante para proteger la m�quina contra todo tipo de ataques de seguridad a trav�s del correo, como los descritos en el Apartado 1.

  • Mejorar la fiabilidad de entrega del correo destinado a usuarios locales (desde Internet) y externos (hacia Internet) al ser una m�quina de alta disponibilidad.

  • Mejorar la gesti�n de cara al usuario. Habr�a un �nico punto informativo, que facilitar�a al usuario las solicitudes de consejo y ayuda sobre el Servicio de correo electr�nico.

    Este tipo de gesti�n al usuario puede estar distribuido entre los responsables de las Estafetas secundarias. Pero siempre manteniendo unas directrices de coordinaci�n, con objeto de ofrecer un Servicio homog�neo. De igual forma la imagen de servicio desde el exterior seria mas elegante y operativa.

  • Simplificar la gesti�n de las m�quinas servidores de correo al implementar configuraciones semejantes, conocidas y por tanto controladas.

Servicio de operaci�n

Un Servicio de correo centralizado necesita una serie de requisitos m�nimos para su correcto mantenimiento, entre los que podemos destacar.

  • Equipo humano de gesti�n del servicio. Responsable de la estafeta central y de la coordinaci�n de la gesti�n de otros servidores de correo secundarios repartidos a lo largo de la toda la organizaci�n.

    Este equipo de gesti�n debe de estar accesible a trav�s de un buz�n universal:

    postmaster@organizacion.es

    el cual debe de ser atendido de forma frecuente, pues es a trav�s de �l donde los usuarios internos y externos podr�n canalizar sus dudas y/o propuestas. Es aconsejable que este buz�n vaya acompa�ado de un tel�fono de contacto y fax.

  • La m�quina responsable del servicio deber� de estar operativa 24 horas al dia 365 dias al a�o, exceptuando las habituales operaciones de mantenimiento que deber�an de interumpir m�nimamente el propio servicio.

  • Se dispondr� de un servidor de reserva para el caso que la principal tuviera algun tipo de problemas. Esta m�quina deber� de estar en perfecto estado de operaci�n y configuraci�n.

  • Servicio de Domain Name System (DNS). Para el correcto funcionamiento del servicio es importante un estrecha coordinaci�n con los responsables del DNS, fundamentalmente en los registros de tipo MX, donde los responsables del correo deber�an dictar de forma estricta este tipo de registros.

Implementaci�n de una topolog�a centralizada

Nivel de red
Para recoger beneficios con la implantaci�n de una topolog�a centralizada es necesario la utilizaci�n de medidas expeditivas como es el filtro del puerto 25 en el conmutador que da acceso a Internet.

El filtro en el puerto 25 define una pol�tica de correo centralizada, pues permite que s�lo la m�quina que realiza las labores de Estafeta Central y la m�quina de reserva, si la hubiera, sean accesibles desde Internet a trav�s del puerto 25 responsable del protocolo de tranferencia de correo electr�nico (SMTP). Es decir ninguna m�quina servidora de correo de la organizaci�n deber�a de poder recibir correo directo desde Internet.

De la misma forma este filtro, debe de impedir que las m�quinas locales puedan enviar correo directamente via SMTP. Se debe el encaminamiento de datagramas originados o destinados a m�quinas diferentes de la Estafeta. Con este mecanismo lo que en verdad se est� implementando, es lo que en Internet se denomina firewall o cortafuergos. Se ha comentado anteriormente la gran utilidad de este filtro para la implementaci�n de mecanismos de seguridad. Esto permitir� concentrar todos los recuros humanos y t�cnicos en hacer de la Estafeta central la m�quina mas segura de la red local.

Nivel DNS
El DNS o Domain Name System es el n�cleo de todas las aplicaciones de Internet. Es el sistema empleado en la Red para poder asignar y usar de forma universal nombres un�vocos para referirse a los equipos conectados a la red. De esta forma, tanto los usuarios humanos como las aplicaciones pueden emplear nombres de DNS en lugar de direcciones num�ricas de red IP.

De todos los tipos de registros de DNS el que m�s nos interesa son los de tipo MX (Mail eXchange) que es el va a indicar cual es la Estafeta responsable de un determinado buz�n. Los registros de tipo MX deben de ser definidos por los responsables del Servicio de Correo y se debe de seguir la siguiente pol�tica:

"Se ha de definir un registro de tipo MX para cada una de las m�quinas susceptibles de recibir correo electr�nico (Estafetas de correo)"

Para reflejar lo topolog�a centralizada del Servicio de correo electr�nico es necesario:

  • Definir un �nico registro de tipo MX de prioridad m�xima y otro de prioridad menor (estafeta de reserva) para cada una de las direcciones del espacio de direccionamiento definido por la organizaci�n.

  • Definir un registro de tipo MX para el acr�nimo de la organizaci�n, aunque s�lo sea para dar cobertura a la direcci�n postmaster@ogz.es.

  • En el caso de alias de m�quinas implementar registros de tipo A antes que de tipo CNAME.

Ejemplo
Partimos de los siguientes datos:

  • Una organizaci�n hipot�tica con el acr�nimo ogz en el dominio es.

  • La direcci�n de la Estafeta es: mail.ogz.es

  • La direcci�n de la Estafeta de reserva es: bib.ogz.es.

  • Un departamento con un espacio de direcciones: nombre.apellido@bib.ogz.es.

  • Este departamento tiene un servidor de correo con el nombre de m�quina cervantes (Estafeta secundaria) con la direcci�n: bib.ogz.es.

La configuraci�n del DNS ser�a:

  ogz.es		IN	MX	10	mail.ogz.es
  ogz.es		IN	MX	20 	bib.ogz.es

  bib.ogz.es		IN	MX	10	mail.ogz.es
  bib.ogz.es		IN	MX	20	bib.ogz.es
  cervantes.ogz.es	IN	A	 	148.195.290.2
Importante: No deben de implementarse registros del estilo:

*.ogz.es	IN	MX	10	mail.ogz.es

pues s�lo se deben de reflejar direcciones susceptibles de recibir de correo. Estas entradas invalidades en el caso de existir registros de tipo Address (A) intentando establecerse conexiones a trav�s del puerto 25.

RedIRIS © 1994-2007
^