[Bug 67516] Support content type message/partial (RFC 2046) reassembling messages

[Bernd Oliver Sünderhauf]

https://bugs.kde.org/show_bug.cgi?id=67516

--- Comment #10 from Bernd Oliver Sünderhauf <pancho.mz at riseup.net> ---
(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.