Michael Wener writes:
Is it fair to say that once a UID is visible within a session it is
shared state?
Yes. It's shared with all other sessions that have the same uidvalidity
and mailbox, and in which that UID is visible.
My goal and intent at the moment is to understand the concept of a
Andreas Aardal Hanssen writes:
Take a look at this funny IMAP transmission between Binc IMAP 1.2.10
and Pine 4.58. Who's at fault here, Binc or Pine?
Both?
0008 FETCH 1 BODY.PEEK[HEADER.FIELDS ()]
* 1 FETCH (BODY[HEADER.FIELDS ()] {2}
)
0008 OK FETCH completed
Neither the command nor the
Mark Crispin writes:
Although it is possible to use \ as a hierarchy delimiter, the fact
that it's a quoted-special makes it somewhat painful to use from the
point of view of a server implementor. That's why most servers use /
or ..
A side note: IIRC the perl cpan code mishandles \ as
Stuart Nicholson writes:
However I would expect folders that can't be modified to have the
READ-ONLY property surely? We see things like this (taken from a user
log):
0003 SELECT INBOX[0x0D][0x0A]
* 40 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1012731894] UID validity status
* OK [UIDNEXT 7880]
1. The berkeley separator line is just that - a separator line. It's not
part of the message, and cannot be, because it's not valid according to
either RFC 822 or 2822 syntax.
2. If you'll cast a glance at RFC 2821 page 50, you'll see that when an
SMTP server performs so-called final delivery,
Rob Siemborski writes:
On Fri, 16 Jul 2004, Arnt Gulbrandsen wrote:
(I'll be happy with either, though. And I wish people would mention
it on the list when they freeze a draft by releasing code widely.)
...
The problem is often times the only way to fully vet a draft is to
implement and actually
Rob Siemborski writes:
While it might be slightly cleaner, both UW and Cyrus both already
implement the original AUTHENTICATE syntax.
In released versions or just internally?
If in released versions, I suggest a Last Call for the SASL-IR draft right now.
Arnt
Well, I suppose the releases effectively Last Called SASL-IR, then. In
that case, I like Alexey's proposal better than Corby's:
b authenticate (SID 1234432143) plain AGFybnQAdG5yYQ==
(I'll be happy with either, though. And I wish people would mention it
on the list when they freeze a draft by
Hi,
draft-ietf-lemonade-reconnect and
draft-siemborski-imap-sasl-initial-response conflict, because they
extend AUTHENTICATE in the same way.
My preferred way of resolving this would be to make sessions more
explicit in the RECONNECT draft, which would also avoid loading the
server with
Lyndon Nerenberg writes:
This seems wrong to me. IMAP servers are tied to people, not hosts. If
I visit your site, I want don't want my IMAP client to suddenly try
to connect to your site's IMAP servers.
Agreed. However, will it? The only usage for such a feature is, IMHO, to
supply a good
Antonio Cambule (STÜBER SOFTWARE) writes:
Can one mailbox have more than one mailbox attribute at the same time
and if so, can they be combined, like:
...
The examples I've seen and the description talk only about one
Attribute but not more.
Don't write from the examples. On RFC 3501 page 87 you
Alexey Melnikov writes:
Which reminds me: is there any interest in writing/implementing an
extension that would allow a server to return client to the
authenticated (unselected) state?
Sounds like RFC 3691?
Arnt
Mark Crispin writes:
With the exception of EXPUNGE, *ALL* untagged responses may be sent
unilaterally.
At risk of sounding like a broken record... I wish that weren't the case
for SEARCH.
Arnt
Mark Crispin writes:
On Tue, 4 May 2004, Arnt Gulbrandsen wrote:
With the exception of EXPUNGE, *ALL* untagged responses may be sent
unilaterally.
At risk of sounding like a broken record... I wish that weren't the
case for SEARCH.
Why? We may want to do that someday.
The server of someday
[EMAIL PROTECTED] writes:
Is sufficient for the server to send unsolicited UIDVALIDITY, UIDNEXT,
EXISTS, RECENT, and UNSEEN messages (as if the client had re-selected
the mailbox) or will that just confuse existing clients
Some clients will have code to handle it. That code will be largely
Eduardo Kienetz writes:
Ok guys, I'm developing a Groupware system, and it's IMAP mail module
is working fine with both Courier-IMAP and UW-IMAP (same commands)
except to the fact that UW-IMAP seems not to have an expunge trash
command (at least not the same one as courier). So, could someone
Antonio Cambule (Stüber Software) writes:
When the client deletes a mailbox does the server have to unsubscribe
that mailbox from the list?
No. It should not.
Do E-Mail Clients send an unsubscribe command before send an delete command?
They do if they want to.
Arnt
Perry Ruiter writes:
I'm equally surprised at the rush to * BYE a client at the slightest
hint of a problem.
Paul mentioned EACCES, ENOMEM, ENFILE, EMFILE as examples of the
problems he had in mind. I, at least, assumed that he had in mind the
type of severe, unforeseen problem that Should
Paul Jarc writes:
Well, depending on the OS, it might clear itself up after a short
time, like ENFILE. So the server *might* be able to answer the next
request.
Yes, assuming you trust both your code and any libraries used to recover
from ENFILE. Pardon my lack of faith, but I don't trust those
Mark Crispin writes:
On Wed, 24 Mar 2004, Arnt Gulbrandsen wrote:
Some errors are caused by lack of global resources, and sometimes
that lack goes away. For example, if some big batch job is currently
eating most of the RAM, that batch job will finish and the RAM will
become available
Mark Crispin writes:
On Wed, 24 Mar 2004, Arnt Gulbrandsen wrote:
Until such time as that happens, I think authors of clients, servers
and peer are well advised to assume that their servers, clients and
peers may be buggy. To some degree.
Which is why, when a horrible error #69 happens, you stop
Paul Jarc writes:
I infer that this would be reported to the user, and the previous
version would not be. But I still don't know how this is better than
tagged NO.
A tagged NO means something is wrong with that command. An untagged BYE
ALERT means that the server is closing the connection and
Paul Jarc writes:
What you're describing sounds more like BAD. RFC3501, 2.2.2:
...
Yes, I agree. Sorry. Another try: A tagged NO means something went wrong
with the execution of that command.
The user would also be notified for NO [ALERT], right? So the only
difference is closing the connection?
Antonio Cambule (STÜBER SOFTWARE) writes:
If I can ignore subscribe and unsubscribe, this would mean, I can
always return an OK as Server Response, without care about what kind
of LSUB command came in, right? I would handle every mailbox as
subscribed. I should only look if the asked mailbox
Christof Drescher writes:
Just wondering: A server can never GUARANTEE that a client as a recv()
outstanding on the socket while no command is in progress, can it?
Since no client can tell the server that it DOES a recv() by any
means, it must assume that there is NO outstanding recv(), right?
David Harris writes:
OK, this one has me stumped.
Imagine that as a client you get this as part of a response to a LIST
command:
-- Cut here
* LIST () / Public Folders/Busi 3923C2/Carisa Lloyd
-- Cut here
Larry Osterman writes:
Absolutely. It's entirely possible that you can have hierarchy without
there being folders in the middle.
Consider Netnews.
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
With Exchange, this could happen if you
Mark Crispin writes:
On Tue, 6 Jan 2004, Arnt Gulbrandsen wrote:
Alt.Fan doesn't exist, but Alt.Fan.Mark.Crispin might.
In IMAP terms, alt.fan is \noselect \haschildren.
Yes, but such a name shows up with a % wildcard.
It does? Larry, can you confirm that?
It does not necessarily show up
David Harris writes:
Clearly \HasChildren and \HasNoChildren are flag extensions, and
hence must be covered by either an RFC or a standards-track document
that revises RFC3501 itself (see RFC3501 page 85). Could someone
please point me at that RFC or standards-track document?
RFC 3348 IIRC.
Richard Bang writes:
According to what I read, if a client does a search and then does
nothing for 45 minutes, the server CANNOT send any expunge messages
because it does not know if the next command MIGHT be a fetch.
Right.
And it's justified, too. Suppose you send an unsolicited
* 1 EXPUNGE
Here's a strawman argument:
Once a client has commanded the server to delete a message and the
server reports having carried that command out, the message should be
deleted. The server can achieve that in a simple way by deleting the
message at once.
Or it can hide the message and mark it for
Christof Drescher writes:
My idea would be to try it (NO [PLEASENOOP] first; if the client does
NOT catch up after this command (the test is very simple to
implement), the server can still disconnect the client (which would
help for clients not (yet) supporting it).
In that case, just send your
Timo Sirainen writes:
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
Timo Sirainen writes:
BYE feels a bit rude to me
...
Agreed.
I'm currently sending NO, that hasn't caused any problems at least with
Evolution and OSX's Mail.app.
What's your exact condition for sending NO? That the message has been
deleted by someone else?
--Arnt
Christian Kratzer writes:
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.
Client authors really ought to read all the relevant RFCs, don't you
think? And world peace would be good
Christof Drescher writes:
Tim and Mark (2nd choice) favor ghost messessages, while Arnt opposes
it (what are your reasons?).
It violates the IMAP cache semantics. In IMAP, the client knows that if
it has fetched some part of a message, that message won't change. If a
message is silently
Christof Drescher writes:
So - I see the explanation in RFC2180, and given I do not want to
bother with ghost messages or absurdly complicated server states to
keep track of imaginary sequence numbers for this client, what can
a server to conforming to the specs?
Choose:
a) make a simple ghost
Christian Kratzer writes:
theres nothing in the protocol stopping you of handling a trashcan in
your client full transparently to your users.
There is, though: IMAP clients have no way to look at more than one
mailbox at a time.
One of the IMAP servers I personally use presents me with a list
Christof Drescher writes:
I'm baffled why this rule exists in 7.4.1. I'd REALLY be interested to
see an example which would cause a loss in syncronization if
untagged expunge responses are sent at the end of any command.
Consider what would happen if the store is followed immediately by a
fetch
Richard Bang writes:
I have two questions.
1. How have other server writers solved this, have they basically said
tough, its how IMAP works or something else.
The former, AFAIK. Sometimes with some muttered complaints.
2. If there is no consensus other than tough then is there a reason
why I
Paul Jarc writes:
[Old thread. I'm writing a read-only, anonymous-only server for
publishing list archives, etc.]
For the SELECT command, what should a server do for OK [UNSEEN n] when
there are no unseen messages? Omit that part of the response?
Yes. If you look at the RFC 3501 formal grammar,
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.
Christof Drescher writes:
Anyway: Do you argue such an extension would not be wise to have?
I'm not sure. It would be a good feature, but is appropriate as an IMAP
extension, or should it be a separate protocol, perhaps using UDP?
There have been a great many attempts at this, all failed. I do
Larry Osterman writes:
TCP connections are NOT cheap, and do not scale infinitely. When you
have 30,000 clients connected to your IMAP server (a very reasonable
number for a large farm), and each of them is opening 10 mailboxes,
you're talking 300,000 sockets in use.
That will tax the limits
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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.
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
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
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.
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
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
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
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
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
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
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
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
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
1 - 100 of 143 matches
Mail list logo
