Por qué reviso el registro de correo WordPress antes que los logs del servidor

El caso típico es siempre el mismo. Un formulario de contacto que «no llega». Un cliente que no recibe el email de restablecimiento de contraseña. Un pedido que se queda sin confirmación. Sin un log a mano, la primera hipótesis es la carpeta de spam. Luego los logs del servidor SMTP. Luego quizá el firewall. Con FluentSMTP me salto esos pasos. Veo enseguida si WordPress realmente intentó enviar ese email. A quién, cuándo, con qué respuesta del servidor de envío.

FluentSMTP registra cada llamada a wp_mail(). No solo los emails de plugins de terceros, también los que genera el núcleo: notificaciones de nuevo usuario, avisos de actualización, alertas de error. Para cada envío el log muestra remitente, destinatario, asunto, cabeceras completas, cuerpo del mensaje. Y la respuesta del proveedor SMTP o de la API usada. Si un email ha fallado, esa respuesta del servidor está ahí. No tengo que adivinarla.

Qué encuentro realmente en el registro de envíos

El plugin soporta decenas de conectores: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. También Google Workspace y Microsoft 365 vía OAuth, además del clásico SMTP genérico. En los sitios que gestiono uso casi siempre SMTP autenticado con el dominio del cliente. Alguna vez una API dedicada, cuando el volumen de emails crece. En ambos casos el registro de correo WordPress no cambia. Cada línea tiene un estado, enviado o fallido. Hay un botón para revisar el contenido o reenviar el mensaje, sin que el usuario tenga que repetir la acción que lo generó.

El reenvío manual es la función que más uso. Un formulario rellenado dos veces porque «no llegaba» se convierte en un clic sobre el log. No un nuevo aviso al cliente. Para los fallos repetidos he activado las notificaciones en Telegram. En cuanto una conexión deja de funcionar, lo sé antes de que me lo escriba alguien. En vez de descubrirlo por un ticket de soporte.

El log no se limita a las notificaciones dirigidas a mí o al cliente que administra el sitio. Ahí acaba también cada email de salida generado por el sitio hacia terceros: la confirmación de pedido que una tienda online envía al cliente final, el recibo de un pago, el aviso de envío. Si esa confirmación no llega, la veo en el registro de correo WordPress exactamente como una notificación interna. Tiene el mismo botón para reenviarla al destinatario correcto, sin hacerle repetir la compra.

Cómo configuro FluentSMTP en los sitios que gestiono

Después de conectar el conector adecuado, cambio la conservación del log. Por defecto se mantiene activo mucho tiempo. Yo la llevo a 30-60 días, según el tráfico del sitio. Sirve para rastrear un problema señalado con retraso. Sin llenar la base de datos de líneas que nunca consultaré. Luego activo al menos un canal de notificación para los fallos, Telegram o Slack según el cliente. El log solo no avisa a nadie: hay que abrirlo para leerlo.

En los sitios con formulario de contacto uso también Cisilino Site Defense Network para el bloqueo de bots. Menos spam entrante significa menos emails generados por los formularios. El log queda más legible, con menos ruido que filtrar cuando busco el mensaje correcto.

Las credenciales SMTP no quedan en claro en la base de datos

Un detalle que compruebo siempre antes de guardar una conexión: dónde acaban las credenciales. FluentSMTP las cifra por defecto con las claves SALT de WordPress, las mismas presentes en wp-config.php para la seguridad de las sesiones. Se puede desactivar el cifrado, pero el propio plugin lo marca como no recomendado. En los sitios que gestiono prefiero otra opción: guardar la contraseña de la API o del SMTP directamente en wp-config.php, fuera de la base de datos. Defino las constantes antes de que el plugin las lea. Así, ni un volcado de la base de datos ni un acceso no autorizado al panel expone la clave del proveedor de envío. Es el mismo principio que aplico en otros sitios: menos secretos en la base de datos, mejor.

Varias conexiones a la vez, no solo una

FluentSMTP permite configurar varias conexiones a la vez, no solo una. En un sitio configuro la predeterminada y añado una segunda como reserva: si el primer proveedor no responde, el envío pasa automáticamente a la conexión de reserva, sin que yo tenga que intervenir. La elección de la conexión depende de la dirección del remitente. Cada conexión tiene su «From». El resto pasa por la predeterminada, con la reserva lista solo si la predeterminada falla de verdad: un error del proveedor, no un email que acabó en spam. Es una de las razones por las que lo prefiero a un único SMTP sin alternativas. Si SendGrid o Amazon SES tienen un problema durante unas horas, el sitio sigue enviando de todas formas, y lo veo enseguida en el registro de correo WordPress. Todo incluido en la versión gratuita, sin una versión pro de pago: solo se paga el proveedor de envío elegido, no el plugin.

Un chequeo de salud cada día, no solo cuando algo se rompe

Además del log línea por línea, FluentSMTP hace un chequeo de salud de la conexión cada día, de forma automática. Si el proveedor deja de responder, el aviso llega antes de que un cliente me escriba «el sitio ya no envía emails». El mismo panel muestra un gráfico con los totales diarios de envíos correctos y fallidos. Es útil para entender de un vistazo si una caída es normal o es el síntoma de algo que se está rompiendo, sin abrir el registro de correo WordPress línea por línea cada vez. También hay un resumen periódico por email, con los totales de la semana. No es un aviso de error, es un boletín que leo de pasada para saber si el volumen de envíos está dentro de lo normal.

Para quien, como yo, gestiona varios sitios desde la línea de comandos, FluentSMTP también expone comandos WP-CLI. Hay una prueba de envío, un chequeo de salud de la conexión, las estadísticas y la limpieza de los logs antiguos. Los uso en los mismos scripts que ya corren en los servidores para otros controles de mantenimiento, sin abrir el panel de cada sitio uno por uno.

Los límites honestos del registro de correo WordPress

No es una solución mágica. La conservación se basa en los días, no en un número máximo de líneas. En un sitio con mucho tráfico transaccional la tabla del log puede crecer rápido. Conviene tenerla controlada, o fijar una conservación más corta. Las notificaciones de fallo llegan solo por los canales de chat configurados, no por email. Tiene sentido: un email que avisa de un email fallido corre el riesgo de fallar también. Pero hay que saberlo de antemano.

Por último, el log registra lo que ha pasado por el lado de WordPress y por el lado del proveedor. No garantiza la entrega en la bandeja del destinatario. Si un email aparece como enviado pero acaba en spam, es un problema de reputación del dominio o de configuración SPF/DKIM. No algo que un log pueda resolver por sí solo. Sigue siendo, aun así, el primer sitio donde miro, antes de cualquier otra comprobación.

El plugin es gratuito y de código abierto. Página oficial en wordpress.org, sin funciones bloqueadas detrás de una versión pro. Para quien gestiona aunque sea un solo sitio con un formulario de contacto, vale la pena instalarlo solo por el registro de correo WordPress. La primera vez que resuelve un «no he recibido el email» en un minuto en vez de en media hora, ya se ha pagado solo.

The post Registro de correo WordPress: por qué lo controlo con FluentSMTP first appeared on Matteo Cisilino.

Qué es Cisilino Site Defense Network

Cisilino Site Defense Network, en resumen CSDN, es un plugin para WordPress. Cuenta los inicios de sesión fallidos de cada dirección IP. Cuando una IP alcanza el umbral, la bloquea escribiéndola en el archivo .htaccess del sitio.

El plugin funciona solo, sin ninguna configuración. La conexión a un panel externo es opcional. Si no la configuras, el plugin no hace ninguna llamada hacia el exterior.

Lo encuentras en el menú lateral de WordPress, en la opción que indica el punto 1 de la imagen: Ajustes > Cisilino Site Defense Network. Dentro hay diez pestañas, enumeradas en el punto 3.

Para qué sirve

El plugin reúne varias defensas, todas gestionadas desde esa página.

• Bloqueo automático de las IP que fallan demasiadas veces el inicio de sesión, con una whitelist para las redes de confianza.
• Bloqueo y desbloqueo manual de una sola IP, incluso por tiempo limitado.
• Reglas opcionales para .htaccess: nada de PHP en uploads, sin listado de carpetas, archivos sensibles protegidos.
• Cabeceras HTTP de seguridad y desconexión de los administradores inactivos.
• Una política sobre quién puede crear nuevos usuarios.
• Un límite a las publicaciones de los autores y a los comentarios y a los formularios de Contact Form 7 enviados por invitados.
• Un registro de las actividades del sitio y un control de integridad de los archivos del plugin.
• Un registro de errores PHP, que puedes activar cuando lo necesites.

Qué no hace el plugin

Este manual CSDN también habla de los límites, y conviene conocerlos desde ya. El plugin no es un firewall de aplicación: no analiza el contenido de las peticiones. La palabra IDS en el nombre de la pestaña indica reglas de acceso a archivos y carpetas, no un verdadero sistema de detección de intrusiones.

• No impide las manipulaciones de archivos: solo las detecta, y quien ya tiene acceso de escritura puede saltarse el control.
• No crea una copia de .htaccess antes de modificarlo.
• No ofrece la Content-Security-Policy entre las cabeceras.
• No oculta el listado de usuarios de la API REST de WordPress.
• No tiene una lista de dominios de correo ni un captcha para los registros.
• En un servidor que ignora .htaccess, como nginx, las reglas a nivel de servidor no tienen efecto.

Atención: un plugin reduce los riesgos, no los elimina. Mantén actualizados WordPress, los temas y los plugins y haz copias de seguridad del sitio, aunque uses CSDN.

Requisitos

• WordPress 5.8 o posterior y PHP 7.4 o posterior.
• Apache, o LiteSpeed compatible, para los bloqueos de IP y para el hardening. El archivo .htaccess debe poder escribirse.
• Una cuenta con el permiso de gestionar los ajustes. En un sitio único es manage_options. En una red multisitio se necesita el superadministrador.
• Para el panel, opcional: una dirección https, un customer code y una clave API.

Las actualizaciones llegan por el mecanismo normal de WordPress, en Plugins > Actualizaciones. El plugin está pensado para el directorio de WordPress.org, donde tiene su página oficial: es el lugar correcto para comprobar qué versión está publicada.

Cómo leer el manual CSDN

Puedes leer los capítulos en orden o saltar al que te haga falta. Cada capítulo tiene una imagen con el mapa de la página y círculos rojos numerados: el número 1 indica la opción de menú, el 2 la pestaña activa, los demás las secciones.

Si es la primera vez, empieza por la instalación y el primer arranque. Si algo no funciona, ve directo al capítulo sobre la resolución de problemas. Estos son los capítulos:

1. Introducción: esta página.
2. Instalar y activar Cisilino Site Defense Network
3. Conectar el plugin al panel: Ajustes remotos
4. Pestaña General: umbral de bloqueo y estado del plugin
5. Bloquear, desbloquear y whitelist: las anulaciones manuales
6. Pestaña IP bloqueadas: leer la lista negra
7. Hardening / IDS: las reglas para .htaccess
8. Vigilancia de subidas y control de integridad
9. Pestaña Test: comprobar que las protecciones funcionan
10. Paranoic Hardening: cabeceras de seguridad y sesión administrativa
11. Registro de usuarios: quién puede crear cuentas
12. Rate limiting: límites para autores y visitantes
13. Registro de actividad: qué ha pasado en el sitio
14. Registro de depuración: los errores PHP en un archivo propio
15. Resolución de problemas y preguntas frecuentes
16. Desactivación, desinstalación y datos personales

Una nota que evita confusiones. El bloqueo y el desbloqueo manual de una IP y la whitelist están en la pestaña General, no en IP bloqueadas. Lo mismo vale para el formulario de vigilancia de subidas.

Todas las etiquetas de los campos y los botones, en el manual CSDN, están copiadas tal como las ves en el plugin. Para empezar, pasa al capítulo siguiente: Instalar y activar Cisilino Site Defense Network.

The post Manual CSDN first appeared on Matteo Cisilino.