Assistenza WordPress specializzata - Consulenza - Web Content

Archivio Tag: SPF

Dimmi che SMTP usi e ti dirò chi sei… (errori SPF con mail inviate a Tiscali)

Posta elettronica di qualità

Il cliente vuole il massimo della qualità nella sua posta elettronica. Vuole che il suo dominio goda del massimo della reputazione, nessuna sua mail deve finire con il marchio infamante dello spam.
Quindi vai di tutte quelle tecniche che ti permettono di tenere alto il buon nome del di lui dominio e server di posta, quindi verifica che l’IP del server mail sia “pulito”, ossia niente blacklist, sistema per benino i DNS con Reverse Lookup e SPF, dato che ci sei mettici pure le firme DomainKeys, testa il tutto e goditi soddisfatto il risultato della tua opera, che ne hai ben donde.

Anche il cliente è soddisfatto.

Poi ti chiama incazzato nero, Tiscali gli ha rifiutato una mail con il seguente errore:

These recipients of your message have been processed by the mail server:
destinatario@tiscali.it; Failed; 5.3.0 (other or undefined mail system status)

    Remote MTA imp-1.mail.tiscali.it: network error

 - SMTP protocol diagnostic: 550 5.1.0 <mittente@dominio.it> SPF Failed - not authorized

C’è da dire che Tiscali, sugli SPF della posta in arrivo, è incarognito forte (peccato non lo sia altrerttanto nella posta in uscita), ma questo non sposta i termini del problema.

Il fatto è che il cliente, per i fatti suoi, ha pensato bene di configurare come server SMTP quello permesso dalla connettività, come si usava una volta, e non quello del suo server mail, vanificando così qualsiasi lavoro fatto per qualificare il dominio di posta elettronica.

C’è da dire che, più o meno, con tutto il resto del mondo le mail vengono consegnate lo stesso, al massimo ti viene assegnato qualche punto positivo ma difficilmente vieni marcato come SPAM. Non con Tiscali, se hai pubblicato un record SPF nei tuoi DNS con l’opzione “disallow”, e non stai utilizzando gli SMTP dichiarati, Tiscali ti rifiuta le mail.
A dirla tutta, Tiscali non fa altro che mettere in praticaalla lettera  le istruzioni pubblicate nei DNS, come sarebbe giusto del resto, altrimenti a che servono?

Morale della favola: se hai DNS e server mail ben configurati, specie se configurati con severità, o un provider che ci tiene al buon nome della posta che esce dai suoi server, usa il server di posta in uscita del tuo servizio di posta elettronica, e non quello della connettività, e insisti se qualcuno cerca di farti fare il contrario. La tua posta elettronica sarà più felice, e avrai meno problemi di consegna.

Utilizzare i server di posta in uscita della connettività era una pratica utilizzata quando le linee erano analogiche, delle vere tartarughe, lo consigliavano anche i provider che ti vendevano il servizio di posta elettronica, così loro risparmiavano banda (molti lo fanno ancora sempre per lo stesso motivo), ma con l’aumentare dello spam e l’innalzamento delle relative barriere difensive è diventato controproducente per la qualità delle mail in uscita, e di conseguenza i recapiti diventano più difficili. Già non si ha mai la certezza assoluta  che un messaggio di posta sia consegnato, se ci si mette di impegno per ridurre queste possibilità è come darsi la zappa sui piedi.
Vale anche se non si utilizzano protocolli particolari come SPF e Domainkeys, le mail che escono dal server SMTP del  dominio sono sempre le più gradite.

Mail firmate e dispositivi mobili

Abbiamo visto in più occasioni come le mail “firmate”, grazie all’utilizzo di strumenti come DomainKeys ed SPF, aiutino a salvaguardare la reputazione del dominio, per quanto riguarda ovviamente la posta elettronica, ed evitare il più possibile che delle mail spedite dal dominio possano essere prese per SPAM, anche solo come falsi positivi.

Spesso però si dimentica, o almeno alcuni lo fanno visto il feedback che sto ricevendo, che questo vale solo se le mail vengono inviate utilizzando il corretto server SMTP, ossia quello dichiarato negli SPF ed abbinato ai DomainKeys. La musica cambia se si utilizza un altro server SMTP o un dispositivo mobile che utilizza un proprio servizio SMTP, un Blackberry ad esempio.

Il servizio Blackberry lavora in modo egregio per quanto riguarda gli SPF, le mail in uscita dai loro server assumono un Return-Path coerente con il server SMTP utilizzato, e tutti i server SMTP di blackberry.com hanno i loro bei record SPF ben dichiarati nei DNS. Tutto verificato.
Giusto per la cronaca, questi sono gli headers di una mail destinata ad un indirizzo gmail.com inviata tramite il mio Blackberry di servizio (ebbene sì ne devo usare uno pure io), con indirizzo mail, IP e server opportunamente camuffati per ovvi motivi:

Return-Path: <SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com>
Received: from smtp05.tris.de.blackberry.com (smtp05.tris.de.blackberry.com [226.53.145.101])
by mx.google.com with ESMTP id 16si4505603qyk.74.2010.01.15.15.57.11;
Fri, 15 Jan 2010 15:57:11 -0800 (PST)
Received-SPF: pass (google.com: domain of SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com designates 226.53.145.101 as permitted sender) client-ip=226.53.145.101;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com designates 226.53.145.101 as permitted sender) smtp.mail=SRS0=TsraiT=JA=quesse.it=robxx@srs.tris.de.blackberry.com

(I riferimenti mail ed IP sono stati modificati per ovvi motivi) Continua a Leggere →

Un nuovo server mail, primi passi per una buona reputazione

server mail

Promemoria: quando si allestisce un server mail e lo si mette in produzione, occorre verificare alcune condizioni, quelle che in linea di massima gli permetteranno di svolgere il suo dovere, ricevere e spedire mail, senza troppi intoppi.

È il primo passo per la costruzione di una buona reputazione del nostro mail server, e di conseguenza del nostro dominio.

La reputazione di un server mail è come la reputazione per gli umani, non è una cosa che si acquisisce come diritto di nascita, ma che va costruita pezzo per pezzo, e quel che è peggio, basta un attimo, una distrazione, per comprometterla.

Vediamo quindi quali sono le prime cose di cui preoccuparsi, prima e durante l’installazione e la messa in produzione di un server mail. Continua a Leggere →

SPF maldestri e AntiSPAM ingannati

Posta elettronica, server mail e AntiSPAMAbbiamo già parlato degli SPF come sistema per combattere lo SPAM, uno dei tanti (che in qualche modo funziona), abbiamo visto come spesso non viene preso in considerazione come meriterebbe.
Oggi invece vediamo chi il sistema SPF lo utilizza in modo maldestro, speriamo senza saperlo, e i danni che causa a chi lotta giornalmente per tenere le mailbox pulite da tanta spazzatura.
Ma facciamo un passo indietro, per capire come sono arrivato fin qui.

Controllando alcuni log dei server mail che amministro, per cercare di capire come mai da certi domini mi arrivava una discreta mole di SPAM, ho imparato una cosa davvero buffa. Magari buffa no, bizzarra di sicuro, magari torna pure utile a qualcun altro.

Controllando più a fondo, per certi domini notavo che c’era una anomalia, che poi tanto anomalia in realtà non era,  nella fase di controllo dell’SPF, dove si evidenziava che l’IP non faceva parte di quelli indicati nei DNS, ma nello stesso tempo non era nemmeno vietato, guadagnandosi così lo stato di SPF_neutral e permettendo di fatto, almeno per quel controllo, di passare indenne.

Received-SPF: neutral (servermail: xxx.xxx.xxx.xxx is neither permitted nor denied by domain of libero.it)

Incuriosito, sono andato a controllare gli SPF impostati per i domini in questione, verizon.net e libero.it per citarne un paio di quelli grossi.

Gli SPF configurati per libero.it:
libero.it. 63236 IN TXT “v=spf1 ip4:212.52.84.101/32 ip4:212.52.84.102/31 ip4:212.52.84.104/29 ip4:212.52.84.112/32 ip4:212.52.84.43/32 ?all”

Gli SPF configurati per verizon.net:
verizon.net text “v=spf1 ip4:206.46.232.0/24 ip4:206.46.170.0/24 ip4:206.46.252.0/24 ip4:206.46.128.33 ip4:206.46.128.101 ip4:209.84.13.21 ip4:209.84.13.20 ?all”

Avete già individuato il bandolo della matassa? Se la risposta è no, continuate a leggere. Continua a Leggere →

Verificare la reputazione di un dominio con Gmail

Dopo aver parlato di DomainKeys e di SPF tra i tanti strumenti a disposizione per qualificare la reputazione di un dominio, e di conseguenza dei messaggi di posta elettronica dello stesso, magari ci viene la voglia di verificare se le mail che spediamo godono davvero di buona salute.

Un buon sistema per verificare se abbiamo configurato tutto per bene sul nostro server mail e sui DNS, è mandare una mail ad un qualsiasi account di Gmail e controllare le intestazioni della mail ricevuta.

Chi è che non dispone di un account Gmail, oggi come oggi?
Se qualcuno dovesse rispondere “io”, l’unico consiglio che gli si può dare è quello di crearsene uno, gli tornerà molto utile per tante cose, non solo per quella che andiamo a vedere oggi e nemmeno per il fato di avere un ulteriore, e pure ottimo, account di posta elettronica.

Dopo esserci mandati una mail sul nostro bell’account Gmail dal dominio che vogliamo verificare, andiamo a dare un’occhiata al suo codice sorgente, o alle sue intestazioni che è lo stesso.
A seconda del client di posta elettronica utilizzato c’è sempre una voce che porta al codice sorgente del messaggio, o alle sue intestazioni nascoste, intestazioni complete o come vorrà chiamarle.
Continua a Leggere →