IMAP Considerations

FTGate has been tested with the following IMAP clients:

Client

IDLE

Handles NIL messages (i)

NOOP
Updates

XTRASH (ii)

Outlook Express

X

Deleted notification

N/A

X

Outlook 2002/XP

X

Deleted Notification

N/A

X

KMail

 

X

X

X

Ximian Evolution

 

Error dialog

X

Error Dialog

The Bat!

 

X

X

N/A

Eudora

 

X

X

 

Thunderbird

 

X

X

X

Mulberry

 

X

X

Nil messages

(i) Handling of Nil Messages

The IMAP protocol requires that a server does not delete any message from the server until all connected clients have been notified of its removal. This is to permit clients to request the message contents of deleted messages. There is no facility in IMAP to tell a client that a message has been deleted and thus the request cannot be honoured.

Thus the following is correct using the IMAP protocol:

  1. Client A connects to a folder, there are 200 messages

  2. Client B and C  connect to the same folder
    All clients see 200 messages

  3. All clients use FETCH and STORE but never do an operation that allows notification of expunged messages, or at least not often enough to count.

  4. Client A deletes the first 100 messages

  5. Client B deletes the second 100 messages

  6. Now client B, after expunging, gets told that the first 100 AND the second 100 are deleted

  7. So the three clients now see the following:
    Client C sees 200 messages and can access them all
    Client A Sees 100 messages and can access those 100
    Client B sees no messages and cannot access any

  8. This can persist for an indefinite period of time

FTGate Technology believe that this is contrary to the whole concept of shared folders, and that there is little point in sharing a folder if all the clients can potentially have different views of it. Thus FTGate will remove messages from the server at the time that the FIRST client EXPUNGEs the message. This may result in clients that do not synchronize frequently showing either blank content or an error message (see table for handling).

Clients that support the IDLE command will not suffer from any of these problems and all views of the folder should remain concurrently correct.

(ii) Handling of XTRASH

FTGate supports an XTRASH IMAP extension that is an experimental FTGate only extension. Configuration of this option is only available through WebAdmin,  WebMail and SolSight. There is no third party support for this extension expected.

This extension modified the standard IMAP handling such that rather than “flag as delete and then expunge”, FTGate will move messages that are marked as deleted in to a specified trash folder. It will then Expunge the folder, removing the messages. All connected clients will be notified of the changes when possible, see (i) above.

Limitations: Mail in shared folder will not be subjected to trash can operation, these messages will default to the IMAP delete/expunge model as there is no shared trash can.

(iia) The XTRASH command

The XTRASH command will be announced by the text XTRASH on the CAPABILITY line of the IMAP server response.

C: CAPABILITY

S: OK CAPABILITY …. XTRASH …

Obtaining the current trash folder

C: XTRASH

S: * XTRASH “current trash folder”

S: OK XTRASH COMPLETED

Setting/disabling the current trash folder

C: XSETTRASH “new trash folder”

S: * XTRASH “current trash folder”

S: OK XSETTRASH COMPLETED

Setting the new trash folder to a blank string will disable trashcan operation.