From: George B. <ge...@em...> - 2009-02-18 11:09:22
|
I have encountered an email from Squirelmail where the content type header has been split at a non-whitespace point, due to an unusually long content type. Example: Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.documen t; name="News.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="News.docx" As far as I can see, this is incorrect according to the standard, e.g. http://tools.ietf.org/html/rfc5322#section-2.2.3 Is this intentional?It may be possible for parsers to work around this particular case, but adherence to standards is generally a good idea.George Barwood |
From: Paul L. <pa...@sq...> - 2009-04-05 07:18:45
|
On Wed, Feb 18, 2009 at 3:17 AM, George Barwood <ge...@em...> wrote: > I have encountered an email from Squirelmail where the content type header > has been split at a non-whitespace point, > due to an unusually long content type. > > Example: > > Content-Type: > application/vnd.openxmlformats-officedocument.wordprocessingml.documen > t; name="News.docx" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="News.docx" > > As far as I can see, this is incorrect according to the standard, e.g. > > http://tools.ietf.org/html/rfc5322#section-2.2.3 > > > Is this intentional? Only the author of the original folding code can tell you that, but I think it's wrong. I have re-written the folding code and it is in 1.5.2SVN now and pending feedback to see if we can port it back to 1.4.x. If you want to try the new code in 1.4.x, there is a file you can use attached to the following tracker: https://sourceforge.net/tracker/?func=detail&atid=100311&aid=1951776&group_id=311 |