Re: Suggestions for Balsa

[Brian Stafford <brian stafford uklinux net>]

On 2001.10.06 22:24:47 +0100 Jon Tai wrote:
> On 2001.10.06 14:06 Pawel Salek wrote:
> >
> >On 2001.10.06 22:57 Peter Bloomfield wrote:
> >>One more question: can you be more specific about `If I edit the 
> >>file...'? What file is that? Would it be the same as unsubscribing? If 
> >>it is, the folder is still supposed to be listed, since the MUA needs to 
> >>explore its subtree for subscribed folders/mailboxes, and I think you'd 
> >>want Balsa to show it as a node in the mailbox tree. A client that fails 
> >>to see the subtree is itself broken, as I understand the process.
> >
> >I guess he meant ~/.mailboxlist which is a text file that UW-IMAP stores 
> >the list of subscribed folders in. Operations on this file are identical 
> >to (UN)SUBSCRIBEing via IMAP commands.
> >
> 
> Correct.  Sorry I didn't make myself clear...
> 
> >I concur that Outlook express in broken in this respect, and squirrelmail 
> >behaviour can be considered as a, hm, feature.
> 
> Agreed, but the alternative would be writing UW IMAP and telling them 
> their server is broken,

Steady, this is not a good idea.  The UW IMAP server is written by the same
bloke that is the principal author of the IMAP RFCs (start with RFC 2060).
Telling him his software is broken wrt the standard he created is unlikely to
help and is also fairly insulting.  OTOH, nobody writes bug-free code so
sending a reasoned argument making reference to the standards and documenting
why the server fails to conform to the normative requirements *is* likely to
get a result.  Also, it is unlikely that the Cyrus server is broken wrt IMAP
RFCs.  Since IMAP is an IETF standard, it is unlikely to pass muster within
the IETF if a client is required to "adapt its behaviour" to the server.
The primary IETF criterion for progressing on the standards track is
interoperability.  Had this not been the case IMAP would never have made
it past peer review in its present form.

The proper solution here is to make sure the client is correctly implemented.
When problems surface with an applications ability to interpret stuff on
deployed infrastructure - suspect the application first.  Make sure the
issues are understood before accusing the authors of the servers (and clients)
of not knowing what they are doing.

Having participated in the IETF standards process in the past, I have either
met or attended presentations by some of the people involved in the creation
of the mail related protocols.  From this experience I know that there are many
subtleties associated with the mail infrastructure - this is why my instinct
is to suspect the local implementation first.  The people who design the IETF
protocols are amongst the brightest people I have ever had the privilege to
meet as are those who have reviewed the draft documents.

> writing Squirrelmail telling them to remove 
> support for UW IMAP,

Again not a good idea...

> and then writing Microsoft, which of course would do 
> no good.

... vote with your feet, dont use the product.  Work to help create a correct
implementation rather than belly aching about others that are broken.

Brian Stafford