https://bugs.kde.org/show_bug.cgi?id=67516
--- Comment #10 from Bernd Oliver Sünderhauf <[email protected]> --- (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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
