How do you come to that conclusion?  Because *other* products don't 
treat it right?  That has never been a proxy for analyzing the details 
of the issue.

And FWIW: I don't think anybody is regarding Thunderbird and/or 
Outlook as paragons of security.
We don't control those tools.  That doesn't mean that what *they* do 
is correct.
This absolutely does NOT make it not a security issue.

Short story: if someone wants to ignore the MIME-Version header, it is 
at their own peril.  But it absolutely, positively can NOT be the 
default of any MIME parsing library.  That is irresponsible coding.

Closing this ticket because we already provide an OPTIONAL way of 
parsing messages without checking for MIME-Version headers 
('forcemime').

Interesting survey. Too bad it does not contain any date information
when it last scanned the IPs or provide the test script. Would be interesting
to see if it detects my local server as cyrus imapd.
I've done the following test:
- create a message with an attachment
- strip all headers except: Date, To, From, Subject and Content-Type
- place it on a POP3 server
- fetch it with a client and check if it still parses the MIME message

Results:
Outlook 2003: Ignores missing MIME-Version, shows attachment
Outlook 2010: Ignores missing MIME-Version, shows attachment
Thunderbird 17.0.3: Ignores missing MIME-Version, shows attachment

So this "antivirus" solution you mentioned is pretty useless
in the real world if it can be fooled by a missing MIME-Version header.

Also the perl-MIME-tools 5.427 used by the popular amavisd-new email 
content scanner (antivirus / antispam tool) also checks for 
"multipart" in the Content-Type header only.
So that's already quite a big security "breach" ;)

-> I don't think it's a security issue since the popular MUAs tested 
above ignore it.

Only Courier IMAP seems to be stubborn about this, it clearly discards 
the content when the MIME-Version header is missing.

Thomas

Actually, for purposes of discussion, I won't remove the patch right now.

Removing patch as this opens up a giant security hole as the default behavior.

I rarely disagree with Timo, but I do here.  This is a bad idea.

But whatever Cyrus and *certain* versions of Dovecot do is irrelevant. 
  The issue still remains that a large number of IMAP servers 
**won't** parse these messages.  By Timo's own numbers, this is at 
LEAST 40% of the servers out there (just counting the number of 
Courier installs and a reasonable estimate of the number of servers 
running the old dovecot software: http://www.openemailsurvey.org/)
1. I know for a fact (because I have dealt with them personally) that 
certain SPAM/Antivirus tools WON'T parse a message missing the 
MIME-Version header as a MIME message.  So it becomes absolutely 
trivial to bypass security checks on these machines by doing something 
like this:

Content-Type: multipart/mixed; bounday=foo

--foo
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

[Malicious base64 data here]
--foo--

Your solution ignores this reality.  Not to mention you can't check 
for Content-Type as a substitute for MIME-Version since Content-Type 
is not guaranteed to exist.

There is only 1 required field for a MIME message.

2. The idea of "be liberal in what you accept" that is always thrown 
around by the other side in this argument is crap.  That is NOT what 
the goal should be.  Instead, it should be "be liberal in what you 
accept BUT ONLY IF it doesn't break other things and/or open security 
holes."

It is one thing to accept, for example, extra whitespace sent back 
from an IMAP server even though this is specifically prohibited in the 
RFC.  That is because this extra whitespace isn't going to change or 
affect anything.

It is a *totally* different thing to completely ignore the MIME spec 
and transform a text/plain message into a message that potentially 
carries malicious data.  There is only ONE mandatory field

3. Where do you draw the line on trying to work around admittedly 
broken senders?  For example, what about an MUA that sends the 
following message:

MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding : base64

[Malicious base64 encoded data]

An RFC compliant MIME parser will correctly parse this as jumbled text 
because the data is 7bit encoded.  Conversely, any MUA that is trying 
to be liberal in what they parse by instead assuming that this message 
contains base64 data is Doing It Wrong (TM).  This is not a base64 
encoded message.

Broken clients are broken clients.  These broken clients send out 
broken messages.  It should not (and must not) be our duty to try to 
"fix" these broken messages.

And quite frankly, 99.9% of all broken MIME messages are being sent 
out by spammers anyway.  We should not sacrifice security to try to 
handle the tiny percentage of broken mailers that exist.

I've created a patch to improve the parser.

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)?

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.

Hi,

I had a Kolab calendar entry (created by another Kolab client)
that loaded just fine. When I tried to modify the object,
an exception about a missing mime part was thrown:

"Missing expected mime type (application/x-vnd.kolab.event)
in object "123" in folder "INBOX/Calendar"!


Digging through the code I found out the parse code
for Kolab messages uses

"Horde_Imap_Client_Fetch_Query()->structure()"
and then "Horde_Imap_Client->getStructure()".

-> This properly finds the Kolab XML attachment part.


The save() function re-reads the message.
It uses "Horde_Imap_Client_Fetch_Query()->fullText()"
and then "Horde_Mime_Part::parseMessage()".

-> The resulting body structure is one "text/plain" part.


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?

Thomas