mailing list archives

Hi,

I've been reworking my folder handling to allow for UTF-16 mail store names and I've come across a problem in the interaction between my server and Pine. 

I have a mail store that looks like this
/inbox
/folder1
/folder2
/folder2/folder3

Pine sends the query
LIST INBOX %

Given the above folder list what would be the correct response?

I believe it should be
x OK List Completed

without any stores listed because there are none that match. However, at this point Pine stops looking for folders and doesn't list any.

Any advice would be greatly appreciated.

Regards

Richard (http://www.ftgate.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060803/74792b4a/attachment.html>

Are you saying that your mail store does not have INBOX?  /inbox is not 
equivalent to INBOX.

Or are you saying that your mail store has INBOX, but does not respond 
with any data to the command
 	tag LIST INBOX %
If so, it should; that command matches INBOX.

On Thu, 3 Aug 2006, Richard Bang wrote:

> Hi,
>
> I've been reworking my folder handling to allow for UTF-16 mail store names and I've come across a problem in the interaction between my server and Pine.
>
> I have a mail store that looks like this
> /inbox
> /folder1
> /folder2
> /folder2/folder3
>
> Pine sends the query
> LIST INBOX %
>
> Given the above folder list what would be the correct response?
>
> I believe it should be
> x OK List Completed
>
> without any stores listed because there are none that match. However, at this point Pine stops looking for folders and doesn't list any.
>
> Any advice would be greatly appreciated.
>
> Regards
>
> Richard (http://www.ftgate.com)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Also, what are "UTF-16 mail store names"?!?

UTF-16 is certainly not permitted in an IMAP mailbox name!  Currently, 
only modified UTF-7 is permitted for internationalized names, although in 
the future there is an attempt to relax the restriction that precludes 
UTF-8 mailbox names.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Mark Crispin writes:
> Are you saying that your mail store does not have INBOX?  /inbox is 
> not equivalent to INBOX.

Hm?

On cyrus, user.arnt is equivalent to INBOX. On uw, /var/spool/mail/arnt 
is equivalent to INBOX. The only thing I can see about /inbox that's 
different from those two is that it contains 'inbox' as a level of 
hierarchy, but is that forbidden?

Artn

Mark Crispin writes:
> Are you saying that your mail store does not have INBOX?  /inbox is 
> not equivalent to INBOX.
>
> Or are you saying that your mail store has INBOX, but does not respond 
> with any data to the command
>        tag LIST INBOX %
> If so, it should; that command matches INBOX.

RFC 3501, page 41, says this on the subject:

            If the reference argument is not a level of mailbox
            hierarchy (that is, it is a \NoInferiors name), and/or
            the reference argument does not end with the hierarchy
            delimiter, it is implementation-dependent how this is
            interpreted.  For example, a reference of "foo/bar" and
            mailbox name of "rag/baz" could be interpreted as
            "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".

Pine's reference name does not end with a hierarchy separator and 
Richard's server's empty response fits two of the three explicitly 
sanctioned possibilities. Sounds OK to me.

As for pine, it is a client and page 41 continues:

            A client SHOULD NOT use such a reference argument except
            at the explicit request of the user.

(I'll reply to your other email later.)

Arnt

On Thu, 3 Aug 2006, Arnt Gulbrandsen wrote:
> Mark Crispin writes:
>> Are you saying that your mail store does not have INBOX?  /inbox is not 
>> equivalent to INBOX.
> On cyrus, user.arnt is equivalent to INBOX. On uw, /var/spool/mail/arnt is 
> equivalent to INBOX.

No, they are not equivalent.  These are names which may access the same 
data in certain configurations of certain implementations, but they are 
not INBOX.  INBOX has a special meaning in IMAP.

[Incidentally, /var/spool/mail/mrc does not access my INBOX on any 
installation of UW imapd that I use.]

> The only thing I can see about /inbox that's different 
> from those two is that it contains 'inbox' as a level of hierarchy, but is 
> that forbidden?

/inbox is simply an ordinary name.  It is not INBOX, even if it happens to 
access the same data in a particular configuration on Richard's server.

You also missed the point of my comment; I asked Richard if his mail store 
did not have INBOX.  I asked because he said that he felt that no untagged 
LIST results should be returned for "tag LIST INBOX %", yet his hierarchy 
had /inbox which suggested that there was, indeed, a mailbox that has the 
role of INBOX in his server.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Thu, 3 Aug 2006, Mark Crispin wrote:
> You also missed the point of my comment; I asked Richard if his mail store 
> did not have INBOX.  I asked because he said that he felt that no untagged 
> LIST results should be returned for "tag LIST INBOX %", yet his hierarchy had 
> /inbox which suggested that there was, indeed, a mailbox that has the role of 
> INBOX in his server.

That, in turn, means that his server should have INBOX, regardless of 
whether there is this other name of /inbox that can access that data.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Mark Crispin writes:
> On Thu, 3 Aug 2006, Mark Crispin wrote:
>> You also missed the point of my comment; I asked Richard if his mail 
>> store did not have INBOX.  I asked because he said that he felt that 
>> no untagged LIST results should be returned for "tag LIST INBOX %", 
>> yet his hierarchy had /inbox which suggested that there was, indeed, 
>> a mailbox that has the role of INBOX in his server.
>
> That, in turn, means that his server should have INBOX, regardless of 
> whether there is this other name of /inbox that can access that data.

Absolutely. "select INBOX" must work, no question about it. That doesn't 
mean that INBOX has any special meaning when used as reference name - 
there's nothing which says that the "foo/bar" example doesn't apply to 
INBOX just as to any other mailbox name or level of hierarchy.

Arnt