AUTOMAZIONE
Bot che compilano e inviano
Script automatici cercano form pubblici, riempiono campi, inseriscono link e consumano il servizio di posta.
Guide
Modulo contatti del sito: come bloccare lo spam e non perdere richieste
Un form che mostra “messaggio inviato” non dimostra che la richiesta sia arrivata. Servono protezioni stratificate, validazione server-side, feedback accessibili e un flusso email configurato e provato fino alla casella reale.
La risposta breve
Un modulo contatti affidabile deve chiedere solo i dati necessari, validare ogni campo anche sul server, limitare gli invii automatici senza affidarsi a un solo controllo, usare un mittente del dominio e il Reply-To dell’utente, mostrare successo soltanto quando la notifica principale viene accettata dal trasporto e verificare poi SPF, DKIM, DMARC e ricezione con un invio reale.
Gian Luca Partengo
Sviluppatore web dal 1995 · siti su misura · Aggiornato
Quando un modulo contatti è davvero affidabile
Il percorso non termina quando l’utente preme il pulsante. Deve funzionare ogni anello, dal campo compilato alla casella che riceve.
- 01La persona comprende e completa il form
- 02Il server valida e limita gli abusi
- 03Il trasporto accetta la notifica principale
- 04Il destinatario autentica e riceve il messaggio
Se il form sembra semplice, perché tante richieste si perdono?
Un modulo collega browser, codice server, servizio email, DNS e casella finale. Una sola configurazione debole può produrre spam, errori silenziosi o false conferme.
HEADER
Valori usati come istruzioni
Se email, oggetto o altri dati entrano negli header senza controllo, caratteri CR/LF possono tentare di aggiungere destinatari o campi indesiderati.
VOLUME
Invii ripetuti in pochi secondi
Anche dati formalmente validi possono diventare abuso quando la stessa funzione viene richiamata centinaia di volte.
RECAPITO
Il server accetta, la casella non riceve
Un trasporto locale può prendere in carico la mail e incontrare dopo un rifiuto, un filtro antispam o un problema di autenticazione.
USABILITÀ
Errori che non spiegano come correggere
Colorare un bordo non basta: chi usa tastiera, screen reader o ingrandimento deve identificare l’errore e raggiungere il campo.
DATI
Più informazioni del necessario
Campi superflui, log completi e tracker caricati sul form aumentano attrito, responsabilità e superficie da proteggere.
Il primo sistema anti-abbandono è un form proporzionato
Prima di aggiungere controlli tecnici, bisogna decidere quali informazioni servono davvero per iniziare una conversazione.
MINIMIZZAZIONE
Ogni campo deve giustificare la propria presenza
W3C ricorda che le persone preferiscono moduli brevi e semplici. Chiedere dati irrilevanti o prematuri aumenta la probabilità di abbandono.
Nome, recapito, contesto e messaggio possono essere sufficienti in molti siti. Azienda, telefono, budget o URL diventano obbligatori solo quando il processo li richiede davvero.
Obbligatorio significa indispensabile
Un campo non diventa necessario perché potrebbe essere utile in futuro. Deve servire alla richiesta che la persona sta facendo ora.
Gli opzionali restano davvero opzionali
Telefono, sito esistente o azienda possono aiutare, ma non devono bloccare una prima richiesta quando non sono essenziali.
La finalità è comprensibile
Etichette, opzioni e testo introduttivo devono far capire chi riceve i dati e quale risposta può aspettarsi.
La privacy non è nascosta
Il consenso e il collegamento all’informativa devono essere chiari, coerenti con il trattamento effettivo e utilizzabili da tastiera.
La validazione nel browser aiuta; quella sul server protegge
Attributi HTML e JavaScript migliorano l’esperienza, ma una richiesta può essere costruita senza usare la pagina. Il server deve quindi ricontrollare tutto.
| Campo | Nel browser | Sul server | Perché |
|---|---|---|---|
| Tipo email e lunghezza massima | Formato, lunghezza e caratteri di controllo | Il valore finisce nel flusso di risposta e non deve alterare gli header | |
| Telefono | Formato suggerito e maxlength | Caratteri, lunghezza e valore plausibile | Un input libero non deve accettare payload arbitrari |
| URL | Tipo URL e istruzioni | Solo HTTP(S), lunghezza e sintassi | Un indirizzo non verificato può diventare un dato ambiguo o pericoloso a valle |
| Argomento | Selezione fra opzioni visibili | Corrispondenza esatta con una lista consentita | Il client può essere modificato e inviare valori mai offerti |
| Messaggio | Minimo, massimo e istruzioni | Lunghezza, normalizzazione e codifica sicura in output | Il testo libero è legittimo, ma deve avere confini ed essere trattato come dato |
Client per l’usabilità, server per la fiducia
OWASP raccomanda controlli sintattici e semantici server-side, limiti minimi e massimi e liste consentite per i valori enumerati. La validazione non sostituisce la codifica corretta quando il dato viene mostrato o inserito in una mail.
Nessun controllo anti-spam basta da solo
Una difesa robusta combina segnali poco invasivi. L’obiettivo non è dimostrare che l’utente sia umano a ogni costo, ma rendere l’automazione meno affidabile e limitarne l’impatto.
Honeypot
Un campo invisibile alle persone ma individuato dai compilatori automatici segnala molte richieste costruite senza comprendere la pagina.
Controllo temporale firmato
Il server verifica che il form non sia stato inviato in un tempo impossibile né riutilizzato oltre la propria validità.
Verifica semplice firmata
Un controllo generato dal sito può aggiungere un ostacolo leggero senza caricare reCAPTCHA, profilazione o risorse di terze parti.
Token verificabili
HMAC e scadenze permettono di riconoscere parametri alterati o riciclati senza creare cookie o sessioni per il visitatore.
Rate limit persistente
Il numero di tentativi viene limitato anche fra richieste separate, così riaprire la pagina non azzera il controllo.
Nessun servizio esterno obbligatorio
Per un normale modulo contatti è possibile evitare widget di terze parti. Un challenge esterno resta una scelta proporzionata solo quando rischio e abuso lo richiedono.
Il rate limit deve sopravvivere alla singola pagina
Un contatore conservato soltanto nella sessione del browser è facile da azzerare. Il limite applicativo deve invece mantenere uno stato minimo, atomico e non pubblico.
-
01
Identificatore non reversibile
Gli elementi usati per distinguere le sorgenti vengono trasformati con HMAC; il file non conserva IP o email in chiaro.
-
02
Stato persistente e atomico
Timestamp e contatori sopravvivono alle richieste successive e vengono aggiornati evitando corse fra invii simultanei.
-
03
Finestra e soglie proporzionate
Il limite deve frenare raffiche anomale senza impedire a una rete condivisa o a una persona reale di correggere un errore.
-
04
Risposta prudente
Quando la soglia viene superata, il sistema non espone dettagli utili a calibrare il bot e invita a riprovare più tardi.
PROXY
X-Forwarded-For non è affidabile per definizione
Per impostazione prudente il server usa REMOTE_ADDR. Un header inviato dal client può essere falsificato e non deve diventare automaticamente la chiave del rate limit.
X-Forwarded-For si interpreta soltanto quando la richiesta arriva da un proxy realmente conosciuto e dichiarato con IP o rete verificati.
Il visitatore non deve diventare il mittente tecnico
From e Reply-To risolvono problemi diversi. Confonderli indebolisce autenticazione, affidabilità e sicurezza degli header.
REGOLA PRATICA
From del dominio, Reply-To dell’utente
La notifica parte da un indirizzo reale appartenente al dominio del sito. L’email inserita nel form viene usata per rispondere, non per fingere che il messaggio sia stato spedito dal suo dominio.
Oggetto, indirizzi e nomi usati negli header vengono controllati e privati di caratteri CR/LF. Ogni mail riceve inoltre un Message-ID coerente e univoco.
From
Identifica il mittente tecnico autorizzato dal dominio e deve essere coerente con il servizio che spedisce.
Reply-To
Nella notifica interna contiene l’indirizzo del visitatore, così “Rispondi” apre la conversazione corretta.
Message-ID
Distingue il messaggio, usa il dominio del sito e aiuta correlazione, diagnostica e tracciamento tecnico del flusso.
Protezione dagli header aggiunti
Valori esterni non devono poter introdurre nuove righe, destinatari, copie nascoste o istruzioni nel messaggio.
Notifica principale prima, autoreply dopo
L’ordine degli invii determina il significato della conferma mostrata alla persona.
- 01Validazione e controlli anti-abuso superati
- 02Notifica interna accettata dal trasporto
- 03Redirect firmato e stato di successo
- 04Autoreply eventuale, senza annullare la notifica
Successo soltanto dopo la notifica principale
Se il trasporto rifiuta la notifica interna, il sito deve mostrare un errore utile e non generare lo stato firmato di successo. Se fallisce soltanto l’autoreply, la richiesta già acquisita resta valida.
SPF, DKIM, DMARC e TLS: quattro controlli, quattro compiti
Il codice può costruire correttamente il messaggio, ma il dominio e l’infrastruttura devono dimostrare ai destinatari chi è autorizzato a spedirlo.
SPF
Quali server possono inviare
Il record DNS elenca i sistemi autorizzati per il dominio usato nel percorso SMTP. Un invio da una sorgente non prevista può fallire il controllo.
DKIM
Firma crittografica del dominio
Il server firma parti del messaggio; il destinatario recupera la chiave pubblica dal DNS e verifica firma e dominio.
DMARC
Allineamento con il From visibile
Collega il dominio mostrato all’utente a un’identità SPF o DKIM autenticata e pubblica una politica per i messaggi che non superano il controllo.
TLS
Cifratura durante il trasporto
Protegge la connessione fra server compatibili. Non sostituisce SPF, DKIM o DMARC e non garantisce da solo che la mail sia legittima.
Come si collauda davvero un modulo contatti
La deliverability non si dimostra interrogando soltanto il DNS né guardando la conferma sul sito. Serve una procedura controllata che arrivi a una casella esterna e separi ogni anello della catena.
PROTOCOLLO DI COLLAUDO
La prova deve coprire applicazione, trasporto, autenticazione e ricezione
Si invia una richiesta controllata verso un indirizzo esterno, verificando che la notifica principale preceda l’autoreply e che il sito non mostri un falso successo quando il trasporto rifiuta il messaggio.
Dal sorgente originale si controllano Authentication-Results, Return-Path, From, Reply-To, Message-ID, passaggi Received e uso di TLS quando il destinatario li rende disponibili.
Applicazione
Stato di successo firmato soltanto dopo l’accettazione della notifica principale.
Trasporto
Un rifiuto simulato non deve produrre successo; un invio accettato deve proseguire verso il destinatario esterno.
Autenticazione
Gli header del destinatario devono permettere di controllare SPF, DKIM, allineamento DMARC e politica pubblicata dal dominio.
Ricezione
Notifica e autoreply vanno cercate in inbox e spam; Reply-To e sorgente originale devono essere provati, non soltanto letti nella configurazione.
Un collaudo riuscito non è una garanzia eterna
La prova descrive un flusso, una configurazione e un momento preciso. DNS, provider, reputazione, contenuti e filtri cambiano: il collaudo va ripetuto dopo modifiche al trasporto e controllato nel tempo.
Un errore utile deve essere visibile, annunciato e raggiungibile
L’accessibilità del modulo non consiste soltanto nell’aggiungere etichette. Comprende istruzioni, associazioni, riepilogo, focus e possibilità di correggere senza ricominciare.
Etichette associate
Ogni controllo possiede un nome comprensibile e collegato tecnicamente al campo, utilizzabile anche con screen reader e input vocale.
Obblighi e formati spiegati
I campi necessari e gli eventuali formati vengono dichiarati prima dell’errore, senza affidarsi al solo colore o all’asterisco.
Riepilogo degli errori
Dopo l’invio, un blocco annunciabile elenca cosa non va e collega direttamente i campi da correggere.
Messaggi vicino al campo
aria-invalid e aria-describedby associano lo stato e la spiegazione al controllo interessato.
Focus gestito
Il focus raggiunge il riepilogo o il primo errore senza intrappolare la tastiera né nascondere il contesto.
Dati conservati con prudenza
I valori ammessi restano disponibili dopo l’errore, entro i limiti previsti; password, token e campi anti-spam non vengono ripresentati.
Per obblighi, WCAG e differenza fra pannello di preferenze e conformità completa, leggi la guida Accessibilità dei siti web.
Registrare abbastanza per capire, non abbastanza per duplicare il form
La diagnostica è utile quando distingue abusi, rifiuti e successi. Diventa un rischio quando copia nei log nomi, email, messaggi e indirizzi senza una necessità reale.
Vocabolario chiuso
Il log tecnico può conservare data, lingua e codici evento previsti, evitando testo libero e contenuto della richiesta.
Identificatori HMAC
Lo stato anti-abuso usa riferimenti non reversibili invece di memorizzare IP ed email in chiaro.
Eventi distinguibili
Validazione fallita, limite superato, trasporto rifiutato e notifica accettata devono poter essere separati senza esporre i dati del visitatore.
Analytics senza contenuto
Se la misurazione è attiva, l’evento di contatto parte soltanto dallo stato firmato e non include campi, query o proprietà personali.
Checklist: come verificare un modulo contatti
La checklist separa ciò che si vede nella pagina, ciò che va provato sul server e ciò che può essere confermato soltanto da una casella esterna.
| Area | Cosa verificare | Prova concreta |
|---|---|---|
| Campi | Solo informazioni necessarie, required e maxlength coerenti | Invio valido e tentativi oltre ogni limite |
| Validazione | Formato, lunghezza, liste consentite e codifica sicura | POST costruite senza browser e valori alterati |
| Anti-spam | Honeypot, tempo, firma e verifica leggera | Campi-trappola, invio troppo rapido e token manomessi |
| Rate limit | Persistenza, atomicità e nessun dato in chiaro | Raffica di richieste separate e controllo dello stato |
| Proxy | REMOTE_ADDR predefinito, proxy fidati dichiarati | X-Forwarded-For falsificato e richiesta da proxy noto |
| Header email | From del dominio, Reply-To utente, Message-ID e CR/LF | Sorgente originale e tentativi di header injection |
| Ordine | Notifica principale, successo firmato, poi autoreply | Trasporto principale rifiutato e autoreply simulata in errore |
| DNS e autenticazione | SPF, DKIM, DMARC e allineamento | Authentication-Results di una casella esterna |
| Consegna | Notifica e autoreply ricevute, inbox e spam controllate | Invio reale verso domini e caselle pertinenti |
| Accessibilità | Label, istruzioni, errori, focus, tastiera e conservazione dati | Errori volontari con tastiera e tecnologia assistiva |
Una scansione automatica non può certificare da sola la consegna. Il collaudo termina soltanto quando una casella esterna mostra il messaggio e i relativi Authentication-Results.
Cosa include lo standard GLP per i moduli contatti
Non aggiungo un form alla fine del progetto come elemento decorativo. Lo tratto come una funzione pubblica che raccoglie dati, attiva email e può diventare bersaglio di automazione.
STANDARD TECNICO
Il modulo deve funzionare anche nelle parti che il cliente non vede
La base comune comprende struttura accessibile, controlli server-side, protezioni stratificate, rate limit persistente, header coerenti e stato di successo legato alla notifica principale.
Ogni sito viene poi configurato sul proprio dominio e collaudato con destinatari reali. Nessuna soluzione garantisce assenza assoluta di spam o consegna eterna: riduce il rischio e rende verificabili gli anelli del sistema.
Cookieless
Niente cookie, sessioni o reCAPTCHA necessari per la protezione ordinaria del form.
Difesa stratificata
Honeypot, firme temporali, verifica firmata, limiti e rate limit coprono abusi differenti.
Errori accessibili
Riepilogo, collegamenti ai campi, focus, ARIA e valori conservati aiutano a correggere senza ricominciare.
Email coerenti
From del dominio, Reply-To corretto, Message-ID e ordine notifica-autoreply sono parte del modulo.
Collaudo reale
Il test comprende trasporto, ricezione e header originali, non soltanto la comparsa di una conferma sul sito.
Verifica nel tempo
Modifiche a hosting, DNS, caselle o trasporto richiedono un nuovo controllo della catena.
Approfondisci anche la sicurezza di un sito web, la scelta cookieless e perché un sito può non portare contatti.
Fonti primarie verificate
Le raccomandazioni della guida derivano da documentazione tecnica primaria e da un protocollo di collaudo applicabile al sistema reale.
-
OWASP — Input Validation Cheat SheetApri la fonte
Validazione sintattica e semantica, liste consentite, limiti e necessità dei controlli server-side.
-
OWASP — Bot Management and Anti-AutomationApri la fonte
Difesa a strati, honeypot, rate limit e limiti dei controlli singoli contro l’automazione.
-
W3C WAI — Forms TutorialApri la fonte
Etichette, istruzioni, validazione, notifiche e raccomandazione di chiedere soltanto i dati necessari.
-
W3C WAI — User NotificationsApri la fonte
Riepiloghi degli errori, messaggi comprensibili, collegamenti ai campi, ARIA e gestione del focus.
-
PHP Manual — mail()Apri la fonte
Sicurezza degli header e distinzione esplicita fra accettazione per la consegna e arrivo alla destinazione.
-
Google — Email sender guidelinesApri la fonte
Requisiti e raccomandazioni Gmail su SPF, DKIM, DMARC, allineamento, TLS e formato dei messaggi.
-
IETF RFC 9989 — DMARCApri la fonte
Standard corrente su identità autenticate, allineamento, policy, monitoraggio p=none e report aggregati.
-
IETF RFC 6376 — DKIMApri la fonte
Firma crittografica, dominio firmatario e verifica tramite chiave pubblicata nel DNS.
Fonti verificate il 27 agosto 2026. Configurazioni DNS, provider, interfacce e requisiti dei destinatari possono cambiare e vanno ricontrollati sul sistema reale.
Domande frequenti sui moduli contatti
Risposte dirette su spam, CAPTCHA, rate limit, email, SPF, DKIM, DMARC, autoreply, privacy e consegna.
Un honeypot basta a fermare lo spam?
No. Blocca molti bot semplici, ma quelli che interpretano la pagina o inviano richieste mirate possono evitarlo. Va combinato con firme temporali, validazione, rate limit e monitoraggio.
Serve sempre reCAPTCHA?
No. Per molti moduli ordinari è possibile usare protezioni locali senza reCAPTCHA o tracciamento esterno. Un servizio aggiuntivo può diventare proporzionato quando volume, rischio o abuso distribuito superano le difese applicative.
La validazione HTML rende sicuro il form?
No. Migliora l’esperienza, ma può essere aggirata costruendo direttamente la richiesta HTTP. Tutti i campi devono essere ricontrollati sul server.
Perché il From non deve essere l’email del visitatore?
Perché il sito non è autorizzato a spedire per conto del dominio del visitatore. Il From deve appartenere al dominio del sito; l’indirizzo inserito viene usato nel Reply-To della notifica interna.
Se mail() restituisce true, la richiesta è arrivata?
Significa che il trasporto ha accettato localmente il messaggio, non che la casella finale lo abbia ricevuto. La consegna si verifica con un invio reale e con gli header del destinatario.
Cosa significano SPF, DKIM e DMARC pass?
SPF conferma che la sorgente è autorizzata, DKIM verifica la firma del dominio e DMARC controlla che almeno un’identità autenticata sia allineata al dominio visibile nel From.
DMARC p=none significa che DMARC non funziona?
No. I messaggi possono superare DMARC, ma p=none indica una politica di monitoraggio che non chiede al destinatario di mettere in quarantena o rifiutare quelli non conformi.
L’autoreply prova che la richiesta è stata letta?
No. Conferma automatica e lettura umana sono eventi diversi. L’autoreply dovrebbe partire soltanto dopo la notifica principale e dichiarare correttamente che la richiesta è stata acquisita.
Il rate limit può bloccare utenti reali?
Sì, se soglie e identificazione sono progettate male. Deve essere proporzionato, considerare reti condivise, non fidarsi di proxy non verificati e permettere una normale correzione degli errori.
Quanto spesso va provato il modulo?
Dopo pubblicazione e modifiche a codice, hosting, DNS, caselle o trasporto; inoltre periodicamente nel piano di manutenzione. Il test deve includere notifica, autoreply, Reply-To, inbox/spam e Authentication-Results.
Prossimo passo
Vuoi un sito che protegga le richieste anche dopo il clic su “Invia”?
Sicurezza, accessibilità, privacy, prestazioni e moduli collaudati fanno parte degli standard tecnici dei siti che realizzo su misura.