domenica 23 marzo 2014

IP nuovo, vita nuova?


La lotta allo spam sta diventando sempre più serrata, le blacklist si inventano tecniche sempre più sofisticate per individuare (e bloccare) gli spammer, e quindi se vogliamo gestire in proprio il nostro server email dobbiamo imparare a fare le cose per benino, configurandolo correttamente da subito...

In particolare se si tratta di un server "nuovo" e che utilizza un IP "vergine" (ossia un IP che in precedenza non è mai stato utilizzato per l'invio di email), è di fondamentale importanza partire bene da subito: ovvero, prima dell'invio della prima mail, il server dovrà essere configurato correttamente, completo anche di DKIM ed SPF: altrimenti, l'inserimento immediato nelle blacklist dei grossi provider è quasi garantito.


martedì 18 marzo 2014

Perché non tutti i server DNS funzionano per i domini .it?


Negli helpdesk dei Registrar, o nei forum specializzati capita frequentemente una segnalazione in merito a problemi di configurazione di server DNS per i domini .it (un esempio recente qui... ma con google potreste trovarne dozzine, se non centinaia!!!); una segnalazione che si può efficacemente riassumere con:

Ci sono questi server DNS che ho SEMPRE usato per tutti i miei domini, che funzionano BENISSIMO, che non hanno MAI avuto alcun problema... ed allora perché ho sempre rogne se voglio usarli per un dominio .it?

Ed il lamento prosegue cercando di attribuire la colpa al Registrar, al nic.it, o ad oscure congiunzioni astrali...

E' il caso di specificare un concetto che, molto spesso, sfugge:

Il nic.it, prima di registrare un dominio assegnandolo a determinati server DNS, oppure prima di accettare che i server DNS già attivi per un certo dominio vengano sostituiti con altri, esegue sui "nuovi" server DNS alcuni test.
E se questi test non vengono superati, l'operazione non viene effettuata.
Quindi:

  • se si tratta di una nuova registrazione, il nic.it andrà avanti per un po' di tempo ad effettuare il test; se i server DNS continuano a non superarlo, ad un certo punto il nic.it cancellerà semplicemente la registrazione, il dominio tornerà ad essere libero per una nuova registrazione, e chi s'è visto s'è visto;
  • se si tratta invece di sostituire i server DNS per un dominio già registrato, il nic.it continuerà ad eseguire i test dino a che non saranno superati; nel frattempo, resteranno sempre attivi i nuovi server DNS.
    Dopo un po' di tempo, se i server DNS continueranno a non superare il test, allora il nic.it abbandonerà l'operazione ed il dominio resterà con i vecchi server DNS
Chiaro?

Vediamo adesso alcuni dettagli:

In cosa consistono i test eseguiti dal nic.it sui server DNS?

I requisiti sono i seguenti:
  • i server DNS autoritativi per il nic.it devono essere almeno 2 (due) e devono corrispondere esattamente a quelli presenti nella registrazione del nome a dominio;
  • gli indirizzi IP degli host presenti nella registrazione del nome a dominio devono  corrispondere a quelli ad essi realmente associati nel DNS;
  • al nome a dominio non può essere associato un record CNAME;
  • il nome del nameserver specificato nel record SOA non può essere un CNAME;
  • i nomi dei nameserver autoritativi per il nome a dominio non possono essere dei CNAME;
  • al record MX, eventualmente presente, non può essere associato un CNAME;
  • durante la procedura di controllo, nessuno dei server DNS deve dare alcuno dei seguenti esiti:
    Not responding
    Not reachable
    Not running
    Non-existent domain
    Host not found
    Server failure
    Query failed
  • tutti gli host presenti nella registrazione devono essere autoritativi per il nome a dominio registrato.

Come faccio a verificare che i miei server DNS sono correttamente configurati?

Una volta il nic.it forniva un tool on-line di verifica e diagnosi dei server DNS; purtroppo questo tool non è più pubblico, ma è solo a disposizione dei Registrar.
Quindi, per verificare i nostri server DNS il modo più semplice è, ovviamente, quello di lasciare che il nic.it faccia il test: se i server DNS sono correttamente configurati, il test verrà superato e quindi significa che è tutto OK.
In alternativa, se vogliamo fare una diagnosi approfondita, dovremmo chiedere al nostro Registrar. Ma ovviamente ciò può portare a qualche problema: non tutti i Registrar sono disponibili a farlo, non tutti sono disponibili a farlo gratis, e non tutti ancora sono disponibili a farlo velocemente...
(Peraltro, bisogna anche capirli: un Registrar solitamente mette a disposizione dei server DNS funzionanti; se noi vogliamo usare i nostri server DNS anziché quelli del Registrar, perché lo stesso dovrebbe farsi carico - gratis e velocemente - delle rogne relative ai NOSTRI server DNS?)
Esistono una serie di tools gratuiti on line che ti permettono di verificare la configurazione dei DNS (quali ad esempio dnsqueries.com), ma obiettivamente non ne ho trovato ancora uno completo ed approfondito come quello del nic.it...
Il problema principale è che i normali tool disponibili in rete fanno un controllo dello stato dei DNS per i server DNS già impostati dal Registro come autoritativi; mentre a noi spesso interessa effettuare il test di confromità per dei server DNS che NON sono ancora riconosciuti dal Registro come autoritativi...
Se voi conoscete qualche tool diagnostico valido e che risolva questo problema, pls segnalatemelo nei commenti.

Per quanto tempo il nic.it testerà i server DNS prima di bocciarli?

Per cinque giorni.
Se al termine dei cinque giorni i nuovi server DNS non avranno superato il test, la richiesta verrà cancellata.

Ma perché i miei server DNS funzionano benissimo per i gTLD e danno problemi solo con i .it?

Semplice. Per i gTLD non viene effettuato NESSUN test: quindi, i server DNS possono essere malconfigurati, non rispondere, o anche non esistere proprio... e nessuno se ne accorgerà (tranne, ovviamente, chi cercherà il tuo sito).
Ma il Registro non recriminerà certamente.
Viceversa, per i .it il nic.it pretende (giustamente) che i server DNS siano perfettamente configurati.
Quindi, non è che "danno problemi solo per i .it": il problema c'è per tutti i domini gestiti attraverso quei DNS, solo che magari non ce se ne accorge... ma il problema c'è e resta, e magari si tradurrà in saltuari ed apparentemente casuali problemi di propagazione, o da altri ed apparentemente casuali che poi tenderemo a sottovalutare... "Capitano solo a te, nessun altro segnala problemi del genere..."

  

lunedì 17 marzo 2014

Il tuo dominio .it è al sicuro?



Vi esporrò oggi un aspetto abbastanza delicato relativo alla registrazione e gestione dei domini .it.
E' un aspetto che coinvolge direttamente la sicurezza del dominio e che, pur non rappresentando una vera e propria vulnerabilità, essendo per lo più sottovalutato se non addirittura ignorato, costituisce almeno una grave criticità.

Andiamo con ordine.

Per poter trasferire presso un altro Registrar un dominio .it, è necessario un codice alfanumerico (cosiddetto "authinfo", o "authcode"). Ovvero, al nuovo Registrar dobbiamo fornire questo codice, altrimenti trasferire il dominio sarà impossibile.
Fino a qui nulla di strano: questo meccanismo è comune a moltissimi altri ccTLD ed ai gTLD

Però ci sono due dettagli che differenziano il meccanismo di trasferimento dei domini .it rispetto a quello (universalmente noto) dei gTLD:

  1. nei domini .it, il codice authinfo viene generato dal Registrar all'atto della registrazione/trasferimento del dominio, e viene immediatamente comunicato a mezzo email al Registrante (nei gTLD invece di norma il Registrante lo deve esplicitamente richiedere al Registrar, che comunque è obbligato a fornirlo entro 5 giorni dalla richiesta)
  2. nei gTLD, dopo aver avviato il trasferimento presso un altro Registrar fornendo l'authinfo, il Registrante dovrà dare un'ulteriore conferma a mezzo email (normalmente, il Registrante riceve un'email con un link: se clicca sul link dà conferma del trasferimento, altrimenti lo stesso, pochi giorni dopo, viene abbandonato e fallisce)
La prima criticità è che il codice authinfo viene fornito al Registrante immediatamente, al momento della registrazione.
Se tutti i Registranti fossero ben consci dell'importanza di questo codice, non ci sarebbe alcun problema; però in realtà ciò non è. Moltissimi Registranti non sanno neppure cosa sia, né a cosa serva, e quindi non lo conservano con le dovute attenzioni. Nel migliore dei casi si limiteranno a lasciare la relativa email in mezzo alle altre, senza cancellarla e senza proteggerla in nessuna maniera particolare.
Però un archivio email è soggetto a tantissime vulnerabilità: può esser violato da un virus o da un malware, oppure può capitare che se ne dia l'accesso (magari ripromettendosi che sia solo "temporaneamente") ad un collega, ad un tecnico, ad un amico, a quella che oggi è nostra moglie ma domani diventerà "la nostra ex moglie"... in tutti questi casi queste figure avranno la possibilità di accedere al codice authinfo, di un dominio che magari abbiamo registrato tre anni prima... e, nel momento del bisogno, potrebbero decidere di farne un uso illecito.

La seconda criticità consiste nel fatto che dopo l'avvio di un trasferimento non viene richiesta nessuna conferma via email al Registrante; quindi, questi non ha la possibilità di bloccarlo o anche solo di accorgersene fino a che non sarà troppo tardi.

Facciamo un esempio concreto.

Voi oggi registrate un dominio .it presso il Registrar $Registrar1.
Come email di riferimento indicate la vostra email personale, quella che utilizzate normalmente ogni giorno, e che consultate quotidianamente dal notebook, dallo smartphone, dal PC dell'ufficio e financo - via webmail - ogni tanto anche da PC "altri" (quello di un amico presso cui siete in ferie, quello di un cybercafè ecc.)
$Registrar1 vi manda - correttamente - il codice authinfo. Voi lo vedete, sovrappensiero ci chiedete "Cos'è 'sta roba?", e lo dimenticate là. O al massimo, se siete ordinati, lo spostate in una cartella apposita.

Nel corso dei tre anni successivi, possono capitare uno (o più di uno) dei seguenti episodi:
  • uno qualsiasi degli apparati utilizzati (compreso il PC del cybercafè...) viene infettato da un virus
  • il vostro notebook va in assistenza, ed al tecnico fornirete la password di accesso
  • vi siete trovati nella necessità di comunicare la password dell'email ad un collega, che vi sostituisce durante un periodo di ferie o malattia
  • vi hanno rubato (o avete smarrito) lo smartphone
  • durante un viaggio all'estero, vi siete collegati ad internet per controllare la posta; e lo avete fatto attraverso una rete wi-fi che avete trovato "aperta" (compiacendovi tra di voi perché siete riusciti a "navigare gratis", senza pagare il salatissimo conto del roaming...)
  • ... o altre dozzine di episodi simili
In tutte queste situazioni, qualcuno avrebbe potuto ottenere l'accesso alla vostra email e, quindi, accedere anche al codice authinfo del vostro dominio. E magari annotarselo, per farne eventualmente uso alla bisogna... "non si sa mai".
O magari il vostro collega, dopo essersi collegato alla vostra mail, ha sbadatamente conservato sul proprio PC una copia completa degli archivi, e dopo il PC gli è stato rubato, o affidato ad un altro collega (che magari ce l'ha con voi per motivi personali) senza stare troppo a badare su quello che c'era e non c'era su quel PC... insomma, le possibilità a questo punto sono pressoché infinite.

Quindi, partiamo dal presupposto: un malintenzionato (che può essere l'autore di un virus, un vostro collega o ex-collega che non vi vuole bene, la vostra ex-moglie, il tecnico del PC a cui non avete pagato una fattura, ecc. ecc.) a questo punto ha l'authinfo del vostro dominio.
Cosa deve fare?
Semplice: scegliersi un altro Registrar accreditato (che chiameremo $Registrar2) accreditato, chiedere il trasferimento del dominio fornendo il relativo authinfo e, nell'occasione, cambiando i dati del registrante (con altri falsi, fittizi, o con dati veri ed effettivi di una persona qualsiasi, del tutto inconsapevole).

A questo punto, a meno che non ve ne accorgiate per puro caso, il dominio sarà trasferito, e sarà controllato dal malintenzionato.
E dico che ve ne potete accorgere solo per puro caso perché, di norma, non viene inviato al Registrar nessun avviso del tipo "guarda che stiamo trasferendo il tuo dominio"... e la cosa si scopre di solito quando ormai la frittata è fatta.
Inoltre, il tempo per accorgersene è anche molto limitato: al massimo tre giorni (ma possono anche esser di meno). E, anche se ve ne accorgete, non è detto che $Registrar1 sia disposto a collaborare per interrompere il trasferimento (in teoria, potrebbe farlo solo in seguito ad un ordine dell'autorità giudiziaria), né che sia abbastanza tempestivo da riuscirci...  

Possibili scenari:
  • accettate le condizioni dettate dal malintenzionate, quali che siano 
  • fate una procedura di opposizione al NIC, ed incrociate le dita (se va tutto bene, comunque ci vorranno alcuni mesi, alcune migliaia di euro di spesa, ed il risultato soprattutto non è scontato)
  • vi scegliete un altro nome a dominio e su quello che avete perso ci mettete una bella pietra sopra (compreso il posizionamento dello stesso, i backlink, il fatto che tot centinaia di clienti e collaboratori lo conoscono ed usano email appoggiate a questo dominio ecc.)

Come fare per evitarlo?

La soluzione, in questo caso, è semplice: è sufficiente che siate consci dell'importanza dell'authinfo di un dominio .it, e che quindi lo conserviate con le dovute cautele, come se fosse una password preziosa (quale, di fatto, è).
Tra i "modi corretti e sicuri" per conservarlo cito ad esempio i due più semplici:
  • stampatelo su carta, riponetelo in una busta sigillata, scrivete sulla busta "contiene authinfo del dominio xxxxxyyyyyzzzzzz.it" e la busta sigillata conservatela in cassaforte;
  • conservatelo in una chiavetta USB con crittografia hardware e protetta da password (non spaventatevi: costano pochi euro in più rispetto ad una normale chiavetta USB!)
Adottando uno di questi semplici accorgimenti, ridurrete di molto le possibilità di furto del vostro dominio, e potrete dormire sonni relativamente più tranquilli. (E scrivo "relativamente" perché esistono anche altre vulnerabilità... ma di queste magari ne scriverò un'altra volta...)

domenica 16 marzo 2014

Si scrive "WordPress", non "Wordpress"!!!!

image credit to Norebbo

Può sembrare una sciocchezza, ma in realtà è importante... scrivere "Wordpress" è sbagliato, la grafia corretta è "WordPress", con la W e la P maiuscole.
Una sola parole, due lettere maiuscole: W e P.

Parimenti, sono sbagliate anche altre grafie, quali ad esempio wordpress, word press, Word Press... la grafia giusta è una sola, ed è WordPress.

Perché è tanto importante?

Intanto, per non apparire sciatti. Un errore di grafia è sempre fastidioso, ed è un sintomo di trascuratezza e disordine.
E se la community di WordPress ha deciso che si scrive WordPress, è così e basta.

Poi perché in WordPress è addirittura presente una funzione (  capital_P_dangit() ) che ha proprio lo scopo di correggere automaticamente la grafia sbagliata di WordPress, sostituendola con quella giusta.
Il che, se non prendete la sana abitudine di scrivere sempre "WordPress" correttamente, potrebbe causarvi qualche problemino...
Infatti questa funzione talvolta interviene anche sugli URL. Quindi se, per esempio, avete installato WordPress in una directory che si chiana /Wordpress ... beh, potreste avere qualche problemino con i link.

NOTA: proprio volendo, è possibile disabilitare la funzione: per farlo, è sufficiente inserire nel file functions.php le seguenti righe di codice:

remove_filter( 'the_title', 'capital_P_dangit', 11 );
remove_filter( 'the_content', 'capital_P_dangit', 11 );
remove_filter( 'comment_text', 'capital_P_dangit', 31 );

Oppure esistono degli appositi plugin, quali ad esempio Remove WordPress to WordPress filter
Ma sconsiglio di farlo, e piuttosto abituatevi a scrivere WordPress.
Non è difficile, ce la potete fare...

sabato 15 marzo 2014

Perché questo blog è su Blogspot.com anziché su WordPress.com?



La domanda può sorgere spontanea: perché - visto che parlo anche di WordPress - questo blog è su Blogspot.com anziché su WordPress.com?

Effettivamente è una bella domanda, alla quale però è possibile dare al massimo una risposta mediocre...

Cominciamo ad analizzare i possibili motivi, magari andando per esclusione... e cercando, soprattutto, di restar fuori da quella che, nel web, sembra esser diventata una "guerra di religione" che vede su opposti fronti i fedeli seguaci di Wordpress confrontarsi con gli altrettanto fedeli seguaci di Blogspot.com...

Non è una questione di soldi

Sia Blogspot.com che WordPress.org sono piattaforme gratuite; e le risorse che mettono a disposizione sono - obiettivamente - superiori a quelle di cui potrei aver mai ragionevolmente aver bisogno per questo blog

Non è una questione di temi disponibili

Entrambe le piattaforme mettono a disposizione un certo numero di temi gratuiti; hanno il problema di essere "temi standard", ma tutto sommato... chi se ne frega? Sono comunque migliori di qualsiasi tema io potrei mai costruirmi "a mano", e spesso l'illusione di "poter fare di meglio" è - appunto - solo un illusione.
Però, volendo, su blogspot.com posso modificare i temi esistenti o anche costruirmene uno del tutto nuovo (sottolineo: volendolo. Ed in questo momento la cosa non mi passa neppure per l'anticamera del cervello...)
Mentre su WordPress.com dovrei necessariamente passare su un servizio di hosting a pagamento.
Quindi, proprio volendo: un punto a Grifondoro... pardon, Blogspot.com

Annunci Adsense

In questo momento il mio blog ha un traffico ridicolo, e quindi altrettanto ridicola sarebbe l'idea di farci dei soldi pubblicando annunci Adsense.
Però, se un domani dovesse avere successo e dovesse cominciare ad avere migliaia di visitatori entusiasti, potrei anche pensare di guadagnarci una pizza una ogni tanto con gli annunci Adsense.
Su Blogspot.com posso farlo, su WordPress.com invece no.
Un altro punto a Blogspot.com

Widget Javascript

Nel caso volessi installare un widget Javascript qualsiasi, su Blogspot.com posso farlo tranquillamente, su WordPress.com invece no.
Ancora un punto per Blogspot.com

Dominio personalizzato

Se avessi il mio nome a dominio personalizzato (o se dovessi domani decidere di registrarlo), con Blogspot.com potrò associarlo al mio blog gratuitamente, con WordPress.com invece dovrò necessariamente pagare qualcosa...
Il distacco a favore di Blogspot.com aumenta di un altro punto.

SEO & indicizzazione

Blogspot.com è una piattaforma di proprietà di Google.
PARE (e, in definitiva, è ragionevole che sia così...) che Google guardi "con un occhio di riguardo" all'indicizzazione di blog ospitati su Blogspot.com
Personalmente, ho potuto ad esempio verificare che - in alcuni casi particolari - un blog su Blogspot.com risultava già indicizzato pochi secondi dopo la creazione.
Forse questo "favoritismo" si potrebbe compensare implementando sul blog su WordPress.com alcune opportune tecniche SEO... ma perché complicarsi la vita?

Quindi, tutto sommato, anche se WordPress mi piace e  lo conosco, di motivi per cui sia preferibile la piattaforma Blogspot.com per un blog personale o amatoriale ce ne sono parecchi...

Il discorso cambia se si tratta di un blog professionale; ma con questo non voglio dire che "per un blog professionale è meglio WordPress", ma solo che - in questo caso - sono ANCHE altri fattori da dover esser presi in considerazione... ed il risultato non sarà così scontato.
Però magari ne parleremo un'altra volta, eh?

venerdì 14 marzo 2014

WordPress: come vuotare il cestino

image credit by Norebbo

Ogni volta che cancelli un post, una pagina o un commento, Wordpress ne conserverà una copia nel cestino: non si sa mai...
Per cancellare la copia dal cestino, è necessario andare nella relativa cartella e cancellare da lì i file.
Il cestino viene vuotato ogni 30 giorni, ma questo tempo può essere ridotto a piacimento modificando il file wp-config.php

Inserendo la riga

define ('EMPTY_TRASH_DAYS', 5);
il cestino verrà vuotato automaticamente ogni 5 giorni.

Se vuoi disabilitare del tutto il cestino, e fare in modo che ogni elemento venga immediatamente cancellato senza possibilità di recupero (attenzione, che di questo un giorno potresti pentirti...), basterà inserire la riga:


define ('EMPTY_TRASH_DAYS', 0);

giovedì 13 marzo 2014

WordPress: come evitare i commenti troppo corti

image credit to Norebbo
Capita spesso che gli utenti lascino solo inutili commenti troppo brevi: "Bene!", "Approvo!", "Ben detto!"...
Spesso si tratta di commenti inutili, che non aggiungono nulla all'interazione e, anzi, possono sviare il lettore distraendolo da altri commenti più pertinenti e pregnanti.

Con poche righe di codice possiamo costringfere i nostri utenti a inserire commenti solo di una lunghezza minima che possiamo stabilire.

E' sufficiente aggiungere a functions.php le seguenti righe di codice:




add_filter( 'preprocess_comment', 'minimal_comment_length' );

function minimal_comment_length( $commentdata ) {

$minimalCommentLength = 30;

if ( strlen( trim( $commentdata['comment_content'] ) ) < $minimalCommentLength ){

wp_die( 'Tutti i commenti devono essere lunghi almeno ' . $minimalCommentLength . ' caratteri.' );

}

return $commentdata;

}


NOTE:

  • $minimalCommentLength deve essere impostato al numero minimo di caratteri desiderato (nell'esempio: 30 caratteri)
  • E' risaputo che è impossibile fare qualcosa a prova di stupido, perchè gli stupidi sono troppo ingegnosi; quindi, sicuramente ci sarà qualche imbecille che risolverà inserendo come commento "Beneeee!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!".
    Peraltro, sappiamo di non vivere in un mondo perfetto...