Boletín eListas, Publicación mensual sobre listas de correo y foros en español 1 de Septiembre, 2000
Número 11

Este boletín se envía únicamente a aquellos que lo han solicitado. Si deseas cancelar tu suscripción al boletín eListas, sigue las instrucciones al final de este mensaje, o accede a tu cuenta en eListas, y modifica tus preferencias desde la página Mis eListas

EDITORIAL 
adv@corp.eListas.com

Bienvenido a una nueva edición del Boletín eListas.

Tras tres meses sin emitir nuestro boletín, se nos han juntado tantas cosas a contar que acabamos con un boletín enorme. Hemos tenido que eliminar algunos artículos, y aunque parezca mentira, recortado otros.

Para evitar esta situación en boletines venideros, estamos trabajando en un nuevo formato para el boletín que estrenaremos el mes que viene y que esperamos os guste.

Como siempre, estamos abiertos a tus comentarios, sugerencias y críticas en la dirección adv@corp.eListas.com.

SUMARIO 

NOVEDADES EN ELISTAS 
art@corp.eListas.com

En eListas no paramos - literalmente. Estos últimos tres meses hemos implementado cientos de pequeñas mejoras aquí y allá, optimizaciones, nuevas funciones y servicios. Más que detallar todas las mejoras realizadas, hemos decidido comentar en detalle las novedades más significativas en el área de servicios.


 

¿SE PIERDE EL CORREO ELECTRONICO? 
Parte 1 - Rechazando mensajes legítimos
rba@corp.eListas.com

El correo electrónico no es infalible. Eso no es novedad, ya que no hay nada perfecto en este mundo. Ahora bien, se tiene la creencia de que cuando algo falla en la transmisión de un mensaje de correo electrónico, como mínimo el remitente del mensaje fallido recibirá un aviso de que algo fue mal. Bueno, puedes ir olvidándote del asunto. En la Internet de hoy se pierden muchos mensajes de correo. Demasiados. Y no debería ser así.

En este boletín iniciamos una serie de artículos que irán explicando muchas de las causas que provocan la pérdida de un mensaje de correo que legítimamente debería haber llegado a su destinatario, en muchos casos, sin que el destinatario - y en ocasiones ni el remitente del mensaje - lleguen a saberlo.

Podemos hablar de varias razones generales por la cual un mensaje acaba perdido sin llegar a su destinatario:

En este boletín hablaremos de un fallo muy común entre administradores de servidores de correo, que caería en el último apartado - Métodos anti-spam que no son tales.
Servidores que rechazan mensajes con un Return-Path nulo 

En ocasiones, un administrador de un servidor de correo hace cosas con muy buenas intenciones, cuando en realidad, más que aliviar un problema, ha creado otros mucho más serios. Pongamos como ejemplo más característico el bloqueo de determinados mensajes por contener lo que se conoce como un envelope sender nulo o vacío.

¡Hay que aceptar Return-Path nulos!

El envelope sender de un mensaje es la dirección utilizada por nuestro servidor de correo para identificarse cuando contacta con el servidor de correo remoto para enviar el mensaje. Este dato es también conocido como el Return-Path o el MAIL FROM de un mensaje de correo. Aunque generalmente el envelope sender de un mensaje suele ser la misma dirección que la del remitente del mensaje (la dirección que aparece en el campo From:), no siempre es así, y en ocasiones, los servidores de correo emitirán mensajes que, a pesar de identificar al remitente del mensaje en la cabecera (campo From), utilizarán un envelope sender nulo o vacío. Sin entrar en detalles, esto se puede hacer por diferentes razones, y en cualquier caso, muy legítimas todas ellas.

Por ejemplo, eListas utiliza direcciones especiales en los Return-Path para poder gestionar rebotes, mensajes de error, etc.

Últimamente sin embargo se ha puesto de moda entre algunos administradores de correo el bloquear mensajes que contengan un envelope sender nulo o vacío, con la pretensión de evitar spam.

¡MAL HECHO!

¿Mal hecho? ¿Pero es realmente válido el enviar mensajes con este campo vacío? Por supuesto. Aparte de estar claramente especificado en los documentos que definen el envío de mensajes (consultar apartado 3.2 del RFC 2476 en http://www.cis.ohio-state.edu/rfc/rfc2476.txt, al principio de la página 5), la gran mayoría de servidores de correo en Internet saben bien que deben aceptarlos, ya que en caso contrario se arriesgan a dejar a sus usuarios sin recibir algunos mensajes de correo legítimos - cosa nada deseable.

Pues algunos administradores han decidido que si rechazan los mensajes que contengan un envelope sender nulo, le hacen un favor muy grande a sus usuarios evitándoles spam. Lo cierto es que mientras que quizás les evitan un spam o dos al mes (a un spammer le cuesta el mismo trabajo el enviar un mensaje con o sin envelope sender) , les han podido dejar sin recibir una docena o más de mensajes legítimos que deberían haber recibido. Este es un fallo muy serio que algunos administradores no terminan de entender.

Curiosamente, ninguna organización anti-spam como pueda ser CAUCE o Mail-Abuse.Org recomienda este método, principalmente porque más que una protección, es una equivocación. De hecho, el RFC 2505 (Recomendaciones anti-spam para servidores de correo SMTP) mientras que recomienda verificar el dominio del envelope sender si existe, no menciona en ningún caso el rechazar mensajes que contengan dicho campo vacío.

Como muestra, algunos de los servidores de correo que hemos observado en alguna ocasión rechazando mensajes con un envelope sender vacío (es decir, que no respetan el punto 3.2 del RFC 2476) son: 24horas.com, e-milio.com, ciudadfutura.com, comnet.com.ar, cordoba.com.ar, argensoft.com.ar, interlap.com.ar, cipel.ispjae.edu.cu, coopenet.com.ar, noanet.com.ar, reskarendaya.com, geo.net.co, reduruguaya.com, winnernet.com.ar, abaforum.es y aida.usal.es. Como siempre, no están todos los que son, pero...

¿Cómo detectar quién no los acepta?

Como usuario de un servidor de correo en particular, la mejor manera de averiguarlo es preguntándole a los encargados. Algo así como - Me han informado que algunos servidores de correo rechazan mensajes con un Return-Path nulo, siendo ésta una práctica que puede resultar en el rechazo de mensajes legítimos. ¿Podríais por favor decirme si vuestros servidores de correo - los que gestionan mi cuenta abc@abc.abc - aceptan mensajes con un Return-Path nulo?

Si eres administrador de una lista en eListas y observas que los servidores de correo de algunos miembros de tu lista están rebotando mensajes, y observas que la causa del rebote es un error parecido a alguno de los siguientes:

501 bogus mail from
501 Invalid From
501 <>... Sender user must exist
554 buildaddr: no host
Ya sabes que estás tratando con un servidor de correo que utiliza un criterio equivocado a la hora de rechazar estos mensajes.

¿Cuando envía eListas mensajes con un Return-Path nulo?

eListas envía mensajes con un Return-Path nulo cuando ha de responder a determinadas acciones de un usuario que han producido algún error. Esto se hace entre otras cosas para evitar que se cree un círculo o loop de mensajes de error en casos que el destinatario tenga activado un autoresponder o mensaje de vacaciones automático. Es una técnica usada por muchísimos servidores de correo y recomendada por sus administradores.

Por ejemplo, si pepe@usuario1.com envía un mensaje a una lista a la que no se le permite enviar mensajes, eListas responderá con un mensaje con un Return-Path nulo, tipo

Hola. Soy el servidor de correo de eListas.net.
El mensaje que enviaste a la siguiente dirección ha sido rechazado:
...

eListas no va a dejar de utilizar estas especificaciones de Internet porque a unos pocos se les ocurra no respetarlas. Lo correcto es que se apliquen y lo corrijan ellos. Y si la "razón" es el evitar spam, quizás debieran preguntarle a sus usuarios si están dispuestos a perder mensajes legítimos por ello, no ya de eListas sino de muchos otros servidores.

Al final, cada uno hace lo que quiere, y en algunos casos, por políticas internas (en nuestra opinión mal fundadas) podría ser permisible, pero si estás ofreciendo un servicio de correo electrónico en Internet a tus usuarios o clientes, deberías hacer lo que hace la gran mayoría de los servidores de correo en Internet, es decir, aceptar estos mensajes y combatir el spam mediante métodos que en ningún caso dejen a un usuario sin recibir un mensaje legítimo.
 

EGROUPS, SU HISTORIA 
rba@corp.eListas.com

Este verano, Yahoo! sorprendió a muchos anunciando que había decidido comprar eGroups Inc., una compañía de San Francisco para muchos desconocida, por la respetable cantidad de 400 millones de dólares en acciones. Lo curioso es que hace no mucho más de un año, apenas nadie conocía a esta empresa, llamada eGroups, e incluso cuando Yahoo! anunció la adquisición, muchos inversores admitieron no haber oído hablar de ellos hasta ese momento.

Y muchos de los que por el contrario sí conocen a eGroups desde incluso meses antes de que adquiriesen su rival ONElist a finales de 1999, realmente tampoco conocen mucho del pasado de la vida de esta empresa, cómo surgió, y en definitiva, su historia - desde los días del "garaje" hasta formar parte de la historia de la empresa más representativa de la era Internet hasta el momento, Yahoo!

eGroups fue fundada en 1998 por Scott Hassan, pero hay que remontarse dos años antes, a 1996 para realmente conocer las raíces de su creación.

La prehistoria

A principios de 1996, Scott, hábil programador, mientras trabajaba para Alexa Internet (ahora conocidos por su herramienta "Sitios Relacionados" incorporada en el Netscape Communicator), desarrolló por su cuenta un sencillo entorno web para la gestión de listas de correo, usando el lenguaje Python bajo Linux corriendo Apache. Eso que sirva de escarmiento a aquellos que no creen que es posible montar un negocion con software libre :-)

En poco tiempo Scott consiguió la financiación necesaria para empujar su proyecto, fundando la empresa FindMail Inc. (escribe www.findmail.com en tu navegador y observa donde acabas) y rápidamente se convirtió en uno de los mayores archivos de listas de debate en Internet en aquel momento.

Convertir a FindMail en eGroups supuso un cambio estratégico en la historia de la empresa. Hasta el momento, FindMail había sido una herramienta útil para los usuarios de la entonces emergente Internet, y un proyecto interesante para sus creadores. La principal motivación de Scott y sus colaboradores era la de mejorar su plataforma de FindMail para que dicho producto y servicios fuesen competitivos, capaces y de buena calidad.

Con el cambio a eGroups en 1998 y un agresivo cuerpo directivo a su frente que obtuvo fuertes rondas de financiación, la meta pasó a ser "engordar al pollo". Al tener la fórmula de crecimiento de este tipo de servicios un carácter tan virulento (propagación exponencial), eGroups apenas necesitó gastar en publicidad. El empuje inicial de FindMail, adquirido a base de esfuerzo y buen hacer fue suficiente para poner en marcha la máquina. Sin embargo, eGroups no estaba solo en este nicho. Aunque en total se puede hablar de una docena escasa de sitios, principalmente tres se destacaban como rivales, y de esos tres, uno con una diferencia abrumadora, ONElist.

Si la competencia es mejor y barata, ¡cómprala!

ONElist poseía todo lo que eGroups - un pasado consolidado que le había proporcionado una numerosa y leal base de usuarios, un juego de herramientas sofisticado para los administradores de listas, un sistema de distribución rápido y curiosamente, muy similar al de eGroups. Pero, aparte de los millones de usuarios - prácticamente a par con los de eGroups - ONElist contaba con un arma que casi les declaraba campeones anticipados en la guerra por el liderazgo en este campo.

eGroups, a través de diversas rondas de financiación, había conseguido abrir oficinas en Japón y Alemania, ambos ofreciendo los servicios de eGroups en sus respectivos lenguajes, pero su software no había sido originalmente diseñado para ser localizado y presentado en otros idiomas con facilidad.

ONElist sin embargo contaba con un sistema técnicamente internacionalizado y capacitado para ser fácilmente localizado a otros idiomas, y de hecho, a mediados de 1999 ya ofrecía sus servicios en una docena de idiomas, habiendo gastado en el proceso mucho menos dinero que eGroups en desarrollar y lanzar sus individuales aventuras alemana y japonesa. Por tanto, en el campo global de Internet, ONElist le sacaba a eGroups no una sino varias cabezas.

Y si ONElist tenía en teoría la batalla ganada en el aspecto global de Internet, ¿porqué dejarse comprar por una empresa técnicamente inferior? La respuesta posiblemente esté en la experiencia del equipo directivo de eGroups contra la del equipo de ONElist.

Y es por eso que a nadie debería de extrañarle que tras la fusión de ambas empresas, quedase la tecnología de ONElist y el nombre de eGroups. Los años de trabajo y esfuerzo de Scott habían conseguido levantar un nombre, eGroups, pero el producto ya no era el mismo, sino un producto que, bueno, estaba mejor hecho que el suyo. De los años del buen hacer y del "garaje" no quedaba ya ni el nombre original de la aventura.

Si se te escapa de las manos ¡véndelo!

Con la adquisición de ONElist, eGroups había duplicado de la noche a la mañana el número de usuarios registrados. Gracias precisamente a estos usuarios que buscaban como es lógico aumentar el número de suscriptores a sus propias listas, eGroups continuaba creciendo a un ritmo como solo los grandes como Yahoo! o eBay experimentaron en su día.

Con semejante carruaje, eGroups necesitaba más caballos no ya para continuar creciendo sino incluso para mantener lo que ya llevaba a sus espaldas. No solo su soporte técnico al usuario se convirtió en el desgraciadamente típico "24/7 significa que has de escribirles 24 veces para que te respondan a los 7 días", sino que la empresa continuaba perdiendo dinero. ¿Qué hace la empresa típica americana de Internet cuando pierde dinero? ¡Pedir más dinero!

Una vez en la cima y lejos del siguiente competidor, la búsqueda del pelotazo se hizo inminente. En la primavera de este año, eGroups planeó lanzarse a bolsa por un valor de 75 millones de dólares. Sin embargo, las condiciones adversas del mercado les pusieron rápidamente en retirada. Y sin ninguna solución en camino, cuando Yahoo! llamó a la puerta (o al revés, sinceramente no sabemos quién dio el primer paso) con 400 millones de dólares, yo creo que no se lo tuvieron que pensar mucho.

Y así acaba - por el momento, ya que la integración de los servicios aún no ha empezado - la historia de esta empresa. Parida en 1996 con la saludable idiosincrasia de Internet del momento, lanzada en 1998 como operación adquisitiva de usuarios y tráfico, y vendida a una de las mayores empresas de Internet en el 2000, eGroups nos deja la historia de una empresa que creció en la oscuridad y fuera del radar de aquellos que buscaban por su cuenta dar con una fórmula de éxito en Internet. La efímera gloria de eGroups no ha sido la oportunidad sino la ejecución.

¿Qué ocurrirá cuando Yahoo! termine de integrar a eGroups en su cuartel? El tiempo lo dirá, pero en general cuando un servicio deja de ser el alma principal de una empresa, y pasa a ser un servicio añadido, lo que gana de forma global, lo pierde en especialización. Y las listas de correo son un instrumento de comunicación muy especial y que hay que cuidar. Es misión de todos - y ahora de Yahoo! también - el asegurarnos de que continúe siéndolo.
 

¿CUAL ES EL MÉTODO MÁS EFECTIVO CONTRA EL UCE/SPAM? 
rba@corp.eListas.com

Métodos para combatir el spam hay muchos, y ninguno de ellos es del todo infalible. En tan solo unos párrafos te indicamos la solución más efectiva - y de ti depende llevarla a cabo o no.

Tanto a nivel del servidor de correo como de nuestro propio gestor de correo (Outlook, Eudora, Netscape, etc.), existen muchas y variadas soluciones para reducir la cantidad de spam recibido, en la mayoría de los casos mediante un filtrado de mensajes basado en el contenido de los mismos. El problema es que estos filtros en ocasiones pueden llegar a rechazar un mensaje legítimo, situación nada deseable, por mucho spam que supuestamente nos pueda quitar de encima.

Por otro lado tenemos el filtrado por dirección, es decir, bloquear direcciones de correo conocidas de haber enviado spam. Este método presenta una protección relativamente efímera contra el spam, ya que los spammers más hábiles procuran no mantener la misma dirección durante mucho tiempo - en ocasiones les es incluso imposible ya que les cancelan las cuentas al poco de realizar sus primeros envíos. En ocasiones sin embargo sí protege, con el aliciente de que no corres el riesgo de filtrar un mensaje legítimo, ya que si el dueño de tal dirección ha sido cazado previamente enviando spam, posiblemente merezca la pena mantenerlo fuera de nuestro buzón.

Otras prácticas menos comunes pero eficaces contra spammers poco habilidosos (o que se pasen de listos, según se mire) son por ejemplo la comprobación de que el dominio del remitente existe realmente - es decir, que el remitente no se identifica como abc@hd89s7d7dg.commm o algo parecido.

Sin embargo, la mejor manera de combatir el spam es denunciándolo a organizaciones como mail-abuse.org, spam.abuse.net o spamcop.net. No nos proporciona resultados directos e inmediatos, pero esta lucha no se puede ganar abarcando tan solo nuestro propio dominio. Cierto es que en la mayoría de los casos, nuestro interés es el evitar que nuestro buzón se llene con basura, así como el de proteger a nuestros usuarios, pero el spam es un problema global de la red, y cada aportación y contribución por su causa es importante.

De enviar tu queja a los sitios mencionados - no olvides enviar una copia íntegra del spam con los encabezados completos - éstos se encargarán de enviar copias de la denuncia a los encargados del servidor de correo, así como a los encargados de cualquier proveedor de acceso que se sitúe sobre ellos. Algunas organizaciones como mail-abuse.org en ocasiones incluyen los servidores de correo que enviaron el spam en su lista RBL (una especie de lista negra), utilizada por empresas dueñas de muchos de los nodos más importantes de Internet a nivel mundial, que bloquearán el tráfico a cualquiera que aparezca en esta lista negra. Ya le sucedió a Terra/Teleline, con todos sus millones e influencias hace unos pocos meses, debido a una única queja de un usuario por recibir un breve spam emitido desde Teleline. Y en menos de 3 días los miles de usuarios de Teleline se encontraron con su correo parcialmente bloqueado.

Esto no evita que nadie vuelva a intentar enviar spam utilizando los servidores de Teleline o de cualquier otra empresa, pero sí contribuye a que estas empresas actúen rápidamente contra los spammers y no les den carta blanca. Mientras que organizaciones como CAUCE buscan soluciones legislativas al asunto, recuerda que es casi tan sencillo el reenviar el spam a los encargados del servidor que lo envió y a sitios como spamcop.net que pulsar la tecla "borrar". ¡Quéjate! Automatiza el proceso para que no te suponga ninguna pérdida de tiempo. La alternativa es ser pasivo, continuar dándole a la tecla "borrar" y dejar que sean otros los que hagan algo. Como dijimos al principio, de ti depende.

Recuerda igualmente que lo primero que hacen estos sitios es ponerse en contacto con los encargados del servidor de correo que envió el spam así como de servicios anunciados en dichos mensajes spam, por lo que si sabes a priori que estos encargados pertenecen a una empresa con un activo programa anti-spam, como es por ejemplo el caso de eListas, puede resultar más eficaz el dirigir tus quejas a los encargados directamente en vez de reportarlos a SpamCop o abuse.net, aunque en caso de duda, dirígete directamente a estos sitios.
 

RINCÓN DEL ADMINISTRADOR 
art@corp.eListas.com

En esta edición del Boletín eListas iniciamos una sección con pistas, trucos y curiosidades de interés para los administradores de listas en eListas

¿Sabías que...

¿Comentarios? Comunícate con nosotros enviando un mensaje a adv@corp.eListas.com

http://www.eListas.net/
Una publicación de Blabia Inc.
Copyright © 1999-2008 Blabia Inc., Todos los derechos reservados