OK, this one has me stumped.
Imagine that as a client you get this as part of a response to a LIST
command:
-- Cut here
* LIST () / Public Folders/Busi 3923C2/Carisa Lloyd
-- Cut here
Is
David Harris writes:
OK, this one has me stumped.
Imagine that as a client you get this as part of a response to a LIST
command:
-- Cut here
* LIST () / Public Folders/Busi 3923C2/Carisa Lloyd
-- Cut here
Hi,
Arnt recommended that I try Mulberry as it would do a good job of
checking my compatibility.
It did indeed find a few issues relating to byte counts in message
parts. I now have my server running correctly with Mulberry.
However, some different issues have come to light.
1. Mulberry seems
1. Mulberry seems to assume that it is the only client that accesses the
mail store. It doesn't use the IDLE command, and rarely sends NOOPS. In
fact it only ever seems to do FETCH STORES unless you explicitly hit
the check button.
In the Preferences, look at the Alerts tab and change the
Christof, as the author of the well-known server (there, I gave it
away), the ghost messages that it returns are valid w.r.t. FLAGS, but
when you attempt to fetch a body part, it returns NIL (or an envelope
containing only NILs) etc.
Our problem was that our message store doesn't have the ability
Absolutely. It's entirely possible that you can have hierarchy without
there being folders in the middle.
Consider Netnews.
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
With Exchange, this could happen if you have access to Public
Folders/Busi 3923C2/Carisa Lloyd but you don't have
Because at the first IMC face-to-face, a number of client authors said:
Hey, it would be REALLY nice if you added this feature to the
protocol, Mike Gharns said Sure, I'll write it up, and I said Ok,
I'll put it in. So we did.
And a couple of people added support for it and.
It turns out
The trailing / indicates that the mailbox in question is a
hierarchy-only mailbox, it can't contain messages iirc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Harris
Sent: Sunday, January 04, 2004 6:23 PM
To: [EMAIL PROTECTED]
Subject:
Before someone mentions \NoSelect - you not might have folder visibility
access to Public Folders/Busi 3923C2 - which means that even though
the folder exists, you can't enumerate it.
Exchange has the concept of per-folder (and per-message) visibility as
enforced by the Visible ACE flag, what
Larry Osterman writes:
Absolutely. It's entirely possible that you can have hierarchy without
there being folders in the middle.
Consider Netnews.
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
With Exchange, this could happen if you
Hi Larry,
Christof, as the author of the well-known server (there, I gave it
away), the ghost messages that it returns are valid w.r.t. FLAGS, but
when you attempt to fetch a body part, it returns NIL (or an envelope
containing only NILs) etc.
Arnt was arguing this might viloate cache semantics;
On Tue, 6 Jan 2004, Arnt Gulbrandsen wrote:
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
Yes, but such a name shows up with a % wildcard. It does not necessarily
show up with a * wildcard.
Doesn't that make a mockery of \noselect?
On Tue, 6 Jan 2004, Richard Bang wrote:
At the
moment, the only clients that seems to do a good job of shared folders
are the dreaded Outlook duo from MS. I cant find any others that use
IDLE or NOOP at a reasonable rate. Any suggestions would be appreciated.
Pine does periodic NOOP.
-- Mark
hello, i'm planning on moving some mailboxes to another server but am having
problems
using mailutil. i believe the remote server is uw's imap-2001a and i'm
using mailutil from
the imap2002d source (from debian's uw-mailutils package). the remote
server only listens
on port 993 so in trying
On Tue, 6 Jan 2004, bj rui wrote:
mailutil check {remote.host.name:993 /user=username}
Two problems:
1) There should be no space in the string.
2) Using :993 without /ssl says to make a non-SSL connection to the
SSL port. I don't think that you want to do that.
The correct command is:
Hi,
Rather than trying to have the server keep a record of what the client
knows about so that it can second guess what the client might ask for,
surely we should just tell the clients to sync up.
And I don't know what's wrong with
SEARCH 1:* UNSEEN
* SEARCH 1,2,3,4,5,6,7,8,9
* EXPUNGE 5
OK
Mark Crispin writes:
On Tue, 6 Jan 2004, Arnt Gulbrandsen wrote:
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
Yes, but such a name shows up with a % wildcard.
It does? Larry, can you confirm that?
It does not necessarily show up with
Hi,
On 01/06/04 16:49:42 + Richard Bang [EMAIL PROTECTED] wrote:
Hi,
Rather than trying to have the server keep a record of what the client
knows about so that it can second guess what the client might ask for,
surely we should just tell the clients to sync up.
And I don't know what's wrong
So the server cannot send an expunge response until it can be sure
the client has not queued up loads of fetches for sequence
numbers that might have been invalidated.
Such a sync point can be forced by the client by sending
noops more often
or entering an explicit idle state with the idle
Richard Bang wrote:
IMAP as it stands does not seem to cater at all well for shared folders.
The Cyrus server has no problem at all with shared folders. CMU uses
shared folders heavily (hundreds, if not thousands of folders) with
clients ranging from Pine to Mulberry to Outlook to Mozilla.
I would like to apologise to Mark for upsetting him.
I have been informed he is now ignoring my mail.
I will lurk on this list, but I will not post any more messages.
My apologies to anyone else I might have upset.
Regards
Richard Bang
Floosietek Ltd
[EMAIL PROTECTED]
A couple of observations and questions about folders and hierarchies:
There are no mechanisms for manipulating hierarchies via the protocol. If
I want to create or rename a folder hierarchy (eg, create a #public
hierarchy), then I have to do it off-line since there is no support in the
protocol
On Tue, 6 Jan 2004, Eric A. Hall wrote:
There are no mechanisms for manipulating hierarchies via the protocol. If
I want to create or rename a folder hierarchy (eg, create a #public
hierarchy), then I have to do it off-line since there is no support in the
protocol directly.
Well, supposedly
Larry Osterman wrote:
I'm speaking for Barry, but as I remember, the logic behind allowing
IDLE in the authenticated state is that in the future a server might
have legitimate information to send to the client when in the
authenticated state.
Currently there's no such info that can happen but...
On 1/6/2004 2:22 PM, Mark Crispin wrote:
As far as creating namespaces themselves, these are usually an artifact
of the implementation software and not a level of hierarchy. It may be
helpful to think of namespaces as being like the D: and E: drives in
Windows with the default namespace
On 6 Jan 2004 at 8:16, Mark Crispin wrote:
IMAP tries to reconcile multiple forms of mail store with sharply
different semantics. Rumors to the contrary notwithstanding, there is no
such thing as an IMAP ideal mail store.
IMAP's definition of hierarchy is a wretched compromise born out of
On Wed, 7 Jan 2004, David Harris wrote:
1: I don't consider myself enough of an IMAP expert to be qualfied for
the task.
You'll learn on the job. Trust me.
2: Since in 14 years of developing e-mail packages I've never once
been invited to participate in any IETF discussions of any kind, I
On Tue, 6 Jan 2004, Eric A. Hall wrote:
Right, they are partitions of the underlying mailstore. The partitions may
be tied to one or more filesystems, or they may be logical representations
of a filesystem (eg, netnews) or some representation of a database
subsystem, or whatever.
Or, instead
On Wed, 7 Jan 2004, David Harris wrote:
I guess that means I've just broken rule #1 - I volunteered. :-)
No good deed goes unpunished. :-)
Generally, there is no such thing as an invitation to a discussion.
?? Way back in 1992 or 1993 I asked John Klensin if I could take part
in the SMTP
On Tue, 6 Jan 2004, Eric A. Hall wrote:
Okay, semantics first. Servers have one (logical) mailstore. The mailstore
may contain one or more subordinate stores, which are essentially
partitions. Whereas you are saying that a server may have multiple stores,
I'm saying that those are partitions
At 05:14 AM 1/5/2004 +0200, Timo Sirainen wrote:
Something I just thought about doing optionally: Mark the message
expunged using some non-standard flag and expunge it later (maybe in
some nightly run). Don't show expunge-marked messages to clients, unless
they haven't been notified that it's been
I think that this discussion indicates that at the very least some
documented clarification is required...
While we are on the subject of clarification, I am moved to suggest one
other related area where I think some clarification would be
beneficial. That is to specify the minimum
--On 2004-1-6 7:32 PM -0500 Pete Maclean [EMAIL PROTECTED] wrote:
While we are on the subject of clarification, I am moved to suggest
one other related area where I think some clarification would be
beneficial. That is to specify the minimum requirements for a
mailstore to be suitable for use
On 1/6/2004 5:58 PM, Mark Crispin wrote:
The barrier that your idea needs to overcome is why not use a root-level
name instead of a namespace.
To be clear, I'm not making a proposal. My original question was whether
or not this is a hole in the protocol. Obviously it's not a very big hole
or
thing is an interesting idea--but on some servers,
mounted namespaces wouldn't be appropriate for the top level (i.e.,
Cyrus). They could also be handled inside the user's account, perhaps
/home/tjs/archive/20040106/INBOX, for instance; maybe this is good,
maybe it's not.
Anyway, I'm sorry
On 1/6/2004 8:39 PM, Tim Showalter wrote:
It's not necessary that partitions should map to NAMESPACE-advertised
parts hierarchy at all. Cyrus allows mailboxes in the same hierarchy
to live on different partitions.
I see what you're saying, but I think that level of abstraction is also
On 7.1.2004, at 01:20, Mark Crispin wrote:
In netnews type semantics such as Cyrus, names are absolute. However,
use of a non-empty LIST reference makes the name in the list pattern
relative to the reference (otherwise clients that use the LIST
reference
for a cwd are broken). I think that in
On Wed, 7 Jan 2004, Timo Sirainen wrote:
I think that in Cyrus:
LIST foo.bar zap.zowie = foo.zap.zowie
LIST foo.bar. zap.zowie = foo.bar.zap.zowie
LIST foo.bar .zap.zowie = foo.bar.zap.zowie
but I'm not really sure; in practice only the second form is used.
Well, this
38 matches
Mail list logo
