email Proxy Introducción Al momento no se cuenta en Velneo vserver con herramientas para el envío de correo electrónico desde el servidor, algo que resulta sumamente útil ya que el desarrollador se desentiende de las tareas de configuración de los componentes necesarios para que un servidor de correo funcione como tal. Planteado esto, surge la necesidad de poder contar con una herramienta que oficie como un proxy de correos electrónicos. El por qué un proxy y no un servidor, porque esta herramienta hace uso de la OpenApp vmailwin para poder, desde un único lugar, enviar los correos que los usuarios de una aplicación cualqueria dentro de vserver, envíen. Que beneficios plantea algo así? Este proyecto surge luego de haber migrado una serie de aplicaciones en uno de nuestros clientes, donde el mismo hace un uso intensivo del envío de correo electrónico entre sus usuarios. En V6 esto está claro que no tiene complejidad alguna, pero en V7, a pesar de que algunos puedan pensar que es también muy simple; ocurre que para enviar correos debemos hacer uso de vmailwin que por sus características, es ejecutado exclusivamente en el cliente. El problema es cuando nos enfrentamos a una red corporativa, donde los clientes no tienen un libre acceso al servidor de correo de la empresa, sino que lo hacen através de las soluciones destinadas a tal efecto. Esto quiere decir que si incluímos el módulo de envío de correo en nuestras aplicaciones, heredando vmailwin y usando sus funciones, tendremos indefectiblemente un problema al momento de acceder al servidor de correo definido en los parámetros de la DLL. En este momento se nos plantea la posibilidad de hacer uso de las funciones y procesos de vmailwin con llamadas en 3er plano (en el servidor) lo cual a primera vista solucionaria el problema. Esto es incorrecto, porque el uso de DLL's en 3er plano, compromete la seguridad de todo el sistema, por tanto no se van a ejectuar dichos procesos. La Solución Antes de explicar cual es la solución, debemos dejar bien en claro que la misma aplica explícitamente a nuestra realidad, pero creemos que sí puede ser un aporte interesante para alguien que tenga entre manos un problema como el que planteamos.
Entonces, para solucionar la centralización de los envíos de correo electrónico en una red corporativa, con altos niveles de seguridad, desarrollamos email Proxy. email Proxy es una solución con un proyecto de aplicación y otro de datos y que a su vez hereda vmailwin. En esta imagen podemos ver cual es el esquema de herencia aplicado: De vmailwin no diremos ni explicaremos nada, ya que tiene la suficiente documentación en el tutorial de vmailwin (http://velneo.es/tutor de vmailwin 10/). Pero empecemos por el proyecto de datos de email Proxy:
Las tablas: E_Mails SETTINGS Lo que podemos apreciar claramente es que SETTINGS es para uso interno de email Proxy y E_MAILS es la tabla que será alimentada desde las aplicaciones que hereden Mail Router. En la tabla de parámetros se almacenan los datos necesarios para ser pasados a la DLL en vmailwin.
Visto el proyecto de datos, veamos el proyecto de aplicación: Sin dudas son muy pocos elementos los que consituyen el proyecto de aplicación ya que el mismo oficia como una consola para verificar lo que esta sucediendo con los mails que los usuarios envían. En el formulario CONTROL_PANEL reside la mayoría de la lógica del sistema, donde se muestra el estado de los mails que se envían mediante email Proxy y la configuración del servidor de correo seleccionado.
Tiene un timer de 10000 milisegundos (10 seg.) para ser usado en la conexión de evento ON_TIMER que dispara el evento ON_TIMER.
El código esta completamente documentado en cada uno de los bloques donde se realizan los distintos procesos. A tener en cuenta Para los archivos adjuntos (por ejemplo informes en PDF), en el vserver hay que hacer una carpeta compartida, por ejemplo email Proxy, dentro de la cual residirán los archivos de la solución más una carpeta llamada adjuntos para que mediante el SDV se suban los archivos a adjuntar desde los clientes. El proceso de adjuntar es un poco atípico pero en definitiva si no se hace de esta manera, la DLL vmail no puede adjuntar correctamente el archivo correspondiente. En el siguiente esquema se muestra conceptualmente como funciona email Proxy en combinación con otra aplicación que lo herede.
Conclusión Con esta solución podemos destinar, por ejemplo una máquina virtual, donde se ejectue email Proxy, para que se encargue de enviar los mails que se generen desde las aplicaciones que hereden a la misma. Esto en términos de seguridad es por demás interesante, ya que los administradores de la red solo tendrán que preocuparse por el control de una sola máquina que envíe los mails dentro de la corporación. Además, los clientes no tienen que instalar ninguna DLL generado aún más confianza en ellos ya que están usando una solución corporativa para compartir información de sus aplicaciones.