Hace unas semanas recogí mi primera camisa “made in Boden”. Para los que no la conozcan, Boden es una camisería con un proceso de producción que permite tener camisas a medida con precios similares a las pret-a-porter. Además, las medidas de los clientes quedan registradas en su base de datos lo que facilita las siguientes compras, incluso pudiéndolas hacer por internet.
Días antes recibí un mail en el que me avisaban que mi camisa estaba lista y me invitaban a pasar a retirarla. Este mail apareció marcado como spam en mi cuenta Gmail.
Cuando en Chilevisión abrimos nuestro sitio web al registro de usuarios, descubrimos que un pequeño número de ellos no era capaz de completar el proceso porque no recibía el correo de confirmación que nuestro sistema le enviaba. Como todos vosotros habréis experimentado, este procedimiento de registro es el habitual en cualquier sitio web y nos sirve para verificar que el correo electrónico de quien se registra es correcto y que, efectivamente, su propietario quiere registrarse en nuestro sitio.
Cuando comenzamos con el desarrollo de la red social MITIU.com nos tomamos muy en serio este problema. En chilevision.cl podemos subsistir con un pequeño porcentaje de errores en el registro de usuarios e incluso podemos gestionarlos manualmente advirtiendo en el proceso de registro a nuestros futuros usuarios de esta posibilidad. Pero en una red social el registro de usuarios y la comunicación con ellos mediante el email son procesos claves, así que decidimos afrontarlos.
Para la gestión de la cuentas de correo @mitiu.com optamos por utilizar la robusta, amigable y gratuita plataforma Gmail. Las tareas de mantenimiento son inexistentes: todo lo que un usuario puede necesitar, como el cambio o la recupración de claves, es “do it yourself”. La única limitación la encontramos en el número de mensajes que un usuario puede enviar al día: 500. Este número es suficiente para un usuario normal, pero no para la gestión de los correos generados por una red social. A los enviados para la creación de nuevas cuantas hay que añadir los que informan sobre la actividad de la red. Para procesar estos mensajes necesitábamos nuestro propio servidor de correo.
Optamos por qmail por su sencillez y seguridad. Una vez instalado, lo configuramos para que sólo enviase correos originados en MITIU.com. Finalmente ajustamos el registro SPF de nuestro DNS.
Las primeras pruebas las realicé con la ayuda de Nacho y sus herramientas de análisis de spam y DNS. Todo parecía ir bien hasta que detecté que ningún correo enviado a cuentas de Yahoo! era admitido por sus servidores de correo. MITIU.com se encuentra alojado en la “nube” de Amazon y ningún correo proveniente de dicha plataforma es bienvenido, al menos, por los servidores de Yahoo!
Este es un problema que Amazon aún no ha resuelto: cualquiera con una tarjeta de crédito puede poner en marcha una máquina en su “nube” en cuestión de minutos y utilizarla para un envío masivo. O peor aún, la gran cantidad de máquinas corriendo en la “nube”, muchas de ellas sólo para pruebas y no configuradas de manera segura, hacen de Amazon un apetitoso objetivo para los spammers que "abusan" de sistemas de terceros cuando realizan sus envíos. La solución adoptada por Yahoo!: no permitir ningún mail cuyo origen sea Amazon.
Descartado nuestro propio servidor, el siguiente paso fue encontrar un proveedor de servicios de correo fiable y con la suficiente reputación como para confiarle todo el tráfico de emails generado por nuestra aplicación. Lo habitual es encontrar proveedores que ponen a disposición de todos sus clientes un servidor de correo. La capacidad de envío está garantizada pero la fiabilidad... Se corre el riesgo de que un mal uso del servicio por parte de un cliente afecte a la reputación de los correos enviados por el resto y sin arte ni parte encontrarte con tu servidor de correo en una lista negra.
La empresa Sailthru ofrece un servicio, triggermail, orientado a evitar esta situación. A diferencia de los descritos anteriormente, triggermail no da acceso directo a un servidor de correo. Los envíos se realizan accediendo a un servicio web. Todo mail que salga desde su aplicación debe incluir un texto y un enlace que permita al receptor avisar de que no quiere recibir más correos del remitente. Este enlace apunta a la plataforma de triggermail, que procesa la petición e informa a la aplicación remitente del mensaje. Si por error o mala intención mi aplicación trata de enviar un mensaje a un usuario que indicó que no quería saber nada más de mí, triggermail no lo enviará. De esta forma triggermail cuida de los destinatarios de los mensajes que salen desde su plataforma, protegiendo la reputación de la misma evitando caer en una lista negra. A su vez, cuida a sus clientes de posibles errores o usos indebidos realizados por otros clientes.
El servicio, además, permite priorizar unos mensajes sobre otros para el hipotético caso de que nos encontrásemos con saturación en el servicio. En el caso de MITIU.com, por ejemplo, las invitaciones que envían los usuarios registrados a sus amigos tienen una prioridad mucho menor que los mensajes de verificación de mail que se envían en el proceso de registro. También es de destacar el completo sistema de estadísticas con información sobre número de mensajes enviados, avisos de spam, rebotes producidos por direcciones erróneas, casillas de correo con problemas,... Un último detalle a destacar: para su contratación realizan una serie de comprobaciones "manuales" con idea de conocer quién es su nuevo cliente.
Aunque lo habitual sea ver el spam como un problema del receptor, quienes queremos comunicarnos por mail con nuestros usuarios de manera lícita tenemos que hilar muy fino con nuestros desarrollos si no queremos ser confundidos con él.
