I believe I was misinterpreting the intent of the PERMANENTFLAGS response. After receiving Larry's replies I now feel this response is largely irrelevant to our wireless client because of its mode of operation (i.e. SnapperMail queries message flags from the server at the start of each session).
I do still feel the server in question is in violation of the RFC however the above point makes this unimportant. Violating both word and spirit of the RFC seems to be the norm rather than the exception with the IMAP servers we've been testing against. Large ISPs rolling their own IMAP interfaces are the worst offenders imho, alas this is exactly the kind of server our mostly consumer user base is likely to connect to! Stuart Nicholson www.snappermail.com ----- Original Message ----- From: "Pete Maclean" <[EMAIL PROTECTED]> To: "Stuart Nicholson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, August 05, 2004 6:51 PM Subject: Re: FLAGS vs PERMANENTFLAGS > Stuart, > > The SELECT response that you quote strikes me as unusual, perhaps even a > bit anomalous, but not unreasonable. The user might, for example, have > permissions that, in principle, give him write access to the mailbox but > have specific prohibitions for storing each message flag. (That's a > fanciful explanation -- I have never come across a server with per-flag > permissions -- but a possible one.) > > By my reading of the RFC, I must agree with you that, if a server stores a > flag in a persistent manner that it has not advertised in a SELECT or > EXAMINE response as a PERMANENTFLAG, then it is in violation. If you can > confirm that the server involved in this particular case is doing that > then, I believe, you should complain strongly. > > I have experience with transitorily connected wireless clients. However, > while that mode of operation is very likely to influence such > considerations as what and how much data is downloaded and in what size > pieces, I cannot see why it should affect the handling of flags in any way > beyond that. And it is not at all clear what you mean by "honouring" > PERMANENTFLAGS. > > Pete Maclean > > At 02:56 PM 8/6/2004, Stuart Nicholson wrote: > Nicely put and I see your point. I'm dealing with a wireless client that > isn't using the normal IMAP 'connected' model. Our sessions typically last > less than 5 minutes which has obviously influenced our design. However I > would expect folders that can't be modified to have the READ-ONLY property > surely? We see things like this (taken from a user log): > > 0003 SELECT "INBOX"[0x0D][0x0A] > * 40 EXISTS > * 0 RECENT > * OK [UIDVALIDITY 1012731894] UID validity status > * OK [UIDNEXT 7880] Predicted next UID > * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) > * OK [PERMANENTFLAGS ()] Permanent flags > * OK [UNSEEN 8] first unseen message in INBOX > 0003 OK [READ-WRITE] SELECT completed > > And the user complains that other clients allow FLAGS to be set and they are > set permanently (over sessions) which seems to violate the RFC, at least as > I understood it. > > I'm beginning to think given our short session times and rigid session model > (i.e. we always sync the message flags at start of session), there's really > little point in us honouring PERMANENTFLAGS at all. > > Thanks, > > Stuart Nicholson > www.snappermail.com
