No responda este mensaje...

Muchos de nosotros recibimos notificaciones y mensajes de los servicios de Internet que utilizamos. Estos mensajes nos son enviado en forma automática, y el remitente del mismo usualmente es una dirección inexistente tal como noresponder@dominio.com o noreply@dominio.com, entre otras tantas opciones.

Es una práctica muy común cuya intención es que el destinatario comprenda que no debe responder al mensaje, además de eviar recibir muchas notificaciones de rebotes de correo (p.e. por direcciones de destino inexistentes) en alguna casilla real.

Más allá de eso, muchos usuarios desconocen de esto y por ende, responden a los mensajes a esas inexistentes direcciones. En la mayoría de los casos, dicha dirección simplemente no recibe mensajes, por lo que la respuesta del destintario, se pierde.

Ahora, ¿qué pasa cuando no se usan direcciones de un dominio propio de la fuente del mensaje? Si observan las direcciones de ejemplo que puse más arriba, verán que las mismas corresponden a un sitio (dominio.com) que existe pero no está en uso. Si enviamos un mensaje de correo allí, no sabremos realmente quien lo recibirá o si alguien realmente lo verá o no.

Sobre este caso hay un interesante, y extraño, post en el blog de seguridad del Washington Post, llevado adelante por Brian Krebs, el cual nos trae una entrevista al dueño del dominio donotreply.com (en español, no responder . com).

Parece ser que varias empresas y negocios de Estados Unidos envian notificaciones a sus usuarios y clientes usando una dirección con ese dominio como remitente. No lo hacen con ninguna intención, en teoría, sino que lo hacen para que quede claro al destinatario que no debe responder... pero mucha gente lo hace igual y quien recibe esas respuestas no son las empresas que envian el mensaje sino Chet Faliszek, el dueño del dominio donotreply.com.

Chet ha recibido muchas cosas que deberían no haber sido enviadas a desconocidos (documentación confidencial, por ejemplo) debido a que algunas empresas y financieras hacen envios a sus clients poniendo una dirección con su dominio como remitente.

Más en Security Fix, el blog sobre seguridad del Washington Post:
http://blog.washingtonpost.com/securityfix/2008/03/they_told_you_not_to_reply.html

La culpa no la tiene Chet, sino los administradores de esas empresas y financieras que deberían usar una dirección de correo que controlen como remitente, en lugar de una de un dominio existente.

Para clarificar un poco el tema, les dejo este simple gráfico:

Esto funciona así:

1. Nosotros recibimos una notificación desde una empresa que utilizamos normalmente llamada suservicio.com.
2. Al recibirlo, respondemos al mensaje para hacer alguna consulta a dicha empresa o para enviarles información porque nos la solicitan.
3. Dado que dicha empresa usa una dirección @donotreply.com en lugar de una @suservicio.com como remitente de la notificación cuando nosotros respondemos, no lo hacemos a la empresa, sino al servidor de Chet
4. Chet entonces recibe nuestra respuesta y no la empresa

Este tema no es tan peligroso como parece pero si muestra dos claras malas costumbres:

• Las empresas deben ser más cuidadosas con los envios que hacen a sus clientes. Las direcciones de remitente de las notificaciones que envien deben ser cuentas en dominios que controlen adecuadamente y no inventadas y sin verificación
• Los usuarios tenemos la mala costubre de no leer correctamente todo el contenido del mensaje. Normalmente, esas notificaciones le dan al destinatario información de cómo es la forma correcta de comunicarse con el servicio pero el mismo no presta atención y responde igual, enviando el mensaje a direcciones que no conoce

Interesante caso para ilustrar que los usuarios debemos ser más responsables con lo que hacemos y prestar atención a los mensajes que recibimos.

"is"

NOTA AL PIE: dominio.com y noresponder.com son dos dominios que actualmente no muestran ninguna página ni servicio en particular; suservicio.com es el sitio de una empresa existente cuyo dominio se utilizó solamente para ejemplificar el caso en cuestión y no tiene ninguna relación con lo comentado en este post.