X IRIS-MAIL, Nov 1999- Universidad de Oviedo

[ Tabla de contenidos ]

Exposicion de Jesus Sanz de las Heras. RedIRIS.


Uno de los temas presentados en esta reunin fu un documento con una
serie de recomendaciones bsicas y mnimas para reducir los efectos del
correo-e no deseado dentro del Servicio de correo-e de cualquier
institucin 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 smbolo de calidad
del Servicio, es decir la institucin que considere cumple este declogo
podra ponerlo como un smbolo de buen servicio. Por supuesto pretende
informar de los aspectos  mas importantes a tener en cuenta para evitar
problemasy pretenda ser la segunda parte del pequeo tutorial que se
expuso en las pasadas reuniones de IRIS-MAIL en Mayo de 1999 en Madrid
con el ttulo de:   Qu debe de ser un Servicio de correo-e
institucional ?
	  Qu institucin 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 problemtica:

		- Aumento de incidentes en periodos vacacionales e instituciones de
tamao pequeo.
		- Aparicin de efectos producidos por problemas colaterales del spam.
		- Aumento del nmero 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 resolucin
inversa.
		- No utiliza filtros de correo-e de servidores de forma unilateral.

 Esta poltica 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.


Comentarios de Jose Antonio Corrales. UNIOVI

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
    sesin 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 aadiendo 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 Iaki Ortega Bergara. EHU (Bizkaia)



heras> 	  Qu institucin puede asegurar que cumple con los estos 10
heras> requisitos ?


 Nosotros cumplimos con la mayora 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
institucin fue una de las que cay en sus garras y pag casi toda la
institucin, que s que rechazaba el relay, por una estafeta secundaria que no
lo haca. 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 todava, a que se lo planteen.


heras> No hay que vender nada. Adems las MAPS/RBL te recuerdo que no est en
heras> el documento, es un poltica unilateral de cada institucin que RedIRIS
heras> como institucin 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 reunin.



En cuanto a los siguientes puntos del documento:

- ---------------
8. En caso de que la Institucin disponga de un servidor de listas de
distribucin en su red debe disponer de las medidas mnimas para
proteger el servicio:

No permitir listas pblicas de envo.
Controlar la disponibilidad de la relacin de suscriptores.
No permitir suscripciones no deseadas a terceros.

(...)

10.La institucin es responsable de las consecuencias que impliquen el almacenamiento
y manipulacin automtica 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 pblicas de envo'?
cmo no permites subscipciones no deseadas a terceros si la lista es abierta?
Supongo que el software que utilizo est obsoleto y carece de los mnimos
controles.


heras> Cualquier lista de un servidor interno de una organizacin
heras> SLO debe permitir  enviar a los suscriptores. Para suscribirse  debe
heras> ser obligatorio verificar la direccin que se suscribe con el mecanismo
heras> que sea, Majordomo lo lleva y LISTSERV usa el mecanismo de OK.

heras> La direccin 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 institucin que la sustenta. No es cuestin
heras> de evitar la suscripcin 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 opinin s, basta con leas el reglamento de la LORTAD, 
heras> cuyo cumplimiento  aportara 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 quizs pueda  salirse del marco de esta reunin.


Esta página ha sido firmada digitalmente usando PGP