GNOME Bugzilla – Bug 222496
Evolution does not appear to support ALERT messages
Last modified: 2013-09-10 13:49:38 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Using Cyrus 2.0.16 IMAPd server. IF the server issues an ALERT message due to quota issues Evolution 1.0.2 and 1.0.3 appear to ignore it. Instead the mailbox can not be accessed. Steps to reproduce the problem: 1. Setup a cyrus imap account 2. Fill the account quota 3. Attempt to login with evolution 1.0.2 or 1.0.3 Actual Results: Evolution fails to login to the imap account when it is over quota. Expected Results: Evolution should login but only allow deleting / reading of email. Evolution should display a popup alert with the alert from the server. Additional Information: section of 3.4.11 of RFC2683 is relevant.
without knowing what the log looks like, I can only say "if evolution fails to login, it's because the server is not allowing us to login, thus not our problem" can you do the following? open 2 xterms, in xterm1 type: export CAMEL_VERBOSE_DEBUG=1; killev; evolution-mail and after waiting 10 seconds or so, start up evolution in the second terminal. the first terminal will get a log of the IMAP protocol transaction, could you paste that here (or attach it as a file)? thanks
Created attachment 41121 [details] IMAP sesson debug output with over quota mailbox
See the attached file to this bug report. In that file an over quota mailbox is opened in evo 1.0.3. Look for the line matching "received: * NO [ALERT] Mailbox is over quota" in the log. Here's what happened: 1) User test1 logged in 2) User was able to see all mails in his mailbox. 3) User did NOT receive alert message with over quota warning Previously, when working with a real world account, a user on this server was not able to login using evo when his mailbox was over quota. Why this test1 account did not show that same problem I'm sure of yet. Based on this, let's set the target resolution for this bug to be that evolution properly handles and displays ALERT messages to the user. For reference, the IMP 3.0 web mail client does handle this ALERT message using the same server / test1 account as attached evo log file was produced from. section of 3.4.11 of RFC2683 may be relevant
Bug status? Any fixes in the nightly builds to test? And more info needed from me?
Adjusting bug priority since it's been crusty.
I dunno. The thing is, mailboxes can be opened in READ-ONLY mode too, if say another client is accessing that mailbox already. Should we report those to the user too? I think it'd get pretty annoying. Now, maybe if the user tried to add a message to the mailbox, we could pop up an alert about the mailbox being READ-ONLY (same for disk-quotas?).
I think this is different from what you're suggestng. In this case I don't think it matters one bit if the mailbox is RW or RO. The root of the problem appears to be that Evolution ignores the ALERT message. From the attached debug output we can see: "received: * NO [ALERT] Mailbox is over quota" This ALERT is never passed on to the user. Cut and pasted from RFC2683 section 3.4.11: 3.4.11. ALERT Response Codes The protocol spec is very clear on the matter of what to do with ALERT response codes, and yet there are many clients that violate it so it needs to be said anyway: "The human-readable text contains a special alert that must be presented to the user in a fashion that calls the user's attention to the message." That should be clear enough, but I'll repeat it here: Clients must present ALERT text clearly to the user.
Scott's right, we need to do something with this. Since i'm not sure what yet, i'll just say its dependent on the tracking bug 216927. It might not be that hard if we can just process it as part of the STATUS query, etc (depends on where ALERT can come). And Jeff, yeah we should do something different with READ-ONLY mailboxes too.
Created attachment 41476 [details] [review] possible fix
applied. untested though.
closing.
*** bug 241625 has been marked as a duplicate of this bug. ***
This bug is confirmed still present in 1.2.x stable and 1.3.x preview releases. Looking at the patch my best guess would be to check for "BAD" and "NO" response status when looking for an ALERT response code. See rfc2683 section 3.4.11. ALERT Response Codes and rfc2060 section 7.1 Server Responses - Status Responses for details or response code/response status combinations.
The patch (http://bugzilla.gnome.org/attachment.cgi?id=41476) that was commited by "Not Zed" (rev. 1.52 of providers/imap/camel-imap-command.c) is not quite right. It tries to compare the result from the server with "* OK [ALERT]", when the response from the server, as can be seen in the attachment http://bugzilla.gnome.org/attachment.cgi?id=41121, is clearly "* NO [ALERT]". Simply changing the "OK", to "NO" on line 332 will correct (this case). Although, I have not read the RFC so I don't know if the response is always "NO" or if it can be either "NO" or "OK", or anything else for that fact.
The patch needs to check for BAD, NO, or OK status repsonses and then look for the ALERT response code. Having "* NO [ALERT]" is just as valid as having "* OK [ALERT]" or "* BAD [ALERT]". Taken from http://www.faqs.org/rfcs/rfc2060.html 7.1. Server Responses - Status Responses Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD may be tagged or untagged. PREAUTH and BYE are always untagged. Status responses MAY include an OPTIONAL "response code". A response code consists of data inside square brackets in the form of an atom, possibly followed by a space and arguments. The response code contains additional information or status codes for client software beyond the OK/NO/BAD condition, and are defined when there is a specific action that a client can take based upon the additional information. The currently defined response codes are: ALERT The human-readable text contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message. ... <SNIP>
yes, we know... I already have code that properly deals with this but it won't make it in for 1.4 http://primates.ximian.com/~fejj/camel-imap-engine.c anyways, re-closing this since I am going to treat this as a dup of "imap rewrite"
Are you saying 1.4.x or are you saying 1.6? I'm curious as to the reason it won't make 1.4 since this bug has been around for a quite a while now. It is really hurting our users when it comes to evo usage. Quota warnings and alerts are not getting properly displayed resulting in excessive bug reports. Is there a bug number for "imap rewrite" or is this the engine rewrite that was supposed to make it into the current 1.2 stable series?
No new features will make 1.2 unless something terrible happens.
Glad to see this active again. I'm willing to test any patches.
*** bug 256638 has been marked as a duplicate of this bug. ***
umm, if you're able to test patches, i'm sure you could've come up with the trivial one i'm about to attach. anyway this might make 2.0.4 with any luck. in 2.1 the code is all new, so who knows.
Created attachment 44681 [details] [review] might fix
I've actually already tested ALERTs in the new code and they work
b
It works for me in 2.0.4.hence changed status of bug as verified