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

no html or text content with multipart/* #115

Closed
markusramsak opened this issue May 25, 2020 · 6 comments
Closed

no html or text content with multipart/* #115

markusramsak opened this issue May 25, 2020 · 6 comments

Comments

@markusramsak
Copy link

markusramsak commented May 25, 2020

        $mailParser = new MailMimeParser();
        $message = $mailParser->parse($rawMessage); // file_get_contents('eml.txt')
        $htmlText = $message->getHtmlContent(); // null
        $plainText = $message->getTextContent(); // null

should be plain text content and one pdf attachment

Here is the original .eml-File to download:
eml.txt

@zbateson
Copy link
Owner

@markusramsak any idea what may be causing that, whether it's a problem in the email or the library, if you've tried anything to remedy it, version of library you're using, anything else that could help?

@markusramsak
Copy link
Author

I am using the latest version of your library and I think it is simply a new kind of mail content. Even the preview on mac os displays an empty content. Only if I open the .eml-File with the Mail.app itself it displays the text content and the pdf attachment.

therefore I assume it is a problem with the handling of the library of the content type "Content-Type: multipart/*; charset="ISO-8859-15";"

@zbateson
Copy link
Owner

Thanks for the info -- I must say I've never heard of/seen multipart/*, do you know what mail program created that content type, and if it's common?

@markusramsak
Copy link
Author

markusramsak commented May 25, 2020

I have parsed more than 20000 mails with your library and this one happens for with content type multipart/* happens for the first time. Therefore I think it is not common. It is a mail after a purchase from https://www.fischersports.com – they have made a mistake with generating a correct mail.

replace multipart/* with multipart/mixed and it works :-)

@markusramsak markusramsak changed the title no html or text content no html or text content with multipart/* May 25, 2020
@zbateson
Copy link
Owner

Weird, I wonder where they got that idea from. Also I wonder how apple mail handles it, maybe they consider anything "multipart/unknown" as "mixed"? I'll keep this here and see how Thunderbird handles it since that's what I have access to.

Thanks for reporting :)

zbateson added a commit that referenced this issue Jun 7, 2020
Changes the regular expression matching multipart mimetypes to
~multipart/.*~ instead of ~multipart/\w+~ to allow for any
character to be matched in a mulatipart content-type header.
@zbateson
Copy link
Owner

https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html in 7.2.2:

Any multipart subtypes that an implementation does not recognize should be treated as being of subtype "mixed".

This has been released in 1.2.2.

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