MBOX-Line: From mrc at CAC.Washington.EDU  Sun Mar 11 17:37:20 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] mailbox hierarchy conventions? 
In-Reply-To: <07Mar11.162448pst."57996"@synergy1.parc.xerox.com>
References: <07Mar11.154843pst."57996"@synergy1.parc.xerox.com>
	<alpine.OSX.0.83.0703111704450.20984@pangtzu.panda.com>
	<07Mar11.162448pst."57996"@synergy1.parc.xerox.com>
Message-ID: <alpine.OSX.0.83.0703111726370.20984@pangtzu.panda.com>

On Sun, 11 Mar 2007, Bill Janssen wrote:
> I certainly understand your feelings here, but Apple Mail is the
> client I'm trying to support, with all its imperfections.

I guess that I wasn't clear.  The problem with implementing a server for a 
particular client, as opposed to the specification, is that the server 
ends up complying with the server author's understanding of what the 
client does.  That is not necessarily the same as what the client actually 
does; and it tends to compound mistakes.

> where
> there are unspecified things (like how to arrange mailboxes), I'd just
> as soon do it the way that some other folks do it, to smooth the path.

This is a good example.  What you stated was your understanding (and 
perhaps others' understanding) of what Apple Mail does.  As unsatisfactory 
as I find Apple Mail to be, the fact is that if it really worked that way 
it would not work at all with multiple widely-deployed servers.

Put another way, you expressed a misunderstanding.  This happens all the 
time.

That's why I advise that you disregard all such (mis)understandings and 
implement only according to the specification.  You'll find that the 
majority of the (mis)understandings are overtaken by events -- the "that's 
strong, I thought it did such-and-such and I was going to have to do this 
workaround for it.  Well, it seems to work the way it is, so I'm leaving 
it alone!" scenario.

Undoubtably, when you finish the server there will be interoperability 
issues.  However, I recommend that you first consult with this mailing 
list, since it might be a bug at your end.  Only after we get through all 
of that, then you can start thinking about workaround for a particular 
client.

It's the whole notion of avoiding going into the swamp unh

>> Have you thought about trying UW imapd, even if you plan to deploy your
>> own implementation, just so you have reference to compare?
> Good idea.  I hadn't realized that it supported MH folders.  I'll do that.

Yup.  mh names are in the #mh/ namespace, and the #mhinbox (with snarfing 
from the spool directory) is #mhinbox.  It's armed by the .mh_profile 
file.

-- 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.

