On Fri, Jan 10, 2003 at 10:46:08PM -0500, Lawrence Greenfield wrote:
Is there anyone who wants to speak up in favor of using Subject in
threading?
Yes. Outlook creates only In-Reply-To header, not References. Since I don't
store my self-written mails into inbox, in-reply-to points to
How exactly should SEARCH CC, BCC, FROM and TO match the strings? Spec says
contains the specified string in the envelope structure's CC field, but
envelope has it split into multiple fields.
UW IMAP seems to match it directly with the non-parsed header field. Is that
required, or can other
On Mon, 2003-01-13 at 17:42, Mark Crispin wrote:
On Mon, 13 Jan 2003, Timo Sirainen wrote:
How exactly should SEARCH CC, BCC, FROM and TO match the strings? Spec says
contains the specified string in the envelope structure's CC field, but
envelope has it split into multiple fields.
UW
On Wed, 2003-01-15 at 18:18, Mark Crispin wrote:
On Wed, 15 Jan 2003, Timo Sirainen wrote:
Well, UW imapd isn't the only one supporting mboxes anymore. I'm writing
a server that supports multiple mailbox formats, using index files to
make accessing them quite fast.
Ah, but do you support
On Sun, 2003-01-19 at 23:30, Andreas Aardal Hanssen wrote:
Like I said, I don't see any requirement for UIDVALIDITY to _grow_. It
has to be _different_.
If unique identifiers from an earlier session fail to persist to this
session, the unique identifier validity value MUST be greater than
On Fri, 2003-01-24 at 13:38, Arnt Gulbrandsen wrote:
One of these two strategies is right. The other is arguably wrong, but
perhaps more practical in today's internet.
1. Convert a newline and all following whitespace into a single ASCII 32.
2. Remove a newline and one following whitespace
On Tue, 2003-01-28 at 00:22, Mark Crispin wrote:
What should the client do if the server fails to return an untagged FETCH
response from STORE?
..
Nevertheless, since the server should have sent the untagged FETCH
response, a cautious client would assume that the state of the flags is
Since the previous thread seems to have died without agreed solution,
let's try again :)
I don't think it's such a good idea to deprecate RENAME entirely like
Mark wants. Doing it with copy+expunge would require user to have enough
quota for a copy of the mailbox (doing it in smaller blocks would
On Tue, 2003-01-28 at 02:24, Cyrus Daboo wrote:
The only caveat is for servers that do not use timestamps for UIDVALIDITY.
In that case those servers would have to ensure that the new UIDVALIDITY is
greater than any UIDVALIDITY for mailboxes that may have previously existed
with any of the
On Tue, 2003-01-28 at 03:12, Cyrus Daboo wrote:
| What happens if the UIDVALIDITY of an inferior name can't be changed,
| such as when ACLs prohibit it or if there's a loop in the hierarchy tree?
|
| Fail the whole operation?
No - rename succeeds but there is no tagged NEW-UIDVALIDITY
On Tue, 2003-01-28 at 06:43, Pete Maclean wrote:
Would you consider these clients broken?
I deem Outlook Express to be considerably broken. I have come across many
problems with it including one of a similar nature: it insistently tries
to delete messages, that is do STORE n +FLAGS
On Tue, 2003-01-28 at 07:58, Mark Crispin wrote:
On Mon, 28 Jan 2003, Timo Sirainen wrote:
It's a bit sad that almost all IMAP clients are broken, more or less.
Pine isn't. :-)
Yes, maybe without it I wouldn't have bothered to add the almost word.
Maybe mutt isn't broken either? Just
On Tue, 2003-01-28 at 09:22, Mark Crispin wrote:
On Mon, 28 Jan 2003, Timo Sirainen wrote:
Multiple
connections eat more memory and more network resources.
How did you arrive at this conclusion? I suggest that you have fallen
prey to an urban myth. Like most myths, there is a vestige
On Tue, 2003-01-28 at 09:42, Mark Keasling wrote:
x RENAME foo bar
x OK [NEW-UIDVALIDITY 123456] Renamed.
This is not as useful as you may think. If the UIDVALIDITY is changed what
prevents the server from changing the UIDs as well. Just getting the UIDVALIDITY
is not sufficient.
It
On Tue, 2003-01-28 at 09:51, Mark Crispin wrote:
On 28 Jan 2003 09:50:53 +0200, Timo Sirainen wrote:
With stateful firewalls or NATs each connection would require at least
some memory and CPU. I didn't mean they'd necessarily cost much, but
they're not free either.
I do not believe
On Tue, 2003-01-28 at 09:52, Mark Keasling wrote:
This is not true. The UIDVALIDITY must be only be different.
Only servers that can not preserve UID values between sessions are required to
use ascending uidvality values.
No, read more carefully:
If unique identifiers from an earlier
On Tue, 2003-01-28 at 22:44, Larry Osterman wrote:
Actually, the implementations that treat subscribed as an aspect of a
mailbox are broken. The spec explicitly requires that you be able to
subscribe to non-existant mailboxes, if subscribed is an attribute of
the mailbox, then you can't do
On Wed, 2003-01-29 at 08:18, Mark Keasling wrote:
What is needed is an easy way for the server make the unique identifier
guarantee while still permitting the user to rearrange things. A mailbox
name is not a guaranteed unique identifier. It should be removed from
the unique identifier
On Tue, Jan 28, 2003 at 11:11:24AM +0100, Arnaud Taddei wrote:
Me neither. My only point was that using STATUS to constantly check for
new mails in multiple mailboxes is less resource (cpu, memory, network)
intensive than using multiple connections with some server
implementations.
Servers
On Wed, 2003-01-29 at 14:05, Mark Keasling wrote:
You're forgetting the most important problem: backwards compatibility.
Introducing a new identifier wouldn't help at all if the clients didn't
support it.
I don't believe I'm forgetting anything...
Adding something to the protocol does
On Sat, 2003-02-08 at 02:14, Mark Crispin wrote:
The other choices are CRAM-MD5, DIGEST-MD5, which basically involve
storing plaintext equivalents of the authentication credentials on the
server.
DIGEST-MD5 stores MD5 sum of user:realm:password on server, which I
wouldn't call plaintext
On Mon, 2003-02-10 at 20:50, John Doty wrote:
It seems exceptionally bogus that outlook would just not work on a system
without IDLE.
My server doesn't support IDLE and I haven't seen any problems with
Outlook.
(After outlook does not get a response from my server, it
pops up a dialog box
Must parent mailboxes be listed before their children? I don't see this
defined anywhere, but I know some clients will break if they're not.
Requesting LIST mail/% from UW imapd shows also mail/ in the reply,
is this required? I think this falls into the server implementations
are permitted to
On Wed, 2003-02-19 at 01:42, Mark Crispin wrote:
On Tue, 19 Feb 2003, Timo Sirainen wrote:
Must parent mailboxes be listed before their children? I don't see this
defined anywhere, but I know some clients will break if they're not.
There is no such requirement; and clients which presume
..a server MAY begin processing another command before processing the
current command to completion..
I hope that doesn't mean that it can send anything back to client before
other commands have been processed?
--
-
For
On Fri, 2003-02-21 at 01:56, Mark Crispin wrote:
On Thu, 21 Feb 2003, Timo Sirainen wrote:
..a server MAY begin processing another command before processing the
current command to completion..
I hope that doesn't mean that it can send anything back to client before
other commands have
I can think of only two reasons why clients still need to bother
rememebering sequence numbers instead of using only UIDs: untagged FETCH
replies updating flags and EXPUNGE replies.
So, how about defining a new extension to give client also the UID in
both of them? FETCH would be easy to just
On Fri, 2003-02-21 at 08:17, Mark Crispin wrote:
On Thu, 21 Feb 2003, Timo Sirainen wrote:
I'd like to know how you can make a client efficiently handle sequence
numbers. If internal message structure contains just the sequence
number, it has to be updated every time an older message
On Fri, 2003-02-21 at 17:33, Simon Josefsson wrote:
Not really, why would you _need_ to get a list of all messages? Client
can request the messages from server only when they become visible in
screen. Scrollbar sizes and such can be generated from just the total
amount of messages. Before
On Tue, 2003-02-25 at 20:42, Mark Crispin wrote:
If there's no charset in Content-Type, I don't send it. uw-imap seems to
send us-ascii if content-type is text/*.
There is no such thing as a standards-compliant message without a charset
that is not also US-ASCII.
But is there a reason to
On Wed, 2003-02-26 at 02:56, Rick Block wrote:
Does anyone know of a cross listing of imap4 extensions
and the clients that implement them? I'm aware of Alexey
Melnikov's extremely useful pages at
Even better if such list would also contain list of known bugs that the
client has with it's
Just a thought - anyone else interested about this?
Paperclip icon indicating attachment can be pretty useful and many
clients want it, but figuring out if it should be put there requires
fetching BODY or the whole message. So how about giving client a few
hints about that?
FETCH .. (FLAGS
On Tue, 2003-03-04 at 18:21, Steve Hole wrote:
That's what I meant with fetching BODY, except I remembered BODY was
enough. But still, fetching BODYSTRUCTURE is pretty much useless
cpu/bandwidth usage just for one paperclip icon.
No, it's not.
A well written client should fetch
On Tue, 2003-03-04 at 20:04, Lawrence Greenfield wrote:
This would be stupid for any client to do.
1 FETCH 1:30 (ENVELOPE BODYSTRUCTURE)
2 FETCH 20 BODY[1]
is considerably more efficient. Either the user asks for other
messages or they don't; you're no worse off since the extra data
On Wed, 2003-03-05 at 00:25, Larry Osterman wrote:
Outlook and OE for example don't want BODY, BODYSTRUCTURE or ENVELOPE.
Caching any of them for these clients is just waste of disk
space and disk I/O.
Don't use Outlook/OE as examples. They're really POP3 clients on
steroids as opposed
On Wed, 2003-03-05 at 01:46, Larry Osterman wrote:
You're missing my point.
This mailing list is about the PROTOCOL. Discussions should be about
are about what's best for the clients that are engineered to use the
protocol and the servers that implement, not for those that are using
On Sat, 2003-03-08 at 14:52, Abhijit Menon-Sen wrote:
(Maildir and IMAP are not ideally suited to each other. For details, see
http://www.washington.edu/imap/IMAP-FAQs/index.html#6.9)
I know of only two problems with it:
1. RENAME INBOX can't be made atomic with Courier-style directory
On Sat, 2003-03-08 at 19:47, Andreas Aardal Hanssen wrote:
2. There's a small possibility of temporarily losing mails if it's flags
keep changing (ie. the filename changes) while the directory is being
scanned. Although this also depends on how filesystem's readdir()
handles renames.
Why
On Sat, 2003-03-08 at 20:57, Andreas Aardal Hanssen wrote:
If renaming a file when a readdir is in progress causes that file (inode)
to be skipped, then the OS is IMO broken! ;) readdir just scans through
the list of files in a directory. The name of the file when it is stored
in the same
On Wed, 2003-03-05 at 11:57, Mark Crispin wrote:
If two sessions have SELECT the same folder and a new message arrives, only
the first to report the new message(s) with EXISTS and RECENT will see them as
recent. The other will get a non-zero EXISTS, but a RECENT count of 0 (with
*any* IMAP
On Mon, 2003-03-10 at 20:14, Joseph S Barrera III wrote:
Cyrus Daboo wrote:
| Am I making this too complicated? Surely every imap implementor
| has faced this issue. Do people live with O(n) deletes, or
| am I missing something?
Most do.
Either use a Hashtable with UID as the key and
On Tue, Mar 11, 2003 at 01:59:26PM +, David Woodhouse wrote:
Well, even though the server is already permitted to send unsolicited
STATUS 'replies', the client would need to know that the server _will_
do so, hence that the client doesn't need to keep polling.
Well, yes. The reason I want
On Tue, Mar 11, 2003 at 03:58:55PM +, David Woodhouse wrote:
But I'm still the wrong end of a 64K ISDN line and even now, with
negligible time actually taken by the _server_ the round-trip time for
40-odd STATUS commands is enough to annoy me.
That could be fixed by sending all the STATUS
On Wed, Mar 12, 2003 at 05:45:25PM -0700, Alexey Melnikov wrote:
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build
On Thu, Mar 13, 2003 at 04:04:56PM +, David Woodhouse wrote:
I mentioned earlier. Instead of storing it for each message, I'd use my
existing transaction log file to remember last few changes. MODSEQ would be
last_MODSEQ + position in log file. MODSEQ of messages not in log file
would
On Thu, Mar 13, 2003 at 06:18:43PM +0200, Timo Sirainen wrote:
If you do this, you'll need to fix up the case where there's a single
client and it's the only one making changes to the folder.
I'm not sure what you mean.
OK, I now I get it :) Yes, it would prevent client from caching
On Tue, 2003-03-18 at 20:16, Alexey Melnikov wrote:
Also do you really have to return MODSEQ messageset for each SEARCH and
SORT? You're just returning the search results twice. Why not add the MODSEQ
into the untagged reply itself? ie. * SEARCH 1 2 4 10 (MODSEQ 123). Since
client
On Wed, 2003-03-19 at 09:43, John Milan wrote:
This is exactly why I raised my initial objection, and after discussing
this with Mark, he and I agree that messages that are modified in any way
that would cause a modification of the ENVELOPE or BODYSTRUCTURE are
different messages, and thus the
On Wed, 2003-03-19 at 19:03, John Milan wrote:
Well, I think what makes IMAP really interesing is its extended session.
Consider the IDLE command, this is really making use of an active connection
to send new events. This is quite powerful and used to good effect as a
means to immediately
On Thu, 2003-04-03 at 00:50, Mark Crispin wrote:
Except for the ones that break if it is done. Evolution at least breaks
if it sees untagged reply instead of + after it has sent APPEND.
If Evolution does that, then it is broken.
Yeah, it is. Too many IMAP clients are.
OE also breaks if
On Thu, 2003-04-03 at 05:55, Mark Keasling wrote:
The way my server does it is that it accepts UIDs even for messages that
client hasn't been notified yet, but '*' in messagesets still refers to
the last notified message.
This behavior will cause more harm than good.
In what way? It
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
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 metadata
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 version?
Tested with 2003.337 and 2002c
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
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 the
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 of
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 not
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 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
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
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
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 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). Mirapoint's
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 fit
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 connection fails in
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
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
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
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
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
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
(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
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 starts
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
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 this
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 foo
mailbox, or (invalid) foo/ mailbox
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 from foo being \NoSelect?
I
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
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 and
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 did
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: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
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
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 presumption
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
Could
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 I'm
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
shared address
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 is the general
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 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
what is exactly missing.
Suppose you have a multipart
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 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 that should be needed is IDs for each
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 fields without extra round trips
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
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 interesting
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 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
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 IMAP
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.
1 - 100 of 133 matches
Mail list logo
