On Tue, 16 Jul 2003, Timo Sirainen wrote:
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
On Mon, 14 Jul 2003, Tim Showalter wrote:
(1) The \Seen flag was changed by FETCH [seq] (FLAGS BODY[]
INTERNALDATE) while the mailbox was being EXAMINEd. \Seen is not
advertised in PERMANENTFLAGS in EXAMINE, but the change appears
permanent.
From RFC 3501, 6.3.2:
The
On Mon, 14 Jul 2003, Tim Showalter wrote:
As a result of the above, FETCH seq (FLAGS BODY[] FLAGS) is equivalent
to FETCH seq BODY[].
This ought to be the case, but it isn't, because it doesn't consolidate
and it doesn't notify. The FETCH response, in fact, is of the form
FLAGS () BODY []
On Fri, 11 Jul 2003, Andreas Aardal Hanssen wrote:
Can the client assume anything about the UID in this last example?
No.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
On Thu, 10 Jul 2003, Alexey Melnikov wrote:
We can't standardize Junk and NotJunk; they are in the wrong namespace.
As $ convention was never documented, I don't see this as a problem.
If both clients use the keywords in the same way, Junk/NoJunk versa
$Junk/$NoJunk is just an
On Fri, 11 Jul 2003, Pete Maclean wrote:
I ask this question not to be picky but because my IMAP server will, in
certain circumstances, send redundant EXISTS responses. And I have never
seen any problem because of this. Now I am wondering if this is something
one should be careful to avoid.
On Fri, 11 Jul 2003, Edward Hibbert wrote:
server ought to maintain the validity of the sequence numbers that it knows
a client has seen on a session, until it has told the client to change them
via untagged responses?
Not ought. MUST.
Do servers generally do that?
A server that does not
On Fri, 11 Jul 2003, Edward Hibbert wrote:
Or are sequence numbers just inherently untrustworthy when you have multiple
access going on, and everyone should really use UIDs?
Within a session, sequence numbers are absolutely, 100% trustworthy. This
is even more trustworthy than UIDs, which can
On Fri, 11 Jul 2003, Lyndon Nerenberg wrote:
Make sense? If so, I'll put together a draft to create the flag
registry.
I think that your proposal is an excellent idea, and that you should start
of the document immediately.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge
On Fri, 11 Jul 2003, Cyrus Daboo wrote:
Right - we still use the ACAP vendor registry for the actual vendor token
but there would be no 'vendor.' prefix in the keyword.
PS We should probably choose something other than '%' for this since that
would be a little ugly with ANNOTATE. Any of '#',
On Fri, 11 Jul 2003, Ralph Dratman wrote:
My problem is that I cannot fetch mail, and keep getting log entries
that look like
imapd[12345]: Login disabled user=joe auth=joe host=abc.def.com
Did you read the release notes, most importantly for the imap-2002 base
release (28 October 2002)?
I'm sympathetic to the idea of an [EXPENSIVE] response code; but (alas!)
my experience suggests that the majority of clients would not utilize such
a feature to change strategy. Probably the only thing that would be done
with it would be to bad-mouth server implementations.
There is a definite
On Fri, 11 Jul 2003, Cyrus Daboo wrote:
Unfortunately I have of late been running more and more into the problem of
users wanting to THREAD very large mailboxes and complaining when it takes
a long time. They are not keen on restricting the input message set to e.g.
just unseen or messages
On Sat, 12 Jul 2003, Ralph Dratman wrote:
In fact, yes, I looked over those notes, and still could not be sure
whether I should enable plaintext passwords. (Being a good and clean
citizen, I didn't particularly want to be non-compliant.)
If you decide to enable plaintext passwords, then
On Thu, 10 Jul 2003, Andreas Aardal Hanssen wrote:
What if a client has not done any IDLE or NOOP or anything in 28 minutes,
and in that time 100 messages have arrived and been expunged without the
client getting any notice (perfectly good imap), and our client then
searches for all messages
On Thu, 10 Jul 2003, Lyndon Nerenberg wrote:
Barry, are you planning to issue a revision to RFC 2683? If so, this
whole issue of command pipelines and sequence numbers should be
addressed.
I agree, this needs to be clarified.
Note in 5.5, the text:
[...] Therefore, if
the client sends
On Wed, 9 Jul 2003, Brad wrote:
I am using Red Hat Linux 7.3 as a mail server and Red Hat 9 as one of the
workstations, and I am finding that the imap response time is woefully slow.
Have you read the FAQs in imap-200?/docs/FAQ.txt or
http://www.washington.edu/imap?
If so, did you read FAQ
On Wed, 9 Jul 2003, Timo Sirainen wrote:
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?
The latter (lack of error detection).
It is also possible
I don't want to jump excessively into the fray about keywords. However,
my view:
. being compatible with Bayesian filtering technology is important
. $spam should not be used; SPAM is a trademark of Hormel Corp. (a fine
company) for their highly-addictive lunch meat (which goes quite when
On Thu, 3 Jul 2003, Abhijit Menon-Sen wrote:
At 2003-07-03 09:07:21 -0700, [EMAIL PROTECTED] wrote:
. $spam should not be used; SPAM is a trademark of Hormel Corp. (a
fine company) for their highly-addictive lunch meat (which goes
quite when when consumed with Dom Perignon)
Hormel
On Thu, 3 Jul 2003, Alexey Melnikov wrote:
I believe Junk and NoJunk are in use (no leading $).
Does anybody have any information on how there are used?
Junk and NoJunk without leading $ are ordinary IMAP keywords, and there is
no convention (not even the informal $ one) to preclude any end
On Tue, 1 Jul 2003, Marc Groot Koerkamp wrote:
Can somebody tell me if the following bodystructure (send by
Mercury32 v.3.32.) is a valid bodystructure?
Sure looks wrong to me, for all the reasons you named.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party
On Mon, 30 Jun 2003, Gangadhar Mylapuram wrote:
Is there any file in linux to change to capability list of IMAP server?
Linux is using UW IMAP server.
The capability list is programmed into the software, and matches what the
software does. Why would you want to change it?
-- Mark --
David -
You are correct that UW imapd generates those responses, and has done so
for quite some time before RFC 3501 came out. I have yet to hear of a
single client which misbehaves because of this.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics,
On Mon, 23 Jun 2003, Richard Bang wrote:
Just for my upended worth. My implementation will never return either
/Marked or /Unmarked.
I see. Do you believe that deliberately thumbing your nose at the
protocol, as you say you will do, is the way to build interoperability or
create quality
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 make it pretty much usable.
You already have that ability: that's what \Marked and \Unmarked do!
\Marked
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? What host operating system?
If UW imapd does that, then it is a bug and I will fix it.
On Mon, 24 Jun 2003, Timo Sirainen wrote:
I thought \Marked == atime mtime, \Unmarked == atime = mtime? STATUS
opens the mbox file which updates atime, so how could it even work? You
could fix it with utime() but that'd be ugly and racy.
Surprise. There is quite a bit of such ugliness
On Fri, 20 Jun 2003, Rob Siemborski wrote:
Its also pretty badly defined (the only requirement is that it is returned
for 'interesting' mailboxes, but 'interesting' is never defined in a
solid way, only a suggestion is given).
This is because, many years ago, CMU didn't want to be nailed down
On Fri, 20 Jun 2003, Rob Siemborski wrote:
However, the wording is unfortunate.
OK, I can go along with that.
Was there a reason why you did not bring up this issue when RFC 3501 was
in Last Call?
Will you now propose amended wording for the next revision?
It is very annoying to hear
On Fri, 20 Jun 2003, David Woodhouse wrote:
Indeed it does, and I cannot imagine how a client would actually make
_use_ of it in a way which is useful to the user.
There are two philosophies in writing a client.
One is to write a client which is fast and addresses the 98% case.
The other is
On Fri, 20 Jun 2003, David Woodhouse wrote:
A common behaviour I desire from a client is to find mailboxen which
have new mail. Yet the \Unmarked flag doesn't necessarily indicate that
status. The \Unmarked flag says that no new mail has been delivered
since the mailbox was last SELECTed.
On Fri, 20 Jun 2003, David Woodhouse wrote:
Do we agree that however we define 'new mail', '\Marked' status in most
practical circumstances will mean the same to a client as no status at
all -- it's '\Unmarked' which is the interesting one since it means that
you can skip the folder. Because
On Thu, 19 Jun 2003, Cyrus Daboo wrote:
Actually the STATUS syntax uses 'number' for all the status responses
Sigh. Why wasn't this caught during the many last calls and many months
of review?
I've added this to the RFC 3501 errata list.
-- Mark --
http://staff.washington.edu/mrc
Science
On Thu, 19 Jun 2003, David Harris wrote:
Sorry if this is an FAQ, but is
draft-ietf-imapext-sort-13
still an up-to-date description of the state of the SORT extension?
Yes. Note that it was released just a month ago.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from
(Please note: the [EMAIL PROTECTED] mailing list is for discussions
about the design and specification of the IMAP protocol, as opposed to
questions about specific software implementations. Since you appear to
be using UW imapd, the [EMAIL PROTECTED] mailing list is the
mailing list
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
And it's not a useless scholastic exercise, as - AFAIR - all IMAP-related
changes we did in CommuniGate Pro during the last 24 months were caused by
the fact that our interpretation and, hmm, proper interpretation of the
IMAP standard were
On Tue, 17 Jun 2003, Jason Munro wrote:
I am getting
ready to release a PHP based webmail IMAP client which falls in this
category, however it only connects once per page load. The only solution I
know of to get around this problem for a client written in a language
unable to maintain a
This is not an IMAP server software vulnerability announcement. However,
you should check your systems and make sure that you are not vulnerable to
this attack.
We've recently seen an attack on IMAP servers where the following user
names are tried: root, admin, webmaster, user, test, web, www,
On Fri, 13 Jun 2003, Steve Hanson wrote:
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() 13-Jun-2003 08:48:41 -0500 {1851}
The first and last line are OK. The numbers in the curly braces are
simply the size of the message being
On Wed, 4 Jun 2003, joe ritter wrote:
I would like to implement the latest UW Imap server on
a Solaris 7 machine. Hoever I do not want mail users
to have a shell on the machine. Could somebody explain
how to acomplish this or point me to a resource ont
the web that would outline this
On Sun, 06 Apr 2003 23:02:24 -0400, Cyrus Daboo wrote:
I've seen 'in the wild' keywords such as $Label1, $Label2 etc Since I'm in
the process of adding keyword support and want to have a fixed set of
'labels' that a user can define
client
I think that my correction is
On Fri, 04 Apr 2003 18:07:41 -0800, Chris Newman wrote:
I concur with Larry's opinion on this issue.
That may be, but that does not make it correct.
The entire purpose of NAMESPACE is to...have namespaces! [What a concept!]
Just as the entire purpose of the LIST reference argument is to
There are two parts to the answer.
The first part is that this is a well-known bug in OE. Indeed, it should
not be attempting to fetch UIDs for messages which have not yet been
announced in the session.
The second part is that you can avoid this problem in your server by
immediately announcing
On Wed, 3 Apr 2003, Timo Sirainen wrote:
Nevertheless, the most straightforward workaround for OE's broken behavior
is to immediately announce of new messages; and this is something that is
actually desirable for all clients.
Except for the ones that break if it is done. Evolution at least
On Wed, 2 Apr 2003, Dilip Menon wrote:
But is this not solved by servers announcing untagged responses?
This is a mandatory requirement of IMAP servers.
I am not sure what you are asking.
A server should notice and announce, via untagged EXISTS, the fact that
new mail has arrived; and it
On Thu, 27 Mar 2003 09:38:49 -0800, Bill McCoy wrote:
My requirements include interoperability
with other MUAs
Good.
Similarly, unless I'm missing
something, searching for Message-ID as you suggested is not possible in this
situation: the original message is gone, the edited message of
On Thu, 27 Mar 2003, Bill McCoy wrote:
Normally, MUA edits of a message do not change the Message-ID.
I don't know how to reconcile this comment with the language of RFC2822 as
previously discussed which specifies that a Message-ID ...pertains to
exactly one instantiation of a particular
On Wed, 19 Mar 2003, John Milan wrote:
I would make use of unrequested, untagged server responses carrying flag
information for a particular UID. The client could receive, at any time, the
following:
S: * 23 FETCH (FLAGS (\Unseen))
Presumably you mean
S: * 23 FETCH (FLAGS ())
The newer mailutil program (part of imap-2002 and later versions) has an
option to delete messages from the source as part of a copy. The imap-utils
are for the most part obsolete.
On Thu, 13 Mar 2003, Tomki wrote:
What is the proper method to get mailutil to work properly on a mailbox
which has spaces in the name? I've tried several combinations, with no luck.
mailutil copy -verbose Kit Wetzler #driver.mbx/Kit Wetzler2
Can't open mailbox Kit Wetzler: no such mailbox
On Wed, 12 Mar 2003, David Woodhouse wrote:
After all, although Evolution is taking 10 seconds to open certain
folders at the moment because it's re-downloading flags, it doesn't
actually _need_ all of those flags
Right. So why does it need to download all of them? Note that the SEARCH
On Tue, 11 Mar 2003, David Woodhouse wrote:
I've already switched from wu-imapd to Courier, because I objected to
wu-imapd trawling through megabytes of each of my project archive
folders, checking the status of each message to see if it's unseen, when
it had done precisely the same thing one
On Tue, 11 Mar 2003, David Woodhouse wrote:
By 'ctime' I meant the inode ctime on the underlying file system, for
the inode of the mbox file.
I know what ctime is.
When configured to 'check for mail in all folders' Evolution is issuing
a LIST command, and then for each mailbox listed it's
On Tue, 11 Mar 2003, David Woodhouse wrote:
Evo _does_ generate unusually high traffic to the server. You select a
mailbox and it'll refuse to display _anything_ until it's got _all_
headers for _every_ mail in that mailbox. You select a mail with a small
text/plain body and a _huge_
On Tue, 11 Mar 2003, David Woodhouse wrote:
I'm trying to take the view IMAP is too limiting; how can
we fix it.
That's not the right view. You should instead have how can I build a
good client within the context of IMAP, without expecting the existing
IMAP world to add facilities to enable
On Wed, 5 Mar 2003 10:50:53 +0100, Martin Sanneblad wrote:
- Multiple sessions doing STATUS or EXAMINE will all recieve the same RECENT
number.
Desirable, but not guaranteed. Also, remember that any session that does a
SELECT will cause recent to be turned off in subsequent sessions.
- Doing
On Mon, 3 Mar 2003, Arnt Gulbrandsen wrote:
But I don't
see any obligation for MTAs or UAs to deal with whatever random
trash is thrown at them.
Be conservative in what you accept and all that, right?
Ten or eleven years ago I was told (on ietf-smtp?) that I had
misunderstood that
On Thu, 27 Feb 2003 20:56:40 -0800 (PST), Dominic Say wrote:
I tried to Fetch rfc822.text but the response was
was follows
*1 FETCH (RFC822.TEXT {608}
PCFET0NUWVBFIEhUTUwgUFVCTEIDICIL0VOIj...
...)
tag OK FETCH completed.
That looks like BASE64 data. Did you
On 26 Feb 2003 10:57:14 -0800, Max Okumoto wrote:
Hi, is there a way to make imap-2002 ignore ~/.snapshot directories
in the users home directory?
Look in imap-/src/osdep/unix/dummy.c, routine dummy_list_work(). There's
already code there to ignore mx format mailboxes (since they are
On Tue, 25 Feb 2003, David Harris wrote:
The best thing I've *ever* encountered is Mark Crispin's torture test
mail message. This is a massively complex 1.8MB mail message that
uses just about every aspect of MIME. If your parser can parse this
message reliably, then it can parse just about
On Tue, 25 Feb 2003, Timo Sirainen wrote:
This brings to my mind about the differences between my and uw-imap
implementation.. BODYSTRUCTURE description says that fields should be
defaulted as necessary but nothing more, so I don't think I'm doing
anything wrong exactly, but would it still be
For what it's worth, Pine's default polling interval is 150 seconds, and
my old MailManager's default polling interval is 180 seconds. Neither
program has ever encountered problems with NAT timeouts.
However, it does seem that using the IDLE extension will provoke a NAT
timeout, so a client that
On Tue, 25 Feb 2003, Tomki wrote:
What is the expected behaviour of imaputil when used so, on a normal UNIX
mailbox:
imaputil copy SPAM SPAM2
I see that it does change some things in the output mailbox.. but it
appears to be still in the same standard format.
mailutil copy will make an
On Sat, 22 Feb 2003, DINH [iso-8859-1] Vi$Bj(Bt Ho$B`(B wrote:
In a typical day, I use from three to five different computers to access
my mail. So do my co-workers.
don't you use NFS to keep the same cache ? :)
and optionnally, the same work ?
I'm sure that this question is a joke,
On Sat, 22 Feb 2003, Andreas Aardal Hanssen wrote:
If John has one IMAP session and appends a message to mailbox B, and Jack
has selected the same folder B in another IMAP session/connection and
issues NOOP straight afterwards (John goes now! and Jack goes NOOP!),
Can Jack expect to see the
On Sat, 22 Feb 2003 18:55:07 +0100, DINH =?iso-8859-1?Q?Vi=EAt_Ho=E0?= wrote:
The fact is that, personnally, I use the IMAP mailbox of my provider
from two main point : at home and at work and the cache can bring some
speedup in this case.
How does it do that, when less data is transmitted
On 21 Feb 2003 19:02:26 +0200, Timo Sirainen wrote:
OK, I looked through c-client and Pine code. It looks just as difficult
as I expected. It uses multiple arrays for seq - message lookups.
Bullshit. There is one cache. Don't get confused by the sortcache which is
not seq-message lookup.
It
On Fri, 21 Feb 2003, Russ Allbery wrote:
D J Bernstein [EMAIL PROTECTED] writes:
Actually, there's very little opposition (especially among implementors)
to requiring all MTAs, MUAs, etc. to handle UTF-8 messages. Eventually
we will all be using UTF-8; all relevant bugs must be fixed. Only
On Fri, 21 Feb 2003, Timo Sirainen wrote:
But whenever sorting is done, there is the sort array that has to be
updated and accessed slowly whenever you get fetch envelope reply
(pine_imap_envelope - mn_raw2m() - msgno_in_sort()).
Wrong. What you are seeing in Pine is a mapping from a view.
On Fri, 21 Feb 2003, Russ Allbery wrote:
Usenet's restrictions on the syntax of message ID headers are very
specific and very precise, and much stronger than those of RFC 2822, in
part because message IDs are used as part of the NNTP protocol.
What are those restrictions?
Comments
in
On Thu, 20 Feb 2003, Russ Allbery wrote:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14
-+--
A| D C N N D Y N N N Y N D Y D
B| Y Y C Y Y N N N N N N N C D
C| D C C C
On Fri, 21 Feb 2003, Timo Sirainen wrote:
I don't know anyone who accesses their mail from more than a few
computers.
In a typical day, I use from three to five different computers to access
my mail. So do my co-workers.
I use IMAP only at home for accesssing my mails, elsewhere I
just ssh
On Fri, 22 Feb 2003, Timo Sirainen wrote:
Well, you stated your problem: you don't use a good IMAP client.
That could be it. Installing and running would have to be as easy as
sshing with putty though. Meaning you could get imapclient.exe from web
page which you can run directly, only
Your best course of action is to configure your IMAP client to use SSL (port
993) if it does not support TLS. Modern versions of good clients, such as
Pine, will automatically negotiate TLS without any need for user action. With
lesser clients, such as Outlook, you have to configure use of SSL
On Thu, 21 Feb 2003, Timo Sirainen wrote:
I meant mostly that could it send reply to first command before the
other? That could get pretty confusing with getting LIST or SEARCH
replies in different order than expected. Or even mix the LIST replies
together.
Your understanding of the potential
On Thu, 21 Feb 2003, Timo Sirainen wrote:
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.
There are many things that you can do with sequence numbers that you
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 is deleted.
An obvious structure is a vector of pointers
On Tue, 18 Feb 2003, Tony Shadwick wrote:
Uh, it's not Pine's problem. It's IMAP's. Users using Outlook Express,
SquirrelMail, Entourage, KMail, all have the same problem. When
connecting to the server via IMAP the inbox shows up as empty, whereas if
they read mail using pine, all the inbox
On Sun, 16 Feb 2003, Dan Kohn wrote:
I believe actual use of Usenet diverged from RFC 1036 because the latter
didn't support internationalized (i18n) headers or i18n newsgroup names.
As a result, most international users started sending a hodgepodge of
different, unlabeled charsets, which
On Mon, 17 Feb 2003, Charles Lindsey wrote:
I am sorry, but the IMAP list doesn't seem to accept messages from me.
You need to subscribe to the IMAP mailing list. You had better do so if
you wish to continue to propose incompatible changes to IMAP in order to
accomodate your proposed changes to
For what it's worth, I agree with all of Ken's points.
I'm not certain what Usefor is attempting to accomplish. If the goal
is IETF standardization of a message format which is incompatible with
the message format of other protocols, then Usefor has set itself an
impossible goal.
Kohn's draft
On Sat, 8 Feb 2003, Charles Lindsey wrote:
I don't think the last vestiges of just send 8-bits using non-UTF-8
character sets and no MIME tagging are being exterminated, or ever will
be. At the moment they seem to be well entrenched in Usenet, especially
in the Chinese newsgroups, and no
On Thu, 06 Feb 2003 17:09:00 -0800, Mike Macgirvin wrote:
The old
Netscape clients had an otherwise disabled menu button for managing mail
account or somesuch. If it had a URL, it would enable that item.
No, that is not how it worked.
It kept the menu button enabled. When the user tried to
Hi Charles -
Thank you very much for your email. I have bounced it to the IMAP mailing
list. This response is also going to the IMAP mailing list.
I agree that it is desirable to transition towards a future in which
mailbox names, email addresses, newsgroup names, and header texts are
8-bit
On Sun, 2 Feb 2003, Matthew T. O'Connor wrote:
Hello, I am trying to get the imap-utils installed on a RedHat 8.0 box.
If you get imap-2002 or newer, you will get the mailutil program bundled
which supercedes the imap-utils.
../imap/c-client/c-client.a(osdep.o): In function
To answer your questions:
By default, the software tries to establish pre-authenticated connections to
an IMAP server via rsh and possibly ssh. Adding the /norsh switch to any IMAP
mailbox specifier will quell this:
mailutil -verbose transfer {emax/pop3} {imp/norsh}test/
There is no
Note however that while RFC 2683 permits a server command line length
limit (and 8000 octets is the recommended value), a client must be
prepared to accept a response line of any length from the server.
Some IMAP response lines can be quite long. Fortunately, the client
usually has a clue that
On Thu, 30 Jan 2003, Cyrus Daboo wrote:
That's not all that is necessary. First clients need a way to discover the
name of a mailbox with an associated ID. Second, it would be more useful if
commands that currently take mailbox names could be modified to take
mailbox IDs so disconnected client
On Tue, 28 Jan 2003, Timo Sirainen wrote:
Sure. And I don't think I've said anything that would indicate otherwise.
The keyword in my comment above was *LESS* resource intensive. Using
multiple connections may be light, but using STATUS may still be lighter.
NEVERTHELESS...
The specification
On Wed, 29 Jan 2003, Lawrence Greenfield wrote:
Nonsense. A client should be implemented with the author's best guess
of what is and isn't expensive.
That's the argument used by Netscape and Outlook -- program the client so
it works with one particular server, don't worry about everything else.
On Tue, 28 Jan 2003, Timo Sirainen 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.
I still dispute that point,
On Tue, 28 Jan 2003, Andreas Aardal Hanssen wrote:
I have probably misunderstood something about the wonderful world of
untagged responses. My whole interpretation was that many of these
responses, typically FETCH, can show up in most occasions, even when the
client does not ask for it, and
On Tue, 28 Jan 2003, Mark Keasling wrote:
Please do not gratuitously break my client.
Hi Mark -
You are not the only person who has a client with a RENAME facility.
Nevertheless, RENAME as it is currently constituted breaks UIDs, and that
breaks IMAP as a reliable protocol for disconnected and
On Mon, 27 Jan 2003 19:36:38 +0100 (CET), Andreas Aardal Hanssen wrote:
x store 1 flags ()
* 1 FETCH (FLAGS ())
x OK Completed
OT, but why does the server return the FETCH update when no change has
been made to the flags?
Very off-topic, since in the example above flags are being changed.
On Mon, 27 Jan 2003 20:04:14 +0100 (CET), Andreas Aardal Hanssen wrote:
The updated flags yes - so the unupdated flags need not be returned, no?
If an external entity changed flags (which is what is being discussed), then
there is always an update. The question is therefore meaningless.
3
On Mon, 27 Jan 2003, Andreas Aardal Hanssen wrote:
Then I think you don't understand my question.. Should STORE _always_
return an untagged FETCH response, even if the flags were _not_ updated?
No. STORE does not return an untagged FETCH response when you use
.SILENT.
Perhaps your question
On Mon, 27 Jan 2003, Andreas Aardal Hanssen wrote:
The updated flags yes - so the unupdated flags need not be returned, no?
If an external entity changed flags (which is what is being discussed), then
there is always an update. The question is therefore meaningless.
Spare me the hostility -
On Mon, 28 Jan 2003, Timo Sirainen wrote:
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
On Mon, 27 Jan 2003, 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 new names.
801 - 900 of 1002 matches
Mail list logo
