Perché controllo il log email WordPress prima dei log del server

Il caso tipico è sempre lo stesso. Un modulo di contatto che “non arriva”. Un cliente che non riceve l’email di reset password. Un ordine che resta senza conferma. Senza un log a portata di mano, la prima ipotesi è la cartella spam. Poi i log del server SMTP. Poi magari il firewall. Con FluentSMTP salto quei passaggi. Vedo subito se WordPress ha davvero provato a spedire quell’email. A chi, quando, con quale risposta del server di invio.

FluentSMTP registra ogni chiamata a wp_mail(). Non solo le email dei plugin di terze parti, anche quelle generate dal core: notifiche di nuovo utente, promemoria di aggiornamento, avvisi di errore. Per ogni invio il log mostra mittente, destinatario, oggetto, intestazioni complete, corpo del messaggio. E la risposta del provider SMTP o dell’API usata. Se un’email è finita in errore, quella risposta del server è lì. Non devo indovinarla.

Cosa trovo davvero nel registro degli invii

Il plugin supporta decine di connettori: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Anche Google Workspace e Microsoft 365 via OAuth, oltre al classico SMTP generico. Sui siti che gestisco uso quasi sempre SMTP autenticato con il dominio del cliente. Qualche volta un’API dedicata, quando il volume di email cresce. In entrambi i casi il log email WordPress non cambia. Ogni riga ha uno stato, inviata o fallita. C’è un pulsante per rivedere il contenuto o rispedire il messaggio, senza che l’utente debba rifare l’azione che l’ha generato.

Il rinvio manuale è la funzione che uso più spesso. Un modulo compilato due volte perché “non arrivava” diventa un clic sul log. Non una nuova segnalazione al cliente. Per i fallimenti ripetuti ho attivato le notifiche su Telegram. Appena una connessione smette di funzionare, lo so prima che me lo scriva qualcuno. Invece di scoprirlo da un ticket di supporto.

Il log non riguarda solo le notifiche dirette a me o al cliente che amministra il sito. Finisce lì ogni email in uscita generata dal sito verso terzi: la conferma d’ordine che un negozio online manda al cliente finale, la ricevuta di un pagamento, la notifica di spedizione. Se quella conferma non arriva, la vedo nel log email WordPress esattamente come una notifica interna, con lo stesso pulsante per rispedirla al destinatario giusto senza fargli ripetere l’acquisto.

Come configuro FluentSMTP sui siti che gestisco

Dopo aver collegato il connettore giusto, cambio la conservazione del log. Di default resta attivo a lungo. Io lo porto a 30-60 giorni, in base al traffico del sito. Serve per risalire a un problema segnalato in ritardo. Senza riempire il database di righe che non consulterò mai. Attivo poi almeno un canale di notifica per i fallimenti, Telegram o Slack secondo il cliente. Il log da solo non avvisa nessuno: va aperto per essere letto.

Sui siti con form di contatto uso anche Cisilino Site Defense Network per il blocco dei bot. Meno spam in ingresso significa meno email generate dai moduli. Il log resta più leggibile, con meno rumore da filtrare quando cerco il messaggio giusto.

Le credenziali SMTP non restano in chiaro nel database

Un dettaglio che controllo sempre prima di salvare una connessione: dove finiscono le credenziali. FluentSMTP le cifra di default con le chiavi SALT di WordPress, quelle già presenti in wp-config.php per sicurezza delle sessioni. Si può disattivare la cifratura, ma il plugin stesso lo segnala come sconsigliato. Sui siti che gestisco preferisco un’altra opzione: salvare la password API o SMTP direttamente in wp-config.php, fuori dal database, definendo le costanti prima che il plugin le legga. Così anche un dump del database o un accesso non autorizzato al pannello non espone la chiave del provider di invio. È lo stesso principio che applico altrove: meno segreti nel database, meglio è.

Più connessioni insieme, non solo una alla volta

FluentSMTP permette di configurare più connessioni insieme, non solo una alla volta. Su un sito imposto quella predefinita e ne aggiungo una seconda come riserva: se il primo provider non risponde, l’invio passa automaticamente alla connessione di riserva, senza che io debba intervenire. La scelta della connessione dipende dall’indirizzo del mittente: ogni connessione ha il suo “From”, il resto passa per quella predefinita, con la riserva pronta solo se la predefinita fallisce davvero (un errore del provider, non un’email finita in spam). È una delle ragioni per cui lo preferisco a un singolo SMTP senza alternative: se SendGrid o Amazon SES hanno un problema per qualche ora, il sito continua comunque a spedire, e lo vedo subito nel log email WordPress. Tutto incluso nella versione gratuita, senza una versione pro a pagamento: si paga solo il provider di invio scelto, non il plugin.

Un controllo di salute ogni giorno, non solo quando qualcosa si rompe

Oltre al log riga per riga, FluentSMTP fa un controllo di salute della connessione ogni giorno, in automatico. Se il provider smette di rispondere, l’avviso arriva prima che un cliente mi scriva “il sito non manda più email”. Lo stesso pannello mostra un grafico con i totali giornalieri di invii riusciti e falliti: utile per capire a colpo d’occhio se un calo è normale o è il sintomo di qualcosa che si sta rompendo, senza dover aprire il log email WordPress riga per riga ogni volta. C’è anche un riepilogo periodico via email, con i totali della settimana: non è un avviso di errore, è un bollettino che leggo di sfuggita per sapere se il volume di invii è nella norma.

Per chi, come me, gestisce più siti da riga di comando, FluentSMTP espone anche dei comandi WP-CLI: un test di invio, un controllo di salute della connessione, le statistiche e la pulizia dei log vecchi. Li uso negli stessi script che già girano sui server per altri controlli di manutenzione, senza dover aprire il pannello di ogni sito uno per uno.

I limiti onesti del log email WordPress

Non è una soluzione magica. La conservazione è basata sui giorni, non su un numero massimo di righe. Su un sito con molto traffico transazionale la tabella del log può crescere in fretta. Conviene tenerla sotto controllo, o impostare una conservazione più breve. Le notifiche di fallimento arrivano solo sui canali di chat configurati, non per email. Ha senso: un’email che avvisa di un’email fallita rischia di fallire a sua volta. Ma va saputo prima di contarci.

Infine il log registra cosa è successo lato WordPress e lato provider. Non garantisce la consegna nella casella del destinatario. Se un’email è segnata come inviata ma finisce in spam, è un problema di reputazione del dominio o di configurazione SPF/DKIM. Non qualcosa che un log può risolvere da solo. Resta comunque il primo posto dove guardo, prima di qualsiasi altra verifica.

Il plugin è gratuito e open source. Pagina ufficiale su wordpress.org, senza funzioni bloccate dietro una versione pro. Per chi gestisce anche un solo sito con un modulo di contatto, vale la pena installarlo solo per il log email WordPress. La prima volta che risolve un “non ho ricevuto l’email” in un minuto invece che in mezz’ora, si è ripagato.

The post Log email WordPress: perché lo controllo con FluentSMTP first appeared on Matteo Cisilino.

Cos’è Cisilino Site Defense Network

Cisilino Site Defense Network, in breve CSDN, è un plugin per WordPress. Conta i login falliti per ogni indirizzo IP. Quando un IP raggiunge la soglia, lo blocca scrivendolo nel file .htaccess del sito.

Il plugin funziona da solo, senza nessuna configurazione. Il collegamento a un pannello esterno è facoltativo. Se non lo configuri, il plugin non fa alcuna chiamata verso l’esterno.

Lo trovi nel menu laterale di WordPress, alla voce indicata dal punto 1 dell’immagine: Impostazioni > Cisilino Site Defense Network. Dentro ci sono dieci schede, elencate al punto 3.

A cosa serve

Il plugin mette insieme diverse difese, tutte gestite da quella pagina.

• Blocco automatico degli IP che sbagliano troppe volte il login, con una whitelist per le reti fidate.
• Blocco e sblocco manuale di un singolo IP, anche a tempo.
• Regole opzionali per .htaccess: niente PHP in uploads, niente elenco delle cartelle, file sensibili protetti.
• Header HTTP di sicurezza e disconnessione degli amministratori inattivi.
• Una policy su chi può creare nuovi utenti.
• Un limite alle pubblicazioni degli autori e ai commenti e ai moduli di Contact Form 7 inviati dagli ospiti.
• Un registro delle attività del sito e un controllo di integrità dei file del plugin.
• Un log degli errori PHP, che puoi accendere quando serve.

Cosa il plugin non fa

Questo manuale CSDN parla anche dei limiti, e conviene conoscerli subito. Il plugin non è un firewall applicativo: non analizza il contenuto delle richieste. La parola IDS nel nome della scheda indica regole di accesso a file e cartelle, non un vero sistema di rilevamento delle intrusioni.

• Non impedisce le manomissioni dei file: le rileva soltanto, e chi ha già accesso in scrittura può aggirare il controllo.
• Non crea una copia di .htaccess prima di modificarlo.
• Non offre il Content-Security-Policy tra gli header.
• Non nasconde l’elenco utenti dell’API REST di WordPress.
• Non ha un elenco di domini email né un captcha per le registrazioni.
• Su un server che ignora .htaccess, come nginx, le regole a livello server non hanno effetto.

Attenzione: un plugin riduce i rischi, non li azzera. Tieni aggiornati WordPress, temi e plugin e fai copie di sicurezza del sito, anche se usi CSDN.

Requisiti

• WordPress 5.8 o successivo e PHP 7.4 o successivo.
• Apache, o LiteSpeed compatibile, per i blocchi IP e per l’hardening. Il file .htaccess deve essere scrivibile.
• Un account con il permesso di gestire le impostazioni. Su un sito singolo è manage_options. Su una rete multisite serve il super admin.
• Per il pannello, facoltativo: un indirizzo https, un customer code e una chiave API.

Gli aggiornamenti arrivano dal normale meccanismo di WordPress, in Plugin > Aggiornamenti. Il plugin è pensato per la directory di WordPress.org, dove ha la sua pagina ufficiale: è il posto giusto per controllare quale versione è pubblicata.

Come leggere il manuale CSDN

Puoi leggere i capitoli in ordine oppure saltare a quello che ti serve. Ogni capitolo ha un’immagine con la mappa della pagina e dei cerchi rossi numerati: il numero 1 indica la voce di menu, il 2 la scheda attiva, gli altri le sezioni.

Se è la prima volta, parti dall’installazione e dal primo avvio. Se qualcosa non funziona, vai diretto al capitolo sulla risoluzione dei problemi. Questi sono i capitoli:

1. Introduzione: questa pagina.
2. Installare e attivare Cisilino Site Defense Network
3. Collegare il plugin al pannello: Impostazioni remote
4. Scheda Generale: soglia di blocco e stato del plugin
5. Bloccare, sbloccare e whitelist: gli override manuali
6. Scheda IP bloccati: leggere la blacklist
7. Hardening / IDS: le regole per .htaccess
8. Sorveglianza dei caricamenti e controllo di integrità
9. Scheda Test: verificare che le protezioni funzionino
10. Paranoic Hardening: header di sicurezza e sessione amministrativa
11. Registrazione utenti: chi può creare account
12. Rate limiting: limiti su autori e visitatori
13. Registro attività: cosa è successo sul sito
14. Log di debug: gli errori PHP in un file proprio
15. Risoluzione dei problemi e domande frequenti
16. Disattivazione, disinstallazione e dati personali

Una nota che evita confusioni. Il blocco e lo sblocco manuale di un IP e la whitelist stanno nella scheda Generale, non in IP bloccati. Lo stesso vale per il form di sorveglianza dei caricamenti.

Tutte le etichette dei campi e dei pulsanti, nel manuale CSDN, sono copiate come le vedi nel plugin. Per cominciare passa al capitolo successivo: Installare e attivare Cisilino Site Defense Network.

The post Manuale CSDN: cos’è Cisilino Site Defense Network e come usarlo first appeared on Matteo Cisilino.