Tom Williams <[EMAIL PROTECTED]> wrote:
> Having the ampersand in the name made it IMPOSSIBLE to delete folders
> using
> the previous e-mail client. So, I've removed all of the ampersands from
> the folder names, so I don't have any to test with SquirrelMail. Just
> like with the trailing space in the folder name problem I had, I could
> NOT unsubscribe nor delete the folder with the ampersand in it and I had
> to
> "fix" this manually by escaping the ampersand when manipulating this
> folder
> via shell access to the server.
Excerpt from rfc3501, section 1.2 Conventions Used in This Document:
"There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations
need to be aware of these conventions, and avoid conflicts whether or
not they implement the convention. For example, "&" may not be used
as a hierarchy delimiter since it conflicts with the Mailbox
International Naming Convention, and other uses of "&" in mailbox
names are impacted as well."
In fact, in section 5.1. Mailbox Naming, there is:
"5) Two characters, "#" and "&", have meanings by convention, and
should be avoided except when used in that convention."
which refers to section 5.1.3. Mailbox International Naming Convention:
"Although modified UTF-7 is a convention, it establishes certain
requirements on server handling of any mailbox name with an
embedded "&" character. In particular, server implementations
MUST preserve the exact form of the modified BASE64 portion of a
modified UTF-7 name and treat that text as case-sensitive, even if
names are otherwise case-insensitive or case-folded.
Server implementations SHOULD verify that any mailbox name with an
embedded "&" character, used as an argument to CREATE, is: in the
correctly modified UTF-7 syntax, has no superfluous shifts, and
has no encoding in modified BASE64 of any printing US-ASCII
character which can represent itself. However, client
implementations MUST NOT depend upon the server doing this, and
SHOULD NOT attempt to create a mailbox name with an embedded "&"
character unless it complies with the modified UTF-7 syntax.
Server implementations which export a mail store that does not
follow the modified UTF-7 convention MUST convert to modified UTF-7 any
mailbox name that contains either non-ASCII characters or the "&"
character."
So, I would summarize this by:
Although it is possible to use an "&" in mailbox names by using the proper
encoding, client software SHOULD NOT allow creation of such mailbox names
since it can mess up the server or other client softwares.
> Does SquirrelMail account for these potentially problematic characters in
> folder names by escaping, etc., or does it just pass the names through
> un-touched for the underlying IMAP server to deal with?
SquirrelMail forbids the use of the server delimiter, which it MUST. It
forbids " (DQUOTE) and "\" (backslash) too, though they are perfectly
valid in mailbox names since servers and clients MUST use literal string
whenever necessary. Instead, or in addition to, it SHOULD forbid "&" and
"#" IMHO, since they may cause major problems, like the one that is being
reported here.
Like I wrote previously, 1.5 devel branch has been fixed to handle literal
strings for mailbox names. I'm still waiting for reports...
Alex.
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
