Mi newsletter también es tu cliente de correo

Mi newsletter no tiene formulario de suscripción, ni doble opt-in con enlace mágico, ni vive en un servicio de terceros con su píxel de seguimiento. Y sin embargo, cualquier lector puede suscribirse, recibir el boletín y darse de baja cuando quiera. El truco es el mismo que ya usé con los comentarios: el correo electrónico como interfaz de usuario.

Este artículo es la continuación natural de Mi caja de comentarios es tu cliente de correo. Allí convertí un buzón en un sistema de comentarios; hoy lo convertiremos en una newsletter. Mi objetivo no es enseñarte código, sino darte una guía de diseño: las piezas, las decisiones y sus porqués.

Suscripción

La instrucción que ve el lector en mi web cabe en una frase:

Envía un correo a newsletter@andros.dev con el asunto SUBSCRIBE y estás dentro.

Sin cajas de texto, sin captchas, sin páginas de confirmación. Un mailto: con el asunto ya rellenado y su cliente de correo hace el resto.

Por detrás, las piezas ya te sonarán:

Un filtro en el proveedor de correo mueve todo lo que llega a newsletter@ de la bandeja de entrada a la carpeta website/newsletter. Mi buzón personal queda limpio y la carpeta funciona como cola de trabajo.
Una tarea programada lee esa carpeta por IMAP en el intervalo que consideres: esto no es un chat.
Cada correo se convierte en un alta en la base de datos y después se borra del buzón.

Además tiene una ventaja oculta: no tengo la necesidad de enviar un correo de confirmación, ni de mantener un estado de "pendiente de confirmación" en la base de datos. El propio correo de alta es la confirmación. Una solución elegante y simple que evita la complejidad de un doble opt-in y la frustración de un enlace que caduca.

Desuscripción

La baja es simétrica al alta:

Para darte de baja, envía UNSUBSCRIBE a la misma dirección.

Este mecanismo se informa en el pie de cada boletín.

El mismo filtro mueve el correo a la misma carpeta, y la misma tarea lo procesa: si el asunto es UNSUBSCRIBE, elimina la dirección de la base de datos y borra el correo.

Hay una decisión de diseño escondida en la regla anterior: cualquier asunto que no sea exactamente UNSUBSCRIBE se trata como una suscripción. Puede parecer alegre, pero es deliberado. La alternativa sería dejar en la carpeta los correos con asuntos imprevistos ("subscribe", "Suscríbeme, por favor", el asunto vacío de quien pulsó enviar demasiado rápido), acumulando mensajes sin procesar que tendría que revisar a mano. Con esta regla, la carpeta siempre acaba vacía, la intención más probable gana, y el coste del peor caso es mínimo: quien acabe suscrito por error tiene la baja a un correo de distancia, explicada en el pie del primer boletín que reciba.

El envío del boletín

Antes de repartir nada hay que redactar el boletín y decidir cuándo sale. Lo hago escribiéndome un correo a mí mismo. Envío un email a mi propia dirección con el asunto NEWSLETTER, y una tarea programada lo recoge a la hora prevista cada día, toma su cuerpo y lo reparte entre los suscriptores. La primera línea es el asunto del boletín; el resto, el contenido. Después borra el correo, igual que hace con las altas. No hay panel de administración, ni editor, ni un formulario donde pegar el texto: si sé escribir un correo, sé publicar una newsletter. Además, si decido cambiar de idea, solo tengo que borrar el correo y el boletín no sale.

Reutilizo, pues, el buzón y la tarea que ya tenía. La única pieza realmente nueva es el servicio de envío, y con ella una advertencia importante: no envíes el boletín desde tu cuenta de correo personal. Los proveedores convencionales prohíben en sus términos de uso el envío masivo, y con razón: su reputación de entrega es compartida entre todos sus usuarios. Antes de que te des cuenta tendrás la cuenta limitada o suspendida. Para esto existen los servicios de envío masivo o transaccional; cualquiera te vale.

Y precisamente porque cualquiera vale, la clave del diseño no está en cuál elegir, sino en que elegir no importe. El proveedor de envío es un detalle de infraestructura, y los detalles de infraestructura se aíslan detrás de una interfaz mínima. Si mañana el proveedor sube precios, empeora su entrega o simplemente deja de gustarte, escribes otra clase de veinte líneas y el resto del sistema ni se entera.

Respecto a qué opción usar para enviar, si el SMTP o la API del proveedor, mi recomendación es la API. No solo es más sencilla de usar, sino que además suele ofrecer métricas de entrega y errores más precisas que el SMTP. Y encima te deja enviar bloques de correos en paralelo (por ejemplo, puedes enviar a 100 suscriptores de golpe), mientras que el SMTP es secuencial.

El contenido

Mi boletín es texto plano. No es una limitación técnica, es una preferencia meditada:

El texto plano es barato en diseño: no hay plantillas HTML que mantener, ni horas peleando con el motor de renderizado de cada cliente de correo.
No hay imágenes ni recursos que adjuntar o almacenar externamente: el boletín es autocontenido y no pesa nada.
Se lee igual de bien en cualquier cliente: webmail, móvil o terminal. Y sin píxeles de seguimiento, porque no hay dónde esconderlos.

Y aunque el contenido no sea el tema del artículo, tres consejos que me han funcionado:

Ofrece contenido exclusivo: extensiones de tus artículos, ideas que no llegaron a post, material nuevo. Una newsletter que solo repite lo que ya está en el RSS no da razones para seguirla.
Pon fácil la baja: las instrucciones en el pie de cada envío, siempre. Un suscriptor que quiere irse y no puede es peor que un suscriptor menos.
No numeres los boletines: sin "Boletín #47" ganas flexibilidad para crear borradores, descartarlos o reordenar los envíos sin que se note ni debas mantener una contabilidad absurda.

Si algún día es de pago

Un consejo por si decides monetizar tu newsletter, algo que yo de momento no tengo pensado: usa un proveedor especializado donde tus lectores puedan suscribirse y pagar, y deja que sus direcciones se almacenen allí. No voy a dar nombres, son fáciles de encontrar. Cobrar implica pasarelas de pago, facturas, impuestos y disputas, y ese es un negocio en el que no quieres estar tú solo con un script y un cron.

Ese proveedor pasa a ser tu fuente de verdad, y gracias a la abstracción anterior el cambio técnico es menor: la lista de suscriptores deja de leerse de tu base de datos y pasa a leerse de su API. El resto del sistema sobrevive intacto.

Conclusión

Una newsletter completa: altas, bajas y envíos, construida con un buzón, un filtro, un cron y una tabla en la base de datos. Los suscriptores viven en tu dominio y no en el silo de un tercero, la dirección de cada lector llega verificada por construcción, y la única pieza externa, el servicio de envío, está aislada detrás de una interfaz que la convierte en reemplazable. El correo electrónico lleva cincuenta años siendo el sistema de suscripción más universal que existe; lo único que he hecho es dejar de estorbarle.

Si montas algo parecido, me encantará saberlo. Y si quieres verlo funcionar desde el lado del lector, ya sabes: SUBSCRIBE.