Perché Gmail converte in allegati le immagini embedded – analisi e soluzione del problema #dominoforever

Spesso capita che nello scambio di e-mail tra un qualunque sistema di posta e Google Suite/Gmail; la mail ritorni al mittente originale con diversi allegati ed alcuni di questi vengono riscritti come noname.
Questo comportamento si verifica quando nella mail originale sono presenti immagini embedded nel corpo della mail stessa.
Se usi Outlook,  Notes, Zimbra, Thinderbird o qualunque altro sistema di posta (webmail etc) ti sarai imbattuto sicuramente in questa problematica che alcuni dei tuoi utenti avranno sicuramente lamentato al vostro IT; e sarai arrivato anche tu a capire che ciò si verifica solo verso Gmail (Personal o Business è indifferente).
Dopo aver approfondito la questione (analizzando il MIME tra Domino e Gmail; ma vale per tutti gli altri sistemi) ho scoperto che Google dal 2018 ha cambiato modalità di gestione delle immagini embedded.
Per ragioni non note (perché va ricordato che la e-mail rispetta diversi standard RFC) Gmail adotta un comportamento tutto particolare e proprietario che ora vi spiegherò in seguito.
Online si trovano diverse discussioni al riguardo (un sacco direi)  e quella che si avvicina di più al problema è questa che non è propriamente precisa (anche Crossware ne aveva parlato limitandosi a dire che il problema è di Google)
Essendo GSuite anch’essa molto diffusa nel mondo business; ho analizzato il problema in profondità ed ho capito le due problematiche sotto:

Perché appaiono gli allegati noname in risposta o inoltro ad una mail inviata ad un account Gmail/GSuite?

Una mail con all’interno un’immagine embedded; alcuni sistemi la codificano con una sintassi che rispecchia lo standard RFC ed analizzando il MIME troveremo gli header di riferimento ad esempio che per Gmail è incompleto:

***
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Content-ID: <_2_0F2992F80F299178005FD423C12588A7>
***

È incompleto perché  Gmail richiede (senza che ci sia uno standard RFC a definirlo) anche l’header che specifica il nome dell’immagine e la sua disposizione all’interno della mail (può essere inline oppure attachment) e questo sarebbe il risultato dopo una risposta da Gmail in cui le immagini embedded vengono convertite in N noname (non ho ancora capito da cosa dipende il numero di allegato dato che nel mio test c’erano solamente 2 immagini embedded):




Se invece nel MIME di invio del sistema di posta sorgente venisse aggiunto per esempio l’header:

***
Content-Disposition: inline; filename="Image001jpg”
***

Gmail risponderà al mittente convertendo tutte le immagini embedded in allegati avente il nome specificato e questo sarebbe il risultato di chi riceverà la mail



E’ evidente che GMAIL stacca l’allegato e lo si vede anche dagli inviati di GMAIL stesso questo comportamento:



Esiste un modo per far si che Gmail non stacchi le immagini embedded in allegati; mantenendo così integra la comunicazione tra i due sistemi?
Si, esiste un campo header denominato X-Attachment-Id (che non rispetta alcun RFC o standard documentato) che se correttamente inserito come header in tutte le immagini embedded; permette a GMAIL di validarle ed avere il risultato sperato in risposta alla mail originale.
Di conseguenza se per ogni immagine embedded avessimo un header costruito in questo modo:

***
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Content-ID: <_2_0F2992F80F299178005FD423C12588A7>
Content-Disposition: inline; filename="Image001.jpg”
X-Attachment-Id: _2_0F2992F80F299178005FD423C12588A7
***
 La risposta da GMAIL permetterebbe di avere perfettamente integra l’immagine nel body originale in risposta



Per concludere:
Anche le soluzioni HCL di posta; quindi HCL Notes, HCL Verse (VOP) , HCL Traveler (Verse for IOS o Android) hanno queste problematiche verso sistemi GMAIL.

Per HCL basterebbe correggere opportunamente gli header delle immagini embedded al fine di rendere l’interscambio integro.
Ho già aperto un caso (case numero #CS0423018 ) e chissà se nella versione V14 prevista per la fine dell’anno ; verrà introdotta questa leggera fix che con poco sforzo di sviluppo; permetterà di migliorare l’interscambio tra sistemi differenti.