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.

Sign up for GitHub

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

Jump to bottom

Embedded images with DOS-like names are classified as attachments #10

Closed
fadeyev opened this issue Sep 29, 2019 · 2 comments
Closed

Embedded images with DOS-like names are classified as attachments #10

fadeyev opened this issue Sep 29, 2019 · 2 comments
Labels
bug
Milestone
1.3.0

Comments

@fadeyev
Copy link

fadeyev commented Sep 29, 2019 •
edited
Loading

During parsing of one particular email one of the embedded images was qualified as an attachment, not as an embedded image (though actually it was an embedded image).

Not sure how this email was created, however debug showed that OutlookFileAttachment longFilename property was something like my-embedded-image.png when short file name was my-emb~1.png, while in the html body the image was referenced by its full name: src="cid:my-embedded-image.png". Probably we can change OutlookMessage#htmlContainsCID() method to check both filename and longFilename

Probably the same issue was reported earlier in #1
bbottema added a commit that referenced this issue Sep 29, 2019
@bbottema
#10: add support for both short and long filename for embedded images…
56a1764 
…, depending on which one was used in the HTML
@bbottema bbottema added the bug label Sep 29, 2019
@bbottema
Copy link
Owner

This was a pretty easy fix, but difficult to test, since I don't have an example .msg file with this case.

@bbottema bbottema modified the milestones: 1.1.20, 1.2.2 Sep 29, 2019
@bbottema
Copy link
Owner

bbottema commented Oct 4, 2019

Released v1.3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
1.3.0
Development

No branches or pull requests
2 participants
@bbottema @fadeyev