registeraddress para TYPO3

El registro de newsletter sin servicios externos ahorra costes y mantiene los datos bajo control propio

Mailchimp, Brevo, rapidmail: por cada registro en el newsletter, las organizaciones pagan por suscriptor y por correo enviado. Con 10.000 abonados, eso se va a entre 100 y 300 euros mensuales solo por la administración de direcciones. registeraddress ofrece una alternativa: registro de newsletter directamente en TYPO3 a través de la ya probada tabla tt_address. La gestión de suscriptores, el Double-Opt-In, el enlace de baja y la documentación de consentimiento conforme al RGPD corren íntegramente en el CMS, sin que un servicio externo tenga acceso a los datos de los abonados.

Para asociaciones, editoriales pequeñas e instituciones públicas con restricciones presupuestarias, es una arquitectura válida, sobre todo si el envío del newsletter se realiza a través de un servicio SMTP económico como Amazon SES (0,10 dólares por cada 1.000 correos) o del propio servidor de correo. Para la AEPD y el cumplimiento del RGPD, la ventaja es clara: no hay transferencia de datos a un proveedor externo que haya que documentar en el registro de actividades de tratamiento.

Los escenarios típicos abarcan newsletters de asociaciones, listas de intranet e inscripciones a eventos

El escenario más frecuente es el clásico newsletter de asociación. Un club deportivo con 2.000 socios ofrece un formulario de alta en su web TYPO3. Los visitantes introducen su dirección de correo, reciben un correo Double-Opt-In, confirman y pasan a la tabla tt_address. La asociación envía mensualmente un newsletter vía la extensión direct_mail o un servicio de envío externo que importa las direcciones desde tt_address. registeraddress se ocupa exclusivamente del registro y de la baja, no del envío en sí.

Un segundo escenario son las listas de distribución en intranets corporativas. Los empleados se apuntan a newsletters informativos internos, como “Sede de Madrid - menú de cantina” o “Ventanas de mantenimiento de TI”. Como los datos no pueden salir de la red corporativa, un servicio de newsletter externo queda descartado. registeraddress gestiona las altas localmente en la base de datos de TYPO3.

Tercer escenario: inscripciones a eventos con confirmación por email. Una biblioteca ofrece actividades y utiliza registeraddress como formulario de inscripción ligero. El correo de confirmación tras el Double-Opt-In incluye fecha, hora y lugar de la actividad. No es una solución de gestión de eventos completa, pero para entidades con cinco a diez actividades al mes resulta suficiente.

La arquitectura técnica se apoya en tt_address y el flujo Double-Opt-In

registeraddress está implementada como plugin Extbase y utiliza la tabla tt_address como base de datos. Cada registro pasa por un proceso en tres pasos: entrada en el formulario, correo Double-Opt-In con enlace de confirmación, activación del registro tras el clic en el enlace. El enlace de confirmación contiene un token firmado criptográficamente que expira tras un plazo configurable (por defecto: 48 horas).

La extensión registra un plugin de frontend que se configura vía TypoScript: campos obligatorios, campos opcionales (nombre, empresa, tratamiento), texto de confirmación, plantillas de correo para el Double-Opt-In y la bienvenida. Las plantillas Fluid son sobrescribibles vía SiteSet para que el formulario encaje en el diseño de la web.

Para el cumplimiento del RGPD, registeraddress almacena el momento del consentimiento, la dirección IP, el user agent y la versión de la política de privacidad a la que se enlazó desde el formulario. Ante una consulta de la AEPD, se puede demostrar cuándo y bajo qué condiciones el suscriptor dio su consentimiento.

Las bajas se gestionan a través de un enlace en el pie del newsletter que desactiva (no elimina) el registro tt_address, de modo que el historial de consentimiento se conserva. Las supresiones definitivas conforme al artículo 17 del RGPD (derecho de supresión) se pueden realizar mediante un formulario de eliminación separado o manualmente desde el backend.

Los problemas frecuentes son los Double-Opt-In en spam y las versiones antiguas de tt_address

El problema dominante es la entregabilidad del correo Double-Opt-In. Si el correo de confirmación acaba en la carpeta de spam, el suscriptor nunca completa el registro. Las causas están casi siempre en el servidor: falta de registro SPF, ausencia de firma DKIM, ausencia de política DMARC. registeraddress en sí no puede mejorar la entregabilidad, porque es un tema del servidor de correo. Recomendamos comprobar la autenticación del correo antes del lanzamiento de un formulario de newsletter con mail-tester.com.

Segundo problema: incompatibilidad con versiones antiguas de tt_address. registeraddress se apoya en ciertos campos de la tabla tt_address. Si tt_address publica una actualización mayor y renombra o retira campos, registeraddress ya no puede escribir correctamente los registros. La solución: actualizar tt_address y registeraddress siempre de forma conjunta y realizar tras la actualización una prueba completa del flujo de registro.

Tercer tema: registros de bots. Sin un mecanismo de protección, los bots rellenan el formulario con direcciones falsas y generan miles de correos Double-Opt-In que sobrecargan el servidor y dañan la reputación del remitente. registeraddress soporta campos honeypot y se puede combinar con sr_freecap o hcaptcha para repeler bots. hcaptcha tiene además la ventaja de alojarse en servidores europeos, lo que simplifica el encaje con el RGPD frente a reCAPTCHA de Google.

TYPO3 v12 está soportado, la compatibilidad con v13 requiere alineamiento con tt_address

registeraddress corre estable en TYPO3 v11 y v12, siempre que tt_address esté instalada en una versión compatible. Para TYPO3 v13 la compatibilidad depende tanto de registeraddress como de tt_address, ya que ambas extensiones se mantienen de forma independiente. Gosign revisa en los upgrades de TYPO3 toda la cadena del newsletter (registro, gestión de direcciones, envío) en cuanto a compatibilidad y recomienda, si es necesario, pasar a un servicio de newsletter externo con conexión API cuando la solución TYPO3 nativa deje de mantenerse.