Note (email 2.0), Contenido Contenido. 1. Introduccién. 2. (Qué es Note (email 2.0)?.. 2.1. Casos de uso 3. Componentes de Note (email 2.0) . 4. Conocimientos aplicados para Note (email 2.0). 5. Note (email 2.0): especificacion técnica .. 5.1, Usuarios (Contactos) .. 5.2. Servidores. 5.3. Mensajes ..... 5.4. Carpetas... 5.5, Estructura de datos detallada.. 5.6. Modelo arquitecténico y de implementacién 6. Note (email 2.0): especificacién funcional... 6.1. Introduccion cr 6.2. IU del Web mail detallada... 6.3, IU Gestién interna de la aplicacién 7. Note (email 2.0): implementacién.. 7.1. Lista de archivos 7.2. Diagrama de clases 7.3. Puesta en inicio de un servidor Note (email 2.0) 8. Note (email 2.0 9. Note (email 2.0): objetivos futuros. incidencias conocidas/abiertas .. 10. — Valoracién econémica del proyecto .. 10.1. Comentarios sobre el proyect 11. Conclusion ....... 12. Anexos.. 12.1. {Qué es un Web Service’ 12.2. Kerberos y sistema de tickets 13. Bibliografia .. 14. GlOSAriO -sssseesseessseeee 15. Agradecimientos Pagina 4 de 611. Introduccion email se ha convertido actualmente en una herramienta vital para las empresas, Esta herramienta permite luna mayor velocidad y establecer una comunicacién entre empresas, proveedores y clientes de forma més efectiva, Gracias @ la potencia de Internet y la facilidad de uso del email, hoy en dia la mayoria de empresas pueden ofrecer productos y servicios a clientes situados en el otro lado del mundo, incluso coordinar departamentos y delegaciones externas situadas a kildmetros de distancia. Mientras que el email supone un gran avance en los canales de comunicacién, también contiene algunas carencias {que le restan efectividad y es causa de problemas para los usuarios. La mayoria de ellas estén referidas a temas de seguridad: ~ Confidencialidad: Normalmente todos los mensajes se transmiten sin ningtin tipo de encriptacién. Internet es tuna ted abierta que permite a cualquiera con suficientes conocimientos, interceptar un mensaje y leerlo sin que lo sepa el remitente. ~ SPAM: una de las mayores quejas de los usuarios del email, es la recepcién de mensajes no solicitados. Muchos estudios realizados, indican que hasta el 90% de los mensajes enviados durante el tiltimo afio son SPAM, (Wer bibliografia: Study: 90-95% of all email sent in 2007 was SPAM) - Gestién de contactos: = Normalmente los usuarios de tipo empresarial, tienen muchos contactos en sus libretas de direcciones, ~ Para enviar un mensaje, es necesario conocer la direccién de email en Internet (user@domain.xxx). ~ Es dificil mantener una lista de contactes unificada y actualizada, acorde con las necesidades empresariales. Todo esto, es lo que muchas veces dificult la seleccién correcta de una direccién de email, ~ Gestion de mensajes: los mensajes de email, normalmente se reciben a través del protocol POP3, con este protocolo los mensajes se descargan en la bandeja de entrada local de los usuarios, Esto a veces es un problema Grave: si los usuarios tienen mas de un ordenador, como PC y un portatil, la bandeja de entrada queda dividia entre ambos ordenadores. Otro problema es cuando ocurre un desastre con el ordenador, donde los mensajes al estar almacenados localmente, se pueden perder. Existe otro protocolo como JMAP que resuelve algunos de estos problemas, pero no lleva de base las herramientas para encriptar mensajes y filtro de SPAM, ‘Ademés existen soluciones propietarias tales como Microsoft Exchange 2003 y Lotus Notes que si solucionan la mayoria de estos problemas, pero tienen en contra que son propietarias, se basan en licencias de uso restrictivas y ‘con un coste de implementacién bastante elevado, Hay algunos usuarios méviles que apuestan por soluciones de correo como Blackberry Realmail, pero esto es una Solucién especializada para las PDAs y Smartphones pero no estan pensadas para ser usadas en ordenadores de sobremesa, Lo que los usuarios demandan realmente, es un buz6n con todos los mensajes accesibles en cualquier momento y con herramientas répidas y giles que faciiten la gestién.Note (email 2.0). 2. sQué es Note (email 2.0)? Note (email 2.0) intenta solucionar todos estos problemas, mientras intenta mantener la experiencia de usuario de los clientes de email estandares. Para conseguir este objetivo principal, por un lado Note (email 2.0) cambia la estructura interna del sistema de envio de mensajes: ~ Cada usuario es un contacto en el servidor y es autenticado para acceder en el sistema, ~ Cada servidor tiene su base de usuarios (libreta de direcciones). = Las comunicaciones entre servidores son autorizadas: un contacto no puede enviar un mensaje a otro contacto en otro servidor mientras ambos servidores no se hayan autorizado mutuamente. = Todos los mensajes son encriptados usando una clave generada aleatoriamente para cada sesin, = Cada servidor mantiene su libreta de direcciones y la comparte con los demas servidores autorizados, manteniendo una gran libreta de direcciones auto gestionada. Ademés los usuarios envian mensajes a Personas por su nombre real y no necesitan conocer codificaciones especiales (como las direcciones de ‘email esténdar). Por otro lado Note (email 2.0) intenta mantener el modelo de usuario de un email esténdar, pero aplicando algunos pequefios cambios para mejorar ese modelo: = Cuando se envia un mensaje, se puede consultar que contactos han leido ya el mensaje de una forma dara y organizada. ~ Note (email 2,0) gestiona esta informacién de forma nativa, en lugar del sistema actual de los emails Donde hay que pedir solicitud de confirmacién de lectura, los clientes de correo no siempre la llevan Implementada y al no haber un esténdar definido, cada mensaje de confirmacién puede tener un formato diferente dependiendo del servidor de correo, lo que dificulta su gestién. = El_comportamiento del comando “Responder” y “Responder a todos” se ha modificado: parece que la mayoria de usuarios no saben usar de forma correcta estas dos opciones donde no queda dara su funcién especifica, confundiéndoles. Asi que pensando en el perfil organizativo empresarial, donde cuando se envia un correo a un cliente, por ejemplo, también se copia al coordinador, etc. Se ha optado por la siguiente solucién: estos dos comandos quedan unificados bajo una Gnica opcién “Responder” y con la funcionalidad de “Responder a todos” exceptuando el incluir al contacto que est escribiendo el correo ya que normalmente no es deseable su auto inclusién. Notese que siempre es posible modificar la lista de los contactos y afiadir otros distintos si es deseable. Pagina 6 de 612.1. Casos de uso Local Delivery Note (email 2.0) puede ser implementado como servidor de correo local tal como Lotus Notes, Microsoft Exchange, etc. Mediante este sistema todos los mensajes son guardados en el servidor y es el usuario que se conecta al servidor para leer el mensaje, de manera que se mejora tanto la seguridad como la Usabilidad ya que los mensajes no quedan desperdigados en buzones dentro de los PCs cliente y el servidor puede actuar como "caja negra”,Remote Delivery ea Sot. es En Note (email 2.0) los mensajes no circulan libremente por Internet de un servidor a otro hasta que llegan al servidor destino, la comunicacién es a través de P2P (Peer-to-Peer) entre el servidor que los envia y el servidor que los recibe. Los mensajes se transmiten directamente al servidor destino encriptados. Ademés, para que ambos servidores se puedan comunicar, el servidor destino debe autorizar al servidor origen, Si esto no se lleva ‘a cabo, los mensajes se descartan. EI modelo es e! mismo que en el correo local: ambos servidores actiian como una caja negra creando ‘conexiones seguras, de manera que los mensajes se pueden transmitir por un medio hostil como es Internet.Global delivery Ssmarhone Note (email 2.0) implementa el cliente de correo como una aplicacién Web mail basada en esténdares del WSC. De esta manera es posible acceder a los mensajes desde varios dispositivos heterogéneos tales como POAs, Smartphones, PCs portatiles y virtualmente desde cualquier dispositive con un navegador Web con soporte para XHTML, Java Script y CSS, Esto permite a un usuario acceder a sus mensajes desde cualquier lugar y en cualquier momento, de ‘manera que los mensajes estén siempre accesibles. tra ventaja es que la interfaz de usuario siempre es la misma, ya que no hay aplicaciones especiales en funcién del dispositive donde vaya a ser usado, de manera que, el modelo de usuario siempre se ‘mantiene evitando cualquier tipo de curva de aprendizaje.‘Note (email 2.0) Abert Giméner Quesada 3. Componentes de Note (email 2.0) Servidor Note (email 2.0): ~ Servidor de Base de datos (MS SQL Server 2005). - Servidor Web (MS Internet Information Services, 11S). Aplicacién Note (email 2.0): ~ Capa de negocio: clases internas que componen el software, como por ejemplo la representacién de Mensaje, Servidor, Contacto, Ticket, etc. - Aplicacién web para enviar/recibir mensajes Note (email 2.0) (un Web mail). ~ Gestién interna (backend) de Note (email 2.0), que permite agregar nuevos servidores externo, asi ‘como contactos y usuarios al sistema. Ademés permite configurar los aspectos mas bésicos’ del servidor local por parte del administrador. 4. Conocimientos aplicados para Note (email 2.0) : Instalacién y configuracién del servidor principal: SO. : Instalacién y configuracién del servidor Web: ASO y PXCSO. - Instalacién y configuracién del servidor de bases de datos: BD. - Analisis y programacién: ES1 y PS, - Enfoque comercial y empresarial: E3 y VPE. - Conocimientos de redes y servidores de correo: XCA, Pagina 10Note (email 2.0) 5. Note (email 2.0 : especificacion técnica En los apartados anteriores, ya se ha comentado los requisites que se pretende solucionar con este software. ‘A continuacién se exponen qué estructuras de datos y componentes internos son necesarios para cumplir los requisitos y cual es su funcionamiento interno y su interrelacién de forma concisa. 5.1. 5.1 51. Usuarios (Contactos) Al Introduccion ‘Los usuarios son una de las piezas fundamentales de Note (email 2.0); en este documento también son referidos como Contactos (Contacts). Cada usuario de Note (email 2.0) es tratado como un Contacto y tiene la capacidad de recibir y enviar mensajes de/a otros contactos. Cada usuario tiene una clave nica Contact 1D que lo identifica. De esta manera, en lugar de direcciones globales de email, cada usuario tiene un cédigo que lo identifica de manera global dentro del ecosistema, difcultando la falsficacién ya que ademas es tratada de forma interna al contrario que las direcciones de correo estindares. Cada usuario tiene su informacién de contacto y su configuracién de usuario contenidas, pero s6lo se transmite los datos de contacto al resto de servidores Note (email 2.0). Informacién de contacto: = Contact Id ~ Servidor = Nombre = Departamento + Idioma Informacién de usuario: ~ Login usuario ~ Contrasefia + Privilegios ~ Resto de campos de configuracién 2. Autenticacién de usuarios Los contactos de tipo interno, se referirdn como Usuarios. Cada usuario tiene que estar autenticado para enviar/recibir mensajes. Esta autenticacién esta basada en una cuenta de usuario y una contrasefia, La contrasefia se encripta usando el algoritmo de hashing SHAL. Esta eleccién esté basada en que los algoritmos de hashing son mucho mas dificles de romper que los algoritmos de cifrado y porque SHAL es mas seguro que otros protocolos oficiales de NSA como el MDS. Una vez la autenticacién es validada se crea una zona especial de memoria asegurada con la informacién de cuenta (a excepcién de su contrasefia) y sus privilegios que le permitiran acceder a los recursos del servidor local, como por ejemplo su buzon de mensajes. Pagina 11 de 61Note email 2.0) 5.1.3. Roles y permisos ‘Cada usuario tiene un rol en el sistema. Estos son los roles disponibles: ~ Externo (External_Contact): un invitado externo indica que es un usuario que proviene de un servidor externa. No puede hacer Login (acceder) y no puede tener buzén local. Ademés, no tiene referencias de usuario. ~ Usuario (User): un usuario esténdar puede enviar y recibir mensajes de otros contactos, puede modificar sus preferencias de usuario y gestionar su propio buzén. - Administrador (Administrator): tiene las mismas funcionalidades que e! usuario esténdar, ademas de estas adicionales: ~ Puede gestionar la conexién con otros servidores Note (email 2.0) externos y aceptar/declinar las peticiones de colaboracién de otros servidores, = Puede gestionar los usuarios de! propio servidor. ‘Ademés de los roles, un usuario puede ser: = Piiblico (Public): un usuario ptibico puede enviar/recibir mensajes de otros contactos tanto internos como externas situados en otros servidores. ~ Privado (Private): un usuario privado puede enviar/recibir mensajes sélo de contactos situados dentro del mismo servidor. No puede enviar ni tan solo ver contactos situados en servidores externas, 5.1.4. @Por qué no usar la direccién email estandar como Contact ID? Como ya se ha comentado, cada usuario debe tener un cédigo Unico que lo identifica en el servidor. Aunque este cédigo podria ser la direccién de email estandar, ya que cumple los requisitos, esto obligaria a transmitir esa direccién de email al resto de servidores colaboradores enlazados. Este hecho puede suponer un problema de seguridad ya que alguien no autorizado en otro servidor podria ver ese email y usarlo como SPAM, Para evitarlo se crea un cédigo alfanumérico como Contact 1D que es lo que se transmite al resto de servidores, manteniendo la direccién de email estandar a salvo sélo en el servidor de origen de! contacto. Pagina 12 de 61Note (email 2.0) fo OZ. 5.2. a2. Servidores 1. Introduccion Los usuarios de tipo empresarial, necesitan una libreta de direcciones unificada con sus colaboradores. Para realizar algo as{ normalmente se suele guardar esta libreta en un servidor global Para que sea facilmente accesible. Este hecho choca de frente con otro requisito de este tipo de Usuarios, y es la disponibilidad y fiabilidad del sistema ante caidas imprevistas, ya que si el servidor Que almacena la libreta pierde la conexién 0 falla, dejaré de estar disponible para todos los usuarios. El disefio de Note (email 2,0) tiene en cuenta este factor y en lugar de crear un servidor global con todos los contactos, cada servidor Note (email 2.0) tiene su libreta particular de contactos y luego es compartida por el resto de servidores en el sistema, De esta manera cuando un servidor cae, el resto pueden continuar enviando y recibiendo mensajes sin problemas. Esta manera de trabajar es muy similar a las redes P2P (Peer to Peer, o redes entre pares). En este documento al servidor que inicia la comunicacién se le referiré como servidor local (local Server) y al servidor que contesta como servidor remoto (remote server). Cada servidor tiene una clave tinica que lo identifica dentro del ecosistema: Server ID. Cada servidor tiene una clave especial o contrasefia llamada clave de desafio (challenge code). Esta clave es usada para encriptaciones intermedias, como cuando se envia las Server IDs\ocal y remota para autorizar la comunicaci 2. Server IDs y claves de desafio (challenge codes) Para que los servidores se comuniquen y autoricen la comunicacién, es necesario un sistema que identifique cada servidor de forma Unica en el Conjunto del sistema. También tiene que haber una manera que se pueda transmitir esta informacién sensible, de una manera ‘segura en un medio hostil como es Internet, En Note (email 2.0) para que un servidor local sea autorizado por un servidor remoto, envia su Propia Server ID local y la Server ID del servidor remoto. Luego el servidor remoto Comprueba esta informacién con la IP de origen del servidor local y si es correcta, entonces e! servidor local obtiene la autorizacién para operar. Las Server 10s son una informacién muy sensible y es necesario enviarlas varias veces al hacer llamadas a funciones en el servidor remoto. Es necesario encontrar una manera de asegurar esta informacién, la manera de hacerlo es encriptando las Server IDs usando una clave de desafio (challenge code) para conformar una cadena de texto que contiene ambas Server IDs la local y la remota ademas de una marca de fecha/hora. Esta nueva clave compuesta, es referida como desafio (challenge), y es lo que se transfiere en la comunicacién, Obsérvese la diferencia entre el desafio (challenge) que viene a ser como un baiil cerrado y la clave de desafio (challenge code) que se podria entender como la llave del bat. Para que una clave de desafio sea efectiva, se deberia enviar sélo una vez, para que la probabilidad {que sea capturada y leida por una tercera persona sea muy baja. De esta manera, se transfiere sélo la primera vez que ambos servidores aceptan la peticién de colaboracién, de esta manera ambos pares saben que clave usar para encriptar sin necesidad de en posteriores comunicaciones reenviar la clave. Generar dos desafios para las mismas Server IDs, debe producir resultados distintos, ya que si no ‘seria muy poco seguro. Con este propésito se ha incluido la marca de fecha/hora a la férmula de generacién del desafio. Pagina 13 de 61Note (email 2.0) Albert Giménge Quesada 5.2.3. Conexion con servidores remotos: peticiones de colaboracion Para que los contactos de un servidor puedan recibir/enviar mensajes de contactos situados en otro servidor, un usuario administrador debe enviar una peticién de colaboracién (collaboration request) al otro servidor. 1 administrador del otro servidor es informado de la nueva peticién, y debe decidir entre aceptarla 0 no. Si se acepta, ambos servidores intercambian sus cédigos de desafio (challenge codes) y sus Server IDs. ‘A continuacién el diagrama de bloques que explica el proceso: | Contact remote server Call emote function: Collaboration Request < Request accptes? >No pe, Sere! dengaton eat | < a a — Yes Send remote server Challenge Code and ‘Server ID to local server L__ vy Pagina 14 de 61Note (email 2.0) Abert Giménez 0 5.24, Trabajando con servidores remotos Cuando ambos servidores se han autorizado reciprocamente (ver peticiones de colaboracién). Deben intercambiar sus contactos, de manera que se puedan enviar mensajes. Justo después de aceptar la peticién, el servidor local pide al remoto su lista de usuarios propios no heredados de otro servidor y que tiene marcado su perfil como piiblico. Una vez transferidos, es el servidor remoto el que hace lo propio con los contactos del servidor local, de esta ‘manera ambos quedan sincronizados en sus contactos puiblicos. Obsérvese que si hay un error en la transferencia de un contacto, éste es descartado y el proceso continia para el resto de contactos. Sin embargo, en una futura sincronizacién puede ser recuperado sin mayor complicacién, Completado este proceso, los contactos de ambos servidores ya pueden reconocerse ¢ intercambiar mensajes. El diagrama de bloques del proceso es el siguiente: [ cen magnet |__gegetsec) >} t ese Pagina 15 de 615.3. Mensajes 5.3.1. Introduccién Los mensajes son la pieza fundamental de Note (email 2.0). El tratamiento que reciben los mensajes, ‘se intenta que sea el mas parecido posible al del email estdndar, de manera que se minimice la curva de aprendizaje del usuatio. De esta forma, la mayor parte de los conceptos de! email esténdar como: mensaje, De, Para, CC, CCO, etc. Se mantienen intactos en Note (email 2.0). asunto, cuerpo de La Unica liferencia apreciable, entre el email esténdar y los mensajes de Note (email 2.0) es la forma ‘en que internamente son gestionados, ya que en Note (email 2.0), los mensajes se envian de forma nativa encriptados usando el sistema de tickets (ticket system). De esta forma, no hay necesidad de usar protocolos externos para asegurar la comunicacién como SSL y entidades certificadoras, aunque pueden ser integradas sin problemas para mejorar atin mas la seguridad, ya que toda la transferencia de datos se realiza mediante protocolo HTTP. 5.3.2. Archivos adjuntos Los mensajes de Note (email 2.0) pueden contener archivos adjuntos de la misma forma que los mensajes de email estandares. Sin embargo, en esta versién inicial, el contenido de los archivos adjuntos no es encriptado durante la transferencia, Los archivos adjuntos se guardan en el servidor en la base de datos, de esta forma se faciita el control de acceso al contenido del archivo por parte de personas no autorizadas, ya que al no estar fisicamente en el servidor como archivo, sino que al ser un campo més en la base de datos, se facta la gestién de la seguridad, en tanto en cuanto, se rige por los mismos procesos que el resto de la base de datos y no es necesario un mantenimiento especial. Una desventaja severa de almacenar los adjuntos asf, es que hardn crecer mucho el tamafio de la base de datos, incrementando los tiempos de acceso y consulta. Para evitarlo, se debe usar las herramientas de gestién de la base de datos para particonarla de la manera correcta, creando un archivo separado para estos datos: awe Io Ye et oad Sag DOBBS, Sete ee gay en tn aNote (email 2.0) 5.3.3. Confirmaciones de lectura En el email esténdar, para las confirmaciones de lectura, es necesario solictarlas cuando se envia el correo y se reciben en forma de otro mensaje de correo generado automaticamente por el servidor de destino. Con este método se complica la gestién de quién ha leido el mensaje y quién no, ya que teste mensaje no sigue un patrén estdndar, puede que el servidor destino tenga deshabilitada esta funcién y los mensajes de confirmacién se pueden desperdigar 0 perder. En Note (email 2.0) las confirmaciones de lectura tienen una entidad propia, de manera que pueden ser gestionadas de forma esténdar: cuando un contacto abre un mensaje, se envia una notificacion al servidor de origen automiaticamente. Este aviso es gestionado desde el propio servidor y enlazado con el mensaje original, As{ que el usuario en todo momento puede hacer un seguimiento casi en tiempo real de qué contactos han abierto su mensaje con la fecha/hora y en un futuro podria ser estudiado comprobar que accién han tomado con el mensaje, en caso que se cumplan ciertos requisitos que no impliquen una intrusién demasiado elevada en la privacidad. Este es el diagrama de bloques del proceso: ‘Contact remote server | | (Call emote function Read. Notification Send Challenge, 10 original message, ‘Sender Contact D, Delivery Contact ‘Sond denegation to local Pagina 17 de 61‘Note (email 2.0) Abert Giménez Que 5.3.4. Envio de mensajes La forma de envio de los mensajes es una de la grandes diferencias entre el email estandar y Note eral 2.0). g ‘el email estdndar, un mensaje suele viajar libremente por Internet hasta el otro servidor de correo, 0 bien, éste lo remite (relay) a otro servidor y asi sucesivamente hasta llegar al servidor destino. No hay ningiin tipo de comprobacién en el proceso sobre qué servidores intervienen en el proceso ni dels contactos que contiene el mensaje. En Note (email 2.0), enviar un mensaje implica sdlo a dos servidores: el que envia el mensaje y el que lo recibe. Ademds, para que se comuniquen dos servidores, deben ser autorizados. Este proceso implica que cada servidor reconace al otro como permitid para poder enviar/recibir mensajes. También, cada mensaje que se envia, se encripta de forma interna usando una clave aleatoria llamada ticket. De manera que cada vez que dos servidores intercambian mensajes, la contrasefia usada para encriptar los mensajes es distinta. Un detalle importante a remarcar: cuando se envia un mensaje a varios contactos, estos al recibir el mensaje y responder a todos, puede que haya algunos contactos de la respuesta, que no ‘estén autorizados por los otros servidores, de manera que no podran recibir la respuesta. Para mitigar esta situacién, se avisaré al usuario cuando puede suceder algo asi para que sepa qué Contactos no recibirdn la respuesta, 5.3.4.1. Autorizacién de servidores Ningiin mensaje puede ser enviado entre servidores hasta que ambos servidores se han autorizado. El funcionamiento de la autorizacién, es el siguiente: cada servidor, tiene su propia Server JD que le identifica de forma tnica dentro del ; ecosistema. Para autorizar al servidor emisor, éste remite ambas Server IDs al servidor receptor: la suya propia y la del servidor receptor. Como ya se ha comentado en el apdo. Server !Ds y claves de desafio, para enviar esta informacién se encapsula en una cadena de caracteres (string) junto con la marca de fecha/hora y se encripta usando la clave de desafio, de manera que se | -x forma el desafio, que es lo que se envia para | ““ssatinem autenticar en el proceso. Nétese que para validar el proceso, entra en juego la seguridad en la transmisién de la clave de desafio (challenge code) inicial y la dificultad en falsificar direcciones IP de forma externa (no estando situado en una red local con un proxy.) Sinsation Luego el servidor que recibe el mensaje, ves ‘comprueba toda esta informacién con la direccién, IP del servidor emisor. Si este proceso es correct, -—— se genera un nuevo ticket para encriptar los mensajes en la sesién de envio entre ambos |S!" servidores. Ala derecha se puede observar el diagrama de bloques: Pagina 18 de 61Note (email 2.0) _ Albert Giménez Quesada 5.3.4.2. Tickets y encriptacién de los mensajes Cada vez que una nueva sesién empieza entre dos servidores, se genera una nueva clave para tencriptar todos los mensajes. Esta clave se denomina ticket. Esta clave esta compuesta por caracteres alfanuméricos: [2-2], [A-Z], [0-9] Los tickets, mejoran la seguridad en la transmisién de mensajes y hace que las conexiones entre servidores, actien como “cajas negras": = Usa claves alfanuméricas y de longitud adecuada para asegurar una buena cencriptacién. - Usa claves aleatorias, que es casi imposible que sean reutilizadas. Esto hace que romper la encriptacién de los mensajes sea una tarea harto dificil, pero ademas, asegura que en caso que cocurriera, sélo una minima parte del sistema se veria afectado ya que esa clave se descarta al finalizar la sesién de envio. - Cada sesién de envio tiene su clave propia, lo que hace que en caso de intrusién séio afectaria a la sesion concreta sin interferir en el resto, que usan claves distintas. Para entenderlo mejor, aqui esté el diagrama de bloques: [eee | extn Encrypt the message using the Ticket Call remote function | nvr Message - ¥ | send chatange (see Sener auoraten) ° [nen Rotun code“ nonce | 1 a tena On : a ~N ‘Send Enerypted Mot <—p-——scmuaaantatonmant—P) lun code = em el | Pagina 19 de 61 Return code 0Note (email 2.0) 2 Avert Giménea Qu 5.3.5. iComo se evita el SPAM? Uno de los pilares de este software, es evitar el SPAM, Para conseguirlo, Note (email 2.0) se basa en lo siguiente: = Un usuario (contacto) se puede obligar a que sélo pueda acceder al sistema desde ciertas direcciones IP autorizadas. = Un contacto puede estar bloqueado en un servidor de manera que todos los mensajes que envie serén rechazados. = Un contacto se comprueba con su Contact ID la Server ID del servidor donde procede = Un servidor puede estar bloqueado, rechazando todos los mensajes que procedan de él. = No se envia la direccién de email estandar al resto de servidores, permanece en el servidor de igen (minimizacién de fuga de email). 5.3.6. @Por qué usar un servicio Web (Web Service) para enviar mensajes a otros servidores remotos? Enviar un mensaje en local implica una transaccién con la base de datos para la entrega del mensaje. Pero para la entrega del mensaje a un destinatario situado en un servidor remoto, implica realizar toda una serie acciones adicionales para afianzar la seguridad y poder hacer la entrega del mensaje. ‘Todas estas accones y comprobacones, se deben realizar mediante llamadas a procedimientos y funciones situadas en el servidor remoto (RPC o Remote Procedure Call). Es necesario un marco que permita realizar estas llamadas a procedimientos remotos y se encargue de los aspectos de mas bajo nivel. Existen algunos estindares al respecto, pero se han valorado sobretodo 3: CORBA, DCOM y Web Services, Para este tipo de desarrollo se ha descartado CORBA y DCOM ya que estas soluciones dependen del fabricante (producto ORB en el caso de CORBA y Windows en caso de DCOM). Ademas el programador se ha de encargar de la gestién y composicién de mensajes. Y por tikimo, estén basados en la transmisién binaria y se muestran débiles para las comunicaciones sobre varios servidores que estén repartidos por Internet. Web Services por otro lado usa esténdares de Internet como HTTP, XML, SOAP, WSDL, etc. estd especialmente capacitado para el tipo de comunicaciones que se realizan en Note (email 2.0) ‘que estan basadas exclusivamente en servidores repartidos por Internet. ‘Ademés al usar HTTP para enviar el mensaje, se puede implementar sin demasiado esfuerzo también sobre HTTPS (SSL HTTP) afianzando atin mas la seguridad. tra ventaja que tienen sobre las otras opciones es la interoperabilidad y es que gracias a los esfuerzos que se estén realizando SOAP es cada vez mas interoperable entre varias plataformas de desarrollo con lo que se faciita las comunicaciones con otros tipos de servidor si fuera necesario en un futuro. Por tiltimo se usa comunicaciones a través del servidor Web (80) con lo cual no es necesario establecer reglas especiales ni es necesario readaptar Firewalls para aceptar la comunicacién entre servidores Note (email 2.0). Si se observa los diagramas de bloques, éstas son las operaciones disponibles para llamar de forma remota: = Collaboration. Request: envia una peticién de colaboracién. = Get_Contact_List: obtiene la lista de contactos piiblicos del servidor. ~ Get Authorization: obtiene un ticket para poder enviar un mensaje. - End. Authorization: finaliza una sesién de envio (es llamada autométicamente por Deliver Message, ‘aunque se permite la llamada manual para notifcar la finalizacién de una sesi6n). ~ Deliver. Message. entrega un mensaje a un contacto en el servidor. - Send_ Read Notifcatior. envia una confirmacién de lectura para un mensaje y contacto. Pagina 20 de 61Note (email 2.0) 5.4. Carpetas 5.4.1. Introduccién Todos los mensajes que se envian se guardan en una estructura organizada y comiin, que facilita la corganizacién de los mensajes al usuario. Esta estructura esté formada por carpetas anidadas de la misma manera que el email estandar. Esta estructura de carpetas desde primer nivel, forma lo que se denomina buzén (mailbox). En Note (email 2.0), el buzén contiene la misma estructura que el email esténdar: bandeja de entrada (Inbox), bandeja de salida (outbox), enviados (send), borradores (drafts), papelera (deleted). Pero estas secciones son tratadas como si de carpetas se tratara, con la diferencia que su carpeta padre es vacia (nula) y tienen un tipo de carpeta especial en funcién del rol que juegan. Las carpetas esténdar sélo pueden anidarse dentro de otras carpetas estindar y de la bandeja de entrada como nivel superior. Hay un tipo carpeta virtual que se usa para un tipo especial de carpeta: las que contienen vistas sobre biisquedas de mensajes fisicos, del mismo modo que las carpetas virtuales de Windows Vista, © las listas inteligentes de /Tunes, Esta caracteristica permitira crear una biisqueda y guardarla como si fuera una carpeta mas, de manera que autométicamente al acceder refleje la biisqueda actualizada. En futuras versiones de Note (email 2.0) podré haber tanto email estandar como la mensajeria de Note (email 2.0), por eso se ha afiadido un campo extra a la carpeta que permite conocer si contiene ‘mensajes de email esténdar. No seré posible mezclar mensajes de email estandar y mensajes de Note (email 2,0). Y estas carpetas de email estandar, se marcaran para denotar su procedencia externa y quizé peligrosa. Tal ‘como hace Internet Explorer 7 cuando se accede a una pagina con un certficado no valido, donde la barra de direcciones se muestra con un fondo rojizo. Pagina 21 de 615.5. Estructura de datos detallada 5.5.1. Diagrama UML Abert Giménez Ou TeSoneSing Sever Sing |cnsterge Coss: Seng |Aseped“Gonean {Sonnac Fate! igor Remote Seven Pah Sra TPS Boole acon Sing Comat Nae Seng ‘Deparment Sing Jo—[:Permison Cerise Pemisson 1+ language: Sg : |socted Bolan {ast Ose add: Date ‘Contac toa fee Tatariac Reva. Sr@] Lag Sing [speared Sng ate Date Saba] —< fiteet Sg |spemisson Conse Pein [ested Bocaon [sera ocean {stra EmaBosiean Message Fie] [Ferns Sng tes Ob ow fiatoa= reaper ‘User Name Sing | eh conace' Sting Taare elder Strg ae [Delt Bootan y ates eae [soft cena bee rom, are: Sng wo Sg + fence" Sa : [since Nana: Sing fondo Nome Song Subject Sng Boo) Sting Dat, Sent Dae |te"Reas Dele [importa secean |Desergton: sine [eat Resse: Pagina 22 de 61 Cone Name Sng ato ate |i tt MesaNote (email 2.0) Abert Giménez Quesada 5.5.2. Descripcion y comentarios de la estructura de datos Atributos: ‘Server: contiene el nombre del servidor y que se mostrard al usuario. ‘IP: direccién IP del servidor, ya se ha preparado para aceptar IPv6. Challenge..Code: cidigo de desafio del servidor. ‘Accepted: cuando se acepte la peticion de colaboracién se marcaré como cierta, de otro modo no se ‘ocr conectar con ese servidor ni enviar mensajes a sus contactos. Connection_Failed: se usar para contar cuantas veces a fallado la conexién con el servidor, de esta manera se podra hacer estadisticas y tomar decisiones sobre qué accién tomar. (Se implementaré cen futuras versiones). Remote Service Path: contiene la ruta para acceder al Web Service remoto en el servidor. HTTPS: cuando es cierto, indica que se debe usar una conexién segura (https), de otro modo se usaré una normal (http). Operaciones: Exists: comprueba si el servidor actual existe en la base de datos. Insert: aftade un nuevo servidor en la base de datos. Update: actualiza los datos del servidor en la base de datos. ‘Delete: borra un servidor asi como todos sus usuarios, buzones y mensajes asociados (ver composicién en diagrama UML). Change ServerID: modifica el Server 1D. Change_.Chalege_Code: modifica el cédigo de desafio del servidor. ‘Change__Remote_Connection_Https: modifica el tipo de conexién si es http o https. Accept: acepta el servidor para poder contactar y recibir/enviar mensajes. ‘Reject: rechaza el servidor (lo bloquea), ya no se podra recibir/enviar ningin mensaje procedente de ese servidor. Load: carga la definicién desde la base de datos del servidor. Contact Clave primaria: 1dContact, Atributos: Un contacto externo (Contact_External) son los que provienen de servidores remotos y no tienen ‘cuenta local. Un contacto interno / Usuario (Contact_Internal) es un usuario con cuenta local y los Gnicos que pueden tener buzén de mensajes (carpetas, mensajes, etc.) en el servidor local Contact. Name: nombre completo del contacto, formato libre aunque se forzara Apellido1 Apellido2, Nombre. Department: departamento/seccién donde esta situado el contacto. Permission: permiso de usuario, 0 rol que tendra. Si es Externo (External_Contact) no podré ‘conectar al servidor que esta asignado, ni mantener preferencias. Language: es el cédigo ISO del idioma: EN-> Inglés, ES-> Espafiol, FR-> Francés, DE-> Aleman, etc. Blocked: cuando es cierto, indica que el contacto esta bloqueado y no se aceptan mensajes que procedan de él. Si es local (contacto interno) ademés no se le permitiré acceso al sistema. Last_Date_Modifed: contiene la fecha iiltima cuando el contacto se ha actualizado. Se usa para la transferencia de contactos al resto de servidores, para enviar sélo los contactos modificados en lugar del lstado completo. TdContact. Remote: contiene el ID del contacto en el servidor origen (remoto), esto es necesario para evitar errores si dos contactos en diferentes servidores recibieran el mismo Contact 1D. Pagina 23 de 61Note (email 2.0) Login: nombre de usuario para acceder al sistema. Password: contrasefia del usuario para acceder al sistema, {IP_ Accepted: se usa por razones de seguridad para hacer que un usuario sélo pueda conectar desde Clertas IPs definidas. ‘Mag_Page: es el niimero de mensajes mostrados por pagina. Js Public: cuando es cierto, el contacto puede recibir mensajes de servidores externs. Si no, sélo puede recibir mensajes del propio servidor. External Email: cuando es cierto, el contacto tendré también una cuenta de email estandar (se implementard en futuras versiones). Todos los campos Emai_XXX estén relacionados con esta opcién, Operaciones: Exists: comprueba si el contacto actual existe en la base de datos. Insert: fiade un contacto servidor en la base de datos. Update: actualiza los datos del contacto en la base de datos. Delete: borra el contacto asi como todos sus buzones y mensajes asociados (ver composicién en diagrama UML). Block: bloquea un contacto. Unblock: desbloquea un contacto, Load: carga la definicién desde la base de datos del contacto. ‘Sdlo en Contact Internal ‘Change_ Permission: cambia el tipo de usuario, administrador/usuario. Change_Public_ Status: cambia el estado de contacto piblico o privado. Folder: Clave primaria: IdFolder ‘Atributos: Folder: es el nombre de la carpeta. Type: es el tipo de carpeta: esténdar o alguno de los especiales. Jeon: es el archivo de icono usado para representar la carpeta, se asigna autométicamente. ‘Deleted: cuando es cierto, indica que la carpeta esté en la papelera. Operaciones: Greate_Child_ Folder: crea una subcarpeta (estandar) dentro de la actual. Change_.Name: cambia el nombre de la carpeta. Trash_Delete: establece como Deleted (en la papelera) la carpeta Trash_ Restore: establece como Not Deleted (restaurada) la carpeta. ‘Move_To_Folder: mueve la carpeta como hija de otra carpeta. Delete: borra la carpeta asi como todos sus mensajes contenidos (ver composicién en diagrama UML). Load carga la definicién desde la base de datos de la carpeta. Pagina 24 de 61Note (email 2.0) Message: Clave primaria: 1dMessage Atributos: Hay dos tipos de mensaje: Note (email 2.0) y Email, estos titimos tienen una propiedad Email_Headers con las cabeceras y informacién del servidor de email estandar. JdMessage_Remote: se usa con Message_Status para mantener la informacién de confitmaciones de lectura del mensaje. Contiene la ID del mensaje original en el servidor remitente. conXXX: contienen la lista de JdContact divididos por *;" (en el caso de email estandar contendra las direcciones de email) conXXX_Name: contienen la lista de ContactName dividido por ";". Como se puede ver, se guarda los nombre originales con el mensaje, esto tiene dos objetivos: por Un lado agilizar fa consulta de un mensaje, la otra, no depender de datos externos para mostrar el mensaje, ya que si sélo se guarda el 1D obligaria a mantener siempre todos los contacts ya no vvlidos para poder consultar mensajes antiguos. Subject: asunto del mensaje. Body: cuerpo del mensaje, Date_Sent: fecha del envio, Date_Read es la fecha que el usuario local ha abierto el mensaje. Important: indicador de mensaje urgente. Deleted: cuando es cierto, indica que el mensaje esté en la papelera, Operaciones: ‘Adid_Contact_xx:afiade un contacto en el campo destinatario para (To), CC, © CCO (BCC). Remove.Contact_,0%: quita el contacto del campo destinatario para (To), CC, 0 CCO (BCC). Save_To_Drafts: quarda el mensaje en la carpeta de borradores del usuario que envia, Trash_Delete: establece como Deleted (en la papelera) el mensaje. Trash_Restore: establece como Not Deleted (restaurada) el mensaje. Delete: borra el mensaje asi como todos sus adjuntos y notificaciones de lectura (ver composicién en diagrama UML). Move. To. Folder: mueve el mensaje a la carpeta indiiada, ‘Send: envia el mensaje, Load: carga la defiicién desde la base de datos del mensaje. Sdlo.en Message Note: ‘Send_internaf: envia el mensaje a un contacto interno, ‘Send_External: envia el mensaje a un contacto externo. Send_Notification_NonDelivery: envia un mensaje al remitente notificando que no se ha podido ‘enviar su mensaje a uno o mas destinatarios, Message File; Clave primari IdMessage, Filename Atributos: Contiene los adjuntos del mensaje. Como se puede observar por la restriccién de clave, no se puede repetir un adjunto més de una vez en un mensaje. El tamajio maximo de archivo soportado es varbinary (MAX) > 2431-1 bytes de longitud, que Corresponde aproximadamente a 2GB de tamafio maximo de archivo, Filename: es el nombre del archivo. Contents: es el contenido binario del archivo. Operaciones: ‘Save: quarda los archivos en la base de datos. Delete: elimina uno o mas archivos adjuntos. Pagina 25 de 61Note (email 2.0) US: Clave primaria: IdMessage, IdContact Atributos: Contiene el estado de un mensaje enviado, cuando un destinatario abre el mensaje se envia la notficacién al servidor remitente que lo guarda en esta clase. De esta forma se puede saber quién ha abierto el mensaje y quién no atin Date: contiene la fecha en que el usuario remoto ha abierto el mensaje. ‘Status: contiene el estado del mensaje para el contacto, Operaciones: Load: carga la definicin desde la base de datos del estado del mensaje, Insert: afade estado lectura del mensaje en la base de datos. (Change_Status: cambia el estado de lectura del mensaje. Delete: borra el estado de lectura del mensaje. Ticket: Clave primaria: IdServer, IdContact, Date_Start Atributos: TaTicket: contiene la dave usada para encriptar el mensaje, tiene una restriccién para que sea Unica. IP: contiene la direcclén 1P del servidor que ha solictado el ticket, se usa para la validacié ‘Date_End: es la fecha/hora que caduca el ticket. Hay un proceso que limpia automaticamente y cada cierto tiempo, los tickets que ya no son validos. Operaciones: Exists_Ticket: comprueba si hay un ticket vilido para el usuario y contactos especificados, Create Ticket: crea un nuevo ticket Delete_ Ticket: da de baja (elimina) el ticket. ‘Load. Ticket: carga y entrega un ticket para el contacto y servidor indicados. Log: Clave primari Idlog Atributos: Se usa para registrar los eventos y acciones que ocurren. UserName: sera el Contact Name 0 un texto que identifique al usuario que ha provocado el evento. Action: es el tipo de evento que ha ocurrido, Date: es la fecha en que ha ocurrido el evento. Description: es la descripcién del evento ocurrido. Operaciones (contenidas en la libreria Support_Functions): White_Log: escribe un evento en el registro (Jog). Pagina 26 de 61Note (email 2.0) This Server: Clave primaria: ‘Atributos: CContiene la informacién para el servidor actual, no se incluye como servidor (Server) porque el trato 5 un tanto distinto al resto y ademas la informacién contenida es més sensible y por tanto mayor necesitada de seguridad que en el resto de servidores. Server_ID:1d servidor local, ‘ServerName: nombre del servidor local. Server_1P:1P del servdor local. Server. Challenge_Code: cBdigo de desafio del servidor local Operaciones: Generate New_Challenge_Code: crea un nuevo cédigo de desafio. Generate_New_Server_Id: crea una nueva server 1D. ‘Send Collaboration Request: enwia una nueva peticién de colaboracién a un servidor remoto. *Challenge: Clave primaria: - Atributos: - Operaciones: Este médulo no aparece en el diagrama pues no contiene propiedades, sélo operaciones: Generate_Challenge: genera un nuevo desafio. (Check_Chailenge: comprueba si un desafio es valido. Get_Remote_ServerID: cbtiene el Server ID del servidor remoto. Pagina 27 de 61Note (email 2.0) 5.6. | Modelo arquitectonico y de implementacién 5.6.1. Disefio arquitecténico La parte mas importante para este proyecto, es el modelo usado para recibir/enviar mensajes, por tanto, la capa de negocio. Uno de los objetivos planteados, es que este modelo no deberia estar ligado a ninguna interfaz de usuario concreta, de manera que se pueda enlazar con cualquier otra IU © redisefiada y personalizarla para usos concretos. De esta forma se gana una gran flexibilidad. Para cumplir este propésito, se ha escogido un disefio en 3 capas: capa de datos, capa de negocio y capa de presentacién, Pero con algunas particularidades: para simplificar el acceso a datos y algunas tareas repetitivas y pesadas, se ha desarrollado un conjunto de librerias = Support_Database: contiene todos los procedimientos para acceso a datos y manipulacién de la base de datos, tiene las siguientes funciones: ~ Open_Database: conecta con la base de datos. - Close_Database: ciesra la conexién con la base de datos, ~ Query_ Value: consulta un valor escalar, dada una condicén. ~ Query_ Table: consulta un conjunto de datos de una tabla. ~ Query_SQL: consulta un conjunto de datos, dada una sentencia de SQL. ~ Execute_SQL; ejecuta una sentencia de SQL (INSERT, UPDATE, DELETE, etc.) - Next_ID; devuelve la siguiente ID numérica, usada para afiadir nuevos datos, ~ Exists_Record: devuelve cierto, cuando existe uno 0 més registros que cumplan la condicién, = Boolean_integer: transforma desde valores booleanos de Visual Basic a valores booleanos para SQL: True => 1, False -> 0, ~ Dates_SQLToDate: transforma fechas SQL a fechas de VB. ~ Dates_DateToSQL.: transforma fechas de VB a fechas SQL. ~ Prepare_String: prepara un texto para ser insertado/actualizado en la BD. ~ Prepare_Number: prepara un niimero para ser insertado/actualizado en la BD. ~ Prepare_Date: prepara una fecha para ser insertada/actualizada en la BD. - Prepare_Boolean: prepara un booleano para ser Insertadoactualizado en la BD. ~ Prepare_Key: prepara una clave (primaria, externa) para ser insertada/actualizada en la BD. Pagina 28 de 61Note (email 2.0) Quesada = Support_Functions: contiene procedimientos y utlidades para facilitar las tareas de programacién: + Split: divide un texto dado un separador devolviendo un vector. A diferencia de la funcién esténdar soporta un separador de miltiples caracteres y recorta espacios sobrantes, ~ Find!_Item_Array: busca un elemento en un vector. + Find Position Array: encuentra la posicién de un elemento en un vector. ~ Send_Email: envia un email estindar. ~ White_Log: escribe un evento en el registro (/og). ~ MsqBox_Error: muestra un mensaje de error al usuario, ~ Read_XMl_Tag: lee el contenido de una etiqueta dada, dentro de un documento XML. ~ White_XH4L_ Tag: escribe el contenido de una etiqueta dada, dentro de un documento XML. = White_Config_XML_Tag: similar a Write_XML_Tag, pero especifica para los archivos .config de ASP.NET. ~ Remove_HTML. Tags: dado un texto HTML, devuelve el texto limpio de todas las etiquetas HTML. = Remove Accents: elimina los acentos, digresis, circunflejos, etc, Devolviendo caracteres ASCII planos. ~ Support_Security: contiene procedimientos para seguridad y encriptacién: - Encrypt.SHA1: encripta usando el algoritmo SHAL. ~ Enerypt_AES/Decrypt_AES: encripta/desencripta usando el algoritmo AES. ~ Encrypt_3DES/Decrypt_3DES: encripta/desencripta usando el algoritmo 3DES. - Generate_Unique_Key: Genera calves ‘inicas, usado para IdServer, IdContact, etc, ~ Encrypt_Path/Decrypt_Path: encripta/desencripta una ruta, usando una clave especial interna, ~ Localization: contiene procedimientos para manejar varios idiomas en la aplicacién: ~ Transiate: dada una constante, devuelve el texto que representa, traducido en un idioma indicado, Pagina 29 de 61Note (email 2.0) Ubert Giménez Quesada 5.6.2. Disefio de implementacion y herram. de desarrollo escogidas Note (email 2.0) es un software orientado para negocios. Asi que para desarrollario, es muy importante seleccionar una plataforma de desarrollo potente y robusta, con herramientas de desarrollo de reconocida reputacién, que sean comunes y ya conocidas en el entorno empresarial. De esta forma para base de datos, se consultaron las siguientes opciones: MySQL, PostgreSQL, Microsoft SQL Server 2005 y Oracle 109. Se ha escogido SQL Server 2005 por las siguientes razones: = Integracién perfecta con Visual Studio 2005, = Reconocida reputacién dentro del mundo de la informatica empresarial = Buenas herramientas de desarrollo y manejo. ~ _ Posibilidad de enlace con otras fuentes de datos externas (Servidores enlazados). ~ Posiblidad de tener clister de servidores activos (Replicas de servidores). ~ Posibilidad de escribir Procedimientos almacenados en lenguajes .NET ademas de T-SQL. = Capacidad de manejar grandes vollimenes de datos. = Reporting services incluido, opcién interesante para ser usada en un futuro. ~ _Analisys services para tareas de mineria de datos disponible y accesible desde Visual Studio 2008. = Versién Express gratuita y potencia més que suficiente para esta aplicacién. Durante el proceso de seleccién de lenguaje, se consultaron varias opciones (PHP, Ruby on Rails, PERL, etc.) y dos plataformas quedaron finalistas: Sun Java EE 1.6 y Microsoft .NET Framework 2.0. A final, se ha escogido .NET por las razones siguientes: = Buen conocimiento previo de ASP y ASP.NET. ~ NET Framework tiene unas herramientas de desarrollo un poco més potentes que Java, sobre todo para desarrollar servicios Web. = Libreria AJAX para .NET y los controles de AJAX Control Toolkit. ~ Visual Basic como lenguaje, para faciltar la tarea de programacié = Mejor integracién con la base de datos escogida, SQL Server 2005 y mejores controles de datos (gridview, datalist, etc.). ~ Se puede combinar varios lenguajes de la plataforma .NET para ampliar/mejorar el desarrollo: C#, Delphi.NET, J#, etc, + Obtencién de una licencia de Visual Studio 2005 mediante MSDNAA. Y buen conocimiento de este IDE, Para la capa de datos se usa: SQL Server 2005. Para la capa de negocio se usa: Visual Basic .NET. Para la capa de presentacién se usa: ASP.NET codificado mediante Visual Basic .NET y las extensiones y controles del AJAX Control Toolkit. El desarrollo del Web Service para permitir 1a comunicacién con servidores externos. Se programa mediante las herramientas estandares de .NET y Visual Basic .NET. Pagina 30 de 61Note (email 2.0) Abert Giménez Quesada 6. Note (email 2.0): especificacion funcional En este apartado se describe el funcionamiento de Note (email 2.0) desde la perspectiva del usuario: se concreta la interfaz de usuario (IU) que se ha disefiado y las caracteristicas y funcionalidades que tiene disponibles. 6.1. Introduccion ‘Note (email 2.0) intenta parecerse lo maximo posible a un cliente de email estandar. Para ello el disefio de la IU se ha basado en los clientes de correo estindares disponibles, tanto aplicaciones de escritorio como Web Mail: Thunderbird, GMail, Horde, Hotmail, Microsoft Exchange (Web) y Microsoft Outlook. Sobre todo se ha pensado en el disefio de Exchange/Outlook ya que es el cliente mas usado y conocido en la actualidad. Y contiene algunos detalles interesantes como por ejemplo: vista dividida en 3 paneles verticales en lugar del panel de carpetas y la vista partida horizontal con la lista de mensajes y el detalle del mensaje. La interfaz de usuario de Note (email 2.0) contendré las siguientes pantallas: = Acceso al sistema (Login) ~ Ventana principal con las carpetas, listado de mensajes y detalle del mensaje. = Edicién de mensajes. ~ Gestién de archivos adjuntos al mensaje. = Basqueda de contactos, = Biisqueda de mensajes. Para la gestién interna de Note (email 2.0), habré las siguientes pantallas: - Afadir/Quitar usuarios (contactos).. ~ Afjadir/Quitar servidores remotes y gestién de peticiones de colaboracién, + Configuracién de las preferencias de usuario. Pagina 31 de 616.2. IU del Web mail detallada 6.2.1. Autenticacion Esta es la primera pantalla que verd un usuario al acceder al sistema. Aqui podré introducir su usuario y contrasefia y se realizaré la validacin contra el servidor. Sies correcta la autenticacién se establecerd una sesién con un objeto especial que contendré los datos de ‘acceso: nombre de usuario, login y los permisos efectivos. La contrasefia jamas se deberia quardar en este objeto de sesién por motivos de seguridad. Wy uses - wos Freon E Archivo Editar Ver Historial Marcadores Hevramientas Ayuda € To) [L htipy/servidor/noteyindexasox 7b) I | Note IN E | User | Password: | OK Cancel ©2008, My Business | | Tenninado6.2.2. Ventana principal ‘A continuacién se puede ver una maqueta de propuesta para la pantalla prindpal de mensajes: Tendré 3 paneles: el izquierdo con la estructura de carpetas, el central con la lista de mensajes y el derecho con el mensaje detallado. Habrd dos barras de herramientas una para la gestién de carpetas (crear, borrar carpetas, etc.) y la otra estdndar para gestién de mensajes (nuevo, reenviar, responder, etc.) Por iltimo habré una barra superior de herramientas con las opciones de la aplicacién: configuracién, gestion y cerrar sesién. ‘Abert tenes nuevas afer de Sistas Insets et teas otto. noe et Satis cscmoove : InfoJobs.net6.2.3. Ventana de mensaje En esta ventana se redactaran los nuevos mensajes. Seré muy parecida a la ventana de redactar mensaje de Microsoft Outiook. La tinica diferencia notables son las siguientes variaciones: = Los campos: Para, CC, CCO, estarén en columnas en lugar de filas facilitando la lectura de destinatarios. = Existe un cuadro de contactos favoritos para arrastrar directamente y faclitar envios répidos. ~ _ Las opciones de enviar y guardar en borradores, estan situadas al final. ee oer) Recini (Cle header to nd) (Baee) Cad) Cae) Cat Subject Tiss anew message ‘tachmentNote (email 2.0) bert Giménez Quesoda 6.2.4. Afiadir adjuntos al mensaje Se debe permitir el afiadir varios adjuntos en un mensaje, para facilitar Ia tarea, se suglere el uso de ‘ModalPopups AJAX del Control Toolkit de Microsoft. De manera que se focalice al usuario en la tarea de seleccionar el archivo que quiere adjuntar. Por lo demas sera un cuadro de “Examinar..” esténdar para subir un archivo. 6.2.5. Busquedas Para la busqueda de mensajes también se sugiere el uso de Mode!Popups de AIAX. Para contactos, se debe poder buscar por nombre, departamento y servidor. Para los mensajes se debe poder buscar por cualquiera de los campos destinatario, intervalo de fechas de envio, por estado de lectura, asunto y contenido del mensaje. Habré dos tipos de biisqueda, una répida como campo en la cabecera de la lista de mensajes y la otra ampliada con todos los campos para hacer busquedas més complejas. 6.2.6. Revisién de lectura de mensajes Habré un apartado al consultar el detalle de un mensaje y en la lista de mensajes para poder ver las acciones de los mensajes enviados: se deberd pader ver el asunto de! mensaje, la fecha de envio y por cada destinatario, ver la accién (leido, no leido, eliminado, etc.) y si es apropiado la fecha y hora en que se ha realizado la accion. 3. IU Gestion interna de la aplicacién 6.3.1. Gestién de contactos y usuarios Cuando se de de alta un contacto. Se deberd asociar a su servidor local. Los campos nombre, departamento, idioma (que no sea vacio), permiso (que sea usuario o administrador) seran obligatorios. El campo Mensajes por pagina debera comprobarse que es un valor numérico > 0. 6.3.2. Gestidn de servidores remotos y peticiones de colaboracién Cuando se reciba una nueva peticién de colaboracién deberé mostrarse un aviso a los usuarios de tipo administrador (y sdlo a estos) informandoles de la situacién y con los datos del servidor. Habra una opcién para aceptar o rechazar la solicitud. ‘Si se acepta se deberé llamar a la funcién Get_Contact_List en el servidor remoto que nos ha contactado. En otro caso se eliminaré la entrada del servidor en la base de datos. 6.3.3. 1U.de configuracién y opciones de usuario ‘Se debe permitir un apartado configuracién del usuario para que éste pueda configurar sus preferencias: Idioma, nimero mensajes por pagina y si se implementa algtin sistema de pieles/disefios poder seleccionar el que desee. Como antes se debe comprobar que NP mensajes por pigina es > 0. El idioma se debe comprobar que sea alguno de los validos instalados en el sistema: comprobando la carpeta Localization y haciendo una lista de los idiomas disponibles. Pagina 35 de 617. Note (email 2.0): implementacion En este apartado se describe grosso modo, los archivos y la estructura que mantiene el proyecto en la implementacién realizada. NOTA: en esta versién ini jal, no esta implementada la interfaz de usuario (IU). 7.1. Lista de archivos = 7 hep _Code = Business Layer ] chalenge.vb ) contact.vb °F) Contaet_External.vb °®) Contaet_Interna. vb 8) Fev Ye) Felder. vb 18) Matbox.vb ©) message.vb 8) Message _Emai.vb %) Message Fies.vb “®) Message Note.vb °S) Message. Status.vb ©) Server vb F) this Servervb B) Ticket. vb = 4 Data Layer Ly Notes + Presentation Layer Support °®) Authentication vb 8) CRindael.vo ®) Localzation vb ©) Support_Database.vb °©) Support_Functions.vb ©) Support_Securty.vb a *) Constants. ©) Note_Messaging.vb = 4 Aop_WebReferences = Note Webservice 1] Note_Messaging dco 1) Note_Messaging.dscomap 5] Note_Messaging wed + gn + <4 Support + a Testunts 15 Connection.config =| index.aspx =| Maibox.master 3H Note_Meszaging.asmx 1) Settings. contig 1} Web config App_Code: ésta es una carpeta estandar de ASP.Net 2.0 y contiene los archivos de cédigo fuente (en nuestro caso archivos .vb de Visual Basic) Esta carpeta contiene la estructura de cédigo de Note (email 2.0: = Business Layer: contiene los objetos que componen y definen et software y que ya se ha comentado en el documento. = Data Layer: contiene el archivo script ANSI SQL Note.sql que permite crear la estructura de base de datos, = Presentation Layer: contendré los archivos de cédigo intermedios para crear la interaz de usuario (IU). = Support: contiene los médulos de soporte creados para faciitar algunas tareas de programacién. = Authentication: se encarga de la autenticacién de usuarios en el sistema. ~ Localization: se encarga de la traduccién de la interfaz de usuario a indies idiomas. ~ Support Database: se encarga del acceso a base de datos. = Support. Functions: se encarga de funciones de soporte. = Support. Security: se encarga de funciones de encriptacisn y seguridad. ~ CRiindael.vb: dase de soporte para Support Security y se encarga de encriptar en el algoritmo AES Rijndael. Contants.vb: contiene las constantes usadas internamente en. la aplicacion. ‘Note_Messaging.vb: contiene el cBdigo fuente del Web Service, App_WebReferences: ésta es una carpeta estindar de ASP.Net 2.0 y contiene las referencias al Web Service y sus archivos de descripcién {ue permite la comunicacién con el servicio. Bin: ésta es una carpeta estindar de ASP.Net 2.0 y contiene los archivos -ally binarios necesarios para la ejecucién. Support: esta carpeta contiene los archivos de soporte de la aplicacion como CSS, archivos de traduccién de la interfaz, etc. Test Units: esta carpeta contiene paginas .aspx para hacer pruebas de ejecucién y testeo. Web. config: archivo esténdar de .NET con la defnicién y configuracién del sitio Web. ‘Connection.config: archivo auxliar de configuracién creado para contener la informacién de conexién con la base de datos. ‘Settings.config: archivo auxiliar de configuracién creado para contener la configuracién del servidor y sus parametros asociados. Mailbox.master: plantila principal con la estructura basica de la 1U, a partir de esta plantilla se generaran el resto de paginas de la IU. Index.aspx: pagina de inicio de a aplicacién.7.2. Diagrama de clases ‘Aqui se puede ver la materializacién del UML. Sélo denotar las siguientes cosas: ~ En Visual Basic una clase Public Static la denota como Module. Los médulos permiten llamar a operaciones sin necesidad de instanciar una clase. - Se puede ver que hay una clase adicional: Mailbox que corresponde a la materializacién del concepto de bbuzén (ver Carpetas). = Ticket se ha materi ¥ la implementacién del Web Service ya que se pasa como un tipo estandar (string). seme yet este pte Message. Ena a Contac terad ‘s ‘Authentication Sepp atte ‘hie Sever Stop Fn. ket izado como médulo y no como clase. Esto se ha hecho asi por comodidad de programacién ya que s6lo interesa el JdTicket (la string que forma el ticket) y no el objeto completo con sus ‘operaciones a la hora de trabajar y pasar como pardmetro a funcién. De esta manera se simplifica el desarrollo Folder Messe files Spoor Secunty7.3. Puesta en inicio de un servidor Note (email 2.0) Para la puesta en marcha de un servidor Note (email 2.0), hay que realizar los siguientes pasos: 1+ Copiar el proyecto dentro de la carpeta del servidor Web (normalmente C:\Intetpub\wwwroot), 2+ Configurar la carpeta como aplicacién en IIS: 3+ Verificar que la aplicacién se ejecute bajo la versién .NET Framework correcta:4- Crear la estructura de la base de datos, ejecutando el script Note.sql, dentro de la carpeta Data Layer: FO er oer beat Io en comet Eo wow 5 Lene y 2 Be oactsows +2 mtcometed @utend Seett : uaasa fom mance ose 2 nore vaaes seen eS rs ofo 53 #e Omorees 5+ Editar el archivo en la raiz del sitio Settings.config, que contiene los datos bisicos de configuracién del servidor, ‘como por ejemplo, el nombre, la IP para conexién extema, etc. @sasarnso-, Be Ses 08 ee TRL{6 Editar el archivo en la raiz del sitio Connection.config, que contiene los datos de configuracién con la base de datos: Jeju-dg sas a 38 P1983 aFae Boe 7- Inidar desde el navegador la pagina Index.aspx: hit //cccionipservidor/Note/index. asox Ww ase on Pcie a Zcivo Eotor Yer Historal Mucadoes Heramiens Anco |i@-o-€ @ | hito//sevidorinatendexason he NOTE Cancel (©2008, My Business | a