Is specifyng the root folder of an imap account an advantage or not?

[Jim S]

--
Jim S

 

[VanguardLH]

<yep, Jim posted a blank body with no details or context>

Usually not but it depends on the IMAP server. Since you gave no
details, like whose IMAP server you [plan to] connect, I can't tell you
whether you specify the [root] node or not in the IMAP hierarchy.

I'll give a hint: it does matter if you use IMAP with Google mail.

 

[Jim S]

Jim S wrote:
Usually not but it depends on the IMAP server. Since you gave no
details, like whose IMAP server you [plan to] connect, I can't tell you
whether you specify the [root] node or not in the IMAP hierarchy.

I'll give a hint: it does matter if you use IMAP with Google mail.

Sorry I tried to unsend the mail, but since you answered, it would be
rude of me not to reply.
I am on a Gmail based server.
I know how to do it, I just wondered why I should.

 

[VanguardLH]

I am on a Gmail based server.
I know how to do it, I just wondered why I should.

POP has no concept of folders, only of a mailbox. That is why there are
no commands in POP to select or navigate to folders. IMAP lets you have
folders under a "root" (the home path for your account). The client
issues a LIST command as:

LIST "" "*"

It doesn't specify a reference (path/folder) so it's asking about
entries under the current path (the default one when it first connects)
and wants back from the server a list of all names (folders) under that
path. This is how the client finds out what folders are available when
it first connects and what is under each folder and walks down the tree
structure. The client then issues a SELECT command to navigate to one
of those folders. So, on initial connect, your client sends:

LIST "" "*"

and server returns

inbox
sent
drafts
trash
(and other folders at the current path)

Because no SELECT can be issued before the client knows what are the
folders when it initially connects to the server, there are some
assumptions. If no root path is specified, the client assumes when it
connects that the server starts at the root ("\" for your account but
which would equate to something like ~username\mail on the server). If
a root is specified then the client is telling the server an offset into
the pathing it should start. For example, if the server defaulted to
"\" for root (under your account for whatever is its path in their file
system) then the above folders would be at:

\inbox (or ~username\mail\inbox)
\sent (or ~username\mail\sent)
\drafts (or ~username\mail\drafts)
\trash (or ~username\mail\trash)

You could, for example, specify a root of [inbox] which means you said
to root your pathing to:

\inbox (or ~username\mail\inbox)

That is, you are rooting your path navigation to start at that folder.
You won't see the above sent, drafts, and trash folders because you are
starting under the inbox path. Any folders you create in your client
would go under the specified root folder (inbox). Not seeing the sent
and other standard folders might you erroneous assume they are missing
so when you create them they would be at:

\inbox (root)
\sent (new folder)
\drafts (new folder)
\trash (new folder)
\sent *
\drafts *
\trash *

* You won't see these folders because you rooted your pathing to inbox
and will only see folders under there.

Say an ISP gives you IMAP access to your account. They even give you
multiple e-mail addresses you can create with them under that one
account. This is a "family account" where multiple users are using the
same customer account but each looks to have an independent e-mail
account. Say you use their web interface to create 3 e-mail addresses
with them for Mom, Dad, and Kid. They could set it up as:

~youraccount\mail\Mom\inbox
\sent
\drafts
\trash
\Dad\inbox
\sent
\drafts
\trash
\Kid\inbox
\sent
\drafts
\trash

They probably would root your pathing based on your login, and you login
with different credentials for each account. So when Mom logs in, she
gets rooted to ~youraccount\mail\Mom and similarly for Dad and Kid. If
it were allowed, one of them could specify a root of "[mail]" which
means they would see Mom, Dad, and Kid at the 1st level in their folder
tree and could see all the subfolders for all the family accounts.

Think of "root" as to where you root the relative pathing. Mailboxes
are handled in IMAP like they are folders. Mailboxes can contain files
or other mailboxes (subfolders). A mailbox is accessed using its
complete hiearchical name; however, rooting eliminates having to specify
anything in the absolute path before the root point. You can see a
similar example if you use rooted pathing in Windows Explorer. Run the
following command:

explorer.exe /root,C:\Windows

A window opens for Windows Explorer which shows you a tree list of
folders that start at C:\Windows. You cannot navigate lower than that
rooted path. You're ROOTED to that point in the tree hierarchy of
folders. Windows Explorer will show that folder at the same level as
your drives. When rooted, there is nothing before that point. It's
where you start. While Windows Explorer shows you roots for other
objects, clicking on any of them will open a new instance of
explorer.exe because you're supposed to be rooted at the folder you
specified.

I'm more expert with POP (which is simpler) than IMAP. The above is how
IMAP looks (to me) to operate with the root you specify in your client
specifying where to root its relative pathing when sending SELECT
commands to the server after first connecting to it. Google has their
own way of doing things. They first came out with webmail probably
because they thought webmail was the future and users would abandon
local clients. Then they hacked it to support POP and IMAP but they
stuck with using flags to create pseudo-mailboxes (aka folders).
Because they were still webmail-centric minded, they had server-side
settings for account behavior that would rightly be issued using
commands from the client to a proper POP or IMAP server. In fact, they
ignore some commands from clients because the server-side settings are
supposed to get used instead. That is why I refer to Google's
implementation of POP and IMAP as gPOP and gIMAP. It's their flavor of
those e-mail protocols.

With Gmail, it appears that only the Inbox folder is at the root path
for your account. All others are under a Gmail subpath, something like:

~youraccount\Inbox
\Gmail\Sent
\Gmail\Drafts
\Gmail\Trash

so your e-mail without specifying a root looks like:

inbox
[gmail]\sent
[gmail]\drafts
[gmail]\trash
[gmail]\addedfolder1
[gmail]\addedfolder2

By rooting the relative pathing to [Gmail], you don't change the
structure on the server but you mask it out. The folders under the
Gmail folder look like they are at the same level as the Inbox folder.
Peculiarly the Inbox folder must be specially handled since shows as
unrooted when you leave blank the root path (in your client). Like I
said, Google has their own implementation of POP and IMAP. I wouldn't
go by what Google does with their IMAP (aka gIMAP) to know how standard
IMAP is supposed to work.

You can RFC 3501 (http://www.rfc-editor.org/rfc/rfc3501.txt) on how IMAP
is supposed to work regarding the LIST and SELECT commands. Google
seems to somewhat follow the RFC for the non-Inbox folders by having you
root the pathing to a Gmail directory under your account but they
apparently do something odd, er, special for the Inbox folder.

While we call them folders, the RFCs refer to them as mailboxes. POP
only knows about a single mailbox and why it can only retrieve items
listed in the Inbox folder shown by the webmail client to your account.
IMAP can handle multiple mailboxes (aka folders). It looks like an IMAP
account must have a minimum of one mailbox and that's called the Inbox
mailbox. All the others (Sent, Drafts, Trash, Junk or Spam) are
optional. So Google must figure that you should always see the Inbox
mailbox without requiring to specify where to root the pathing to access
the mailbox(es) under your account. I can't be sure that isn't how all
IMAP servers handle showing you the minimum Inbox mailbox since lots of
implementation details can be masked to the client.

The above are my noob observations from glancing over RFCs and noting
behavior. I haven't been using IMAP long enough to warrant my thorough
investigation on how IMAP should work versus how it get implemented.
There are probably newsgroups or forums where you can get gurus that
have written IMAP server programs to know just how LIST, SELECT, and
rooting work; however, I'm not sure anyone outside Google's Gmail group
knows how IMAP works under the covers for Gmail.

Rooting says what is the starting point for finding folders (mailboxes)
in your account. Hopefully the server restricts you from walking too
far up the path to end up seeing all accounts under a family account or
going back even further to see the account folders for other customers.
So there is an assumption that the root you get will be whatever is the
root path in your account. Specifying a root means you are actually
walking down further in the tree of folders (mailboxes) under your
account.

 

[Jim S]

I am on a Gmail based server.
I know how to do it, I just wondered why I should.

POP has no concept of folders, only of a mailbox. That is why there are
no commands in POP to select or navigate to folders. IMAP lets you have
folders under a "root" (the home path for your account). The client
issues a LIST command as:

LIST "" "*"

It doesn't specify a reference (path/folder) so it's asking about
entries under the current path (the default one when it first connects)
and wants back from the server a list of all names (folders) under that
path. This is how the client finds out what folders are available when
it first connects and what is under each folder and walks down the tree
structure. The client then issues a SELECT command to navigate to one
of those folders. So, on initial connect, your client sends:

LIST "" "*"

and server returns

inbox
sent
drafts
trash
(and other folders at the current path)

Because no SELECT can be issued before the client knows what are the
folders when it initially connects to the server, there are some
assumptions. If no root path is specified, the client assumes when it
connects that the server starts at the root ("\" for your account but
which would equate to something like ~username\mail on the server). If
a root is specified then the client is telling the server an offset into
the pathing it should start. For example, if the server defaulted to
"\" for root (under your account for whatever is its path in their file
system) then the above folders would be at:

\inbox (or ~username\mail\inbox)
\sent (or ~username\mail\sent)
\drafts (or ~username\mail\drafts)
\trash (or ~username\mail\trash)

You could, for example, specify a root of [inbox] which means you said
to root your pathing to:

\inbox (or ~username\mail\inbox)

That is, you are rooting your path navigation to start at that folder.
You won't see the above sent, drafts, and trash folders because you are
starting under the inbox path. Any folders you create in your client
would go under the specified root folder (inbox). Not seeing the sent
and other standard folders might you erroneous assume they are missing
so when you create them they would be at:

\inbox (root)
\sent (new folder)
\drafts (new folder)
\trash (new folder)
\sent *
\drafts *
\trash *

* You won't see these folders because you rooted your pathing to inbox
and will only see folders under there.

Say an ISP gives you IMAP access to your account. They even give you
multiple e-mail addresses you can create with them under that one
account. This is a "family account" where multiple users are using the
same customer account but each looks to have an independent e-mail
account. Say you use their web interface to create 3 e-mail addresses
with them for Mom, Dad, and Kid. They could set it up as:

~youraccount\mail\Mom\inbox
\sent
\drafts
\trash
\Dad\inbox
\sent
\drafts
\trash
\Kid\inbox
\sent
\drafts
\trash

They probably would root your pathing based on your login, and you login
with different credentials for each account. So when Mom logs in, she
gets rooted to ~youraccount\mail\Mom and similarly for Dad and Kid. If
it were allowed, one of them could specify a root of "[mail]" which
means they would see Mom, Dad, and Kid at the 1st level in their folder
tree and could see all the subfolders for all the family accounts.

Think of "root" as to where you root the relative pathing. Mailboxes
are handled in IMAP like they are folders. Mailboxes can contain files
or other mailboxes (subfolders). A mailbox is accessed using its
complete hiearchical name; however, rooting eliminates having to specify
anything in the absolute path before the root point. You can see a
similar example if you use rooted pathing in Windows Explorer. Run the
following command:

explorer.exe /root,C:\Windows

A window opens for Windows Explorer which shows you a tree list of
folders that start at C:\Windows. You cannot navigate lower than that
rooted path. You're ROOTED to that point in the tree hierarchy of
folders. Windows Explorer will show that folder at the same level as
your drives. When rooted, there is nothing before that point. It's
where you start. While Windows Explorer shows you roots for other
objects, clicking on any of them will open a new instance of
explorer.exe because you're supposed to be rooted at the folder you
specified.

I'm more expert with POP (which is simpler) than IMAP. The above is how
IMAP looks (to me) to operate with the root you specify in your client
specifying where to root its relative pathing when sending SELECT
commands to the server after first connecting to it. Google has their
own way of doing things. They first came out with webmail probably
because they thought webmail was the future and users would abandon
local clients. Then they hacked it to support POP and IMAP but they
stuck with using flags to create pseudo-mailboxes (aka folders).
Because they were still webmail-centric minded, they had server-side
settings for account behavior that would rightly be issued using
commands from the client to a proper POP or IMAP server. In fact, they
ignore some commands from clients because the server-side settings are
supposed to get used instead. That is why I refer to Google's
implementation of POP and IMAP as gPOP and gIMAP. It's their flavor of
those e-mail protocols.

With Gmail, it appears that only the Inbox folder is at the root path
for your account. All others are under a Gmail subpath, something like:

~youraccount\Inbox
\Gmail\Sent
\Gmail\Drafts
\Gmail\Trash

so your e-mail without specifying a root looks like:

inbox
[gmail]\sent
[gmail]\drafts
[gmail]\trash
[gmail]\addedfolder1
[gmail]\addedfolder2

By rooting the relative pathing to [Gmail], you don't change the
structure on the server but you mask it out. The folders under the
Gmail folder look like they are at the same level as the Inbox folder.
Peculiarly the Inbox folder must be specially handled since shows as
unrooted when you leave blank the root path (in your client). Like I
said, Google has their own implementation of POP and IMAP. I wouldn't
go by what Google does with their IMAP (aka gIMAP) to know how standard
IMAP is supposed to work.

You can RFC 3501 (http://www.rfc-editor.org/rfc/rfc3501.txt) on how IMAP
is supposed to work regarding the LIST and SELECT commands. Google
seems to somewhat follow the RFC for the non-Inbox folders by having you
root the pathing to a Gmail directory under your account but they
apparently do something odd, er, special for the Inbox folder.

While we call them folders, the RFCs refer to them as mailboxes. POP
only knows about a single mailbox and why it can only retrieve items
listed in the Inbox folder shown by the webmail client to your account.
IMAP can handle multiple mailboxes (aka folders). It looks like an IMAP
account must have a minimum of one mailbox and that's called the Inbox
mailbox. All the others (Sent, Drafts, Trash, Junk or Spam) are
optional. So Google must figure that you should always see the Inbox
mailbox without requiring to specify where to root the pathing to access
the mailbox(es) under your account. I can't be sure that isn't how all
IMAP servers handle showing you the minimum Inbox mailbox since lots of
implementation details can be masked to the client.

The above are my noob observations from glancing over RFCs and noting
behavior. I haven't been using IMAP long enough to warrant my thorough
investigation on how IMAP should work versus how it get implemented.
There are probably newsgroups or forums where you can get gurus that
have written IMAP server programs to know just how LIST, SELECT, and
rooting work; however, I'm not sure anyone outside Google's Gmail group
knows how IMAP works under the covers for Gmail.

Rooting says what is the starting point for finding folders (mailboxes)
in your account. Hopefully the server restricts you from walking too
far up the path to end up seeing all accounts under a family account or
going back even further to see the account folders for other customers.
So there is an assumption that the root you get will be whatever is the
root path in your account. Specifying a root means you are actually
walking down further in the tree of folders (mailboxes) under your
account.

Serves me right for asking.