Archivio Tag: DNS

Quando la newsletter finisce nella posta indesiderata

Newsletter in SPAM impostare i DNS corretti

Stai utilizzando un servizio di newsletter professionale, ma le tue newsletter finiscono comunque nello SPAM, nella posta indesiderata?

Magari non tutte, ma se succede anche solo per pochi destinatari è sempre un grande fastidio se non peggio, delle occasioni mancate di contatto o di business.

Il problema potrebbe essere che non hai configurato i tuoi DNS in modo appropriato, seguendo le indicazioni del servizio di newsletter.

Servizi come MailChimp (il mio preferito), AWeber o MailUp, giusto per citare qualcuno tra i più noti, offrono buone garanzie di consegna, ma occorre attenersi alle loro indicazioni tecniche per ridurre al minimo il rischio di finire nelle famigerate cartelle di posta indesiderata.

In parole povere, se le tue newsletter vengono inviate con un indirizzo del tuo dominio, come avviene nella maggior parte dei casi, devi avvisare gli antispam dei destinatari che il servizio che stai utilizzando è autorizzato ad inviare posta elettronica per il tuo dominio. Continua a Leggere →

Ottimizzazione PHP, Geolocalizzazione IP e compressione web su hosting OVH

Ottimizzazione PHP su Hosting OVH

Di recente ho a che fare con OVH, fornitore internazionale di servizi Internet apprezzato anche qui in Italia, per alcune installazioni su hosting condiviso con profili diversi, sia personali che business.

Può succedere in un hosting di tipo “Personale”, ad esempio, che sovrascrivendo inavvertitamente il contenuto originale del file .htaccess, o cancellando il file stesso, le ultime versioni di WordPress si rifiutino di lavorare, con un messaggio di errore che il PHP utilizzato è troppo vecchio e non supportato.

Questo perché gli hosting condivisi di OVH dispongono di diverse versioni di PHP, dalla 4.4.9 alla 5.4.6 (al momento di scrivere queste note), e nei profili personali, se non indicato diversamente nel file .htaccess, la versione di default è la 4.4.9, inutilizzabile con le versioni recenti di WordPress.

Nei profili business invece, mi pare di capire che la versione di default di PHP sia la 5.2.17. Continua a Leggere →

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.

Prima di tutto la Risoluzione Inversa

Postmaster

Parliamoci chiaro, te che ti vuoi mettere un server mail in ufficio: se non rispetti alcune regole basilari, farai un solo un gran casino e poi non ti venire a lamentare qui che le tue mail ti tornano indietro, rifiutate come si rifiuta la presenza di un appestato.

La prima di queste regole fondamentali, è che i server si devono presentare tra di loro, e non devono cercare di spacciarsi per chi non sono, come spesso fanno gli spammer. Buone maniere e sincerità sono alla base di una buona comunicazione anche nella vita reale, o no?

I server mail, quando iniziano a parlare fra di loro prima di cominciare a scambiarsi messaggi di posta, si pongono alcune domande. Anzi è il server di destinazione che le pone al mittente, per verificare che sia davvero un server di posta “perbene” come vorrebbe far credere, che non sia uno spammer o peggio ancora un untore.

Dialogo tra server SMTP:

  • Mittente: “Ciao, devo mandarti un paio di mail per i tuoi utenti!”
  • Destinatario: “Si OK, però prima fa il bravo e dimmi chi sei…”
  • Mittente “Giusto, presentarsi è da serverini ben educati, io mi chiamo mail.cicciabombacanottiera.it”

Il server del destinatario, che non è uno scemo, ha già memorizzato l’indirizzo IP del server del mittente e zitto zitto effettua immediatamente due prove per stabilire che il server del mittente sia effettivamente chi dica di essere.

  1. Come prima verifica, si accerta che al nome host dichiarato corrisponda effettivamente l’indirizzo IP con cui si presenta.
  2. La seconda verifica è la classica prova del nove, verifica cioè che all’IP con cui il server mittente si è collegato corrisponda esattamente il nome host di cui sopra.

In pratica, se al nome mail.cicciabombacanottiera.it è stato assegnato l’IP 123.123.123.123, e questo deve essere convalidato dai DNS, all’indirizzo IP 123.123.123.123 deve corrispondere dell’host, mail.cicciabombacanottiera.it.

Record A, Record PTR, Risoluzione Inversa…

Le due prove sono banali interrogazioni ai server DNS, la prima chiede il record A di un dato nome host, la seconda chiede il record PTR di un indirizzo IP, entrambe devono corrispondere, ma un peso maggiore viene dato in genere al secondo test, per una serie di motivi che magari spiegherò in un secondo tempo.

Succede, e pure molto frequentemente, che chi decide di mettersi in casa un mail server si preoccupa, per forza di cose, di far assegnare un nome all’indirizzo IP pubblico destinato al server, un Record A affinché il server mail sia raggiungibile dal mondo. Per forza di cose, dicevo, altrimenti non riceverebbe una beata fava da nessuno…

L’improvvisato postmaster però non si preoccupa di far assegnare un record PTR all’IP da chi gli fornisce la connessione.  Se ha fortuna, ma capita di rado, la connessione e i DNS sono gestiti dalla stessa azienda, e il responsabile della gestione dei DNS, quando riceve la richiesta del Record A capisce che è importante associare anche il Record PTR. Santuomo…

È vero anche (e va detto, sic!) il problema contrario, ossia che molti mail server non effettuano o non considerano il test del reverse check come un errore, come dovrebbe essere, il più delle volte per una configurazione discutibile o frettolosa, e si lasciano recapitare porcherie da chiunque. Postmaster maldestri…

Morale della favola: i server mail non devono accettare missive dagli sconosciuti, e gli aspiranti postmaster devono preoccuparsi, prima di mettere in produzione un server mail, di avere un indirizzo IP ben configurato nei DNS, con tanto di Risoluzione Inversa.

Non è finita qui, ma il resto lo vediamo poi, un pezzo per volta…

Mentre ero arrivato ormai alla fine della stesura di questo post, mi sono accorto che avevo già scritto riguardo Indirizzi IP e  Risoluzione Inversa. La memoria non è più quella di una volta.
Poco male, repetita iuvant…

Google vuole la velocità sul web – 1

google girl

Non è un mistero che la grande G miri ad un web più veloce, tanto che, nelle indicizzazioni  dei siti nel suo motore di ricerca, non è un mistero che prestazioni scarse di caricamento della pagina sono fonte di penalizzazioni.

Nulla di preoccupante per i webmaster ed i blogger, perché si parla di 30 secondi come limite di caricamento di una pagina, ma di fatto l’intenzione c’è.

DNS di Google, DNS veloci e sicuri

Google ha reso disponibili da poco i suoi Server DNS pubblici, una alternativa a quelli del proprio provider di connettività, solitamente consigliati per la “vicinanza” e quindi per le prestazioni, ed ai già famosi OpenDNS.
Quelli di Google  puntano direttamente alle prestazioni ed alla sicurezza, due argomenti che fanno sicuramente breccia sui naviganti…

C’è il rovescio della medaglia, se vogliamo. Google è già sotto accusa perché risaputamente avida di informazioni sulle abitudini dei naviganti in rete, talvolta il dubbio su presunte violazioni della Privacy è più che lecito, e certo il controllo dei DNS non aiuta certo a smorzare le polemiche, anzi.
Ma torniamo all’aspetto pratico.

Come fare ad usare i nuovi DNS di Google?

Semplicissimo, basta impostare nelle preferenze di rete dei propri computer (o dispositivi mobili) i seguenti numeri IP, indifferentemente come DNS Server primari o secondari

  • 8.8.8.8
  • 8.8.4.4

Sono pure facili da ricordare, e ad una prima impressione sono davvero veloci come promettono.
Sulla sicurezza ovviamente vedremo in seguito, ma per gli uomini di Google questo è un tasto a cui tengono molto, per ovvi motivi, e magari c’è da stare relativamente tranquilli.

Qualcuno li ha provati? Che ne dite?

Ciao, come posso aiutarti?
Powered by