Subject: Re: Name attributes in LSUB responses

From: "Russ Atkind" <[email-masked]>
Date: Tue, 12 May 1998 02:12:19 -0400

Two things:

>> For mailboxes that do exist, is it required that an LSUB response contain
>> the same list of name attributes as the LIST response for the same
mailbox? 
>> In testing the big-name servers I have observed some widely varying
>> behaviors.
> 
> So I believe what Russ is diplomatically alluding to is that is that
Cyrus,
> under some circumstances, can do this:

Actually, I wasn't thinking of Cyrus, despite the coincidence with my report
of the behavior you mention.  The question I ask was inspired by behavior I
observed of a very old version of the UW server, but I really would like an
answer independent of any particular server implementation.  The question is
a somewhat important one for me to have an answer to for my client
implementation -- I want to know what people think the spec intends/implies,
since I'm not sure that it's clear on this issue.  Of course, if a major
server such as Cyrus behaves in a certain way, even if that's not so kosher,
I don't have much choice but to engineer my client not to be broken by it. 
But I am really curious what everyone thinks about this.

> 
> C: . lsub "" %
> S: * LSUB (\Noselect) "." INBOX
> S: . OK Completed
> C: . list "" %
> S: * LIST () "." INBOX
> S: . OK Completed
> 
> The circumstances are simple: Have a mailbox called "INBOX", then
> unsubscribe to it.  (Someone put the "anonymous" user on
> cyrus.andrew.cmu.edu in this state.)
> 
> While I agree that this is counterintuitive, misleading, and very very
> nasty, it would be absolutely wrong for the server to say
> S: . LSUB () "." INBOX
> if the user is not actually subscribed to INBOX.

Right, of course.  But forget about counterintuitive, misleading,
destructive, genocidal; it seems to me that it's just broken.  I mean, if
you're going to choose a way to be broken, subscription is not a bad place
to choose it, but the spec says:

      The LSUB command returns a subset of names from the set of names
      that the user has declared as being "active" or "subscribed".
      Zero or more untagged LSUB replies are returned.  The arguments to
      LSUB are in the same form as those for LIST.

So, 2 non-compliances:

1) Interpretation of the text above: if there is an LSUB response at all for
mailbox Fred, that means that the mailbox name Fred is subscribed.

2) Spec is pretty clear that "\Noselect" absolutely, positively means that
trying to SELECT the mailbox will fail, but here it succeeds.

Now, 

      A server MAY validate the subscribed names to see if they still
      exist.  If a name does not exist, it SHOULD be flagged with the
      \Noselect attribute in the LSUB response.  The server MUST NOT
      unilaterally remove an existing mailbox name from the subscription
      list even if a mailbox by that name no longer exists.

..so the LSUB/Noselect combo for INBOX seems particularly ridiculous -- one
could argue that it's suggesting that INBOX does not exist!  Maybe this is
at least part of what you meant by "misleading" etc.

By the way, I observed this behavior on 1.5.8 Alpha only.  My account on a
1.5.2 server is not anonymous, but when I unsubscribe from INBOX, LSUB no
longer returns a response for it.

Russ