laminas / laminas-mail

Provides generalized functionality to compose and send both text and MIME-compliant multipart e-mail messages
https://docs.laminas.dev/laminas-mail/
BSD 3-Clause "New" or "Revised" License
95 stars 64 forks source link

Content-Type header handling #51

Open michalbundyra opened 4 years ago

michalbundyra commented 4 years ago

Hi

There is a case when emails have Content-Type header, defined with keyword "ContentType", for example:

ContentType: text/html; charset="UTF-8"

In this case error appears:

Invalid header line for Content-Type string

Looking header fieldName normalization, I see that Content-Type, Content_Type, Content Type, ContentType will be normalized to contenttype. So contenttype will be stored in Zend\Mail\Headers::$headersKeys and appropriate header in Zend\Mail\Headers::$headers. Than on header loading pluginClassLoader will load Zend\Mail\Header\ContentType and method Zend\Mail\Header\ContentType::fromString() is called. But there is condition that do not accept 'contenttype` value.

It looks like inconsistent behavior. I understand that rfc2045 accepts Content-Type keyword only, but in real cases other keywords can appear.


Originally posted by @hugeval at https://github.com/zendframework/zend-mail/issues/107

michalbundyra commented 4 years ago

Good catch :+1: Definitely looks to me like a strictness mismatch between the two classes: ContentType::fromString does not normalize the keyword while the Headers bag does. I'm not familiar enough with Zend\Mail to know which is the intended behaviour, but it should definitely be consistent. Tecnically, only Content-Type is valid and the others should be ignored, but our world is not that perfect :stuck_out_tongue:

I spot-checked a few other Headers classes for headers with hyphenated names and those also do not do normalization and so would have the same problem.


Originally posted by @adamlundrigan at https://github.com/zendframework/zend-mail/issues/107#issuecomment-239431188

michalbundyra commented 4 years ago

I'm not sure we should support the contentType header. I just searched through a corpus of about a million emails sent over the past 5 days. And found only 5 emails containing the 'contentType' header. All from the same server and domain, and all mails with the contentType header also had a Content-Type header (with an identical value).

I could search in a much larger corpus as well, but this server is handling email for about a 100K domains, so I'd say it's fairly representative.


Originally posted by @Freeaqingme at https://github.com/zendframework/zend-mail/issues/107#issuecomment-239509497

michalbundyra commented 4 years ago

@Freeaqingme , I'm not sure, but it looks like, mails sent using Microsoft Outlook have both Content-Type and ContentType headers in each email.


Originally posted by @hugeval at https://github.com/zendframework/zend-mail/issues/107#issuecomment-239526587

michalbundyra commented 4 years ago

@Freeaqingme how about other headers this class normalizes the field names of? Could we drop that normalization for 3.0? Right now it's just shifting the problem from the header bag into the individual header classes (which reject the invalid field names).


Originally posted by @adamlundrigan at https://github.com/zendframework/zend-mail/issues/107#issuecomment-241154422

michalbundyra commented 4 years ago

We are also experiencing this issue. Mail which is sent by Wrike also contains Content-Type and Contenttype


Originally posted by @fasterforward at https://github.com/zendframework/zend-mail/issues/107#issuecomment-259090796

michalbundyra commented 4 years ago

This is happening for headers other than Content-Type, FYI. I ran into this problem with Mime-Version coming in as MimeVersion. I implemented it in my fork, here's an example: https://github.com/ParticleBits/zend-mail/commit/96a8a4a3b0803a05ba1665e87e5a3a4a255ffcff

I don't know if this would be the preferred fix for this codebase but if it is, it's a minor PR.


Originally posted by @mikegioia at https://github.com/zendframework/zend-mail/issues/107#issuecomment-282501742