Tutorial de Sendmail - Organización con divisiones administrativas

En organizaciones muy grandes es frecuente que se establezcan áreas relativamente interdependientes pero separadas. Por ejemplo, geográficamente.

A fin de optimizar el rendimiento, el diseño de la configuración de email debe aprovechar estas características.

Solución trivial: Diversos dominios

Supondremos que nuestra organización se llama "inkacoca" y que tiene sucursales en las ciudades de Lima, Trujillo, Cuzco, Iquitos y Puerto Maldonado. Asumimos que la organización ha adquirido la autoridad del dominio "inkacoca.org".

En ese sentido, una manera de operar sería crear los siguientes subdominios, que corresponderían a las direcciones email respectivas:

Tabla 1.

|| Ciudad || Dominio || Dirección email ||
|| Lima || lima.inkacoca.org || usuario@lima.inkacoca.org ||
|| Trujillo || trujillo.inkacoca.org || usuario@trujillo.inkacoca.org ||
|| Cuzco || cuzco.inkacoca.org || usuario@cuzco.inkacoca.org ||
|| Iquitos || iquitos.inkacoca.org || usuario@iquitos.inkacoca.org ||
|| Puerto Maldonado || pmaldonado.inkacoca.org || usuarios@pmaldonado.inkacoca.org ||

Luego se configurarían servidores de email independientes para cada ciudad. Desde el punto de vista del email, cada subdominio viene a ser una organización independiente. En cada servidor (en cada ciudad) el administrador crea sus propias cuentas independientes.

El DNS deberá contener entradas independientes para cada uno de estos servidores (aquí llamados lima-mail, tru-mail, cuzco-mail, iqui-mail, pto-mail.)

|| ; archivo de zona de inkacoca.org lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 trujillo IN MX 10 tru-mail tru-mail IN A 18.1.4.40 cuzco IN MX 10 cuzco-mail cuzco-mail IN A 18.1.5.40 iquitos IN MX 10 iqui-mail iqui-mail IN A 18.1.6.40 pmaldonado IN MX 10 pto-mail pto-mail IN A 18.1.7.40 ||

Los problemas de este esquema son:

1. No se está reflejando el dominio único de la organización (nadie tiene cuenta de la forma usuario@inkacoca.org)
2. Las direcciones de email son muy largas

Un sólo dominio

Tratemos de mejorar el esquema anterior. Intentemos que todas las direcciones sean de la forma usuario@inkacoca.org, manteniendo los cinco servidores en cada ciudad. El primer inconveniente de este esquema es que si tenemos dos usuarios llamados "diego" en Lima y Cuzco, y ambos originalmente tenían direcciones:

|| diego@lima.inkacoca.org diego@cuzco.inkacoca.org ||

ahora habrá que buscar una forma de diferenciarlos. Por ejemplo, podríamos usar "diego1" y "diego2". Esto, si bien no es estéticamente agradable, puede ser mejorado con el uso de aliases. Pero dejaremos esto para más adelante.

Ahora bien, si un mensaje llega desde el exterior a "usuario@inkacoca.org", ¿qué servidor lo recibe?

Una posibilidad es designar un servidor adicional (ubicado en cualquier ciudad) para que sirva como "switch", aunque podría ser cualquiera de los otros, como veremos.

Este servidor deberá ser capaz de redirigir el mensaje al servidor adecuado. Es decir, deberá disponer de una tabla similar a:

Tabla 2.

|| Usuario || Destino ||
|| diego1 || lima.inkacoca.org ||
|| diego2 || cuzco.inkacoca.org ||

Esto es precísamente lo que hace el archivo virtusertable que se discutió anteriormente en la sección "dominios virtuales".

Para esto, el archivo /etc/mail/virtusertable contendrá algo como:

|| diego1@incakoca.com diego1@lima.inkacoca.org diego2@incakoca.com diego2@cuzco.inkacoca.org ||

Recuérdese que se debe generar la versión "compilada" como se vio anteriormente.

Adicionalmente se requieren registros en el DNS para el "mail switch":

|| ; archivo de zona de inkacoca.org @ IN MX 10 switch switch IN A 18.1.3.41 lima IN MX 10 lima-mail lima-mail IN A 18.1.3.40 trujillo IN MX 10 tru-mail tru-mail IN A 18.1.4.40 cuzco IN MX 10 cuzco-mail cuzco-mail IN A 18.1.5.40 iquitos IN MX 10 iqui-mail iqui-mail IN A 18.1.6.40 pmaldonado IN MX 10 pto-mail pto-mail IN A 18.1.7.40 ||

Todo esto permite que los mensajes destinados con @incakoca.org lleguen al servidor de correo local que les corresponde.

Los problemas pendientes son:

Pérdida de independencia

Cada administrador local debe notificar al administrador del switch de que se ha creado un usuario local a fin de que se le registre en virtusertable. Se pierde independencia y no hay una forma sencilla de evitar esto.

Ineficiencia en escritura de direcciones

Cuando un mensaje se envía desde el interior de la organización a otro usuario de la organización, es necesario especificar la dirección de email completa (usuario@inkacoca.org.) Sería deseable usar sólo el nombre del usuario y que el sistema asuma que se trata de la organización.

Ineficiencia en los envíos locales

Si se envía un mensaje desde Iquitos a otro usuario en Iquitos usando su dirección email "usuario@inkacoca.org", el mensaje (de acuerdo al DNS) irá primero al switch de la organización y luego !retornará! a Iquitos. Esto es correcto pero ineficiente.

Sería deseable que si el usuario destinatario es local al remitente, entonces el mensaje no tenga que viajar hasta el switch.