Marek Kowal [EMAIL PROTECTED]
The problems are entirely at the Outlook end. The best way
to get them
resolved is to file problem reports with Microsoft.
The other way, of course, is to patch the server sources with some
interesting #define, i.e. MICROSOFT_BRAIN_DAMAGE, in which case
David Morsberger [EMAIL PROTECTED]
I switched to the mbox format and I have not had a connection error since.
Not sure if this is apples vs. oranges.
It is. One issue is about multiple IMAP clients accessing the same folder
at the same time. The other is about the inactivity timeout.
--Arnt
Gaël Roualland [EMAIL PROTECTED]
Yes, * is translated for 1600, so that gives the range 1601:1600.
But does that have sense ?
Sure.
(general understanding is probably that the
second sequence number must be larger or equal to the first one, but I
can't find it in the RFC).
Precisely. As
Paul Smith [EMAIL PROTECTED]
Precisely. As far as the RFC says, 1:2 and 2:1 are equivalent.
It doesn't say this.. (as far as I can see). It's open to interpretation
from reading the RFC.
Exactly. ;)
It says a:b means all the messages with MSNs/UIDs between a and b,
inclusive. That's
Mark Crispin [EMAIL PROTECTED]
Courier violates IMAP in multiple ways.
Could you elaborate?
--Arnt
Simon Josefsson [EMAIL PROTECTED]
UID SEARCH UID generates quite some data too, but it is just a
fraction of the above.
Well, you can improve on that too.
I use a combination of FETCH UID and UID FETCH UID, and a loop that splits
unknown UID ranges into smaller ranges.
Assume that in my
David Harris [EMAIL PROTECTED]
This is fine in theory, but how do you handle sorting?
I keep my client-side data sorted appropriately. When the server tells me
something, I insert it into my clientside data structures and remind
myself to update my display.
If I discover that UID 12444 doesn't
Lawrence Walton [EMAIL PROTECTED]
We have just put a new server into production
running UW-imapd-ssl. Within an hour or
two we started getting the following message
in syslog:
Jul 1 08:32:51 messenger inetd[19852]: imap2/tcp server failing (looping), service
terminated
So, why are you
Mark Crispin [EMAIL PROTECTED]
The more difficult issue is if the client asked for BODY[TEXT]386.16384.
I contend that BODY[TEXT]386 (zero bytes starting at byte 386) in no way
implies that byte 385 exists, and thus the server should respond in the
same way rather than issuing an error. Of
All IMAP servers must present the user with an INBOX. INBOX may also be
present under another name.
Is it common that IMAP servers also make INBOX available under a different
name? Is there a way to find out whether two different names refer to the
same mailbox?
--Arnt
--
The client can also use the widely-implemented IDLE extension, see RFC
2177, and there are current proposals for real-time notification. I
haven't followed that, but the acronym SNAP comes to mind.
--Arnt
Mark Crispin [EMAIL PROTECTED]
The messages still exist, and will continue to exist until the untagged
EXPUNGEs are transmitted. RFC 2180 offers NO as an option; however I
contend (and empirical evidence has shown) that OK is what works best.
RFC 2180 offers three ways that OK can happen:
DINH Viet Hoa [EMAIL PROTECTED]
if I (as an IMAP client) have to exit quickly and have an open IMAP
connection, I can't wait around for the IMAP server's responses.
What is the reason for this ?
I can think of four possible reasons right away. There might be more.
1. The user closes the
Mark Crispin [EMAIL PROTECTED]
There are worse consequences.
...
The result is that the flag changes are lost.
Good point.
The only excuse for a client not to send a proper LOGOUT is if the client
crashes. The LOGOUT command is in the protocol for a reason, and that reason
was not
C: a fetch 1 uid
C: A fetch 2 uid
S: * 1 fetch (uid 1)
S: a ok
S: A 2 fetch (uid 2)
This line should be S: * 2 fetch (uid 2). Sorry.
S A ok
--Arnt
Andreas Aardal Hanssen writes:
If the current protocol says that the client should either use TLS or
SSL, then I suppose connecting to it through stunnel makes the
connection to the IMAP server a plain-text connection.
Well, it doesn't. The near-future protocol says that.
I'll give good odds
Andreas Aardal Hanssen writes:
So even if it isn't too clear _why_ a client would want to do this,
it's obviously a case that is not handled in the rfc in any way.
Here's a plausible example:
Suppose I've been using elm to read mail and store them in local folders
for the past fifteen years.
Barra Seck writes:
I'm writting an IMAP4rev1 client api in which I need to map the UID to
a 5 digits value for my client.
What should happen if there's 10001 messages in the mailbox?
Apart from that, it sounds as if the MSN is what you want.
--Arnt
Barra Seck writes:
My api should retrieve the mails one by one and all the time indicates
with 5 decimals an identifier to the current retrieved mail and to
the next mail.
Seems like you need to map the hard way - persistent mappings from the
UIDVALIDITY+UID to your own numbers.
The simplest
Mark Crispin writes:
The reasons given are specious. The text REFERENCES is something
that it sent over the wire. It has nothing to do with anything that a
human would see.
I'm a programmer. I'm human. I see the text.
This working group has a deplorable history of saying do what you
want,
Andreas Aardal Hanssen writes:
And I don't buy the argument that a server can't store 4bytes
UIDVALIDITY somewhere when mailbox is deleted/renamed.
Do you understand the problem with UIDVALIDITY and RENAME? Not only do
you have to store your 4 bytes, but you will have to store all
UIDVALIDITY
Andreas Aardal Hanssen writes:
What happens if the alternative UIDVALIDITY log file gets messed up?
If the server's persistent storage is messed up, every guarantee breaks.
One example among dozens: If the server's UIDNEXT storage is
hand-edited, the UID grows guarantee is broken.
--Arnt
Andreas Aardal Hanssen writes:
On Wed, 22 Jan 2003, Arnt Gulbrandsen wrote:
Andreas Aardal Hanssen writes:
What happens if the alternative UIDVALIDITY log file gets messed up?
If the server's persistent storage is messed up, every guarantee
breaks. One example among dozens: If the server's
Timo Sirainen writes:
Or just send it escaped (\).
The sound you hear is me frantically scrambling to fix my code, only to
see that the code was right ;) I actually had forgotten that 'string'
could contain escaped characters.
--Arnt
Timo Sirainen writes:
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.
Not just memory and CPU - I've seen evil NAT boxes that apparently
discard an old connection or two when the
Mark Crispin writes:
There is another advantage to always sending updates with STORE: the
server would otherwise have to maintain a record of client state. It
already has to keep track of its own state, and the state of the mail
store. Resolving three states is much harder than resolving two
Mark Crispin writes:
Any TCP implementation, in which the cost of a static connection is
non-trivial, is broken.
Speaking personally: I agree wholeheartedly. And if I had any realistic
plan for getting rid of all the NAT boxes in the world, I'd do it.
However, the evil boxes are here and they
Andreas Aardal Hanssen writes:
I have probably misunderstood something about the wonderful world of
untagged responses.
I think you've actually understood it too well. You've understood it so
well that your beautiful and coherent design may not interoperate very
well with the such-and-suches
DINH Viêt Hoà writes:
I have question for imap and kmail 1.5 (kde 3.1.0) Kmail send to imap
server NOOP for every 15 second. Is it obligate to keeep connection
to server (I thik that imap server keep connection for 3 min if
haven't login and 30 min with login in imap)
Kmail should use the IDLE
Timo Sirainen writes:
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
DINH Viêt Hoà writes:
And are you sure NOOP every 15 seconds will be suffisant ? your NAT
seems to expire quickly.
Catch me using NAT ;)
I do, however, know that certain NAT-like boxes expire much more quickly
than 29 minutes, at least when there are many idle connections. I
haven't checked, but
Benjamin Franz writes:
You mean like the mail I just fished out of my box that starts like this?
To: [EMAIL PROTECTED] Subject: Welcome to Wells Fargo Online®.
I'm glad to know that it wasn't English. Or important.
Was it 2047-encoded?
FWIW, I used to get mail kind of like that from a company
Dominic Say wrote:
Is there anything to look out for at the end of the text message so
that i can comfirm the end of message so that this wont happen?
Usually not. Messages are typically in literals, which are counted strings.
any clues anyone?
You need a good book about this stuff.
--Arnt
Dave Barr writes:
On Sat, 2003-03-01 at 17:13, Keith Moore 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
Timo Sirainen [EMAIL PROTECTED] wrote:
On Tue, 2003-03-04 at 18:21, Steve Hole wrote:
A well written client should fetch BODYSTRUCTURE as preferentially before
fetching any other body data.
But if I'm just browsing message headers, only thing I need is ENVELOPE.
BODYSTRUCTURE is needed
Timo Sirainen writes:
Have you even looked at what BODYSTRUCTURE actually returns?
Not, I must confess, since I wrote code to use it.
It doesn't return From field. It doesn't return To field. It doesn't
return Date field.
My bad. For some reason I confused the top-level message with
The problem isn't an IMAP problem. Or a sendmail problem.
One peer is trying to initiate a SSL/TLS handshake while the other peer is
not talking SSL/TLS at all. OpenSSL misconfiguration, I dare say. Not an
issue for this list.
Can we now get back to talking about IMAP protocol issues?
--Arnt
In IMAP, a client is free to cache any part of a message for as long as it
wants. That implies that once a server has sent e.g. a message's ENVELOPE
to a client, that message can't be changed any more, or the client's cache
would hold incorrect data.
The only way for a server to invalidate the
John,
Offline IMAP use with UIDs for cache resynchronization was first mentioned
in RFC 1733, which was published in December 1994. The concept may be
older, but at least it's eight years old.
So, what are you suggesting, precisely? To me it sounds as if you want to
break compatibility with
Padmanaban Kumar writes:
Can we get the timestamp at which a flag (system / user-defined) was
set for a message (without storing it separately at the time when it
was flagged ) ?
Not in basic IMAP. The CONDSTORE and/or ANNOTATE extensions may help
you, I seem to remember that one of them
[EMAIL PROTECTED] writes:
Kindly unsubsribe me from the mailing list.
That's not how you do it. A google search for 'unsubscribe' and the name
of the mailing list invariably shows how to. In this case:
http://www.google.com/search?q=unsubscribe+imap%40u.washington.edu
The first result is:
Timo Sirainen writes:
On Thu, 2003-04-03 at 05:55, Mark Keasling wrote:
This behavior will cause more harm than good.
In what way? It affects only broken clients.
De facto it extends the protocol in weird and magic ways. The next
client author doing i14y testing against your server (and against
Richard Bang writes:
Hi,
Would the following be considered a valid request
BODY.PEEK[1.1,1.4,1.3,1.2]25...647
No. The bit inside [] is not a section-spec, and it should be . not
However, you can do something roughly equvalent (from memory, might be
off a little):
a FETCH 1
date-time is used a few times in the grammar, but in SEARCH date is
used, e.g. SINCE date, not SINCE date-time. Is there any particular
reason for that?
Just curious.
--Arnt
--
-
For information about this mailing list, and its
Mark Crispin writes:
On Wed, 4 Jun 2003, Arnt Gulbrandsen wrote:
date-time is used a few times in the grammar, but in SEARCH date is
used, e.g. SINCE date, not SINCE date-time. Is there any particular
reason for that?
Yes. When IMAP was first defined, times and timezones were much less
Gangadhar Mylapuram writes:
Hi all, A small doubt.
suppose i want to maitain a filter on incoming messages, how can i
divert the message to specified folder?
Sieve is the canonical solution.
My idea is, we have to check for recent message headers and then based
on from address i have to move
Gangadhar Mylapuram writes:
According to my observation, BYE response form server is the one. ARE
THERE ANY OTHER REASONS?
Yes. For example, if there is another client active, that client can
cause EXPUNGE, EXISTS, FETCH and other responses to be sent to you.
I am considering for mobile
Larry Osterman writes:
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 reason for this
currently
Timo Sirainen writes:
How is keeping client state in mind with SEARCH any different than with
FETCH?
The UID SEARCH command takes MSNs as arguments, yet is not covered by
the restrictions 3501 5.5 imposes on FETCH, STORE and SEARCH. Therefore
a client can conceivably send MSNs that have become
Philip Guenther writes:
[This would be easier to read if the UIDs and msgno didn't overlap...]
(I suppose so. OTOH, they distracted you so you did not see the syntax
error... ;)
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
Edward Hibbert writes:
Thanks for the various replies on this.
I have a follow-up question about sequence numbers. Again, apologies
if it's been covered before.
Many times ;)
There's a window where a client hasn't yet picked up an untagged response
and therefore uses a sequence number that
Lyndon Nerenberg writes:
Do servers generally do that?
Servers are *required* to do that.
And yes, they do it.
--Arnt
Timo Sirainen writes:
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
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 the middle, whether client has to establish
connection or it
I started my last message by typing something like this is brief and
simplified; see the grammar for the full and exact truth. But then I
got carried away and by the time I hit send, it was easy to be misled.
Sorry.
What I wrote is a useful rule of thumb for a client, but the description
of
Gangadhar Mylapuram writes:
Dear Arnt,
The client, which was developed with IMAP4(rfc1730), wants to connect
to the UW IMAP server (supports IMAPver4rev1). In this case server
has to support a command like PARTIAL(even it is obsleted).
That's fairly easy: Either you can download a ten-year-old
Gangadhar Mylapuram writes:
Which RFCs has to be considered while developing IMAPservers/clients?
3501, 2595, 2683 and the specifications for whatever IMAP extensions you
use/support.
--Arnt
Cyrus Daboo writes:
IMAP is just not a very rich protocol, Steve Conn, Exchange Server
product manager, told ZDNet Australia during the company's Tech Ed
conference.
Well, that one sentence may be right, but there's a long jump from not
very rich to not good or even not good enough. Good is an
Stefan Tanurkov writes:
If a protocol allows extensions, it is rich by definition because it
allows building feature-rich software based on this protocol.
I cannot really agree with that.
An implementor has to consider: Which features are realiably available?
If the endlessly possible
Larry Osterman writes:
My statement was intended to be a value-neutral statement - the
proprietary protocols have more features than the open standard
protocols.
Naturally. It's much easier for two teams sitting in adjacent offices to
agree on how to add a feature and get it done than it is for
Pete Maclean writes:
The Exchange protocol is orders of magnitude richer than IMAP, but
it's not standard (which is why it's totally proprietary :)).
But is it fair to say that the Exchange protocol is a protocol in the
same sense as IMAP, or even a true protocol at all?
Not in the same sense.
Marcel Crasmaru writes:
Hi everybody,
I have some questions regarding IMAP.
First, it seems that RFC 3501 is missing the definition of 'CHAR'.
CHAR is defined in RFC2234, which defines the grammar used in RFC 3501
(and most other RFCs, but not RFC 2060). It's a seven-bit US-ASCII
value
David Harris writes:
I'm looking for guidance on the best practice when handling
syntactically invalid message id's in FETCH ENVELOPE responses. One
of my users has some messages that contain message-id fields like
this:
This will make a lot of people protest, I guess.
If you bother to check
Mark Crispin writes:
On Thu, 11 Sep 2003, Marcel Crasmaru wrote:
c1: a store 1 +flags (\Deleted)
s : * 1 FETCH (FLAGS (\Deleted) UID 3)
s : a OK store
So far, so good.
c2: aa store 2 +flags.silent (\Deleted)
s : * 1 FETCH (FLAGS (\Deleted) UID 3)
s : aa OK store
The FETCH response is wrong.
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?
That client is asking information about mailboxes whose names start with
foo/ and
Mark Crispin writes:
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 saying all along.
Yes. IMHO, Rob is right
Mark Crispin writes:
On Tue, 16 Sep 2003, Arnt Gulbrandsen wrote:
So, why should the IMAP server be telling the IMAP client about
entities that have nothing to do with mail?
Because those entities affect the behavior of the IMAP names.
Lots of things do, most of which are rightly ignored
Ken Murchison writes:
Arnt Gulbrandsen wrote:
Ken Murchison writes:
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 saying all along.
Yes. IMHO, Rob is right
Ken Murchison writes:
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.
--Arnt
Mark Crispin writes:
Most of the people who express bewilderment about listing foo/ don't
deal with such a store.
Why should client authors deal with such a store?
RFC 3501 gives me the impression that IMAP clients deal with IMAP only;
they're not supposed to care about which particular kind of
Mark Crispin writes:
That is an extremely harmful position to take.
Oh?
IMAP does **NOT** (NOT!!!) define the semantics of a mail store in any
way. Rather, IMAP is a means to export/import a mail store.
IMAP would seem to define at least two things: there is an MSN, and
there is a UID and
Marcel Crasmaru writes:
Please let me know if there was any attempt to make explicit locking
of mailboxes an IMAP extension.
...
As one may see, C1 can not physically delete the message 1 if odds are
against it. An explicit locking mechanism may help:
That's a rather contrived example. Can you
David Harris writes:
Is it reasonable for client 1 to receive this response (assuming that
the sequence numbers are correctly adjusted as required):
AAA EXPUNGE
* x FETCH (FLAGS (\DELETED))
* x EXPUNGE
* y EXPUNGE
AAA OK Expunge Completed
It's correct, but is the flag update necessary? Consider
Arnaud Taddei writes:
Arnt Gulbrandsen wrote:
I believe neither does. AFAIK, only Mulberry does.
I thought Mulberry was supporting IMSP and Eudora can support ACAP??
Maybe I need a reset on these ones.
Could be - I always used to mix up IMSP and ACAP. Anway, I've never seen
another client
Marc Groot Koerkamp writes:
Finally, what's the use of untagged NO responses (warnings) when each
server has it own specific warnings.
When I take the example again and all were untagged NO responses then
we have:
Bogus sequence in FETCH
Invalid message sequence number 121212
No matching
Slavo Uhrin writes:
Hello,
I have a similar question to the previous one about fetching a non
existent message sequence.
What exactly should server do when fetching a message with invalid
MIME header or body?
This was asked a some time ago. Timo Sirainen answered it well in the
recent thread about
Chris Wilson writes:
i've been able to find little documentation on the standalone
oepration of UW Imap, is this possible?
Why do people always want that?
I mean, it makes sense for services like DNS and HTTP, but why do people
want it for IMAP?
--Arnt
Vladimir A. Butenko writes:
The current versions of CommuniGate Pro store address books as vCards,
you can see how it's done there - but again, if someone wants to
write a client that just follows the standards, it's a no-brainer.
The problem usually is to follow the unstated restrictions when
Chris Wilson writes:
squirrelmail says it'll improve my performance, kinda makes sense.
http://www.squirrelmail.org/wiki/en_US/SquirrelMailPerformance
I'm seeing that IMAP connection open takes about a second, depending on
RTT. Most of that is STARTTLS and AUTHENTICATE processing.
Starting the
Rob Siemborski writes:
On Fri, 10 Oct 2003, Arnt Gulbrandsen wrote:
I'm seeing that IMAP connection open takes about a second, depending
on RTT. Most of that is STARTTLS and AUTHENTICATE processing.
Sure, but if the machine is seeing many connections per second, its
maximum fork rate starts
Slavo Uhrin writes:
Hello,
in 6.3.1 it is stated that the untagged UNSEEN response to SELECT is
REQUIRED and that server MUST send the listed untagged data to the
client. However, in detailed explaining of UNSEEN we can read that
if this is missing, the client cannot make any assumption about
Larry Osterman writes:
I just received the attached bounce message from the mail I sent.
I don't know who generated it, but it may possibly be the WORST bounce
message I've ever seen.
Lucky you.
I think that ISP generates a message like that for each message going to
Slavo Uhrin [EMAIL
Chad Woolley writes:
Hi,
Sorry if this is off topic, if so please let me know where I can go :)
...
You're basically saying, I wish mozilla and others used Sieve and
ACAP. Well, so do I. The state of Sieve and ACAP support is sad.
You can ask the Mozilla people to implement Sieve and ACAP
Your proposal would do violence to IMAP caching.
At present, a client knows that if it has read a message identified by
the tuple (mailbox, uidvalidity, uid), there is no need to reread.
Pretty much all clients I've seen depend on this. Some cache on disk,
others merely in RAM. Some cache the
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 ACAP mailing list archives for the discussion which led to the
design of ACAP.)
Richard Bang writes:
I thought that ACAP stood for Application configuration access protocol
Not shared groupware objects protocol .
I don't see the connection between an address book entry and an ACAP entry!
Well, what's application configuration, exactly? Anything that goes in
the Window
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/digest and want to fetch all the subject
and from fields from the
DINH Viet Hoa writes:
Currently, my client allows people to display just the message counts
of a mailbox :
http://libetpan.sf.net/etpan/images/folder-list-view.png
And for IMAP mailboxes, I just do that, then, when the user choose the
mailbox, there is more things.
Good point.
I was thinking
Andreas Aardal Hanssen writes:
Be careful when reporting this bug to the Courier-IMAP project, or you
might just get flamed (seriously).
I am shocked. Are you really serious?
--Arnt
Richard Bang writes:
This brings up the point that we need a test suite produced by the
IMAP community that can be used to validate servers. It will resolve
these issues for once and for all
...
Not very likely. One thing is that the test suite won't be complete, for
various reasons. What should
Christof Drescher writes, answering Abhijit Menon-Sen:
Minor nit: it's an nstring, which can be either quoted (no length),
or a literal string (with a length, as you show in your example). I
think most servers send a literal or perhaps NIL, though.
Yes, in a way: In this case, it's an answer to
There is another problem that noone has pointed out:
Chun-Ping Man writes:
C: 004 fetch 4827313 (UID RFC822.SIZE BODY.PEEK[HEADER] FLAGS)
You would not get this command at all unless your server has told the
client there are five million messages in this folder, e.g. using
* 4827313
Richard Bang writes:
Thus I would like to ask if the following sequence is compliant:
003 SELECT Folder
* FLAGS ()
Sorry, no. The FLAGS response occurs as a result of a SELECT or EXAMINE
command. The flag parenthesized list identifies the flags (at a
minimum, the system-defined flags) that are
Chun-Ping Man writes:
hi,
hm that's strange, perhaps I describe the whole scenario.
netscape try to access to my imap-test-server.
After I response the select command from the client (S: * 1 EXISTS;
S: * 1 RECENT, etc.)
I get following UID command from the client:
C: 003 fetch 1:* (FLAGS)
Antonio Cambule writes:
That is why I said there should be no problem for me writing an IMAP
Server. I think the most difficult work is done.
Based on the problems mentioned in the past few days, I think you're wrong.
Good luck.
--Arnt
Richard Bang writes:
Thanks for the clarification, but does returning read only allow me to
return the suggested response to the attempt to change the flags?
i.e.
005 STORE 1 FLAGS (\seen)
005 OK STORE Completed but I ignored you because this is read only
Almost. You also need to return FETCH
Richard Bang writes:
Hi,
Here is the final version, thanks for all the feedback on this. I hope
that this proves to be acceptable and is compliant.
Looks very good.
I saw Mark's comment about RFC 1176, and disagree. That's IMAP version
2, I wouldn't worry about it. Either you should support
Mark Crispin writes:
On Wed, 10 Dec 2003, Arnt Gulbrandsen wrote:
Either you should support IMAP2, in which case you should actually
test with IMAP2 clients (good luck finding any), or you should
decide not to support it and your current responses are fine.
That is an amazingly callous thing
Mark Crispin writes:
On Thu, 11 Dec 2003, Marcel Crasmaru wrote:
IMHO the following clarification
A UID is NOT sent in the following cases:
unsolicited FETCH responses
should be explicitly stated in the next version of the IMAP
specification.
The problem with doing this is that there are
Christof Drescher writes:
Arnt Gulbandsen wrote:
TCP connections are cheap, once opened. And even opening can be
cheap, depending on whether you're using TLS or not and what sort of
authentication you're using.
It might be cheap for modern pc systems and only concerning the
Network overhead.
1 - 100 of 143 matches
Mail list logo
