A mailbox can be subscribed to twice, which does not make any sense, whatsoever.
If an interpretation does not make sense, that should be a clue that there is something wrong with the interpretation, and that an alternative interpretation should be found.
In your own RFC, 3501, 6.3.6:
The SUBSCRIBE command adds the specified mailbox name to the
server's set of "active" or "subscribed" mailboxes as returned by
the LSUB command. This command returns a tagged OK response only
if the subscription is successful.
Adds, this means if you have foo and add foo, you get foo foo. As written,
this is completely unambiguous. If you have a set {a,b,c} and add the set
{a} then you get {a,b,c,a}. It doesn't make sense, but it's what it says.
This may be a language comprehension problem.
In English, "add" can have the meaning of "enter if not already present." "Please add Andreas to the IMAP club" does *not* mean "please clone Andreas if he is already a member of the club." "Please add my workstation to the list of systems authorized to access the open Internet" does *not* mean "please put my workstation in that list a second time if it is already there."
Common sense is necessary in such circumstances. It makes no sense to list a workstation twice in an access list. It makes no sense to clone Andreas so he is in the club twice. It makes no sense to have a mailbox subscribed twice.
Moreover, the LSUB command mentions nothing about removing duplicates so one has to assume that multiple subscribed mailboxes must be listed as they are.
It is impossible for any specification to itemize exhaustively (or even anticipate) every possible absurdity. Since it's absurd to duplicate an entry in the subscription list, it's pointless to talk about LSUB removing duplicates.
This has been discussed before, and Courier-IMAP and Cyrus IMAP both ignore the second SUBSCRIBE to foo; I specifically remember the discussion being that with the current IMAP scheme, the subscribed-list can be filled with junk this way.
I'm not sure what you mean by "ignore", unless you mean "issue an OK but do nothing" on an attempted duplicate SUBSCRIBE. UW imapd issues a NO and does nothing. Either way, you're reporting that three servers agree that names are not duplicated, which in turn does not support your position.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
