[Tickets #12062] Re: Mime parser fails to parse multipart message

noreply at bugs.horde.org noreply at bugs.horde.org
Thu Feb 21 09:53:55 UTC 2013


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12062
------------------------------------------------------------------------------
  Ticket             | 12062
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | Mime parser fails to parse multipart message
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-02-21 09:53) wrote:

>> Further debugging showed the Kolab object / email
>> in question is missing the
>>
>> "MIME-Version: 1.0"
>>
>> header field. Should the MIME parser be less strict about this?
>
> NO.  Without a MIME-Version header, it is NOT a MIME message.
>
> And it is not something we should ignore.  For example, IMAP servers  
> will treat a message as non-MIME in BODYSTRUCTURE (i.e. single  
> tex/plain ASCII part) without MIME-Version.

The initial Kolab parse code uses getStructure() which in turn uses  
Horde_Imap_Client::FETCH_STRUCTURE. At least the cyrus imap server  
sends back the full structure and is unimpressed by the missing  
MIME-Version header.

Peeking through the cyrus code, it just checks for "multipart" in the  
Content-Type header.

I've also looked at the dovecot code. It checks for the presence of  
the "Content-Type" header field if it doesn't find "MIME-Version".  
This behavior can be disabled by a flag but it is enabled by default  
(and there's no code to configure it by the user)
See also here:
http://www.dovecot.org/list/dovecot/2009-November/044311.html
"...but there were enough broken mails that I decided to make this  
optional in code (but
not by admin)"

What could go wrong if we do the same (to be more relaxed on parsing)?






More information about the bugs mailing list