Introducci�n

Este es el punto mas importante de la iniciativa ya que nos permitir� definir los criterios de selecci�n y estructurar el proyecto. La idea es definir 3 niveles de calidad del Servicio (nivel b�sico, nivel medio y nivel avanzado) y cada uno de ellos con un serie de indicadores de calidad . A cada indicador se le asignar� un valor (peso) individual que habr� que definir. Cada uno de los niveles tendr� un valor total m�ximo. Seg�n los indicadores que disponga una instituci�n encajar� en un Nivel u otro.

Estos criterios dar�an una estimaci�n cuantitativa que nos permitir� catalogar los servicio de correo de una instituci�n en alguno de los 3 niveles anteriormente definidos Con esta relaci�n se har� una mapa de la calidad del Servicio de correo-e en la comunidad RedIRIS. A cada criterio RACE se le ha a�adido alguna informaci�n adicional: RFC, legislativa etc

�mbito de aplicaci�n. Para acotar la implantaci�n o uso de los indicadores, �stos deber�n afectar como m�nimo a las Estafetas (principal y secundarias) controladas por los responsables del Servicio de Correo Electr�nico de dicha la Instituci�n.

Todos los criterios del Nivel B�sico son de obligado cumplimiento para que un Servicio de Correo Electr�nico sea etiquetado en este Nivel. Se han considerador criterios m�nimos para la calidad de este Nivel B�sico.

En los niveles Medio y Avanzado hay unos indicadores que se han considerado como imprescindibles ,es decir, criterios m�nimos y de obligado cumplimiento para que un Servicio sea etiquetado con uno de estos dos estos niveles.

Nivel b�sico

EL objetivo de este Nivel B�sico es definir un nivel m�nimo de calidad del Servicio de Correo donde se han considerado no s�lo aspectos t�cnicos. Como ya se ha comentado anteriormente todos los criterios de este Nivel son de imprescindibles de obligado cumplimiento

1. Control de acceso al puerto SMTP/25 de la Instituci�n (tr�fico de entrada).

   Descripci�n: Existencia de un �nico punto de entrada del tr�fico SMTP en la Instituci�n a trav�s de la definici�n de listas de acceso (filtros) del puerto SMTP(25) en el router principal.

2. Documento p�blico describiendo el Servicio de Correo Electr�nico.

   Descripci�n: Documento p�blico y conocido por los usuarios que defina la pol�tica t�cnica del mismo (POP/IMAP, seguridad, tama�o buzones o mensajes de entrada, listas de spam) asi como el buen uso del servicio de correo-e.Este documento debe describir:

   • Responsabilidades del Servicio
   • Tipo de MTA en los puertos
   • Modelo de acceso (pop,imap,http)
   • Pol�tica Antivirus
   • Politica AntiSpam
   • Pol�tica de Logs (trazas)
   • Pol�tica de encaminamiento: entrada y salida
   • Servidores: descripci�n simple
   • Capacidad m�xima permitida de los buzones.Si existe
   • Politicas de limpieza o eliminacion de buzones. Si existe.
   • Puntos de contacto: postmaster, abuse

   Informaci�n: DOCE (Documento de Correo Electr�nico)-ZT IRIS-MAIL-. Recomendaciones de RACE para generar un documento descriptivo del Servicio
   Art 37/3c de "Ley 34/2002 de 11 de Julio de Servicios de la Sociedad de la Informaci�n y de comercio electr�nico"

3. Reglas Anti-Relay.

   Descripci�n: Definir claramente las direcciones IP de las redes a las que damos servicio de correo-e y que deber�n ser las �nicas que tengan permiso de utilizar el servidor principal para encaminar correo. A cualquier otra se la debe denegar el servicio en la transacci�n SMTP.
   Es decir, hay que tener completo control de las direcciones IP que tienen permiso para establecer un sesi�n SMTP contra nuestro servidor, l�gicamente se incluyen tanto Agentes de Usuarios desde PCs como servidores de correo-e secundarios internos de nuestra organizaci�n No se debe aceptar correo desde direcciones externas a nuestra dominio y destinadas a direcciones externas a nuestro dominio. Esta regla junto con el anterior p�rrafo debe denegar el encaminamiento de correo desde cualquier direcci�n IP fuera de nuestro dominio destinada a cualquier direcci�n (RCPT TO:) fuera de nuestro dominio, independientemente cual sea la direcci�n origen del sobre(MAIL FROM:).
   Informaci�n: RFC2505 (Anti-Spam Recommendations for SMTP MTAs), RFC2635 (A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)

4. Servicio de soporte y gesti�n de incidentes (abuse, postmaster@)

   Descripci�n: Servicio documentado y divulgado de atenci�n de problemas relacionados con el correo electr�nico postmaster@ y de abusos de correo abuse@ falsificaciones, correo no deseado (spam)
   Informaci�n: RFC822 (6.3), RFC2821 (4.5.1) RFC1123 (5.2.7),

5. Sincronizaci�n NTP.

   Descripci�n: Sincronizaci�n horaria con la red NTP de RedIRIS de los servidores de correo.
   Informaci�n:Zona horaria en Espa�a

6. Antivirus en el Servidor de Correo (Entrada/Salida).

   Descripci�n: Existencia de alg�n tipo de Antivirus que escanee el tr�fico SMTP de entrada y salida a la instituci�n en busca de virus.

7. Pol�tica de ficheros de trazas (logs)

   Descripci�n: Existencia y mantenimiento de ficheros donde se almacenen las trazas de las transacciones SMTP de la Instituci�n. Rotaci�n y almacenamiento de dichos ficheros de los �ltimos 6 meses como m�nimo.
   Informaci�n:Art 12 de "Ley 34/2002 de 11 de Julio de Servicios de la Sociedad de la Informaci�n y de comercio electr�nico"

8. Datos del administrador del Servicio en la base de datos de RedIRIS.

   Descripci�n: Personas implicadas en la gesti�n del Servicio dadas de alta en la base de datos IRIS-MAI donde est� los responsables del Servicio de correo-e de cada instituci�n de RedIRIS.

9. Resoluci�n inversa de las Estafetas

   Descripci�n: Las Estafetas que componen el Servicio deben disponer de resoluci�n inversa de sus respectivas direcciones IP.
   Informaci�n:RFC3172"Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", DNS en RedIRIS

   Nivel Medio.

   El objetivo de Nivel Medio es definir criterios de valor a�adido al Servicio que se han considerado aportan calidad al mismo. En este Nivel hay dos criterios imprescindibles. El control del tr�fico de salida es un nivel mas para controlar todo el tr�fico smtp de entrada/salida con todas las ventajas que ello aporta. El servicio de WebMail es lo m�nimo que se puede ofrecer a los usuarios acceso desde el exterior a sus buzones.

10. Control de acceso al puerto 25 de la Instituci�n (tr�fico de salida) -imprenscindible-

    Descripci�n: Existencia de un �nico punto de salida del tr�fico SMTP en la Instituci�n a trav�s de la definici�n de listas de acceso (filtros) del puerto SMTP(25) en el router principal.

11. Servicio de WebMail. -imprenscindible-

    Descripci�n: Servicio b�sico de acceso remoto a los buzones de correo a trav�s de aplicaciones web con acceso SSL que permita el cifrado de datos entre el punto de acceso y el servidor WebMail.

12. Servicio de Listas de Distribuci�n.

    Descripci�n: Servicio de distribuci�n masiva y organizada de informaci�n as� como foros de debate para el trabajo en grupo. Es un servicio de valor a�adido que ofrece ventajas a la calidad del Servicio.

13. Servicios a�adidos a usuarios: cambio de clave, redirecci�n de correo, autorespondedor (vacaciones etc).
    Descripci�n: Son servicios de gran valor a�adido en un Servicio de Correo Electr�nico.

14. Control tama�o de mensajes

    Descripci�n: Definici�n de filtros o medidas para impedir transacciones SMTP desde el exterior de ficheros voluminosos e impedir problemas de seguridad. Alternativas:

    • Servicio de Servidor por ficheros.
    • Otros: control de cuotas de buzones etc
    
    Informaci�n:RFC1653 "SMTP Service Extension for Message Size Declaration".

15. Estad�sticas del Servicio

    Descripci�n: Estad�sticas del tr�fico SMTP de las m�quinas que nos permitir� dimensionar de forma adecuada la evoluci�n del servicio.

    Nivel Avanzado

    El objetivo de este Nivel b�sicamente es conseguir cifrar y autenticas todas las transacciones entre el emisor y el receptor de un mensaje.ES el niv�l m�ximo y el que nos permitir� ir aumentando una Red Privada Acad�mica de correo-e con encaminamiento est�tico y conexiones cifradas y autenticadas entre los extremos.

16. Cifrado en transacciones POP, IMAP y SMTP (UA-MTA) -imprescindible-

    Descripci�n: Permitir a los usuarios poder utilizar SMTP, POP, IMAP autenticado y cifrado. Correo cifrado entre usuarios. Infraestructura de PKI integrada en el Servicio de correo-e.
    Informaci�n:RFC2595 "Using TLS with IMAP, POP3 and ACAP"

17. Comunicaci�n cifrada SMTP entre MTAs internos (MTAi-MTAi) -imprescindible-

    Descripci�n: El correo interno entre Estafetas debe ser cifrado (TLS)
    Informaci�n:RFC3207 "SMTP Service Extension for Secure SMTP over Transport Layer Security"

18. Estructura de PKI en el Servicio de Correo Electr�nico.

    Descripci�n: Autenticaci�n y cifrado de correo con la CA de la Instituci�n que permita a sus usuarios firmar/cifrar los mensajes .

19. Autenticaci�n centralizada.

    Descripci�n: Sistema de autenticaci�n de buzones centralizado.

20. Autenticaci�n en transacciones SMTP externas (UA-MTA)

    Descripci�n: Permitir a clientes SMTP autenticarse cuando se desea utilizar el relay desde direcciones IP externas a nuestro dominio: SMTP-AUTH,SASL.
    Informaci�n:RFC2554 "SMTP Service Extension for Authentication"

21. Comunicaci�n cifrada SMTP con MTA externos (MTA-MTA)

    Descripci�n: MTA preparada para establecer conexiones cifradas (TLS)
    Informaci�n:RFC3207 "SMTP Service Extension for Secure SMTP over Transport Layer Security"

22. Alta disponibilidad en el servicio de correo.

    Descripci�n: Si disponemos de un sistema centralizado de autenticaci�n es necesario la redundancia o alta disponibilidad para garantizar la disponibilidad del Servicio y el acceso a los buzones:
    

    • Alta disponibilidad en Estafeta de entrada (MTA) (Round Robin, switch...)
    • Alta disponibilidad en Almac�n de buzones (MDAs) o
    • Redundancia del servidor de autenticaci�n.

Criterios Meritorios

Hay indicadores que por su contexto o son experimentales o son dif�ciles de evaluar pero si son de inter�s tenerlos en cuenta. Estos criterios podr�n ser valorados en la evaluaci�n y son lo siguientes:

Parametrizaci�n del MTA:

• Cumplimiento de RFCs en los errores de entrega
• Notificaciones al usuario de retraso en la entrega
• Configuraci�n del banner smtp para no revelar informaci�n de la versi�n
• Deshabilitar los comandos expn y vrfy
• Definir un valor m�ximo de destinatarios por correo
• Definir un tama�o m�ximo de devoluci�n de mensaje de error ( envio 100 Mb y me devuelves un error que solo contiene los 50 primeros kbs )

Otros experimentales:

• Ipv6 entre MTAs y todo lo que conlleva, direcciones, DNS
• Certificados en MTAs para cifrar transacciones SMTP externas.
• Librerias Milter en MTAs y sus posibilidades
• Criterios de compilaci�n RACE para sendmail y postfix
• Implementaci�n de confirmaci�n de entrada de mensaje en las Estafetas que formen RACE.

Institucionales:
� Dispone su Instituci�n de un m�todo fiable que permita apreciar las necesidades, expectativas y el grado de satisfacci�n de los usuarios del servicio de correo electronico, y poder tenerlos en cuenta a la hora de planificar nuevas prestaciones ?

Si usted dispone de alg�n m�todo (encuestas, otros hojas de sugerencias, etc.) expliqu�lo en el formulario del correspondiente Nivel.