Deleting message

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open message
2. Push "Delete" buttom
3. Page refreshes but message still shown as undeleted. (Press F5 and it will 
be shown as deleted).

I think the problem is in code, that firstly get message, than mark it as 
deleted.

Original issue reported on code.google.com by akimov.alex on 22 Sep 2010 at 7:05

[GoogleCodeExporter]

Tested on this side and can't reproduce the problem. (I've tested with google 
IMAP, Cyrus and Yandex)

Original comment by hguerreiro@gmail.com on 22 Sep 2010 at 7:46

[GoogleCodeExporter]

Disregard my previous comment - tested on the message list...

- Tested on Cyrus: no error.
- Tested with Google IMAP and raises a MessageNotFound exception (because of 
the same problem that caused bug 23 - will fix).
- Tested on Yandex: no error
- Tested on Rambler: no error

There is a problem but only in Gmail and not in the way you've described.

Original comment by hguerreiro@gmail.com on 22 Sep 2010 at 8:02

[GoogleCodeExporter]

Fixed the problem that I've identified with Google IMAP.

Original comment by hguerreiro@gmail.com on 22 Sep 2010 at 9:57

[GoogleCodeExporter]

My bad, it happened with Ramblers imap only with one of my boxes. And still 
happens. I'll try to reproduce it in webpymail@ramber.ru today.

Original comment by akimov.alex on 23 Sep 2010 at 7:32

[GoogleCodeExporter]

Here is sample of Client-Server talk with Rambler:

C: KJLH005 UID STORE 41 -FLAGS (\Deleted)<cr><lf>
S: * 40 FETCH (FLAGS (\Seen))<cr><lf>
S: KJLH005 OK completed<cr><lf>

What does 40 in response means here?
Yandex talks like this:

C: GLEO006 UID STORE 40 +FLAGS (\Deleted)<cr><lf>
S: * 37 FETCH (UID 40 FLAGS (\Seen \Deleted))<cr><lf>
S: GLEO006 OK STORE completed<cr><lf>

I think that maybe changed flags are stored in wrong UID fetch response with 
Rambler?

Original comment by akimov.alex on 23 Sep 2010 at 8:13

[GoogleCodeExporter]

The rambler conversation is correct. 

> What does 40 in response means here?

That's the message number, it's like a UID but it is not permanent, it can 
change between sessions. Is you use non UID SEARCH for instance, you'll get 
message numbers as response instead of UIDs - check the IMAP RFC.

Original comment by hguerreiro@gmail.com on 23 Sep 2010 at 11:16

[GoogleCodeExporter]

Ok, but after conversation

C: MLCB005 UID STORE 41 +FLAGS (\Deleted)<cr><lf>
S: * 38 FETCH (FLAGS (\Seen \Deleted))<cr><lf>
S: MLCB005 OK completed<cr><lf>

self._imap.sstatus['fetch_response'] is :

{41: {'RFC822.SIZE': 2385, 'INTERNALDATE': datetime.datetime(2010, 9, 22, 12, 
47, 38), 'UID': 41, 'ENVELOPE': {<ENVELOPE_DESCRIPTION_GOES_HERE>}, 'FLAGS': 
['\\Seen'], 'ID': 38}, 38: {'FLAGS': ['\\Seen', '\\Deleted'], 'ID': 38}}

Is it correct? I'm talking about dict keys -- is it UIDs? If so, then 
imap.store adds false message to status dict.

Original comment by akimov.alex on 23 Sep 2010 at 12:09

[GoogleCodeExporter]

The dict keys should be UIDs. 

The server/client conversation is OK, however the fetch_response is not 
coherent:

- UID 41 => ID 38: {41: {'RFC822.SIZE': 2385, 'INTERNALDATE': 
datetime.datetime(2010, 9, 22, 12, 47, 38), 'UID': 41, 'ENVELOPE': 
{<ENVELOPE_DESCRIPTION_GOES_HERE>}, 'FLAGS': ['\\Seen'], 'ID': 38}

- But then you have: 38: {'FLAGS': ['\\Seen', '\\Deleted'], 'ID': 38}} which 
makes no sense.

Did you manage to reproduce this on webpymail@ramber.ru?

Original comment by hguerreiro@gmail.com on 24 Sep 2010 at 7:12

[GoogleCodeExporter]

Yep.
I expunged one message (UID 2).
Now bug is reproducing on message with UID = 3.

Original comment by akimov.alex on 24 Sep 2010 at 7:16

[GoogleCodeExporter]

I can also reproduce this in Rambler. Must have made some kind of mistake the 
last time I've tested this.

I think I understand the problem now:

Look at the conversation you've sent:

C: MLCB005 UID STORE 41 +FLAGS (\Deleted)<cr><lf>
S: * 38 FETCH (FLAGS (\Seen \Deleted))<cr><lf>
S: MLCB005 OK completed<cr><lf>

The conversation is almost OK, but it's missing the UID in the server answer, 
the server should have answered:

S: * 38 FETCH (FLAGS (\Seen \Deleted) UID 41)<cr><lf>

This originates the incoherence in the answer dict that I've noted in comment 
8. If there is a UID in the answer, we use the UID as key, otherwise we use the 
msg number. In this case a new dict key is created, it just happens that the 
message sequence numbers and the UIDs are very similar (for some reason they 
cease to be that way when we have more messages).

The Rambler's behavior is against the RFC (and if we think about it, not very 
useful in any way), we can read the following in the RFC:

      The number after the "*" in an untagged FETCH response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH. (RFC3501 Section 6.4.8)

Original comment by hguerreiro@gmail.com on 26 Sep 2010 at 1:40

[GoogleCodeExporter]

God damn russian IMAP servers, so full of bugs :)
I'll try to find Rambler support email for IMAP service and tell them about it.

Original comment by akimov.alex on 26 Sep 2010 at 6:12

[GoogleCodeExporter]

Yap lots of bugs! Marking this to be implemented in the quirks mode.

Original comment by hguerreiro@gmail.com on 27 Sep 2010 at 8:32

• Added labels: Quirks-Mode, Type-Enhancement, Wish
• Removed labels: Type-Defect