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

* Your Email Address
* Spam protection	Enter the letters below: .__.. ,._..__.. . \| \| \./ \| [__]\|__\| \|__\| \| _\|_\| \|\| \|
Comment	>> 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)" > > 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/) > >> What could go wrong if we do the same (to be more relaxed on parsing)? > > 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.
Attachment
Watch this ticket

Saved Queries