63 lines
2.8 KiB
Plaintext
63 lines
2.8 KiB
Plaintext
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.
|
|
|