Runbox increases all email storage quotas to 10 GB.

[hellie]

Although I am a devoted Fastmail and Promptpost fan this good news. I store everything at Runbox and will privacy policy that has been posted in another thread I will continue to do so. Everyone also knows Runbox is my back up address.

Absolutely brilliant.

Helen

[ivec]

Originally posted by carverrn
Any IMAP client could implement deleting attachments because the basic commands needed to do so already exist in IMAP. It would just need to download the message, delete the original, strip off the attachments, then upload the new version without the attachments.

Actually, by correctly using the IMAP body structure the attachment doesn't have to be downloaded for stripping. Attachment deletion is actually a very fast operation

[BKB]

Originally posted by ivec
Actually, by correctly using the IMAP body structure the attachment doesn't have to be downloaded for stripping. Attachment deletion is actually a very fast operation

Tell us more - I'm interested to know. How come TB is just adding this functionality, and why haven't we seen it on other clients?

[ivec]

Originally posted by BKB
Tell us more - I'm interested to know. How come TB is just adding this functionality, and why haven't we seen it on other clients?

I think there are several reasons. The first one is that there was never a great demand for this since IMAP was not very popular. Those who needed to clear their mailboxes from big attachments would either delete the whole message, hack around it themselves or use IMAPSize (the latter allows you to strip attachments from multiple messages in one go).

Second, IMAP doesn't (yet) provide attachment deletion as a protocol feature which makes people think it is not possible.

Third and most important, almost all email clients today still treat messages from IMAP stores in the old POP way (TB was one of them until recently). When you open a message for viewing they download the whole message with all attachments. So, imagine wanting to delete a 10MB attachment, your client would have to download the whole lot, do some MIME reordering and processing (the POP way - on the whole message) and upload a stripped message. Not very effective. IMAP works differently, it provides nice ways for clients to download only message parts that they really need. The hard thing about this is that MIME parsing can't be done on the whole message, it has to be done by processing body structure replies from IMAP servers which is not trivial. And in order for a client to perform this operation it has to have a solid IMAP framework which TB now does.

[BKB]

Originally posted by ivec
I think there are several reasons. The first one is that there was never a great demand for this since IMAP was not very popular. Those who needed to clear their mailboxes from big attachments would either delete the whole message, hack around it themselves or use IMAPSize (the latter allows you to strip attachments from multiple messages in one go).

Second, IMAP doesn't (yet) provide attachment deletion as a protocol feature which makes people think it is not possible.

Third and most important, almost all email clients today still treat messages from IMAP stores in the old POP way (TB was one of them until recently). When you open a message for viewing they download the whole message with all attachments. So, imagine wanting to delete a 10MB attachment, your client would have to download the whole lot, do some MIME reordering and processing (the POP way - on the whole message) and upload a stripped message. Not very effective. IMAP works differently, it provides nice ways for clients to download only message parts that they really need. The hard thing about this is that MIME parsing can't be done on the whole message, it has to be done by processing body structure replies from IMAP servers which is not trivial. And in order for a client to perform this operation it has to have a solid IMAP framework which TB now does.

Pretty cool, thanks for the explanation.

[henrico]

I subscribed exactly two months ago. I know Runbox for years and it was time to join the club. I like the clean interface, the 1GB mail space, the 100mb file storage, the aliases, etc. And the support is very good. 29.95 dollars a year isn't very cheap, but I think it's worth it.

Now I have to pay 49,95 dollars, because Runbox has decided that we needed more space. I can't believe many customers asked for such an increase of storage. 1GB is very generous, 10GB is laughable IMHO. What user is ever going to come close to maxing out that storage limit?

I hope Runbox will think about introducing a Lite version. Two different plans; that will not be the end of Runbox...

[BKB]

Originally posted by henrico
I hope Runbox will think about introducing a Lite version. Two different plans; that will not be the end of Runbox...

The end of Runbox? That would make a lot of people very sad.

[MarkD]

Originally posted by henrico
1GB is very generous, 10GB is laughable IMHO. What user is ever going to come close to maxing out that storage limit?

You're right of course, no users would really need this right now. But this reminds me of comments I have heard over the years like:

* On (at the time) a new 20gb hard drive - why would anyone ever need 20gb of hard drive space in their home computer?

* On RAM - 640K of memory should be enough for anyone (allegedly a quote by Bill Gates!)

10gb is way beyond necessary today and that's not going to change in the next 12 months or so. But beyond that who knows? I'm sure that people will eventually be using this sort of space.

Not sure why RB would want to move storage up so much so fast right now, but I guess they want to be seen as moving first ahead of the pack. I think it's a good way for them to get noticed, and let's be honest, hardly anyone will actually be using up all that server space anytime too soon.

MarkD

[drkotsius]

Originally posted by carverrn
Runbox has very limited resources (e.g. only a few staff people) so they can't afford to spread these already strapped resources over servicing the demands of several markets.

This move is a business decision that I think makes sense given their current resources. Runbox's only source of revenue (that I know of) is their email service. So resources (time and money for support and development) would be better spent on fewer high-end users than more low-end users.

Please allow me the thought that the main point (made in the first paragraph) does not necessarily follow from the arguments put forward. Indeed, critical resources are better spent on well-paying users (high-end or not, that's another matter). Yet not all resources are equally scarce, and there is therefore scope for market segmentation with variable levels of service. Support for Runbox-lite users could, for instance, be provided exclusively through this forum.

And yes, let as also consider the possibility of Runbox people making erroneous business decisions. Or even of hiding their real future plans...

[rishi]

They need to increase the attachment size beyond 30 Mb.

Also this is not correct on the Runbox forum itself but someone ought to come
out with a Runbox version of viksoe.dk so we can utilize this storage for files

Just increasing storage won't be enough for higher end user , you need to have features like nested folders or search facility to manage that space.

[Trip]

Originally posted by rishi
They need to increase the attachment size beyond 30 Mb.

Yeah, I would support that. 100MB attachments would be solid. Real solid. Thoughts?

Trip

[Shelded]

The main thought I have is that mailing things that large is absurd. With the 30% overhead added it makes me wonder why not just use a file store. I've never mailed anything over 15MB except for a test and I did that on my DSL at 256 up. Now that I'm on cable at 128 up it means even more to economize on upload size.

[Edwin]

Why not have two file attachment sizes?

Mail from a Runbox user to another Runbox user could have a massive limit (e.g. 100MB).

Mail from a Runbox user to the outside could still be subject the current limit, since there's very little chance a 100MB attachment will make it across an unknown-length chain of servers spread across the globe and most destination mail systems won't accept it anyway.

That way, Runbox doesn't need to transmit the massive attachment across the Web once it's uploaded (since they just need to move it between servers or even within the same server), and there's a 100% chance of it arriving in the destination user's mailbox.

Great for multiple company mailboxes... For example, give a company's 25 employees their own Runbox-powered addresses under @companydomain.com and they know they can send huge files back and forth to each other. The limits only come in when going "outside".

[kservik]

Great idea Edwin.

[s a]

 
actually, this entire upgrade is old news