characters allowed in mailbox names
Nancy McGough
I describe here
<http://www.ii.com/internet/robots/procmail/qs/#style>
I'd like to name my incoming mailboxes so that they are listed
near the top of my mailbox list. I've been staring at this ascii
chart
32 sp 33 ! 34 " 35 # 36 $ 37 % 38 & 39 '
40 ( 41 ) 42 * 43 + 44 , 45 - 46 . 47 /
48 0 49 1 50 2 51 3 52 4 53 5 54 6 55 7
56 8 57 9 58 : 59 ; 60 < 61 = 62 > 63 ?
64 @ 65 A 66 B 67 C 68 D 69 E 70 F 71 G
72 H 73 I 74 J 75 K 76 L 77 M 78 N 79 O
80 P 81 Q 82 R 83 S 84 T 85 U 86 V 87 W
88 X 89 Y 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _
96 ` 97 a 98 b 99 c 100 d 101 e 102 f 103 g
104 h 105 i 106 j 107 k 108 l 109 m 110 n 111 o
112 p 113 q 114 r 115 s 116 t 117 u 118 v 119 w
120 x 121 y 122 z 123 { 124 | 125 } 126 ~ 127 del
and experimenting with different IMAP servers and it seems that starting
mailbox names with any of these
:in-
,in-
=in-
works on Cyrus, UW, Courier, and Exchange IMAP servers. A long
time ago Sam suggested not using : in a mailbox name, but I think
that is the one that I prefer. Can anyone point me to a list of
characters that will work in mailbox names on all IMAP servers?
Also, details about restrictions on characters in certain
positions - for example, my guess is that # should not be used as
the first character, but is it ok within the rest of the name?
I'd appreciate any thoughts about this, including how other
people organize and name their mailboxes. I know that I can use
subdirectories but I prefer having all my mailboxes in one
directory.
Thanks,
Nancy
--
Nancy McGough
Infinite Ink
<http://www.ii.com/>
DINH Viet Hoa
> the first character, but is it ok within the rest of the name?
Why '#' may not work for the mailbox name ?
> I'd appreciate any thoughts about this, including how other
> people organize and name their mailboxes.
I think I would use upper cases and lower cases.
--
DINH V. Hoa,
libEtPan! - a mail library - http://libetpan.sourceforge.net
"sunZ ! capitaine de soirées"
Neil Hoggarth
DINH Viet Hoa <dinh-coeur.viet-fle...@free-sourire2.fr> wrote:
> Why '#' may not work for the mailbox name ?
It is reserved for specifying a namespace for the folder, such as
"#news" or "#shared".
Regards,
--
Neil Hoggarth Departmental Computer Officer
<neil.h...@physiol.ox.ac.uk> Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK
Pete Maclean
name starting with a space. Can't say that this will work well with all
IMAP servers though.
I don't think it's possible to give a list of characters that are acceptable
in mailbox names generally. The main reason is that the set of acceptable
characters for any given server has little to do with IMAP per se and mostly
to do with the underlying message store -- and message stores vary widely in
this respect.
Pete Maclean
Mark Crispin
> I don't think it's possible to give a list of characters that are acceptable
> in mailbox names generally. The main reason is that the set of acceptable
> characters for any given server has little to do with IMAP per se and mostly
> to do with the underlying message store -- and message stores vary widely in
> this respect.
I agree with this assessment. It's impossible to know what characters may
be special in the underlying message store or even the filesystem. Just
off the top of my head, here is a list of characters that I know are
special in some filesystems:
% * [ ] ; : , . < > / ? \
I know that I have missed some. And, of course, IMAP has special meanings
for
# % * &
Historically, people forced a top-of-sort by prefixing digits to the
forced names. For example, instead of a "README" file they would have a
0README or 00README. A variation of that was hyphens: -README-
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
c.c....@67.usenet.us.com
top-level entries in the collection list. One lists only the incoming
folders, while the other lists all folders including the incoming
folders.
Incoming-Folders
Incoming Message Folders
Mail
Folders on imap.rahul.net in Mail/
The .pinerc lines that make this happen look similar to:
inbox-path=
incoming-folders=aaa {imap.rahul.net}Mail/aaa,
bbb {imap.rahul.net}Mail/bbb,
ccc {imap.rahul.net}Mail/ccc
folder-collections=Mail {imap.rahul.net}Mail/[]
The empty inbox-path line causes the standard INBOX to appear within
the incoming-folders list.
--
Rahul
Nancy McGough
>
> I agree with this assessment. It's impossible to know what characters may
> be special in the underlying message store or even the filesystem. Just
> off the top of my head, here is a list of characters that I know are
> special in some filesystems:
> % * [ ] ; : , . < > / ? \
>
> I know that I have missed some. And, of course, IMAP has special meanings
> for
> # % * &
>
> Historically, people forced a top-of-sort by prefixing digits to the
> forced names. For example, instead of a "README" file they would have a
> 0README or 00README. A variation of that was hyphens: -README-
Thank you all for your input on this, especially Mark's message
above. I've pretty much decided that I'm now going to prefix all
my incoming mailbox names with a dash (-). For example, incoming
pine-info and procmail mailing-list messages are now put into
these mailboxes (*)
-s-pine-info
-s-procmail
These sort very nicely at the top of my mailbox list and so far
they haven't caused any problems with Cyrus, UW, Courier, or
Exchange IMAP Servers. Procmail likes them. Mulberry and Pine
like them. And they even work with FastMail.FM's plus addresses,
i.e., I can send a message to uid+-s-...@fastmail.fm and it
is delivered to the -s-procmail mailbox.
Can anyone think of any problem that these mailbox names might
cause? They don't work with FM subdomain-addressing, e.g., I can
*not* send a message to -s-pro...@uid.fastmail.fm but I can get
around that with the "plus" address variation. I'm planning to
implement this for other people than just me so it's important
that this will work on many platforms, IMAP servers, and IMAP
clients.
Another Question: What do you suggest for a bottom-of-sort
prefix? None of { | } or ~ work on all the systems I tried so it
seems like I'm stuck with using something like zz as a prefix.
Does anyone have a better idea or thoughts about this?
Thanks again,
Nancy
(*) the s in -s-mailinglist stands for "subscription" or
"solicited bulk email"
--
PROCMAIL <http://www.ii.com/internet/robots/procmail/qs/>
IMAP <http://www.ii.com/internet/messaging/imap/isps/>
PINE <http://www.ii.com/internet/messaging/pine/>
-- I N F I N I T E I N K www.ii.com N A N C Y M c G O U G H --
Sam
Hash: SHA1
In article <Pine.LNX.4.49.99.0209...@zebes.dreamhost.com>,
Nancy McGough <nm-this-addr...@no.sp.am> writes:
> Another Question: What do you suggest for a bottom-of-sort
> prefix? None of { | } or ~ work on all the systems I tried so it
> seems like I'm stuck with using something like zz as a prefix.
> Does anyone have a better idea or thoughts about this?
You're pretty much at the tail end of us-ascii, over there. The last
character you can reasonably expect most imap clients to take, for a folder
name, would be ~, 0x7E. 0x7F is ASCII DEL, and high-8 characters are
supposed to be encoded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE9kPYt3ejdWUS0ltARAjtHAJ4k2Uhro1oqSVBl8gKvLgcsfL1P1wCgl6cd
NnhBmAOm7OqaIKumOriGBIA=
=CHR1
-----END PGP SIGNATURE-----
Eric A. Hall
on 9/24/2002 8:06 AM Nancy McGough wrote:
> Another Question: What do you suggest for a bottom-of-sort
> prefix? None of { | } or ~ work on all the systems I tried so it
> seems like I'm stuck with using something like zz as a prefix.
> Does anyone have a better idea or thoughts about this?
"{" is not part of the IMAP atom so it is going to be prohibited in most
cases. "}" is also going to be prohibited as a matter of caution on many
systems as well. "|" should work but I can see lots of problems with it in
user+folder addressing and why systems would refuse it.
You will almost certainly run into problems with "~" on IMAP servers which
use that character to address a foreign namespace. About the only option
here is to see if you can create and subscribe to the folders using manual
commands via TELNET, and using your full hierarchy in the naming (eg,
"create ~nancy/~foldername"). Note that I just tried this on a couple of
servers that use tilde and it didn't work, but it worked fine on servers
that don't use that character for their namespaces. Even if you could get
it to work though, you will almost certainly run into problems if you ever
try to move these folders to another server.
Looks like you are stuck with "zz-" if you want portability.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Mark Crispin
> "{" is not part of the IMAP atom so it is going to be prohibited in most
> cases. "}" is also going to be prohibited as a matter of caution on many
> systems as well. "|" should work but I can see lots of problems with it in
> user+folder addressing and why systems would refuse it.
> You will almost certainly run into problems with "~" on IMAP servers which
> use that character to address a foreign namespace.
All of the above characters are permitted in mailbox names in the IMAP
protocol. In fact, the only prohibited ASCII character is NUL (0x00).
8-bit characters are reserved for future assignment as UTF-8 names; this
prohibition is to exterminate pre-1996 legacy use as ISO-8859-1, S-JIS,
and EUC-JP names.
Additionally, the "&" character is defined by convention in RFC 2060 for
Unicode names. What's important here is that your client knows about this
convention (most do) if you intend to create a name with this character.
However, servers are allowed to add restrictions to mailbox name
characters above and beyond the above. Many servers prohibit CR and LF.
Some servers prohibit non-graphic characters (less than 0x20 or 0x7f).
Some servers prohibit or restrict potential filesystem navigation strings
(e.g. "/../") or shell escape specials (e.g. "|") that might allow access
to prohibited directories.
This last would be the only reason to restrict "{", "|", "}", or "~". Of
these, only "{" has a special syntax meaning in IMAP, but that is not a
major problem. Lots of people use space in mailbox names, and that has
the same handicap as "{".
Sam
Hash: SHA1
In article <Pine.LNX.4.50.02092...@shiva0.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> writes:
> All of the above characters are permitted in mailbox names in the IMAP
> protocol. In fact, the only prohibited ASCII character is NUL (0x00).
> 8-bit characters are reserved for future assignment as UTF-8 names; this
> prohibition is to exterminate pre-1996 legacy use as ISO-8859-1, S-JIS,
> and EUC-JP names.
Hmmm... Personally, I wouldn't bet my money on iso-2022-jp and shift-JIS
usage (including searching and collating) disappearing any time soon...
Just a hunch, just a hunch...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE9kSuf3ejdWUS0ltARAuY1AJ9ElYESyI7ANlw2Q4mx5bD7Y2mM5ACfdOEN
bN5GB+I6h3x+EyrEwEwVAXA=
=Y7/E
-----END PGP SIGNATURE-----
Mark Crispin
> > All of the above characters are permitted in mailbox names in the IMAP
> > protocol. In fact, the only prohibited ASCII character is NUL (0x00).
> > 8-bit characters are reserved for future assignment as UTF-8 names; this
> > prohibition is to exterminate pre-1996 legacy use as ISO-8859-1, S-JIS,
> > and EUC-JP names.
> Hmmm... Personally, I wouldn't bet my money on iso-2022-jp and shift-JIS
> usage (including searching and collating) disappearing any time soon...
How do ISO-2022-JP and SHIFT-JIS searching and collating have anything to
do with mailbox names?
The 8-bit restriction noted above applies *only* to mailbox names and
*not* to any other IMAP strings. 8-bit strings can be transmitted in IMAP
via literals, and are permitted in those IMAP strings which have
identified charsets (generally, message body data).
What IMAP server has ISO-2022-JP mailbox names? What operating system has
ISO-2022-JP file names? I speak, read, and write Japanese; and I work
with Japanese operating systems and Japanese IMAP products. If there is
one that uses ISO-2022-JP file/mailbox names, I have contrived to miss it.
I know of numerous Japanese operating systems which use EUC-JP or
SHIFT-JIS for filenames; and I know of Japanese IMAP products that used
EUC-JP but have since switched to Unicode.
If there is an IMAP server that uses ISO-2022-JP for mailbox names, does
it adhere strictly to RFC 1468 (original JUNET, and the only one generally
accepted), one of the proposed successors (of which RFC 1554 was the first
of many), or does it use one of the many unapproved ways in which people
misuse it (such as hankaku katakana or JIS X 0212)?
Or are you confused with the CHARSET option to SEARCH and the charset
argument in SORT and THREAD, all of which have active (and approved) use
of ISO-2022-JP, EUC-JP, SHIFT-JIS, and numerous other valid charsets?
Oh yeah, I almost forgot to mention. The prohibition of 8-bit strings in
mailbox names in no way precludes ISO-2022-JP mailbox names. ISO-2022-JP
is completely 7-bit. Do not confuse ISO-2022-JP with ISO 2022, or with
EUC-JP, or with Shift-JIS.
If you don't want to read the RFCs, get Ken Lunde's book.
LC's No-Spam Newsreading account
> I'd appreciate any thoughts about this, including how other
> people organize and name their mailboxes. I know that I can use
> subdirectories but I prefer having all my mailboxes in one
> directory.
I do use subdirectories and folder collections. This is mainly
historical. Each folder collection has a name and points to a
subdirectory. The unix subdirectory name is different from the
collection name. All subdirectories have "hidden" dot-names.
I use pine folder-sort-rule alpha-with-dirs-last.
My folder list appears as :
INBOX saved-messages AAA.SAVED-TO-CD-AUG00A
SEMINARI Suspect SuspectSpam
postponed-msgs sent-mail .AA.Quarantine/
.Default/ .Faq/ .HW-SW/
.Milano/ .Old-1999/ .Old-2000/
.Old-2001/ .Rete/ .Sax/
.SaxAO1/ .SaxAO2/ .SaxAO3/
.SaxAO4/ .SaxAO5/ .Space/
.Suv/ .Xmm/
As you can see the first three lines list plain folders (except
.AA.Quarantine which is a plain subdirectory.
All remaining lines list dot-folders which correspond to folder
collections (in alphabetic order, while the list of folder collections
below on my screen lists collections shuffled in order of priority.
Items in the first three lines are either :
- my inbox
- pine "service" folders with standard names
- a file AAA.SAVED-TO-CD-AUG00A which is not a folder, just some
note (must start with AAA) I put to record when I last backed up
things to CD (I'd really like that pine won't list normal files
which are not folders or directories)
- the only folders which are not in a subdirectory are those filled
in by my quite extensive procmail filtering (the list may vary,
during vacations I have more folders storing some mailing lists)
- the .AA.Quarantine is also used by my procmail filters to store
(one folder per sender) mails awaiting an authentication. It is
not a folder collection, and I never look at it (if authenticated,
will go to inbox, if not disappears after 7 days).
To make it appear before the other folders I've used .AA
For the rest I've lived with normal upper case / lower case, and dot vs
no-dot naming to achieve an acceptable order. No funny characters.
What I'd like would be a way to list folders and directories always with
directories started on a new line. I tried for this creating an empty
file with names like ----- to be used as a separator, but I cannot be
sure that the number of folders above the separator is a multiple of
three, so I abandoned the idea.
Also note that all my collections are local on my unix box, and I have
only one incoming folder. Only occasionally (when I'm away and use a
laptop) I access remotely all the above, and add a "local" folder
collection on the laptop.
--
----------------------------------------------------------------------
nos...@ifctr.mi.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.