IMAP over quota popup warnings displayed by thunderbird

[russellf]

I'm posting this in the hope that it will get indexed by google and save some other poor soul's sanity...

I recently went over 90% of the quota on my IMAP server and started to receive popups from TB. I spent ages going through the TB configuration and docs (such as they are) and finally googled and everything I could think of to find a way to stop the alerts. All to no avail. I finally was typing up a note in this very window when the penny dri^Hopped, the popup message was coming from Cyrus the IMAP server, not from TB.

I'm security officer for a large university and I remembered a discussion with the mail folk about the possibility of using IMAP popups to alert Users to warn users if we suspected malware had made it through our defenses and had got into user's inboxes. So I knew that IMAP had a popup capability and it figured that Cyrus would use it for an quota warning. A quick check with our mail folk confirmed that is was what was happening.

So, if you get mysterious popup messages from your IMAP mail client (TB or whatever) don't assume they are coming from the client. The client may just be relaying messages from the server. I'm going to talk to our mail folk to see if we can change the message so it is clear that the message originates on the server. I'm also asking if the can change the config for one special user ;)

[Guest]

I am that poor soul. Thankyou, this drives me _absolutely_nuts_.

[rsx11m]

Thunderbird has a "quota meter" which shows up in the status bar when you exceed 75% of your quota, then turns yellow and red at certain thresholds (80% and 95%, those can be set with the mail.quota.mainwindow_threshold preferences in the Config Editor, Tools > Options > Advanced > General tab).

The pop-up message is a different story. That warning actually comes from the server, and Thunderbird is obliged to present this to the user "as is". There are other cases where repeated pop-up boxes are rather annoying than helpful, thus the introduction of an Activity Manager to present those in a better way is under discussion.

[superposition]

These pop-up messages are infuriating. I'm in the same situation, at a university, over 90% usage, server wont stop sending these messages, Thunderbird wont stop forcing them to be displayed. I'm pretty sure most UK universities have the same issue.

I'm near the end of my course, I'm very happy having only 10% free space remaining, it makes no difference to me, but I've had to delete emails purely to avoid this problem.

Don't think I'm ripping into TB, it's a great piece of software, I'm only writing this because after years of perfect use with FF and TB, this is the first thing I've come across that's truly frustrating in a kind of 'microsoft,-gunna-make-you-smash-your-head-into-the-keyboard' way.

Oli.

[rsx11m]

Please talk to your IT people. As stated correctly in the first post, the warning is issued by the server and does not result from Thunderbird's reading of the quota (it will only open the red quota meter in the status bar). Per standard, the client must forward that message to the user.

[Olli Savolainen]

The issue is not that the warnings are sent, but that they are displayed obtrusively. This is most harmful when doing a seach of the entire mail account: the warning is issued every time the mail client enters a new folder, and thus I have to guard my computer as it goes through the dozens of folders, being there to 'ok' moving to each of the folders.

A nonmodal popup would do the trick just as well, or does the standard specify explicitly that the application must wait the user to confirm they have understood the warning, before the client can do anything? For example, warnings issued by modern browsers of blocked popups or the nonmodal dialogs by firefox asking if the user wants their password saved, would offer the warning "as is" without destroying the user experience.

Relaying the responsibility of UI design to sysadmins who usually do not know anything about usability is a typical problem of open source usability, usually leading to also another issue, the proliferation of options when developers do not actually understand what users really need.

[Olli Savolainen]

The bug is at
https://bugzilla.mozilla.org/show_bug.cgi?id=247193

[robolange]

So my understanding from this discussion is that the IMAP standard defines some pseudo-out-of-band mechanism for the server to send short text messages to the user agent. Does anyone know the official, standard terminology for this "feature". Perhaps if we knew that, we would find that there is some about:config option to turn it off, or some add-on to disable it.

Frankly, if I have to sacrifice all server messages, or whatever they are called, to get rid of this stupid quota nonsense, then I am okay with that. If my admin wants to contact me for some reason, he can contact me out-of-band, or even disable my email and force me to contact him, but there is never any excuse to pester a user like this.

[robolange]

As a followup to my request, I have scoured traces of my IMAP sessions and the IMAP standard document (RFC 3501) and have found that these server messages fall under section 7.1, server status responses, and more specifically, response NO with response code ALERT. The standard says that an alert is "human-readable text [that] contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message." No doubt, the Thunderbird's developers' insistence on keeping the annoying popups are due to a misplaced desire to follow standards to the letter.

Human-readable text means that this is not something that affects how your mail client works. Therefore, in theory, ignoring these messages should cause no harm, and the only alerts I have seen in my IMAP session logs are these quota alerts.

My instinct is that until a Mozilla UI-expert rewrites the code to make the alerts non-intrusive, Thunderbird should be modified to allow users to ignore them, standard be damned. Right now I am compiling a relatively small change to the protocol handler to ignore alerts. Assuming I modified the right bit of code, I will then add an about:config option, something like mailnews.imap.suppressTextAlerts, and will ignore the alerts only if that option is toggled.

I doubt that Thunderbird developers will accept this patch, but perhaps user-focused distribs like Ubuntu will.

[rsx11m]

No doubt, the Thunderbird's developers' insistence on keeping the annoying popups are due to a misplaced desire to follow standards to the letter.

Well, that's what standards are good for, and Mozilla ain't Microsoft making up their own standards...

Human-readable text means that this is not something that affects how your mail client works. Therefore, in theory, ignoring these messages should cause no harm, and the only alerts I have seen in my IMAP session logs are these quota alerts.

As I explained in the comment you are citing above, the problem is to distinguish a "real" alert from the quota message, and/or also to recognize multiple identical messages to suppress duplicates. Thus, some logic would be needed to assure that, otherwise you are probably right that such a patch wouldn't be accepted by the devs.

My instinct is that until a Mozilla UI-expert rewrites the code to make the alerts non-intrusive

Not all patches come from the developers, thus I'd nevertheless recommend that you post the patch. Be it for users who want to switch it of themselves in this way (and know how to apply it), or just as an incentive or pointer for anybody who wants to take the bug and finalize it.

[robolange]

Well, that's what standards are good for, and Mozilla ain't Microsoft making up their own standards...

Standards exist mostly to specify state machines, grammars, and other bits of machine-to-machine interactions. In this particular instance, the standard unnecessarily specifies a machine-to-non-machine interaction that is rather stupid and is known to be very frustrating to users. Sometimes it is justifiable to ignore a broken part of a standard to improve usability, when it does not interfere with inter-machine interoperability.

As I explained in the comment you are citing above, the problem is to distinguish a "real" alert from the quota message, and/or also to recognize multiple identical messages to suppress duplicates. Thus, some logic would be needed to assure that, otherwise you are probably right that such a patch wouldn't be accepted by the devs.

Point one, doesn't filtering "duplicates" violate the standard? That is, the standard says that alerts must be presented to the user, but makes no mention of duplicates. Presumably, if the server wanted to send you 100 of the same message, there was a "good" reason for it.

Point two, there actually does seem to be some logic in Thunderbird to suppress duplicate alerts. However, it only works if the alerts are contiguous in the IMAP session, and the quota alerts usually are separated by other non-alert stuff.

Point three, I am not sure what you mean by "real" alerts. I'm not convinced that I care about anything that an IMAP server might send via that mechanism. The only examples I have seen are anachronistic, specifically, warnings that the server is going down soon (Who cares, I'll save my draft mail and send it when the server comes back up. Besides, downtime notification is better handled via an actual email, anyways.), and quota warnings (Thunderbird already has a better way to find this information). Does anyone have examples of alert messages that are not better handled by actual email?

Not all patches come from the developers, thus I'd nevertheless recommend that you post the patch. Be it for users who want to switch it of themselves in this way (and know how to apply it), or just as an incentive or pointer for anybody who wants to take the bug and finalize it.

Yeah, the patch will point out the location in the code base where the message box call is. Perhaps someone familiar with XPCOM, XUL, and all of those other confusing frameworks will then know of a way to switch this to one of those non-intrusive banners. Then, we might appease the standards gods and still have a usable mail client.

Anyway, I have the patch, it compiled, I tested it, and it worked. Thunderbird now no longer shows me quota warnings, or presumably any other server alert messages. I have stress tested it by going over my quota, and I still get error messages when I should, for example, when attempting to copy a message to a folder after I have passed my quota. I am not sure what is the appropriate forum for posting the patch. I suppose Mozilla's bugzilla (listed in another post above) will do, but I also have an Ubuntu-specific patchset that should make it easier for Ubuntu users to build a patched deb package.

[rsx11m]

In this particular instance, the standard unnecessarily specifies a machine-to-non-machine interaction that is rather stupid and is known to be very frustrating to users.

It specifies that an alert message has to be presented to the user as such, so I'm not sure if I'd call this "unnecessary". The apparent problem that an alert is an alert and no further granularity (like info, warning, error, etc., as frequently seen in such mechanisms) is available. The server stupidly sends an informational message in this way, doing this inappropriately often, and that remains the root of the problem.

Sometimes it is justifiable to ignore a broken part of a standard to improve usability, when it does not interfere with inter-machine interoperability.

I agree with that, and also with your following comment. Some pragmatism is certainly fine as long as it doesn't pose any other problems (in terms of the "real" alerts, which could indicate whatever server issue may occur on the other end that needs to alert the user that he or she shouldn't continue for whatever reason).

there actually does seem to be some logic in Thunderbird to suppress duplicate alerts. However, it only works if the alerts are contiguous in the IMAP session, and the quota alerts usually are separated by other non-alert stuff.

That probably won't cover the 91% versus 92% case being duplicates.

Does anyone have examples of alert messages that are not better handled by actual email?

What do you mean by actual e-mail? The server can give you a "permission denied" or "message not found" or "write error" or whatever message it pleases to send by this mechanism. Sure, other than "mailbox full" I didn't see any such messages either, which doesn't imply that they don't exist and that they don't need to be presented to the user's attention immediately.

I am not sure what is the appropriate forum for posting the patch. I suppose Mozilla's bugzilla (listed in another post above) will do

I can't say anything about ubuntu, but you can attach the patch (preferably against the comm-central sources) to that bug report without flagging it for review or anything, explain what it does and that it presents a workaround for anybody who'd like it.

[robolange]

What do you mean by actual e-mail? The server can give you a "permission denied" or "message not found" or "write error" or whatever message it pleases to send by this mechanism. Sure, other than "mailbox full" I didn't see any such messages either, which doesn't imply that they don't exist and that they don't need to be presented to the user's attention immediately.

I guess my point is that I have done some preliminary testing, and messages such as (paraphrasing, don't have the proper quote handy) "Error: could not write message to folder because mailbox is full" still are presented. I *believe* that because these messages are attached to specific IMAP error conditions, they travel along a different path internally. I *believe* that the only server responses my patch ignores are the ones that are not attached to any specific condition, and are simply generic "alerts". Of course, I'll accept that I may be unaware of genuinely important conditions that are only communicated via the generic alert mechanism, but I haven't run across one. And of course, I only have access to a few different types of IMAP server, so who knows how many different ones communicate using this annoying generic mechanism. Of course, this patch should be taken with a grain of salt.

I can't say anything about ubuntu, but you can attach the patch (preferably against the comm-central sources) to that bug report without flagging it for review or anything, explain what it does and that it presents a workaround for anybody who'd like it.

Okay, I'll look into posting the generic patch in that manner. I bet there is also an Ubuntu launchpad bug for this problem, so I will try to find it and post the Ubuntu patch there, then let this forum know about that link.

[rsx11m]

I guess my point is that I have done some preliminary testing, and messages such as (paraphrasing, don't have the proper quote handy) "Error: could not write message to folder because mailbox is full" still are presented. I *believe* that because these messages are attached to specific IMAP error conditions, they travel along a different path internally. I *believe* that the only server responses my patch ignores are the ones that are not attached to any specific condition, and are simply generic "alerts".

I think adding this to the bug report and posting a patch even if it's incomplete at this time is a good move, especially if some basic filtering of the alerts by type is done already. Nothing will happen for 3.0 any more, but for 3.1 (or whatever the next version is) having a partial patch should help with the progress of that bug.

[Regis R]

Hello guys,

I'm having the same trouble. If you have a patch to filter these quota alerts, could you share it ? Where can I download it ?

Thanks, Regis.