Re: IMAP server implementation details unclear in RFC-3501

On Wed, 2 Aug 2006, ondrugs@xxxxxxxxx wrote:
1. If one were to implement an IMAP server that allowed concurrent
connections to the same mailbox (across multiple servers across NFS),
and one of those connections performed an EXPUNGE command, what would
the (ideal) consequences be for the other connections?

The other connections will receive untagged EXPUNGE events when permitted in the session. Until an untagged EXPUNGE is permitted, the other connections can still access the expunged message data as described in RFC 2180 section 4.1.1.

If that turns out to be unimplementable due to server implementation details, disallow the shared EXPUNGE as described in RFC 2180 section 4.1.4.

Disregard RFC 2180 section 4.1.2 and 4.1.3; those techniques have been proven to cause problems for clients. I predicted as much, and opposed those sections being part of RFC 2180, but some people wanted to try those techniques to see if they were viable. They are not.

2. Section 5.2 states that a server is "NOT permitted to send an EXISTS
response that would reduce the number of messages in the mailbox". If
another connection expunged messages, then there would certainly be
less.

That is correct. Only an EXPUNGE response can reduce the number of messages in the mailbox.

3. Also, if an expunge occurred, there would be some discrepancy
between the message sequence numbers (in memory) of the currently
selected mailbox and the actual (on disk) mailbox. How would this be
resolved in respect to non-UID based requests?

That is the purpose of the EXPUNGE response. The instant that an EXPUNGE response is received, the in-memory copy of the associated message sequence number is removed, and the message sequence numbers of all subsequent in-memory messages are immediately decremented by 1.

4. How is the APPENDing of 8-bit data best handled? Should it be
stored as raw 8-bit data, and then converted into base64 when FETCHed,
or base64 encoded on the fly when appending?

As the ability to APPEND raw 8-bit data is server dependent, and some servers will refuse raw 8-bit data (or even 8-bit textual data), a prudent client will convert 8-bit data to 7-bit (either as QUOTED-PRINTABLE or BASE64) prior to appending.

Do IMAP clients often APPEND 8-bit data?

IMAP clients should not attempt to append raw 8-bit data to a server which does not advertise the BINARY extension.

Append of 8-bit textual data, in a context that is properly charset tagged, is less likely to cause problems; but it is still within a server's discretion to reject it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
.

Relevant Pages

  • Re: IMAP server implementation details unclear in RFC-3501
    ... connections to the same mailbox, ... Until an untagged EXPUNGE is permitted, ... So untagged EXPUNGE responses are permitted at any time? ... responses followed by an untagged EXISTS response when the server ...
    (comp.mail.imap)
  • Re: Expunging Mailbox Fails (Quota issue)
    ... Reason Given: EXPUNGE failed: Unable to extend mailbox: Disk quota exceeded Does this imply that expunging a mailbox involves making a copy of the mailbox? ... the best thing that you can do is charge the user a quarter (so you can afford to double his disk quota) and then do so. ...
    (comp.mail.imap)
  • Expunging Mailbox Fails (Quota issue)
    ... Reason Given: EXPUNGE failed: Unable to extend mailbox: Disk quota ... Does this imply that expunging a mailbox involves making a copy of the ... With system quotas this is ... What actually happens when a user hits expunge? ...
    (comp.mail.imap)