| Summary: | Support content type message/partial (RFC 2046) reassembling messages | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Barry O'Donovan <barry> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | annma, kavol, kde, montel, pancho.s, psychonaut |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Barry O'Donovan
2003-11-07 18:03:06 UTC
See also RFC 1344 and http://www.kb.cert.org/vuls/id/836088 Message/partial fragments need to be reassembled prior to, or at the latest in conjunction with any (anti-spam, anti-virus, etc.) filtering. As kmail retrieves messages from a {POP,IMAP,local} message store which is typically after such filtering, the messages should already have been reassembled. If reassembly is incorporated into kmail, it should be done very carefully and in accordance with the guidelines in RFC 1344, and paying special attention to any filtering options or plugins. Note that this bug is still present in KDE 4.3.1, which is very sad ... What's the status of this? Reassigning to kmail2, please Bruce, Barry and kavol update this bug report against KMail2. Thanks in advance! (In reply to comment #3) > What's the status of this? > > Reassigning to kmail2, please Bruce, Barry and kavol update this bug report > against KMail2. Thanks in advance! now I'm on KDE 4.7.3 I've got one series of such messages in my inbox, and I still see it as six separate messages and kmail is still unable to combine them to allow me to see the original message which was split I've never seen such partial messages... Kavol, could you please post an example? Also, it would be interesting, how other mail clients (e.g. Thunderbird) handle this. If I remember correctly this type of partial messages were common back when emails often had a fixed size limit. It is splitting a single message over multiple emails, was also commonly used by usenet newsgroups. Yes, I remember and found some evidence that they are still produced by recent Outlook versions. However, these days they seem to be mostly used for obfuscating malware, because split up attachments can't be checked by antivirus software. The security problems are so large that even Exchange Server 2007 blocks them, as well as Qmail and probably more mail servers and antivirus software. Finally, US-CERT explicitely warns from automatically reassembling the partial messages (https://www.kb.cert.org/vuls/id/836088) and proposes rejecting partial messages. So if some really stable code with secure logics and a foolproof UI existed, we might want to think about it. But it doesn't, and the demand has been ceasing, so I think it's really not worth the hassle. Therefore I'm marking this WONTFIX. (In reply to comment #5) > I've never seen such partial messages... great, and I've never had any music in MusePack or WavePack or some other formats that are supported by Qmmp - yet it hadn't prevented me from translating the respective plugins when I was working on Qmmp translation to Czech, and it doesn't prevent me from building these plugins (and resolving any build issues associated with them) when maintaining the Qmmp package in Fedora ... > Kavol, could you please post an example? no, because 10 MiB attachments are not allowed here (In reply to comment #7) > Yes, I remember and found some evidence that they are still produced by > recent Outlook versions. However, these days they seem to be mostly used for > obfuscating malware, because split up attachments can't be checked by > antivirus software. please do more research these days, they are *still* produced by multipurpose office machines when sending large emails (bix scans and faxes converted to emails) > The security problems are so large that even Exchange Server 2007 blocks > them, as well as Qmail and probably more mail servers and antivirus > software. Finally, US-CERT explicitely warns from automatically reassembling > the partial messages (https://www.kb.cert.org/vuls/id/836088) and proposes > rejecting partial messages. ahem, isn't this a bit incomplete? - US-CERT mentions blocking this type as one of *four* possible solutions ... btw, isn't a reference to a document that is more than ten years old a bit inappropriate when you are talking about "these days"? > So if some really stable code I'm just sad that kmail team hadn't demanded "really stable code" also when transitioning to Akonadi ... > with secure logics and a foolproof UI existed, > we might want to think about it. > But it doesn't, yes, this is the point of this RFE that we, the humble users, are asking you, the mighty developers, to write it ... btw, I really do not understand what do you mean by demanding a code that has its own UI? - kmail is *the* UI, what do you need is the backend which will compose the parts into one message ... as for the UI, you even have a solid basis in kmail for this - it could be the same like when kmail is asking about displaying html content or reading the external links > and the demand has been ceasing, [Citation needed] I still need this when receiving large attachments from our office machine; meanwhile, the number of people employed in the same office, thus using the same machine, has grown ... > so I think it's really not worth the hassle. > Therefore I'm marking this WONTFIX. hm, what would it take to reconsider? We can't fix it if we don't have test-case. Sorry but I don't have time to search on google for it. And I don't know which client can generate it. (In reply to comment #8) > hm, what would it take to reconsider? Certainly, a rock solid patch. A nicer attitude would help, too. And some testcase would be the minimum. Finally, this is really no must-have feature, which to my knowledge atm is supported only by TheBat. Thunderbird has an open issue that didn't receive any comment in 6 years (https://bugzilla.mozilla.org/show_bug.cgi?id=71189). > > Kavol, could you please post an example? > no, because 10 MiB attachments are not allowed here Is the single partial message 10 MiBs? If yes, is there a chance to produce a smaller testcase? Otherwise a file uploading service would be the way to go. > these days, they are *still* produced by multipurpose office machines when > sending large emails (bix scans and faxes converted to emails) > [...] > I still need this when receiving large attachments from our office machine; > meanwhile, the number of people employed in the same office, thus using the > same machine, has grown ... Okay. Now, it would be interesting to know if this is used by just your multipurpose office machines and maybe a few more, or if it is something like an industry-standard. The declining demand for adding this feature suggests that it isn't widely used (anymore). But if you have other evidence, just bring it up! > btw, isn't a reference to a document that is more than ten years old a bit > inappropriate when you are talking about "these days"? Not per se. Clamav seems to be able to scan partial messages, Exchange Server blocks them, other solutions still might let them slip through. We can't take care of everything, but we need to know. > yes, this is the point of this RFE that we, the humble users, are asking > you, the mighty developers, to write it ... Yes, and this will happen, if the maintainers are convinced that this, at least to some extent, is a priority. > btw, I really do not understand what do you mean by demanding a code that > has its own UI? - kmail is *the* UI, what do you need is the backend which > will compose the parts into one message ... Surely the backend is central piece of the solution, something like uudeview or nmh's nhstore would do it. But then: is it worth shipping another library or adding a dependency? Also we need to figure out how to store partial messages, especially in IMAP environments. Do we just reassemble on the client-side? How do we quarantaine message parts until their last piece arrived? And then, how does this integrate with our messagelist model? And: do we cache the reassembled messages in Akonadi? Or do we even sync them up to the server? And if for security reasons we don't want to reassemble automatically, then we even more need a UI for all of that. So please refrain from downplaying this to "just some backend and voilà - there it is". It's not, and I'm still not convinced it's worth the pain, but am of course open for good arguments. To get it started, this might be interesting: - http://www.freesoft.org/CIE/RFC/1521/24.htm - http://rand-mh.sourceforge.net/book/mh/cosemime.html#ParMes - http://rand-mh.sourceforge.net/book/mh/remime.html#PartMess - http://securityvulns.com/Ldocument310.html Regards, Pancho This is very common in newsgroup readers. Perhaps you can find code to handle it in knode. In email-clients it is mostly common in those that share backend with newsreaders like Outlook express and such. (In reply to comment #9) > We can't fix it if we don't have test-case. > Sorry but I don't have time to search on google for it. > And I don't know which client can generate it. There's a small (23 KB) test case at https://bugzilla.mozilla.org/show_bug.cgi?id=71189 -- the direct link is https://bugzilla.mozilla.org/attachment.cgi?id=107916 |