Hello,
I would like a precision on the behavior to follow with PERMANENTFLAGS with \* and flags like \FOO
For example, Zimbra imap server can have this PERMANENTFLAGS list:
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,
but rising an error here seems not correct since the RFC says:
"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."
So the RFC asks "the server will either ignore or store for current session only."
Ignoring is not raising an error like "BAD ...", as does Zimbra.
And will is shall, shall is must in RFC vocabulary: http://www.ietf.org/rfc/rfc2119.txt
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?
Thanks in advance.
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.
--
Au revoir, 09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
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>
On Sun, Aug 11, 2013 at 08:39:10AM +0100, Dave Cridland wrote:
> Will is not SHALL, will is a statement of fact...
2119 doesn't say that its definitions apply only in upper case.
Arnt
On Sun, Aug 11, 2013 at 9:33 AM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no>wrote:
> On Sun, Aug 11, 2013 at 08:39:10AM +0100, Dave Cridland wrote:
> > Will is not SHALL, will is a statement of fact...
>
> 2119 doesn't say that its definitions apply only in upper case.
>
No, but "WILL" isn't listed either...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130811/58fbf1cb/attachment.html>
On Sun, Aug 11, 2013 at 11:27:47AM +0100, Dave Cridland wrote:
> No, but "WILL" isn't listed either...
You have a point ;)
Gilles, anyway: \* means that you can store new flags, but now
\attachments. \ is not a permitted character in the flag names YOU can
store. RFCs can make up new names containing \, you can not.
Arnt
Hi,
> Gilles, anyway: \* means that you can store new flags, but now
> \attachments. \ is not a permitted character in the flag names YOU can
> store. RFCs can make up new names containing \, you can not.
Ok. I understand now.
I guessed wrong because of the syntax \*, it is a terribly bad symbol.
It really means "anything else than what I look like".
A single * or a double ** (or anything else without a \) would have been less tortuous.
I MUST read the RFCs very carefully, with no background in mind, and I MUST retain
what I read despite the syntax. All of this in a foreign language. I'm welcome.
Thanks for your clarifications. I guess it is not the last time I ask for them.
--
Au revoir, 09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06