Ho fatto un test ora e Gmail non blocca le immagini se sono inviate come embedded.

Dalla nostra esperienza abbiamo aziende che hanno provato entrambe le soluzioni (anche con A/B test) e hanno scelto strade diverse: alcune non invierebbero mai senza le immagini embedded, altre preferiscono il metodo tradizionale. Varia a seconda del tipo di messaggio e del tipo di destinatari, per quello suggerivo il test. La nostra newsletter ad esempio, che è inviata al mondo B2B con un taglio informativo e non promozionale, ho scelto di inviarla in modo tradizionale perchè la differenza in termini di CTR c'era ma non altissima, mentre il peso del messaggio, visto che almeno 5-6 immagini ci sono sempre, sarebbe risultato troppo alto. Inoltre avrei perso tutte le statistiche sulle aperture. Credo che nel settore B2C la questione potrebbe ribaltarsi facilmente.

Riguardo alla diffusione dei client lascio questa statistica, che è un po' viziata perchè calcolata sulle aperture (visto che i client Apple solitamente non hanno blocchi di immagini, risultano probabilmente più in alto del dovuto in classifica) ma comunque aggiornata ed interesante: http://emailclientmarketshare.com/

Su Gmail da quello che mi risulta le blocca se il mittente non è in rubrica (e se non si è specificato precedentemente "visualizza sempre le immagini inviate da [email protected]").

Ho appena fatto un test e Gmail BLOCCA anche se le immagini sono embedded.

Bago, probabilmente Gmail utilizza propri algoritmi per decidere quali immagini bloccare e quali no. Io ho inviato ora ad un indirizzo Gmail con immagini embedded e non ci sono stati blocchi. Stesso mittente, stesso destinatario con immagini non embedded, ed è scattato il blocco.

Quello che descrivi è quello che succede nella mia casella gmail se il mittente è in rubrica. Se il mittente non è in rubrica (e non hai mai selezionato "mostra sempre le immagini per questo mittente") allora vengono bloccate sia le embedded che le "linked". Ho appena provato con le caselle di 2 colleghi e 1 amico e tutte hanno avuto lo stesso comportamento. Poi non escludo che Google applichi tecniche diverse su caselle diverse (magari anche in funzione della nazione di appartenenza, visto che la normativa sulla privacy cambia da nazione a nazione).

Dimenticavo: per fare le prove le email le spedisco da un altro account gmail, così escludo qualunque cosa che possa aver a che fare con reputazione del server o con metodi non supportati di embedding.

Non combacia con i miei test. Il mittente non è in rubrica e non è un mittente gmail. Il comportamento è diverso a seconda di invio con embedded e non, con le embedded non bloccate. Probabilmente ci sono altre variabili che Gmail considera. Se vuoi girami un msg in privato che proviamo a fare un test insieme, su un tuo indirizzo!

Ti ho mandato un PM.

Alcune funzioni di Gmail cambiano se ci sono state "risposte" o "email inviate" verso quell'indirizzo: potrebbe essere una di quelle. Comunque quando mi giri la casella su cui provi ti mando un messaggio usando una delle mie caselle che sicuramente non hanno mai conversato con te e vediamo.

PS: ovviamente io sto parlando della webmail di gmail "standard" usata da browser (chrome/firefox) su desktop (non so se le versioni webmail mobile e le varie app mobile abbiano comportamenti similari o meno). Immagino che anche tu parli di quella, ma non si sa mai

Ottima iniziativa e teneteci aggiornati...

Dalle prove fatte con Nazzareno (grazie) forse abbiamo scoperto l'arcano:

Sembra che se l'email proviene da un indirizzo con SPF configurato e "valido" allora il comportamento sia quello descritto da Nazzareno: blocco per le sole immagini "linkate".
Se invece l'email non ha SPF o "non passa" allora il comportamento è quello che ho descritto io: blocco per tutte le immagini, embedded comprese.

Non è da escludere che ci siano anche altri fattori, ma dopo qualche test quello discriminatorio sembra quello.

Scusate l'offtopic, possiamo tornare alla discussione iniziale!

Cos'è il SPF? scusate ignoranza...

Un protocollo per l'autenticazione email (Sender Policy Framework): http://it.wikipedia.org/wiki/Sender_Policy_Framework
In parole povere consiste nell'aggiungere un record DNS al tuo dominio dove dichiari quali sono i server che sono autorizzati a spedire email usando il tuo dominio come "mittente".

Bago scusa se approfitto. Quindi avendo siti su register devo andare su register a settare questo SPF o devo andare su agonet che mi da il servizio internet e uso il suo smpt.agonet.it?
Fammi sapere grazie

SPF è nato per autenticare l'envelope-sender. L'envelope-sender corrisponde all'indirizzo dell'header Return-Path (dove vengono recapitati i bounce) se presente, altrimenti corrisponde al FROM:. Quindi se spedisci con Outlook, devi mettere il record SPF sul dominio che usi come mittente, se invece spedisci con un sistema professionale (servizio invio email oppure servizio smtp), il record SPF è già settato da chi te lo fornisce. Nel tuo caso dubito che il servizio smtp di Agonet includa anche il servizio di gestione automatica dei bounce, mentre non so se Sendblaster lo faccia e come. Quindi il suggerimento è: inviarti un messaggio, guardare la sorgente del messaggio (chiamate anche proprietà, intestazioni internet, header...) e vedere se trovi una riga con "return-path: [email][email protected][/email]". Se la trovi, l'SPF va messo su example.com, se non la trovi, l'SPF lo devi mettere sul dominio che usi come mittente.