INBOX, how is it really supposed to work?
use...@isbd.co.uk
is INBOX cast in stone in IMAP servers (i.e. is it in the RFC and must
it be called INBOX) and how is it supposed to work?
Different MUAs (and different IMAP servers) seem to treat INBOX in
different ways and I find this somewhat confusing. Some simply treat
it as the place where new mail arrives and keep it separate from the
rest of the IMAP folder hierarchy, others require that the folder
hierarchy is rooted at the INBOX.
Personally I find having to have something called INBOX rather odd, on
the system where I read most of my mail I have procmail delivering my
mail to multiple 'new mail' folders according to its source and
subject. This approach is simply impossible (I think, please tell me
if I'm wrong) with an IMAP server, you can only get new mail delivered
to INBOX, rather limiting. Actually that's rubbish of course, it
depends how the mail arrives rather than on the IMAP server, in fact
considering the papragraph below it's confused me even more now!
If I run UW Imap on the system where I normally read my mail locally I
can see all my mail OK but UW Imap insists on creating an INBOX
directory which has no function at all, no mail ever gets into it and
the folder hierarchy of my actual mail is rooted elsewhere.
--
Chris Green
Mark Crispin
> Another question to go along with the one about subscribe/unsubscribe,
> is INBOX cast in stone in IMAP servers (i.e. is it in the RFC and must
> it be called INBOX)
Yes
> and how is it supposed to work?
The IMAP specification defines INBOX as follows:
The case-insensitive mailbox name INBOX is a special name reserved to
mean "the primary mailbox for this user on this server". The
interpretation of all other names is implementation-dependent.
Note that any name which is not INBOX but is prefixed with "INBOX" is an
"other name" with implementation-dependent interpretation.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
use...@isbd.co.uk
> On Wed, 25 May 2005, use...@isbd.co.uk wrote:
> > Another question to go along with the one about subscribe/unsubscribe,
> > is INBOX cast in stone in IMAP servers (i.e. is it in the RFC and must
> > it be called INBOX)
>
> Yes
>
> > and how is it supposed to work?
>
> The IMAP specification defines INBOX as follows:
> The case-insensitive mailbox name INBOX is a special name reserved to
> mean "the primary mailbox for this user on this server". The
> interpretation of all other names is implementation-dependent.
>
and, if I did why should I have to call it INBOX? I know this can't
be changed now but it does seem to be a rather odd requirement of the
IMAP4 protocol as it constrains MUAs to do things that they wouldn't
otherwise have to do.
--
Chris Green
NM Public
It seems to me that the INBOX *concept* is not a constraint, but
actually makes things easier for both MUA developers and users.
Here's how I think of it:
+-----------------------------------------------+
| |
| IMAP Server |
| |
| +------------------------------------+ |
| | username's personal mailstore | |
| | | |
| | +----------------------------+ | |
| | | username's special mailbox | | |
| | +----------------------------+ | |
| | ^ | |
| | | | |
| +-------+----------------------------+ |
| | ^ |
| | | |
| | | |
+--------------+---+----------------------------+
| |
INBOX| |(standard name for personal mailstore???)
| |
+-----+
| MUA |
+-----+
If the MUA wants to ask for the special mailbox, it uses the
special name INBOX *as part of the protocol dialog*. But, AKAIK,
the MUA can present this mailbox to the user with any name and in
fact does not even need to present it at all (for example, if
filters automatically move INBOX messages somewhere else). I'm
sure Mark will correct me if I'm wrong!
What I would like is a standard way to refer to the user's
personal mailstore, for example, a namespace like this:
#personal
Again, the user would not need to know about this special name.
The MUA could simply be configured to automatically present the
#personal mailstore and a user would only need to configure the
"IMAP path" (aka "IMAP prefix" or "IMAP root" or "IMAP
namespace") if she wanted something other than the #personal
namespace. I read a lot of IMAP-related discussion groups and
users (and even some admins!) have an unbelievable amount of
trouble understanding how to get an IMAP client to point to
username's personal mailstore.
If I am confused about all this, please let me know. I am writing
this from an IMAP user's perspective so I won't be surprised if I
am wrong about the protocol level behavior.
Thank you, Nancy
--
Nancy McGough ~ <http://www.ii.com> ~ <http://deflexion.com>
IMAP, pine, procmail, data deflexion, infinity, and more
> > > Please keep the discussion in the group < < <
Pete Maclean
> Mark Crispin <M...@cac.washington.edu> wrote:
>> On Wed, 25 May 2005, use...@isbd.co.uk wrote:
>> > Another question to go along with the one about subscribe/unsubscribe,
>> > is INBOX cast in stone in IMAP servers (i.e. is it in the RFC and must
>> > it be called INBOX)
>>
>> Yes
>>
>> > and how is it supposed to work?
>>
>> The IMAP specification defines INBOX as follows:
>> The case-insensitive mailbox name INBOX is a special name reserved to
>> mean "the primary mailbox for this user on this server". The
>> interpretation of all other names is implementation-dependent.
>>
> OK, thanks. However why should I *have* a "primary mailbox" at all
There is no requirement in IMAP that you have such a "primary mailbox".
> and, if I did why should I have to call it INBOX?
"INBOX" is like a code word used between IMAP client and server to refer
to the user's primary mailbox if and when that exists. Outside of the IMAP
realm it may be called something different and the client is entirely free
in
principle to present it to the user with any name. If the choice of name
is yours (and I know of few cases where the user has such control), you can
probably name it anything you want.
> I know this can't be changed now but it does seem to be a rather odd
> requirement of the IMAP4 protocol as it constrains MUAs to do things
> that they wouldn't otherwise have to do.
It can indeed be a constraint not only on the client but on the server as
well.
Pete Maclean
wkearney99
> and, if I did why should I have to call it INBOX? I know this can't
> be changed now but it does seem to be a rather odd requirement of the
> IMAP4 protocol as it constrains MUAs to do things that they wouldn't
> otherwise have to do.
You're more than free to have whatever additional boxes you like. I have
several for handling mail from different accounts; Inbox-Yahoo,
Inbox-Hotmail, etc... one for each external account. I then pull the mail
from each of them using fetchmail and deliver it directly to the appropriate
folder. Works great. There is an INBOX folder but I never read it as
that's just the shell account's mailbox and never has anything delivered to
it.
So where's the problem?
Mark Crispin
> OK, thanks. However why should I *have* a "primary mailbox" at all
> and, if I did why should I have to call it INBOX? I know this can't
> be changed now but it does seem to be a rather odd requirement of the
> IMAP4 protocol as it constrains MUAs to do things that they wouldn't
> otherwise have to do.
You are an IMAP client developer. You have a user with userid fred, and
you need to get fred's IMAP client configured.
Looks like you need to know the operating system of the host operating
system. If it's a TOPS-20 system, then fred's mail is on
PS:<FRED>MAIL.TXT. That's easy.
If it's a UNIX system, then fred's mail is on /var/spool/mail/fred.
Except when it is /var/mail/fred. Or /usr/spool/mail/fred. Or
/usr/mail/fred. Or ~fred/mbox. Or ~fred/mail.txt. Or ~fred/INBOX. Or
~fred/Mailboxes/Inbox/. etc. ad nauseum.
If it's a Windows sytem, then fred's mail is on some directory in the
bowels of IIS. Or is it on C:\WINSMTP\FRED?
If it's a VMS system, then...
Such a bother! Why didn't the designer of IMAP create One True Name that
all servers must map into the place where fred's mail is? How the hell
can I ever keep track on all these names? Why is my support line
constantly ringing off the hook with irate customers complaining that my
client can't get at the mail?
Then you awake from your nightmare.
You remember that the designer of IMAP did create One True Name, and that
name is INBOX. Whew! Thank goodness!
And you go back to sleep, thankful that it was just a bad dream and not
real.
use...@isbd.co.uk
directory!
--
Chris Green
use...@isbd.co.uk
> On Thu, 26 May 2005, use...@isbd.co.uk wrote:
> > OK, thanks. However why should I *have* a "primary mailbox" at all
> > and, if I did why should I have to call it INBOX? I know this can't
> > be changed now but it does seem to be a rather odd requirement of the
> > IMAP4 protocol as it constrains MUAs to do things that they wouldn't
> > otherwise have to do.
>
> You are an IMAP client developer. You have a user with userid fred, and
> you need to get fred's IMAP client configured.
>
> Looks like you need to know the operating system of the host operating
> system. If it's a TOPS-20 system, then fred's mail is on
> PS:<FRED>MAIL.TXT. That's easy.
>
> If it's a UNIX system, then fred's mail is on /var/spool/mail/fred.
> Except when it is /var/mail/fred. Or /usr/spool/mail/fred. Or
> /usr/mail/fred. Or ~fred/mbox. Or ~fred/mail.txt. Or ~fred/INBOX. Or
> ~fred/Mailboxes/Inbox/. etc. ad nauseum.
>
> If it's a Windows sytem, then fred's mail is on some directory in the
> bowels of IIS. Or is it on C:\WINSMTP\FRED?
>
> If it's a VMS system, then...
>
WHY do I need to know these things? The point I am making is that
it's inherent in the way that people (well me anyway) use their mail
that there isn't a magic, single folder which is incoming mail's home.
Not to mention that none of the above have anything to do with IMAP's
INBOX, you *still* need to configure your MUA to know about the above
folders, having IMAP's INBOX doesn't make any difference to that
requirement.
If a remote IMAP server want's to have a home 'folder' (which is
effectively a virtual folder, it doesn't have to have any reality) for
a user than it can, and it can call it zzxxccddee for all I care as I
don't have to know about it.
--
Chris Green
wkearney99
So? You have the source, go scratch your itch.
<use...@isbd.co.uk> wrote in message news:3g03b5F...@individual.net...
NM Public
> WHY do I need to know these things? The point I am making is that
> it's inherent in the way that people (well me anyway) use their mail
> that there isn't a magic, single folder which is incoming mail's home.
>
> Not to mention that none of the above have anything to do with IMAP's
> INBOX, you *still* need to configure your MUA to know about the above
> folders, having IMAP's INBOX doesn't make any difference to that
> requirement.
>
> If a remote IMAP server want's to have a home 'folder' (which is
> effectively a virtual folder, it doesn't have to have any reality) for
> a user than it can, and it can call it zzxxccddee for all I care as I
> don't have to know about it.
I agree with you Chris and I'm wondering what IMAP client you are
using? I suggest that you try Mulberry and set up Cabinets, which
are virtual directories (aka virtual collections) of mailboxes
that are of interest to you. For example, you can create a
"RECENT Mail" cabinet that contains all your mailboxes that
contain a RECENT message. Then you never need to look at the
string "INBOX"! All my incoming mailboxes have names that start
with the string "--", for example, "--procmail" is where procmail
mailing-list messages are delivered, "--green" is where my
greenlisted messages are delivered, "--yellow" is where my
MaybeSpam messages are delivered, "--red" is where my
AlmostSurelySpam messages are delivered, etc. Nothing is ever
delivered to my so-called IMAP INBOX.
Does anyone know of any IMAP client other than Mulberry that
allows the user to hide the string "INBOX" -- I also think it
sucks. But, it is a problem with IMAP clients that were designed
by people stuck in the old POP single-INBOX state of mind, not a
problem with the IMAP protocol.