On 28.9.2004, at 22:19, Michael Wener wrote:
This is clearly a client bug. There are no guarantees that multiple
sessions have compatible sequence numbers. Expunges especially may
make
the fetch return wrong message. At minimum the client should do UID
FETCH and do some fallback processing if it d
On 28.9.2004, at 20:30, Michael Wener wrote:
Session 1
1 IDLE
+ IDLE Accepted
* N EXISTS
* 1 RECENT
Session 2
2 FETCH N BODYSTRUCTURE
* N EXISTS
* 1 RECENT
2 NO the specified message set is invalid
This is clearly a client bug. There are no guarantees that multiple
sessions have compatible seque
On 28.9.2004, at 17:52, Mark Crispin wrote:
On Tue, 28 Sep 2004, Philip Guenther wrote:
What's interesting about Timo's example is that UW-IMAP didn't answer
the question that was asked it. ("from to") != (from to) == ("from"
"to")
What do you mean? Since there is no "from to" header, the respon
On 28.9.2004, at 13:11, Andreas Aardal Hanssen wrote:
Cyrus IMAP says:
3 fetch 1 body[header.fields ("")]
3 BAD Invalid field-name in Fetch BODY[HEADER.FIELDS
I also did some testing. I hadn't noticed before that literals were
allowed in headers list, that needed some changes to my parser.
Anyway
On 25.8.2004, at 11:30, Pawel Salek wrote:
I encountered a strange response to message part fetch command. It
looks like a bug in the server to me but I would like to get a second
opinion. Suggestions how to work around this problem are welcome too.
The problem is the server promises to send 23824
On 19.8.2004, at 00:08, Larry Osterman wrote:
Actually if you set FLAGS to non empty and PERMANENTFLAGS to empty, all
the clients should work. You need to maintain flags in-memory even if
you can't persist them (it's in the spec), but most (if not all)
clients
handle the non persistence correctly
On 18.8.2004, at 23:28, petite_abeille wrote:
Returning empty PERMANENTFLAGS list is your best bet. Although
probably no clients actually do it.
I already do that for anonymous access:
* FLAGS ()
* OK [PERMANENTFLAGS ()]
FLAGS list shouldn't be empty. It should contain at least the system
flags.
On 18.8.2004, at 23:02, petite_abeille wrote:
Is it possible to signal to the client to keep track of the message's
flags?
Returning empty PERMANENTFLAGS list is your best bet. Although probably
no clients actually do it.
PGP.sig
Description: This is a digitally signed message part
On Tue, 2004-07-20 at 16:49, "Antonio Cambule (STÜBER SOFTWARE)" wrote:
> I'm doing the implementation for UIDs and thought that the UID will be
> stored within the Mail itself.
> Taking a look at RFC 2822 I couldn't find anything about UID, the
> Identification Number is called Message ID.
How
Is it correct for client to send "SUBSCRIBE mailbox/" command? If yes,
should server treat it the same as "SUBSCRIBE mailbox"? mailbox being
either a directory, or a dual-user mailbox.
I'm wondering if I should reply with NO to first command, or just make
sure they behave the same so client can't
On Fri, 2004-07-09 at 02:23, Mark Crispin wrote:
> > Unless the account is mirrored between multiple servers in realtime as
> > well (how?), user can also lose mails. Better than everyone's mail
> > breaking, but I'd prefer transparent failovers without any data loss.
>
> Why do you believe that a
On Fri, 2004-07-09 at 01:23, [EMAIL PROTECTED] wrote:
> I'm confident that if Lustre does what it says it should work with IMAP just
> like IMAP works over a local volume. I'm still skeptical that they can boast
> this, but if it turns out that IMAP won't work over Lustre I would suggest
> that IMA
On Thu, 2004-07-08 at 22:25, Mark Crispin wrote:
> Each user has his own DNS name for his server. In my case, it is
> mrc.deskmail.washington.edu, and that is the only system that I connect
> to. Some number of users are on the same physical CPU. mrc.deskmail is
> currently on a machine calle
On Tue, 2004-05-04 at 22:11, Mike Wener wrote:
> > Whether that means anything today is open to debate; but it may mean
> > something tommorrow, and at the very least your client has to handle
> > it well enough to ignore it.
>
> How would this become clearly defined? Is it a matter of conventio
On Wed, 2004-04-28 at 09:58, Andreas Aardal Hanssen wrote:
> With the current IMAP specification, if one client creates a special
> mailbox "Postponed" and subscribes to it, then deletes the mailbox and
> crashes/dies (and is uninstalled and so on), then all other clients will
> forever see the fir
On 7.4.2004, at 17:04, David Harris wrote:
I have an IMAP client developer telling me that my server is broken
because I insist on the proper RFC3501 sequencing of steps when the
client submits a literal.
In short, he is saying that he can send the {} followed by the
data in a single packet withou
On Wed, 2004-03-24 at 19:21, Paul Jarc wrote:
> Mark Crispin <[EMAIL PROTECTED]> wrote:
> > If the message is "no longer available" the server should have sent an
> > untagged expunge.
>
> Of course - if it has had a chance. If it hasn't (i.e., when there
> hasn't been any intermediate command th
On Wed, 2004-03-24 at 00:52, Paul Jarc wrote:
> Timo Sirainen <[EMAIL PROTECTED]> wrote:
> > "Message being deleted" case was just discussed in January (Subject:
> > Multiple command clarification). Issuing NO isn't a very good idea,
> > rather use NIL i
On Tue, 2004-03-23 at 23:00, Paul Jarc wrote:
> But if a particular message is inaccessible (due to wrong permissions,
> or being deleted (possibly by a non-IMAP agent), etc.), then NO is
> appropriate, since the server can still answer other requests, right?
"Message being deleted" case was just
On Wed, 2004-01-21 at 12:30, Richard Bang wrote:
> I have a problem with clients not displaying the subject line correctly
> if it has an 8 bit format. In Outlook the message is just ignored and
> not displayed.
You're sending 8bit chars in "string", not in a literal as required by
IMAP RFC. Outlo
On Fri, 2004-01-16 at 13:18, per hygum wrote:
> Client->Server: 6 FETCH 19 (UID RFC822.SIZE BODY[]<0.4967>)
>
> Client<-Server: "I get the data back I request BUT also additional
> data. This is 'FLAGS (\Recent \Seen)' data". It is contained in the
> same untagged response and not in a seperat
On Wed, 2004-01-07 at 06:34, Mark Crispin wrote:
> 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
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 5.1.2004, at 08:23, Mark Crispin wrote:
On Mon, 5 Jan 2004, Timo Sirainen wrote:
the problem with traditional UNIX mailbox format is that
shared access itself is a problem
I don't think it's that much of a problem. It may be slow when other
applications modify it though. My plan is:
On Mon, 2004-01-05 at 06:47, Mark Crispin wrote:
> > With mbox this could be done by adding a new header (X-IMAP-Expunged:
> > timestamp).
>
> Indeed, but the problem with traditional UNIX mailbox format is that
> shared access itself is a problem if the messages can move about in the
> mailbox.
On Sun, 2004-01-04 at 18:57, Pete Maclean wrote:
> The only alternatives I see, given the particular constraints upon my
> server, are to behave like the UW server and disallow multiple concurrent
> selections or make a copy of every mailbox as it is selected. However,
> implementing the latter
On 3.1.2004, at 00:43, Mark Crispin wrote:
You will not tempt fate if you either:
. forbid shared expunge
. keep the message text around until the last client that has the
mailbox
open is notified about the expunge
The other strategies tempt fate.
Why subject yourself to the risk, when th
On Fri, 2004-01-02 at 12:47, Christof Drescher wrote:
> >Atomic fetch-and-set of flags is addressed by the CONDSTORE extension,
> >which I understand to have beeen designed for *exactly* the situation
> >you describe.
>
> Might be. I'll have a look at it, but as I read the synopsis, it does
> not
On 2.1.2004, at 12:58, Arnt Gulbrandsen wrote:
I'm currently sending NO, that hasn't caused any problems at least
with
Evolution and OSX's Mail.app.
Actually when I think about it, I'm not sure about that. The condition
is so rare that I can't be sure it has ever happened. It will probably
show
On Fri, 2004-01-02 at 12:25, Arnt Gulbrandsen wrote:
> > Maybe someone could check how most commonly used clients behave with
> > NO vs. BYE? Those are really the only options for most legacy mail
> > stores which don't support delayed expunging.
>
> BYE is simple. All the clients that work well
On Fri, 2004-01-02 at 11:10, Christian Kratzer wrote:
> hmm. But as Christof pointed out sending NO to FETCH response is endorsed
> somewhat by rfc2180 in section 4.1.1. I would expect clients to be
> able to handle this.
Maybe someone could check how most commonly used clients behave with NO
vs.
On Wed, 2003-12-31 at 12:15, Richard Bang wrote:
> Client A connects and does a long fetch of all the flags (takes say 20s)
> Client B connects and does a store 1:* /deleted followed by expunge
> meanwhile Client C connect and does a store 1:* /seen
IMHO, the ideal (not required) behaviour for IMA
On Dec 17, 2003, at 10:48 PM, Mark Crispin wrote:
STATUS is not necessary, and can involve excessive costs. These costs
have nothing to do with new mail. The costs are in STATUS data which,
for
the limited purpose of new mail notification, are frills!
Well, many clients don't really want to kno
On Dec 17, 2003, at 8:05 PM, Lyndon Nerenberg wrote:
Consider a trouble ticketing system that uses an IMAP mailbox as an
input queue for requests. Requests are delivered into the mailbox. On
the other side, n (n > 1) processes retrieve requests from the mailbox
for processing. These processes u
On Dec 17, 2003, at 1:38 PM, Christof Drescher wrote:
Anyway: Do you argue such an extension would not be wise to have?
20 TCP connections might be cheap for CPU and memory, but it also means
more network traffic which might not be nice if your bandwidth costs
per kilobyte (mobile phones).
I'm
On Dec 16, 2003, at 1:02 PM, Christof Drescher wrote:
If this is the case, then what is the purpose of RECENT anyway?! What
do
clients do if they get RECENT messages (and I mean what do existing
clients
do "more" at RECENT in comparison with EXISTS only)? For me as a client
user, the "interestin
On Sun, 2003-12-14 at 15:06, DINH Viet Hoa wrote:
> the STATUS command SHOULD NOT be used on the currently selected mailbox.
>
> I do not see why it exists since the following statement exists :
One problem is at least recent-counter. Do you return the number of
\recent messages as seen by the cu
On Dec 8, 2003, at 5:18 PM, Antonio Cambule wrote:
Have you considered outsourcing an IMAP server for your software?
Several people, including the Cyrus project and Maclean Sofware, offer
suitable software.
Seehttp://www.maclean.com/imap/home.html, for example.
Thanks for that site I'll show i
On Dec 4, 2003, at 9:27 PM, Mark Crispin wrote:
1) Do nothing. IMAP client implementors are put on notice that servers
which unilaterally recycle keywords (including in a session) may
happen
someday, and that client code which doesn't handle this is broken.
I vote this, with the restrictio
On Dec 3, 2003, at 2:10 PM, Andreas Aardal Hanssen wrote:
This is some of the messages from my attempt at posting the sequence
set
bug. I gave a live example, referred to the RFC, and politely stated
that
there is a bug here that should be fixed. I should never have used
Outlook
Express as the
On Mon, 2003-11-24 at 22:10, Mark Crispin wrote:
> > Well, one possibly useful field would be References header in
> > message/rfc822 body parts.
>
> That's not a BODYSTRUCTURE issue; it is an ENVELOPE issue.
FETCH ENVELOPE can be easily worked around with FETCH[HEADER.FIELDS
(whatever you want)]
On Mon, 2003-11-24 at 20:51, Mark Crispin wrote:
> On Mon, 24 Nov 2003, Timo Sirainen wrote:
> > Anyway, the long repeated BODY[...] texts in replies probably eat away
> > all potential bandwidth savings, but it would allow interested clients
> > to fetch some extra MIME field
On Mon, 2003-11-24 at 20:25, Mark Crispin wrote:
> On Mon, 24 Nov 2003, Timo Sirainen wrote:
> > > After the fetch of BODY[STRUCTURE], the client can fetch the HEADERs it
> > > wants in the MIME sub-messages, don't you think so ?
> > Well, something like that. All
On Mon, 2003-11-24 at 16:45, DINH Viet Hoa wrote:
> > The point was that it could replace BODY and BODYSTRUCTURE fetches
> > completely by allowing client to say exactly what fields it needs, not
> > some specific fields forced by protocol which may be more or less than
> > needed by the client.
>
On Sun, 2003-11-23 at 19:34, Arnt Gulbrandsen wrote:
> DINH Viet Hoa writes:
> > Timo Sirainen wrote :
> >> FETCH BODY.PEEK[*.HEADER.FIELDS (...)] would be a nice addition.
> >
> > what do you mean by BODY.PEEK[*.HEADER.FIELDS (...)] ? I can't see
> >
On Tue, Nov 04, 2003 at 12:46:47PM -0500, Paul Jarc wrote:
> I'm writing an entirely read-only IMAP server; it's mainly intended
> for serving mailing list archives. Just like a web archive, it lets
> anyone in (PREAUTH greeting),
Many clients don't understand it and will try to login anyway. I'm
On Sat, Nov 01, 2003 at 03:36:11PM -0800, Vladimir A. Butenko wrote:
> Speaking of CAP, it's not suitable for today groupware in any case. I do
> not know if they have changed that, but what about calendaring items with
> attachments? It's quite a common thing when you send an invitation with an
On Fri, Oct 31, 2003 at 12:36:25PM -0800, Vladimir A. Butenko wrote:
> * LIST (\Class("IPF.Appointment") \UnMarked) "/" Calendar
> * LIST (\Class("IPF.Contact") \UnMarked) "/" Contacts
> * LIST (\Class("IPF.stickyNote") \Marked) "/" Notes
> * LIST (\Class("IPF.Task") \UnMarked) "/" Tasks
> What i
On Fri, Oct 31, 2003 at 03:12:54PM +0100, Arnt Gulbrandsen wrote:
> Richard Bang writes:
> >IMAP is great for sharing of folders but really needs a defined
> >mechanism for handling data objects that can change.
>
> Yes, and it's called ACAP. It's a companion protocol. (See the IMAP,
> IMSP and
On Fri, Oct 31, 2003 at 10:27:22AM -, Richard Bang wrote:
> > > MODIFY id {size} data
> > Like Arnt said, this won't happen. I don't think it's much of
> > a problem just
> > to do this with APPEND + EXPUNGE.
> >
> Imagine I have an organisation with a 1000 people and each of them has a
> share
On Fri, Oct 31, 2003 at 08:00:36AM +0100, DINH Viet Hoa wrote:
> > Hmm. Maybe it'd work just as well without the virtual trashcan if everything
> > else was there :) Currently I'm just annoyed at seeing the deleted messages
> > there so I expunge them immediately (and sometimes wish I hadn't), but
On Thu, Oct 30, 2003 at 11:07:16AM -0800, Mark Crispin wrote:
> Many clients wish to present a "trashcan" type graphical model, and expect
> the server to implement that model by means of a "Trash" or "Deleted
> Items" mailbox. That is, instead of treating the "trashcan" as a client
> based graphi
On Thu, Oct 30, 2003 at 09:43:57AM -, Richard Bang wrote:
> Could this not be resolved cleanly and made a little more general
> purpose in the next revision of imap.
>
> The SELECT could have a TYPE response
>
> TYPE = MAILSTORE | ICARD | ICAL | DOCUMENT
>
> Thus
> SELECT addressbooks/fred
>
On Monday, Sep 15, 2003, at 20:35 Europe/Helsinki, Ken Murchison wrote:
I would have the server return all the decodeable parts, and return a
NO
[UNKNOWN-CTE]. From that the client should be able to figure out
what's going
on and act appropriately.
In this case, should the server omit the BINARY
On Tuesday, Sep 16, 2003, at 18:38 Europe/Helsinki, Mark Crispin wrote:
On Tue, 16 Sep 2003, Ken Murchison wrote:
Wouldn't the client know that the name exists from the output of:
x LIST "" %
* LIST (\Noselect) "." "foo"
That's the point. The client would have to do that extra LIST.
The presumpt
On Tuesday, Sep 16, 2003, at 17:31 Europe/Helsinki, Mark Crispin wrote:
On Tue, 16 Sep 2003, Arnt Gulbrandsen wrote:
Agreed. What is being discussed is whether INBOX/ must also be
returned.
Well, is there anything that says it must? I find no wording to
that effect.
This is what Rob has been sa
On Tue, 2003-09-16 at 00:59, Ken Murchison wrote:
> > Looks like Cyrus just creates a normal selectable mailbox with "CREATE
> > mailbox.". I guess there haven't been much complains about that, so I'll
> > do that as well.
>
> I don't believe that is correct. You can create foo.1.2 without foo or
On Tue, 2003-09-16 at 00:21, Mark Crispin wrote:
> OK, I understand now. And without some registry of names, there's no good
> way to create foo.1. without creating foo.1, and you'd have to have a
> placeholder if there is no foo.1.2 (or other child). That may be hard to
> do.
I think you meant
On Mon, 2003-09-15 at 22:53, Mark Crispin wrote:
> > > IMHO, a Maildir type structure should never use \NoSelect except in
> > > LSUB.
> > And if a mailbox with children is deleted.
>
> Is there such a concept in Maildir? Doesn't the fact that the directory
> exists mean that it's valid? Or do y
On Mon, 2003-09-15 at 22:37, Mark Crispin wrote:
> On Mon, 15 Sep 2003, Ken Murchison wrote:
> > What is the meaning of BINARY[]?
>
> I think that it should be a syntax error, but unfortunately the
> section-binary rule in RFC 3516 is:
>section-binary = "[" [section-part] "]"
> instead of:
>
On Monday, Sep 15, 2003, at 20:12 Europe/Helsinki, Mark Crispin wrote:
IMHO, "foo" and "foo/" should be treated as equivalent in all cases
except for CREATE.
I've just returned NO to all such requests.
I don't think that your server should do that.
Looks like that's what your server does too. Or d
On Monday, Sep 15, 2003, at 20:12 Europe/Helsinki, Mark Crispin wrote:
Or if mailbox can contain children but currently doesn't, should list
"" mailbox/% show anything?
Yes, it should show the mailbox.
What about:
x list "" */%
Should it list all \NoInferiors mailboxes twice, once as "mailbox" a
On Monday, Sep 15, 2003, at 19:48 Europe/Helsinki, Mark Crispin wrote:
In the case where foo has children (which was Timo's question), that
makes
sense. But what if foo does not have children?
If the server doesn't list "foo/" in that case, then it's saying that
the
hierarchical name foo doesn
On Monday, Sep 15, 2003, at 19:49 Europe/Helsinki, Mark Crispin wrote:
On Mon, 15 Sep 2003, Timo Sirainen wrote:
Actually another question about that: Should "foo/" be listed if "foo"
doesn't actually exist, but it has children?
What do you mean? How does this differ fr
On Monday, Sep 15, 2003, at 19:14 Europe/Helsinki, Arnt Gulbrandsen
wrote:
Timo Sirainen writes:
If I send:
x LIST "" foo/%
and "foo" is a selectable mailbox with children, should the reply
contain \NoSelect flag for "foo/" entry? ie. are the flags for &qu
If I send:
x LIST "" foo/%
and "foo" is a selectable mailbox with children, should the reply
contain \NoSelect flag for "foo/" entry? ie. are the flags for "foo"
mailbox, or (invalid) "foo/" mailbox?
--
-
For information about th
On Wed, 2003-09-10 at 00:47, Dilip Menon wrote:
> When I design an IMAP server to accept smtp address what should the length
> be?
Just IMHO: You shouldn't hardcode limits for things which don't really
need limiting. I don't see any point in limiting mail addresses when
reading them, except maybe
On Mon, 2003-09-08 at 16:07, David Harris wrote:
> > If you do this, then surely you should do the same for invalid Date:
> > headers, invalid addresses in From:/To:/Cc: headers, etc?
>
> If a side-effect is that the mail client used by something like 80% of all
> Internet users messes up and sta
(listproc complained about the first word beginning with SEARCH, now it
doesn't)
SEARCH BODY and TEXT isn't really well defined regarding how they're
supposed to handle multipart messages. There's a comment that servers
may exclude non-text parts, so they're not always required to do exact
text ma
On Wednesday, Aug 13, 2003, at 23:15 Europe/Helsinki, Lyndon Nerenberg
{VE6BBM} wrote:
What I was actually trying to get at is this: should the server set
the \Seen flags for messages for which it has returned data or not?
Yes, it should.
Better question is should it set \Seen flag for message
On Thursday, Aug 14, 2003, at 21:09 Europe/Helsinki, Larry Osterman
wrote:
I did say that most of these features are available with extensions,
didn't I?
Yes, but I just had to comment on them :)
Please, I'm not trying to start an Exchange protocol vs IMAP protocol.
Me neither. My point was most
On Thursday, Aug 14, 2003, at 18:56 Europe/Helsinki, Cyrus Daboo wrote:
I don't want to start a flame war of any kind but I think the
following quote (which I saw quoted on comp.mail.imap) deserves some
response from the IMAP community, if only to re-evaluate IMAP's
strengths and weaknesses:
"
On Thursday, Aug 14, 2003, at 20:03 Europe/Helsinki, Larry Osterman
wrote:
The Exchange protocol is orders of magnitude richer than IMAP, but it's
not standard (which is why it's totally proprietary :)).
Well, sure. I was mostly thinking about the mail-receiving part of
Exchange protocol. IMAP o
On Monday, Aug 4, 2003, at 23:29 Europe/Helsinki, Larry Osterman wrote:
My inbox also has lots of unseen messages, I feel your pain :)
I think you're right - the protocol behavior change you are proposing
(to change the behavior of the \Recent flag to be more "persistant") is
almost certain to br
On Mon, 2003-08-04 at 22:26, Larry Osterman wrote:
> Several people have pointed out in the past that the \Recent flag
> doesn't work when you have more than one client accessing a mailbox
> simultaneously, you've just pointed out another problem where this
> occurs.
What other problems are there
A month ago here was this discussion about new mail notification in
mailboxes. I started thinking about it some more how I'd want the
client's user interface to behave.
Recent counters are actually quite good. They do exactly what I want,
but only as long as there's only one client having mailboxe
On Wed, 2003-07-16 at 22:53, Mark Crispin wrote:
> It is a reason to say "I don't want to have garbage-collection depend upon
> exclusive access." If so, then you need a more complex mechanism than is
> used in UW imapd's mbx driver.
rename(). You rewrite the file and rename it over the old one.
On Wednesday, Jul 16, 2003, at 21:46 Europe/Helsinki, Mark Crispin
wrote:
Expunge requires exclusive acquisition of the access lock. Should this
be achieved, opens are blocked until the expunge finishes.
Otherwise, the expunged messages are marked with an internal flag (not
visible to the client
On Wednesday, Jul 16, 2003, at 19:27 Europe/Helsinki, Steve Hole wrote:
If you ever want to implement the CONDSTORE extension, then it is
probably
a good idea to put the effort into atomicity. Basically you will
have to
implement write locking mechanisms in your store.
Sure, write locking woul
On Wed, 2003-07-16 at 11:03, Arnt Gulbrandsen wrote:
> Gangadhar Mylapuram writes:
> > Hi everybody,
> >
> > For IMAP online model, whether client has to maintain connection
> > untill user closes the application or every time it has to establish
> > connection for user request?
> >
> > If connec
On Wed, 2003-07-16 at 06:16, Mark Crispin wrote:
> One way to avoid this is to make the flag list be a single token. For
> example, represent the flags as bit vectors which are updated in a single
> write operation. The system flags are 6 bits, and if you allow up to 26
> keyword flags you can fi
I'm wondering if there's any problems with creating a message store that
doesn't support atomic changing of multiple message flags. I don't think
IMAP spec itself requires it, but are there any clients relying on this?
If I did it, would it badly break some things? Or in general, is it a
bad idea?
On Tue, 2003-07-15 at 21:49, Tim Showalter wrote:
> Larry Osterman wrote:
>
> > The server respond with:
> > S: * 1 FLAGS (\Seen)
> > S: 1 OK Fetch completed
>
> > As opposed to failing the STORE.
>
> Cyrus will fail the store. This has always been its behavior (as far as
> I can remember). M
On Tue, 2003-07-15 at 01:34, Larry Osterman wrote:
> There are clients out there (I believe
> PINE is one of them, I know that Outlook Express is another) that
> require flags updates on read-only mailboxes, and if you carefully read
> the spec's language on READ-ONLY and FLAGS, it's clear that the
On Saturday, Jul 12, 2003, at 06:36 Europe/Helsinki, David Harris wrote:
I would strongly urge server implementers to
look beyond merely caching references headers, and to come up with
smart caching of the actual thread tree structure itself.
As Mark pointed out in his reply to me, the addition of
On Saturday, Jul 12, 2003, at 00:32 Europe/Helsinki, Ralph Dratman
wrote:
I subscribed to this list in hopes of getting help with an operational
problem in imap-uw 2002c1 on FreeBSD 4.7 ...
... but now I see that this list is for developers.
How did you find this list? Links in www.washington.e
On Friday, Jul 11, 2003, at 17:49 Europe/Helsinki, Cyrus Daboo wrote:
I would like to see Alexey's document recommend a best practice for
naming of keywords in the 'private' area to avoid namespace problems:
specifically a 'vendor.productid.xxx' convention.
This brings to my mind, is there any r
On Friday, Jul 11, 2003, at 14:21 Europe/Helsinki, Edward Hibbert wrote:
- You have a mailbox selected on one session containing 2 messages.
- 3 messages are APPENDed, and 1 of them expunged by another session.
- The first session issues a NOOP.
What notifications should it get back? I can think
On Thu, 2003-07-10 at 17:16, Andreas Aardal Hanssen wrote:
> >I don't really see where the problem is. Both client and server have to
> >know what messages map to which sequences and they have to be fully
> >synced all the time. If client requests sequences which don't exist, or
>
> No, they are n
On Thu, 2003-07-10 at 12:22, Arnt Gulbrandsen wrote:
> C: c uid search (or 1 3) from larryo
> S: 2 expunge
> S: * search 1
> S: c ok
>
> Is this even legal? I don't see anything to forbid it. But I also don't
> see which message set is searched: uids 1 and 3 or uids 1 and 4?
Well, that is kind o
On Thu, 2003-07-10 at 11:07, Andreas Aardal Hanssen wrote:
> >> Is there anything in the client's behavior that deserves a BAD response?
> >No, since the EXPUNGE hasn't taken effect in that session yet.
>
> This is exactly my point. How is the server to decide wether there is a
> bug in the client
On Thu, 2003-07-10 at 00:34, Larry Osterman wrote:
> There is clearly something wrong with a client specifying an invalid
> message sequence number in a fetch (since the client knows at all times
> the number of messages in a mailbox), but that does not necessarily hold
> true for search (although
Giving out of range sequence set for FETCH returns BAD error with most
IMAP servers, but why not with SEARCH? Is there a reason, which I can't
see in RFC, or is it just lack of error detection?
--
-
For information about this maili
On Tue, Jun 24, 2003 at 09:48:36AM -0700, Gangadhar Mylapuram wrote:
> 4. I will first search for the message number based on header information.
> Then i will retrieve the message text from the server based on message
> number. I will store this information on temporory memory, i will parse
> this
On Mon, 2003-06-23 at 23:58, Mark Crispin wrote:
> On Mon, 23 Jun 2003, Timo Sirainen wrote:
> > Or actually .. UW-IMAP + mbox seems to set mailbox \Unmarked even if I
> > do only STATUS for it. That wouldn't work well. Is it even
> > RFC-compliant? :)
>
> What ve
On Mon, 2003-06-23 at 22:19, Timo Sirainen wrote:
> On Mon, 2003-06-23 at 21:43, Mark Crispin wrote:
> > On Mon, 23 Jun 2003, Timo Sirainen wrote:
> > > If you also send notifications for "some client selected mailbox xyz",
> > > that could be used to reset
On Mon, 2003-06-23 at 21:43, Mark Crispin wrote:
> On Mon, 23 Jun 2003, Timo Sirainen wrote:
> > If you also send notifications for "some client selected mailbox xyz",
> > that could be used to reset the "contains new mail" flag. I think that
> > would mak
On Mon, 2003-06-23 at 20:27, Mark Crispin wrote:
> > > Does it really matter to a client if there are 44 new messages or 51 new
> > > messages? Does it really matter to an end user?
> > No, but it matters that user knows that there actually are new mails.
>
> Exactly! So you don't really need ST
On Mon, 2003-06-23 at 19:11, Mark Crispin wrote:
> > Anyway, I think the nicest way to do this would be
> > to tell server to send standard untagged STATUS replies for specified
> > folders.
>
> That would be very expensive with some mail stores. STATUS requires
> values that *may* be in mailbox
On Mon, Jun 23, 2003 at 10:10:59AM +0100, Richard Bang wrote:
> A new command set MONITOR and UNMONITOR would solve this as it would
> allow my client to be notified of any mailbox it were interested in.
I've suggested similiar commands before.. And Mark was also planning some
"new mail" notificat
1 - 100 of 191 matches
Mail list logo
