IMAP Gateway: error when saving email as draft

[FuePi]

1. Create new email.
2. Save email as a draft.

20090630-114205.336|| 0||demo1||28 Response8
20090630-114205.391|| 0||demo1||sldkfj
20090630-114205.392|| 0||demo1||C: 29 uid SEARCH UNDELETED HEADER Message-ID <email address hidden>
Syntax error
Couldn't repair and continue parse
20090630-114205.394|| 0||demo1||command processing: ""
20090630-114205.395|| 0||demo1||29 Response1
20090630-114205.395|| 0||demo1||29 Response2
20090630-114205.395|| 0||demo1||29 Response3
20090630-114205.395|| 0||demo1||29 Response7
20090630-114205.395|| 0||demo1||S: 29 BAD XXX Unrecognized Command

[Andreas Hügel (andreas-huegel)]

Problem is: SEARCH command is not jet implemented

[Andreas Hügel (andreas-huegel)]

The search command has been implemented so far, that this command will return the right response, so Thunderbird can continue saving the draft message and remove the original mail from drafts folder.

[Andreas Hügel (andreas-huegel)]

We still have a problem. As we return all emails, not only the undeleted ones, thunderbird has a problem. If you close and reopen a draft email, it will keep old copies if you save it again multiple times. Thunderbird only expects 2 emails to be returned by search. The first one will be deleted. As in our case search returns an even older copy first, that copy is attempted to be deleted.

[Andreas Hügel (andreas-huegel)]

implementation of keyword UNDELETED has been done. The Problem listed above persists

[Andreas Hügel (andreas-huegel)]

The Problem of saving draft messages

2 cases:

1) creating a draft message and saving it multiple times. Works.
2) reopening a draft message and saving it multiple times. Works only every 2nd time.

We discuss case 2) here:

Findigs:
- whereas Thunderbird creates a new Message-Id every time in case 1), it keeps the Message-Id of the stored draft message in case 2)
- suspicion was, that Thunderbird requires untagged responses of the store command, which had not been implemented. After implementation the problem persistet.
- suspicion was, that some return of the IMAP Gateway was wrong. We logged a similar session to our company IMAP server. Finding was, the UIDPLUS and QUOTA extensions have been used in the session. We don't implement these to date. Also, no search command has been issued by Thunderbird in this session.
- APPENDUID response of the UIDPLUS extension was implemented as it is desclared as SHOULD even if UIDPLUS itself is not implemented. Trouble is, this solves the problem only, if the capability UIDPLUS is exposed to Thunderbird.

Conclusion:
Thunderbird is probably having a problem handling the situation if UIDPLUS is not supported. Reasons for that are:
- UIDPLUS is a rather common extension, so Thunderbird does not come accross it in many cases
- the APPENDUID response of the append command is recommended to implement, even if UIDPLUS is not implemented in whole, so it may be supplied by many servers, supporting the assumption above

Solution:
- we would need to implement at least the UID EXPUNGE, so the UIDPLUS requirements are met. We might be able to let the COPYUID response undone, as it is declared SHOULD only. But we need to test that.
- APPENDUID and uid expunge have been implemented. COPYUID is not.

Risks:
- COPYUID means a major change in the handling of CmdCopy, therefor it is considerable to not implement COPYUID as it is a SHOULD only. But we can only prove non impact to Thunderbird by thorough testing. Not all clients fall back on workarounds if optional features are missing. The client might change behaviour in unforseen places/processes, causing other problems by additionaly requesting features of the standard which we don't implement yet.
- If implementation of COPYUID would somehow be required, I'm not even sure, if the implementation can be realized, as we have to find out which is the new mail by other means. Either by scanning notifications or by getting a new table. In both cases we have to find out, if the mail was created by our process. Notifications will be rather unreliable when switching from one store provider to another, as notifications can be implemented differently by providers and they don't reliably identify the link of copied message and copy initiating process.
- some tests of expunging/copying have shown, that uid expunge is not being issued by Thunderbird, and the missing COPYUID information did not seem to disurb operations. Thorough testing should still be done.

Status:
- Thunderbird seems to work right with the UIDPLUS extension
- further tests required, as only view tests have been performed