Perché il tuo modulo di contatto è il tuo maggiore rischio di spam

Il problema è più vecchio di quanto pensi

I moduli di contatto sono un vettore di spam dai primi anni 2000, ma il problema è peggiorato man mano che i provider email hanno irrigidito i requisiti di autenticazione. La maggior parte dei moduli di contatto è ancora costruita nello stesso modo: l’utente compila un modulo, il tuo server invia un’email usando l’indirizzo dell’utente nell’header From, e tu attendi le risposte.

Questa è una vulnerabilità classica di spoofing email. Gli spammer possono usare il tuo modulo per inviare email che sembrano provenire da qualunque indirizzo vogliano, instradate attraverso l’IP del tuo server. Se viene inviato abbastanza spam in questo modo, il tuo dominio viene segnalato e le tue email transazionali legittime smettono di raggiungere le caselle di posta.

La correzione è semplice, ma la maggior parte dei tutorial continua a sbagliare.

Cosa rende i moduli di contatto così facili da sfruttare

Un modulo di contatto tipico accetta tre campi: nome, email e messaggio. L’handler lato server prende quell’indirizzo email e lo inserisce direttamente nell’header From di un messaggio SMTP in uscita. È comodo per le risposte: puoi semplicemente premere "rispondi" nella tua casella di posta, ma è anche un regalo per gli spammer.

Ecco cosa succede quando uno spammer trova il tuo modulo:

1. Invia il modulo con l’indirizzo email di una vittima nel campo "from"
2. Il tuo server invia diligentemente un’email con l’indirizzo della vittima nell’header From
3. Il server di posta della vittima vede un’email che dichiara di provenire dal suo dominio, ma che ha origine dal tuo IP
4. Se il tuo dominio non ha record SPF/DKIM/DMARC corretti (o anche se li ha), l’email può comunque passare perché molti server sono permissivi con il traffico dei moduli di contatto
5. La vittima riceve spam che sembra provenire dal proprio indirizzo, oppure il tuo dominio viene segnalato per spoofing

Non è un attacco teorico. Succede continuamente. Se gestisci un modulo di contatto e non hai mai controllato i log del tuo server di posta, probabilmente sei già usato in questo modo.

Il modo corretto di inviare email dai moduli di contatto

La correzione consiste nel non inserire mai input utente nell’header From. Invece:

• From: [email protected] (o qualunque indirizzo che controlli)
• Reply-To: l’indirizzo email inviato dall’utente
• Subject: includi il nome dell’utente se vuoi, ma mai la sua email
• Body: includi tutti i dati del modulo, chiaramente etichettati

In questo modo, il tuo server invia email solo da indirizzi che possiedi e che hai autenticato correttamente. Quando premi "rispondi" nella tua casella, la risposta va comunque all’utente: è questo lo scopo di Reply-To. Ma gli spammer non possono usare il tuo modulo per impersonare indirizzi arbitrari.

La maggior parte delle librerie email supporta questo comportamento nativamente. In PHPMailer di PHP:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

In smtplib di Python con email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

In Node.js con Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Se il tuo modulo di contatto attualmente inserisce input utente nell’header From, questa è una correzione di una riga. Fallo oggi.

La limitazione della frequenza non è opzionale

Anche con una corretta igiene degli header, un modulo di contatto non protetto resta un vettore di spam. Gli spammer invieranno il modulo centinaia di volte con corpi del messaggio diversi, e la tua casella si riempirà di spazzatura.

Hai bisogno di limitazione della frequenza su più livelli:

• Per IP: non più di 5 invii all’ora dallo stesso IP
• Per email: non più di 3 invii al giorno dallo stesso indirizzo email
• Globale: non più di 50 invii all’ora tra tutti gli utenti (regola il valore in base al tuo traffico)

La limitazione della frequenza deve stare nel codice della tua applicazione, non solo nella configurazione del web server. La limitazione della frequenza di Nginx e Apache può aiutare, ma opera a livello di richiesta e non conosce indirizzi email o pattern di abuso specifici del modulo.

Se usi un framework, probabilmente esiste un middleware di rate limiting che puoi inserire. Se stai costruendo da zero, un semplice contatore Redis con chiavi a scadenza funziona bene:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Non è a prova di tutto: gli spammer possono ruotare gli IP, ma aumenta in modo significativo il costo dell’abuso.

I CAPTCHA sono un compromesso, non una soluzione

reCAPTCHA v3 di Google è invisibile e assegna un punteggio agli utenti in base al comportamento, il che sembra ideale. In pratica, blocca utenti legittimi più spesso di quanto ci si aspetti, soprattutto utenti su VPN, Tor o reti aziendali condivise.

reCAPTCHA v2 (la casella "Non sono un robot") è più affidabile ma aggiunge attrito. I campi honeypot — input nascosti del modulo che gli esseri umani non compileranno ma i bot sì — intercettano bot poco sofisticati senza alcun impatto sull’utente, ma sono banali da aggirare per qualunque spammer serio.

L’approccio migliore è a livelli:

1. Header email corretti (non negoziabile)
2. Limitazione della frequenza (non negoziabile)
3. Campo honeypot (vittoria facile, nessuno svantaggio)
4. CAPTCHA solo se ricevi ancora spam significativo dopo quanto sopra

Se aggiungi un CAPTCHA, usa reCAPTCHA v3 con una soglia bassa (0,5 o inferiore) e un fallback a v2 per gli utenti con punteggio basso. Questo mantiene basso l’attrito per la maggior parte degli utenti, continuando a bloccare i bot.

Quando usare un servizio di moduli di terze parti

Se gestisci un sito piccolo e non vuoi mantenere un’infrastruttura per i moduli, servizi di terze parti come Formspree, Tally o Netlify Forms gestiscono tutto questo per te. Limitano la frequenza, validano e inviano email dai propri domini, quindi la tua reputazione resta pulita.

Il compromesso è che stai inviando dati utente a una terza parte, cosa che può entrare in conflitto con la tua informativa sulla privacy o con gli obblighi GDPR. Elaborare i dati lato client è una tendenza in crescita per i team attenti alla privacy, ma i moduli di contatto richiedono intrinsecamente elaborazione lato server: non puoi inviare email dal browser senza esporre credenziali.

Se gestisci richieste sensibili (legali, mediche, finanziarie), probabilmente devi eseguire una tua infrastruttura per i moduli. Per tutto il resto, un servizio di terze parti è una scelta ragionevole.

Il problema DMARC

Anche se correggi gli header del tuo modulo di contatto, non sei al sicuro se il tuo dominio non ha una policy DMARC. DMARC dice ai server di posta riceventi cosa fare con le email che non superano i controlli SPF o DKIM. Senza, gli spammer possono ancora inviare email che sembrano provenire dal tuo dominio, anche se non usano i tuoi server.

Configurare DMARC è fuori dall’ambito di questo articolo, ma se prendi sul serio la reputazione email, non è negoziabile. Inizia con una policy di solo monitoraggio (p=none) e passa gradualmente a p=quarantine o p=reject man mano che verifichi che la tua email legittima sia autenticata correttamente.

E Consenso cookie e tracciamento dei moduli?

Se il tuo modulo di contatto usa analytics o pixel di marketing per tracciare gli invii, probabilmente sei soggetto alle regole GDPR ed ePrivacy. La maggior parte dei moduli di contatto non ha bisogno di tracciamento: sai già che qualcuno ha inviato il modulo perché hai ricevuto l’email, ma se usi qualcosa come Facebook Pixel o eventi Google Analytics, ti serve consenso esplicito prima che quegli script vengano caricati.

L’approccio più semplice è non tracciare affatto gli invii dei moduli di contatto. Se devi tracciarli, carica gli script di tracciamento solo dopo il consenso dell’utente e assicurati che il tuo banner di consenso sia conforme.

Punti chiave

• Non inserire mai indirizzi email forniti dagli utenti nell’header From. Usa invece Reply-To.
• La limitazione della frequenza è obbligatoria. Implementala a livello applicativo, non solo sul web server.
• I campi honeypot sono un vantaggio gratuito. I CAPTCHA dovrebbero essere l’ultima risorsa.
• I servizi di moduli di terze parti sono una scelta ragionevole per siti piccoli, ma introducono compromessi sulla privacy.
• Se invii qualunque email dal tuo dominio, hai bisogno di una policy DMARC.

FAQ

Q: Posso semplicemente disattivare il modulo di contatto e usare invece un link mailto?

A: Puoi, ma i link mailto espongono il tuo indirizzo email agli scraper e perdi la possibilità di raccogliere dati strutturati. Se lo spam è ingestibile, un link mailto è meglio di un modulo di contatto rotto, ma correggere il modulo è meglio di entrambi.

Q: E se avessi bisogno di inviare email dall’indirizzo dell’utente per motivi legittimi?

A: Quasi certamente non ne hai bisogno. Se pensi di sì, probabilmente stai cercando di risolvere un problema di workflow (come l’instradamento delle risposte) che Reply-To risolve già. Se hai davvero bisogno di inviare email da indirizzi arbitrari, ti serve un servizio email dedicato con autenticazione corretta, non un modulo di contatto.

Q: Come faccio a sapere se il mio modulo di contatto è già abusato?

A: Controlla i log del tuo server di posta per le connessioni SMTP in uscita. Se vedi un volume elevato di email in uscita verso indirizzi che non riconosci, o se il tuo dominio è stato segnalato da database antispam come Spamhaus, probabilmente vieni usato come relay. Strumenti come MXToolbox possono controllare la reputazione del tuo dominio.

Q: È sicuro usare un servizio CAPTCHA gratuito?

A: reCAPTCHA di Google è gratuito e ampiamente usato, ma invia dati utente a Google, cosa che può entrare in conflitto con la tua informativa sulla privacy. hCaptcha è un’alternativa orientata alla privacy che non addestra modelli AI sui tuoi utenti. Cloudflare Turnstile è un’altra opzione meno intrusiva dei CAPTCHA tradizionali.

Q: Qual è la differenza tra SPF, DKIM e DMARC?

A: SPF elenca quali server di posta sono autorizzati a inviare email dal tuo dominio. DKIM firma crittograficamente le email in uscita così che i destinatari possano verificare che non siano state manomesse. DMARC li collega e dice ai destinatari cosa fare se un’email non supera i controlli SPF o DKIM. Ti servono tutti e tre per una corretta autenticazione email.

Fonti

• OWASP: Email Header Injection — Spiegazione dettagliata di come i moduli di contatto possano essere sfruttati per lo spoofing email.
• RFC 5322: Internet Message Format — Lo standard tecnico che definisce gli header email, inclusi From e Reply-To.
• DMARC.org: Overview — Risorsa ufficiale per comprendere e implementare le policy DMARC.
• Spamhaus: Domain Blocklists — Controlla se il tuo dominio è stato segnalato per spam e comprendi come funzionano le blocklist.