• Inicio IRIS-MAIL (desde 1993)

Uno de los temas presentados en esta reunión fué un documento con una
serie de recomendaciones básicas y mínimas para reducir los efectos del
correo-e no deseado dentro del Servicio de correo-e de cualquier
institución afiliada a RedIRIS.  Dicho documentos podreis encontrarlo en:

		http://www.rediris.es/mail/abuso/race.html

El objetivo de este documento era conocer qué instituciones pueden
afirmar que cumplen con estas recomendaciones como un símbolo de calidad
del Servicio, es decir la institución que considere cumple este decálogo
podría ponerlo como un símbolo de buen servicio. Por supuesto pretende
informar de los aspectos  mas importantes a tener en cuenta para evitar
problemasy pretendía ser la segunda parte del pequeño tutorial que se
expuso en las pasadas reuniones de IRIS-MAIL en Mayo de 1999 en Madrid
con el título de:  ¿ Qué debe de ser un Servicio de correo-e
institucional ?
	 ¿ Qué institución puede asegurar que cumple con los estos 10
requisitos ?

 Para darnos cuenta de la magnitud del problema os diré que desde Marzo
de 1999 y relacionado con el uso no autorizado de servidores de correo
hubo:

		- 165 incidentes .
		- 59 instituciones afectadas.

Otros datos a tener en cuenta acerca de la problemática:

		- Aumento de incidentes en periodos vacacionales e instituciones de
tamaño pequeño.
		- Aparición de efectos producidos por problemas colaterales del spam.
		- Aumento del número de instituciones de RedIRIS que han definido
filtros en el puerto SMTP (25).

Como datos complementarios,  el Centro de Comunicaciones CSIC/REDIRIS:

		- Ha adoptado el uso de MAPS/RBL. Rechaza correo de servidores
incluidos en estas tablas.
		- No acepta conexiones de servidores de correo-e sin resolución
inversa.
		- No utiliza filtros de correo-e de servidores de forma unilateral.

 Esta política es usada tanto en el servidor de correo principal de
RedIRIS: 130.206.1.3 (chico.rediris.es) como en el servidor que soporta
el servicio de MailBackup (mail.rediris.es - 130.206.1.2) y que afecta a
las instituciones que disponen de dicho servicio.

Excepto los  dos apartados del punto 2 del documentp, creo que cumplimos todos
los demas requisitos:

2.2 Chequean el DNS para rechazar conexiones SMTP de servidores
    que no dispongan de resolucion inversa.
2.3 Chequan el DNS para rechazar mensajes en los que durante la
    sesión SMTP aparezca un valor de MAIL FROM: con un dominio
    incorrecto.

No tengo clara ademas la utilidad de estos puntos frente a la
degradacion de servicio que conllevan ya que hay que realizar una 
llamada "extra" al DNS.Las consultas sobre maquinas que no estan
"cerca" llevan su tiempecillo (todos sabemos que la red va cada
dia mas lenta).

Sobre el 2.2 estoy cansado de recibir mensajes (al postmaster)
del estilo:

          "user dfdfdfdf@ibm.com does not exist"

(un spammer que trato de enviar basurilla a un ex-usuario nuestro
y que puso de from: o errors-to: o return-to: una direccion falsa
de un dominio existente)

El primer spammer que vea rechazado un mensaje con direccion
inexistente tardara un segundo en poner una direccion de dominio
existente pero falsa o incluso una direccion real que no sea la
suya.



 
Comentarios de Juan Carlos Blanco. FI.UPM



ja.corrales> El problema Jesus es que el funcionamiento del correo (recepcion)
ja.corrales> esta quedando subordinado al funcionamiento del DNS y esto solo
ja.corrales> trae desventajas e inconvenientes para el usuario. Al final lo
ja.corrales> unico que ha ocurrido es que por malfuncionamiento del DNS un
ja.corrales> usuario ha recibido un correo importante con 8 dias de retraso. Y
ja.corrales> ello se podia haber evitado.

Jose Antonio, en parte de doy la razon, la validacion extra de cualquier
cosa contra el DNS provoca una mayor lentitud en el flujo de los mensajes,
sin embargo, sobre este parrafo quiero comentar que el buen funcionamiento
del correo SIEMPRE ha estado subordinado al BUEN funcionamiento del DNS,
sino no hay manera de traducir los servidores correspondientes a las
direcciones de correo y las direccions IP de estos.

En este caso, solo estas añadiendo la necesidad de que no solo el receptor,
sino tambien el emisor tengan bien configurado su DNS, creo que no es
demasiado pedir ya que si no las posibles respuestas a los mensajes tampoco
llegarian a su destino.

Por otra parte se estan mezclando dos cosas, los mensajes de "princast.es"
no eran procesados, no porque no funcionara el servidor de correo, que para
eso esta la cola de mensajes, sino porque no funcionaba el DNS, y en mi
opinion esto es mas grave y requiere una solucion mas urgente ya que
puede provocar la perdida del correo destinado a ese dominio.




 
Comentarios de Iñaki Ortega Bergara. EHU (Bizkaia)




heras> 	 ¿ Qué institución puede asegurar que cumple con los estos 10
heras> requisitos ?


 Nosotros cumplimos con la mayoría de los puntos salvo con los que ha comentado
Jose Antonio sobre el DNS.

En cuanto a las listas MAPS/RBL me lo teneis que vender muy bien ya que nuestra
institución fue una de las que cayó en sus garras y pagó casi toda la
institución, que sí que rechazaba el relay, por una estafeta secundaria que no
lo hacía. Lo que sí que hicimos a partir del incidente (como no) fue aplicar
los filtros al puerto 25 y ahí sí que hemos ganado en tranquilidad. En esto sí
que animo, a los que no lo hagan todavía, a que se lo planteen.


heras> No hay que vender nada. Además las MAPS/RBL te recuerdo que no está en
heras> el documento, es un política unilateral de cada institución que RedIRIS
heras> como institución ha adoptado, pero cada uno es libre de adoptar la que
heras> mejor considere. El documento sí son recomendaciones globales para toda
heras> la Comunidad RedIRIS , en caso de que se obtenga  un amplio consenso en
heras> esta reunión.



En cuanto a los siguientes puntos del documento:

- ---------------
8. En caso de que la Institución disponga de un servidor de listas de
distribución en su red debe disponer de las medidas mínimas para
proteger el servicio:

No permitir listas públicas de envío.
Controlar la disponibilidad de la relación de suscriptores.
No permitir suscripciones no deseadas a terceros.

(...)

10.La institución es responsable de las consecuencias que impliquen el almacenamiento
y manipulación automática de datos de direcciones de correo-e por parte de los
usuarios de su red de acuerdo con el "Reglamento de seguridad de la LORTAD".
- --------------

En el punto 8 ¿a qué se refiere el 'No permitir listas públicas de envío'?
¿cómo no permites subscipciones no deseadas a terceros si la lista es abierta?
Supongo que el software que utilizo está obsoleto y carece de los mínimos
controles.


heras> Cualquier lista de un servidor interno de una organización
heras> SÓLO debe permitir  enviar a los suscriptores. Para suscribirse  debe
heras> ser obligatorio verificar la dirección que se suscribe con el mecanismo
heras> que sea, Majordomo lo lleva y LISTSERV usa el mecanismo de OK.

heras> La dirección de una lista es como de una persona pero los indeseables
heras> pueden usarla para fines no correctos que deterioran la funcionalidad de
heras> la lista y la imagen de las institución que la sustenta. No es cuestión
heras> de evitar la suscripción de las personas sino de definir mecanismos de
heras> control y sobre todo estar concienciado para evitarlo.


En cuanto al punto 10. ¿Esto implica a servicios como LDAP o X.500?

heras> En mi opinión sí, basta con leas el reglamento de la LORTAD, 
heras> cuyo cumplimiento  aportaría un nivel de calidad a cualquier 
heras> servicio que almacene datos: X500,LDAP,listas etc. La LORTAD 
heras> no elimina un ápice de funcionalidad ni al X500 ni al LDAP. El 
heras> debate de este  tema quizás pueda  salirse del marco de esta reunión.