RE: [LACNIC/Seguridad] [Seguridad] Nuevo código de conducta anti-spam en Australia
Anatoly Alexei Pedemonte Ku
apedemonte en gmail.com
Mie Abr 26 01:38:45 BRT 2006
Gracias por tus comentarios estimado Javier...
Me parece realista, tu punto de vista, limitar al spammer a no cumplir su
objetivo es buen punto...
-----------------------------------------------------------
Anatoly Alexei Pedemonte Ku
RAGE SYSTEMS S.A.C.
<http://www.ragesys.net/> http://www.ragesys.net
Av. Juan Pascal Pringles 1225 (ex- La Fontana) - LA MOLINA
LIMA - PERU
Teléfono: 511.7962262
Móvil: 511.97167435
-----------------------------------------------------------
Este correo y su contenido son confidenciales y exclusivos para su
destinatario. Si usted recibe este mensaje por error o no es el destinatario
del mismo, por favor sírvase eliminarlo y notificarle a su originador. Así
mismo, todas las ideas y reflexiones expresadas en esta comunicación
corresponden al originador del correo y NO representa la posición oficial de
su empleador.
----------------------------------------------------------------------------
----------------------------------------------------------
This email is intended only for the addressee(s) and contains information
which may be confidential, legally privileged. If you are not intended
recipient please do not save, forward, disclose or copy the content of this
email. Please delete it completely from your system and notify
originator.Finally, all ideas expressed in this communication are personal
comments and NOT represent official position of his employer.
----------------------------------------------------------------------------
----------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.3 (MingW32)
mQGiBERIkeQRBAClI9GKvK4sDfnnXiZPZAu1LxTNd8dT+F2SG3R38LbCPzqKE7vh
GpIv73VkjoSaRPdeB3LXWwA6aKEQU+IZESB78EaQomSfNYCxDshc7DoqgYX9F6cJ
chlB2bhC8FP1l3wUMudTIyPyKjg84DkSDSnwn7xjAe7cvKyZ+ro0/7FRTwCg/7dQ
Q9Bmb/bx7nUgb0ciWRbQSEcEAIUXDt8uTbIdq+dH5ufMFFV+KwobpXA8wA6J0vkv
BI9mdh+7IaQ6W9Tb3v78QMC2C9EbTQUJueCNZ/e7BT1VraTzZhbxR8WXyL1F9a5Y
TEdU//d33Wx1RG3WPIFvWkAy/AgOaxMpJ4ObvEVEyVevDn0J5PtVjflpO3yeCVns
iLSwBACJegqLf9fp3Rz57rQaDwtnDMUd54T6ZdWpxHnz3x1lPqcN1BC8zZcxOpMh
PgvzbH6jjaC2T4LMppqFDVq2xA9+UJINmen5S92HzNvyvq6VmaWwO1QCKWApQes+
NFOIU+/pPFsSHLJxl2h0lu0MW2hwYbno+MwirmHgBGoAs8H0gbRIQW5hdG9seSBB
LiBQZWRlbW9udGUgS3UgKEZpcm1hIERpZ2l0YWwgZGUgQW5hdG9seSkgPGFuYXRv
bHlAcmFnZXN5cy5uZXQ+iGAEExECACAFAkRIkeQCGwMGCwkIBwMCBBUCCAMEFgID
AQIeAQIXgAAKCRBnMNxOlTPvNcsBAKCLyLwBbsoZwQFuUWifS1Qv+158iACguCAl
ApL0XCJJsxwaDcJC0YKbzV+5Ag0EREiR6RAIAJMJSK3nF7/GOZPK+xu7nt2OpbtD
sE+g5wS8Nz9rEEsTbDRqmLZ9neS6OODGj6abGFy6dUtR7LcJtCXufCr+dEsGA4O0
iSY/8k1bjWqoNqxHcTYbdhjy/SxYQOIrurTSsmlludhVn0XlpXN87jd9HtWi/Lg4
TZhp0CRqG7IfY8BGySUbqAWB63x8jMXTzJRoorJx/HxbDRvDAayJcZ+LV3l6dF0f
68km3TebPYf9Cca6cEQvn96gflcijneTbeKPU2JVClYBHtlnlJgFZjNsdSmsl3qb
m20BRWIyTux/Om7YBEZlGA6JonYQxmbK+LEnLvyTHUgohtYWEP5ED8qv1ncAAwUH
/0kpGlCvzHh1B1CH3Uc/AeUoXihvZM2D0TA887PyFSNAgkZBYyriRt8I7rTuVk4m
XvphOLJvSqoYUX+9kLP0oDWVzBGfKmvFWaoXVjOeP3D/o4r6YxZTVM6NdvSgS+gd
5U45Zg3f2offihvcNFyENjsFyYm2J8iTQb/YZqfb0fOrQNqp2I5HLsQO5rsyaok8
xZfwjjZO1mXvCtPvwNs5KoAzvrCElUXNjG0rigXL9/M4Ewjq3mVcL3K5mlOEg2Rj
qd6HfatZ6Fd00iGt751dHM45OO8+FTF6MD4DFR0+N25fS5PsYqM8Cc87yDdt/6G9
vLyvkPfmperuFuuWvQuR/mCISQQYEQIACQUCREiR6QIbDAAKCRBnMNxOlTPvNRvm
AKDCEGmCqWCdH+f4ZYal1bAXaNF2MwCdFiGKKQq3bxkF1iIlvlbzUs5GKTY=
=e5cb
-----END PGP PUBLIC KEY BLOCK-----
_____
De: seguridad-bounces en lacnic.net [mailto:seguridad-bounces en lacnic.net] En
nombre de Webmaster Comtron
Enviado el: Martes, 25 de Abril de 2006 05:35 a.m.
Para: seguridad en lacnic.net
Asunto: Re: [LACNIC/Seguridad] [Seguridad] Nuevo código de conducta
anti-spam en Australia
Anatoly:
En otro de mis mensajes yo comentaba que el problema del spam nos está
empezando a saturar.
Tanto la paciencia de nuestro lado de usuarios, las redes desde el lado del
ISP, etc.
Es un problema serio que si no se trata en serio lo único que va a generar
es impedirnos, finalmente, el uso del mail de la forma en la que estamos
acostumbrados.
O tendremos que incrementar tanto la capacidad de proceso para diferenciar
un mail válido de un spam que vamos a necesitar usar clusters.
Por eso, la idea que se presenta es la de buscar alguna solución rápida,
sencilla y barata que permita disminuir el spam. Empezando por la
generación, obviamente, ya que esto permite mucho mas ahorro que luchar
contra el spam ya emitido.
Y hasta ahora venimos discutiendo mucho, pero las propuestas que garantizen
smtps abiertos, con individualización real del usuario, que IMPIDAN que ese
usuario mande spam, que lo haga on the fly y que se puedan implementar en
poco tiempo y sean de bajo costo, no aparecen.
Tenemos algunos miembros de la lista que no han entendido lo que significa
EVITAR LA GENERACION del spam y piensan que, bajo el argumento de un control
que jamás tuvieron ni van a tener, pueden elegir si permiten o no la salida
libre por puerto 25. Y además lo quieren gratis.
¿No serán la misma gente que trató que los ISPs argentinos tuvieran que
guardar durante 10 años todas las comunicaciones de sus clientes, a costo de
ellos y sin que el Estado Nacional pusiera un mísero peso, y que encima todo
eso estuviera disponible 24 x 7 para la consulta de los organismos de
seguridad?
Redondeando:
Salida por un único puerto 25, con chkusr = control de spam saliente
SMTP AUTH = identificación de spammer, requiere si o si el punto anterior,
sino es inútil.
Spamassassin y toda la parafernalia de reglas: para MARCAR los mails
entrantes y que el cliente decida que hacer con ellos.
Opciones comerciales para ofrecer al usuario con costo adicional: white y
black list personalizada, dirección de feedback para enseñar a su
spamassassin lo que es y lo que no es spam, tmda y/o e-mails de 24 hs de
vida, y una larga lista de etcs.
Saludos
Javier
Anatoly Alexei Pedemonte Ku escribió:
Estimados amigos.
Interesantes commentarios y distintos puntos de vista...
Algunos en realidad sobre las medidas sobre el Spam hay muchas formas de
implementar...
Pero creo que la base a todo este problema es usar muchas tecnologias y
contramedidas con respeto al protocolo SMTP.
Habiendo entre ellas, tecnologias abiertas:
- SMTP_AUTH, TLS, SSL, correspondiente a la autentificacion y antirelay
- CHKUSER (qmail: limita que no puedes enviar p.e 15 correos seguidos en 50
segundos)
- DSPAM, SpamAssassin, Consulta de RBLs, Regex.
- SPF, Domain Keys, GreyList....
Bueno algunas, medidas que se puede tomar en cuenta en el protocolo...
Aunque tambien quizas utilizar los puertos 587 y 465, segun algunos, que
oficialmente son usadas por Gmail, y mencionadas en la lista.
Pues el protocolo, fue diseñado desde un principio en un realidad distinta a
la actual, y creo que debe exisitir por alli alguna universidad o grupos
tratando de diseñar algun protocolo o infraestructura, para lo que se
denomina en conjunto, e-collaboration, ademas que las medidas para este
problema debe ser un estandar, y que todos los servidores o al menos un
porcentaje aplicar estas bases, y asi disminuir este dilema...
Mi humilde opinion, si hay alguien quien me aclare un lapsus, espero su
comentario, y si hay que complementar, adelante con las opiniones....
-----------------------------------------------------------
Anatoly Alexei Pedemonte Ku
RAGE SYSTEMS S.A.C.
http://www.ragesys.net
Av. Juan Pascal Pringles 1225 (ex- La Fontana) - LA MOLINA
LIMA - PERU
Teléfono: 511.7962262
Móvil: 511.97167435
-----------------------------------------------------------
Este correo y su contenido son confidenciales y exclusivos para su
destinatario. Si usted recibe este mensaje por error o no es el destinatario
del mismo, por favor sírvase eliminarlo y notificarle a su originador. Así
mismo, todas las ideas y reflexiones expresadas en esta comunicación
corresponden al originador del correo y NO representa la posición oficial de
su empleador.
----------------------------------------------------------------------------
----------------------------------------------------------
This email is intended only for the addressee(s) and contains information
which may be confidential, legally privileged. If you are not intended
recipient please do not save, forward, disclose or copy the content of this
email. Please delete it completely from your system and notify
originator.Finally, all ideas expressed in this communication are personal
comments and NOT represent official position of his employer.
----------------------------------------------------------------------------
----------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.3 (MingW32)
mQGiBERIkeQRBAClI9GKvK4sDfnnXiZPZAu1LxTNd8dT+F2SG3R38LbCPzqKE7vh
GpIv73VkjoSaRPdeB3LXWwA6aKEQU+IZESB78EaQomSfNYCxDshc7DoqgYX9F6cJ
chlB2bhC8FP1l3wUMudTIyPyKjg84DkSDSnwn7xjAe7cvKyZ+ro0/7FRTwCg/7dQ
Q9Bmb/bx7nUgb0ciWRbQSEcEAIUXDt8uTbIdq+dH5ufMFFV+KwobpXA8wA6J0vkv
BI9mdh+7IaQ6W9Tb3v78QMC2C9EbTQUJueCNZ/e7BT1VraTzZhbxR8WXyL1F9a5Y
TEdU//d33Wx1RG3WPIFvWkAy/AgOaxMpJ4ObvEVEyVevDn0J5PtVjflpO3yeCVns
iLSwBACJegqLf9fp3Rz57rQaDwtnDMUd54T6ZdWpxHnz3x1lPqcN1BC8zZcxOpMh
PgvzbH6jjaC2T4LMppqFDVq2xA9+UJINmen5S92HzNvyvq6VmaWwO1QCKWApQes+
NFOIU+/pPFsSHLJxl2h0lu0MW2hwYbno+MwirmHgBGoAs8H0gbRIQW5hdG9seSBB
LiBQZWRlbW9udGUgS3UgKEZpcm1hIERpZ2l0YWwgZGUgQW5hdG9seSkgPGFuYXRv
bHlAcmFnZXN5cy5uZXQ+iGAEExECACAFAkRIkeQCGwMGCwkIBwMCBBUCCAMEFgID
AQIeAQIXgAAKCRBnMNxOlTPvNcsBAKCLyLwBbsoZwQFuUWifS1Qv+158iACguCAl
ApL0XCJJsxwaDcJC0YKbzV+5Ag0EREiR6RAIAJMJSK3nF7/GOZPK+xu7nt2OpbtD
sE+g5wS8Nz9rEEsTbDRqmLZ9neS6OODGj6abGFy6dUtR7LcJtCXufCr+dEsGA4O0
iSY/8k1bjWqoNqxHcTYbdhjy/SxYQOIrurTSsmlludhVn0XlpXN87jd9HtWi/Lg4
TZhp0CRqG7IfY8BGySUbqAWB63x8jMXTzJRoorJx/HxbDRvDAayJcZ+LV3l6dF0f
68km3TebPYf9Cca6cEQvn96gflcijneTbeKPU2JVClYBHtlnlJgFZjNsdSmsl3qb
m20BRWIyTux/Om7YBEZlGA6JonYQxmbK+LEnLvyTHUgohtYWEP5ED8qv1ncAAwUH
/0kpGlCvzHh1B1CH3Uc/AeUoXihvZM2D0TA887PyFSNAgkZBYyriRt8I7rTuVk4m
XvphOLJvSqoYUX+9kLP0oDWVzBGfKmvFWaoXVjOeP3D/o4r6YxZTVM6NdvSgS+gd
5U45Zg3f2offihvcNFyENjsFyYm2J8iTQb/YZqfb0fOrQNqp2I5HLsQO5rsyaok8
xZfwjjZO1mXvCtPvwNs5KoAzvrCElUXNjG0rigXL9/M4Ewjq3mVcL3K5mlOEg2Rj
qd6HfatZ6Fd00iGt751dHM45OO8+FTF6MD4DFR0+N25fS5PsYqM8Cc87yDdt/6G9
vLyvkPfmperuFuuWvQuR/mCISQQYEQIACQUCREiR6QIbDAAKCRBnMNxOlTPvNRvm
AKDCEGmCqWCdH+f4ZYal1bAXaNF2MwCdFiGKKQq3bxkF1iIlvlbzUs5GKTY=
=e5cb
-----END PGP PUBLIC KEY BLOCK-----
-----Mensaje original-----
De: seguridad-bounces en lacnic.net [mailto:seguridad-bounces en lacnic.net] En
nombre de Nicolás Ruiz
Enviado el: Lunes, 24 de Abril de 2006 08:23 p.m.
Para: Jorge en Messano.com.ar; seguridad en lacnic.net
Asunto: Re: [LACNIC/Seguridad] [Seguridad] Nuevo código de conducta
anti-spam en Australia
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola Jorge:
Jorge F. Messano wrote:
Hola Nicolas,
Respecto de porque no se aplica el filtrado sobre el puerto 80...
La respuesta, paradojicamente, es que en realidad "SI" se aplica... es
el bloqueo de "pop ups".
;-)
Parece un razonamiento tramposo, pero no lo es.
Ahi difiero contigo. Si me parece un razonamiento tramposo... :o)
El problema con comparar el bloqueo de pop-ups (y pop-unders y todos los
otros pops y paps) es que el cliente final tiene el control.
En cambio tanto bloquear el puerto 25 como utilizar DNS es que en ambos caso
no es el cliente el que tiene el control del bloqueo del puerto 25 ni el
control de DNS.
Yo no tendria problema si mi ISP (en mi casa) establece al momento de firmar
el contrato una clausula como "por omisión cerramos el puerto 25 para evitar
spam saliente, si quiere permitirlo, metase en esta URL", que la mayoria de
los usuarios, por flojera, lo va a dejar bloqueado. Y que no me cobre extra
por ello. Pero medidas sobre las cuales no tengo control, no me gustan (como
usuario).
El objetivo del filtrado, tanto de spam como de pop ups, es el de
retirar todo aquello que no pedimos, no solicitamos, nos molesta, nos
invade.
En ese sentido el pop up es tan abusivo y genera tantos riesgos como
el spam.
Ahora bien, en el caso de los "pop ups blocker", el filtrado es
facultad del usuario, no del Service Provider.
Lo mismo deberia ocurrir con el correo electronico.
Lo unico que como ISPs deberiamos hacer es convenir en un marco de
convivencia... de "buenos vecinos"... por el cual podamos controlar la
salida de spam desde nuestras propias redes.
Y respecto del filtrado sobre el spam entrante, desde mi punto de
vista, el mas simple y efectivo es recurrir al DNS como unico "white list"
valido.
Saludos
Jorge
-----Original Message-----
From: seguridad-bounces en lacnic.net
[mailto:seguridad-bounces en lacnic.net] On Behalf Of Nicolás Ruiz
Sent: Saturday, April 22, 2006 4:20 AM
To: seguridad en lacnic.net
Subject: Re: [LACNIC/Seguridad] [Seguridad] Nuevo código de conducta
anti-spam en Australia
Hola Javier:
Webmaster Comtron wrote:
Saliendo un poco de la parte técnica, me parece algo arriesgado
hablar de un "derecho" a conectarte a un puerto determinado en el
otro punto del mundo.
Vale. Use el término "derecho" en un sentido un poco más general.
Efectivamente no es un derecho que me otorgó el divino FSM. Pero si
hay un servidor allá afuera que acepta conexiones al puerto 25, creo
que mi ISP no es la entidad que debe decidir si puedo establecer una
conexión o no. Lo mismo que si es el puerto 21, 22, 23, 80, 119, 123,
443 o cualquier otro.
Por eso, y aunque te suene algo duro mi comentario, tus razones son
atendibles pero tremendamente egoistas.
Porque poner solo "MI" problema como excusa y no considerar el
problema de recibir miles de spam en los usuarios, cientos de gigas
de consumo de ancho de banda inútil, saturación de redes, etc, etc,
no veo que se le pueda poner otro calificativo.
Perfecto. Entiendo tu punto de vista. Por qué no se aplica el mismo
criterio al puerto 80? Que hubiese pasado hace más de 10 años (en el
93-94) si los ISP deciden filtrar el acceso al puerto 80 antes de que
se hiciese popular "porque resulta que los usuarios se estan
consumiendo el 80% del ancho de banda, y casi todo en pornografia". En
aquellos dias se gastaban cientos de megas de consumo de ancho de
banda inutil y ciertamente se saturaban los enlaces.
Te parece que sería egoista el acceder a que los usuarios tuviesen
acceso al puerto 80 cuando solo era una minoria la que lo utilizaba? O
sería miopico?
Dicho sea de paso, ¿alguna solución a la generación de spam desde
cuentas residenciales que no implique filtrar la salida por puerto 25?
Lo mismo se podia decir en aquel entonces de filtrar el puerto 80. Más
de una vez fantasee poder decirle a mis jefes que tenia la solución a
nuestros enlaces saturados.
Obviamente hay diferencias: HTTP era en aquel momento el futuro,
mientras que SMTP es hoy en día más pasado que presente. Y los
clientes SI van a abandonar al ISP que les restringe el puerto 80....
:o)
Saludos
Javier
En fin que mis comentarios no eran para comenzar un "flamefest", sino
precisamente porque esperaba una respuesta en la linea de "es por el
bien de todos". Y a mi la verdad me agobia transitar ese sendero (ojo
que estoy perfectamente consciente de la necesidad de resolver el
problema del spam y que debemos tomar medidas al respecto). Uno sabe
cuando comienza a censurar, pero no cuando termina. Y con las mejores
intenciones se ponen cortapisas a excelentes ideas.
Una de esas ideas que me preocupaba (y todavia me preocupa un poco) es
el futuro de las aplicaciones p2p. Desde mi posición, es una idea
extraordinaria, y me apenaria mucho verla morir porque los ISP deciden
que "es un gasto de ancho de banda, satura los enlaces, solo se usa
para infringir copyrights, etc." Y es por eso que cada vez que se me
ofrece la oportunidad de bajar contenido legitimamente via p2p lo
hago. Para legitimizar su uso.
Pero bueno, suficiente de predicar. Por mi parte regreso a coordinar
activides relacionadas con seguridad con todos uds., como sugiere Raul.
--
Juan Nicolás Ruiz | Corporación Parque Tecnológico de Mérida
Investigación/Desarrollo | Centro de Tecnologias de Información
nicolas en ula.ve | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur
+58-(0)274-240-3889 | La Hechicera, Mérida - Edo. Mérida. Venezuela
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
http://lacnic.net/mailman/listinfo/seguridad
- --
Juan Nicolás Ruiz | Corporación Parque Tecnológico de Mérida
Investigación/Desarrollo | Centro de Tecnologias de Información
nicolas en ula.ve | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur
+58-(0)274-240-3889 | La Hechicera, Mérida - Edo. Mérida. Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETXn3mjsZS9ZBxv8RAkqhAJ0V5jaJqFRdfeZrzf3WLUDTX5YPFwCdGaGO
umorYOXNDsGu75BkzIqoaew=
=+DLV
-----END PGP SIGNATURE-----
_____
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
http://lacnic.net/mailman/listinfo/seguridad
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060425/9e9b4254/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3692 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060425/9e9b4254/attachment.bin>
Más información sobre la lista de distribución Seguridad