+++ This bug was initially created as a clone of Bug #482476 +++ Spun off to distinguish space/time from download volume policies. (In reply to bug 482476 comment #6) > (In reply to bug 482476 comment #1) > > A static interface that looks something to the effect of this: > > > > Keep the last [ 3 ] ( months | v ) of email and use less than [ 3 ] ( gigabytes > > | v ) of disk space. > > According to the discussions there [bug 497833], this would need to be extended by a 2nd set > of choices to limit the rate of the download (e.g., for slow/costly connections > or servers limiting the amount of data over time before blocking an account). (In reply to bug 482476 comment #7) > Could this also be based on active network connections? Using a (bad) UMTS or > even a GPRS connection for caching mails is not so nice, and might be expensive > depending on the plan ... (In reply to bug 482476 comment #8) > rate of download is an orthogonal issue and I'd rather that be talked about in > a different bug to avoid complicating this bug, which is going to be > complicated enough - this is more about which messages to download, and > retention policy of already downloaded messages (i.e., which already downloaded > messages to remove in favor of newer messages). Auto-compact of offline stores > is very closely related, since, if the main goal is to limit the amount of disk > space used, we'll need to compact offline stores.

Adding to the initial collection of comments from the other bug: > (Quoting bug 482476 comment #6) ... e.g., for slow/costly connections > or servers limiting the amount of data over time before blocking an account That's the main motivation for nominating this as a TB3 blocker. There are several reports in the MZ forums that users got locked out of their accounts during the initial syncing and when rebuilding the index (one Gmail case today, and I recall coming across this issue before in one or more other threads). It's a bad advertisement if someone decides to give 3.0 a try and ends up being locked out of his or her account for a 24-hour penalty period or more, just due to download-bandwidth restrictions of the provider...

This bug seems to be about _rate_ of downloading being capped (as opposed to capping total download size, or max-age of downloaded messages). When it comes to Gmail in particular, my understanding from talking to someone @ google was that the current autosync policy alone shouldn't trigger a lockout -- it required a multiple of the total account data in a short period of time, so one TB3 setup alone shouldn't trigger a lockout. It'd be good to understand more about what caused the lockouts (multiple simultaneous TB3s? something else?) [Metered network connections are different - if you're using TB through an expensive connection, autosync will certainly download a lot, and could cost a lot -- but I don't think we have enough understanding of the parameters there to understand how to deal with that generically.]

(In reply to comment #2) > This bug seems to be about _rate_ of downloading being capped (as opposed to > capping total download size, or max-age of downloaded messages). Yes, this bug is primarily about bandwidth rather than volume. > When it comes to Gmail in particular, my understanding from talking to someone > @ google was that the current autosync policy alone shouldn't trigger a lockout I can only forward what has been reported in the MZ forums. Apparently the lockout by Gmail was not immediate but after several hours while autosyncing complete accounts with all folders. Thus, it appears to be measured over longer time intervals until it reaches a given threshold of exceeded bandwidth for this specific provider. And yes, I agree that the parameters of metering are difficult to define, something like "n KB/MB" every "m minutes/hours" is probably the only generic enough way to specify those.

Bug 508276 would be one fairly straightforward way to allow users with metered connections to keep from losing a bunch of money.

To forward some further feedback from the MZ forums after the 3.0b4 release, the double-whammy of synchronizing and indexing all messages in all accounts after migration of an existing or establishing a new profile or account is a point of major critique. There also have been further "bandwidth exceeded" shut-outs for Gmail users. Compared with the bandwidth restriction employed for automatic Thunderbird application updates (which is 300kB every 10 minutes, if I recall correctly), allowing synchronization to utilize the full available bandwidth appears rather reckless. While it is probably too late for a full implementation of this now, a "lite" version with fixed-size chunks and intervals similar to the automated updates should still be possible and would improve the initial user experience (at least for the synchronization part).

(In reply to comment #5) > While it is probably too late for a full implementation of this now, > a "lite" version with fixed-size chunks and intervals similar to the automated > updates should still be possible and would improve the initial user experience > (at least for the synchronization part). But please provide some migration UI (poptart or whatever) so that the user can say "do it now!". My IMAP accounts do not have quota.

There has been another report of Gmail lockout due to bandwidth in bug 520403, this time not at initial synchronization but after a while. (In reply to comment #6) > But please provide some migration UI (poptart or whatever) so that the user can > say "do it now!". This may be difficult now with the string freeze in effect. Some hidden pref with a reasonable default would be the best solution still possible for 3.0.

A *single* TB 3.0.3 user pushed 10Mbit/s for several hours yesterday. Oddly he moved well over 50GB of data even though he has a mailbox a fraction that size (maybe an additional bug?). Please consider turning sync off by default. This bug is 9 months old now and clearly hasn't been addressed (the user in question just installed 3.0.3 yesterday, 2010-03-29). This type of policy can be potentially disastrous for users (both in terms of losing access to their mail due to ISP or carrier limits, or worse, getting a devastatingly large bill from their provider).

This is a graph showing TB 3.0.3 bandwidth utilization for a single user. Note the point halfway where I terminated TB. This is for a single 3.3GB mailbox that is only syncing the last 30 days. I cannot imagine what TB is doing.