Alessandro Bonzi blog - Internet e motori di ricerca

Mainly Internet business, but also life mysteries and videogames

Apple Mail El Capitan SMTP’s gone crazy! How to fix.

 

 

If you just upgraded to El Capitan Mac OS X, you may have expected a better Apple Mail.

AppLanding_Mail

While a better Apple mail is not what Apple has got to deliver us as priority (oh Eudora I miss you), there are worst things you may bump into as soon as you open Apple Mail with El Capitan the first time: all configured email accounts got SMTP settings mixed up! In fact, when you try to send an email, Apple Mail uses a random unconfigured SMTP server of your list. And everything was working perfectly before upgrading!

If you try to re-configure them by selecting each email account under Apple Mail -> Preferences -> Accounts and by setting back the correct Outgoing Mail Server (SMTP) using the pull down menu, well, they just don’t get saved and they keep on being unassigned.

Also my emails are all getting the lastest SMTP I configure despite the previous one I saved was different.

After some tries, I found out a solution to bring the SMTP’s back to work.

When you open the SMTP Pull Down menu for each email account you are going to fix, be sure to CHANGE THE NAME in the Description Field. This forces Apple Mail to re-write the entry plist xml file for that account, fixing it.

Screen Shot 2015-10-01 at 20.47.03

So open each SMTP entry, change the value in the Description field with a new one, close to save and you’re back with a working smtp Apple Mail in El Capitan.

Happy (Apple) Mail again!

 

Update 24 Oct 2015 El Capitan 10.11.1 seems to address this smtp issue.

fixed-smtp

 

Da HTTP a HTTPS: server e sitemap

Recentemente abbiamo deciso di portare l’intero sito web da http ad https per via di alcune integrazioni che funzionano solo in https e per i recenti cambiamenti annunciati da Gogol (così come Google fu chiamato in tempi recenti dai alcuni nostri politici) sulla valutazione dei siti sicuri rispetto a quelli non sicuri a favore dei primi.

Al fine di evitare alcune gravi disattenzioni ho deciso di elencare qui i problemi più gravi in cui si può incorrere.

businessman in suit https

IL PROTOCOLLO HTTPS – Il primo problema è legato a come funziona il protocollo HTTPS.

Quando ci si collega al sito www.pizza.it, il protocollo HTTP (quello non sicuro di sempre) contatta il server del sito, comunica al server che cerca www.pizza.it e, se il server lo trova, lo negozia con successo e rende visibile il sito web.

Quando ci si collega al sito https://www.pizza.it, il protocollo HTTPS (quello sicuro) contatta il server del sito e comunica che c’è in arrivo una connessione sicura ma non dice niente altro a meno che il server risponda anche lui in modo sicuro. Il server allora cerca la prima configurazione sicura che conosce e da lì in poi può proseguire la negoziazione in modo sicuro con l’utente. A questo punto gli viene annunciato che si vuole www.pizza.it. Se www.pizza.it non c’è sul server, il server continua comunque a servire la prima configurazione sicura che aveva usato per comunicare, indipendentemente dal sito a cui appartenga.

In questo caso, per evitare che due siti di un stesso server, 1 sicuro e 1 no, si confondano e il secondo appaia come il primo, anche se non esiste in modalità sicura, si creano sul server delle configurazione sicure inutili (di default) affinché il server usi sempre quella per dialogare in https e affinché si blocchi nel caso il sito non esista (una trappola, praticamente).

Tale processo può fallire per i browser che non supportano la modalità di dialogo multipla su https, e può fallire per alcuni bot/spider non aggiornati e soprattutto può essere mandata online in modo errato, senza accorgersene.

TIP 1. HTTPS ON MULTIPLE VIRTUAL HOSTS ISSUE

Una volta configurato HTTPS su di un server che ospita più domini, controllate che la URL di un sito dello stesso server (e che NON sia https) non appaia comunque quando digitate la url con https, perché potrebbe non essere voluto e potreste trovarvi il vostro sito sicuro sotto la url di un’altra persona (cioè vedreste il contenuto di www.pizza.it apparire sotto https://www.mozzarella.com)! Il browser mostrerebbe errori sul certificato, ma bot di indicizzazione come il googlebot leggerebbero il sito generando nel tempo un problema di contenuto duplicato.

Dovete quindi creare il server SSL di default in cui intrappolare queste connessioni (tecnicamente sono delle “SERVER BLOCK” per virtual host apache2 o ngnix, ad es. in apache si configura un virtual host *:443 con “SSLStrictSNIVHostCheck on” default tale che dia un errore 444), ma se non potete modificare il setup del server, allora nell’header del vostro sito sicuro, inserite un controllo lato pagina web che blocchi ogni connessione che arriva e che sia all’infuori del dominio https che vi aspettate.

In PHP, se il vostro sito sicuro è https://www.pizza.it allora aggiungete:

if (isset( $_SERVER['SSL_TLS_SNI'] ))
{
if ($_SERVER['SSL_TLS_SNI'] !== 'www.pizza.it')
{
// uh, sto servendo un dominio diverso dal mio, bloccare!
header('HTTP/1.0 444 No Response');
header('Connection: close');
exit;
}
}

In mod_perl2 (se lo usate), il controllo nella sub{} sarebbe:


return Apache2::Const::NOT_FOUND if (($r->headers_in->{ 'SSL_TLS_SNI' } || 'www.pizza.it') ne 'www.pizza.it');

Il secondo controllo da fare riguarda invece le sitemap.

TIP 2. SITEMAPS, GOOGLE BOT e CANONICAL URLs da HTTP a HTTPS.

Se il problema principale di una misconfigurazione server come da punto 1 vi sembra grave, allora si può provocare un danno maggiore con le sitemap di un sito che cambia da http a https.

Che cosa succede infatti con il passaggio da http ad https con le sitemap e Googlebot? Che cosa fa Google nei proprio indici? Che pagine leggerà? Http o https? CHE COSA farà?

INDIPENDENTEMENTE da tutto quello che leggerete sui siti web, intanto GOOGLE deciderà spontaneamente di mostrare le vostre nuove pagine HTTPS anche quando gli starete passando SITEMAP con URL in http. Questo perché è una scelta di Google di spostarsi su https appena una pagina diventa disponibile con tale protocollo.

CANONICAL URL DISASTER – Il primo DISASTRO è che se passate in https e se per caso il vostro sito continua ad indicare url canoniche in http, allora su google le pagine saranno sostituite da pagine https, ma il canonico della pagina tenterà di invalidare la scelta di google, facendo piano piano perdere la visibilità della pagina, fino anche alla scomparsa stessa della pagina dai risultati di ricerca.

Per risolvere questo problema, la soluzione migliore è la seguente.

Mandato live il sito in HTTPS, creiamo sitemaps per tutte le URL in HTTPS da inviare a Google con il webmaster tools. Non vogliamo togliere le sitemap con le URL http ad oggi esistenti; queste servono per preservare l’indicizzazione precedente, ma poco dopo andranno dismesse.
Eliminiamo eventuali canonical url HTTP per trasformarle in HTTPS, oppure rimuoverle del tutto e inserire Redirect 301 lato codice verso le pagine https.
Lasciare che GOOGLE legga le url nell’indice HTTPS. A queto punto potete smettere di generare le SITEMAP in HTTP. Il webmaster tools (search console) che si usa per vedere lo stato di indicizzazione da parte di Google NON è lo stesso! Dovete aggiungere il sito con il dominio HTTPS in webmaster tools o vi perderete le statistiche sul nuovo sito! Il vantaggio di farlo dove c’è già configurato il sito http è che viene aggiunto SUBITO senza chiedervi la verifica di possesso del sito.

Attenzione, se non dite che le pagine HTTP sono diventate HTTPS con un 301 o con una tag canonical, rischiate di duplicare i contenuti e di duplicare il numero di pagine da leggere da parte del googlebot, perdendo quindi anche potenza di banda (numero di pagine lette al giorno).

Fatto questo dovete aspettare che piano piano Google vi porti al 100% in HTTPS (molto veloce). La velocità di lettura delle pagine da parte del googlebot non rallenta il cambio da http in https nelle pagine di ricerca, poichè il canonical o il 301 accelerano il processo indipendentemente dalle sitemap.

Happy HTTPS.

P.S. Se avete caricato un file nel disavow tool di Google per il sito http, ricordatevi che dovete ricaricarlo anche per il sito HTTPS perchè non viene trasferito da Google in automatico, anzi, rischiate di partire con un sito “nuovo” https già zoppicando.