On Aug 17, 2004, at 08:28, Mark Crispin wrote:
There is no conformance test suite for IMAP. Such a program would be
a great deal of work, and a thankless task at that.
Oh, well... I guess I will stick to my current methodology then:
... dont read specs until someone yells...
On Wed, 18 Aug 2004, petite_abeille wrote:
Oh, well... I guess I will stick to my current methodology then:
... dont read specs until someone yells...
Not a good idea. The IMAP protocol is very rigid, and does not permit
deviation. Failure to read the IMAP specification closely prior to
On Aug 18, 2004, at 18:56, Mark Crispin wrote:
Not a good idea. The IMAP protocol is very rigid, and does not permit
deviation. Failure to read the IMAP specification closely prior to
implementation will result in you having to rewrite your entire
application to fix the massive bugs that will
Hello,
What is the recommended way for dealing with shared mailbox regarding
permanent flags?
Specifically, I have a public mailbox accessible to anyone, however
only the owner of the mailbox can store flags permanently.
Anonymous clients can access such a mailbox properly, but because they
On 18.8.2004, at 23:02, petite_abeille wrote:
Is it possible to signal to the client to keep track of the message's
flags?
Returning empty PERMANENTFLAGS list is your best bet. Although probably
no clients actually do it.
PGP.sig
Description: This is a digitally signed message part
Hi Timo,
On Aug 18, 2004, at 22:37, Timo Sirainen wrote:
FLAGS list shouldn't be empty. It should contain at least the system
flags.
Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged
\Recent and \Seen? Even if they are not applicable for such mailbox?
But this doesn't seem
Actually if you set FLAGS to non empty and PERMANENTFLAGS to empty, all
the clients should work. You need to maintain flags in-memory even if
you can't persist them (it's in the spec), but most (if not all) clients
handle the non persistence correctly (if you think about it, they won't
know the
You MUST support ALL the built-in flags on every mailbox. You might not
be able to persist those flag settings, but you MUST support them on a
per-session basis.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of petite_abeille
Sent: Wednesday, August 18,
On Wed, 18 Aug 2004, petite_abeille wrote:
Ok. So FLAGS should always returns \Answered \Deleted \Draft \Flagged \Recent
and \Seen? Even if they are not applicable for such mailbox?
Yes, and those flags are *always* applicable (even if they are
session-only) by definition.
Consider the effect
On Aug 18, 2004, at 23:09, Larry Osterman wrote:
You MUST support ALL the built-in flags on every mailbox. You might
not
be able to persist those flag settings, but you MUST support them on a
per-session basis.
Ok. I'm keeping track of them on a session basis. Thanks for the
clarification.
PA.
On 19.8.2004, at 00:08, Larry Osterman wrote:
Actually if you set FLAGS to non empty and PERMANENTFLAGS to empty, all
the clients should work. You need to maintain flags in-memory even if
you can't persist them (it's in the spec), but most (if not all)
clients
handle the non persistence
I think that either what you say is not quite correct or I am not
understanding it right. RFC 3501 gives an example of a FLAGS response that
does not include all the system/built-in flags:
Example:S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
In this case, \Recent is missing. As I
--On 2004-8-19 12:37 AM +0300 Timo Sirainen [EMAIL PROTECTED] wrote:
Having clients store flag changes permanently in client side would be
useful for publically accessible IMAP mailboxes. I think clients
should do that for flags not included in PERMANENTFLAGS list, but
they don't.
I'm not
Argh! I have always had a serious misunderstanding about this then. It
seemed to me that the very fact that there is a response explicitly listing
FLAGS applicable to the mailbox meant that a server was not required to
support all of them. Well, I stand corrected. Thank you for the
Still struggling with anonymous access... :)
During an anonymous connection, the Inbox is typically not accessible,
nor visible (e.g. it doesn't show up in LIST nor is it available for
SELECT or EXAMINE)...
Some clients seem to chock on this... so... what is the proper way of
handling an, er,
15 matches
Mail list logo
