Sí, yo también odio los formularios de correo. Esos pequeños recuadros que aparecen en las páginas web y que nos invitan a escribir nuestro nombre, nuestra dirección de correo electrónico y un mensaje, para finalmente pulsar un botón que dice «Enviar». Parece sencillo, ¿verdad?
Pues no. Es una de esas pequeñas maravillas de la informática moderna que consiguen convertir una tarea elemental en una aventura tecnológica de proporciones épicas. Y la culpa de su existencia es el spam, obviamente.
Llevo décadas administrando páginas web y he perdido la cuenta de las horas dedicadas a configurar, reparar y volver a reparar formularios de contacto. Lo más desesperante es que, cuando finalmente consigues que funcionen, no tienes ninguna garantía de que sigan funcionando dentro de seis meses. De hecho, pueden dejar de funcionar sin que te enteres, y durante meses puedes estar perdiendo mensajes sin tener la menor sospecha.
La extraordinaria complejidad de enviar un simple mensaje
Imaginemos que alguien visita mi página web porque está interesado en uno de mis proyectos y quiere colaborar, hacer una propuesta o simplemente plantearme una pregunta. Escribe un mensaje cuidadosamente redactado, introduce su correo electrónico y pulsa «Enviar». La página responde: «Su mensaje ha sido enviado correctamente». Perfecto, el visitante se marcha satisfecho, pero puede que yo nunca reciba nada.
¿Cómo es posible? Pues porque detrás de ese aparentemente inocente botón hay una cantidad sorprendente de mecanismos que deben funcionar correctamente y que, en muchos casos, dependen de sistemas y organizaciones diferentes.
He elaborado un inventario de 74 posibles fallos relacionados con los formularios de correo de WordPress. No pretendo que sea una lista exhaustiva ni que todos los fallos sean igual de frecuentes, pero el número ilustra hasta qué punto algo aparentemente trivial puede depender de numerosos sistemas. Vamos a recorrer algunos de ellos.
Primera estación: el propio formulario
Para empezar, el formulario puede estar construido mediante un plugin de WordPress, y ese plugin puede estar mal configurado, desactualizado o ser incompatible con la versión actual de WordPress o PHP. También puede haber dejado de recibir mantenimiento, entrar en conflicto con otro plugin o fallar después de una actualización automática.
Puede que el formulario dependa de JavaScript y que algún error del navegador impida que funcione, que un sistema de caché esté sirviendo una versión antigua de la página o que un sistema antispam decida que el visitante es un robot y rechace su mensaje. Incluso puede ocurrir que el formulario parezca funcionar, pero que una petición al servidor haya fallado silenciosamente y el mensaje no haya llegado a procesarse.
Ya tenemos una interesante colección de posibilidades y todavía no hemos empezado a enviar ningún correo.
Segunda estación: ¿a quién demonios estamos escribiendo?
Supongamos que el formulario funciona. Ahora tenemos que comprobar la configuración de correo, porque la dirección del destinatario puede estar mal escrita, ser una dirección antigua o pertenecer a un dominio que ya no utilizamos. También puede ocurrir que el formulario esté configurado para enviar el mensaje a una cuenta de un antiguo administrador de la página, que el campo de correo del remitente esté mal asociado o que la dirección utilizada como remitente no esté autorizada para enviar mensajes desde ese dominio.
Incluso puede que existan varios destinatarios y que alguno de ellos sea incorrecto, o que una cuenta que aparentemente sigue existiendo ya no se consulte. Todo esto puede suceder sin que el visitante tenga ninguna posibilidad de saberlo y sin que el administrador actual de la web sea consciente del problema.
Tercera estación: WordPress necesita que alguien envíe el correo
Aquí empieza la parte verdaderamente interesante. WordPress no es, por sí mismo, un servicio de correo electrónico. Normalmente utiliza una función de envío, wp_mail(), que depende de la configuración de WordPress, de PHP y del sistema de correo disponible.
En una instalación convencional, el servidor puede disponer de un agente de transporte de correo, como Exim, Postfix o Sendmail. Ese programa puede estar mal configurado, desactivado o haber cambiado de configuración durante una actualización del servidor. También puede existir una restricción del proveedor de alojamiento, haberse superado algún límite de envío o producirse un fallo en las conexiones necesarias para transmitir el mensaje.
En otras configuraciones se utiliza un servicio SMTP autenticado o una API externa. En ese caso, el problema puede estar en una contraseña que ha cambiado, una cuenta suspendida, unas credenciales caducadas, un servicio que ha dejado de estar disponible o una política de seguridad que ha cambiado. Lo que funcionaba perfectamente ayer puede dejar de funcionar hoy sin que hayamos modificado nada en nuestra página web.
Así que tenemos otra característica fascinante: el formulario puede estar perfectamente configurado y dejar de funcionar por un cambio realizado en un sistema que ni siquiera controlamos.
Cuarta estación: ahora necesitamos el permiso del resto de Internet
Supongamos que nuestro servidor consigue enviar el correo. ¿Hemos terminado? Por supuesto que no, porque ahora comienza el maravilloso mundo de los sistemas de autenticación y reputación del correo electrónico.
Tenemos SPF, DKIM y DMARC, tres mecanismos relacionados con la autorización y autenticación de los mensajes enviados en nombre de un dominio. Una configuración incorrecta puede provocar que los correos sean rechazados o considerados sospechosos. También tenemos los registros DNS, cuya configuración puede cambiar o quedar obsoleta, y diversas políticas de seguridad que aplican los servidores de destino.
Y después están las listas de bloqueo y los sistemas de reputación. Quizá nuestro servidor de correo haya sido utilizado para enviar spam y su dirección IP tenga mala reputación. Puede que nuestra web haya sufrido una intrusión, que un plugin vulnerable haya permitido el envío masivo de mensajes o que alguien haya conseguido las credenciales de una cuenta de correo.
Pero existe una posibilidad todavía más irritante: puede que nosotros no hayamos hecho absolutamente nada malo. En muchos alojamientos compartidos, varios clientes utilizan la misma dirección IP para enviar correo. Otro cliente puede haber enviado spam, voluntaria o involuntariamente, deteriorando la reputación de esa IP. Así que podemos tener una página perfectamente configurada, un servidor funcionando y un dominio legítimo, pero sufrir problemas de entrega por lo que ha hecho un desconocido que comparte infraestructura con nosotros.
Hay que precisar que aparecer en una lista de bloqueo no implica necesariamente que todos los correos vayan a ser rechazados. Cada servicio de correo utiliza sus propios criterios, consulta diferentes sistemas de reputación y aplica políticas que pueden cambiar con el tiempo. Lo cual, naturalmente, añade otra capa de incertidumbre.
Quinta estación: el correo ha salido, pero todavía no ha llegado
Nuestro mensaje ha superado todos los obstáculos anteriores, pero todavía tiene que atravesar los sistemas de recepción del destinatario. El servidor receptor puede rechazarlo, aceptarlo y clasificarlo como spam, enviarlo a cuarentena o retrasar temporalmente su entrega. También puede aplicar una regla de filtrado que lo mueva a una carpeta inesperada, encontrarse con un buzón lleno, una cuenta cancelada o un reenvío automático mal configurado.
Incluso puede que el mensaje llegue varias horas después y que, cuando revisemos el funcionamiento del formulario, concluyamos equivocadamente que no funciona. Y hay una distinción técnica importante: que un servidor acepte un mensaje no significa que este haya llegado a la bandeja de entrada del destinatario, y mucho menos que haya sido leído.
A estas alturas, la frase «Su mensaje ha sido enviado correctamente» empieza a parecerme una declaración bastante optimista, especialmente porque, en muchos sistemas, lo único que significa es que el formulario ha conseguido entregar el mensaje al siguiente componente de la cadena.
Sexta estación: el drama del remitente
Hasta ahora hemos contemplado el problema desde la perspectiva del administrador de la página, pero pensemos también en quien escribe. Una persona puede dedicar veinte minutos a redactar un mensaje importante, quizá una propuesta de colaboración, una sugerencia elaborada o una consulta compleja. Cuando pulsa «Enviar», el formulario puede borrar el contenido de los campos y, si el mensaje se pierde y no existe ninguna copia, el visitante puede haber perdido también todo su trabajo.
Por eso algunos formularios ofrecen la posibilidad de enviar automáticamente una copia al remitente, lo que parece una solución razonable hasta que advertimos un pequeño detalle: esa copia se envía utilizando el mismo sistema de correo que acabamos de comprobar que puede fallar de decenas de maneras. Es decir, hemos intentado solucionar el problema de un correo que no llega enviando otro correo. Admiro la elegancia circular de esta solución.
Una alternativa más segura sería permitir que el visitante copiase o descargase su mensaje, independientemente de que el sistema de correo funcionase. Incluso podríamos mostrarle una copia completa antes de borrar los campos del formulario, de manera que pudiera conservarla por sus propios medios.
Séptima estación: lo verdaderamente preocupante
Aquí llegamos al problema que considero más grave. Imaginemos que alguien quiere participar en un proyecto que llevamos años desarrollando. Encuentra nuestra página web, lee la información, se interesa y decide escribirnos. El formulario le confirma que su mensaje ha sido enviado, pero nosotros no recibimos nada.
El visitante espera una respuesta y, cuando transcurren los días o las semanas, puede concluir que no nos interesa su colaboración, que somos poco profesionales o que el proyecto está abandonado. Por nuestra parte, ni siquiera sabemos que esa persona existe. Tal vez hayamos perdido una oportunidad de investigación, una colaboración, una amistad o una propuesta importante, y lo más inquietante es que no tenemos forma de saber cuántas oportunidades hemos perdido.
Podemos comprobar que un formulario funciona hoy, pero eso no demuestra que haya funcionado durante los últimos seis meses. El silencio de una página web no demuestra que nadie quiera ponerse en contacto con sus responsables, porque también puede significar que el sistema de comunicación está fallando.
Esta es una diferencia crucial entre una avería visible y una avería silenciosa. Si una página web no carga, el problema resulta relativamente fácil de detectar; en cambio, si un formulario deja de entregar mensajes, podemos tardar meses en enterarnos o no enterarnos nunca. Y cuanto más importante sea recibir comunicaciones inesperadas de personas que todavía no conocemos, más difícil será incluso sospechar que estamos perdiéndolas.
¿Y no existen soluciones profesionales?
Naturalmente que existen. Hay servicios de correo transaccional, plugins con almacenamiento de mensajes, herramientas de monitorización, sistemas antispam, proveedores de SMTP y plataformas especializadas en formularios. Algunos tienen versiones gratuitas y otros son de pago, frecuentemente mediante suscripción.
No todos son caros y existen combinaciones gratuitas que pueden funcionar razonablemente bien, pero configurar un sistema fiable, mantenerlo actualizado, protegerlo contra el spam y comprobar regularmente que sigue funcionando puede requerir un esfuerzo considerable. Además, añadir proveedores externos introduce nuevas dependencias: cuentas, credenciales, cuotas, límites, cambios de tarifas y políticas de servicio.
En ocasiones resulta desconcertante que, para conseguir algo tan elemental como recibir un mensaje de un visitante, tengamos que administrar una infraestructura que parece diseñada para una pequeña empresa de telecomunicaciones. Se supone que el objetivo de utilizar un gestor de contenidos como WordPress es simplificar la administración de una página web, pero en este caso la aparente simplicidad del formulario oculta una complejidad técnica considerable, cuyo mantenimiento acaba recayendo sobre el propietario de la página.
¿Cómo debería ser un formulario de contacto?
Creo que habría que empezar por abandonar una idea: que el correo electrónico debe ser el único lugar donde existe el mensaje.
Mi formulario ideal guardaría el mensaje en la base de datos de la página web antes de confirmar su recepción, asignándole un identificador único. De esta manera, si el correo electrónico fallase, el mensaje seguiría estando disponible para el administrador. El visitante también podría conservar una copia inmediata de su texto, sin depender de recibir otro correo electrónico, y tendría una referencia con la que identificar su comunicación.
Además, el sistema distinguiría claramente entre «mensaje registrado en la web» y «notificación enviada por correo», sin prometer una entrega que no puede verificar. Dispondría de registros de errores y mecanismos de alerta para detectar los fallos, aunque naturalmente también habría que comprobar periódicamente que el propio sistema de alertas funciona.
Por último, sería necesario proteger los mensajes almacenados, limitar el acceso a ellos y establecer una política de conservación y eliminación compatible con la privacidad de los visitantes. Guardar mensajes en una base de datos evita algunos riesgos, pero introduce otros, especialmente cuando contienen información personal.
No se trata de conseguir una fiabilidad absoluta, algo difícilmente garantizable, sino de evitar que un único fallo provoque la pérdida irreversible de una comunicación. Y tampoco tendría mucho sentido instalar diez plugins diferentes para resolver el problema, porque cada uno de ellos añadiría nuevas posibilidades de error.
Mi solución favorita: no poner todos los huevos en el mismo formulario
Mientras llega ese sistema ideal, creo que una página de contacto debería ofrecer varios canales de comunicación, en lugar de obligar al visitante a utilizar exclusivamente un formulario.
El correo electrónico directo tiene una ventaja enorme: el remitente normalmente conserva una copia de lo que ha enviado en su carpeta de mensajes enviados. Esto tampoco garantiza la entrega, pero al menos protege el contenido y permite comprobar posteriormente qué dirección utilizó y cuándo intentó establecer contacto.
Las redes sociales y los sistemas de mensajería ofrecen alternativas adicionales. También pueden fallar, filtrar mensajes o esconderlos en carpetas de solicitudes, pero no dependen exactamente de la misma infraestructura que el correo enviado desde nuestro servidor web. La clave está en disponer de canales suficientemente independientes para que el fallo de uno de ellos no impida completamente la comunicación.
Y, sobre todo, conviene avisar a los visitantes de algo que normalmente damos por supuesto: si no reciben respuesta, no significa necesariamente que no queramos responderles. Es posible que nunca hayamos recibido su mensaje, por lo que sería conveniente intentar contactar mediante otro canal.
Una última reflexión: la ilusión de simplicidad
Hay algo filosóficamente interesante en todo esto. Los sistemas informáticos modernos están diseñados para ocultarnos su complejidad y, en general, eso es positivo, porque nadie quiere conocer los protocolos de transporte, los registros DNS o las políticas de autenticación cada vez que envía un mensaje. Pero esa simplicidad de la interfaz puede generar una falsa sensación de seguridad.
Vemos un cuadro de texto, un botón y una confirmación, e interpretamos que el proceso es sencillo y que el resultado está garantizado. La realidad es que ese botón desencadena una cadena de operaciones distribuidas entre programas, servidores, redes y organizaciones distintas, cada una con sus propios errores, límites y políticas. Además, no siempre podemos observar lo que sucede al otro lado, de manera que una indicación aparentemente inequívoca como «Mensaje enviado correctamente» puede ocultar una considerable incertidumbre.
En cierto sentido, el formulario de contacto es una pequeña metáfora de nuestra relación con la tecnología: confiamos en sistemas cuya complejidad desconocemos y cuyos fallos pueden permanecer invisibles. La interfaz nos proporciona una representación simplificada del funcionamiento, pero a veces confundimos esa representación con lo que realmente ha sucedido.
Por eso he decidido empezar mi página de contacto con una confesión: yo también odio los formularios de correo. Y si has llegado hasta aquí después de intentar enviarme un mensaje sin conseguirlo, probablemente ahora entiendas por qué.
Si quieres contactar conmigo, utiliza cualquiera de los canales disponibles y, si no respondo, prueba con otro. Puede que no te esté ignorando, sino que uno de esos 74 pequeños demonios informáticos se haya interpuesto entre nosotros.
1 Comment