.EML attachments support

[Kharg]

Is your feature request related to a problem? Please describe.
Registered Electronic Mail (Certified Email) is getting more and more popular nowadays both for business and personal use.
Usually you get an email with an .eml attachment that contains the real email content.
It would be ideal if Espo supported the opening of eml instead of direct download as inline attachment.

Describe the solution you'd like
Clicking on an .eml attachment (maybe only if inside email entity?) will open a modal showing the email and its attachments with a button to import the email if the user wants; to avoid automatic importing on viewing.

Describe alternatives you've considered
I've developed a custom extension to parse and import .eml as Archived emails using an entrypoint; A button will show in the email detail view if a 'message/rfc822' attachment type has been found and it will first parse the email and generate a .json containing the .eml data (to make it easier debugging) and then it will save an archived email using the data from the json.

Additional context
Certified email is a special type of email in use in Italy, Switzerland, Hong Kong and Germany.
It would also be useful when you get other email as an attachment from someone else.

[yurikuzn]

It should just parse EML and save? It does not suppose that some request should be sent upon opening to confirm receival? Or the email is already considered as received if it was fetched from the IMAP mailbox?

[Kharg]

I think the best implementation would be to show the email in a modal and leave the choice to import it to the user (maybe the email should be related to the parent to avoid importing duplicates?)
The email is already considered as received as you get this email as an attachment to another email.
My custom extension just parses it and save it automatically (relating it to the parent email) and then it redirects to the saved email as that's what I needed

[yurikuzn]

Wouldn't it be easier just to parse the attachment during import and save a body and attachments as a regular email? I don't get the point of having an option to parse or not to parse.

[yurikuzn]

If an email does not contain body but contains only one EML we could parse it right away. I don't know how such emails are usually formatted.

[Kharg]

Sorry, I forgot to mention that the body of the first email isn't empty usually (at lest for Italy) it's like this

[yurikuzn]

A have a few more questions.

1. How email clients usually treat such emails? Do they offer "View" functionality?
2. Does EML may contain attachments inside? How this handled by email clients?

Thanks

[Kharg]

1. Email clients (Thunderbird and Roundcube Webmail) will show the .eml as an attachment, clicking on it will let you view the email with the option to reply/forward/print/download just like a standard eml attachment (just send yourself an email with an .eml attached and you will see).
2. These EML can contain both normal and inline attachments (like body images as cid)

[yurikuzn]

Do they have own Message-ID?

[Kharg]

yes they do.
It is basically an email inside another email.

If you need it and you have a mailbox configured in Espo I can forward you one of these messages

[yurikuzn]

There's the issue with very large emails. We can't view them in browser w/o saving all attachments on the server before.

[Kharg]

even if they are already base64 encoded? Like showing the attachments in a href?
I used something like this during debugging to generate a html page containing the attachments, it's ugly but it worked well for testing. (I didn't have the opportunity to test it with very large files)

[yurikuzn]

Attachment can be of any format. E.g. 1GB video file.

[Kharg]

These email are usually used for documents so not larger than a few mb, I understand that we have to consider all use cases.
Maybe showing attachments larger than a certain threshold only if you import the mail? With a message disclosing that there are attachment that will be available only after importing(saving)?

Or automatic importing of the email and clicking on the .eml attachment will redirect you to the record view for that email.

[hi-ko]

It's not that easy. We had a similar discussion for our own resource service accessing emails thru our service (consumed from other systems like workflows). The main email is what we want as main reference/resource and not mismatch with metadata from the attachments. We decided to implement a hierarchy concept which means: from the main email we support to navigate into known containers like eml (even on the api level) but I guess that would be a major change for espocrm. In that case we would need something like a viewer concept. Just dumping out the mail's content if it's an eml file would open pandora's box ...

[Kharg]

Hi @hi-ko
I actually solved this problem by relating the new email that gets created from the .eml as a child of the email that contains the .eml attachments and it has been working very well so far.

[hi-ko]

I have thought about it a little:

• a message/rfc822 attachment could be stored directly as a mail entity instead of an attachment entity like a normal inbound email and
• linked via new relation (one-to-many) as 'attached mail' (similar to replies)

If this releation is shown on both sides (is attached in mail, has attached mail) the required transparency could be achived.

[hi-ko]

what I see as pandora's box is:

• should an email handled unique by message-id?
  (actually I don't know how this is handled now with other emails)
  • if storing unique: how to handle user and team assignments, folder references, ...
• should the new message only accessable from the parent mail (which may affect search)?

In order not to get completely lost here, it would probably be easiest to allow any number of emails with the same message-id. the only question is how this maps with other use cases which use message-id.