Inlined image broken in GMail

[chibenwa]

Description

GMail do not support inlined base64 image.

We somehow have to compose an email and attach the image as an inlined email attachment with CID.

Let's discuss this 06/05 during Twake Mail frontend meeting. If we can find a way to keep the design simple.

[chibenwa]

I reached out to modern email folks...

Hello Modern email folks!

Today I struggled with one aspect of RFC-8621 JMAP Mail

We were trying to add client support for image in signatures - if possible in an inter-operable way.

The issue is that Identity only defines text and html fields and do not include images in there.

We so far thought about several approach:

Inlining the image directly in an img tag as base64, which can easily be done with the current spec, which we POCed, but is not supported by all MUA, including GMail.
So img tag base64 is a dead-end...
Of course one would like to attach the signature as a separate mime part with multipart/related, cid, content-disposition inlined &al but the RFC do not define such data structure for storage on the server side, thus this would need to live as a vendor specific extension... Emails with the given signature could only be composed from my MUA...
And finally having the signature linking third party http resources. Sure the signature is then not duplicated in each and every mail. Sure any MUA can compose an email. But the edition of the signature (changing the image) can no longer be done in an interoperable fashion (changing the image would require updating / creating a new HTTP third party resource).

How other JMAP players worked around this issue?

Tried out what fastmail do:

I see fastmail opted for an HTTP link managed by the user...

[chibenwa]

I move this back to story:writing

-> We are discussin g a solution. That's not the time yet to implement something...

Also Fastmail solution as is is not user friendly at all. We need to design a system that helps preserve the current UX.

[chibenwa]

What I have in mind is a new server extension (Tmail backend):

Session extention:
 - URI com:linagora:params:public:assets
 - publicAssetTotalSize: UnsignedInt space that can be hosted

PublicAsset JMAP objects

 - id (serverSet)
 - publicURI (serverSet)
 - size (serverSet)
 - blobId
 - identityIds: Id[]|null, default to null

/get implemented
/set create 
    front need to upload the image first
    back needs to copy the content (not just upload)
    back needs to validate the content type: `image/*`
/set destroy
/set update on identityIds

Client (Twake mail) is responsible of deleting PublicAssets with no identity associated with them.

GET (no auth) jmap.linagora.com/publicAsset/xyz
    Route would need to be added in Apisix basicAuth routes to bypass OIDC authentication

[benbucksch]

Public HTTP URLs in email need to be avoided, because of the tracking problem that they pose. They are basically a read validation for spammers. (Server-side proxies do not solve the problem entirely: https://spammer.com/id/45667890.png is still a "email arrived" confirmation - and they don't work for encrypted mail.)

So, properly implemented email clients have to ignore HTTP URLs in email.

I know only 2 ways to include images in email:

• data: URLs (discouraged, and I think you said they don't work in GMail), or
• multipart/related with cid: URLs.

attach the image as an inlined email attachment with CID

+1