Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachments were not converted #1

Closed
tetsuya-asai opened this issue Apr 26, 2018 · 2 comments
Closed

Attachments were not converted #1

tetsuya-asai opened this issue Apr 26, 2018 · 2 comments

Comments

@tetsuya-asai
Copy link

Great! My partial.emlx files were successfully converted to eml files, but all the converted eml files did not contain any attachment file... although the source emlx files had attachments (cf. attached data source).
I explored your code, and found "data.body" (after parsing elm) were not an array, but was strings including multi-part border strings, which means the multi-part eml sources were not parsed correctly. This resulted in appending contents of the original emlx files only, without attaching any file. Do you have any concern on this?

Environment: MacOS X 10.13.4, Node v6.11.0, Apple Mail 11.3
Data source: data.zip

Many thanks in advance!

@qqilihq
Copy link
Owner

qqilihq commented Apr 26, 2018

Thanks for your report, and great that you have provided a test case. I'll have a look at it as soon as I have some spare minutes (tentatively this weekend). I'll get back to you then!

@qqilihq
Copy link
Owner

qqilihq commented Apr 26, 2018

Here's a quick update, what I've found out so far:

The issue seems to be, that the eml-format lib, which we use in this project, considers email headers case sensitively. In your .emlx file, the header name is Content-type, but the eml-format lib only handles Content-Type.

  1. Changing the header manually seems to solve this issue (line 77 in your .emlx file file).

  2. This post suggests, that email headers are to be treated case-insensitively. So the current behavior is too strict.

  3. Simplest solution: Ask eml-format's author to make the parsing case-insensitive (would you be willing to open an issue here, @tetsuya-asai?)

  4. Other, less favorable workaround in case (3) is not feasible: Write a workaround in this project to take care of above.

qqilihq added a commit that referenced this issue Apr 26, 2018
Should probably better by covered by the 'eml-format' module

See #1
qqilihq added a commit that referenced this issue Mar 30, 2019
Should probably better by covered by the 'eml-format' module

See #1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants