65 lines
2.5 KiB
Plaintext
65 lines
2.5 KiB
Plaintext
MBOX-Line: From gilles.lamiral at laposte.net Sat Aug 10 14:05:58 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] PERMANENTFLAGS \* and server behavior with \ANYFOO
|
|
flag.
|
|
Message-ID: <5206AB36.7080808@laposte.net>
|
|
|
|
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
|
|
|