79 lines
2.8 KiB
Plaintext
79 lines
2.8 KiB
Plaintext
MBOX-Line: From dave at cridland.net Sun Aug 11 00:39:10 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] PERMANENTFLAGS \* and server behavior with
|
|
\ANYFOO flag.
|
|
In-Reply-To: <5206AB36.7080808@laposte.net>
|
|
References: <5206AB36.7080808@laposte.net>
|
|
Message-ID: <CAKHUCzz=-kCLAmzswJeujL-ox+Y_GA+raDXXN9LANkC5ViBLNg@mail.gmail.com>
|
|
|
|
On Sat, Aug 10, 2013 at 10:05 PM, Gilles LAMIRAL <gilles.lamiral@laposte.net
|
|
> wrote:
|
|
|
|
> OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded
|
|
> $MDNSent Forwarded NULL \*)] junk-related flags are not permanent"
|
|
>
|
|
> So Zimbra honors the \* flags meaning any new keyword creation is allowed.
|
|
>
|
|
> But a client command like the following
|
|
>
|
|
> APPEND INBOX (\Seen \ATTACHED) "03-Jul-2013 15:02:40 -0400" {51806}':
|
|
>
|
|
> generates an error from Zimbra
|
|
>
|
|
> BAD parse error: invalid flag: \ATTACHED
|
|
>
|
|
> I understand \ATTACHED is not a keyword, it is a \flag,
|
|
>
|
|
|
|
No, it's not. Page 86 shows that flags beginning "\" are enumerated, for
|
|
example. Elsewhere (?2.3.2) it discussed that these are system flags, and
|
|
defined within RFC 3501.
|
|
|
|
And will is shall, shall is must in RFC vocabulary:
|
|
> http://www.ietf.org/rfc/rfc2119.txt
|
|
>
|
|
>
|
|
Will is not SHALL, will is a statement of fact...
|
|
|
|
|
|
> What do other imap servers do?
|
|
> Are there servers accepting \ANYFOO flag?
|
|
> >From a migration point of view (imapsync), does the migrate tool have to
|
|
> filter flags like \FOO
|
|
> or should it try to sync it?
|
|
>
|
|
>
|
|
It should ignore it and not pass it through, or else drop the leading "\".
|
|
|
|
IMAP RFC http://tools.ietf.org/html/rfc3501 full quote of PERMANENTFLAGS
|
|
>
|
|
> PERMANENTFLAGS
|
|
>
|
|
> Followed by a parenthesized list of flags, indicates which of
|
|
> the known flags the client can change permanently. Any flags
|
|
> that are in the FLAGS untagged response, but not the
|
|
> PERMANENTFLAGS list, can not be set permanently. If the client
|
|
> attempts to STORE a flag that is not in the PERMANENTFLAGS
|
|
> list, the server will either ignore the change or store the
|
|
> state change for the remainder of the current session only.
|
|
> The PERMANENTFLAGS list can also include the special flag \*,
|
|
> which indicates that it is possible to create new keywords by
|
|
> attempting to store those flags in the mailbox.
|
|
>
|
|
|
|
Right, and here it says "keywords".
|
|
|
|
From ?2.3.2, para 3:
|
|
|
|
A keyword is defined by the server implementation. Keywords do not
|
|
begin with "\". Servers MAY permit the client to define new keywords
|
|
in the mailbox (see the description of the PERMANENTFLAGS response
|
|
code for more information).
|
|
|
|
Dave.
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130811/8d554dd7/attachment.html>
|