Posta dal Suo sito web e dai moduli di contatto

Modulo 7: Newsletter e posta dal Suo sito web · Tempo di lettura: 11 minuti

Obiettivo formativo: dopo questa lezione saprà configurare la posta del sito web (moduli di contatto, conferme d'ordine, notifiche di WordPress) in modo che arrivi a destinazione, non crei problemi di DMARC e non esponga il Suo pacchetto ad abusi.

Concetti chiave: PHP mail(), SMTP con autenticazione, mittente della busta (envelope), From vs. Reply-To, l'indirizzo del visitatore mai come From, plugin SMTP, posta transazionale, spam tramite moduli, captcha, honeypot, limite di invio, consegna locale quando l'MX punta altrove

Anche il Suo sito web è un programma di posta

Il Suo sito web invia più posta di quanto pensi. Un modulo di contatto Le invia ogni messaggio ricevuto. Un negozio online invia conferme d'ordine, fatture e notifiche di spedizione. WordPress invia messaggi in caso di un nuovo commento, un aggiornamento o un reset della password. Per il destinatario si tratta semplicemente di posta proveniente dal Suo dominio, e viene controllata con lo stesso rigore della posta inviata dalla Sua casella: SPF, DKIM, DMARC, reputazione.

Tuttavia la posta del sito web presenta problemi più spesso della posta normale. Ciò dipende generalmente da una di queste tre cause: il metodo di invio, l'indirizzo del mittente, oppure un abuso del modulo.

Metodo 1: PHP mail()

Il modo più semplice per un sito web di inviare posta è la funzione PHP mail(). In questo caso il sito web consegna la posta direttamente al programma di posta del server web, senza autenticarsi. Di solito funziona, ma presenta diversi svantaggi:

• Il mittente della busta (Return-Path) diventa spesso l'account di sistema del Suo pacchetto, ad esempio utente@server.hosting.example, e non il Suo indirizzo. L'SPF viene quindi verificato per il dominio del server e risulta pertanto non allineato con il Suo dominio From (lezione 7.1).
• Se venga apposta o meno una firma DKIM del Suo dominio dipende dal server. Su alcuni server succede, su altri no.
• Non riceve alcun riscontro. Se la posta non arriva o riceve un bounce, questo finisce sull'account di sistema, che nessuno controlla.
• Nessun limite per modulo. Se il modulo viene usato in modo improprio, il server invia messaggi a Suo nome finché non viene raggiunto il limite del Suo pacchetto.

Metodo 2: SMTP con autenticazione (migliore)

Faccia inviare al Suo sito web allo stesso modo del Suo programma di posta: autenticandosi sul server di posta in uscita con una casella di posta reale, tramite la porta 587 (STARTTLS) o 465 (SSL/TLS), usando l'indirizzo e-mail completo come nome utente (lezioni 1.4 e 2.1). In questo modo:

• il mittente della busta è il Suo indirizzo e la posta viene firmata come la normale posta del Suo dominio;
• i bounce finiscono in una casella di posta che può leggere;
• la posta inviata viene salvata, se lo desidera, nella cartella Inviati;
• può impostare un limite di invio specifico per ciascuna casella.

In WordPress questo si ottiene con un plugin SMTP, che sostituisce la funzione di invio predefinita di WordPress con l'invio tramite SMTP. Inserisce gli stessi dati di un programma di posta: server, porta, protezione, nome utente e password. A tale scopo crei preferibilmente una casella di posta dedicata, ad esempio sitoweb@example.com. Se la password venisse mai rubata, la Sua casella personale resterebbe al sicuro, e potrà vedere a colpo d'occhio quale posta proviene dal sito web.

Per un sito PHP personalizzato esistono librerie che inviano tramite SMTP, come PHPMailer. Inserisca la password in un file di configurazione esterno alla cartella web pubblica, non nel codice di una pagina.

Presso WebOké, i dati per SMTP si trovano nella guida DirectAdmin 8.1, con il nome del server del Suo pacchetto; presso altri fornitori si trovano nella guida o nell'e-mail di benvenuto, e il funzionamento è analogo.

Molta posta transazionale? Utilizzi un servizio dedicato

Se invia centinaia di conferme d'ordine al giorno, conviene utilizzare un servizio transazionale: un servizio di invio dedicato alla posta automatica. Ha una buona reputazione e mostra cosa è accaduto a ogni messaggio. Colleghi il dominio come con un servizio di newsletter (DKIM tramite CNAME, lezione 7.1). Tenga separate la posta transazionale e le newsletter: una campagna fallita non deve compromettere l'e-mail di conferma dei Suoi ordini.

La regola d'oro: l'indirizzo del visitatore non è mai il mittente

Con un modulo di contatto è tentante far inviare la posta "da" parte del visitatore. In questo modo potrebbe cliccare direttamente su Rispondi nel Suo programma di posta. L'aspetto sarebbe questo:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Ma il Suo server non può in alcun modo inviare posta per conto di example.net. Supponiamo che example.net abbia una politica DMARC p=reject. Il server ricevente (il Suo, oppure quello di Gmail se la posta viene reindirizzata) riceve un messaggio con From example.net che non proviene dall'SPF o dal DKIM di example.net, e lo rifiuta. Molti grandi domini di posta applicano una politica severa: in un controllo dell'8 novembre 2026, tra gli altri yahoo.com, aol.com, ziggo.nl e kpnmail.nl avevano una politica DMARC p=reject, e icloud.com, gmx.de e web.de p=quarantine. Un visitatore con un simile indirizzo compila il Suo modulo, e Lei non riceve mai il messaggio, oppure lo trova nella cartella spam. I domini con p=none (come in quel momento gmail.com e hotmail.com) possono inasprire la propria politica in qualsiasi momento, e Google specifica esplicitamente nelle proprie linee guida che non è consentito imitare gli indirizzi Gmail come From. Non faccia quindi mai affidamento sul fatto che tutto vada bene.

Il modo corretto:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Il mittente è il Suo stesso indirizzo, quindi SPF, DKIM e DMARC risultano corretti. L'indirizzo del visitatore si trova nel campo Reply-To. Se clicca su Rispondi, la risposta viene inviata a Pieter. Nella maggior parte dei plugin per moduli trova questa opzione nelle impostazioni della posta: in Mittente (From) imposti un indirizzo fisso del Suo dominio, e in Reply-To il campo in cui il visitatore inserisce il proprio indirizzo.

Proteggere i moduli dagli abusi

Un modulo senza protezione viene prima o poi trovato dai bot. Nel migliore dei casi, Lei riceve spam. Nel peggiore dei casi, lo usano per inviare spam ad altri: se il Suo modulo invia una conferma "all'indirizzo inserito dal visitatore", un bot può inserire lì qualsiasi indirizzo al mondo, con un testo scelto da lui nel messaggio. In tal caso il Suo dominio invia spam, con tutte le conseguenze sulla Sua reputazione (lezione 5.2).

Protezione a più livelli:

• Captcha o un controllo invisibile (come reCAPTCHA o Turnstile) blocca la maggior parte dei bot.
• Honeypot: un campo nascosto che le persone non vedono ma che i bot compilano. Se viene compilato, il messaggio non viene inviato.
• Nessun testo libero in una conferma al visitatore, o nessuna conferma all'indirizzo fornito. Un semplice messaggio "Grazie, abbiamo ricevuto il Suo messaggio" sulla pagina è sufficiente.
• Un limite di invio per casella di posta per la casella del sito web, inferiore a quello del Suo pacchetto.
• Aggiornare il software. I plugin obsoleti sono un punto d'ingresso noto per gli abusi.

Nota che il Suo pacchetto invia improvvisamente molta posta, oppure riceve una notifica che il limite giornaliero è stato raggiunto mentre Lei stesso invia poca posta? Cambi subito le password e verifichi quale modulo o script sta inviando la posta (lezione 3.4).

La posta si trova altrove, il sito web qui

Un errore comune: il Suo sito web si trova presso un fornitore, la Sua posta presso un altro (ad esempio Microsoft 365 o Google Workspace). Il Suo MX punta verso quell'altro fornitore. Ma il server web pensa ancora di gestire personalmente la posta per il Suo dominio, poiché il dominio è presente anche sul proprio pacchetto. La posta del modulo destinata a info@example.com viene quindi consegnata localmente, in una casella di posta sul server web che nessuno controlla, oppure restituisce un errore come 550 ... mailbox unavailable.

La soluzione consiste nell'indicare nel pannello del server web che la posta viene gestita altrove. In DirectAdmin presso WebOké si tratta della casella di controllo "Utilizza questo server per gestire le mie e-mail" presso i Record MX (da disattivare). Altri pannelli hanno impostazioni analoghe, come "instradamento e-mail: esterno" in cPanel. Ancora meglio: faccia inviare il sito tramite SMTP usando una casella di posta presso il fornitore dove risiede realmente la Sua posta.

Riepilogo

• La posta del sito web viene controllata con lo stesso rigore della posta normale. Faccia inviare il sito tramite SMTP con autenticazione, non tramite mail().
• Utilizzi una casella di posta dedicata per il sito web, con un proprio limite di invio.
• L'indirizzo del visitatore va inserito in Reply-To, mai in From. Altrimenti il DMARC fallisce, e presso domini con p=reject (come yahoo.com, ziggo.nl, kpnmail.nl) la posta viene rifiutata.
• Protegga i moduli con captcha, honeypot ed evitando conferme con testo libero agli indirizzi forniti.
• Se la Sua posta si trova presso un altro fornitore, disattivi la consegna locale sul server web oppure invii tramite SMTP presso quel fornitore.

Quiz

Esercizio

Esercizio O7.3: Verificare la posta dal sito web. Compili un modulo sul Suo sito web inserendo un indirizzo Gmail o Outlook.com come mittente e osservi le intestazioni del messaggio che Le arriva. Risponda alla checklist: quale indirizzo compare in From, l'indirizzo del visitatore è presente in Reply-To, cosa indicano spf=, dkim= e dmarc= in Authentication-Results, il Suo sito invia tramite SMTP o tramite mail(), e il modulo dispone di captcha o honeypot? Se non ha un proprio sito web, risponda alle domande facendo riferimento all'esempio di questa lezione. Riceverà poi la risposta modello.

Per approfondire

I passaggi descritti in questi articoli si riferiscono ai pannelli di WebOké; presso altri fornitori il funzionamento è analogo.

• Un modulo di contatto sul Suo sito web: come inviare i campi via email e prevenire lo spam
• Come ottengo il mittente corretto in PHP con mail()? SMTP
• L'invio di e-mail tramite PHP non funziona, i record MX puntano altrove
• Limite per l'invio di email
• Limite giornaliero di e-mail raggiunto
• Guida DirectAdmin 8.1: Tutte le impostazioni in un colpo d'occhio: server, porte e sicurezza
• Guida DirectAdmin 5.10: E-mail con Microsoft 365 o Google Workspace, sito web presso WebOké